From rob.stradling@comodo.com Mon Feb 6 04:21:10 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC5A21F8600 for ; Mon, 6 Feb 2012 04:21:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.367 X-Spam-Level: X-Spam-Status: No, score=-2.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y3qjvuVVFG+v for ; Mon, 6 Feb 2012 04:21:06 -0800 (PST) Received: from mmmail1.mcr.colo.comodoca.net (mdfw.comodoca.net [91.209.196.68]) by ietfa.amsl.com (Postfix) with ESMTP id BA50521F85FF for ; Mon, 6 Feb 2012 04:21:04 -0800 (PST) Received: (qmail 8572 invoked from network); 6 Feb 2012 12:20:59 -0000 Received: from ian.bd.office.comodo.net (HELO ian.brad.office.comodo.net) (192.168.0.201) by mail.colo.comodoca.net with ESMTPS (DHE-RSA-AES256-SHA encrypted); 6 Feb 2012 12:20:59 -0000 Received: (qmail 18143 invoked by uid 1000); 6 Feb 2012 12:20:59 -0000 Received: from nigel.brad.office.comodo.net (HELO [192.168.0.58]) (192.168.0.58) (smtp-auth username rob, mechanism plain) by ian.brad.office.comodo.net (qpsmtpd/0.40) with (CAMELLIA256-SHA encrypted) ESMTPSA; Mon, 06 Feb 2012 12:20:59 +0000 Message-ID: <4F2FC5AA.5070600@comodo.com> Date: Mon, 06 Feb 2012 12:20:58 +0000 From: Rob Stradling User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Hannes Tschofenig References: <4EF84292.50201@gmx.net> In-Reply-To: <4EF84292.50201@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] TLS Cached Information Extension - version 11 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Feb 2012 12:21:10 -0000 Hi Hannes. A couple of thoughts... 1. Have you considered the NI (Named Information) scheme [1] that the DECADE WG have been working on? It "defines a URI-based name form that identifies a named object via hash-based binding". Would it make sense to adapt your definition of CachedObject so that it makes use of NI? (This would obviate the need for yet another hash algorithm registry). 2. Currently, cached-info only allows a TLS Client to indicate to the TLS Server a list of static Objects that it _doesn't_ want to receive (because it already has them). i.e. "Don't send me any Objects of Type X, Y or Z that match Digests A, B or C". How about extending this so that the TLS Client can indicate types of Object that it _does_ want to receive? i.e. "Do send me any Objects of Type X, Y and Z that you have, excluding any that match Digests A, B or C". This added functionality could meet the needs of several other TLS extensions that are being proposed, for example... - Multiple OCSP Responses [2]. - Audit proofs for Google's Certificate Transparency proposal [3]. - TACK rules for Convergence [4]. Or, is it your explicit intention to restrict cached-info so that it only supports the "standard" TLS handshake objects (e.g. Certificate, Trusted CAs list). (I can see that such a restriction could help to ensure that client-side code can be implemented entirely within the network layer rather than bleeding into the application layer). [1] http://tools.ietf.org/html/draft-farrell-decade-ni [2] http://tools.ietf.org/html/draft-pettersen-tls-ext-multiple-ocsp [3] http://www.links.org/file/CertificateAuthorityTransparencyandAuditability.pdf [4] https://github.com/moxie0/Convergence/wiki/TACK On 26/12/11 09:46, Hannes Tschofenig wrote: > Hi all, > > Nikos provided review comments (see > http://www.ietf.org/mail-archive/web/tls/current/msg08338.html) and I > have incorporated them in version 11 of the draft: > http://www.ietf.org/internet-drafts/draft-ietf-tls-cached-info-11.txt > > As you can see, there are a number of smaller changes here and there. I > hope that readability has improved. > > There is an open issue: algorithm negotiation > > Currently, the draft defines a registry for hash algorithms that are > used to produce the hashes of cached information. The client can tell > the server that it has already cached, for example, the certificate > chain. The server then has to only send the fingerprint of it (rather > than the complete certificate chain). The other information (besides > certificate chains) that can be "fingerprinted" is the list of trusted > CAs. Does this cover all use cases? > > A few algorithms are defined, namely SHA-1, SHA-224, SHA-256, SHA-384, > SHA-512. Is this a good list to start with? > > The draft does not define a way for the client to tell the server that > it only supports a certain hash algorithm. Should we allow the client to > indicate what algorithm it supports? > > Ciao > Hannes > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online From wwwrun@rfc-editor.org Tue Feb 7 16:48:11 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CB5C11E8088; Tue, 7 Feb 2012 16:48:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.107 X-Spam-Level: X-Spam-Status: No, score=-102.107 tagged_above=-999 required=5 tests=[AWL=-0.107, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZoZN20Y7KCzU; Tue, 7 Feb 2012 16:48:10 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1D911E808D; Tue, 7 Feb 2012 16:47:56 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 78F3EB1E004; Tue, 7 Feb 2012 16:43:38 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120208004338.78F3EB1E004@rfc-editor.org> Date: Tue, 7 Feb 2012 16:43:38 -0800 (PST) Cc: tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] RFC 6520 on Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 00:48:11 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6520 Title: Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Heartbeat Extension Author: R. Seggelmann, M. Tuexen, M. Williams Status: Standards Track Stream: IETF Date: February 2012 Mailbox: seggelmann@fh-muenster.de, tuexen@fh-muenster.de, michael.glenn.williams@gmail.com Pages: 9 Characters: 16858 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tls-dtls-heartbeat-04.txt URL: http://www.rfc-editor.org/rfc/rfc6520.txt This document describes the Heartbeat Extension for the Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols. The Heartbeat Extension provides a new protocol for TLS/DTLS allowing the usage of keep-alive functionality without performing a renegotiation and a basis for path MTU (PMTU) discovery for DTLS. [STANDARDS-TRACK] This document is a product of the Transport Layer Security Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From lists@drh-consultancy.demon.co.uk Thu Feb 9 08:13:54 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1015E21F851C for ; Thu, 9 Feb 2012 08:13:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nk-zvyRpJgai for ; Thu, 9 Feb 2012 08:13:50 -0800 (PST) Received: from claranet-outbound-smtp03.uk.clara.net (claranet-outbound-smtp03.uk.clara.net [195.8.89.36]) by ietfa.amsl.com (Postfix) with ESMTP id E481E21F8508 for ; Thu, 9 Feb 2012 08:13:49 -0800 (PST) Received: from drh-consultancy.demon.co.uk ([80.177.30.10]:51859 helo=[192.168.7.8]) by relay03.mail.eu.clara.net (relay.clara.net [213.253.3.43]:10587) with esmtpsa (authdaemon_plain:drh) (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) id 1RvWd1-0006bG-AA for tls@ietf.org (return-path ); Thu, 09 Feb 2012 16:13:47 +0000 Message-ID: <4F33F0BC.7060708@drh-consultancy.demon.co.uk> Date: Thu, 09 Feb 2012 16:13:48 +0000 From: Dr Stephen Henson User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: "tls@ietf.org list" X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [TLS] TLS versions when renegotiating... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 16:13:54 -0000 While performing interop testing with some servers an issue arose relating to renegotiation and TLS clients supporting TLS 1.1 or later and servers only supporting 1.0. One scenario is this: 1. Client connects using compatible client hello indicating maximum version of TLS 1.2. 2. Server only supports TLS 1.0 so sends back server hello containing version 1.0. RSA key exchange ciphersuite indicated. 3. Connection proceeds using TLS 1.0 with client using maximum supported version of 1.2 in RSA encrypted premaster secret. All fine so far. Now suppose the connection renegotiates (e.g. we requested a URL needing client authentication). It might go like this... 4. Server sends hello request requesting renegotiation. 5. Client sends client hello containing version 1.0 this time as we know that is all the server supports. 6. Connection proceeds using TLS v1.0. Question is: what version should go in the RSA encrypted premaster secret? Possible answers: a. Same value as in the corresponding client hello for that handshake as that is the maximum version we will permit i.e. 1.0. b. Be consistent with initial client hello and use 1.2 as that is the maximum version we support. The problem is whichever one you choose some widely deployed servers will choke on it. The servers which choke on (a) work fine if RSA key exchange is not used but they seem to prioritise RSA key exhchange ciphersuites even if others have precedence in the client hello. My current workaround is to avoid the client hello with version 1.0 when renegotiating and use a compatible client hello using version 1.2 and keeping that in the RSA encrypted premaster secret. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. From ynir@checkpoint.com Thu Feb 9 08:27:30 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1F7021F84A2 for ; Thu, 9 Feb 2012 08:27:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.462 X-Spam-Level: X-Spam-Status: No, score=-10.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36TRa7y4X3qj for ; Thu, 9 Feb 2012 08:27:29 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id C8DAD21F84BD for ; Thu, 9 Feb 2012 08:27:28 -0800 (PST) X-CheckPoint: {4F33F04C-0-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q19GRPlJ003016; Thu, 9 Feb 2012 18:27:25 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 9 Feb 2012 18:27:25 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 9 Feb 2012 18:27:24 +0200 From: Yoav Nir To: Dr Stephen Henson Date: Thu, 9 Feb 2012 18:27:28 +0200 Thread-Topic: [TLS] TLS versions when renegotiating... Thread-Index: AcznR7RmAt4KdAAcRfiemZOkDfYfrw== Message-ID: <505DA588-F67B-4914-8BE0-8E622817AC17@checkpoint.com> References: <4F33F0BC.7060708@drh-consultancy.demon.co.uk> In-Reply-To: <4F33F0BC.7060708@drh-consultancy.demon.co.uk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "tls@ietf.org list" Subject: Re: [TLS] TLS versions when renegotiating... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 16:27:30 -0000 Hi. I don't think that any sane reading of RFC 5246 (or 2246) can lead us to an= y conclusion other than a. Personally, I think the solution for the server is to accept in the ClientK= eyExchange all version numbers at least equal to its highest supported vers= ion. So in that example, we would accept 3.1, 3.2, 3.3, or even 3.99, but n= ot 3.0. Downgrade attacks are still thwarted (although the hash in the Finished mes= sage does that as well), but upgrade attacks are not. Are we worried about = upgrade attacks? I think not. Yoav On Feb 9, 2012, at 6:13 PM, Dr Stephen Henson wrote: > While performing interop testing with some servers an issue arose relatin= g to > renegotiation and TLS clients supporting TLS 1.1 or later and servers onl= y > supporting 1.0. >=20 > One scenario is this: >=20 > 1. Client connects using compatible client hello indicating maximum versi= on > of TLS 1.2. > 2. Server only supports TLS 1.0 so sends back server hello containing ver= sion > 1.0. RSA key exchange ciphersuite indicated. > 3. Connection proceeds using TLS 1.0 with client using maximum supported > version of 1.2 in RSA encrypted premaster secret. >=20 > All fine so far. Now suppose the connection renegotiates (e.g. we request= ed a > URL needing client authentication). It might go like this... >=20 > 4. Server sends hello request requesting renegotiation. > 5. Client sends client hello containing version 1.0 this time as we know = that > is all the server supports. > 6. Connection proceeds using TLS v1.0. >=20 > Question is: what version should go in the RSA encrypted premaster secret= ? >=20 > Possible answers: >=20 > a. Same value as in the corresponding client hello for that handshake as = that > is the maximum version we will permit i.e. 1.0. > b. Be consistent with initial client hello and use 1.2 as that is the max= imum > version we support. >=20 > The problem is whichever one you choose some widely deployed servers will= choke > on it. >=20 > The servers which choke on (a) work fine if RSA key exchange is not used = but > they seem to prioritise RSA key exhchange ciphersuites even if others hav= e > precedence in the client hello. >=20 > My current workaround is to avoid the client hello with version 1.0 when > renegotiating and use a compatible client hello using version 1.2 and kee= ping > that in the RSA encrypted premaster secret. >=20 > Steve. > --=20 > Dr Stephen N. Henson. > Core developer of the OpenSSL project: http://www.openssl.org/ > Freelance consultant see: http://www.drh-consultancy.co.uk/ > Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 > Scanned by Check Point Total Security Gateway. From philipp@cacert.org Fri Feb 10 15:54:55 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E28C21F84EA for ; Fri, 10 Feb 2012 15:54:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.443 X-Spam-Level: X-Spam-Status: No, score=-8.443 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_EQ_NL=1.545, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6UCCM-4ZYSz for ; Fri, 10 Feb 2012 15:54:54 -0800 (PST) Received: from email.cacert.org (gate.cacert.nl [213.154.225.228]) by ietfa.amsl.com (Postfix) with ESMTP id 4869021F84C4 for ; Fri, 10 Feb 2012 15:54:53 -0800 (PST) Received: from [192.168.0.12] (chello212017076182.4.15.vie.surfer.at [212.17.76.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: philipp) by email.cacert.org (Postfix) with ESMTPSA id 6CFB6574CB5 for ; Fri, 10 Feb 2012 23:54:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cacert.org; s=mail; t=1328918092; bh=5i5OI3nRqDIiU9sGIGpiBf7LhpLGNxqcJ2Peyb2548c=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type: Content-Transfer-Encoding; b=havRrD3Hw3+tznXEMLWfEOoSmEvPfkC6NJEHv fR2AkKMEBJ4TcH5OkrMrRgDcmuVTofmGOVl3T+8nJ9q/kslnmM42xfiSIsVro59V4DB lOkDEcd+ImK2KNsKWRr43bLS64XfuasLneTvrXKz5Mh+i4WZxzm7z8yxOPWQu1AGqr0 = Message-ID: <4F35AE4B.3000908@cacert.org> Date: Sat, 11 Feb 2012 00:54:51 +0100 From: Philipp Guehring User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111229 Thunderbird/9.0 MIME-Version: 1.0 To: "tls@ietf.org" X-Enigmail-Version: 1.3.4 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 8bit Subject: [TLS] Stapling with several OCSP responses X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 23:54:55 -0000 Hi, Is it possible to have a server send several OCSP responses (for intermediate certificates + end certificate) in one TLS-stapling ? If not, would it be possible to add that for the next TLS version? >From my point of view, OCSP stapling solves a number of problems (latency for dedicated OCSP requests by browsers, privacy issue of OCSP requests, scalability for OCSP(/CRL) servers), but if it does not work for Sub-CAs, then it we cannot solve those problems. Best regards, Philipp Gühring From yngve@opera.com Fri Feb 10 16:00:15 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 755CC21F85FC for ; Fri, 10 Feb 2012 16:00:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Qxq1oalTfVF for ; Fri, 10 Feb 2012 16:00:12 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 863EB21F85F7 for ; Fri, 10 Feb 2012 16:00:09 -0800 (PST) Received: from acorna.oslo.osa (pat-tdc.opera.com [213.236.208.22]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q1B006P0019113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sat, 11 Feb 2012 00:00:07 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: tls@ietf.org References: <4F35AE4B.3000908@cacert.org> Date: Sat, 11 Feb 2012 01:00:22 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Message-ID: In-Reply-To: <4F35AE4B.3000908@cacert.org> User-Agent: Opera Mail/10.63 (Win32) Subject: Re: [TLS] Stapling with several OCSP responses X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2012 00:00:15 -0000 On Sat, 11 Feb 2012 00:54:51 +0100, Philipp Guehring wrote: > Hi, > > Is it possible to have a server send several OCSP responses (for > intermediate certificates + end certificate) in one TLS-stapling ? > If not, would it be possible to add that for the next TLS version? >> From my point of view, OCSP stapling solves a number of problems > (latency for dedicated OCSP requests by browsers, privacy issue of OCSP > requests, scalability for OCSP(/CRL) servers), but if it does not work > for Sub-CAs, then it we cannot solve those problems. Not at present. -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 23 69 32 60 Fax: +47 23 69 24 01 ******************************************************************** From mrex@sap.com Fri Feb 10 21:33:43 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B59AE21E8028 for ; Fri, 10 Feb 2012 21:33:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.115 X-Spam-Level: X-Spam-Status: No, score=-10.115 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id czgARDSKAgoL for ; Fri, 10 Feb 2012 21:33:42 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 56B6C21F847D for ; Fri, 10 Feb 2012 21:33:41 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q1B5XdtH024451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 11 Feb 2012 06:33:39 +0100 (MET) From: Martin Rex Message-Id: <201202110533.q1B5XcMS018134@fs4113.wdf.sap.corp> To: lists@drh-consultancy.demon.co.uk (Dr Stephen Henson) Date: Sat, 11 Feb 2012 06:33:38 +0100 (MET) In-Reply-To: <4F33F0BC.7060708@drh-consultancy.demon.co.uk> from "Dr Stephen Henson" at Feb 9, 12 04:13:48 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLS versions when renegotiating... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2012 05:33:43 -0000 Just follow the spec: 7.4.1.2 Client Hello http://tools.ietf.org/html/rfc5246#page-41 client_version The version of the TLS protocol by which the client wishes to *> communicate during this session. This SHOULD be the latest *> (highest valued) version supported by the client. For this version of the specification, the version will be 3.3 (see Appendix E for details about backward compatibility). The spec has always been saying "This SHOULD be the latest (highest valued) version supported by the client". What is your rationale to *NOT* always send the latest (highest valued) version supported by the client in ClientHello.client_version, and in particular on renegotiation handshakes? In particular, when that highest value worked just finie on the inital handshake. When you do that, then you don't get into trouble talking to windows 7 / windows 2008, where an interoperability problem had been newly added to SChannel (windows XP/2003 does not have this bug). -Martin Dr Stephen Henson wrote: > > While performing interop testing with some servers an issue arose relating to > renegotiation and TLS clients supporting TLS 1.1 or later and servers only > supporting 1.0. > > One scenario is this: > > 1. Client connects using compatible client hello indicating maximum version > of TLS 1.2. > 2. Server only supports TLS 1.0 so sends back server hello containing version > 1.0. RSA key exchange ciphersuite indicated. > 3. Connection proceeds using TLS 1.0 with client using maximum supported > version of 1.2 in RSA encrypted premaster secret. > > All fine so far. Now suppose the connection renegotiates (e.g. we requested a > URL needing client authentication). It might go like this... > > 4. Server sends hello request requesting renegotiation. > 5. Client sends client hello containing version 1.0 this time as we know that > is all the server supports. > 6. Connection proceeds using TLS v1.0. > > Question is: what version should go in the RSA encrypted premaster secret? > > Possible answers: > > a. Same value as in the corresponding client hello for that handshake as that > is the maximum version we will permit i.e. 1.0. > b. Be consistent with initial client hello and use 1.2 as that is the maximum > version we support. > > The problem is whichever one you choose some widely deployed servers > will choke on it. > > The servers which choke on (a) work fine if RSA key exchange is not used but > they seem to prioritise RSA key exhchange ciphersuites even if others have > precedence in the client hello. > > My current workaround is to avoid the client hello with version 1.0 when > renegotiating and use a compatible client hello using version 1.2 and keeping > that in the RSA encrypted premaster secret. > > Steve. > -- > Dr Stephen N. Henson. > Core developer of the OpenSSL project: http://www.openssl.org/ > Freelance consultant see: http://www.drh-consultancy.co.uk/ > Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From ynir@checkpoint.com Sat Feb 11 07:19:18 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C85CE21F84E4 for ; Sat, 11 Feb 2012 07:19:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.85 X-Spam-Level: X-Spam-Status: No, score=-9.85 tagged_above=-999 required=5 tests=[AWL=-0.491, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wtYIIsRo3Nin for ; Sat, 11 Feb 2012 07:19:17 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4542621F84E2 for ; Sat, 11 Feb 2012 07:19:16 -0800 (PST) X-CheckPoint: {4F36833C-0-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q1BFJCW6028659; Sat, 11 Feb 2012 17:19:12 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sat, 11 Feb 2012 17:19:12 +0200 From: Yoav Nir To: "mrex@sap.com" Date: Sat, 11 Feb 2012 17:19:18 +0200 Thread-Topic: [TLS] TLS versions when renegotiating... Thread-Index: Aczo0IHkLxr7zm10RsWoYBnslH5C5w== Message-ID: <087CCB98-B66B-4A48-827D-A72316FA38A6@checkpoint.com> References: <201202110533.q1B5XcMS018134@fs4113.wdf.sap.corp> In-Reply-To: <201202110533.q1B5XcMS018134@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS versions when renegotiating... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Feb 2012 15:19:18 -0000 Hi Martin As a client that's good advice. As a server that does not support TLS 1.2 y= et, you get Windows 7 and iOS 5 clients reverting to 3.1 or 3.0 on the Clie= ntHello.client_version, but keeping 3.3 in the PMK. You have to deal with t= hat. Sure, adding TLS 1.2 support is the right way, but you might try for a= smaller fix in the short term. Yoav On Feb 11, 2012, at 7:33 AM, Martin Rex wrote: >=20 > Just follow the spec: >=20 > 7.4.1.2 Client Hello >=20 > http://tools.ietf.org/html/rfc5246#page-41 >=20 > client_version > The version of the TLS protocol by which the client wishes to > *> communicate during this session. This SHOULD be the latest > *> (highest valued) version supported by the client. For this > version of the specification, the version will be 3.3 (see > Appendix E for details about backward compatibility). >=20 >=20 > The spec has always been saying "This SHOULD be the latest (highest value= d) > version supported by the client". What is your rationale to *NOT* always > send the latest (highest valued) version supported by the client > in ClientHello.client_version, and in particular on renegotiation handsha= kes? > In particular, when that highest value worked just finie on the inital > handshake. >=20 > When you do that, then you don't get into trouble talking to > windows 7 / windows 2008, where an interoperability problem > had been newly added to SChannel (windows XP/2003 does not have > this bug). >=20 >=20 > -Martin >=20 >=20 > Dr Stephen Henson wrote: >>=20 >> While performing interop testing with some servers an issue arose relati= ng to >> renegotiation and TLS clients supporting TLS 1.1 or later and servers on= ly >> supporting 1.0. >>=20 >> One scenario is this: >>=20 >> 1. Client connects using compatible client hello indicating maximum vers= ion >> of TLS 1.2. >> 2. Server only supports TLS 1.0 so sends back server hello containing ve= rsion >> 1.0. RSA key exchange ciphersuite indicated. >> 3. Connection proceeds using TLS 1.0 with client using maximum supported >> version of 1.2 in RSA encrypted premaster secret. >>=20 >> All fine so far. Now suppose the connection renegotiates (e.g. we reques= ted a >> URL needing client authentication). It might go like this... >>=20 >> 4. Server sends hello request requesting renegotiation. >> 5. Client sends client hello containing version 1.0 this time as we know= that >> is all the server supports. >> 6. Connection proceeds using TLS v1.0. >>=20 >> Question is: what version should go in the RSA encrypted premaster secre= t? >>=20 >> Possible answers: >>=20 >> a. Same value as in the corresponding client hello for that handshake as= that >> is the maximum version we will permit i.e. 1.0. >> b. Be consistent with initial client hello and use 1.2 as that is the ma= ximum >> version we support. >>=20 >> The problem is whichever one you choose some widely deployed servers >> will choke on it. >>=20 >> The servers which choke on (a) work fine if RSA key exchange is not used= but >> they seem to prioritise RSA key exhchange ciphersuites even if others ha= ve >> precedence in the client hello. >>=20 >> My current workaround is to avoid the client hello with version 1.0 when >> renegotiating and use a compatible client hello using version 1.2 and ke= eping >> that in the RSA encrypted premaster secret. >>=20 >> Steve. >> --=20 >> Dr Stephen N. Henson. >> Core developer of the OpenSSL project: http://www.openssl.org/ >> Freelance consultant see: http://www.drh-consultancy.co.uk/ >> Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >>=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 > Scanned by Check Point Total Security Gateway. From mrex@sap.com Sat Feb 11 16:05:10 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6BE21F8596 for ; Sat, 11 Feb 2012 16:05:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.499 X-Spam-Level: X-Spam-Status: No, score=-9.499 tagged_above=-999 required=5 tests=[AWL=-0.490, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8, SARE_LWSHORTT=1.24] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sukkFyTqOnvV for ; Sat, 11 Feb 2012 16:05:09 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5C11021F8593 for ; Sat, 11 Feb 2012 16:05:09 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q1C050qh009318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 12 Feb 2012 01:05:00 +0100 (MET) From: Martin Rex Message-Id: <201202120004.q1C04xeh009591@fs4113.wdf.sap.corp> To: ynir@checkpoint.com (Yoav Nir) Date: Sun, 12 Feb 2012 01:04:58 +0100 (MET) In-Reply-To: <087CCB98-B66B-4A48-827D-A72316FA38A6@checkpoint.com> from "Yoav Nir" at Feb 11, 12 05:19:18 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLS versions when renegotiating... X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 00:05:10 -0000 Yoav Nir wrote: > > As a client that's good advice. As a server that does not support > TLS 1.2 yet, you get Windows 7 and iOS 5 clients reverting to 3.1 > or 3.0 on the ClientHello.client_version, but keeping 3.3 in the PMK. > You have to deal with that. Sure, adding TLS 1.2 support is the right > way, but you might try for a smaller fix in the short term. Agreed. I'm sorry, I forgot about servers that want to offer renegotiation (I never supported that in our server...). On renegotiation handshakes, the server ought to skip the client_version check on the RSA PMS completely. Why? because the (lack of) design of this part of the SSL/TLS protocol does not allow changing of the protocol version during renegotiation handshakes. -Martin From hannes.tschofenig@gmx.net Mon Feb 13 02:39:11 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93A1921F86E8 for ; Mon, 13 Feb 2012 02:39:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.37 X-Spam-Level: X-Spam-Status: No, score=-102.37 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJ-UHwgJvi8e for ; Mon, 13 Feb 2012 02:39:11 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 6158921F86E0 for ; Mon, 13 Feb 2012 02:39:10 -0800 (PST) Received: (qmail invoked by alias); 13 Feb 2012 10:39:08 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.101]) [88.115.216.191] by mail.gmx.net (mp038) with SMTP; 13 Feb 2012 11:39:08 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/0JagMmzX04SNp2SZihSQnKqhycfrFJN8M4NnCB1 Q3GuwSm2mVAmf3 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Mon, 13 Feb 2012 12:39:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6BEABA77-F229-4A7B-B33A-14CC98D3B494@gmx.net> References: To: zhou.sujing@zte.com.cn X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: tls@ietf.org Subject: [TLS] =?utf-8?q?Comments_regarding_tls-oob-pubkey_was_Re=3A__?= =?utf-8?q?=E7=AD=94=E5=A4=8D=3A__Consensus_for_adoption_of_draft-wouters-?= =?utf-8?q?tls-oob-pubkey-02?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 10:39:11 -0000 Hi Zhou,=20 you had some comments embedded in your response to Joe's call for = adoption and I only spotted them now.=20 On Dec 1, 2011, at 9:28 AM, zhou.sujing@zte.com.cn wrote: > And currently there are two unclear descriptions to me:=20 > 1. Will client also send rawpublic key to server?=20 > although the aim of OOB is to reduce the size of transported server = certificate, client will have to be affected according to this solution = unless otherwise defined.=20 > =20 The idea was to allow the certificate payload to carry a raw public key. = As such, the proposed extension can be used by the server and the = client. Note that there will not only be a difference in the message = size but also in the required code.=20 > 2. What will client do on receiving certificaterequest?=20 > Comparing received rawpublic key and stored public key bit by bit? = But nomatterhow, definitly not " identical to the TLS specification" as = described in this document. When the client receives a certificate request, it supports the raw = public key extension, and the ClientHello/ServerHello exchange had = indicated so then the returned certificate payload will only carry the = raw public key.=20 We will make both points more clear in an upcoming revision of the = draft. Ciao Hannes= From hannes.tschofenig@gmx.net Tue Feb 14 00:46:00 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 878EA21F8751 for ; Tue, 14 Feb 2012 00:46:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.853 X-Spam-Level: X-Spam-Status: No, score=-101.853 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3o0ONQRsh2pp for ; Tue, 14 Feb 2012 00:45:58 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 1051F21F874A for ; Tue, 14 Feb 2012 00:45:57 -0800 (PST) Received: (qmail invoked by alias); 14 Feb 2012 08:45:56 -0000 Received: from unknown (EHLO [10.255.132.95]) [192.100.123.77] by mail.gmx.net (mp030) with SMTP; 14 Feb 2012 09:45:56 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19GJuo98zJGni4ZGohQp+WRw00MHB1YUfIslSFBXs jcjBkYGPxJK9To Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <201201210123.q0L1NOwX000859@fs4113.wdf.sap.corp> Date: Tue, 14 Feb 2012 10:45:49 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <102AF7DB-6FC4-4AD1-8ED1-5ADD21E1F3AA@gmx.net> References: <201201210123.q0L1NOwX000859@fs4113.wdf.sap.corp> To: mrex@sap.com X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: tls@ietf.org Subject: Re: [TLS] New Version Notification for draft-ietf-tls-oob-pubkey-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 08:46:00 -0000 Hi Martin,=20 I don't think I have responded to your review already.=20 On Jan 21, 2012, at 3:23 AM, Martin Rex wrote: > Paul Wouters wrote: >>=20 >> A new version of I-D, draft-ietf-tls-oob-pubkey-01.txt has been = successfully=20 >> submitted by Paul Wouters and posted to the IETF repository. >>=20 >> Filename: draft-ietf-tls-oob-pubkey >> Revision: 01 >> Title: TLS Out-of-Band Public Key Validation >> Creation date: 2012-01-20 >> WG ID: tls >> Number of pages: 10 >>=20 >>=20 >> The new certificate type specified can also be used to reduce the >> latency of a TLS client that is already in possession of a = validated >> public key of the TLS server before it starts a (non-resumed) TLS >> handshake. >=20 >=20 > (1) >=20 > I'm confused about this paragraph with respect to later parts of the > document. Maybe I've read the document too quickly, but I didn't > find an explanation how exactly this new certificate type could be > used to "reduce the latency of a TLS client that is already in > posession of a validated public key". >=20 Think about a radio technology like IEEE 802.15.4 http://en.wikipedia.org/wiki/IEEE_802.15.4 It is a low bandwidth radio with a small MTU.=20 The small MTU leads to fragmentation and potentially to retransmissions. = The low bandwidth increases latency for longer data transfers.=20 Maybe this needs to be more clear in the draft.=20 >=20 > Since the new certificate type "RawPublicKey" is in reality a > PKIX SubjectPublicKeyInfo, every server in posession of an X.509 cert > could simply agree to this extension when proposed by the client, > extract the SubjectPublicKeyInfo from this X.509 server certificate > and send it as RawPublicKey in the ServerCertificate handshake = message. > This would reduce the amount of data in the Server's Certificate and > optional CertificateRequest Handshake message. (and when the server > requested it, it would reduce the size of the Client's Certificate > handshake message as well, provided the client had a credential). >=20 > Is is that reduction in size of the handshake message that was meant? Yes. The SubjectPublicKeyInfo part of the certificate is much smaller = than the entire certificate.=20 Additionally, there is also the lower implementation overhead for a TLS = stack that only supports raw public keys (which is useful for smart = objects).=20 >=20 >=20 > (2) >=20 > Personally, I believe it would be quite reasonable, for servers > implementing this in addition to regular X.509 support, to also > use X.509 certs as containers for the raw public keys so that no > changes whatsoever are required for the adminstrative parts > (creation and management of server TLS credentials). The document does not mandate a specific way to store the raw public = keys.=20 You could, for example, create self-signed certificate using one of the = many available tools but then only transmit the SubjectPublicKeyInfo = part of the cert.=20 >=20 > Is the intention to actively suggest to (server) implementations of > this document to generally extract and use of the SubjectPublicKeyInfo > as RawPublicKey for whatever X.509 certificate the server might have, > then this requirement, that was copied from rfc6091, would become > superfluous: >=20 > This > extension MUST be omitted if the client only supports X.509 > certificates. If a server only has X.509 certificate support then it makes not sense = to advertise the support for raw public keys.=20 >=20 > btw. I believe that MUST (from rfc6091) is in conflict with rfc2119 = section 6. >=20 How come is that?=20 > Likewise, is the intention to actively suggest to (client) = implementations > of this document to extract SubjectPublicKeyInfo from X.509 Server > Certificates that they received on a full handshake with that server > and where available to validate (PKIX/DANE/whathaveyou) and attempt to > use it in a sucessor TLS handshake with that server as a RawPublicKey > with the TLS extension defined in this document? >=20 >=20 No, that's not the intention.=20 The server only sends the SubjectPublicKeyInfo and not the certificate. >=20 > (3) >=20 > I'm wondering about any kind of "server has more than one credential > scenario", which comes in two different flavours (and mixtures = thereof): >=20 > (a) virtual hosting, several distinct server certificates and > their selection guided by TLS extension SNI >=20 > (b) ciphersuites that require distinct keypairs (RSA,DSA,ECDSA) >=20 > I believe with respect to (a) the interaction of the extension defined = in > this document with TLS extension SNI should be specified. What would you like to specify?=20 > This would > be essential if the intention of (2) applies that clients&servers are > expected to extract SubjectPublicKey Infos from X.509 certificates = that > they would use as X.509 certs in regular TLS handshakes without this > extension. >=20 >=20 > With respect to (b), I believe that it should be spelled out that > clients(!) may have to restrict the list of TLS cipher suites > that they propose in ClientHello, when using the TLS extension > defined in this document, to those algorithms for which they > actually have server RawPublicKeys available. It is a pure policy issues how many ciphersuites to advertise.=20 I am not sure I would add a lot of advice by saying that.=20 Ciao Hannes >=20 >=20 >=20 > -Martin > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From iesg-secretary@ietf.org Tue Feb 14 06:09:47 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55A2521F87CC; Tue, 14 Feb 2012 06:09:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipq6t0qedIzI; Tue, 14 Feb 2012 06:09:46 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDDBD21F8564; Tue, 14 Feb 2012 06:09:46 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120214140946.27284.89633.idtracker@ietfa.amsl.com> Date: Tue, 14 Feb 2012 06:09:46 -0800 Cc: tls@ietf.org Subject: [TLS] Last Call: (AES-CCM Cipher Suites for TLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 14:09:47 -0000 The IESG has received a request from an individual submitter to consider the following document: - 'AES-CCM Cipher Suites for TLS' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-03-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This memo describes the use of the Advanced Encryption Standard (AES) in the Counter and CBC-MAC Mode (CCM) of operation within Transport Layer Security (TLS) and Datagram TLS (DTLS) to provide confidentiality and data origin authentication. The AES-CCM algorithm is amenable to compact implementations, making it suitable for constrained environments. The file can be obtained via http://datatracker.ietf.org/doc/draft-mcgrew-tls-aes-ccm/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-mcgrew-tls-aes-ccm/ No IPR declarations have been submitted directly on this I-D. From jsalowey@cisco.com Tue Feb 14 09:32:17 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9B8D21E8097 for ; Tue, 14 Feb 2012 09:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.599 X-Spam-Level: X-Spam-Status: No, score=-108.599 tagged_above=-999 required=5 tests=[AWL=2.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TUUap6NDmdsU for ; Tue, 14 Feb 2012 09:32:17 -0800 (PST) Received: from mtv-iport-3.cisco.com (mtv-iport-3.cisco.com [173.36.130.14]) by ietfa.amsl.com (Postfix) with ESMTP id 482A721E8095 for ; Tue, 14 Feb 2012 09:32:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=1795; q=dns/txt; s=iport; t=1329240737; x=1330450337; h=from:content-transfer-encoding:subject:date:references: to:message-id:mime-version; bh=dlitMQd9CieZ+2W+xIXPykc7mA7kCUWtG5vUc8+BTYM=; b=KSpUJXlJJDL6+XqOxH01hcqVC/72STU1AoNiRdNby2xnfLNTgH0vi6Ut 93tNdYmtAF48nXr61dbhAe9przMzYr/mfKx0AKepTY3MOXWrhvbZyUyOJ Bun/QfLU5VXSlvbfj8isbV7OfyaRx/qjjPZFMZU3GZYYfdMISY5x2pPhe s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUHAOqZOk+rRDoG/2dsb2JhbABDgxGtFoEHgXIBAQEDAQEBAQ8BJzQQCxwDAQIkCycfBwIIGSKHWgmeCQGWf4t1KwYIAw4EBgMRAQsGAwKDdS0JCAcDCBKCOmMEiEqMaIVajSs X-IronPort-AV: E=Sophos;i="4.73,417,1325462400"; d="scan'208";a="30385887" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-3.cisco.com with ESMTP; 14 Feb 2012 17:32:16 +0000 Received: from [10.33.251.13] ([10.33.251.13]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id q1EHWGUY012482 for ; Tue, 14 Feb 2012 17:32:16 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 14 Feb 2012 09:33:07 -0800 References: <20120214140946.27284.89633.idtracker@ietfa.amsl.com> To: tls@ietf.org Message-Id: Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [TLS] Fwd: Last Call: (AES-CCM Cipher Suites for TLS) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 17:32:17 -0000 FYI Begin forwarded message: > From: The IESG > Date: February 14, 2012 6:09:46 AM PST > To: IETF-Announce > Cc: tls@ietf.org > Subject: Last Call: (AES-CCM Cipher = Suites for TLS) to Proposed Standard > Reply-To: ietf@ietf.org >=20 >=20 > The IESG has received a request from an individual submitter to = consider > the following document: > - 'AES-CCM Cipher Suites for TLS' > as a Proposed Standard >=20 > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2012-03-13. Exceptionally, comments may = be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. >=20 > Abstract >=20 >=20 > This memo describes the use of the Advanced Encryption Standard = (AES) > in the Counter and CBC-MAC Mode (CCM) of operation within Transport > Layer Security (TLS) and Datagram TLS (DTLS) to provide > confidentiality and data origin authentication. The AES-CCM > algorithm is amenable to compact implementations, making it suitable > for constrained environments. >=20 >=20 >=20 >=20 > The file can be obtained via > http://datatracker.ietf.org/doc/draft-mcgrew-tls-aes-ccm/ >=20 > IESG discussion can be tracked via > http://datatracker.ietf.org/doc/draft-mcgrew-tls-aes-ccm/ >=20 >=20 > No IPR declarations have been submitted directly on this I-D. >=20 >=20 > _______________________________________________ > IETF-Announce mailing list > IETF-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/ietf-announce From mrex@sap.com Tue Feb 14 13:22:35 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC84421E8065 for ; Tue, 14 Feb 2012 13:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.123 X-Spam-Level: X-Spam-Status: No, score=-10.123 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMZPTIu0n-eG for ; Tue, 14 Feb 2012 13:22:34 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id D5D3A21F8547 for ; Tue, 14 Feb 2012 13:22:30 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q1ELMReM027765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 14 Feb 2012 22:22:27 +0100 (MET) From: Martin Rex Message-Id: <201202142122.q1ELMR2Y015267@fs4113.wdf.sap.corp> To: jsalowey@cisco.com (Joe Salowey) Date: Tue, 14 Feb 2012 22:22:27 +0100 (MET) In-Reply-To: from "Joe Salowey" at Feb 14, 12 09:33:07 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Fwd: Last Call: (AES-CCM X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 21:22:35 -0000 Joe Salowey wrote: > > FYI > > > The IESG has received a request from an individual submitter to consider > > the following document: > > - 'AES-CCM Cipher Suites for TLS' > > as a Proposed Standard I believe this document should be published as Informational, not as Proposed Standard, because it is only interesting to a specific community and not a generally useful set of cipher suites. Other RFCs describing TLS cipher suites that were published as informational: 5289 TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois Counter Mode (GCM). E. Rescorla. August 2008. (Format: TXT=12195 bytes) (Status: INFORMATIONAL) 5489 ECDHE_PSK Cipher Suites for Transport Layer Security (TLS). M. Badra, I. Hajjeh. March 2009. (Format: TXT=14194 bytes) (Status: INFORMATIONAL) 6209 Addition of the ARIA Cipher Suites to Transport Layer Security (TLS). W. Kim, J. Lee, J. Park, D. Kwon. April 2011. (Format: TXT=19501 bytes) (Status: INFORMATIONAL) 6367 Addition of the Camellia Cipher Suites to Transport Layer Security (TLS). S. Kanno, M. Kanda. September 2011. (Format: TXT=17613 bytes) (Status: INFORMATIONAL) (btw. I believe that rfc5932 would have been perfectly sufficient as informational, in spite of replacing rfc4132. And I'm confused why both 5932 and 4132 contain the list of ciphersuites TWICE (and nothing much else). -Martin From n.mavrogiannopoulos@gmail.com Wed Feb 15 04:24:06 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F6021F87B6 for ; Wed, 15 Feb 2012 04:24:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoE+7ODU6jfr for ; Wed, 15 Feb 2012 04:24:02 -0800 (PST) Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id DBEBC21F86A8 for ; Wed, 15 Feb 2012 04:24:01 -0800 (PST) Received: by bkuw12 with SMTP id w12so958181bku.31 for ; Wed, 15 Feb 2012 04:24:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=QJQ4qxN4y0j0DzhjoBTmBwKUGSBU3bL7dOjWxDShqOQ=; b=EaW0GB4B98th/2B+pAk99OiJYp6A42L8fX7zomR9WX9Ur8yr4rvu/+MKteXF5Z9xDN NVlO7ySFRK19rZaDrbhH8L88a4Wc1GE/7mOlS41ik1eenJ/Rt95yqrEtCnWlxvxcq+yM MXbip4vNPhdKZzEG0rIyjvCdIWFO/G2wm9U2Q= Received: by 10.204.131.90 with SMTP id w26mr4594947bks.55.1329308638958; Wed, 15 Feb 2012 04:23:58 -0800 (PST) Received: from [10.100.2.14] (d51A49E78.access.telenet.be. [81.164.158.120]) by mx.google.com with ESMTPS id d5sm6334134bkb.3.2012.02.15.04.23.57 (version=SSLv3 cipher=OTHER); Wed, 15 Feb 2012 04:23:58 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <4F3BA524.20604@gnutls.org> Date: Wed, 15 Feb 2012 13:29:24 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Icedove/3.1.16 MIME-Version: 1.0 To: tls@ietf.org References: <201202142122.q1ELMR2Y015267@fs4113.wdf.sap.corp> In-Reply-To: <201202142122.q1ELMR2Y015267@fs4113.wdf.sap.corp> X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [TLS] TLS related rfcs (was Fwd: Last Call: ) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 12:24:06 -0000 On 02/14/2012 10:22 PM, Martin Rex wrote: > 6209 Addition of the ARIA Cipher Suites to Transport Layer Security > (TLS). W. Kim, J. Lee, J. Park, D. Kwon. April 2011. (Format: > TXT=19501 bytes) (Status: INFORMATIONAL) > > 6367 Addition of the Camellia Cipher Suites to Transport Layer > Security (TLS). S. Kanno, M. Kanda. September 2011. (Format: > TXT=17613 bytes) (Status: INFORMATIONAL) It seems none of the above documents are listed in https://datatracker.ietf.org/wg/tls/. Is there any way to get a list of the TLS-related RFCs? As far as I understand TLS-related RFCs or drafts are not even announced in the tls mailing list. Is there a reason for that? I believe members of this list could provide comments on few of these documents. regards, Nikos From turners@ieca.com Wed Feb 15 07:52:39 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895FD21F84FC for ; Wed, 15 Feb 2012 07:52:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.086 X-Spam-Level: X-Spam-Status: No, score=-102.086 tagged_above=-999 required=5 tests=[AWL=0.179, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XZraSp5IPAWo for ; Wed, 15 Feb 2012 07:52:36 -0800 (PST) Received: from gateway08.websitewelcome.com (gateway08.websitewelcome.com [69.41.242.28]) by ietfa.amsl.com (Postfix) with ESMTP id D21DF21F84F1 for ; Wed, 15 Feb 2012 07:52:35 -0800 (PST) Received: by gateway08.websitewelcome.com (Postfix, from userid 5007) id 30BB9C34E934E; Wed, 15 Feb 2012 09:51:39 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway08.websitewelcome.com (Postfix) with ESMTP id 2673AC34E932B for ; Wed, 15 Feb 2012 09:51:39 -0600 (CST) Received: from [96.231.121.232] (port=44042 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1Rxh8s-00066y-N5; Wed, 15 Feb 2012 09:51:39 -0600 Message-ID: <4F3BD48A.90300@ieca.com> Date: Wed, 15 Feb 2012 10:51:38 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Nikos Mavrogiannopoulos References: <201202142122.q1ELMR2Y015267@fs4113.wdf.sap.corp> <4F3BA524.20604@gnutls.org> In-Reply-To: <4F3BA524.20604@gnutls.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-96-231-121-232.washdc.east.verizon.net (thunderfish.local) [96.231.121.232]:44042 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: tls@ietf.org Subject: Re: [TLS] TLS related rfcs (was Fwd: Last Call: ) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 15:52:39 -0000 On 2/15/12 7:29 AM, Nikos Mavrogiannopoulos wrote: > On 02/14/2012 10:22 PM, Martin Rex wrote: > > >> 6209 Addition of the ARIA Cipher Suites to Transport Layer Security >> (TLS). W. Kim, J. Lee, J. Park, D. Kwon. April 2011. (Format: >> TXT=19501 bytes) (Status: INFORMATIONAL) >> >> 6367 Addition of the Camellia Cipher Suites to Transport Layer >> Security (TLS). S. Kanno, M. Kanda. September 2011. (Format: >> TXT=17613 bytes) (Status: INFORMATIONAL) > > > It seems none of the above documents are listed in > https://datatracker.ietf.org/wg/tls/. Is there any way to get a list > of the TLS-related RFCs? > > As far as I understand TLS-related RFCs or drafts are not even > announced in the tls mailing list. Is there a reason for that? I believe > members of this list could provide comments on few of these documents. Neither of these drafts were WG documents so they wouldn't show up the list of RFCs produced by the WG, which is what's on https://datatracker.ietf.org/wg/tls/. However because that Camella RFC does obsolete a WG product it's on that page as an obsoletes - same as for the openpgp RFC 6091. The related documents shows drafts that include the string "tls" in them so before these were RFCs they showed up in that list. Not sure how folks would feel about adding a list of related RFCs there. Not sure what the rule would be for including them there - there's lots of RFCs produced that include "TLS" or "DTLS" in the title that are the products of other WGs. If I last call an AD sponsored draft, then I try to remember to cc the list, but sometimes I forget and have to forward it to the list. Note that for these particular drafts the WG was copied on request for reviews and LCs: ARIA: http://www.ietf.org/mail-archive/web/tls/current/msg07065.html http://www.ietf.org/mail-archive/web/tls/current/msg07261.html http://www.ietf.org/mail-archive/web/tls/current/msg07325.html Camellia: http://www.ietf.org/mail-archive/web/tls/current/msg07316.html http://www.ietf.org/mail-archive/web/tls/current/msg07442.html http://www.ietf.org/mail-archive/web/tls/current/msg07674.html spt From n.mavrogiannopoulos@gmail.com Wed Feb 15 10:22:52 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C132121F8552 for ; Wed, 15 Feb 2012 10:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rbLkbSCEUWjf for ; Wed, 15 Feb 2012 10:22:46 -0800 (PST) Received: from mail-ee0-f44.google.com (mail-ee0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD0D21F8534 for ; Wed, 15 Feb 2012 10:22:35 -0800 (PST) Received: by eekc41 with SMTP id c41so487477eek.31 for ; Wed, 15 Feb 2012 10:22:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=UtZdX2V+vxaXAuUjqZ8R/vpqzFFwU58RSn/vHuJGJuM=; b=J3aUJHWRgERZkrA/IPZhyMKDqKa+hhiQo5GXejNa+/mril826RhfZICxa5+Wr8NIz2 nwAhtTlYhL6lvOCyy7ICk87Ej//rAXzkl/ecMamTB55Klas2E1HNFUGz1nzvi2iXN6Ya TMAcSaPIs68r+oB8yoyL1vpQJvNa6xJsL7JwY= Received: by 10.213.34.210 with SMTP id m18mr223322ebd.124.1329330154584; Wed, 15 Feb 2012 10:22:34 -0800 (PST) Received: from [10.100.2.14] (d51A49E78.access.telenet.be. [81.164.158.120]) by mx.google.com with ESMTPS id v51sm13702141eef.2.2012.02.15.10.22.33 (version=SSLv3 cipher=OTHER); Wed, 15 Feb 2012 10:22:33 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <4F3BF930.4090402@gnutls.org> Date: Wed, 15 Feb 2012 19:28:00 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111114 Icedove/3.1.16 MIME-Version: 1.0 To: Sean Turner References: <201202142122.q1ELMR2Y015267@fs4113.wdf.sap.corp> <4F3BA524.20604@gnutls.org> <4F3BD48A.90300@ieca.com> In-Reply-To: <4F3BD48A.90300@ieca.com> X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] TLS related rfcs (was Fwd: Last Call: ) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 18:22:52 -0000 On 02/15/2012 04:51 PM, Sean Turner wrote: >> As far as I understand TLS-related RFCs or drafts are not even >> announced in the tls mailing list. Is there a reason for that? I >> believe members of this list could provide comments on few of these >> documents. > Neither of these drafts were WG documents so they wouldn't show up > the list of RFCs produced by the WG, which is what's on > https://datatracker.ietf.org/wg/tls/. Ok I understand they were developed outside the WG, but they propose changes/updates to the protocol the WG is responsible for. If the WG page isn't the page to list those updates, then it seems there is no other way to find them in a single place. > However because that Camella RFC > does obsolete a WG product it's on that page as an obsoletes - same > as for the openpgp RFC 6091. The related documents shows drafts > that include the string "tls" in them so before these were RFCs they > showed up in that list. Not sure how folks would feel about adding a > list of related RFCs there. I think they should be listed somewhere, so that an implementor could look for interesting features proposed for TLS. It doesn't need to be mixed with the work group documents and it should be clear that they are third-party proposals. > Not sure what the rule would be for including them > there - there's lots of RFCs produced that include "TLS" or "DTLS" > in the title that are the products of other WGs. A simple liberal rule could be whether they could be useful to someone implementing TLS. regards, Nikos From turners@ieca.com Wed Feb 15 11:31:06 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B652021F863F for ; Wed, 15 Feb 2012 11:31:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.135 X-Spam-Level: X-Spam-Status: No, score=-102.135 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G00Ub636tTOd for ; Wed, 15 Feb 2012 11:31:02 -0800 (PST) Received: from gateway07.websitewelcome.com (gateway07.websitewelcome.com [67.18.53.18]) by ietfa.amsl.com (Postfix) with ESMTP id D8C9721F862B for ; Wed, 15 Feb 2012 11:31:02 -0800 (PST) Received: by gateway07.websitewelcome.com (Postfix, from userid 5007) id E6291D5BE6F54; Wed, 15 Feb 2012 13:31:01 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway07.websitewelcome.com (Postfix) with ESMTP id C2FA4D5BE6E97 for ; Wed, 15 Feb 2012 13:31:01 -0600 (CST) Received: from [96.231.121.232] (port=38432 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RxkZB-0001Iv-9j; Wed, 15 Feb 2012 13:31:01 -0600 Message-ID: <4F3C07F5.8000607@ieca.com> Date: Wed, 15 Feb 2012 14:31:01 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Nikos Mavrogiannopoulos References: <201202142122.q1ELMR2Y015267@fs4113.wdf.sap.corp> <4F3BA524.20604@gnutls.org> <4F3BD48A.90300@ieca.com> <4F3BF930.4090402@gnutls.org> In-Reply-To: <4F3BF930.4090402@gnutls.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-96-231-121-232.washdc.east.verizon.net (thunderfish.local) [96.231.121.232]:38432 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: tls@ietf.org Subject: Re: [TLS] TLS related rfcs (was Fwd: Last Call: ) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 19:31:06 -0000 On 2/15/12 1:28 PM, Nikos Mavrogiannopoulos wrote: > On 02/15/2012 04:51 PM, Sean Turner wrote: > >>> As far as I understand TLS-related RFCs or drafts are not even >>> announced in the tls mailing list. Is there a reason for that? I >>> believe members of this list could provide comments on few of these >>> documents. >> Neither of these drafts were WG documents so they wouldn't show up >> the list of RFCs produced by the WG, which is what's on >> https://datatracker.ietf.org/wg/tls/. > > > Ok I understand they were developed outside the WG, but they propose > changes/updates to the protocol the WG is responsible for. If the WG > page isn't the page to list those updates, then it seems there is > no other way to find them in a single place. > >> However because that Camella RFC >> does obsolete a WG product it's on that page as an obsoletes - same >> as for the openpgp RFC 6091. The related documents shows drafts >> that include the string "tls" in them so before these were RFCs they >> showed up in that list. Not sure how folks would feel about adding a >> list of related RFCs there. > > > I think they should be listed somewhere, so that an implementor > could look for interesting features proposed for TLS. It doesn't need to > be mixed with the work group documents and it should be clear that > they are third-party proposals. > >> Not sure what the rule would be for including them >> there - there's lots of RFCs produced that include "TLS" or "DTLS" >> in the title that are the products of other WGs. > > > A simple liberal rule could be whether they could be useful to someone > implementing TLS. I'll see what I figure out. spt From ehimawan@gmail.com Tue Feb 21 08:37:47 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD6821F880D for ; Tue, 21 Feb 2012 08:37:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lIT7IwdGQLDM for ; Tue, 21 Feb 2012 08:37:42 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id BE0C321F8804 for ; Tue, 21 Feb 2012 08:37:41 -0800 (PST) Received: by wgbdt10 with SMTP id dt10so4093212wgb.13 for ; Tue, 21 Feb 2012 08:37:41 -0800 (PST) Received-SPF: pass (google.com: domain of ehimawan@gmail.com designates 10.180.99.100 as permitted sender) client-ip=10.180.99.100; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ehimawan@gmail.com designates 10.180.99.100 as permitted sender) smtp.mail=ehimawan@gmail.com; dkim=pass header.i=ehimawan@gmail.com Received: from mr.google.com ([10.180.99.100]) by 10.180.99.100 with SMTP id ep4mr27263641wib.7.1329842261071 (num_hops = 1); Tue, 21 Feb 2012 08:37:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=9tfjusHLzH0fvIiPVkhhEKAHwUcPhPsh2/yx5OODKL4=; b=ZHjixTdW+CVzCTkleVcqtG3B57KnbFIiAhZCAqU64UhqbOsSllBwJiq5mIFa1+WtEx kpcUpMZShQ7+dVoN2yz8mGHHEwJ58ziP3oMvHWpvsJond43gu1/EFzk+F6DiAuYylSke QAMRT0zwCDN9J+beKhmq0TZqlS1WB/+ZVj264= MIME-Version: 1.0 Received: by 10.180.99.100 with SMTP id ep4mr22727480wib.7.1329842260639; Tue, 21 Feb 2012 08:37:40 -0800 (PST) Received: by 10.216.24.140 with HTTP; Tue, 21 Feb 2012 08:37:40 -0800 (PST) Date: Tue, 21 Feb 2012 10:37:40 -0600 Message-ID: From: Erwin Himawan To: tls@ietf.org Content-Type: multipart/alternative; boundary=f46d04428e5c8d7e8304b97c077e Subject: [TLS] CPU Cost for TLS vs. DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 16:37:47 -0000 --f46d04428e5c8d7e8304b97c077e Content-Type: text/plain; charset=ISO-8859-1 Hi Folks, I have been googling for more information on the CPU cost comparison/study on use of TLS vs. DTLS. Among other things to consider, this information will also be useful for determining which transport protocol to use (TCP or UDP). I am expecting that DTLS will consume less CPU since DTLS does not have the TCP handshake. However, how much better? I am interested to get some idea whether the CPU cost for DTLS and TLS is significantly less, about the same, or significantly higher. Does anybody know any paper/study associated with this topic? Thanks, Erwin --f46d04428e5c8d7e8304b97c077e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Folks,

I have been googling for more infor= mation on the CPU cost comparison/study on use of TLS vs. DTLS.
A= mong other things to consider, this information will also be useful for det= ermining which transport protocol to use (TCP or UDP).

I am expecting that DTLS will consume less CPU since DT= LS does not have the TCP handshake.
However, how much better?
I am interested to get some idea whether the CPU cost for DTLS = and TLS is=A0significantly=A0less, about the same, or significantly higher.=

Does anybody know any pa= per/study associated with this topic?

Thanks,
Erwin
--f46d04428e5c8d7e8304b97c077e-- From ynir@checkpoint.com Tue Feb 21 11:20:58 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A3721E8052 for ; Tue, 21 Feb 2012 11:20:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.473 X-Spam-Level: X-Spam-Status: No, score=-10.473 tagged_above=-999 required=5 tests=[AWL=0.126, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCT8bcY9DfiV for ; Tue, 21 Feb 2012 11:20:57 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 183B121E803B for ; Tue, 21 Feb 2012 11:20:56 -0800 (PST) X-CheckPoint: {4F43EA7B-6-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q1LJKsnK003537; Tue, 21 Feb 2012 21:20:54 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 21 Feb 2012 21:20:54 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Tue, 21 Feb 2012 21:20:54 +0200 From: Yoav Nir To: Erwin Himawan Date: Tue, 21 Feb 2012 21:20:57 +0200 Thread-Topic: [TLS] CPU Cost for TLS vs. DTLS Thread-Index: Aczwze3LerGqokHHSmaQ5afypIrdKA== Message-ID: <5E635009-F97C-4AAF-8763-B248214C5E6B@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "tls@ietf.org" Subject: Re: [TLS] CPU Cost for TLS vs. DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 19:20:58 -0000 Hi Erwin Usually TLS and DTLS are not alternatives to each other. If the underlying = application is TCP-based (like HTTP), TLS is appropriate, whereas if the ap= plication protocol is UDP-based, DTLS is the obvious choice. The functions for encryption and MAC used by TLS and DTLS are the same, so = I wouldn't expect a huge performance difference. Still, because TCP is stre= am-based, partitioning the data into 16KB records is feasible, so you get l= ess of the per-record cost. With UDP you would try to have your datagrams (= and hence your records) fit on IP packets, limiting you to smaller records.= I would guess that this advantage would dominate the disadvantage of havin= g to do a three-way handshake. TCP has another advantage, that dropped packets get retransmitted by TCP, s= o they don't have to be encrypted again. UDP is not reliable, so retransmis= sions (if needed) would have to be handled by the application, and DTLS wou= ld have to be applied again. I don't know of any study that proves it, so this is mostly guesswork. There is one case where DTLS and TLS are alternatives. The so-called "SSL V= PN clients" tunnel actual IP packets either through a TCP stream or one-by-= one using DTLS. In that case the performance of DTLS is usually much better= , but mostly because it avoids the overhead of capturing the packets, placi= ng them on the stream and then separating the incoming stream into packets = and reinjecting them into the stack.=20 Hope this helps Yoav On Feb 21, 2012, at 6:37 PM, Erwin Himawan wrote: > Hi Folks, >=20 > I have been googling for more information on the CPU cost comparison/stud= y on use of TLS vs. DTLS. > Among other things to consider, this information will also be useful for = determining which transport protocol to use (TCP or UDP). >=20 > I am expecting that DTLS will consume less CPU since DTLS does not have t= he TCP handshake. > However, how much better? > I am interested to get some idea whether the CPU cost for DTLS and TLS is= significantly less, about the same, or significantly higher. >=20 > Does anybody know any paper/study associated with this topic? >=20 > Thanks, > Erwin >=20 From pgut001@login01.cs.auckland.ac.nz Tue Feb 21 16:20:54 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D44E321F86E4 for ; Tue, 21 Feb 2012 16:20:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Es3EuJPunzwE for ; Tue, 21 Feb 2012 16:20:43 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1940421F86F3 for ; Tue, 21 Feb 2012 16:20:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1329870043; x=1361406043; h=from:to:subject:in-reply-to:message-id:date; bh=b3S1YIj1JaFSvxG1g0dZFnqaFULgbh3UIwr9YlUDGa4=; b=KdIqpTnyP/dQUJYwLLuk1UUl6XT8ntu4BdzY6HHzioQyfhe1Jmsw7eKr KVFCUEPaGeysQTWMK2I+ZPbA5bXOAl1Qa6Ka6dzm+WpPmeuKTPYUwuQNs 1xLGF7V+4S8Qz0TjveQzv1zlpI1lFFHIiKsiJDZWSISlVRolKP8c0qgfW I=; X-IronPort-AV: E=Sophos;i="4.73,460,1325415600"; d="scan'208";a="104779771" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.34.40 - Outgoing - Outgoing Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 22 Feb 2012 13:20:39 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1Rzzwk-0004TY-Ez; Wed, 22 Feb 2012 13:20:38 +1300 From: Peter Gutmann To: ehimawan@gmail.com, tls@ietf.org In-Reply-To: Message-Id: Date: Wed, 22 Feb 2012 13:20:38 +1300 Subject: Re: [TLS] CPU Cost for TLS vs. DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 00:20:55 -0000 Erwin Himawan writes: >I am expecting that DTLS will consume less CPU since DTLS does not have the >TCP handshake. Counterargument: Significant parts of the TCP handshake will be handled by TOE's in NICs, while for DTLS you have to hand-assemble the reliable transport that TCP normally gives you. So DTLS could be a lot more expensive than TLS. You'd have to run multiple tests, DTLS against TLS with and without various levels of TOE (or find some representative NIC that's widely used, probably under Windows which the last time I looked has better TOE support than Linux), and also under adverse traffic conditions where the DTLS has to work to clean up the UDP unreliable transport. Peter. From gswaru@rediffmail.com Wed Feb 22 01:43:58 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA68C21F8709 for ; Wed, 22 Feb 2012 01:43:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.484 X-Spam-Level: **** X-Spam-Status: No, score=4.484 tagged_above=-999 required=5 tests=[BAYES_80=2, HTML_IMAGE_ONLY_16=1.526, HTML_MESSAGE=0.001, HTML_SHORT_LINK_IMG_2=0.001, MSGID_FROM_MTA_HEADER=0.803, SARE_SUB_ENC_UTF8=0.152, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3J+dN6vHTu3G for ; Wed, 22 Feb 2012 01:43:58 -0800 (PST) Received: from rediffmail.com (f4mail-235-197.rediffmail.com [202.137.235.197]) by ietfa.amsl.com (Postfix) with SMTP id F154621F882E for ; Wed, 22 Feb 2012 01:43:56 -0800 (PST) Received: (qmail 20394 invoked by uid 0); 22 Feb 2012 09:43:53 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=redf; d=rediffmail.com; b=o+qnbUFgbhmG6PWIIUQlwTD2wVJUmT3JA4Yf1fWr5szQGRtG3Wz4OOMXbnVa44hEvHonRexIVILD2uTo9NrU4Rnp44h/XqTZZXfi/1F6hbjJpWKmg67bZCGQbPbnAAqGTcbtd99OuXfWGrWEI5WR2NvLmkJKLnDundfUC3SgI0o= ; x-m-msg: asd54ad564ad7aa6sd5as6d5; a6da7d6asas6dasd77; 5dad65ad5sd; X-CTCH-Spam: Unknown X-CTCH-VOD: Unknown X-CTCH-Flags: : 0 X-CTCH-RefID: str=0001.0A150204.4F44B8D9.0071,ss=1,re=0.000,fgs=0 X-REDF-OSEN: gswaru@rediffmail.com Date: 22 Feb 2012 09:43:52 -0000 Message-ID: <20120222094352.20378.qmail@f4mail-235-197.rediffmail.com> MIME-Version: 1.0 To: "tls " Received: from unknown 101.63.241.115 by rediffmail.com via HTTP; 22 Feb 2012 09:43:52 -0000 Sender: gswaru@rediffmail.com From: "gonuguntla swarupa" Content-Type: multipart/alternative; boundary="=_f48eb027f445d436eb3112dbe999577a" Subject: [TLS] =?utf-8?q?TLS_extensions?= X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: gswaru@rediffmail.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 09:43:59 -0000 --=_f48eb027f445d436eb3112dbe999577a Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Hi, I have a query in SSLv3 client , sending Server Name extension in Client Hello. As these extensions are TLS specific extensions, what is the approparite action? a) Do we need to just ignore this extensions and proceed with next extension?(we need to parse for extensions even on sslv3 as Renegotitaion indication extension is valid for ssl3 also).So here query is when parsing these extension if we come across TLS specific extensions(like SNI), what is the  action to be taken? b) or abort the session and send decode error as soon as we see TLS specific extensions on SSL3 session. Thanks and Regards, Swarupa.G --=_f48eb027f445d436eb3112dbe999577a Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="UTF-8"
Hi,
I have a query in SSLv3 client , sending Server Name extension in Clie= nt Hello. As these extensions are TLS specific extensions, what is the appr= oparite action?
a) Do we need to just ignore this extensions and proceed with next ext= ension?(we need to parse for extensions even on sslv3 as Renegotitaion indi= cation extension is valid for ssl3 also).So here query is when parsing= these extension if we come across TLS specific extensions(like SNI), what = is the  action to be taken?
b) or abort the session and send decode error as soon as we see TLS sp= ecific extensions on SSL3 session.
Thanks and Regards,
Swarupa.G



Foll= ow Rediff Deal ho jaye! to get exciting of= fers in your city everyday.
--=_f48eb027f445d436eb3112dbe999577a-- From mrex@sap.com Wed Feb 22 07:51:53 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FC1921F8807 for ; Wed, 22 Feb 2012 07:51:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.066 X-Spam-Level: X-Spam-Status: No, score=-9.066 tagged_above=-999 required=5 tests=[AWL=-0.809, BAYES_00=-2.599, DATE_IN_PAST_12_24=0.992, HELO_EQ_DE=0.35, J_BACKHAIR_46=1, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qcAs-BFXee+7 for ; Wed, 22 Feb 2012 07:51:52 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7A16821F8809 for ; Wed, 22 Feb 2012 07:51:49 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q1MFpdHn026994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 22 Feb 2012 16:51:39 +0100 (MET) From: Martin Rex Message-Id: <201202221551.q1MFpc9m023263@fs4113.wdf.sap.corp> Orig-To: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: pgut001@cs.auckland.ac.nz, ehimawan@gmail.com, tls@ietf.org Date: Wed, 22 Feb 2012 01:50:51 +0100 (MET) In-Reply-To: from "Peter Gutmann" at Feb 22, 12 01:20:38 pm Sender: mrex@sap.com X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] CPU Cost for TLS vs. DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 15:51:53 -0000 Peter Gutmann wrote: > > Erwin Himawan writes: > > > >I am expecting that DTLS will consume less CPU since DTLS does not have the > >TCP handshake. > > Counterargument: Significant parts of the TCP handshake will be handled by > TOE's in NICs, while for DTLS you have to hand-assemble the reliable transport > that TCP normally gives you. So DTLS could be a lot more expensive than TLS. Even if it's not TOE (Tcp/ip Offload Engine) in NICs, a lot of the stuff is done in the networking protocol stack of the Kernel, whereas a reliable transport built by the application in userland will incur many additonal user<->kernel transitions and eventing. Unless your traffic patterns are seriously affected by the "TCP slow start" and "delayed Ack" features in TCP, I would expect TLS-over-TCP to provide better performance than DTLS-over-UDP. Where it isn't, I expect it to be a shortcoming of at least one the particular implementations in that comparison TLS-over-TCP vs DTLS-over-UDP. -Martin From ynir@checkpoint.com Wed Feb 22 08:01:36 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4114A21F87A9 for ; Wed, 22 Feb 2012 08:01:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.976 X-Spam-Level: X-Spam-Status: No, score=-9.976 tagged_above=-999 required=5 tests=[AWL=-0.377, BAYES_00=-2.599, J_BACKHAIR_46=1, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QZbvChfhqNZw for ; Wed, 22 Feb 2012 08:01:35 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 363DB21F87A1 for ; Wed, 22 Feb 2012 08:01:34 -0800 (PST) X-CheckPoint: {4F450D39-0-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q1MG1KMS002395; Wed, 22 Feb 2012 18:01:20 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 22 Feb 2012 18:01:20 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Wed, 22 Feb 2012 18:01:19 +0200 From: Yoav Nir To: "mrex@sap.com" Date: Wed, 22 Feb 2012 18:01:21 +0200 Thread-Topic: [TLS] CPU Cost for TLS vs. DTLS Thread-Index: Aczxezc0sc+fQUsDQseflrqSFytEUA== Message-ID: <1B9DC32D-A78F-4ABF-82DD-5E5F641BCAA8@checkpoint.com> References: <201202221551.q1MFpc9m023263@fs4113.wdf.sap.corp> In-Reply-To: <201202221551.q1MFpc9m023263@fs4113.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "tls@ietf.org" Subject: Re: [TLS] CPU Cost for TLS vs. DTLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 16:01:36 -0000 I think we can all agree that the choice of TLS vs DTLS is not a factor in = the decision of whether to base your application on UDP or TCP. The nature of the application should dictate a reliable, stream-based trans= port, or a non-reliable datagram-based transport. The differences in perfor= mance of TLS vs DTLS are negligible compared to the cost of emulating one t= ransport using the other. Yoav On Feb 22, 2012, at 2:50 AM, Martin Rex wrote: > Peter Gutmann wrote: >>=20 >> Erwin Himawan writes: >>>=20 >>> I am expecting that DTLS will consume less CPU since DTLS does not have= the >>> TCP handshake. >>=20 >> Counterargument: Significant parts of the TCP handshake will be handled = by >> TOE's in NICs, while for DTLS you have to hand-assemble the reliable tra= nsport >> that TCP normally gives you. So DTLS could be a lot more expensive than= TLS. >=20 > Even if it's not TOE (Tcp/ip Offload Engine) in NICs, a lot of the > stuff is done in the networking protocol stack of the Kernel, > whereas a reliable transport built by the application in userland > will incur many additonal user<->kernel transitions and eventing. >=20 > Unless your traffic patterns are seriously affected by the "TCP slow star= t" > and "delayed Ack" features in TCP, I would expect TLS-over-TCP > to provide better performance than DTLS-over-UDP. Where it isn't, > I expect it to be a shortcoming of at least one the particular > implementations in that comparison TLS-over-TCP vs DTLS-over-UDP. From wwwrun@rfc-editor.org Thu Feb 16 10:18:40 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F26C11E8081 for ; Thu, 16 Feb 2012 10:18:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.414 X-Spam-Level: X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PshIQhBgG3NC for ; Thu, 16 Feb 2012 10:18:35 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id E829011E8072 for ; Thu, 16 Feb 2012 10:18:35 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 79FD3B1E002; Thu, 16 Feb 2012 10:13:46 -0800 (PST) To: tim@dierks.org, ekr@rtfm.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, ekr@networkresonance.com, jsalowey@cisco.com, ekr@rtfm.com From: RFC Errata System Message-Id: <20120216181346.79FD3B1E002@rfc-editor.org> Date: Thu, 16 Feb 2012 10:13:46 -0800 (PST) X-Mailman-Approved-At: Wed, 22 Feb 2012 19:02:18 -0800 Cc: rfc-editor@rfc-editor.org, tls@ietf.org, daniel.otte@rub.de Subject: [TLS] [Editorial Errata Reported] RFC5246 (3122) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 18:18:40 -0000 The following errata report has been submitted for RFC5246, "The Transport Layer Security (TLS) Protocol Version 1.2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=3122 -------------------------------------- Type: Editorial Reported by: Daniel Otte Section: A.4. Original Text ------------- enum { hello_request(0), client_hello(1), server_hello(2), certificate(11), server_key_exchange (12), certificate_request(13), server_hello_done(14), certificate_verify(15), client_key_exchange(16), finished(20) (255) } HandshakeType; Corrected Text -------------- enum { hello_request(0), client_hello(1), server_hello(2), certificate(11), server_key_exchange (12), certificate_request(13), server_hello_done(14), certificate_verify(15), client_key_exchange(16), finished(20), (255) } HandshakeType; Notes ----- The comma after finished(20) is missing in the original text. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5246 (draft-ietf-tls-rfc4346-bis-10) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.2 Publication Date : August 2008 Author(s) : T. Dierks, E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Thu Feb 16 10:25:45 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9C6721F8573 for ; Thu, 16 Feb 2012 10:25:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.415 X-Spam-Level: X-Spam-Status: No, score=-102.415 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BLthz0FVjaqJ for ; Thu, 16 Feb 2012 10:25:41 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 83CB821F85DD for ; Thu, 16 Feb 2012 10:25:41 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 482FCB1E004; Thu, 16 Feb 2012 10:20:52 -0800 (PST) To: tim@dierks.org, ekr@rtfm.com, stephen.farrell@cs.tcd.ie, turners@ieca.com, ekr@networkresonance.com, jsalowey@cisco.com, ekr@rtfm.com From: RFC Errata System Message-Id: <20120216182052.482FCB1E004@rfc-editor.org> Date: Thu, 16 Feb 2012 10:20:52 -0800 (PST) X-Mailman-Approved-At: Wed, 22 Feb 2012 19:02:18 -0800 Cc: rfc-editor@rfc-editor.org, tls@ietf.org, daniel.otte@rub.de Subject: [TLS] [Editorial Errata Reported] RFC5246 (3123) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 18:25:46 -0000 The following errata report has been submitted for RFC5246, "The Transport Layer Security (TLS) Protocol Version 1.2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=3123 -------------------------------------- Type: Editorial Reported by: Daniel Otte Section: A.4.2. Original Text ------------- struct { select (KeyExchangeAlgorithm) { case dh_anon: ServerDHParams params; case dhe_dss: case dhe_rsa: ServerDHParams params; digitally-signed struct { opaque client_random[32]; opaque server_random[32]; ServerDHParams params; } signed_params; case rsa: case dh_dss: case dh_rsa: struct {} ; /* message is omitted for rsa, dh_dss, and dh_rsa */ /* may be extended, e.g., for ECDH -- see [TLSECC] */ } ServerKeyExchange; Corrected Text -------------- struct { select (KeyExchangeAlgorithm) { case dh_anon: ServerDHParams params; case dhe_dss: case dhe_rsa: ServerDHParams params; digitally-signed struct { opaque client_random[32]; opaque server_random[32]; ServerDHParams params; } signed_params; case rsa: case dh_dss: case dh_rsa: struct {} ; /* message is omitted for rsa, dh_dss, and dh_rsa */ /* may be extended, e.g., for ECDH -- see [TLSECC] */ }; } ServerKeyExchange; Notes ----- The '};' which belongs to 'select (KeyExchangeAlgorithm) {' is missing in the original text. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5246 (draft-ietf-tls-rfc4346-bis-10) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.2 Publication Date : August 2008 Author(s) : T. Dierks, E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From ietf@augustcellars.com Thu Feb 23 17:55:58 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B1F21F8871 for ; Thu, 23 Feb 2012 17:55:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=-0.635, BAYES_20=-0.74, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gwYVcjfPK36l for ; Thu, 23 Feb 2012 17:55:57 -0800 (PST) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) by ietfa.amsl.com (Postfix) with ESMTP id 79EF821F886F for ; Thu, 23 Feb 2012 17:55:57 -0800 (PST) Received: from Tobias (176.120.168.69.static.onlinenw.com [69.168.120.176]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id 2B81238F1D; Thu, 23 Feb 2012 17:55:57 -0800 (PST) From: "Jim Schaad" To: "'Eric Rescorla'" Date: Thu, 23 Feb 2012 17:55:12 -0800 Message-ID: <02c901ccf297$58b4d010$0a1e7030$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AczyltKKA2ZO+sdgQGuDdepgJ6meyQ== Content-Language: en-us Cc: tls@ietf.org Subject: [TLS] RFC 5705 and reconnection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 01:55:58 -0000 I was planning on using RFC 5705 for getting some cryptographic material relating to the TLS channel, however I was asked a question about reconnections and it suddenly dawned on me that I don't know what the behavior would be in the event of a reconnect/resumption occurring. If I get the key material immediately, then I will be able to have the material agree. If there is an amount of time between when the client and the server look to derive the key material, and if a re-connect occurs during that interval, then will they client and the server have the same material? Jim From ekr@rtfm.com Fri Feb 24 07:52:57 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F00C421F8866 for ; Fri, 24 Feb 2012 07:52:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.92 X-Spam-Level: X-Spam-Status: No, score=-102.92 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8TrrJJ8tsXa for ; Fri, 24 Feb 2012 07:52:57 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id D0F8B21F8850 for ; Fri, 24 Feb 2012 07:52:56 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so1948251vcb.31 for ; Fri, 24 Feb 2012 07:52:56 -0800 (PST) Received-SPF: pass (google.com: domain of ekr@rtfm.com designates 10.52.69.116 as permitted sender) client-ip=10.52.69.116; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ekr@rtfm.com designates 10.52.69.116 as permitted sender) smtp.mail=ekr@rtfm.com Received: from mr.google.com ([10.52.69.116]) by 10.52.69.116 with SMTP id d20mr1530078vdu.58.1330098776400 (num_hops = 1); Fri, 24 Feb 2012 07:52:56 -0800 (PST) Received: by 10.52.69.116 with SMTP id d20mr1235055vdu.58.1330098776328; Fri, 24 Feb 2012 07:52:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.70.136 with HTTP; Fri, 24 Feb 2012 07:52:16 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: <02c901ccf297$58b4d010$0a1e7030$@augustcellars.com> References: <02c901ccf297$58b4d010$0a1e7030$@augustcellars.com> From: Eric Rescorla Date: Fri, 24 Feb 2012 07:52:16 -0800 Message-ID: To: Jim Schaad Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmvKKOiBOPog7PNX9vR6qJIfxcKQpL56C4jXfAYrUaqW9d4J0UPVJOI52hWhH9qU8tpzIQN Cc: tls@ietf.org Subject: Re: [TLS] RFC 5705 and reconnection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 15:52:58 -0000 I'm not sure I understand the context. Is this about rehandshake on the same channel or about resumption on a different channel? -Ekr On Thu, Feb 23, 2012 at 5:55 PM, Jim Schaad wrote: > I was planning on using RFC 5705 for getting some cryptographic material > relating to the TLS channel, however I was asked a question about > reconnections and it suddenly dawned on me that I don't know what the > behavior would be in the event of a reconnect/resumption occurring. > > If I get the key material immediately, then I will be able to have the > material agree. > > If there is an amount of time between when the client and the server look to > derive the key material, and if a re-connect occurs during that interval, > then will they client and the server have the same material? > > Jim > > From ietf@augustcellars.com Fri Feb 24 08:21:53 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29CFC21F8871 for ; Fri, 24 Feb 2012 08:21:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.241 X-Spam-Level: X-Spam-Status: No, score=-3.241 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01b4ahVc5oGp for ; Fri, 24 Feb 2012 08:21:51 -0800 (PST) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) by ietfa.amsl.com (Postfix) with ESMTP id A759D21F8606 for ; Fri, 24 Feb 2012 08:21:50 -0800 (PST) Received: from Tobias (176.120.168.69.static.onlinenw.com [69.168.120.176]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id 5EF7D2C9C5; Fri, 24 Feb 2012 08:21:50 -0800 (PST) From: "Jim Schaad" To: "'Eric Rescorla'" References: <02c901ccf297$58b4d010$0a1e7030$@augustcellars.com> In-Reply-To: Date: Fri, 24 Feb 2012 08:21:03 -0800 Message-ID: <002301ccf310$4f3e6fe0$edbb4fa0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQIwSL/pouyjUsh4Y98MRj82Ew498wFzcdnzlXnzWOA= Content-Language: en-us Cc: tls@ietf.org Subject: Re: [TLS] RFC 5705 and reconnection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 16:21:53 -0000 Possibly both, it would depend on what the client and server applications are expected to know. I was originally thinking about resumption on a different channel. Jim > -----Original Message----- > From: Eric Rescorla [mailto:ekr@rtfm.com] > Sent: Friday, February 24, 2012 7:52 AM > To: Jim Schaad > Cc: tls@ietf.org > Subject: Re: RFC 5705 and reconnection > > I'm not sure I understand the context. Is this about rehandshake on the > same channel or about resumption on a different channel? > > -Ekr > > > On Thu, Feb 23, 2012 at 5:55 PM, Jim Schaad > wrote: > > I was planning on using RFC 5705 for getting some cryptographic > > material relating to the TLS channel, however I was asked a question > > about reconnections and it suddenly dawned on me that I don't know > > what the behavior would be in the event of a reconnect/resumption > occurring. > > > > If I get the key material immediately, then I will be able to have the > > material agree. > > > > If there is an amount of time between when the client and the server > > look to derive the key material, and if a re-connect occurs during > > that interval, then will they client and the server have the same material? > > > > Jim > > > > From ekr@rtfm.com Fri Feb 24 08:28:32 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 593A721F8882 for ; Fri, 24 Feb 2012 08:28:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.922 X-Spam-Level: X-Spam-Status: No, score=-102.922 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2MKvhehO8Os for ; Fri, 24 Feb 2012 08:28:31 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id B384721F88AE for ; Fri, 24 Feb 2012 08:28:31 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so1992594vbb.31 for ; Fri, 24 Feb 2012 08:28:31 -0800 (PST) Received-SPF: pass (google.com: domain of ekr@rtfm.com designates 10.52.27.70 as permitted sender) client-ip=10.52.27.70; Authentication-Results: mr.google.com; spf=pass (google.com: domain of ekr@rtfm.com designates 10.52.27.70 as permitted sender) smtp.mail=ekr@rtfm.com Received: from mr.google.com ([10.52.27.70]) by 10.52.27.70 with SMTP id r6mr1655564vdg.41.1330100911324 (num_hops = 1); Fri, 24 Feb 2012 08:28:31 -0800 (PST) Received: by 10.52.27.70 with SMTP id r6mr1336523vdg.41.1330100911115; Fri, 24 Feb 2012 08:28:31 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.70.136 with HTTP; Fri, 24 Feb 2012 08:27:51 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: <002301ccf310$4f3e6fe0$edbb4fa0$@augustcellars.com> References: <02c901ccf297$58b4d010$0a1e7030$@augustcellars.com> <002301ccf310$4f3e6fe0$edbb4fa0$@augustcellars.com> From: Eric Rescorla Date: Fri, 24 Feb 2012 08:27:51 -0800 Message-ID: To: Jim Schaad Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQkw+MvGd/t25M1yhScZBH52yQpiPaSuAJm4XjqinvFifaCvMx2WT/tGAzoc1jrNz0CQs/PU Cc: tls@ietf.org Subject: Re: [TLS] RFC 5705 and reconnection X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 16:28:32 -0000 On Fri, Feb 24, 2012 at 8:21 AM, Jim Schaad wrote: > Possibly both, it would depend on what the client and server applications > are expected to know. =A0I was originally thinking about resumption on a > different channel. As Nasko says, the exporters on different channels (even with resumption) are (deliberately) different. So, applications which want to have a secret spanning channels will need to figure something else out, I suspect -Ekr From Jeff.Hodges@KingsMountain.com Tue Feb 28 08:58:42 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C9CB21F86D7 for ; Tue, 28 Feb 2012 08:58:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.895 X-Spam-Level: X-Spam-Status: No, score=-97.895 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AH8TlbIf6qLp for ; Tue, 28 Feb 2012 08:58:41 -0800 (PST) Received: from oproxy4-pub.bluehost.com (oproxy4.bluehost.com [IPv6:2605:dc00:100:2::a4]) by ietfa.amsl.com (Postfix) with SMTP id 4635721F86C3 for ; Tue, 28 Feb 2012 08:58:41 -0800 (PST) Received: (qmail 26403 invoked by uid 0); 28 Feb 2012 16:58:39 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 28 Feb 2012 16:58:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=jZHzgJ/mvwu3zyH4QhJCqbpRB17RUWXnX17SOQBAh6I=; b=W5O1fhVCKzN2idY9BT3rgpOpFIDD+pz65h8kbLin785R3qtIf0t8+mwCsDXULPG4zUBfYsNVYuIymMq/6gzSp4ABSuwLNWqdts5XyFRPlZg8IZFdvIwp2QM1slqJUkI7; Received: from [107.37.150.170] by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1S2QNo-0005l4-B2 for tls@ietf.org; Tue, 28 Feb 2012 09:58:36 -0700 Message-ID: <4F4D07B7.9090107@KingsMountain.com> Date: Tue, 28 Feb 2012 08:58:31 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: IETF TLS WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 107.37.150.170 authed with jeff.hodges+kingsmountain.com} Subject: [TLS] fyi: CA/Browser Forum Announces Organizational Reform Working Group X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2012 16:58:42 -0000 Of possible interest (note the solicitation of position papers and statements of interest down at the end)... --- http://cabforum.org/ 28 February 2012 CA/Browser Forum Announces Organizational Reform Working Group The CA/Browser Forum is a voluntary organization of leading certification authorities (CAs) and vendors of Internet browser software and other applications. At the twenty fifth face to face meeting of the CA/Browser Forum, held in Santa Clara, California, USA on February 22 and 23rd, 2012, the membership agreed to form a working group on organizational reform. The task of this group will be to develop and present to the full organization, by April 16th, proposals for a new charter and bylaws. The CA/Browser Forum recognizes the growing importance of the PKI marketplace as a critical piece of Internet infrastructure, and the need to continue to safeguard and advance the public's trust in the Internet as a secure place for communication, socialization and commerce. The goal of the reform will be to evolve the organization into a more mature and capable, multi-stakeholder forum that can promote the growth and maintenance of the public PKI and certificate ecosystem in the interests of Internet security and the broader public good. Key topics to be addressed by the special working group include: Formal incorporation of the Forum; A broader scope of action; Wider membership and participation in the Forum, including by certificate subscribers, relying parties, and users; and A more open and public process. In support of this process, the special working group is soliciting short (no more than 750 words, please) position papers and statements of interest from organizations and individuals on these topics. We encourage stakeholders to submit their comments to questions@cabforum.org now through March 30, 2012. All submissions will be posted publicly on the CA/Browser Forum website. (www.cabforum.org) --- end From Michael.Staubermann@webolution.de Wed Feb 29 01:03:26 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B45421F8885 for ; Wed, 29 Feb 2012 01:03:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.69 X-Spam-Level: X-Spam-Status: No, score=0.69 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTY-jnBWkZQG for ; Wed, 29 Feb 2012 01:03:26 -0800 (PST) Received: from mail.webolution.de (mail.webolution.de [80.152.246.40]) by ietfa.amsl.com (Postfix) with ESMTP id 9310A21F8889 for ; Wed, 29 Feb 2012 01:03:22 -0800 (PST) Received: from staubermann.webolution.de ([192.168.168.32] helo=StaubermannPC) by mail.webolution.de with esmtp (Exim 4.69) (envelope-from ) id 1S2fRD-0001P6-Fv for tls@ietf.org; Wed, 29 Feb 2012 10:03:07 +0100 From: "Michael Staubermann" To: Date: Wed, 29 Feb 2012 10:03:31 +0100 Message-ID: <068101ccf6c1$053210f0$0f9632d0$@Staubermann@webolution.de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0682_01CCF6C9.66F678F0" X-Mailer: Microsoft Office Outlook 12.0 Content-language: de Thread-Index: Acz2CX+d6aWyqDHbRUy+yKW0+Cr3/wAt3GNw X-SA-Exim-Connect-IP: 192.168.168.32 X-SA-Exim-Mail-From: Michael.Staubermann@webolution.de X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:14:11 +0000) X-SA-Exim-Scanned: Yes (on mail.webolution.de) X-Mailman-Approved-At: Wed, 29 Feb 2012 07:10:44 -0800 Subject: [TLS] TLS Hello Request for Connection Request X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 09:05:24 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0682_01CCF6C9.66F678F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Our group is planning to use the TLS Hello Request Message (sent from the server to the client) to request a new TLS Connection establishment from the Client to the Server (where the Client has the choice to ignore the Hello Request). The environment/preconditions: TLS is used over a non-IP, reliable transport layer over a shared medium (wireless media or wired bus). The reliable transport layer does not support session open/close (i.e. Connect/Disconnect), the association (channel) between Client and server is implicit open. The underlying Reliable Transport Layer uses an (AES-CMAC) authentication with a shared secret known only to one client and server pair, and the Hello Request is sent over this authenticated channel from the Server to the Client. The Hello Request Format is standard as per RFC5246: Content-Type=Handshake(21), Message Type=Hello Request(0), MsgLength/ContentLength=0, Major=3 and Minor=2 or 3 (TLS1.1/TLS1.2) Version >From RFC5246 (7.4.1.1): HelloRequest is a simple notification that the client should begin the negotiation process *anew*. In response, the client should send a ClientHello message when convenient. This message is not intended to establish which side is the client or server but merely to initiate a new negotiation. Question: Is it ok to use the Hello Request Message for the above mentioned purpose (initiate a non existing TLS Connection), or may it collide in the future with a use of Hello Request with slightly other semantics? The word "anew" rises my attention. Best regards, Michael Staubermann ------=_NextPart_000_0682_01CCF6C9.66F678F0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Our group is planning to use the TLS Hello Request Message = (sent from the server to the client) to request a = new

TLS = Connection establishment from the Client to the Server (where the Client = has the choice to ignore the Hello Request).

 

The = environment/preconditions:

TLS is used over a non-IP, reliable = transport layer over a shared medium (wireless media or wired = bus).

The = reliable transport layer does not support session open/close (i.e. = Connect/Disconnect), the association (channel)

between Client and server is = implicit open. The underlying Reliable Transport Layer uses an = (AES-CMAC)

authentication with a shared secret known only to one = client and server pair, and the Hello Request is =

sent over = this authenticated channel from the Server to the = Client.

The = Hello Request Format is standard as per RFC5246: = Content-Type=3DHandshake(21), Message Type=3DHello Request(0), = MsgLength/ContentLength=3D0, Major=3D3 and Minor=3D2 or = 3

(TLS1.1/TLS1.2) Version

 

From RFC5246 = (7.4.1.1):

HelloRequest is a simple notification that the client = should begin the negotiation process *anew*.  In response, = the client should send a ClientHello message when convenient.  This = message is not intended to establish which side is the client or server = but merely to initiate a new negotiation.

 

Question:

Is it ok to use the Hello Request = Message for the above mentioned purpose (initiate a non existing TLS = Connection),

or may it collide in the future with a use of Hello Request = with slightly other semantics?

The word "anew" rises my = attention.

 

Best regards,

   Michael = Staubermann

------=_NextPart_000_0682_01CCF6C9.66F678F0-- From marsh@extendedsubset.com Wed Feb 29 10:41:41 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A89921F868A for ; Wed, 29 Feb 2012 10:41:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zDTkkqur7fBM for ; Wed, 29 Feb 2012 10:41:40 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by ietfa.amsl.com (Postfix) with ESMTP id 8C76621F8678 for ; Wed, 29 Feb 2012 10:41:40 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1S2oT5-000Dvj-P4; Wed, 29 Feb 2012 18:41:39 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 7438267A3; Wed, 29 Feb 2012 18:41:38 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/+EcwUypm3mWmQRnqNd+Q4xnJo6Egg+GI= Message-ID: <4F4E7163.2000300@extendedsubset.com> Date: Wed, 29 Feb 2012 12:41:39 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: Michael Staubermann References: <068101ccf6c1$053210f0$0f9632d0$@Staubermann@webolution.de> In-Reply-To: <068101ccf6c1$053210f0$0f9632d0$@Staubermann@webolution.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] TLS Hello Request for Connection Request X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 18:41:41 -0000 On 02/29/2012 03:03 AM, Michael Staubermann wrote: > Our group is planning to use the TLS Hello Request Message (sent from > the server to the client) to request a new > TLS Connection establishment from the Client to the Server (where the > Client has the choice to ignore the Hello Request). >[...] > Is it ok to use the Hello Request Message for the above mentioned > purpose (initiate a non existing TLS Connection), Not within the definition of TLS, as I read it. TLS has only two defined ways to initiate a connection: An SSL 3.0/TLS format ClientHello message An SSLv2-compatible ClientHello message (deprecated) > or may it collide in the future with a use of Hello Request with > slightly other semantics? It's not so much that, after all no one is likely sending or accepting HelloRequests that you might fail to interoperate with now. It's that the real TLS ClientHello and ServerHello messages have fields necessary for version negotiation. If you go back through the archives of this list, there has been plenty of discussion about the exact details of this process. There are also protections against things like version downgrade attacks that you only get when using the official message. > The word "anew" rises my attention. It's interesting that the TLS RFCs actually say "The HelloRequest message MAY be sent by the server at any time." But clearly the intent here is any time after an initial handshake. Implementations probably vary significantly in their handling of a HelloRequest message sent during an initial (or subsequent) handshake. Note that TLS defines the "client" as "The application entity that initiates a TLS connection to a server." and "server" as "The server is the application entity that responds to requests for connections from clients." So the server cannot initiate the connection, by definition. But of course, TLS only defines TLS. What you want to do at lower or upper protocol layers, or on the same channel before or after TLS is used is your own business. My recommendation would be to define your own super-lightweight transport for this purpose. Since your transport seems to have its own particular properties, you might consider defining a way to separate the proper TLS records from your other messages. It could be a simple TLV format. You could even pick a random GUID or something to indicate the HelloRequest-like semantics you need. Anything could work, but it's probably better if it *doesn't* look too much like an actual TLS message when it's not actually valid TLS. - Marsh P.S. I suspect you might find it useful to have a "TLS-carrying connection closed" message as well. From Jeff.Hodges@KingsMountain.com Wed Feb 29 15:50:21 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD02A21F8638 for ; Wed, 29 Feb 2012 15:50:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.052 X-Spam-Level: X-Spam-Status: No, score=-100.052 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ygBDYSLRSqNm for ; Wed, 29 Feb 2012 15:50:21 -0800 (PST) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id DC80421F8627 for ; Wed, 29 Feb 2012 15:50:20 -0800 (PST) Received: (qmail 27793 invoked by uid 0); 29 Feb 2012 23:50:20 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy7.bluehost.com with SMTP; 29 Feb 2012 23:50:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=prAdhajFEtkA21a1Us8ZwFMwJTD479geX8WjzEIn9Wc=; b=itzbv0L4IrLOl47Oz9PdIOgq9g3ZVxTMlChXgfiOq3WFpuQlQkE8FpWvsNdS6ZoO7TMsz1RNyNBTNFkrAkQ3krWZnUmRwIBQRpX6ONiDt/3HqbdNhGsV4F6apAu1nQAu; Received: from c-24-4-122-173.hsd1.ca.comcast.net ([24.4.122.173] helo=[192.168.11.11]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1S2tHn-0004Ir-V6 for tls@ietf.org; Wed, 29 Feb 2012 16:50:20 -0700 Message-ID: <4F4EB9BA.4050600@KingsMountain.com> Date: Wed, 29 Feb 2012 15:50:18 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.27) Gecko/20120216 Thunderbird/3.1.19 MIME-Version: 1.0 To: IETF TLS WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.122.173 authed with jeff.hodges+kingsmountain.com} Subject: Re: [TLS] fyi: CA/Browser Forum Announces Organizational Reform Working Group X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Feb 2012 23:50:22 -0000 note that the CABF announcement now has a specific URI.. http://cabforum.org/org_announcement.html And here's PayPal's public position statement we submitted to the CA/Browser Forum reform working group.. PayPal supports reform at the CA/Browser Forum =JeffH Internet Standards and Governance Team PayPal Information Risk Management