From tls-bounces@lists.ietf.org Mon Oct 02 05:55:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUKTt-0005yz-Lt; Mon, 02 Oct 2006 05:53:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUKTs-0005yi-Pa for tls@ietf.org; Mon, 02 Oct 2006 05:53:00 -0400 Received: from tholian.rsasecurity.com ([216.162.240.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUKTr-0005Le-Fw for tls@ietf.org; Mon, 02 Oct 2006 05:53:00 -0400 Received: from hyperion.rsasecurity.com by tholian.rsasecurity.com via smtpd (for [156.154.16.150] [156.154.16.150]) with ESMTP; Mon, 2 Oct 2006 05:52:42 -0400 Received: from sdtihq24.securid.com (sdtihq24.na.rsa.net [10.100.8.152]) by hyperion.na.rsa.net (MOS 3.7.4b-GA) with ESMTP id CSI10569; Mon, 2 Oct 2006 06:04:52 +0500 (GMT-5) Received: from rsana-ex-hq0.NA.RSA.NET (e2k.rsa.net [10.100.8.49]) by sdtihq24.securid.com (8.12.10/8.12.9) with ESMTP id k929qHiO002595 for ; Mon, 2 Oct 2006 05:52:27 -0400 (EDT) Received: from rsana-ex-sm1.NA.RSA.NET ([10.80.211.17]) by rsana-ex-hq0.NA.RSA.NET with Microsoft SMTPSVC(6.0.3790.211); Mon, 2 Oct 2006 05:52:17 -0400 Received: from localhost ([10.129.13.14]) by rsana-ex-sm1.NA.RSA.NET with Microsoft SMTPSVC(6.0.3790.211); Mon, 2 Oct 2006 02:52:16 -0700 Date: Mon, 2 Oct 2006 11:51:23 +0200 (W. Europe Daylight Time) From: =?iso-8859-1?Q?Magnus_Nystr=F6m?= To: tls@ietf.org Message-ID: X-X-Sender: mnystrom@[10.80.211.17] MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-OriginalArrivalTime: 02 Oct 2006 09:52:16.0314 (UTC) FILETIME=[7163F1A0:01C6E608] X-Spam-Score: 0.1 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: Subject: [TLS] Follow-up to comments on draft-linn-otp-tls-00 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: magnus@rsasecurity.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: , Errors-To: tls-bounces@lists.ietf.org All, I would like to follow-up on some of the comments that John and I have received in the past and also received during the TLS session at the 66th IETF in Montreal. Firstly, I'd like to thank all the reviewers; we really appreciate you taking the time. Whether to layer on TLS-PSK or not ---------------------------------- Several reviewers have suggested that it would be architecturally better if new ciphersuites would be defined rather than attempting to profile/extend TLS-PSK. There seems to be a few reasons why the current approach has not been seen as optimal: a) The term "key exchange" in TLS relates to the whole handshake as opposed to the actual cryptographic key exchange (Pasi Eronen). Since we're modifying the handshake (new extensions, new alerts, ...) it should follow that this is a new key exchange and hence should define a new ciphersuite (or -suites). b) Interpretation of certain data (e.g. the psk_identity field) will vary depending on whether "ordinary" TLS-PSK is performed or not; this is undesirable as servers will need to be prepared to interpret (and act upon) this field based on information in the Hello exchanges (Eric Rescorla). I don't quite understand a) above. I don't see that RFC4346 says that the key exchange defines the whole handshake. But even if this is the case, what about some of the extensions defined in RFC 4366, e.g. the truncated_hmac one? It seems to me that that extension also modifies the behavior of the parties, without introducing new ciphersuites? On b) above, I agree that this is undesirable. One way forward that I can see - besides defining new ciphersuites - would be to introduce (and require use of, when doing a handshake based on OTPs) a new extension, along the lines of (obviously the syntax needs to be corrected): OTPHandshakeParams otp_handshake_params<0..2^16-1>;> struct { OTPAlgorithm otp_algorithm; ChallengeData challenge_data<0..>; HardeningData hardening_data<0..>; KeyIdentifier key_identifier<0..>; UserIdentifier user_identifier<0..>; } OTPHandshakeParams; This approach would allow not only signaling of the intent of basing the exchange on OTPs, but also to negotiate the actual OTP algorithm as well as related parameters. I note that the above should also take away the need to change the meaning of the psk_identity field, something we anyway have been recommended not to do. What I'd like to ask is if this mandatory "signaling" of OTP use would be enough to resolve the concerns raised about the layering on top of the TLS-PSK ciphersuites? The strength of OTPs as a basis for TLS session keys ---------------------------------------------------- There was a discussion about this in Montreal and I just want to clarify: A typical OTP is 6 - 8 decimal digits long, although alphanumerical OTPs are also in use. In addition, some OTP systems employ centralized PINs, meaning that the user provides a PIN in conjunction with the OTP. Typically this would therefore give in the order of 33 - 40 bits of entropy. Through hardening, one can increase the resistance. For example, hardening by iterative hashes, as suggested in the current draft, could complicate an attack as follows: With 100,000 iterations, the work load of the attacker will be about 17 bits more, in effect adding about 17 bits of strength (admittedly at a cost for the legit parties). For the example above, this would mean 50 - 57 bits of "entropy". Clearly this is less than even the 80-bit level offered through use of RSA 1024-bit keys, and I agree we could make this fact explicit (e.g. through some detailed examples) in the document and also add a recommendation to use the D-H-PSK (with normal caveats about MITM) or RSA-PSK variants in these situations. But I would not want to disallow the "direct" variant, for example since some connected OTP tokens may be able to emit considerably longer OTPs when in connected mode, and therefore would not need D-H (or the use of a PKI with RSA). (Longer OTPs in connected mode do not need to degrade the user experience since the user in these cases only enters the PIN, the OTP is programmatically retrieved. Long OTPs also eliminate or at least reduce the need for "hardening"). -- Magnus _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Oct 03 07:02:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUi0K-0000D7-Nv; Tue, 03 Oct 2006 07:00:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUi0J-0000D0-6E for tls@ietf.org; Tue, 03 Oct 2006 07:00:03 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUi0H-0000SS-No for tls@ietf.org; Tue, 03 Oct 2006 07:00:03 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k93B00UK021541; Tue, 3 Oct 2006 14:00:00 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 14:00:00 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Oct 2006 14:00:00 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Follow-up to comments on draft-linn-otp-tls-00 Date: Tue, 3 Oct 2006 14:00:02 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Follow-up to comments on draft-linn-otp-tls-00 Thread-Index: AcbmCUK2YqaAtgFQTku23Fwp9InzMQAz1wYQ From: To: , X-OriginalArrivalTime: 03 Oct 2006 11:00:00.0080 (UTC) FILETIME=[11FF2D00:01C6E6DB] X-Spam-Score: 0.2 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Magnus Nystr=F6m wrote: > On b) above, I agree that this is undesirable. One way forward that I > can see - besides defining new ciphersuites - would be to introduce > (and require use of, when doing a handshake based on OTPs) a new > extension, along the lines of (obviously the syntax needs to be > corrected): >=20 > OTPHandshakeParams otp_handshake_params<0..2^16-1>;> > struct { > OTPAlgorithm otp_algorithm; > ChallengeData challenge_data<0..>; > HardeningData hardening_data<0..>; > KeyIdentifier key_identifier<0..>; > UserIdentifier user_identifier<0..>; > } OTPHandshakeParams; >=20 > This approach would allow not only signaling of the intent of basing > the exchange on OTPs, but also to negotiate the actual OTP algorithm > as well as related parameters. I note that the above should also take > away the need to change the meaning of the psk_identity field, > something we anyway have been recommended not to do. >=20 > What I'd like to ask is if this mandatory "signaling" of OTP use would > be enough to resolve the concerns raised about the layering on top of > the TLS-PSK ciphersuites? It would solve the "coexistence with ordinary TLS-PSK" concern, but the motivation of this layering still puzzles me... it would make sense if defining a new ciphersuite was extremely hard and unpleasant thing=20 that should be done only if no other option is possible... but to me, it looks like a new ciphersuite would be both easier, simpler, and architecturally "nicer" way to do OTP with TLS.=20 And it's actually easier get numbers for ciphersuites than=20 TLS extensions :-) Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Oct 03 11:34:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUmGg-0004wH-W5; Tue, 03 Oct 2006 11:33:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUmGf-0004w0-JF for tls@lists.ietf.org; Tue, 03 Oct 2006 11:33:13 -0400 Received: from citi.umich.edu ([141.211.133.111]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUmGe-00005R-Aj for tls@lists.ietf.org; Tue, 03 Oct 2006 11:33:13 -0400 Received: from [141.211.133.26] (yoga.citi.umich.edu [141.211.133.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "aglo", Issuer "CITI Production KCA" (verified OK)) by citi.umich.edu (Postfix) with ESMTP id E28F71BDE1; Tue, 3 Oct 2006 11:33:09 -0400 (EDT) Message-ID: <452282B5.7000708@citi.umich.edu> Date: Tue, 03 Oct 2006 11:33:09 -0400 From: Olga Kornievskaia User-Agent: Thunderbird 1.5.0.7 (X11/20060913) MIME-Version: 1.0 To: saag@mit.edu, kitten@ietf.org, nfsv4@ietf.org, tls@lists.ietf.org, ietf-pkix@imc.org, spkm@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: Subject: [TLS] [67th IETF] SPKM3 BOF announcement X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org We would like to announce the following BOF for the 67th IETF meeting. BOF name: NFSv4 and Low Infrastructure Public Key Based GSS Security Mechanisms Area: Security Area Chair: Jeffrey Hutzelman If this topic is of interest to you please email your questions and concerns to the mail list (spkm@ietf.org). Problem Statement: The NFSv4 protocol has a need for low infrastructure PKI based GSS security mechanism(s) that provide for the creation of a secure channel using mutual authentication where 1) both user and server authenticate with public key certificates 2) server authenticates with public key certificates, and the user authenticates with a username and password. Current State: RFC3530 "Network File System (NFS) version 4 Protocol" mandates the use of RFC2847 "LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM". While RFC2847 fulfills the requirements of the problem statement, there are areas where RFC2847 is outdated and/or underspecified. Futhermore, RFC2847 both replaces and refers to portions of RFC2025 "The Simple Public-Key GSS-API Mechanism (SPKM)" and is confusing to implementers. None the less, there are two implementations (Hummingbird and Linux) based upon RFC2847. draft-adamson-rfc2847-bis-01.txt, an update of RFC2847, is intended to address RFC2847 shortcomings and provide a complete specification that doesn't need [RFC2025] and that replaces [RFC2847]. Agenda: 1) Need for a low infrastructure PK based GSS security mechanism for NFSV4 - what is low infrastructure - existing markets - current implementations 2) draft-adamson-rfc2847-bis-01.txt - issues brought up by IESG review - naming - algorithms - which diffie-hellman - clarify protocol security claims - whole document review - backwards compatibility with RFC2847 based implementations 3) moving forward - finish draft-adamson-rfc2847-bis-01.txt - get draft into shape to submit to for IESG comments. - find reviewers - explore alternative GSS mechanisms _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 04 14:18:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVBIF-00035j-VZ; Wed, 04 Oct 2006 14:16:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVBIE-00035d-Qv for tls@ietf.org; Wed, 04 Oct 2006 14:16:30 -0400 Received: from bay0-omc2-s12.bay0.hotmail.com ([65.54.246.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVBID-0002Rg-07 for tls@ietf.org; Wed, 04 Oct 2006 14:16:30 -0400 Received: from BAY103-W1 ([65.54.174.101]) by bay0-omc2-s12.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Oct 2006 11:16:28 -0700 X-Originating-IP: [67.97.95.201] X-Originating-Email: [home_pw@msn.com] Message-ID: MIME-Version: 1.0 From: "Peter Williams" Subject: RE: [TLS] Follow-up to comments on draft-linn-otp-tls-00 Date: Wed, 4 Oct 2006 11:16:28 -0700 X-OriginalArrivalTime: 04 Oct 2006 18:16:28.0356 (UTC) FILETIME=[35D6B840:01C6E7E1] X-Spam-Score: 2.2 (++) X-Scan-Signature: e5bfa71b340354e384155def5e70b13b Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Content-Type: multipart/mixed; boundary="===============1739351238==" Errors-To: tls-bounces@lists.ietf.org --===============1739351238== Content-Type: multipart/alternative; boundary="_3f261acc-edd3-4b4e-9c38-faa6c3480321_" --_3f261acc-edd3-4b4e-9c38-faa6c3480321_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I see no reason why TLS ciphers/ciphersuites should not facilitate key exc= hange or key derivation based on traditional key stream lookups (e.g. an OT= P algorithm). This is really no different architecturally to the use of UKM= s, in NSA/DoD processes for govt-grade TLS ciphersuites, to vary the the ma= c/enc TEKs formulated by asymmetric processes byuser/bytime. Whereas a mode= rn UKM modifies the process of TEK key derivation by moderating the asymme= tric process generating the DerivedSessionToken, OTP streams could alternat= ively moderate external-time-synced tek generation(s) that do specifically = to NOT rely on asymmetric algorithms. =20 I've already seen this happen in the TLS-like handshakes used in the OASIS = ws-* family, when handling equivalent session token generation processes. = I.e. time synced key derivation processes influencing the TEKs in the deriv= edSessionToken resulting from a SSL-like handshake based on prior _symmetri= c_ key distribution to endpoints, only. The linking of external time to the= keys protecting security contexts of course impacts the evidentiary value = of PDUs. This is arguably far more valuable in internal, (sub)layer 7 secur= ity contexts (the ssl-like xml handshake's flowing over ws-reliablemessagin= g or X.400 RTS in Nato nets), than layer 4 contexts (https/ssl flows over t= cp on the public Internet). =20 > Date: Mon, 2 Oct 2006 11:51:23 +0200> From: magnus@rsasecurity.com> To: t= ls@ietf.org> CC: > Subject: [TLS] Follow-up to comments on draft-linn-otp-t= ls-00> > All,> > I would like to follow-up on some of the comments that Joh= n and I have > received in the past and also received during the TLS sessio= n at the 66th > IETF in Montreal. Firstly, I'd like to thank all the review= ers; we really > appreciate you taking the time.> > Whether to layer on TLS= -PSK or not> ----------------------------------> Several reviewers have sug= gested that it would be architecturally> better if new ciphersuites would b= e defined rather than attempting to> profile/extend TLS-PSK. There seems to= be a few reasons why the> current approach has not been seen as optimal:> = > a) The term "key exchange" in TLS relates to the whole handshake as> oppo= sed to the actual cryptographic key exchange (Pasi Eronen). Since> we're mo= difying the handshake (new extensions, new alerts, ...) it> should follow t= hat this is a new key exchange and hence should define> a new ciphersuite (= or -suites).> > b) Interpretation of certain data (e.g. the psk_identity fi= eld) will> vary depending on whether "ordinary" TLS-PSK is performed or not= ; this> is undesirable as servers will need to be prepared to interpret (an= d> act upon) this field based on information in the Hello exchanges (Eric> = Rescorla).> > I don't quite understand a) above. I don't see that RFC4346 s= ays that the> key exchange defines the whole handshake. But even if this is= the case,> what about some of the extensions defined in RFC 4366, e.g. the= > truncated_hmac one? It seems to me that that extension also modifies the>= behavior of the parties, without introducing new ciphersuites?> > On b) ab= ove, I agree that this is undesirable. One way forward that I> can see - be= sides defining new ciphersuites - would be to introduce> (and require use o= f, when doing a handshake based on OTPs) a new> extension, along the lines = of (obviously the syntax needs to be> corrected):> > OTPHandshakePar= ams otp_handshake_params<0..2^16-1>;>> struct {> OTPAlgor= ithm otp_algorithm;> ChallengeData challenge_data<0..>;> = HardeningData hardening_data<0..>;> KeyIdentifier key_identi= fier<0..>;> UserIdentifier user_identifier<0..>;> } OTPHa= ndshakeParams;> > This approach would allow not only signaling of the inten= t of basing> the exchange on OTPs, but also to negotiate the actual OTP alg= orithm> as well as related parameters. I note that the above should also ta= ke> away the need to change the meaning of the psk_identity field,> somethi= ng we anyway have been recommended not to do.> > What I'd like to ask is if= this mandatory "signaling" of OTP use would> be enough to resolve the conc= erns raised about the layering on top of> the TLS-PSK ciphersuites?> > The = strength of OTPs as a basis for TLS session keys> -------------------------= ---------------------------> There was a discussion about this in Montreal = and I just want to> clarify:> > A typical OTP is 6 - 8 decimal digits long,= although alphanumerical OTPs > are also in use. In addition, some OTP syst= ems employ centralized PINs, > meaning that the user provides a PIN in conj= unction with the OTP. > Typically this would therefore give in the order of= 33 - 40 bits of > entropy. Through hardening, one can increase the resist= ance. For example, > hardening by iterative hashes, as suggested in the cur= rent draft, could > complicate an attack as follows: With 100,000 iteration= s, the work load of > the attacker will be about 17 bits more, in effect ad= ding about 17 bits of > strength (admittedly at a cost for the legit partie= s). For the example > above, this would mean 50 - 57 bits of "entropy". Cle= arly this is less > than even the 80-bit level offered through use of RSA 1= 024-bit keys, and I > agree we could make this fact explicit (e.g. through = some detailed > examples) in the document and also add a recommendation to = use the D-H-PSK > (with normal caveats about MITM) or RSA-PSK variants in t= hese situations. > But I would not want to disallow the "direct" variant, f= or example since > some connected OTP tokens may be able to emit considerab= ly longer OTPs > when in connected mode, and therefore would not need D-H (= or the use of a > PKI with RSA). (Longer OTPs in connected mode do not need= to degrade the > user experience since the user in these cases only enters= the PIN, the OTP > is programmatically retrieved. Long OTPs also eliminate= or at least reduce > the need for "hardening").> > -- Magnus> > > ________= _______________________________________> TLS mailing list> TLS@lists.ietf.o= rg> https://www1.ietf.org/mailman/listinfo/tls _________________________________________________________________ Share your special moments by uploading 500 photos per month to Windows Liv= e Spaces=20 http://clk.atdmt.com/MSN/go/msnnkwsp0100000001msn/direct/01/?href=3Dhttp://= spaces.live.com/signup.aspx = --_3f261acc-edd3-4b4e-9c38-faa6c3480321_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A=

I see no reason why  TLS ciphers/ciphersuites should not= facilitate key exchange or key derivation based on traditional key stream = lookups (e.g. an OTP algorithm). This is really no different architecturall= y to the use of UKMs, in NSA/DoD processes for govt-grade TLS ciphersuites,= to vary the the mac/enc TEKs formulated by asymmetric processes byuser/byt= ime. Whereas a modern UKM modifies the process of TEK key derivation  = by moderating the asymmetric process generating the DerivedSessionToken, OT= P streams could alternatively moderate external-time-synced tek genera= tion(s) that do specifically to NOT rely on asymmetric algorithms.
 
I've already seen this happen in the TLS-like handshakes used in the OASIS = ws-* family, when handling equivalent session token generation process= es.  I.e. time synced key derivation processes influencing the TEKs in the derivedSessionToken resulting from a SSL-like hands= hake based on prior _symmetric_ key distribution to endpoints, only.= The linking of external time to the keys protecting security contexts of c= ourse impacts the evidentiary value of PDUs. This is arguably far more valu= able in internal, (sub)layer 7 security contexts (the ssl-like xml handshak= e's flowing over ws-reliablemessaging or X.400 RTS in Nato nets= ), than layer 4 contexts (https/ssl flows over tcp on th= e public Internet). 



> Date: Mon, 2 Oct 2006 11:51:23 +0200
> From: magnus@rsasecurity.= com
> To: tls@ietf.org
> CC:
> Subject: [TLS] Follow-up = to comments on draft-linn-otp-tls-00
>
> All,
>
>= I would like to follow-up on some of&nb= sp;the comments that John and I have > received in the past and also received&= nbsp;during the TLS session at the 66th =
> IETF in Montreal. Firstly, I'd like = to thank all the reviewers; we really > appreciate you taking the time.
>
>= Whether to layer on TLS-PSK or not
> -= ---------------------------------
> Several reviewers have&= nbsp;suggested that it would be architecturally> better if new ciphersuites would be def= ined rather than attempting to
> profile/extend&n= bsp;TLS-PSK. There seems to be a few rea= sons why the
> current approach has not = ;been seen as optimal:
>
> a) The ter= m "key exchange" in TLS relates to the&n= bsp;whole handshake as
> opposed to the actu= al cryptographic key exchange (Pasi Eronen). = Since
> we're modifying the handshake (new e= xtensions, new alerts, ...) it
> should foll= ow that this is a new key exchange = and hence should define
> a new ciphersuite&= nbsp;(or -suites).
>
> b) Interpretation of&nbs= p;certain data (e.g. the psk_identity field) = will
> vary depending on whether "ordinary" = TLS-PSK is performed or not; this
> is = undesirable as servers will need to be p= repared to interpret (and
> act upon) this&n= bsp;field based on information in the Hello&n= bsp;exchanges (Eric
> Rescorla).
>
> I don't&n= bsp;quite understand a) above. I don't see&nb= sp;that RFC4346 says that the
> key exchange=  defines the whole handshake. But even i= f this is the case,
> what about some&n= bsp;of the extensions defined in RFC 4366,&nb= sp;e.g. the
> truncated_hmac one? It seems t= o me that that extension also modifies t= he
> behavior of the parties, without introd= ucing new ciphersuites?
>
> On b) above,&n= bsp;I agree that this is undesirable. One&nbs= p;way forward that I
> can see - beside= s defining new ciphersuites - would be t= o introduce
> (and require use of, when = ;doing a handshake based on OTPs) a new<= BR>> extension, along the lines of (obviously&n= bsp;the syntax needs to be
> corrected):
> =
>        OTPHandshakeParams = otp_handshake_params<0..2^16-1>;>
>     =    struct {
>       = ;     OTPAlgorithm otp_algorithm;
> &nb= sp;          ChallengeDat= a challenge_data<0..>;
>      &nb= sp;     HardeningData hardening_data<0..&g= t;;
>           &nb= sp;KeyIdentifier key_identifier<0..>;
>    =         UserIdentifier user_id= entifier<0..>;
>        }&nb= sp;OTPHandshakeParams;
>
> This approach would = allow not only signaling of the intent o= f basing
> the exchange on OTPs, but al= so to negotiate the actual OTP algorithm
&= gt; as well as related parameters. I note&nbs= p;that the above should also take
> away&nbs= p;the need to change the meaning of the&= nbsp;psk_identity field,
> something we anyway ha= ve been recommended not to do.
>
> Wh= at I'd like to ask is if this manda= tory "signaling" of OTP use would
> be = enough to resolve the concerns raised about&n= bsp;the layering on top of
> the TLS-PSK&nbs= p;ciphersuites?
>
> The strength of OTPs a= s a basis for TLS session keys
> ------= ----------------------------------------------
> There was = a discussion about this in Montreal and = I just want to
> clarify:
>
> A typi= cal OTP is 6 - 8 decimal digits lon= g, although alphanumerical OTPs 
> are also&= nbsp;in use. In addition, some OTP systems&nb= sp;employ centralized PINs, 
> meaning that = the user provides a PIN in conjunction w= ith the OTP. 
> Typically this would th= erefore give in the order of 33 - 4= 0 bits of 
> entropy.  Through hardenin= g, one can increase the resistance. For = example, 
> hardening by iterative hashes, a= s suggested in the current draft, could =
> complicate an attack as follows: With&nbs= p;100,000 iterations, the work load of 
&g= t; the attacker will be about 17 bits mo= re, in effect adding about 17 bits of&nb= sp;
> strength (admittedly at a cost for&nbs= p;the legit parties). For the example 
>= ; above, this would mean 50 - 57 bits&nb= sp;of "entropy". Clearly this is less 
>= ; than even the 80-bit level offered through&= nbsp;use of RSA 1024-bit keys, and I > agree we could make this fact explicit&= nbsp;(e.g. through some detailed 
> examples)&nbs= p;in the document and also add a recomme= ndation to use the D-H-PSK 
> (with nor= mal caveats about MITM) or RSA-PSK variants&n= bsp;in these situations. 
> But I would = ;not want to disallow the "direct" variant,&n= bsp;for example since 
> some connected OTP&= nbsp;tokens may be able to emit considerably&= nbsp;longer OTPs 
> when in connected mode,&= nbsp;and therefore would not need D-H (or&nbs= p;the use of a 
> PKI with RSA). (= Longer OTPs in connected mode do not nee= d to degrade the 
> user experience sin= ce the user in these cases only enters&n= bsp;the PIN, the OTP 
> is programmatically&= nbsp;retrieved. Long OTPs also eliminate or a= t least reduce 
> the need for "hardeni= ng").
>
> -- Magnus
>
>
> ___________= ____________________________________
> TLS mailing list
= > TLS@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls<= BR>

Share your special moments by uploading 500 photos per m= onth to Windows Live Spaces Share it!=0A= = --_3f261acc-edd3-4b4e-9c38-faa6c3480321_-- --===============1739351238== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============1739351238==-- From tls-bounces@lists.ietf.org Wed Oct 04 18:51:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVFZ8-0006uK-NY; Wed, 04 Oct 2006 18:50:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVFYz-0006nW-9a; Wed, 04 Oct 2006 18:50:05 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVFYw-0002BU-F9; Wed, 04 Oct 2006 18:50:05 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id 6C0463288F; Wed, 4 Oct 2006 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GVFYw-0002l8-9V; Wed, 04 Oct 2006 18:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 04 Oct 2006 18:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-psk-null-02.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Pre-Shared Key Cipher Suites with NULL Encryption for Transport Layer Security (TLS) Author(s) : U. Blumenthal, P. Goel Filename : draft-ietf-tls-psk-null-02.txt Pages : 5 Date : 2006-10-4 This document specifies authentication-only cipher suites for the Pre-Shared Key based Transport Layer Security (TLS) protocol to support null encryption. These cipher suites are useful for countries and places with cryptography-related restrictions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-null-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-psk-null-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-psk-null-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-4151807.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-psk-null-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-psk-null-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-4151807.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@lists.ietf.org Thu Oct 05 14:54:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVYKC-0006nA-QP; Thu, 05 Oct 2006 14:52:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVYKA-0006mk-0Y; Thu, 05 Oct 2006 14:52:02 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVYK9-0006Xc-Ux; Thu, 05 Oct 2006 14:52:01 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GVYK8-0000WG-Mu; Thu, 05 Oct 2006 14:52:01 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 6F016175A5; Thu, 5 Oct 2006 18:51:30 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GVYJe-000701-1c; Thu, 05 Oct 2006 14:51:30 -0400 X-test-idtracker: no To: IETF-Announce From: The IESG Message-Id: Date: Thu, 05 Oct 2006 14:51:30 -0400 X-Spam-Score: -2.8 (--) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: tls@ietf.org Subject: [TLS] Last Call: 'Pre-Shared Key Cipher Suites with NULL Encryption for Transport Layer Security (TLS)' to Proposed Standard (draft-ietf-tls-psk-null) X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: iesg@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: , Errors-To: tls-bounces@lists.ietf.org The IESG has received a request from the Transport Layer Security WG to consider the following document: - 'Pre-Shared Key Cipher Suites with NULL Encryption for Transport Layer Security (TLS)' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. The IESG is especially interested in feedback about this document being published as a Standards Track RFC or an Informational RFC. The TLS WG as asked for publication as a Standards Track RFC, and the IESG would like to know if you think this is the correct course of action or if you think it is more appropriate to publish as an Informational RFC. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-10-19. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-null-02.txt _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Oct 17 03:03:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZixI-0004qH-A4; Tue, 17 Oct 2006 03:01:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZixD-0004Ol-8N for tls@ietf.org; Tue, 17 Oct 2006 03:01:35 -0400 Received: from groucho.itss.auckland.ac.nz ([130.216.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZitE-0008D1-4R for tls@ietf.org; Tue, 17 Oct 2006 02:57:29 -0400 Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by groucho.itss.auckland.ac.nz (Postfix) with ESMTP id 233043578F; Tue, 17 Oct 2006 19:57:23 +1300 (NZDT) Received: from groucho.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 23451-20; Tue, 17 Oct 2006 19:57:22 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by groucho.itss.auckland.ac.nz (Postfix) with ESMTP id BF0DE348DF; Tue, 17 Oct 2006 19:57:22 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id BF09B37744; Tue, 17 Oct 2006 19:57:22 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1GZitF-0006Cb-00; Tue, 17 Oct 2006 19:57:29 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: david.nospam.hopwood@blueyonder.co.uk Subject: Re: [TLS] PRF in TLS 1.2 In-Reply-To: <451BF1AF.1040405@blueyonder.co.uk> Message-Id: Date: Tue, 17 Oct 2006 19:57:29 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.5 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org David Hopwood writes: >I don't see what the motivation is for changing the PRF at all. > >Sure, it's an inelegant construction, but that's not important. What he said :-). (Apologies for the time-warp reply, I've been travelling with no net access). Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Oct 17 15:40:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZulV-0000MV-Ts; Tue, 17 Oct 2006 15:38:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZulU-0000MO-V7 for tls@ietf.org; Tue, 17 Oct 2006 15:38:16 -0400 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZulS-0002P1-KG for tls@ietf.org; Tue, 17 Oct 2006 15:38:16 -0400 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id ACB695C01E for ; Tue, 17 Oct 2006 12:41:09 -0700 (PDT) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19) Date: Tue, 17 Oct 2006 12:38:11 -0700 From: Eric Rescorla Message-Id: <20061017194109.ACB695C01E@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: Subject: [TLS] Open issue: Record Version Numbers X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Yngve Petterson has pointed out [0] that there is some confusion in how to interpret what version numbers ought to appear in the ClientHello record in TLS handshakes. The issue is that there are two numbers: - the record version number - the client hello version number The text is quite clear that the second of these should be the highest version you support. However, the text for the secodn reads: "TLS clients who wish to negotiate with SSL 3.0 servers should send client hello messages using the SSL 3.0 record format and client hello structure, sending {3, 1} for the version field to note that they support TLS 1.0". I read this text as saying that if you are a client who supports TLS 1.0 and SSLv3, you should in general send the following values: - record version number {3, 0} (SSLv3) - client hello version number {3, 1} (TLSv1) If the server decides to accept TLS 1.0, it should respond with the following values: - record version number {3, 1} (TLSv1) - client hello version number {3, 1} (TLSv1) Pettersen reports that in some cases this causes errors because servers (inexplicably) use the record version in the negotiation. However, I think at the end of the day, that's a clear implementation error and the spec should just clarify that the above behavior is what's expected. Comments? -Ekr [0] draft-ietf-pettersen-tls-interop-experience-00 (soon to be a TLS-WG draft but not published that way yet). _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Oct 17 15:45:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZusM-0006T1-OP; Tue, 17 Oct 2006 15:45:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZusL-0006Nm-Mc for tls@ietf.org; Tue, 17 Oct 2006 15:45:21 -0400 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZusK-0003b5-CZ for tls@ietf.org; Tue, 17 Oct 2006 15:45:21 -0400 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id EE0715C01E for ; Tue, 17 Oct 2006 12:48:17 -0700 (PDT) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19) Date: Tue, 17 Oct 2006 12:45:20 -0700 From: Eric Rescorla Message-Id: <20061017194817.EE0715C01E@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: Subject: [TLS] Open Issue: verify_data processing X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Stipulating for the moment that we intend to replace the PRF, we're left with the issue of how to compute the verify_data. Currently, the verify_data is computed as: PRF(master_secret, finished_label, MD5(handshake_messages) + SHA-1(handshake_messages)) [0..11]; If you're not using MD5 for your PRF, it doesn't make sense to use it here either. This leaves us with two possibilities: 1. PRF the handshake_messages directly. 2. Hash them first. The argument for hashing them first is that it avoids having to store them (2-5k) for the entire handshake. It also will accomodate PRFs which won't take unlimited size data. The argument against is that it puts the security of the handshake on an unkeyed hash rather than a MAC (since you only need to mount a 2nd preimage attack on the hash and then you have 2nd preimage on MAC(K,hash).). My preference here would be to move to PRF(messages) and if new PRFs can't cope with that then they can specify a hash reduction of their own. Recall that the PRF needs to be able to deal with fairly large data anyway since the PMS + randoms could easily be 300+ bytes... Comments? -Ekr P.S. Please don't use this thread to say you don't want to replace the PRF at all. The only question here is what we do if *do* replace the PRF. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Oct 17 17:25:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZwQB-0006lY-Sr; Tue, 17 Oct 2006 17:24:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZwQB-0006lT-HK for tls@ietf.org; Tue, 17 Oct 2006 17:24:23 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZwQA-0005aU-5x for tls@ietf.org; Tue, 17 Oct 2006 17:24:23 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 6E3BB1E8C28; Tue, 17 Oct 2006 14:24:21 -0700 (PDT) To: tls@ietf.org Subject: Re: [TLS] Open issue: Record Version Numbers References: <20061017194109.ACB695C01E@laser.networkresonance.com> From: Eric Rescorla Date: Tue, 17 Oct 2006 14:24:21 -0700 In-Reply-To: <20061017194109.ACB695C01E@laser.networkresonance.com> (Eric Rescorla's message of "Tue, 17 Oct 2006 12:38:11 -0700") Message-ID: <867iyyws8q.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR 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: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla writes: > Yngve Petterson has pointed out [0] that there is some confusion > in how to interpret what version numbers ought to appear in > the ClientHello record in TLS handshakes. The issue is that > there are two numbers: > > - the record version number > - the client hello version number > > The text is quite clear that the second of these should be the > highest version you support. However, the text for the secodn > reads: I had it pointed out to me in private that these are contradictory. This should read: The text is quite clear that the second of these should be the highest version you support. However, the text for the first reads: > "TLS clients who wish > to negotiate with SSL 3.0 servers should send client hello messages > using the SSL 3.0 record format and client hello structure, sending > {3, 1} for the version field to note that they support TLS 1.0". > > I read this text as saying that if you are a client who supports TLS 1.0 > and SSLv3, you should in general send the following values: > > - record version number {3, 0} (SSLv3) > - client hello version number {3, 1} (TLSv1) > > If the server decides to accept TLS 1.0, it should respond with the > following values: > > - record version number {3, 1} (TLSv1) > - client hello version number {3, 1} (TLSv1) > > Pettersen reports that in some cases this causes errors because servers > (inexplicably) use the record version in the negotiation. However, I > think at the end of the day, that's a clear implementation error > and the spec should just clarify that the above behavior is what's > expected. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Oct 17 17:51:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZwox-00055q-Ua; Tue, 17 Oct 2006 17:49:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZwow-00055g-Re for tls@ietf.org; Tue, 17 Oct 2006 17:49:58 -0400 Received: from smtp.microsoft.com ([131.107.115.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZwor-0008BC-B9 for tls@ietf.org; Tue, 17 Oct 2006 17:49:58 -0400 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.665.7; Tue, 17 Oct 2006 14:49:53 -0700 Received: from tuk-hub-02.redmond.corp.microsoft.com ([157.54.70.28]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 14:49:52 -0700 Received: from tk5-exhub-c104.redmond.corp.microsoft.com ([157.54.70.185]) by tuk-hub-02.redmond.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Oct 2006 14:49:51 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) with Microsoft SMTP Server id 8.0.665.7; Tue, 17 Oct 2006 14:49:38 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Tue, 17 Oct 2006 14:49:38 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 17 Oct 2006 14:49:32 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 3456 - OCSP extension question Thread-Index: AcbyNiE3G7cz47SWTsCVYPsd5ouKwQ== From: Joshua Ball To: X-OriginalArrivalTime: 17 Oct 2006 21:49:38.0810 (UTC) FILETIME=[24E9DDA0:01C6F236] X-Spam-Score: 0.0 (/) X-Scan-Signature: 71f780ffdd80c541d3e75aa5f2710d3d Cc: Subject: [TLS] RFC 3456 - OCSP extension question X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Content-Type: multipart/mixed; boundary="===============0100385464==" Errors-To: tls-bounces@lists.ietf.org --===============0100385464== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6F236.21885A9C" ------_=_NextPart_001_01C6F236.21885A9C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In regards to the implementation of RFC 3546, in particular the OCSP = extension. When the client does not wish to send any list of responders, = what is the correct sequence to send (as a zero length vector apparently = has a special meaning). It would appear (with my na=EFve understanding = of RFC 2560) that it would be a list of ResponderID's (from RFC2560). = But ResponderID's are CHOICE's, and I am not versed in my ASN.1 enough = to know if there is a way to write zero of these). =20 So what are the ASN.1 and DER of the correct response for no list. = Thanks. =20 struct { CertificateStatusType status_type; select (status_type) { case ocsp: OCSPStatusRequest; } request; } CertificateStatusRequest; =20 enum { ocsp(1), (255) } CertificateStatusType; =20 struct { ResponderID responder_id_list<0..2^16-1>; Extensions request_extensions; } OCSPStatusRequest; =20 opaque ResponderID<1..2^16-1>; opaque Extensions<0..2^16-1>; =20 In the OCSPStatusRequest, the "ResponderIDs" provides a list of OCSP responders that the client trusts. A zero-length "responder_id_list" sequence has the special meaning that the responders are implicitly known to the server - e.g., by prior arrangement. "Extensions" is a DER encoding of OCSP request extensions. =20 Both "ResponderID" and "Extensions" are DER-encoded ASN.1 types as defined in [OCSP]. "Extensions" is imported from [PKIX]. A zero- length "request_extensions" value means that there are no extensions (as opposed to a zero-length ASN.1 SEQUENCE, which is not valid for the "Extensions" type). =20 =20 ------_=_NextPart_001_01C6F236.21885A9C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

In regards to the implementation of RFC 3546, in = particular the OCSP extension. When the client does not wish to send any list of responders, what is the correct sequence to send (as a zero length = vector apparently has a special meaning). It would appear (with my na=EFve = understanding of RFC 2560) that it would be a list of ResponderID’s (from = RFC2560). But ResponderID’s are CHOICE’s, and I am not versed in my ASN.1 = enough to know if there is a way to write zero of these).

 

So what are the ASN.1 and DER of the correct = response for no list. Thanks.

 

=A0=A0=A0=A0=A0 struct {

=A0=A0=A0=A0=A0=A0=A0=A0=A0 CertificateStatusType = status_type;

=A0=A0=A0=A0=A0=A0=A0=A0=A0 select (status_type) = {

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 case ocsp: = OCSPStatusRequest;

=A0=A0=A0=A0=A0=A0=A0=A0=A0 } = request;

=A0=A0=A0=A0=A0 } = CertificateStatusRequest;

 

=A0=A0=A0=A0=A0 enum { ocsp(1), (255) } = CertificateStatusType;

 

=A0=A0=A0=A0=A0 struct {

=A0=A0=A0=A0=A0=A0=A0=A0=A0 ResponderID = responder_id_list<0..2^16-1>;

=A0=A0=A0=A0=A0=A0=A0=A0=A0 Extensions=A0 = request_extensions;

=A0=A0=A0=A0=A0 } OCSPStatusRequest;

 

=A0=A0=A0=A0=A0 opaque = ResponderID<1..2^16-1>;

=A0=A0=A0=A0=A0 opaque = Extensions<0..2^16-1>;

 

=A0=A0 In the OCSPStatusRequest, the = "ResponderIDs" provides a list of OCSP

=A0=A0 responders that the client trusts.=A0 A = zero-length "responder_id_list"

=A0=A0 sequence has the special meaning that the = responders are implicitly

=A0=A0 known to the server - e.g., by prior = arrangement.=A0 "Extensions" is a

=A0=A0 DER encoding of OCSP request = extensions.

 

=A0=A0 Both "ResponderID" and = "Extensions" are DER-encoded ASN.1 types as

=A0=A0 defined in [OCSP].=A0 "Extensions" = is imported from [PKIX].=A0 A zero-

=A0=A0 length "request_extensions" value = means that there are no extensions

=A0=A0 (as opposed to a zero-length ASN.1 SEQUENCE, = which is not valid for

=A0=A0 the "Extensions" = type).

 

 

------_=_NextPart_001_01C6F236.21885A9C-- --===============0100385464== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============0100385464==-- From tls-bounces@lists.ietf.org Tue Oct 17 17:56:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZwut-0004QZ-GN; Tue, 17 Oct 2006 17:56:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GZwur-0004QU-Of for tls@ietf.org; Tue, 17 Oct 2006 17:56:05 -0400 Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GZwuo-0000dI-Gf for tls@ietf.org; Tue, 17 Oct 2006 17:56:05 -0400 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k9HLu0h0002225 for ; Tue, 17 Oct 2006 17:56:00 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id k9HLtxLZ030744 for ; Tue, 17 Oct 2006 17:55:59 -0400 Received: from [127.0.0.1] (dhcp-172-16-25-208.sfbay.redhat.com [172.16.25.208]) by potter.sfbay.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k9HLtuu5016023 for ; Tue, 17 Oct 2006 17:55:58 -0400 Message-ID: <4535516B.2050401@redhat.com> Date: Tue, 17 Oct 2006 14:55:55 -0700 From: Wan-Teh Chang User-Agent: Thunderbird 2.0b1pre (Windows/20061016) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Open Issue: verify_data processing References: <20061017194817.EE0715C01E@laser.networkresonance.com> In-Reply-To: <20061017194817.EE0715C01E@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Content-Type: multipart/mixed; boundary="===============0826159464==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0826159464== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090407020006020109080106" This is a cryptographically signed message in MIME format. --------------ms090407020006020109080106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Eric Rescorla wrote: > > The argument against is that it puts the security of the > handshake on an unkeyed hash rather than a MAC (since > you only need to mount a 2nd preimage attack on the hash > and then you have 2nd preimage on MAC(K,hash).). You can use this argument against RSA, DSA, and ECDSA signatures, too. My preference is to hash the handshake_messages first. The issue isn't that new PRFs can't cope with large data. The issue is the new burden on TLS implementations to buffer data of an indefinite length. Also consider the memory usage of a busy TLS server that has a lot of handshakes in progress. Wan-Teh --------------ms090407020006020109080106 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKWDCC BSgwggQQoAMCAQICECPc+9+WtsOZqiiOT1eYr6cwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMR0wGwYDVQQLExRBZGRUcnVzdCBUVFAgTmV0 d29yazEhMB8GA1UEAxMYQWRkVHJ1c3QgQ2xhc3MgMSBDQSBSb290MB4XDTA1MTIyMzAwMDAw MFoXDTA2MTIyMzIzNTk1OVowgdsxNTAzBgNVBAsTLENvbW9kbyBUcnVzdCBOZXR3b3JrIC0g UEVSU09OQSBOT1QgVkFMSURBVEVEMUYwRAYDVQQLEz1UZXJtcyBhbmQgQ29uZGl0aW9ucyBv ZiB1c2U6IGh0dHA6Ly93d3cuY29tb2RvLm5ldC9yZXBvc2l0b3J5MR8wHQYDVQQLExYoYyky MDAzIENvbW9kbyBMaW1pdGVkMRYwFAYDVQQDEw1XYW4tVGVoIENoYW5nMSEwHwYJKoZIhvcN AQkBFhJ3dGNoYW5nQHJlZGhhdC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJZ3 pYgLLfB2IU5Rdd4B/1Z7p391Z+vjH2pCEeQMWxK966ptunHqLmA8Iz/8Tiy5KN9LKRkV9Q2c zvWjapJeyiutrictOZCY2qkRMG6eTbDDT8Tz6qO7iRnUK7JkXs2cZtlk442Xgky+xcLr1cCC RJ8w3d/ul4HKdGZwtsYFLkLpAgMBAAGjggHfMIIB2zAdBgNVHQ4EFgQUAsOMfMcFVfub10xu 3ycfUWaYHO4wDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYB BQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsG AQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQ UzB3BgNVHR8EcDBuMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRUcnVzdENs YXNzMUNBUm9vdC5jcmwwNKAyoDCGLmh0dHA6Ly9jcmwuY29tb2RvLm5ldC9BZGRUcnVzdENs YXNzMUNBUm9vdC5jcmwwgYYGCCsGAQUFBwEBBHoweDA7BggrBgEFBQcwAoYvaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQWRkVHJ1c3RVVE5DbGllbnRDQS5jcnQwOQYIKwYBBQUHMAKGLWh0 dHA6Ly9jcnQuY29tb2RvLm5ldC9BZGRUcnVzdFVUTkNsaWVudENBLmNydDAdBgNVHREEFjAU gRJ3dGNoYW5nQHJlZGhhdC5jb20wDQYJKoZIhvcNAQEFBQADggEBAGpDustBazwJLV/u3OHE gGKhU5QxPPnhJcAs4hPn6oG2de85pKS9/mioaEhf1Huvu8cBaEMIe0dQoGQuqOIiM38WFXRI N4m0SoTu2pw4MXIy9t20kNiqq0ISf/O+kLJ6QrIsRurqw7WexkGkv8S4Z+hgls1wFXTBFsnu vZsgqqtDc2s6EHMh9Wqk4WWCMsr8WExtsst5pnLWHV7BbiquqHrbFZhwRLiWjVrBNDrVT+ym lmZilFt8GHjdrJs3aLvuptP+yzDqIE0jFtlVNn5gLzYSKMMx8twn9yJTHCC2AwAbfmGNf75o yPCS8MqAqupN2B+oST9MqdF6ZpVcxVdR61QwggUoMIIEEKADAgECAhAj3PvflrbDmaoojk9X mK+nMA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBB QjEdMBsGA1UECxMUQWRkVHJ1c3QgVFRQIE5ldHdvcmsxITAfBgNVBAMTGEFkZFRydXN0IENs YXNzIDEgQ0EgUm9vdDAeFw0wNTEyMjMwMDAwMDBaFw0wNjEyMjMyMzU5NTlaMIHbMTUwMwYD VQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQG A1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UE AxMNV2FuLVRlaCBDaGFuZzEhMB8GCSqGSIb3DQEJARYSd3RjaGFuZ0ByZWRoYXQuY29tMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCWd6WICy3wdiFOUXXeAf9We6d/dWfr4x9qQhHk DFsSveuqbbpx6i5gPCM//E4suSjfSykZFfUNnM71o2qSXsorra4nLTmQmNqpETBunk2ww0/E 8+qju4kZ1CuyZF7NnGbZZOONl4JMvsXC69XAgkSfMN3f7peBynRmcLbGBS5C6QIDAQABo4IB 3zCCAdswHQYDVR0OBBYEFALDjHzHBVX7m9dMbt8nH1FmmBzuMA4GA1UdDwEB/wQEAwIFoDAM BgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYd aHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwdwYDVR0fBHAwbjA2oDSgMoYwaHR0cDov L2NybC5jb21vZG9jYS5jb20vQWRkVHJ1c3RDbGFzczFDQVJvb3QuY3JsMDSgMqAwhi5odHRw Oi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1c3RDbGFzczFDQVJvb3QuY3JsMIGGBggrBgEFBQcB AQR6MHgwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0FkZFRydXN0VVRO Q2xpZW50Q0EuY3J0MDkGCCsGAQUFBzAChi1odHRwOi8vY3J0LmNvbW9kby5uZXQvQWRkVHJ1 c3RVVE5DbGllbnRDQS5jcnQwHQYDVR0RBBYwFIESd3RjaGFuZ0ByZWRoYXQuY29tMA0GCSqG SIb3DQEBBQUAA4IBAQBqQ7rLQWs8CS1f7tzhxIBioVOUMTz54SXALOIT5+qBtnXvOaSkvf5o qGhIX9R7r7vHAWhDCHtHUKBkLqjiIjN/FhV0SDeJtEqE7tqcODFyMvbdtJDYqqtCEn/zvpCy ekKyLEbq6sO1nsZBpL/EuGfoYJbNcBV0wRbJ7r2bIKqrQ3NrOhBzIfVqpOFlgjLK/FhMbbLL eaZy1h1ewW4qrqh62xWYcES4lo1awTQ61U/sppZmYpRbfBh43aybN2i77qbT/ssw6iBNIxbZ VTZ+YC82EijDMfLcJ/ciUxwgtgMAG35hjX++aMjwkvDKgKrqTdgfqEk/TKnRemaVXMVXUetU MYIC7DCCAugCAQEweTBlMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxHTAb BgNVBAsTFEFkZFRydXN0IFRUUCBOZXR3b3JrMSEwHwYDVQQDExhBZGRUcnVzdCBDbGFzcyAx IENBIFJvb3QCECPc+9+WtsOZqiiOT1eYr6cwCQYFKw4DAhoFAKCCAckwGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMDE3MjE1NTU1WjAjBgkqhkiG9w0B CQQxFgQUOY6TEtyV21i+J0/uzNUBDUZhBxYwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0 IEFCMR0wGwYDVQQLExRBZGRUcnVzdCBUVFAgTmV0d29yazEhMB8GA1UEAxMYQWRkVHJ1c3Qg Q2xhc3MgMSBDQSBSb290AhAj3PvflrbDmaoojk9XmK+nMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMR0wGwYDVQQLExRBZGRUcnVz dCBUVFAgTmV0d29yazEhMB8GA1UEAxMYQWRkVHJ1c3QgQ2xhc3MgMSBDQSBSb290AhAj3Pvf lrbDmaoojk9XmK+nMA0GCSqGSIb3DQEBAQUABIGAJmEQfTZSRV4Fb7FeRY+DBMTMPwnZZt6D KYe+zvsDfHtLrEBMRjAMtdD+MAQuIHQXQ2FAVqjoqarL3shU5cOSYR4xuSc8+dLG4TXruj7T 8WqHSApBd9Evd8QnAI+mQeA8FL1mjvlF3V45lXNglCbCypqh7tVKYV3ZLqqgUKQGw/oAAAAA AAA= --------------ms090407020006020109080106-- --===============0826159464== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============0826159464==-- From tls-bounces@lists.ietf.org Tue Oct 17 22:58:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga1cD-0000En-EM; Tue, 17 Oct 2006 22:57:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga1cC-0000Ei-FQ for tls@ietf.org; Tue, 17 Oct 2006 22:57:08 -0400 Received: from dyn50.sunlabs.com ([204.153.12.50] helo=mail-mta.sunlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga1c9-0002qG-50 for tls@ietf.org; Tue, 17 Oct 2006 22:57:08 -0400 Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0J7B007539IQ1Z00@dps.sfvic.sunlabs.com> for tls@ietf.org; Tue, 17 Oct 2006 19:56:50 -0700 (PDT) Received: from [10.0.1.2] ([67.161.29.104]) by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0J7B00KFL9IOAF20@mail.sunlabs.com> for tls@ietf.org; Tue, 17 Oct 2006 19:56:48 -0700 (PDT) Date: Tue, 17 Oct 2006 19:56:48 -0700 From: Vipul Gupta Subject: Re: [TLS] Open Issue: verify_data processing In-reply-to: <4535516B.2050401@redhat.com> To: tls mailing list Message-id: <769A35F3-CC26-4EF8-A523-81D35E359836@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT References: <20061017194817.EE0715C01E@laser.networkresonance.com> <4535516B.2050401@redhat.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Vipul Gupta X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Oct 17, 2006, at 2:55 PM, Wan-Teh Chang wrote: > Eric Rescorla wrote: >> The argument against is that it puts the security of the handshake >> on an unkeyed hash rather than a MAC (since you only need to mount >> a 2nd preimage attack on the hash >> and then you have 2nd preimage on MAC(K,hash).). > > You can use this argument against RSA, DSA, and ECDSA > signatures, too. > > My preference is to hash the handshake_messages first. > The issue isn't that new PRFs can't cope with large data. > The issue is the new burden on TLS implementations to buffer > data of an indefinite length. Also consider the memory usage > of a busy TLS server that has a lot of handshakes in progress. > > Wan-Teh I would also prefer hashing. Our research team has successfully created a TLS stack for tiny, wireless sensor devices like the Berkeley "motes" with only 4KB of RAM (see http://research.sun.com/spotlight/2004-12-20_vgupta.html http://research.sun.com/projects/crypto/guptav_sizzle_pmc.pdf). If the spec were modified to require storing the handshake messages in full, then TLS (and derivatives like DTLS) would pretty much be ruled out for this emerging class of devices. vipul _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 18 07:25:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga9Wq-00056L-AD; Wed, 18 Oct 2006 07:24:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ga9Wo-00056F-W4 for tls@ietf.org; Wed, 18 Oct 2006 07:24:06 -0400 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ga9Wm-000425-If for tls@ietf.org; Wed, 18 Oct 2006 07:24:06 -0400 Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id k9IBNe6i017289 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 18 Oct 2006 13:23:41 +0200 From: Simon Josefsson To: Vipul Gupta References: <20061017194817.EE0715C01E@laser.networkresonance.com> <4535516B.2050401@redhat.com> <769A35F3-CC26-4EF8-A523-81D35E359836@sun.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:061018:vipul.gupta@sun.com::uOXa2bZllvx5DxP8:uc7 X-Hashcash: 1:22:061018:tls@ietf.org::Up1aw/HPyzAIzr3S:nFAf Date: Wed, 18 Oct 2006 13:23:40 +0200 In-Reply-To: <769A35F3-CC26-4EF8-A523-81D35E359836@sun.com> (Vipul Gupta's message of "Tue\, 17 Oct 2006 19\:56\:48 -0700") Message-ID: <871wp5oojn.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: tls mailing list Subject: [TLS] Re: Open Issue: verify_data processing X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Vipul Gupta writes: > On Oct 17, 2006, at 2:55 PM, Wan-Teh Chang wrote: > >> Eric Rescorla wrote: >>> The argument against is that it puts the security of the handshake >>> on an unkeyed hash rather than a MAC (since you only need to mount >>> a 2nd preimage attack on the hash >>> and then you have 2nd preimage on MAC(K,hash).). >> >> You can use this argument against RSA, DSA, and ECDSA >> signatures, too. >> >> My preference is to hash the handshake_messages first. >> The issue isn't that new PRFs can't cope with large data. >> The issue is the new burden on TLS implementations to buffer >> data of an indefinite length. Also consider the memory usage >> of a busy TLS server that has a lot of handshakes in progress. >> >> Wan-Teh > > I would also prefer hashing. Our research team has successfully > created a TLS stack for tiny, wireless sensor devices like the > Berkeley "motes" with only 4KB of RAM (see > http://research.sun.com/spotlight/2004-12-20_vgupta.html > http://research.sun.com/projects/crypto/guptav_sizzle_pmc.pdf). > If the spec were modified to require storing the handshake messages > in full, then TLS (and derivatives like DTLS) would pretty much > be ruled out for this emerging class of devices. One idea would be to make it possible to negotiate whether to hash the handshake messages or not. Perhaps by having the ciphersuite implies that a particular PRF is used with or without hashing. Personally, I would prefer to use the entire handshake messages as input to the PRF, but I agree that you have a compelling argument to hash them. /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 18 08:03:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaA8T-0006Ht-TX; Wed, 18 Oct 2006 08:03:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaA8S-0006Ho-Gy for tls@ietf.org; Wed, 18 Oct 2006 08:03:00 -0400 Received: from moutng.kundenserver.de ([212.227.126.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaA8R-000197-1A for tls@ietf.org; Wed, 18 Oct 2006 08:03:00 -0400 Received: from [80.142.189.152] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1GaA8O2hNU-0003OR; Wed, 18 Oct 2006 14:02:57 +0200 Received: by tau.invalid (Postfix, from userid 1000) id 4EC434D57; Wed, 18 Oct 2006 14:02:55 +0200 (CEST) Date: Wed, 18 Oct 2006 14:02:55 +0200 From: Bodo Moeller To: Eric Rescorla Subject: Re: [TLS] Open issue: Record Version Numbers Message-ID: <20061018120254.GA14826@tau.invalid> References: <20061017194109.ACB695C01E@laser.networkresonance.com> <867iyyws8q.fsf@raman.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <867iyyws8q.fsf@raman.networkresonance.com> User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org > Eric Rescorla writes: >> Yngve Petterson has pointed out [0] that there is some confusion >> in how to interpret what version numbers ought to appear in >> the ClientHello record in TLS handshakes. [...] >> "TLS clients who wish >> to negotiate with SSL 3.0 servers should send client hello messages >> using the SSL 3.0 record format and client hello structure, sending >> {3, 1} for the version field to note that they support TLS 1.0". >> >> I read this text as saying that if you are a client who supports TLS 1.0 >> and SSLv3, you should in general send the following values: >> >> - record version number {3, 0} (SSLv3) >> - client hello version number {3, 1} (TLSv1) >> >> If the server decides to accept TLS 1.0, it should respond with the >> following values: >> >> - record version number {3, 1} (TLSv1) >> - client hello version number {3, 1} (TLSv1) >> >> Pettersen reports that in some cases this causes errors because servers >> (inexplicably) use the record version in the negotiation. However, I >> think at the end of the day, that's a clear implementation error >> and the spec should just clarify that the above behavior is what's >> expected. I agree that, by the wording of the specification, clients in this setting should send {3, 0} as record version number and {3, 1} as client hello version number, and that it is a clear implementation error if servers do not properly handle this. However, since there *are* servers showing this bug, it is reasonable for clients to send {3, 1} for both the record version number and the client hello version number. (The specification text only says "should", not "MUST".) I don't agree that the RFCs are totally clear about the situation: for example, RFC 2246 says "a TLS server which wishes to interoperate with SSL 3.0 clients should accept SSL 3.0 client hello messages", but does not say that TLS servers who do *not* wish to interoperate with TLS 3.0 clients should accept SSL 3.0 client hello messages anyway (since the actual client hello protocol version may be TLS 1.0). This requirement is a logical consequence if we want the protocol to work, but this is something that should be worked out in the specification and not left for implementors to derive. The wording in RFC 4346 (TLS 1.1) is even less clear because it does not mention the TLS 1.0 backwards compatibility case. The proper way to resolve the situation appears to be: - Clients MAY (not "should") use the lowest supported protocol version for the record version number, and must use the highest supported protocol version for the client hello version number. - Servers MUST accept any {3, ??} record version number for the client hello and interpret the client hello message according to their supported protocol versions. If the client hello version number denotes a protocol version supported by the server, use this version. Otherwise, if the client hello version number is higher than any protocol version supported by the server, use the maximum protocol version supported by the server. In this case, if the client hello version number is different from the client's record version number, then the server MAY send a fatal protocol_version alert if this server protocol version is below both the client hello version number and the client's record version number. With this rule, servers can use the information conveyed in the record version number / client hello version number combination if there is some useful information (i.e. if the client is using the record version number to provide the least protocol version supported), but still no harm is done if clients send the client hello version number as record version number to avoid confusing buggy servers. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 18 10:49:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaCi1-00063V-Ca; Wed, 18 Oct 2006 10:47:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaChz-00062e-Pv for tls@ietf.org; Wed, 18 Oct 2006 10:47:51 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaChv-0003fL-99 for tls@ietf.org; Wed, 18 Oct 2006 10:47:51 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9IElghY012877 for ; Wed, 18 Oct 2006 17:47:46 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 17:47:45 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 17:47:45 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 18 Oct 2006 17:47:39 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Agenda for IETF67 Thread-Index: AcbyxFv6wKPTLex5S/2sZKzXcoB5Pg== From: To: X-OriginalArrivalTime: 18 Oct 2006 14:47:45.0334 (UTC) FILETIME=[5F51B560:01C6F2C4] X-Spam-Score: 0.2 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [TLS] Agenda for IETF67 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org TLS WG is scheduled to meet in San Diego as follows: TLS Session 1 (2 hours) Friday, Morning Session I 0900-1130 Room Name: Nautilus 1 If you have something you'd like to present, please drop a note to me and Eric. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 18 11:20:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaDDB-0004di-PR; Wed, 18 Oct 2006 11:20:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaDD9-0004a5-8t for tls@ietf.org; Wed, 18 Oct 2006 11:20:03 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaD8M-0000s9-9l for tls@ietf.org; Wed, 18 Oct 2006 11:15:07 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9IFF5Cg020777; Wed, 18 Oct 2006 18:15:05 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 18:15:04 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Oct 2006 18:15:04 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Open Issue: verify_data processing Date: Wed, 18 Oct 2006 18:14:54 +0300 Message-ID: In-Reply-To: <769A35F3-CC26-4EF8-A523-81D35E359836@sun.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Open Issue: verify_data processing Thread-Index: AcbyYdVYuOt75PdvSRi+EwUKDul6iQAYsA/w From: To: , X-OriginalArrivalTime: 18 Oct 2006 15:15:04.0547 (UTC) FILETIME=[305DC330:01C6F2C8] X-Spam-Score: 0.2 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Vipul Gupta wrote: > I would also prefer hashing. Our research team has successfully > created a TLS stack for tiny, wireless sensor devices like the > Berkeley "motes" with only 4KB of RAM (see > http://research.sun.com/spotlight/2004-12-20_vgupta.html > http://research.sun.com/projects/crypto/guptav_sizzle_pmc.pdf). > If the spec were modified to require storing the handshake messages > in full, then TLS (and derivatives like DTLS) would pretty much > be ruled out for this emerging class of devices. Is it obvious that hashing the messages requires less memory? Much of the information in the handshake messages is either static, or has to be kept around anyway -- and running hashes requires state, too. For example, consider a TLS server that has just sent ServerHelloDone, and has negotiated an RSA-based ciphersuite. At this point, the only pieces of information from the handshake messages the server can safely discard are: - ClientHello.compression_methods (usually 2 bytes) - ClientHello.cipher_suites (hmm.. 22 bytes with 10 ciphersuites?) - ClientHello.session_id (just 1 byte if not resuming) - Any unrecognized extensions in ClientHello (usually none) All the rest has to be kept around anyway (at this point); and I'm assuming the server certificate is static, so it's kept around=20 anyway (once, not separately for each TLS session). In other words: at this particular point-of-time, hashing would allow discarding ~25 bytes of information, at the cost of storing the hash context -- which in e.g. OpenSSL is 96 bytes for SHA-1 and 216 bytes=20 for SHA-512.=20 If we're using RSA ciphersuites and a PRF that requires only one pass over the data, the client can start calculating verify_data as soon as ServerHello has been received, so it's not obvious that first calculating a hash and then running PRF over the hash would actually save anything.=20 Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 18 13:12:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaEwk-0007ae-S5; Wed, 18 Oct 2006 13:11:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaEwj-0007aQ-QU for tls@ietf.org; Wed, 18 Oct 2006 13:11:13 -0400 Received: from smtp-out.google.com ([216.239.45.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaEwh-0003Me-AG for tls@ietf.org; Wed, 18 Oct 2006 13:11:13 -0400 Received: from zps77.corp.google.com (zps77.corp.google.com [172.25.146.77]) by smtp-out.google.com with ESMTP id k9IHB4mR027972 for ; Wed, 18 Oct 2006 10:11:04 -0700 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:content-transfer-encoding: content-disposition:references; b=mzq3EuTfU9bsW/wm8t0Wtf/JZry+pd75hZieMaqTiyLKh9W7tM7REUWV8IKJYPX7o NeX37OdyPFIwxIb9Zcaww== Received: from nf-out-0910.google.com (nfec2.prod.google.com [10.48.155.2]) by zps77.corp.google.com with ESMTP id k9IH9euv000740 for ; Wed, 18 Oct 2006 10:11:00 -0700 Received: by nf-out-0910.google.com with SMTP id c2so728025nfe for ; Wed, 18 Oct 2006 10:10:59 -0700 (PDT) Received: by 10.82.123.16 with SMTP id v16mr2441312buc; Wed, 18 Oct 2006 10:10:33 -0700 (PDT) Received: by 10.78.81.10 with HTTP; Wed, 18 Oct 2006 10:10:32 -0700 (PDT) Message-ID: <1b587cab0610181010q47bfe431j3138a62c8719a24f@mail.gmail.com> Date: Wed, 18 Oct 2006 18:10:32 +0100 From: "Ben Laurie" To: "Eric Rescorla" Subject: Re: [TLS] Open Issue: verify_data processing In-Reply-To: <20061017194817.EE0715C01E@laser.networkresonance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061017194817.EE0715C01E@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On 17/10/06, Eric Rescorla wrote: > Stipulating for the moment that we intend to replace the PRF, > we're left with the issue of how to compute the verify_data. > Currently, the verify_data is computed as: > > PRF(master_secret, finished_label, MD5(handshake_messages) + > SHA-1(handshake_messages)) [0..11]; > > If you're not using MD5 for your PRF, it doesn't make sense to use > it here either. This leaves us with two possibilities: > > 1. PRF the handshake_messages directly. > 2. Hash them first. > > The argument for hashing them first is that it avoids having > to store them (2-5k) for the entire handshake. It also will > accomodate PRFs which won't take unlimited size data. > > The argument against is that it puts the security of the > handshake on an unkeyed hash rather than a MAC (since > you only need to mount a 2nd preimage attack on the hash > and then you have 2nd preimage on MAC(K,hash).). A pedantic quibble here: this makes the assumption that a hash can always be calculated by chaining partial inputs, which is not a required property of hashes, just one we're used to having. > > My preference here would be to move to PRF(messages) and > if new PRFs can't cope with that then they can specify > a hash reduction of their own. Recall that the PRF needs > to be able to deal with fairly large data anyway since > the PMS + randoms could easily be 300+ bytes... > > Comments? > > -Ekr > > P.S. Please don't use this thread to say you don't want to > replace the PRF at all. The only question here is what we > do if *do* replace the PRF. > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 18 14:49:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaGT4-0003m0-HU; Wed, 18 Oct 2006 14:48:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaGT3-0003lu-TT for tls@ietf.org; Wed, 18 Oct 2006 14:48:41 -0400 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaGT1-0006Fq-Fw for tls@ietf.org; Wed, 18 Oct 2006 14:48:41 -0400 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id UAA12933; Wed, 18 Oct 2006 20:48:29 +0200 (MESZ) From: Martin Rex Message-Id: <200610181848.UAA03734@uw1048.wdf.sap.corp> Subject: Re: [TLS] Open issue: Record Version Numbers To: bmoeller@acm.org (Bodo Moeller) Date: Wed, 18 Oct 2006 20:48:29 +0200 (MET DST) In-Reply-To: <20061018120254.GA14826@tau.invalid> from "Bodo Moeller" at Oct 18, 6 02:02:55 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@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: , Errors-To: tls-bounces@lists.ietf.org Bodo Moeller wrote: > Eric wrote: > >> the ClientHello record in TLS handshakes. [...] > >> "TLS clients who wish > >> to negotiate with SSL 3.0 servers should send client hello messages > >> using the SSL 3.0 record format and client hello structure, sending > >> {3, 1} for the version field to note that they support TLS 1.0". > >> > >> I read this text as saying that if you are a client who supports TLS 1.0 > >> and SSLv3, you should in general send the following values: > >> > >> - record version number {3, 0} (SSLv3) > >> - client hello version number {3, 1} (TLSv1) > >> > >> If the server decides to accept TLS 1.0, it should respond with the > >> following values: > >> > >> - record version number {3, 1} (TLSv1) > >> - client hello version number {3, 1} (TLSv1) > >> > >> Pettersen reports that in some cases this causes errors because servers > >> (inexplicably) use the record version in the negotiation. However, I > >> think at the end of the day, that's a clear implementation error > >> and the spec should just clarify that the above behavior is what's > >> expected. I fully agree with Eric. This is the correct and most reasonable approach. > > I agree that, by the wording of the specification, clients in this > setting should send {3, 0} as record version number and {3, 1} as > client hello version number, and that it is a clear implementation > error if servers do not properly handle this. However, since there > *are* servers showing this bug, it is reasonable for clients to send > {3, 1} for both the record version number and the client hello version > number. (The specification text only says "should", not "MUST".) I violently disagree. Although there are broken servers out there, the bug seems to result in the negotiation of SSLv3 {3,0} instead of TLSv1 {3,1} if the client uses the correct behaviour and places {3,0} in the record protocol for backwards compatibility. Although this might be an undesirable result, it is neither a serious interoperability problem nor a direct security vulnerability by itself. However, the approach of the client using {3,1} in the record protocol will rightfully cause some SSLv3-only Server to abort the handshake, which amounts to a real interoperability problem, so clients ought to be strongly discouraged from taking that approach. Changing a spec to break interoperability with perfectly correct (server) implementations (of SSLv3) is a pretty bad idea. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 18 15:53:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaHSj-0003wa-MC; Wed, 18 Oct 2006 15:52:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaHRP-0002Pi-Ls; Wed, 18 Oct 2006 15:51:04 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaHRP-0003uZ-I7; Wed, 18 Oct 2006 15:51:03 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GaHRP-0001pa-4h; Wed, 18 Oct 2006 15:51:03 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id CC55D2ACF3; Wed, 18 Oct 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1GaHQQ-0001Tz-Iu; Wed, 18 Oct 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Wed, 18 Oct 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-interoperability-00.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Clientside interoperability experiences for the SSL and TLS protocols Author(s) : Y. Pettersen Filename : draft-ietf-tls-interoperability-00.txt Pages : 30 Date : 2006-10-18 This document presents a number of problems encountered when implementing TLS 1.0, TLS 1.1 and TLS Extensions for clients, and their consequences. The problems include servers that refuse to connect with clients supporting newer versions of the protocol, or that do not handle such negotiation properly. Another problem encountered is the incorrect use of values in the protocol messages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-interoperability-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-interoperability-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-interoperability-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-18130536.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-interoperability-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-interoperability-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-18130536.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@lists.ietf.org Wed Oct 18 18:31:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaJur-0005Q9-AJ; Wed, 18 Oct 2006 18:29:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaJ6D-0001d9-W2 for tls@ietf.org; Wed, 18 Oct 2006 17:37:17 -0400 Received: from moutng.kundenserver.de ([212.227.126.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaHsD-0007cT-Q5 for tls@ietf.org; Wed, 18 Oct 2006 16:18:49 -0400 Received: from [80.142.189.152] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1GaHsC2bFs-0008Qd; Wed, 18 Oct 2006 22:18:45 +0200 Received: by tau.invalid (Postfix, from userid 1000) id 7682F4D63; Wed, 18 Oct 2006 22:18:43 +0200 (CEST) Date: Wed, 18 Oct 2006 22:18:43 +0200 From: Bodo Moeller To: Martin Rex Subject: Re: [TLS] Open issue: Record Version Numbers Message-ID: <20061018201843.GA3536@tau.invalid> References: <20061018120254.GA14826@tau.invalid> <200610181848.UAA03734@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200610181848.UAA03734@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Wed, Oct 18, 2006 at 08:48:29PM +0200, Martin Rex wrote: >> I agree that, by the wording of the specification, clients in this >> setting should send {3, 0} as record version number and {3, 1} as >> client hello version number, and that it is a clear implementation >> error if servers do not properly handle this. However, since there >> *are* servers showing this bug, it is reasonable for clients to send >> {3, 1} for both the record version number and the client hello version >> number. (The specification text only says "should", not "MUST".) > I violently disagree. > > Although there are broken servers out there, the bug seems to result > in the negotiation of SSLv3 {3,0} instead of TLSv1 {3,1} if the > client uses the correct behaviour and places {3,0} in the record > protocol for backwards compatibility. Although this might be > an undesirable result, it is neither a serious interoperability > problem nor a direct security vulnerability by itself. Well, SSL 3.0 does have more severe security vulnerabilities than TLS 1.0 (http://www.imc.org/ietf-tls/mail-archive/msg03983.html), although these shouldn't be too significant for typical use. Also, in some cases draft-pettersen-tls-interop-experience-00.txt does report connection abortions due to this bug that could be avoided by sending {3,1} in both version fields. My impression was that sending {3,1} in both fields is less problematic in practice than sending {3,0} as the record version number and {3,1} as the client hello version number. However, this may be based on an incomplete assessment of what servers are out there, and more importantly, how current servers will react to similar situations involving newer and future protocol versions, such as {3,2} (TLS 1.1), {3,3} (TLS 1.2), and {3,42} (a made-up future protocol version that should cause servers to negotiate an existing version). > However, the approach of the client using {3,1} in the record protocol > will rightfully cause some SSLv3-only Server to abort the handshake, > which amounts to a real interoperability problem, so clients ought > to be strongly discouraged from taking that approach. > > Changing a spec to break interoperability with perfectly correct > (server) implementations (of SSLv3) is a pretty bad idea. In my view the main problem is that the speficification never clearly and fully described how implementations should behave to guarantee interoperability. Just like the SSL 3.0 specification does not require servers (SSL 3.0-only servers, that is) to accept {03, 01} in the record version number, the TLS 1.0 specification does not require servers (TLS 1.0-only servers) to accept {03, 00}. In both cases, it is to be hoped that implementors are wise enough to accept any version that looks reasonably close, because the worst thing that can happen is a connection failure, which isn't much worse than what you'd get if you straightly reject the connection attempt after seeing the version number: either way, this would be a connection failure, but servers that are tolerant about the version number also may actually see the connection succeed using the negotiated version number (based on the client hello version number and the server's capabilities). Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 18 18:44:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaK8E-0000va-MZ; Wed, 18 Oct 2006 18:43:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaK8C-0000td-V4 for tls@ietf.org; Wed, 18 Oct 2006 18:43:24 -0400 Received: from smtp-out5.blueyonder.co.uk ([195.188.213.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaK8B-00035d-GU for tls@ietf.org; Wed, 18 Oct 2006 18:43:24 -0400 Received: from [172.23.170.138] (helo=anti-virus01-09) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1GaK88-0003Pp-Lv for tls@ietf.org; Wed, 18 Oct 2006 23:43:20 +0100 Received: from 82-42-16-20.cable.ubr01.knor.blueyonder.co.uk ([82.42.16.20] helo=[127.0.0.1]) by asmtp-out3.blueyonder.co.uk with esmtp (Exim 4.52) id 1GaK88-0004mz-8F for tls@ietf.org; Wed, 18 Oct 2006 23:43:20 +0100 Message-ID: <4536AE07.70004@blueyonder.co.uk> Date: Wed, 18 Oct 2006 23:43:19 +0100 From: David Hopwood User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Re: Open Issue: verify_data processing References: <20061017194817.EE0715C01E@laser.networkresonance.com> <4535516B.2050401@redhat.com> <769A35F3-CC26-4EF8-A523-81D35E359836@sun.com> <871wp5oojn.fsf@latte.josefsson.org> In-Reply-To: <871wp5oojn.fsf@latte.josefsson.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: david.nospam.hopwood@blueyonder.co.uk 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: , Errors-To: tls-bounces@lists.ietf.org Simon Josefsson wrote: > Vipul Gupta writes: >>On Oct 17, 2006, at 2:55 PM, Wan-Teh Chang wrote: >>>Eric Rescorla wrote: >>> >>>>The argument against is that it puts the security of the handshake >>>>on an unkeyed hash rather than a MAC (since you only need to mount >>>>a 2nd preimage attack on the hash >>>>and then you have 2nd preimage on MAC(K,hash).). >>> >>>You can use this argument against RSA, DSA, and ECDSA >>>signatures, too. >>> >>>My preference is to hash the handshake_messages first. >>>The issue isn't that new PRFs can't cope with large data. >>>The issue is the new burden on TLS implementations to buffer >>>data of an indefinite length. Also consider the memory usage >>>of a busy TLS server that has a lot of handshakes in progress. >> >> I would also prefer hashing. Our research team has successfully >>created a TLS stack for tiny, wireless sensor devices like the >>Berkeley "motes" with only 4KB of RAM (see >>http://research.sun.com/spotlight/2004-12-20_vgupta.html >>http://research.sun.com/projects/crypto/guptav_sizzle_pmc.pdf). >>If the spec were modified to require storing the handshake messages >>in full, then TLS (and derivatives like DTLS) would pretty much >>be ruled out for this emerging class of devices. > > One idea would be to make it possible to negotiate whether to hash the > handshake messages or not. Please, no. Not only does this unnecessarily complicate the protocol and its security analysis, it gives an attacker more options as to what to attack. (In general, adding negotiated alternatives as to how the handshake is *verified* is a bad idea. Just decide on one of the possibilities; that will almost never be worse than negotiation from a security point of view.) -- David Hopwood _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 18 18:57:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaKLF-0005WP-Os; Wed, 18 Oct 2006 18:56:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaKLF-0005VE-44 for tls@ietf.org; Wed, 18 Oct 2006 18:56:53 -0400 Received: from smtp-out5.blueyonder.co.uk ([195.188.213.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaKKt-0005BY-8s for tls@ietf.org; Wed, 18 Oct 2006 18:56:52 -0400 Received: from [172.23.170.145] (helo=anti-virus03-08) by smtp-out5.blueyonder.co.uk with smtp (Exim 4.52) id 1GaKKs-0004z1-Hk for tls@ietf.org; Wed, 18 Oct 2006 23:56:30 +0100 Received: from 82-42-16-20.cable.ubr01.knor.blueyonder.co.uk ([82.42.16.20] helo=[127.0.0.1]) by asmtp-out2.blueyonder.co.uk with esmtp (Exim 4.52) id 1GaKKs-0007LT-0F for tls@ietf.org; Wed, 18 Oct 2006 23:56:30 +0100 Message-ID: <4536B117.7060304@blueyonder.co.uk> Date: Wed, 18 Oct 2006 23:56:23 +0100 From: David Hopwood User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] RFC 3456 - OCSP extension question References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: david.nospam.hopwood@blueyonder.co.uk 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: , Errors-To: tls-bounces@lists.ietf.org Joshua Ball wrote: > In regards to the implementation of RFC 3546, in particular the OCSP extension. > When the client does not wish to send any list of responders, what is the correct > sequence to send A zero-length vector. > (as a zero length vector apparently has a special meaning). If the client does not wish to send a list, then logically it *must* be the case that "the responders are implicitly known to the server - e.g., by prior arrangement." Otherwise how would the server know which responder to use? -- David Hopwood _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 18 20:00:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaLJE-00012T-5M; Wed, 18 Oct 2006 19:58:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaLJD-00012O-Ii for tls@ietf.org; Wed, 18 Oct 2006 19:58:51 -0400 Received: from dyn50.sunlabs.com ([204.153.12.50] helo=mail-mta.sunlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaLJ8-0008JH-8m for tls@ietf.org; Wed, 18 Oct 2006 19:58:51 -0400 Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0J7C0083NVXNU500@dps.sfvic.sunlabs.com> for tls@ietf.org; Wed, 18 Oct 2006 16:58:35 -0700 (PDT) Received: from [129.146.75.12] by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0J7C00MIYVXN3D20@mail.sunlabs.com> for tls@ietf.org; Wed, 18 Oct 2006 16:58:35 -0700 (PDT) Date: Wed, 18 Oct 2006 16:58:37 -0700 From: Vipul Gupta To: tls mailing list Message-id: <2B0956F1-0D84-4357-B696-EC6B3CB34E83@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.752.2) Content-type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: Vipul Gupta Subject: [TLS] Missing text in PRF description? X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Section 5 in http://www.ietf.org/internet-drafts/draft-ietf-tls- rfc4346-bis-01.txt seems to leave out details on how the label is used in the PRF computation. An additional sentence like PRF (secret, label, seed) = P_hash(secret, label + seed) would clarify how the three inputs to the PRF are turned into two inputs for the P_hash. vipul _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 18 20:07:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaLQq-0000Yc-Tj; Wed, 18 Oct 2006 20:06:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaLQo-0000P2-Mj for tls@ietf.org; Wed, 18 Oct 2006 20:06:42 -0400 Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaLQm-0001Uo-EE for tls@ietf.org; Wed, 18 Oct 2006 20:06:42 -0400 Received: by machshav.com (Postfix, from userid 512) id 85A06FB2C8; Wed, 18 Oct 2006 20:06:33 -0400 (EDT) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 8D176FB2AA; Wed, 18 Oct 2006 20:06:31 -0400 (EDT) Received: by berkshire.machshav.com (Postfix, from userid 54047) id AEA603C06F3; Wed, 18 Oct 2006 18:52:24 -0400 (EDT) Date: Wed, 18 Oct 2006 18:52:24 -0400 From: "Steven M. Bellovin" To: "Ben Laurie" Subject: Re: [TLS] Open Issue: verify_data processing Message-Id: <20061018185224.144f53df.smb@cs.columbia.edu> In-Reply-To: <1b587cab0610181010q47bfe431j3138a62c8719a24f@mail.gmail.com> References: <20061017194817.EE0715C01E@laser.networkresonance.com> <1b587cab0610181010q47bfe431j3138a62c8719a24f@mail.gmail.com> Organization: Columbia University X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.20; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Wed, 18 Oct 2006 18:10:32 +0100, "Ben Laurie" wrote: > A pedantic quibble here: this makes the assumption that a hash can > always be calculated by chaining partial inputs, which is not a > required property of hashes, just one we're used to having. > Indeed. In fact, the desirability of this property has been raised at some of the NIST hash function workshops -- some people think we will not be able to preserve it in a future secure hash function. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 18 20:17:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaLaY-0000Fa-1j; Wed, 18 Oct 2006 20:16:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaLaX-0000CF-AE for tls@ietf.org; Wed, 18 Oct 2006 20:16:45 -0400 Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaLaV-00035O-0Z for tls@ietf.org; Wed, 18 Oct 2006 20:16:45 -0400 Received: by delta.rtfm.com (Postfix, from userid 1001) id 6D8D11CC61; Wed, 18 Oct 2006 17:13:36 -0700 (PDT) To: Vipul Gupta Subject: Re: [TLS] Missing text in PRF description? References: <2B0956F1-0D84-4357-B696-EC6B3CB34E83@sun.com> From: EKR Date: Wed, 18 Oct 2006 17:13:36 -0700 In-Reply-To: <2B0956F1-0D84-4357-B696-EC6B3CB34E83@sun.com> (Vipul Gupta's message of "Wed, 18 Oct 2006 16:58:37 -0700") Message-ID: <86hcy1yxfz.fsf@delta.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.2 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: tls mailing list X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR 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: , Errors-To: tls-bounces@lists.ietf.org Yes, this is fixed in my local copy. -Ekr Vipul Gupta writes: > Section 5 in http://www.ietf.org/internet-drafts/draft-ietf-tls- > rfc4346-bis-01.txt > seems to leave out details on how the label is used in the PRF > computation. > An additional sentence like > > PRF (secret, label, seed) = P_hash(secret, label + seed) > > would clarify how the three inputs to the PRF are turned into two > inputs for the P_hash. > > vipul > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 18 20:34:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaLrC-0006B3-BZ; Wed, 18 Oct 2006 20:33:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaLrB-0006Aj-J2 for tls@lists.ietf.org; Wed, 18 Oct 2006 20:33:57 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaLr7-00066u-78 for tls@lists.ietf.org; Wed, 18 Oct 2006 20:33:57 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id CAA19780; Thu, 19 Oct 2006 02:33:49 +0200 (MESZ) From: Martin Rex Message-Id: <200610190033.CAA13991@uw1048.wdf.sap.corp> Subject: Re: [TLS] Open Issue: verify_data processing To: Pasi.Eronen@nokia.com Date: Thu, 19 Oct 2006 02:33:48 +0200 (MET DST) In-Reply-To: from "Pasi.Eronen@nokia.com" at Oct 18, 6 06:14:54 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: tls@lists.ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@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: , Errors-To: tls-bounces@lists.ietf.org Pasi.Eronen@nokia.com wrote: > > Vipul Gupta wrote: > > I would also prefer hashing. Our research team has successfully > > created a TLS stack for tiny, wireless sensor devices like the > > Berkeley "motes" with only 4KB of RAM (see > > http://research.sun.com/spotlight/2004-12-20_vgupta.html > > http://research.sun.com/projects/crypto/guptav_sizzle_pmc.pdf). > > If the spec were modified to require storing the handshake messages > > in full, then TLS (and derivatives like DTLS) would pretty much > > be ruled out for this emerging class of devices. > > Is it obvious that hashing the messages requires less memory? Much of > the information in the handshake messages is either static, or has to > be kept around anyway -- and running hashes requires state, too. The memory requirements are significantly higher if the protocol stack needs to keep all of the handshake messages around, and a lot more code is required resulting in more bugs. How much of the information from small&friendly handshake message are retained with the session state is entirely irrelevant here. Some of the values may not be stored in the original form, i.e. some implementations will store some protocol values as byte values, others will store it as integers of varying sizes (which may reverse the order of LSB/MSB in memory), and it would result in extremely bloated and error-prone code if an implementation tried to compute the hash over the handshake messages from unparsed session state information. There were proposals to allow additional handshake messages, the client hello can carry an extension which the server does not need to recognize, but which goes into the hanshake message hash. Then there is a cert request message with a list of trusted CAs which may be fairly long, and cert messages may actually contain fairly long certificate chains, not only one single certificate. Personally, I found the original scheme much more appealing (smaller memory footprint, smaller code), where the protocol stack did NOT need to keep the handshake messages around. Is there a real-world security benefit (not a pure academic one) justifying such a burden-some change? -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 18 21:09:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaMOe-0006m9-J2; Wed, 18 Oct 2006 21:08:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaMOd-0006ly-6Y for tls@ietf.org; Wed, 18 Oct 2006 21:08:31 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaMOX-0004VU-D0 for tls@ietf.org; Wed, 18 Oct 2006 21:08:31 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id DAA10623; Thu, 19 Oct 2006 03:08:04 +0200 (MESZ) From: Martin Rex Message-Id: <200610190108.DAA14947@uw1048.wdf.sap.corp> Subject: Re: [TLS] Open Issue: verify_data processing To: smb@cs.columbia.edu (Steven M. Bellovin) Date: Thu, 19 Oct 2006 03:08:04 +0200 (MET DST) In-Reply-To: <20061018185224.144f53df.smb@cs.columbia.edu> from "Steven M. Bellovin" at Oct 18, 6 06:52:24 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@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: , Errors-To: tls-bounces@lists.ietf.org Steven M. Bellovin wrote: > > On Wed, 18 Oct 2006 18:10:32 +0100, "Ben Laurie" wrote: > > > A pedantic quibble here: this makes the assumption that a hash can > > always be calculated by chaining partial inputs, which is not a > > required property of hashes, just one we're used to having. > > > Indeed. In fact, the desirability of this property has been raised at > some of the NIST hash function workshops -- some people think we will not > be able to preserve it in a future secure hash function. It will be interesting to see how they're going to sell such hash functions to current consumers of PKI-based software. PKCS#7/CMS as well as Web services security (xmlsig) applies digital signatures to quite large blobs of data today. Some of that data does not fit into memory already today, and one definitely does not want such a requirement on a busy server. So any hash function without that property is likely not going to be suitable for a drop-in replacement of installed base PKI-based software. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 18 22:29:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaNe0-0006XP-6N; Wed, 18 Oct 2006 22:28:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaNdz-0006Pv-13 for tls@ietf.org; Wed, 18 Oct 2006 22:28:27 -0400 Received: from smtp-out.google.com ([216.239.45.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaNdw-00033t-LA for tls@ietf.org; Wed, 18 Oct 2006 22:28:26 -0400 Received: from zps38.corp.google.com (zps38.corp.google.com [172.25.146.38]) by smtp-out.google.com with ESMTP id k9J2SNLA016950 for ; Wed, 18 Oct 2006 19:28:23 -0700 DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=received:message-id:date:from:to:subject:cc:in-reply-to: mime-version:content-type:content-transfer-encoding: content-disposition:references; b=SbGwmayU20CabS2/0IbezvSoEIMIH77ITzQ4z+T06maDRZ1cBwA6yiRUIIByGjPmT l8s2MRYF2TwcRJkhfhrUQ== Received: from nf-out-0910.google.com (nfal36.prod.google.com [10.48.63.36]) by zps38.corp.google.com with ESMTP id k9J2SECf028621 for ; Wed, 18 Oct 2006 19:28:16 -0700 Received: by nf-out-0910.google.com with SMTP id l36so1084988nfa for ; Wed, 18 Oct 2006 19:28:16 -0700 (PDT) Received: by 10.78.90.10 with SMTP id n10mr10952224hub; Wed, 18 Oct 2006 19:28:15 -0700 (PDT) Received: by 10.78.81.10 with HTTP; Wed, 18 Oct 2006 19:28:15 -0700 (PDT) Message-ID: <1b587cab0610181928w4cc6cc5aye33abec8d29d4e9e@mail.gmail.com> Date: Thu, 19 Oct 2006 03:28:15 +0100 From: "Ben Laurie" To: martin.rex@sap.com Subject: Re: [TLS] Open Issue: verify_data processing In-Reply-To: <200610190108.DAA14947@uw1048.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20061018185224.144f53df.smb@cs.columbia.edu> <200610190108.DAA14947@uw1048.wdf.sap.corp> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On 19/10/06, Martin Rex wrote: > Steven M. Bellovin wrote: > > > > On Wed, 18 Oct 2006 18:10:32 +0100, "Ben Laurie" wrote: > > > > > A pedantic quibble here: this makes the assumption that a hash can > > > always be calculated by chaining partial inputs, which is not a > > > required property of hashes, just one we're used to having. > > > > > Indeed. In fact, the desirability of this property has been raised at > > some of the NIST hash function workshops -- some people think we will not > > be able to preserve it in a future secure hash function. > > It will be interesting to see how they're going to sell such > hash functions to current consumers of PKI-based software. > > PKCS#7/CMS as well as Web services security (xmlsig) applies digital > signatures to quite large blobs of data today. Some of that data > does not fit into memory already today, and one definitely does > not want such a requirement on a busy server. > > So any hash function without that property is likely not going > to be suitable for a drop-in replacement of installed base > PKI-based software. So, a throwaway observation is that you can always derive a chained hash function from an unchained one, by hashing fixed-size blocks then hashing the hashes. Whether this preserves the properties needed I suspect depends on the hash function and the block size. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 19 09:10:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXdv-0001YQ-Bm; Thu, 19 Oct 2006 09:09:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXdu-0001TC-1F for tls@ietf.org; Thu, 19 Oct 2006 09:09:02 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaXdr-00012R-HN for tls@ietf.org; Thu, 19 Oct 2006 09:09:02 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9JD8w6e024718 for ; Thu, 19 Oct 2006 16:08:58 +0300 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 16:08:58 +0300 Received: from 4FIL09356 ([172.21.42.147]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 19 Oct 2006 16:08:57 +0300 From: "Pasi Eronen" To: "tls mailing list" Date: Thu, 19 Oct 2006 16:09:01 +0300 Message-ID: <000001c6f37f$bece5ff0$932a15ac@NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acbzf75VtCl0xy4NRoSed78thZ+vwQ== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-OriginalArrivalTime: 19 Oct 2006 13:08:57.0616 (UTC) FILETIME=[BC897900:01C6F37F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Subject: [TLS] Straw poll about default PRF X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Let's try to close the default PRF issue before the San Diego meeting. To summarize the issue: to meet its chartered goal of removing dependencies to MD5 and SHA-1, TLS WG will most likely specify a PRF that is not based on MD5/SHA-1 (the exact details will be determined separately). TLS 1.2 will also most likely allow new ciphersuites to specify a ciphersuite-specific PRF (e.g. the GOST ciphersuites). The remaining question is exactly how the PRF negotiation will work for those ciphersuites that don't specify anything, especially all the currently defined ciphersuites. The two main alternatives seem to be as follows: 1) Default PRF is tied to the TLS version number: in other words, ciphersuites that don't specify anything else (including all currently defined ciphersuites) will use the new TLS 1.2 PRF (details of which are TBD) when TLS 1.2 is negotiated. 2) The new PRF will be used only for new ciphersuites that explicitly say so; all currently defined ciphersuites continue to use the current (TLS 1.0/1.1) PRF even when TLS 1.2 is negotiated. Clearly neither alternative is horribly broken or unworkable, so this is mainly a question of "which seems nicer". Some arguments that have been made are as follows: - Option 1 is not necessary, since there are no practical attacks against the current PRF (yet) - Option 1 can cause implementation and/or interop problems - On the other hand, changing PRF in SSLv3->TLS1.0 did not cause big implementation and/or interop problems (there are interop problems, but not because of the PRF). - With option 1, all ciphersuites benefit without having to get new numbers (and there are lots of RFCs that would have to be updated). - In order to have secure negotiation, all the PRFs that both sides support have to be secure against a specific kind of active attack (true, but would this suggest option 1 or 2, or neither?). - TLS versions older than 1.2 have to be enabled for long time (true, but would this suggest option 1 or 2, or neither?). Please state your opinion on the WG list within a week. When judging the WG consensus, I will also take into account the sense of the room at Montreal, where support for option 1 was practically unanimous. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 19 09:25:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXsk-0001I3-NJ; Thu, 19 Oct 2006 09:24:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaXsj-0001FG-DK for tls@ietf.org; Thu, 19 Oct 2006 09:24:21 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaXsc-0003y9-Cx for tls@ietf.org; Thu, 19 Oct 2006 09:24:21 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9JDODuR013893; Thu, 19 Oct 2006 16:24:13 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 16:24:13 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 16:24:13 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Open issue: Record Version Numbers Date: Thu, 19 Oct 2006 16:24:12 +0300 Message-ID: In-Reply-To: <200610181848.UAA03734@uw1048.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Open issue: Record Version Numbers Thread-Index: Acby5okkRwzEoCtzSsK+tf7h8R6Z4wAmoqkw From: To: X-OriginalArrivalTime: 19 Oct 2006 13:24:13.0021 (UTC) FILETIME=[DE2930D0:01C6F381] X-Spam-Score: 0.2 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Martin Rex wrote: > However, the approach of the client using {3,1} in the record > protocol will rightfully cause some SSLv3-only Server to abort the > handshake, which amounts to a real interoperability problem, so > clients ought to be strongly discouraged from taking that approach. On the other hand, using {3,0} in the record protocol will cause=20 some TLS 1.0 servers to abort the handshake (or fail it some way).=20 Yngve's draft shows such servers do exist. I don't think arguing which of them does it "rightfully" is very useful (as Bodo pointed out, TLS 1.0 spec does not say that TLS 1.0-only servers should accept {3,0} in the record version); we should be arguing about which approach will cause the least amount of interop problems. To this question, we don't seem to have a definitive answer yet. > Changing a spec to break interoperability with perfectly correct > (server) implementations (of SSLv3) is a pretty bad idea. As basically all current TLS implementations send {3,1} in the=20 record version (when configured to support both SSLv3 and TLS 1.0), interoperability with servers that reject this is already broken in real world. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 19 09:32:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaY08-0000Dw-Oj; Thu, 19 Oct 2006 09:32:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaY06-0000Da-Kg for tls@ietf.org; Thu, 19 Oct 2006 09:31:58 -0400 Received: from woodstock.binhost.com ([66.150.120.2]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GaXzv-0005WH-I6 for tls@ietf.org; Thu, 19 Oct 2006 09:31:58 -0400 Received: (qmail 10216 invoked by uid 0); 19 Oct 2006 13:31:40 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (84.35.84.3) by woodstock.binhost.com with SMTP; 19 Oct 2006 13:31:40 -0000 Message-Id: <7.0.0.16.2.20061019092746.07473468@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 19 Oct 2006 09:31:37 -0400 To: tls@ietf.org From: Russ Housley Subject: Re: [TLS] Straw poll about default PRF In-Reply-To: <000001c6f37f$bece5ff0$932a15ac@NOE.Nokia.com> References: <000001c6f37f$bece5ff0$932a15ac@NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org I prefer Option 1. At 09:09 AM 10/19/2006, Pasi Eronen wrote: >Let's try to close the default PRF issue before the San Diego >meeting. > >To summarize the issue: to meet its chartered goal of removing >dependencies to MD5 and SHA-1, TLS WG will most likely specify a >PRF that is not based on MD5/SHA-1 (the exact details will be >determined separately). TLS 1.2 will also most likely allow new >ciphersuites to specify a ciphersuite-specific PRF (e.g. the >GOST ciphersuites). > >The remaining question is exactly how the PRF negotiation will >work for those ciphersuites that don't specify anything, especially >all the currently defined ciphersuites. > >The two main alternatives seem to be as follows: > > 1) Default PRF is tied to the TLS version number: in other words, > ciphersuites that don't specify anything else (including all > currently defined ciphersuites) will use the new TLS 1.2 PRF > (details of which are TBD) when TLS 1.2 is negotiated. > > 2) The new PRF will be used only for new ciphersuites that > explicitly say so; all currently defined ciphersuites continue to > use the current (TLS 1.0/1.1) PRF even when TLS 1.2 is negotiated. > >Clearly neither alternative is horribly broken or unworkable, so this >is mainly a question of "which seems nicer". Some arguments that >have been made are as follows: > >- Option 1 is not necessary, since there are no practical attacks > against the current PRF (yet) >- Option 1 can cause implementation and/or interop problems >- On the other hand, changing PRF in SSLv3->TLS1.0 did not cause > big implementation and/or interop problems (there are interop > problems, but not because of the PRF). >- With option 1, all ciphersuites benefit without having to get > new numbers (and there are lots of RFCs that would have to > be updated). >- In order to have secure negotiation, all the PRFs that both > sides support have to be secure against a specific kind of > active attack (true, but would this suggest option 1 or 2, > or neither?). >- TLS versions older than 1.2 have to be enabled for long time > (true, but would this suggest option 1 or 2, or neither?). > >Please state your opinion on the WG list within a week. When >judging the WG consensus, I will also take into account the >sense of the room at Montreal, where support for option 1 was >practically unanimous. > >Best regards, >Pasi > > >_______________________________________________ >TLS mailing list >TLS@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 19 09:38:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaY6F-0002kQ-Ph; Thu, 19 Oct 2006 09:38:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaY6E-0002jc-Qd for tls@ietf.org; Thu, 19 Oct 2006 09:38:18 -0400 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaY6A-0006cP-5x for tls@ietf.org; Thu, 19 Oct 2006 09:38:18 -0400 Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id k9JDbwkV020927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Oct 2006 15:37:58 +0200 From: Simon Josefsson To: "Pasi Eronen" References: <000001c6f37f$bece5ff0$932a15ac@NOE.Nokia.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:061019:tls@ietf.org::Vg6z1Jr8p9JmWhs5:GVDZ X-Hashcash: 1:22:061019:pasi.eronen@nokia.com::qDVNPS/dCL7zf3Ru:Dtpn Date: Thu, 19 Oct 2006 15:37:58 +0200 In-Reply-To: <000001c6f37f$bece5ff0$932a15ac@NOE.Nokia.com> (Pasi Eronen's message of "Thu\, 19 Oct 2006 16\:09\:01 +0300") Message-ID: <87ods8fmtl.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: tls mailing list Subject: [TLS] Re: Straw poll about default PRF X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org "Pasi Eronen" writes: > The two main alternatives seem to be as follows: > > 1) Default PRF is tied to the TLS version number: in other words, > ciphersuites that don't specify anything else (including all > currently defined ciphersuites) will use the new TLS 1.2 PRF > (details of which are TBD) when TLS 1.2 is negotiated. > > 2) The new PRF will be used only for new ciphersuites that > explicitly say so; all currently defined ciphersuites continue to > use the current (TLS 1.0/1.1) PRF even when TLS 1.2 is negotiated. ... > Please state your opinion on the WG list within a week. I have a (mild) preference for alternative 2 for these reasons: * I prefer if all negotiations that influence which cryptographic algorithms are used is negotiated through the cipher suites. * I prefer to de-couple PRF negotiation from TLS version level negotiation. Consider this: What if the new TLS 1.2 default PRF is broken, but the current TLS PRF is not broken? What should implements do? Stop using TLS 1.2 and negotiate TLS 1.1? That would be quite unfortunate, especially if TLS 1.2 fixes other security problems or add important new features that implementations need. * The TLS version number negotiation appears to be fragile. (Although, if TLS 1.2 fixed this problem with stricter text, and implementations followed it, this argument would go away.) To me, there is only one disadvantage with alternative 2: * We need to specify new cipher suites that use the new PRF. That's some work, but seems do-able. I could change my mind if some good arguments against 2 are presented. /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 19 09:39:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaY6V-0003al-Ao; Thu, 19 Oct 2006 09:38:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaY6T-0003ZS-Fl for tls@ietf.org; Thu, 19 Oct 2006 09:38:33 -0400 Received: from smtp.xenetic.net ([217.77.192.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaY6P-0006cv-0X for tls@ietf.org; Thu, 19 Oct 2006 09:38:33 -0400 Received: from SSHEXCH1.ad.ssh.com (sshexch1.ad.ssh.com [217.77.200.204] (may be forged)) by smtp.xenetic.net (8.13.3/8.13.3) with ESMTP id k9JDenoF019764 for ; Thu, 19 Oct 2006 16:40:49 +0300 (EEST) (envelope-from Sami.Lehtinen@ssh.com) Received: from [127.0.0.1] ([10.1.44.7]) by SSHEXCH1.ad.ssh.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 16:38:17 +0300 Message-ID: <45377F86.5000407@ssh.com> Date: Thu, 19 Oct 2006 16:37:10 +0300 From: Sami Lehtinen User-Agent: Mozilla Thunderbird 1.0.8 (X11/20060502) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tls mailing list Subject: Re: [TLS] Straw poll about default PRF References: <000001c6f37f$bece5ff0$932a15ac@NOE.Nokia.com> In-Reply-To: <000001c6f37f$bece5ff0$932a15ac@NOE.Nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Oct 2006 13:38:17.0519 (UTC) FILETIME=[D5855BF0:01C6F383] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Option 1, please. Pasi Eronen wrote: [SNIP] > 1) Default PRF is tied to the TLS version number: in other words, > ciphersuites that don't specify anything else (including all > currently defined ciphersuites) will use the new TLS 1.2 PRF > (details of which are TBD) when TLS 1.2 is negotiated. [SNIP] -- sjl@ssh.com _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 19 09:42:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaY9y-0005sE-2i; Thu, 19 Oct 2006 09:42:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaY9w-0005rD-VM for tls@ietf.org; Thu, 19 Oct 2006 09:42:08 -0400 Received: from moutng.kundenserver.de ([212.227.126.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaY9s-0007Cs-FD for tls@ietf.org; Thu, 19 Oct 2006 09:42:08 -0400 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis), id 0MKxQS-1GaY8s1kHR-0005ld; Thu, 19 Oct 2006 15:41:02 +0200 Received: by tau.invalid (Postfix, from userid 1000) id B735B4DE5; Thu, 19 Oct 2006 15:41:01 +0200 (CEST) Date: Thu, 19 Oct 2006 15:41:01 +0200 From: Bodo Moeller To: Pasi Eronen Subject: Re: [TLS] Straw poll about default PRF Message-ID: <20061019134101.GA18133@tau.invalid> References: <000001c6f37f$bece5ff0$932a15ac@NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000001c6f37f$bece5ff0$932a15ac@NOE.Nokia.com> User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: tls mailing list X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Thu, Oct 19, 2006 at 04:09:01PM +0300, Pasi Eronen wrote: [...] > The remaining question is exactly how the PRF negotiation will > work for those ciphersuites that don't specify anything, especially > all the currently defined ciphersuites. > > The two main alternatives seem to be as follows: > > 1) Default PRF is tied to the TLS version number: in other words, > ciphersuites that don't specify anything else (including all > currently defined ciphersuites) will use the new TLS 1.2 PRF > (details of which are TBD) when TLS 1.2 is negotiated. > > 2) The new PRF will be used only for new ciphersuites that > explicitly say so; all currently defined ciphersuites continue to > use the current (TLS 1.0/1.1) PRF even when TLS 1.2 is negotiated. [...] > Please state your opinion on the WG list within a week. When > judging the WG consensus, I will also take into account the > sense of the room at Montreal, where support for option 1 was > practically unanimous. Really? According to Eric (<86k6403hqq.fsf@raman.networkresonance.com>, 18 Sep 2006), what was decided at Montreal was < 1. The default PRF is the TLS 1.1 PRF with a single hash algorithm < and the entire key used as input to P_hash. < 2. All current cipher suites will use SHA-1 in TLS 1.2. < 3. New cipher suites will by default use the TLS 1.1 PRF with whatever < hash they're using for HMAC. < 4. New cipher suites can define a new PRF but it must use the same < "API" as the TLS 1.1 PRF. This variant looks worse to me than #1 above in that it would limit existing ciphersuites to strictly 160-bit security for encryption (and would limit the encryption security for new ciphersuites using these defaults to whatever is deemed sufficient for authentication), and would lead to a complicated situation where there are multiple PRFs and where essentially similar ciphersuites might be using different PRFs. Option #1 above makes sense, provided that the new PRF is an actual 256-bit PRF or better. But if no suitable candidate is agreed upon, then we should rather stay with #2 until something apropriate comes up. Sorry for not sticking with one of the two options as you outlined them ... Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 19 09:43:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYAu-0006EP-He; Thu, 19 Oct 2006 09:43:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYAs-0006DB-Ei for tls@ietf.org; Thu, 19 Oct 2006 09:43:06 -0400 Received: from sp.isima.fr ([193.55.95.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaYAl-0007L3-Hx for tls@ietf.org; Thu, 19 Oct 2006 09:43:06 -0400 Received: from [127.0.0.1] (pc158.isima.fr [193.55.95.158]) by sp.isima.fr (8.9.3/jtpda-5.3.1) with ESMTP id PAA30872 ; Thu, 19 Oct 2006 15:41:45 +0200 Message-ID: <453780D9.7070000@isima.fr> Date: Thu, 19 Oct 2006 15:42:49 +0200 From: badra User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Pasi Eronen Subject: Re: [TLS] Straw poll about default PRF References: <000001c6f37f$bece5ff0$932a15ac@NOE.Nokia.com> In-Reply-To: <000001c6f37f$bece5ff0$932a15ac@NOE.Nokia.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sp.isima.fr id PAA30872 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: tls mailing list X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org I think it is better to don't ties the PRF only to the TLS version=20 number. Let us tie it to the identifier of the cipher_suite too. Best regards, Badra Pasi Eronen a =E9crit : > Let's try to close the default PRF issue before the San Diego=20 > meeting. > > To summarize the issue: to meet its chartered goal of removing > dependencies to MD5 and SHA-1, TLS WG will most likely specify a=20 > PRF that is not based on MD5/SHA-1 (the exact details will be=20 > determined separately). TLS 1.2 will also most likely allow new=20 > ciphersuites to specify a ciphersuite-specific PRF (e.g. the=20 > GOST ciphersuites). > > The remaining question is exactly how the PRF negotiation will=20 > work for those ciphersuites that don't specify anything, especially=20 > all the currently defined ciphersuites. > > The two main alternatives seem to be as follows: > > 1) Default PRF is tied to the TLS version number: in other words,=20 > ciphersuites that don't specify anything else (including all=20 > currently defined ciphersuites) will use the new TLS 1.2 PRF=20 > (details of which are TBD) when TLS 1.2 is negotiated. > > 2) The new PRF will be used only for new ciphersuites that > explicitly say so; all currently defined ciphersuites continue to > use the current (TLS 1.0/1.1) PRF even when TLS 1.2 is negotiated. > > Clearly neither alternative is horribly broken or unworkable, so this > is mainly a question of "which seems nicer". Some arguments that > have been made are as follows: > > - Option 1 is not necessary, since there are no practical attacks > against the current PRF (yet) > - Option 1 can cause implementation and/or interop problems > - On the other hand, changing PRF in SSLv3->TLS1.0 did not cause=20 > big implementation and/or interop problems (there are interop=20 > problems, but not because of the PRF). > - With option 1, all ciphersuites benefit without having to get > new numbers (and there are lots of RFCs that would have to > be updated). > - In order to have secure negotiation, all the PRFs that both > sides support have to be secure against a specific kind of > active attack (true, but would this suggest option 1 or 2, > or neither?). > - TLS versions older than 1.2 have to be enabled for long time > (true, but would this suggest option 1 or 2, or neither?). > > Please state your opinion on the WG list within a week. When=20 > judging the WG consensus, I will also take into account the=20 > sense of the room at Montreal, where support for option 1 was=20 > practically unanimous. > > Best regards, > Pasi > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > > =20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 19 09:47:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYEA-0007L9-Bh; Thu, 19 Oct 2006 09:46:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYE8-0007JG-L6 for tls@ietf.org; Thu, 19 Oct 2006 09:46:28 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaYE4-0007uV-6X for tls@ietf.org; Thu, 19 Oct 2006 09:46:28 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id PAA01050; Thu, 19 Oct 2006 15:46:15 +0200 (MESZ) From: Martin Rex Message-Id: <200610191346.PAA04282@uw1048.wdf.sap.corp> Subject: Re: [TLS] Straw poll about default PRF To: pasi.eronen@nokia.com (Pasi Eronen) Date: Thu, 19 Oct 2006 15:46:15 +0200 (MET DST) In-Reply-To: <000001c6f37f$bece5ff0$932a15ac@NOE.Nokia.com> from "Pasi Eronen" at Oct 19, 6 04:09:01 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@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: , Errors-To: tls-bounces@lists.ietf.org Pasi Eronen wrote: > > 1) Default PRF is tied to the TLS version number: in other words, > ciphersuites that don't specify anything else (including all > currently defined ciphersuites) will use the new TLS 1.2 PRF > (details of which are TBD) when TLS 1.2 is negotiated. I would prefer (1) over (2) *IF*, and only if the new PRF will _NOT_ need all of the handshake messages to be stored for the entire handshake. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 19 10:01:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYRm-00028i-1I; Thu, 19 Oct 2006 10:00:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYRl-00028c-2q for tls@ietf.org; Thu, 19 Oct 2006 10:00:33 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaYRg-0002KK-LD for tls@ietf.org; Thu, 19 Oct 2006 10:00:33 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id QAA12473; Thu, 19 Oct 2006 16:00:15 +0200 (MESZ) From: Martin Rex Message-Id: <200610191359.PAA04663@uw1048.wdf.sap.corp> Subject: Re: [TLS] Open issue: Record Version Numbers To: Pasi.Eronen@nokia.com Date: Thu, 19 Oct 2006 15:59:53 +0200 (MET DST) In-Reply-To: from "Pasi.Eronen@nokia.com" at Oct 19, 6 04:24:12 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@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: , Errors-To: tls-bounces@lists.ietf.org Pasi.Eronen@nokia.com wrote: > > Martin Rex wrote: > > However, the approach of the client using {3,1} in the record > > protocol will rightfully cause some SSLv3-only Server to abort the > > handshake, which amounts to a real interoperability problem, so > > clients ought to be strongly discouraged from taking that approach. > > On the other hand, using {3,0} in the record protocol will cause > some TLS 1.0 servers to abort the handshake (or fail it some way). > Yngve's draft shows such servers do exist. There is not problem with requiring broken servers to be fixed. There is a serious problem with requiring perfectly correct implementations to be fixed to cater much newer broken implementations. The availability of patches is likely better for newer implementations (broken TLSv1) than for older implementations (correct SSLv3). > > I don't think arguing which of them does it "rightfully" is very > useful (as Bodo pointed out, TLS 1.0 spec does not say that TLS > 1.0-only servers should accept {3,0} in the record version); On the contrary. The version on the record protocol is a PDU encoding, and TLS was specifically designed to reuse most of SSLv3. There is no requirement for a TLSv1 server to agree to talking SSLv3 {3,1}, but it certainly is required to parse the SSLv3 record procotol without hitches! > > As basically all current TLS implementations send {3,1} in the > record version (when configured to support both SSLv3 and TLS 1.0), > interoperability with servers that reject this is already broken > in real world. Only the (TLSv1) servers that require this hack are broken, and they're broken in a real stupid fashion. Clients that are sending {3,1} even with SSLv3 enabled are technically not broken, but they're not doing what is recommended. Only clients that do not offer the user a switch to make them behave in the recommended fashion are broken with regards to the spirit of the spec. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 19 10:30:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYte-0003Mp-V4; Thu, 19 Oct 2006 10:29:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaYtd-0003Mg-Tq for tls@ietf.org; Thu, 19 Oct 2006 10:29:21 -0400 Received: from woodstock.binhost.com ([66.150.120.2]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GaYtb-0008Gp-LJ for tls@ietf.org; Thu, 19 Oct 2006 10:29:21 -0400 Received: (qmail 31420 invoked by uid 0); 19 Oct 2006 14:29:14 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (84.35.84.3) by woodstock.binhost.com with SMTP; 19 Oct 2006 14:29:14 -0000 Message-Id: <7.0.0.16.2.20061019102503.074cc928@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 19 Oct 2006 10:26:45 -0400 To: Simon Josefsson ,"Pasi Eronen" From: Russ Housley Subject: Re: [TLS] Re: Straw poll about default PRF In-Reply-To: <87ods8fmtl.fsf@latte.josefsson.org> References: <000001c6f37f$bece5ff0$932a15ac@NOE.Nokia.com> <87ods8fmtl.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: tls mailing list X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Simon: If the TLS 1.2 PRF gets broken, can't a server demand the use of a ciphersuite that specifies its own yet-to-be-broken PRFs? Russ At 09:37 AM 10/19/2006, Simon Josefsson wrote: >"Pasi Eronen" writes: > > > The two main alternatives seem to be as follows: > > > > 1) Default PRF is tied to the TLS version number: in other words, > > ciphersuites that don't specify anything else (including all > > currently defined ciphersuites) will use the new TLS 1.2 PRF > > (details of which are TBD) when TLS 1.2 is negotiated. > > > > 2) The new PRF will be used only for new ciphersuites that > > explicitly say so; all currently defined ciphersuites continue to > > use the current (TLS 1.0/1.1) PRF even when TLS 1.2 is negotiated. >... > > Please state your opinion on the WG list within a week. > >I have a (mild) preference for alternative 2 for these reasons: > >* I prefer if all negotiations that influence which cryptographic > algorithms are used is negotiated through the cipher suites. > >* I prefer to de-couple PRF negotiation from TLS version level > negotiation. > > Consider this: What if the new TLS 1.2 default PRF is broken, but > the current TLS PRF is not broken? > > What should implements do? Stop using TLS 1.2 and negotiate TLS > 1.1? That would be quite unfortunate, especially if TLS 1.2 fixes > other security problems or add important new features that > implementations need. > >* The TLS version number negotiation appears to be fragile. > (Although, if TLS 1.2 fixed this problem with stricter text, and > implementations followed it, this argument would go away.) > >To me, there is only one disadvantage with alternative 2: > >* We need to specify new cipher suites that use the new PRF. That's > some work, but seems do-able. > >I could change my mind if some good arguments against 2 are presented. > >/Simon > >_______________________________________________ >TLS mailing list >TLS@lists.ietf.org >https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 19 11:40:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaZzK-0003pI-0J; Thu, 19 Oct 2006 11:39:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaZzI-0003mD-NI for tls@ietf.org; Thu, 19 Oct 2006 11:39:16 -0400 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaZkI-00057w-Gf for tls@ietf.org; Thu, 19 Oct 2006 11:23:51 -0400 Received: from c80-217-218-49.cm-upc.chello.se (c80-217-218-49.cm-upc.chello.se [80.217.218.49]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id k9JFNal9008597; Thu, 19 Oct 2006 17:23:37 +0200 Subject: Re: [TLS] Re: Straw poll about default PRF From: Simon Josefsson To: Russ Housley In-Reply-To: <7.0.0.16.2.20061019102503.074cc928@vigilsec.com> References: <000001c6f37f$bece5ff0$932a15ac@NOE.Nokia.com> <87ods8fmtl.fsf@latte.josefsson.org> <7.0.0.16.2.20061019102503.074cc928@vigilsec.com> Content-Type: text/plain Date: Thu, 19 Oct 2006 17:23:34 +0200 Message-Id: <1161271414.26581.15.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=4.9 required=5.0 tests=AWL,BAYES_00, HELO_DYNAMIC_IPADDR,RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.1.1 X-Spam-Level: **** X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: Pasi Eronen , tls mailing list X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Thu, 2006-10-19 at 10:26 -0400, Russ Housley wrote: > Simon: > > If the TLS 1.2 PRF gets broken, can't a server demand the use of a > ciphersuite that specifies its own yet-to-be-broken PRFs? Yes, true, pending that such ciphersuites are specified and deployed. It could also fall back to TLS 1.1 and use the old PRF. If TLS >= 1.2 fixes other security problems, compared to TLS 1.1, there would be a tradeoff: either run with the risks with a broken TLS 1.2 PRF or the risks of the things broken in TLS 1.1 but fixed in TLS >= 1.2. I consider it unlikely that the TLS 1.2 PRF will be broken faster than the TLS 1.0 PRF -- although stranger things have happened... -- hence my preference is only a mild one. It is primarily based on the first bullet below. /Simon > > Russ > > At 09:37 AM 10/19/2006, Simon Josefsson wrote: > >"Pasi Eronen" writes: > > > > > The two main alternatives seem to be as follows: > > > > > > 1) Default PRF is tied to the TLS version number: in other words, > > > ciphersuites that don't specify anything else (including all > > > currently defined ciphersuites) will use the new TLS 1.2 PRF > > > (details of which are TBD) when TLS 1.2 is negotiated. > > > > > > 2) The new PRF will be used only for new ciphersuites that > > > explicitly say so; all currently defined ciphersuites continue to > > > use the current (TLS 1.0/1.1) PRF even when TLS 1.2 is negotiated. > >... > > > Please state your opinion on the WG list within a week. > > > >I have a (mild) preference for alternative 2 for these reasons: > > > >* I prefer if all negotiations that influence which cryptographic > > algorithms are used is negotiated through the cipher suites. > > > >* I prefer to de-couple PRF negotiation from TLS version level > > negotiation. > > > > Consider this: What if the new TLS 1.2 default PRF is broken, but > > the current TLS PRF is not broken? > > > > What should implements do? Stop using TLS 1.2 and negotiate TLS > > 1.1? That would be quite unfortunate, especially if TLS 1.2 fixes > > other security problems or add important new features that > > implementations need. > > > >* The TLS version number negotiation appears to be fragile. > > (Although, if TLS 1.2 fixed this problem with stricter text, and > > implementations followed it, this argument would go away.) > > > >To me, there is only one disadvantage with alternative 2: > > > >* We need to specify new cipher suites that use the new PRF. That's > > some work, but seems do-able. > > > >I could change my mind if some good arguments against 2 are presented. > > > >/Simon > > > >_______________________________________________ > >TLS mailing list > >TLS@lists.ietf.org > >https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 19 12:17:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gaaa1-0006H4-IY; Thu, 19 Oct 2006 12:17:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gaaa0-00068d-3w for tls@ietf.org; Thu, 19 Oct 2006 12:17:12 -0400 Received: from moutng.kundenserver.de ([212.227.126.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaaZw-0000nA-LN for tls@ietf.org; Thu, 19 Oct 2006 12:17:12 -0400 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1GaaZv0p5S-0003Pu; Thu, 19 Oct 2006 18:17:07 +0200 Received: by tau.invalid (Postfix, from userid 1000) id 914C34DE5; Thu, 19 Oct 2006 18:17:06 +0200 (CEST) Date: Thu, 19 Oct 2006 18:17:06 +0200 From: Bodo Moeller To: Martin Rex Subject: Re: [TLS] Open issue: Record Version Numbers Message-ID: <20061019161706.GA22034@tau.invalid> References: <200610191359.PAA04663@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200610191359.PAA04663@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Thu, Oct 19, 2006 at 03:59:53PM +0200, Martin Rex wrote: >> I don't think arguing which of them does it "rightfully" is very >> useful (as Bodo pointed out, TLS 1.0 spec does not say that TLS >> 1.0-only servers should accept {3,0} in the record version); > On the contrary. The version on the record protocol is a PDU encoding, > and TLS was specifically designed to reuse most of SSLv3. Just like TLS 1.0 was designed to reuse most of SSL 3.0, SSL 3.0 was designed to allow reuse in future protocol versions, and server implementations of the SSL 3.0 specification should tolerate seeing {3, 1} or later in the record version number used for the client hello. If implementations don't tolerate this, it is a deficiency, just like it is a deficiency if TLS 1.0 implementations don't tolerate {3, 0} in the record version number. In neither case, it necessarily deserves to be called a bug in the implementation since the actual bug is the unclear language in the specifications. Note that the SSL 3.0 specification (draft-freier-ssl-version3-02.txt) can be read as implying that the record version number field will contain the highest version of the protocol supported by the client, not the fixed value {3, 0}. Appendix E.1 (on the version 2 client hello) has the following description: version The highest version of the protocol supported by the client (equals ProtocolVersion.version, see Appendix A.1.1). Appendix A.1.1 is on the record layer, not on the client hello; App. E.1 could have said "equals ClientHello.client_version, see Appendix A.4.1", but doesn't. (The language that suggests that TLS 1.0 servers may be doing better by sending {3, 0} in the record version number, in contradiction to what is implied by E.1 and A.1[.1], was only added with the TLS 1.0 specification, and only with a fuzzy "should".) > There is no requirement for a TLSv1 server to agree to talking > SSLv3 {3,1}, but it certainly is required to parse the SSLv3 > record procotol without hitches! This certainly would be a very reasonable requirement (as in the reverse case of SSL 3.0 servers when faced with the TLS 1.0 record protocol). One problem is that the specification does not say that it is a requirement. The more important problem is that various fielded servers don't behave as well as we would like them to (i.e. don't handle {3, 0} cleanly), whereas SSL 3.0-only servers showing the reverse problem (not handling {3, 1} cleanly) appear to be rather rare. Now it appears to be the case that most client implementations offering both SSL 3.0 and TLS 1.0 do send {3, 1} as both the record version number and the client hello version number, and appear to get along quite well. You could say that these clients focus on their role as TLS 1.0 clients (trying to interoperate with buggy TLS 1.0 servers as well), and try to *also* be SSL 3.0 clients (but without extra effort for interoperating with deficient servers). Thinking of it, it might actually be best if some clients use the highest supported version for the record version number, and others use the lowest supported version there, because this diversity increases the probability that server problems about not tolerating "strange" record version numbers will be found and fixed. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 19 12:55:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gab9P-00036K-Jk; Thu, 19 Oct 2006 12:53:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gab7n-0001rC-VK for tls@ietf.org; Thu, 19 Oct 2006 12:52:07 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gab0P-0006ea-KE for tls@ietf.org; Thu, 19 Oct 2006 12:44:33 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id SAA15554; Thu, 19 Oct 2006 18:44:21 +0200 (MESZ) From: Martin Rex Message-Id: <200610191644.SAA09002@uw1048.wdf.sap.corp> Subject: Re: [TLS] Open issue: Record Version Numbers To: bmoeller@acm.org (Bodo Moeller) Date: Thu, 19 Oct 2006 18:44:21 +0200 (MET DST) In-Reply-To: <20061019161706.GA22034@tau.invalid> from "Bodo Moeller" at Oct 19, 6 06:17:06 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@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: , Errors-To: tls-bounces@lists.ietf.org Bodo Moeller wrote: > > On Thu, Oct 19, 2006 at 03:59:53PM +0200, Martin Rex wrote: > > >> I don't think arguing which of them does it "rightfully" is very > >> useful (as Bodo pointed out, TLS 1.0 spec does not say that TLS > >> 1.0-only servers should accept {3,0} in the record version); > > > On the contrary. The version on the record protocol is a PDU encoding, > > and TLS was specifically designed to reuse most of SSLv3. > > Just like TLS 1.0 was designed to reuse most of SSL 3.0, SSL 3.0 was > designed to allow reuse in future protocol versions, and server > implementations of the SSL 3.0 specification should tolerate seeing > {3, 1} or later in the record version number used for the client > hello. I totally disagree. An Implementation of SSLv3 knows at best all PDUs up to and including {3,0}. It does NOT know whether there are any changes in the {3,1} record protocol, and by design, it should NOT try to parse records tagged with {3,1}. Existing patches to SSLv3 only server do not claim to parse the {3,1} record protocol, they try to parse inappropriately tagged {3,0} records instead. Similarly as a simple X.509 certificate that doesn't contain any X.509v3 attributes ought to be tagged as X.509v1. Implementations that do otherwise are broken. The original TLSv1 spec didn't contain a MUST, but rather a SHOULD, so we ought to retain a SHOULD, and not contort it to a MAY to cater the installed base of broken TLSv1 server implementations. The client should use the lowest protocol version it is willing to negotiate on the record protocol of the client hello, and the desired protocol version (per default the highest it implements) in the client protocol version field of the client hello. Technically, if a client would agree to either SSLv3 or TLSv1.1, but NOT TLSv1.0, then having a recommendation for sending {3,1} in the record protocol would be quite weird (I don't want to discuss whether such a combination makes sense). Anyway -- a reliable indicator for the server that the client is going to agree to a SSLv3 handshake is the presence of {3,0} in the record protocol of the client hello message. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 19 13:17:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GabVi-0007XV-Kc; Thu, 19 Oct 2006 13:16:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GabVh-0007XG-Uk for tls@ietf.org; Thu, 19 Oct 2006 13:16:49 -0400 Received: from moutng.kundenserver.de ([212.227.126.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GabVg-0006RY-HM for tls@ietf.org; Thu, 19 Oct 2006 13:16:49 -0400 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1GabVd0ZD9-0002kI; Thu, 19 Oct 2006 19:16:47 +0200 Received: by tau.invalid (Postfix, from userid 1000) id 67B484D8D; Thu, 19 Oct 2006 19:16:44 +0200 (CEST) Date: Thu, 19 Oct 2006 19:16:44 +0200 From: Bodo Moeller To: Martin Rex Subject: Re: [TLS] Open issue: Record Version Numbers Message-ID: <20061019171644.GA24175@tau.invalid> References: <20061019161706.GA22034@tau.invalid> <200610191644.SAA09002@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200610191644.SAA09002@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Thu, Oct 19, 2006 at 06:44:21PM +0200, Martin Rex wrote: > Bodo Moeller wrote: >> On Thu, Oct 19, 2006 at 03:59:53PM +0200, Martin Rex wrote: >>>> I don't think arguing which of them does it "rightfully" is very >>>> useful (as Bodo pointed out, TLS 1.0 spec does not say that TLS >>>> 1.0-only servers should accept {3,0} in the record version); >>> On the contrary. The version on the record protocol is a PDU encoding, >>> and TLS was specifically designed to reuse most of SSLv3. >> Just like TLS 1.0 was designed to reuse most of SSL 3.0, SSL 3.0 was >> designed to allow reuse in future protocol versions, and server >> implementations of the SSL 3.0 specification should tolerate seeing >> {3, 1} or later in the record version number used for the client >> hello. > I totally disagree. An Implementation of SSLv3 knows at best > all PDUs up to and including {3,0}. It does NOT know whether there > are any changes in the {3,1} record protocol, and by design, it > should NOT try to parse records tagged with {3,1}. > > Existing patches to SSLv3 only server do not claim to parse the > {3,1} record protocol, they try to parse inappropriately tagged > {3,0} records instead. > > Similarly as a simple X.509 certificate that doesn't contain any > X.509v3 attributes ought to be tagged as X.509v1. Implementations > that do otherwise are broken. TLS 1.0 vs. SSL 3.0 is different than X.509v3 vs. X509v1 because it is interactive: Faced with {3,1} records, a server that picks the SSL 3.0 protocol allows the client, in turn, to give the "You can't say we never tried / ain't it time we said goodbye" fatal alert. Oops, sorry, wrong song, make that "protocol_version". Remember that the SSL 3.0 specification and RFC 2426 and RFC 4346 all imply that the record version number field is the "highest version of the protocol supported by the client" (E.1 read in conjunction with A.1.1 or A.1). The language about "should send client hello messages using the SSL 3.0 record format and client hello structure" could reasonably be read as merely indicating that you can't send anything that can't be parsed by following the SSL 3.0 specification and still expect an SSL 3.0 handshake to succeed, in particular given that RFC 2246 doesn't explicitly require TLS 1.0-only servers to tolerate {3,0} in record version numbers. > Technically, if a client would agree to either SSLv3 or TLSv1.1, > but NOT TLSv1.0, then having a recommendation for sending {3,1} > in the record protocol would be quite weird Absolutely, but protocol versions that the client would agree to use make some sense for the record version number field. > Anyway -- a reliable indicator for the server that the client > is going to agree to a SSLv3 handshake is the presence of > {3,0} in the record protocol of the client hello message. Agreed. It just doesn't work the other way around, in practice: an SSL 3.0 handshake may be possible even though the client did not mention {3,0} anywhere. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 19 14:27:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gacb1-0003HB-PN; Thu, 19 Oct 2006 14:26:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gacaz-00038d-6P for tls@ietf.org; Thu, 19 Oct 2006 14:26:21 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GacMk-0000dW-SX for tls@ietf.org; Thu, 19 Oct 2006 14:11:40 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id UAA00622; Thu, 19 Oct 2006 20:11:33 +0200 (MESZ) From: Martin Rex Message-Id: <200610191811.UAA11377@uw1048.wdf.sap.corp> Subject: Re: [TLS] Open issue: Record Version Numbers To: bmoeller@acm.org (Bodo Moeller) Date: Thu, 19 Oct 2006 20:11:33 +0200 (MET DST) In-Reply-To: <20061019171644.GA24175@tau.invalid> from "Bodo Moeller" at Oct 19, 6 07:16:44 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@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: , Errors-To: tls-bounces@lists.ietf.org Bodo Moeller wrote: > > Remember that the SSL 3.0 specification and RFC 2426 and RFC 4346 all > imply that the record version number field is the "highest version of > the protocol supported by the client" (E.1 read in conjunction with > A.1.1 or A.1). Quite to the contrary. There is one missing word in RFC-2246 Appendix E, but I argue that it is a poor excuse for ignoring the quite clear comments on the purpose of the two seperate version foelds (client version and protocol version) where the actual data elements are defined. As I wrote in early July, rfc 2246 Appendix E reads: > TLS version 1.0 and SSL 3.0 are very similar; thus, supporting both > is easy. TLS clients who wish to negotiate with SSL 3.0 servers > should send client hello messages using the SSL 3.0 record format and > client hello structure, sending {3, 1} for the version field to note > that they support TLS 1.0. If the server supports only SSL 3.0, it > will respond with an SSL 3.0 server hello; if it supports TLS, with a > TLS server hello. The negotiation then proceeds as appropriate for > the negotiated protocol. the missing word is here: sending {3, 1} for the client_version field to note ^^^^^^^ > > The language about "should send client hello messages > using the SSL 3.0 record format and client hello structure" could > reasonably be read as merely indicating that you can't send anything > that can't be parsed by following the SSL 3.0 specification and still > expect an SSL 3.0 handshake to succeed, in particular given that > RFC 2246 doesn't explicitly require TLS 1.0-only servers to tolerate > {3,0} in record version numbers. I'm sorry, but if interoperability with SSLv3 is desired, this is a very obvious implication. And if "should send client hello messages using the SSL 3.0 record format and client hello structure" isn't clear, then I don't know what is clear. Most, if not all protocol specs have defects or ambiguities. The alleged ambiguity in Appendix E is fairly easy to figure by doing a consistency check on the descriptions of the three variants of version fiels "version, client_version, server_version" throughout the document plus a grain of common sense. The wording in rfc-2246 Appendix E suggests that this appendix was written before TLSv1.0 was finalized, because it is vague in two respects: it doesn't tell you wether the {3,1} record protocol differs somehow from the {3,0} record protocol, and it doesn't tell you whether the {3,1} ClientHello message differs from the {3,0} ClientHello _structure_. The record protocol NEVER EVER had a field to indicate the client_protocol version in any version of the spec. There are exactly two structures to carry the client_version, the ClientHello and the PreMasterSecret. And then there is the ServerHello structure which carries the server(-selected/negotiated) protocol version. This dicussion doesn't get us anywhere. My proposal is to fix the longstanding typo in Appendix E and to insert "client_" where it has been missing. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 19 20:03:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GahpX-000345-Lz; Thu, 19 Oct 2006 20:01:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GahpV-00033K-90 for tls@ietf.org; Thu, 19 Oct 2006 20:01:41 -0400 Received: from mailc.microsoft.com ([131.107.115.214] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GahpN-0005bZ-Rn for tls@ietf.org; Thu, 19 Oct 2006 20:01:41 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E803.partners.extranet.microsoft.com (10.251.56.169) with Microsoft SMTP Server id 8.0.665.7; Thu, 19 Oct 2006 17:01:31 -0700 Received: from tuk-hub-03.redmond.corp.microsoft.com ([157.54.70.29]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Thu, 19 Oct 2006 17:01:31 -0700 Received: from tk5-exhub-c104.redmond.corp.microsoft.com ([157.54.70.185]) by tuk-hub-03.redmond.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 17:01:30 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) with Microsoft SMTP Server id 8.0.665.7; Thu, 19 Oct 2006 17:01:30 -0700 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Thu, 19 Oct 2006 17:01:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Re: Straw poll about default PRF Date: Thu, 19 Oct 2006 17:01:29 -0700 Message-ID: <802A881C87166D4597F9EEFC3F04F4F8024CF213@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> In-Reply-To: <1161271414.26581.15.camel@localhost.localdomain> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Re: Straw poll about default PRF Thread-Index: AcbzlRjRiJ6EeU+VTPKjTz/kZlP5swARZNOQ From: Ari Medvinsky To: Simon Josefsson , Russ Housley X-OriginalArrivalTime: 20 Oct 2006 00:01:30.0146 (UTC) FILETIME=[E5437020:01C6F3DA] X-Spam-Score: 0.0 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: Pasi Eronen , tls mailing list X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org I prefer method 1, I think that it's a cleaner approach then making prf explicit in all new ciphersuites=20 -----Original Message----- From: Simon Josefsson [mailto:jas@extundo.com]=20 Sent: Thursday, October 19, 2006 8:24 AM To: Russ Housley Cc: Pasi Eronen; tls mailing list Subject: Re: [TLS] Re: Straw poll about default PRF On Thu, 2006-10-19 at 10:26 -0400, Russ Housley wrote: > Simon: >=20 > If the TLS 1.2 PRF gets broken, can't a server demand the use of a=20 > ciphersuite that specifies its own yet-to-be-broken PRFs? Yes, true, pending that such ciphersuites are specified and deployed. It could also fall back to TLS 1.1 and use the old PRF. If TLS >=3D 1.2 fixes other security problems, compared to TLS 1.1, there would be a tradeoff: either run with the risks with a broken TLS 1.2 PRF or the risks of the things broken in TLS 1.1 but fixed in TLS >=3D 1.2. I consider it unlikely that the TLS 1.2 PRF will be broken faster than the TLS 1.0 PRF -- although stranger things have happened... -- hence my preference is only a mild one. It is primarily based on the first bullet below. /Simon >=20 > Russ >=20 > At 09:37 AM 10/19/2006, Simon Josefsson wrote: > >"Pasi Eronen" writes: > > > > > The two main alternatives seem to be as follows: > > > > > > 1) Default PRF is tied to the TLS version number: in other words, > > > ciphersuites that don't specify anything else (including all > > > currently defined ciphersuites) will use the new TLS 1.2 PRF > > > (details of which are TBD) when TLS 1.2 is negotiated. > > > > > > 2) The new PRF will be used only for new ciphersuites that > > > explicitly say so; all currently defined ciphersuites continue to > > > use the current (TLS 1.0/1.1) PRF even when TLS 1.2 is negotiated. > >... > > > Please state your opinion on the WG list within a week. > > > >I have a (mild) preference for alternative 2 for these reasons: > > > >* I prefer if all negotiations that influence which cryptographic > > algorithms are used is negotiated through the cipher suites. > > > >* I prefer to de-couple PRF negotiation from TLS version level > > negotiation. > > > > Consider this: What if the new TLS 1.2 default PRF is broken, but > > the current TLS PRF is not broken? > > > > What should implements do? Stop using TLS 1.2 and negotiate TLS > > 1.1? That would be quite unfortunate, especially if TLS 1.2 fixes > > other security problems or add important new features that > > implementations need. > > > >* The TLS version number negotiation appears to be fragile. > > (Although, if TLS 1.2 fixed this problem with stricter text, and > > implementations followed it, this argument would go away.) > > > >To me, there is only one disadvantage with alternative 2: > > > >* We need to specify new cipher suites that use the new PRF. That's > > some work, but seems do-able. > > > >I could change my mind if some good arguments against 2 are presented. > > > >/Simon > > > >_______________________________________________ > >TLS mailing list > >TLS@lists.ietf.org > >https://www1.ietf.org/mailman/listinfo/tls >=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 19 20:22:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gai9Q-0007hs-CY; Thu, 19 Oct 2006 20:22:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gai9O-0007hG-Mq for tls@ietf.org; Thu, 19 Oct 2006 20:22:14 -0400 Received: from mail-eur1.microsoft.com ([213.199.128.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gai9L-0000Tz-9q for tls@ietf.org; Thu, 19 Oct 2006 20:22:14 -0400 Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Oct 2006 01:22:10 +0100 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Straw poll about default PRF Date: Fri, 20 Oct 2006 01:22:08 +0100 Message-ID: In-Reply-To: <000001c6f37f$bece5ff0$932a15ac@NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Straw poll about default PRF Thread-Index: Acbzf75VtCl0xy4NRoSed78thZ+vwQAXe+qA References: <000001c6f37f$bece5ff0$932a15ac@NOE.Nokia.com> From: "Stefan Santesson" To: "Pasi Eronen" , "tls mailing list" X-OriginalArrivalTime: 20 Oct 2006 00:22:10.0337 (UTC) FILETIME=[C8799110:01C6F3DD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org I vote for Option 1. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Pasi Eronen [mailto:pasi.eronen@nokia.com] > Sent: den 19 oktober 2006 06:09 > To: tls mailing list > Subject: [TLS] Straw poll about default PRF >=20 >=20 > Let's try to close the default PRF issue before the San Diego > meeting. >=20 > To summarize the issue: to meet its chartered goal of removing > dependencies to MD5 and SHA-1, TLS WG will most likely specify a > PRF that is not based on MD5/SHA-1 (the exact details will be > determined separately). TLS 1.2 will also most likely allow new > ciphersuites to specify a ciphersuite-specific PRF (e.g. the > GOST ciphersuites). >=20 > The remaining question is exactly how the PRF negotiation will > work for those ciphersuites that don't specify anything, especially > all the currently defined ciphersuites. >=20 > The two main alternatives seem to be as follows: >=20 > 1) Default PRF is tied to the TLS version number: in other words, > ciphersuites that don't specify anything else (including all > currently defined ciphersuites) will use the new TLS 1.2 PRF > (details of which are TBD) when TLS 1.2 is negotiated. >=20 > 2) The new PRF will be used only for new ciphersuites that > explicitly say so; all currently defined ciphersuites continue to > use the current (TLS 1.0/1.1) PRF even when TLS 1.2 is negotiated. >=20 > Clearly neither alternative is horribly broken or unworkable, so this > is mainly a question of "which seems nicer". Some arguments that > have been made are as follows: >=20 > - Option 1 is not necessary, since there are no practical attacks > against the current PRF (yet) > - Option 1 can cause implementation and/or interop problems > - On the other hand, changing PRF in SSLv3->TLS1.0 did not cause > big implementation and/or interop problems (there are interop > problems, but not because of the PRF). > - With option 1, all ciphersuites benefit without having to get > new numbers (and there are lots of RFCs that would have to > be updated). > - In order to have secure negotiation, all the PRFs that both > sides support have to be secure against a specific kind of > active attack (true, but would this suggest option 1 or 2, > or neither?). > - TLS versions older than 1.2 have to be enabled for long time > (true, but would this suggest option 1 or 2, or neither?). >=20 > Please state your opinion on the WG list within a week. When > judging the WG consensus, I will also take into account the > sense of the room at Montreal, where support for option 1 was > practically unanimous. >=20 > Best regards, > Pasi >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 19 20:41:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaiRJ-0002nh-Sm; Thu, 19 Oct 2006 20:40:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaiRI-0002nP-Ha for tls@ietf.org; Thu, 19 Oct 2006 20:40:44 -0400 Received: from gate01out.mcdata.com ([208.47.132.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaiRH-0003vw-4U for tls@ietf.org; Thu, 19 Oct 2006 20:40:44 -0400 Received: from mc4gate01.mcdata.com ([172.16.11.205]) by gate01out.mcdata.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 19 Oct 2006 18:40:42 -0600 Received: from MC4EXCH04.mcdata.com ([172.16.11.120]) by mc4gate01.mcdata.com with InterScan Message Security Suite; Thu, 19 Oct 2006 18:40:42 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Straw poll about default PRF Date: Thu, 19 Oct 2006 18:40:41 -0600 Message-ID: <153205C2B0ED9B4EAB33119816A012FA0743A1@MC4EXCH04.mcdata.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Straw poll about default PRF Thread-Index: Acbzf75VtCl0xy4NRoSed78thZ+vwQAXe+qAAACe/bA= From: "Larry Hofer" To: "Stefan Santesson" , "Pasi Eronen" , "tls mailing list" X-imss-version: 2.043 X-imss-result: Passed X-imss-scanInfo: M:P L:E SM:0 X-imss-tmaseResult: TT:0 TS:0.0000 TC:00 TRN:0 TV:3.6.1039(14762.000) X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:3 C:2 M:2 S:2 R:2 (0.5000 0.5000) X-OriginalArrivalTime: 20 Oct 2006 00:40:42.0350 (UTC) FILETIME=[5F4948E0:01C6F3E0] X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Option 1 sounds good.=0D Larry Hofer=0D -----Original Message----- From: Stefan Santesson [mailto:stefans@microsoft.com]=0D Sent: Thursday, October 19, 2006 6:22 PM To: Pasi Eronen; tls mailing list Subject: RE: [TLS] Straw poll about default PRF I vote for Option 1. Stefan Santesson Senior Program Manager Windows Security, Standards > -----Original Message----- > From: Pasi Eronen [mailto:pasi.eronen@nokia.com] > Sent: den 19 oktober 2006 06:09 > To: tls mailing list > Subject: [TLS] Straw poll about default PRF >=0D >=0D > Let's try to close the default PRF issue before the San Diego meeting. >=0D > To summarize the issue: to meet its chartered goal of removing=0D > dependencies to MD5 and SHA-1, TLS WG will most likely specify a PRF=0D > that is not based on MD5/SHA-1 (the exact details will be determined=0D > separately). TLS 1.2 will also most likely allow new ciphersuites to=0D > specify a ciphersuite-specific PRF (e.g. the GOST ciphersuites). >=0D > The remaining question is exactly how the PRF negotiation will work=0D > for those ciphersuites that don't specify anything, especially all the > currently defined ciphersuites. >=0D > The two main alternatives seem to be as follows: >=0D > 1) Default PRF is tied to the TLS version number: in other words, > ciphersuites that don't specify anything else (including all > currently defined ciphersuites) will use the new TLS 1.2 PRF > (details of which are TBD) when TLS 1.2 is negotiated. >=0D > 2) The new PRF will be used only for new ciphersuites that > explicitly say so; all currently defined ciphersuites continue to > use the current (TLS 1.0/1.1) PRF even when TLS 1.2 is negotiated. >=0D > Clearly neither alternative is horribly broken or unworkable, so this=0D > is mainly a question of "which seems nicer". Some arguments that have=0D > been made are as follows: >=0D > - Option 1 is not necessary, since there are no practical attacks > against the current PRF (yet) > - Option 1 can cause implementation and/or interop problems > - On the other hand, changing PRF in SSLv3->TLS1.0 did not cause > big implementation and/or interop problems (there are interop > problems, but not because of the PRF). > - With option 1, all ciphersuites benefit without having to get > new numbers (and there are lots of RFCs that would have to > be updated). > - In order to have secure negotiation, all the PRFs that both > sides support have to be secure against a specific kind of > active attack (true, but would this suggest option 1 or 2, > or neither?). > - TLS versions older than 1.2 have to be enabled for long time > (true, but would this suggest option 1 or 2, or neither?). >=0D > Please state your opinion on the WG list within a week. When judging=0D > the WG consensus, I will also take into account the sense of the room=0D > at Montreal, where support for option 1 was practically unanimous. >=0D > Best regards, > Pasi >=0D >=0D > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls SPECIAL NOTICE=0D All information transmitted hereby is intended only for the use of the addressee(s) named above and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of confidential and privileged information is prohibited. If the reader of this message is not the intended recipient(s) or the employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that you must not read this transmission and that= disclosure, copying, printing, distribution or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. Anyone who receives confidential and privileged information in error should notify us immediately by telephone and mail the original message to us at the above address and destroy all copies. To the extent any portion of= this communication contains public information, no such restrictions apply to= that information. (gate01) _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 19 21:23:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gaj57-0005tj-IB; Thu, 19 Oct 2006 21:21:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gaj57-0005t2-7Q for tls@ietf.org; Thu, 19 Oct 2006 21:21:53 -0400 Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gaj55-0002mT-8b for tls@ietf.org; Thu, 19 Oct 2006 21:21:53 -0400 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k9K1LiIV018816 for ; Thu, 19 Oct 2006 21:21:45 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id k9K1LhJv024302 for ; Thu, 19 Oct 2006 21:21:44 -0400 Received: from [127.0.0.1] (dhcp-172-16-25-208.sfbay.redhat.com [172.16.25.208]) by potter.sfbay.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k9K1Lc3G009121 for ; Thu, 19 Oct 2006 21:21:40 -0400 Message-ID: <453824A0.3040401@redhat.com> Date: Thu, 19 Oct 2006 18:21:36 -0700 From: Wan-Teh Chang User-Agent: Thunderbird 2.0b1pre (Windows/20061019) MIME-Version: 1.0 To: tls mailing list Subject: Re: [TLS] Straw poll about default PRF References: <000001c6f37f$bece5ff0$932a15ac@NOE.Nokia.com> In-Reply-To: <000001c6f37f$bece5ff0$932a15ac@NOE.Nokia.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Content-Type: multipart/mixed; boundary="===============0644440102==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0644440102== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms070508050800010801070508" This is a cryptographically signed message in MIME format. --------------ms070508050800010801070508 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Pasi Eronen wrote: > Let's try to close the default PRF issue before the San Diego > meeting. > > To summarize the issue: to meet its chartered goal of removing > dependencies to MD5 and SHA-1, TLS WG will most likely specify a > PRF that is not based on MD5/SHA-1 (the exact details will be > determined separately). TLS 1.2 will also most likely allow new > ciphersuites to specify a ciphersuite-specific PRF (e.g. the > GOST ciphersuites). > > The remaining question is exactly how the PRF negotiation will > work for those ciphersuites that don't specify anything, especially > all the currently defined ciphersuites. > > The two main alternatives seem to be as follows: > > 1) Default PRF is tied to the TLS version number: in other words, > ciphersuites that don't specify anything else (including all > currently defined ciphersuites) will use the new TLS 1.2 PRF > (details of which are TBD) when TLS 1.2 is negotiated. > > 2) The new PRF will be used only for new ciphersuites that > explicitly say so; all currently defined ciphersuites continue to > use the current (TLS 1.0/1.1) PRF even when TLS 1.2 is negotiated. I vote for option 1. Wan-Teh Chang --------------ms070508050800010801070508 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKWDCC BSgwggQQoAMCAQICECPc+9+WtsOZqiiOT1eYr6cwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMR0wGwYDVQQLExRBZGRUcnVzdCBUVFAgTmV0 d29yazEhMB8GA1UEAxMYQWRkVHJ1c3QgQ2xhc3MgMSBDQSBSb290MB4XDTA1MTIyMzAwMDAw MFoXDTA2MTIyMzIzNTk1OVowgdsxNTAzBgNVBAsTLENvbW9kbyBUcnVzdCBOZXR3b3JrIC0g UEVSU09OQSBOT1QgVkFMSURBVEVEMUYwRAYDVQQLEz1UZXJtcyBhbmQgQ29uZGl0aW9ucyBv ZiB1c2U6IGh0dHA6Ly93d3cuY29tb2RvLm5ldC9yZXBvc2l0b3J5MR8wHQYDVQQLExYoYyky MDAzIENvbW9kbyBMaW1pdGVkMRYwFAYDVQQDEw1XYW4tVGVoIENoYW5nMSEwHwYJKoZIhvcN AQkBFhJ3dGNoYW5nQHJlZGhhdC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJZ3 pYgLLfB2IU5Rdd4B/1Z7p391Z+vjH2pCEeQMWxK966ptunHqLmA8Iz/8Tiy5KN9LKRkV9Q2c zvWjapJeyiutrictOZCY2qkRMG6eTbDDT8Tz6qO7iRnUK7JkXs2cZtlk442Xgky+xcLr1cCC RJ8w3d/ul4HKdGZwtsYFLkLpAgMBAAGjggHfMIIB2zAdBgNVHQ4EFgQUAsOMfMcFVfub10xu 3ycfUWaYHO4wDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYB BQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsG AQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQ UzB3BgNVHR8EcDBuMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRUcnVzdENs YXNzMUNBUm9vdC5jcmwwNKAyoDCGLmh0dHA6Ly9jcmwuY29tb2RvLm5ldC9BZGRUcnVzdENs YXNzMUNBUm9vdC5jcmwwgYYGCCsGAQUFBwEBBHoweDA7BggrBgEFBQcwAoYvaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQWRkVHJ1c3RVVE5DbGllbnRDQS5jcnQwOQYIKwYBBQUHMAKGLWh0 dHA6Ly9jcnQuY29tb2RvLm5ldC9BZGRUcnVzdFVUTkNsaWVudENBLmNydDAdBgNVHREEFjAU gRJ3dGNoYW5nQHJlZGhhdC5jb20wDQYJKoZIhvcNAQEFBQADggEBAGpDustBazwJLV/u3OHE gGKhU5QxPPnhJcAs4hPn6oG2de85pKS9/mioaEhf1Huvu8cBaEMIe0dQoGQuqOIiM38WFXRI N4m0SoTu2pw4MXIy9t20kNiqq0ISf/O+kLJ6QrIsRurqw7WexkGkv8S4Z+hgls1wFXTBFsnu vZsgqqtDc2s6EHMh9Wqk4WWCMsr8WExtsst5pnLWHV7BbiquqHrbFZhwRLiWjVrBNDrVT+ym lmZilFt8GHjdrJs3aLvuptP+yzDqIE0jFtlVNn5gLzYSKMMx8twn9yJTHCC2AwAbfmGNf75o yPCS8MqAqupN2B+oST9MqdF6ZpVcxVdR61QwggUoMIIEEKADAgECAhAj3PvflrbDmaoojk9X mK+nMA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBB QjEdMBsGA1UECxMUQWRkVHJ1c3QgVFRQIE5ldHdvcmsxITAfBgNVBAMTGEFkZFRydXN0IENs YXNzIDEgQ0EgUm9vdDAeFw0wNTEyMjMwMDAwMDBaFw0wNjEyMjMyMzU5NTlaMIHbMTUwMwYD VQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQG A1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UE AxMNV2FuLVRlaCBDaGFuZzEhMB8GCSqGSIb3DQEJARYSd3RjaGFuZ0ByZWRoYXQuY29tMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCWd6WICy3wdiFOUXXeAf9We6d/dWfr4x9qQhHk DFsSveuqbbpx6i5gPCM//E4suSjfSykZFfUNnM71o2qSXsorra4nLTmQmNqpETBunk2ww0/E 8+qju4kZ1CuyZF7NnGbZZOONl4JMvsXC69XAgkSfMN3f7peBynRmcLbGBS5C6QIDAQABo4IB 3zCCAdswHQYDVR0OBBYEFALDjHzHBVX7m9dMbt8nH1FmmBzuMA4GA1UdDwEB/wQEAwIFoDAM BgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYd aHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwdwYDVR0fBHAwbjA2oDSgMoYwaHR0cDov L2NybC5jb21vZG9jYS5jb20vQWRkVHJ1c3RDbGFzczFDQVJvb3QuY3JsMDSgMqAwhi5odHRw Oi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1c3RDbGFzczFDQVJvb3QuY3JsMIGGBggrBgEFBQcB AQR6MHgwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0FkZFRydXN0VVRO Q2xpZW50Q0EuY3J0MDkGCCsGAQUFBzAChi1odHRwOi8vY3J0LmNvbW9kby5uZXQvQWRkVHJ1 c3RVVE5DbGllbnRDQS5jcnQwHQYDVR0RBBYwFIESd3RjaGFuZ0ByZWRoYXQuY29tMA0GCSqG SIb3DQEBBQUAA4IBAQBqQ7rLQWs8CS1f7tzhxIBioVOUMTz54SXALOIT5+qBtnXvOaSkvf5o qGhIX9R7r7vHAWhDCHtHUKBkLqjiIjN/FhV0SDeJtEqE7tqcODFyMvbdtJDYqqtCEn/zvpCy ekKyLEbq6sO1nsZBpL/EuGfoYJbNcBV0wRbJ7r2bIKqrQ3NrOhBzIfVqpOFlgjLK/FhMbbLL eaZy1h1ewW4qrqh62xWYcES4lo1awTQ61U/sppZmYpRbfBh43aybN2i77qbT/ssw6iBNIxbZ VTZ+YC82EijDMfLcJ/ciUxwgtgMAG35hjX++aMjwkvDKgKrqTdgfqEk/TKnRemaVXMVXUetU MYIC7DCCAugCAQEweTBlMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxHTAb BgNVBAsTFEFkZFRydXN0IFRUUCBOZXR3b3JrMSEwHwYDVQQDExhBZGRUcnVzdCBDbGFzcyAx IENBIFJvb3QCECPc+9+WtsOZqiiOT1eYr6cwCQYFKw4DAhoFAKCCAckwGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMDIwMDEyMTM2WjAjBgkqhkiG9w0B CQQxFgQUM28CzVmIJ85ZNJ9odehsL+m6uCswUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0 IEFCMR0wGwYDVQQLExRBZGRUcnVzdCBUVFAgTmV0d29yazEhMB8GA1UEAxMYQWRkVHJ1c3Qg Q2xhc3MgMSBDQSBSb290AhAj3PvflrbDmaoojk9XmK+nMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMR0wGwYDVQQLExRBZGRUcnVz dCBUVFAgTmV0d29yazEhMB8GA1UEAxMYQWRkVHJ1c3QgQ2xhc3MgMSBDQSBSb290AhAj3Pvf lrbDmaoojk9XmK+nMA0GCSqGSIb3DQEBAQUABIGAHB+W5Jtma9WZSKTNl4sVMbNXAKhMyPNI kHuUL+1YcSJ0LhxMo4CIKpWfuaWLYDBEhQnRtc6Ya8Mde/IDfL55lCWmHqLpV2Rqxs5hSEIk Po39fxH6p7XyyEJmRP92DLw/68/h+FO+Ft7gKJjQ89Fca0Xe/ubJFzCy67j2FthB1TUAAAAA AAA= --------------ms070508050800010801070508-- --===============0644440102== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============0644440102==-- From tls-bounces@lists.ietf.org Fri Oct 20 03:05:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaoQZ-0005Gn-2M; Fri, 20 Oct 2006 03:04:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaoQX-0005FW-Bq for tls@ietf.org; Fri, 20 Oct 2006 03:04:21 -0400 Received: from moutng.kundenserver.de ([212.227.126.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaoQD-0000LE-78 for tls@ietf.org; Fri, 20 Oct 2006 03:04:21 -0400 Received: from [80.142.178.138] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis), id 0MKwpI-1GaoQB2yUA-0004VT; Fri, 20 Oct 2006 09:04:00 +0200 Received: by tau.invalid (Postfix, from userid 1000) id 6E5694E39; Fri, 20 Oct 2006 09:03:58 +0200 (CEST) Date: Fri, 20 Oct 2006 09:03:58 +0200 From: Bodo Moeller To: Martin Rex Subject: Re: [TLS] Open issue: Record Version Numbers Message-ID: <20061020070358.GA26457@tau.invalid> References: <20061019171644.GA24175@tau.invalid> <200610191811.UAA11377@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200610191811.UAA11377@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Thu, Oct 19, 2006 at 08:11:33PM +0200, Martin Rex wrote: > Bodo Moeller wrote: >> Remember that the SSL 3.0 specification and RFC 2426 and RFC 4346 all >> imply that the record version number field is the "highest version of >> the protocol supported by the client" (E.1 read in conjunction with >> A.1.1 or A.1). > Quite to the contrary. I am fully aware that language has been added in RFC 2426 and RFC 4346 that indicates that the record version number field should be be {3, 0} for backwards compatibility. However, here I was explicitly referring to Appendix E.1, which consistently has said something else; look at the SSL 3.0 specification, or at RFC 2426, or at RFC 4346. Yes, perfect specifications probably would always have said that the record version number field should use the lowest protocol version supported by the client. Well, but the SSL 3.0 specification didn't do this, the TLS 1.0 specification arguably tried to do it, and the TLS 1.1 specification again failed to do so! If as a client you want to offer the choice between TLS 1.0 and TLS 1.1, then according to RFC 4346 you should ("SHOULD", even) use the SSL 3.0 record format, which would imply sending {3, 0} as the record version number even though {3, 0} does not designate a protocol version supported by the client! So, after all, the presence of {3, 0} in the record protocol of the client hello message is *not* a reliable indicator for the server that the client is going to agree to a SSL 3.0 handshake ... This is something we had agreed upon before, but I have to take this back, at least if implementors take this part of RFC 4346 that seriously. What remains is my main conclusion that the language in the specification in this regards is a total mess, and that we can't just look what we would *like* the specification to be, but mostly at what will work best with the implementations that are actually out there. > My proposal is to fix > the longstanding typo in Appendix E and to insert "client_" > where it has been missing. I totally agree to this. It is absolutely clear that Appendix E should mention client_version explicitly when saying where the client must put the highest supported version to be used for key agreement. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Oct 20 06:16:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GarP3-0001l4-DN; Fri, 20 Oct 2006 06:15:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GarP2-0001ky-LG for tls@ietf.org; Fri, 20 Oct 2006 06:15:00 -0400 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GarP1-0007ig-7j for tls@ietf.org; Fri, 20 Oct 2006 06:15:00 -0400 Received: from pc6 (1Cust62.tnt104.lnd4.gbr.da.uu.net [213.116.56.62]) by ranger.systems.pipex.net (Postfix) with SMTP id BACECE0005BC; Fri, 20 Oct 2006 11:14:45 +0100 (BST) Message-ID: <008201c6f427$43353460$0601a8c0@pc6> From: "tom.petch" To: "Pasi Eronen" , "tls mailing list" References: <000001c6f37f$bece5ff0$932a15ac@NOE.Nokia.com> Subject: Re: [TLS] Straw poll about default PRF Date: Fri, 20 Oct 2006 09:56:28 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" 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: , Errors-To: tls-bounces@lists.ietf.org Option 2 (Option 1 may be suitable for the present situation but may become a liability at the next version change. Option 2 gives us the better long term control). Tom Petch ----- Original Message ----- From: "Pasi Eronen" To: "tls mailing list" Sent: Thursday, October 19, 2006 3:09 PM Subject: [TLS] Straw poll about default PRF > > Let's try to close the default PRF issue before the San Diego > meeting. > > To summarize the issue: to meet its chartered goal of removing > dependencies to MD5 and SHA-1, TLS WG will most likely specify a > PRF that is not based on MD5/SHA-1 (the exact details will be > determined separately). TLS 1.2 will also most likely allow new > ciphersuites to specify a ciphersuite-specific PRF (e.g. the > GOST ciphersuites). > > The remaining question is exactly how the PRF negotiation will > work for those ciphersuites that don't specify anything, especially > all the currently defined ciphersuites. > > The two main alternatives seem to be as follows: > > 1) Default PRF is tied to the TLS version number: in other words, > ciphersuites that don't specify anything else (including all > currently defined ciphersuites) will use the new TLS 1.2 PRF > (details of which are TBD) when TLS 1.2 is negotiated. > > 2) The new PRF will be used only for new ciphersuites that > explicitly say so; all currently defined ciphersuites continue to > use the current (TLS 1.0/1.1) PRF even when TLS 1.2 is negotiated. > > Clearly neither alternative is horribly broken or unworkable, so this > is mainly a question of "which seems nicer". Some arguments that > have been made are as follows: > > - Option 1 is not necessary, since there are no practical attacks > against the current PRF (yet) > - Option 1 can cause implementation and/or interop problems > - On the other hand, changing PRF in SSLv3->TLS1.0 did not cause > big implementation and/or interop problems (there are interop > problems, but not because of the PRF). > - With option 1, all ciphersuites benefit without having to get > new numbers (and there are lots of RFCs that would have to > be updated). > - In order to have secure negotiation, all the PRFs that both > sides support have to be secure against a specific kind of > active attack (true, but would this suggest option 1 or 2, > or neither?). > - TLS versions older than 1.2 have to be enabled for long time > (true, but would this suggest option 1 or 2, or neither?). > > Please state your opinion on the WG list within a week. When > judging the WG consensus, I will also take into account the > sense of the room at Montreal, where support for option 1 was > practically unanimous. > > Best regards, > Pasi > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Oct 20 06:52:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaryR-0000EK-0S; Fri, 20 Oct 2006 06:51:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GaryO-0000EE-SW for tls@ietf.org; Fri, 20 Oct 2006 06:51:32 -0400 Received: from nat194.certicom.com ([66.48.18.194] helo=mail.ca.certicom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GaryH-0006kM-ER for tls@ietf.org; Fri, 20 Oct 2006 06:51:32 -0400 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 94AAA102C1987 for ; Fri, 20 Oct 2006 06:51:20 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17344-66 for ; Fri, 20 Oct 2006 06:51:17 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 985A3102C6054 for ; Fri, 20 Oct 2006 06:51:17 -0400 (EDT) In-Reply-To: <000001c6f37f$bece5ff0$932a15ac@NOE.Nokia.com> To: "tls mailing list" Subject: Re: [TLS] Straw poll about default PRF MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Rob Dugal Date: Fri, 20 Oct 2006 06:45:27 -0400 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 7.0.1|January 17, 2006) at 10/20/2006 06:49:45 AM, Serialize complete at 10/20/2006 06:49:45 AM X-Spam-Score: 0.5 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Content-Type: multipart/mixed; boundary="===============0893102380==" Errors-To: tls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============0893102380== Content-Type: multipart/alternative; boundary="=_alternative 003B9F648525720D_=" This is a multipart message in MIME format. --=_alternative 003B9F648525720D_= Content-Type: text/plain; charset="US-ASCII" I prefer option 1. ----------------------------------------------- Robert Dugal Member of Development Group Certicom Corp. EMAIL: rdugal@certicom.com PHONE: (905) 501-3848 FAX : (905) 507-4230 WEBSITE: www.certicom.com "Pasi Eronen" wrote on 10/19/2006 09:09:01 AM: > > Let's try to close the default PRF issue before the San Diego > meeting. > > To summarize the issue: to meet its chartered goal of removing > dependencies to MD5 and SHA-1, TLS WG will most likely specify a > PRF that is not based on MD5/SHA-1 (the exact details will be > determined separately). TLS 1.2 will also most likely allow new > ciphersuites to specify a ciphersuite-specific PRF (e.g. the > GOST ciphersuites). > > The remaining question is exactly how the PRF negotiation will > work for those ciphersuites that don't specify anything, especially > all the currently defined ciphersuites. > > The two main alternatives seem to be as follows: > > 1) Default PRF is tied to the TLS version number: in other words, > ciphersuites that don't specify anything else (including all > currently defined ciphersuites) will use the new TLS 1.2 PRF > (details of which are TBD) when TLS 1.2 is negotiated. > > 2) The new PRF will be used only for new ciphersuites that > explicitly say so; all currently defined ciphersuites continue to > use the current (TLS 1.0/1.1) PRF even when TLS 1.2 is negotiated. > > Clearly neither alternative is horribly broken or unworkable, so this > is mainly a question of "which seems nicer". Some arguments that > have been made are as follows: > > - Option 1 is not necessary, since there are no practical attacks > against the current PRF (yet) > - Option 1 can cause implementation and/or interop problems > - On the other hand, changing PRF in SSLv3->TLS1.0 did not cause > big implementation and/or interop problems (there are interop > problems, but not because of the PRF). > - With option 1, all ciphersuites benefit without having to get > new numbers (and there are lots of RFCs that would have to > be updated). > - In order to have secure negotiation, all the PRFs that both > sides support have to be secure against a specific kind of > active attack (true, but would this suggest option 1 or 2, > or neither?). > - TLS versions older than 1.2 have to be enabled for long time > (true, but would this suggest option 1 or 2, or neither?). > > Please state your opinion on the WG list within a week. When > judging the WG consensus, I will also take into account the > sense of the room at Montreal, where support for option 1 was > practically unanimous. > > Best regards, > Pasi > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls --=_alternative 003B9F648525720D_= Content-Type: text/html; charset="US-ASCII"
I prefer option 1.

-----------------------------------------------
Robert Dugal
Member of Development Group
Certicom Corp.
EMAIL: rdugal@certicom.com
PHONE: (905) 501-3848
FAX  : (905) 507-4230
WEBSITE: www.certicom.com

"Pasi Eronen" <pasi.eronen@nokia.com> wrote on 10/19/2006 09:09:01 AM:

>
> Let's try to close the default PRF issue before the San Diego
> meeting.
>
> To summarize the issue: to meet its chartered goal of removing
> dependencies to MD5 and SHA-1, TLS WG will most likely specify a
> PRF that is not based on MD5/SHA-1 (the exact details will be
> determined separately). TLS 1.2 will also most likely allow new
> ciphersuites to specify a ciphersuite-specific PRF (e.g. the
> GOST ciphersuites).
>
> The remaining question is exactly how the PRF negotiation will
> work for those ciphersuites that don't specify anything, especially
> all the currently defined ciphersuites.
>
> The two main alternatives seem to be as follows:
>
>    1) Default PRF is tied to the TLS version number: in other words,
>    ciphersuites that don't specify anything else (including all
>    currently defined ciphersuites) will use the new TLS 1.2 PRF
>    (details of which are TBD) when TLS 1.2 is negotiated.
>
>    2) The new PRF will be used only for new ciphersuites that
>    explicitly say so; all currently defined ciphersuites continue to
>    use the current (TLS 1.0/1.1) PRF even when TLS 1.2 is negotiated.
>
> Clearly neither alternative is horribly broken or unworkable, so this
> is mainly a question of "which seems nicer". Some arguments that
> have been made are as follows:
>
> - Option 1 is not necessary, since there are no practical attacks
>   against the current PRF (yet)
> - Option 1 can cause implementation and/or interop problems
> - On the other hand, changing PRF in SSLv3->TLS1.0 did not cause
>   big implementation and/or interop problems (there are interop
>   problems, but not because of the PRF).
> - With option 1, all ciphersuites benefit without having to get
>   new numbers (and there are lots of RFCs that would have to
>   be updated).
> - In order to have secure negotiation, all the PRFs that both
>   sides support have to be secure against a specific kind of
>   active attack (true, but would this suggest option 1 or 2,
>   or neither?).
> - TLS versions older than 1.2 have to be enabled for long time
>   (true, but would this suggest option 1 or 2, or neither?).
>
> Please state your opinion on the WG list within a week. When
> judging the WG consensus, I will also take into account the
> sense of the room at Montreal, where support for option 1 was
> practically unanimous.
>
> Best regards,
> Pasi
>
>
> _______________________________________________
> TLS mailing list
> TLS@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls
 --=_alternative 003B9F648525720D_=-- --===============0893102380== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============0893102380==-- From tls-bounces@lists.ietf.org Fri Oct 20 08:27:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GatS0-00031N-U4; Fri, 20 Oct 2006 08:26:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GatRz-00031F-VP for tls@ietf.org; Fri, 20 Oct 2006 08:26:11 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GatRy-00050G-BT for tls@ietf.org; Fri, 20 Oct 2006 08:26:11 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9KCPxdP020943; Fri, 20 Oct 2006 15:26:06 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Oct 2006 15:26:05 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 20 Oct 2006 15:26:04 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Open issue: Record Version Numbers Date: Fri, 20 Oct 2006 15:26:12 +0300 Message-ID: In-Reply-To: <20061020070358.GA26457@tau.invalid> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Open issue: Record Version Numbers Thread-Index: Acb0FpwcjLhk66gnSJSuP9vo79s/XgAK5KHA From: To: X-OriginalArrivalTime: 20 Oct 2006 12:26:04.0978 (UTC) FILETIME=[E989D120:01C6F442] X-Spam-Score: 0.2 (/) X-Scan-Signature: a2c12dacc0736f14d6b540e805505a86 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Bodo Moeller wrote: > What remains is my main conclusion that the language in the > specification in this regards is a total mess, and that we can't just > look what we would *like* the specification to be, but mostly at what > will work best with the implementations that are actually out there. I agree. Here's some suggested text; let's see if we can improve on it somehow... In Section 6.2.1, when describing the version field, add the=20 following text: "Note that a client that supports multiple versions of TLS may not know what version will be employed before it receives ServerHello. See Appendix E for discussion about what record layer version number should be employed for ClientHello." And rewrite=20 E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0 For historical reasons and in order to avoid a profligate consumption of reserved port numbers, application protocols which are secured by various versions of TLS (1.0, 1.1, and 1.2) and SSL (2.0 and 3.0) all frequently share the same connection port: for example, the https protocol (HTTP secured by SSL or TLS) uses port 443 regardless of which security protocol it is using. Thus, some mechanism must be determined to distinguish and negotiate among the various protocols. TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use compatible ClientHello messages; thus, supporting all of them is relatively easy. A TLS 1.2 client who wishes to negotiate with such older servers will send a normal TLS 1.2 ClientHello, containing { 3, 3 } (TLS 1.2) in ClientHello.client_version. If the server does not support this version, it will respond with ServerHello containing an older version number. If the client agrees to use this version, the=20 negotiation will proceed as appropriate for the negotiated protocol. If the version chosen by the server is not supported by the client=20 (or not acceptable), the client MUST send a "protocol_version" alert=20 message and close the connection. If a TLS server receives a ClientHello containing a version number greater than the highest version supported by the server, it MUST reply according to the highest version supported by the server. A TLS server can also receive a ClientHello containing version number smaller than the highest supported version. If the server wishes to negotiate with old clients, it will proceed as appropriate for the highest version supported by the server that=20 is not greater than ClientHello.client_version. For example, if=20 the server supports TLS 1.0, 1.1, and 1.2, and client_version is TLS 1.0, the server will proceed with a TLS 1.0 ServerHello. If=20 server supports (or is willing to use) only versions greater=20 than client_version, it MUST send a "protocol_version" alert=20 message and close the connection. Whenever a client already knows the highest protocol known to a server (for example, when resuming a session), it SHOULD initiate the connection in that native protocol. Note: some server implementations are known to implement version negotiation incorrectly. For example, there are buggy TLS 1.0 servers that simply close the connection when the client offers a version newer than TLS 1.0. Also, it is known that some servers will refuse connection if any TLS extensions are included in ClientHello. Interoperability with such buggy servers is a complex topic beyond the scope of this document, and may require multiple connection attempts by the client. Earlier versions of the TLS specification were not fully clear on what the record layer version number (TLSPlaintext.version) should contain when sending ClientHello (i.e., before it is known which version of the protocol will be employed). Thus, TLS servers compliant with this specification MUST accept any value {03,XX} as the record layer version number for ClientHello. TLS clients that wish to negotiate with older servers MAY send any value {03,XX} as the record layer version number. Typical values would be {03,00}, the lowest version number supported by the client, and the value of ClientHello.client_version. No single value will guarantee interoperability with all old servers,=20 but this is a complex topic beyond the scope of this document. (and move all discussion of SSL 2.0 discussion to separate section, appendix E.2) Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Oct 22 11:18:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbf3v-0002us-Np; Sun, 22 Oct 2006 11:16:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbf3t-0002sU-QH for tls@ietf.org; Sun, 22 Oct 2006 11:16:29 -0400 Received: from s0106000b972b98d7.vc.shawcable.net ([24.82.185.54] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gbf3p-0000Dr-IQ for tls@ietf.org; Sun, 22 Oct 2006 11:16:29 -0400 Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 01B381CC22 for ; Sun, 22 Oct 2006 08:13:38 -0700 (PDT) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19) Date: Sun, 22 Oct 2006 08:13:37 -0700 From: EKR Message-Id: <20061022151338.01B381CC22@delta.rtfm.com> X-Spam-Score: 0.2 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Subject: [TLS] Updated TLS 1.2 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org I've submitted updated version of TLS 1.2. I note that we haven't finished the PRF and verify_data discussions so those should be considered preliminary. The major new change here is the addition of a slot (though no cipher suites) for AEAD (combined encryption and authentication) modes. Until the draft is posted you can find a preliminary copy at: https://scm.sipfoundry.org/rep/ietf-drafts/ekr/tls/tls.txt -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Oct 22 19:07:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbmOQ-0005OE-Ue; Sun, 22 Oct 2006 19:06:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GbmO9-0005KG-7p; Sun, 22 Oct 2006 19:05:53 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gbm9J-0004PJ-15; Sun, 22 Oct 2006 18:50:34 -0400 Received: from ns3.neustar.com ([156.154.24.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Gbm9I-0004u4-M8; Sun, 22 Oct 2006 18:50:32 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns3.neustar.com (Postfix) with ESMTP id 573CE175A6; Sun, 22 Oct 2006 22:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gbm8n-0006QX-S4; Sun, 22 Oct 2006 18:50:01 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Sun, 22 Oct 2006 18:50:01 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-psk-null-03.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Pre-Shared Key Cipher Suites with NULL Encryption for Transport Layer Security (TLS) Author(s) : U. Blumenthal, P. Goel Filename : draft-ietf-tls-psk-null-03.txt Pages : 5 Date : 2006-10-22 This document specifies authentication-only cipher suites (with no encryption) for the Pre-Shared Key based Transport Layer Security (TLS) protocol. These cipher suites are useful when authentication and integrity protection is desired, but confidentiality is not needed or not permitted. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-null-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-psk-null-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-psk-null-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-22163826.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-psk-null-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-psk-null-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-22163826.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@lists.ietf.org Mon Oct 23 05:09:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbvmu-0001Qu-5S; Mon, 23 Oct 2006 05:08:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gbvmt-0001Qf-GZ for tls@ietf.org; Mon, 23 Oct 2006 05:08:03 -0400 Received: from moutng.kundenserver.de ([212.227.126.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gbvmr-0007mw-Jm for tls@ietf.org; Mon, 23 Oct 2006 05:08:03 -0400 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis), id 0MKxQS-1Gbvmo3Rpk-0005oq; Mon, 23 Oct 2006 11:07:59 +0200 Received: by tau.invalid (Postfix, from userid 1000) id 25D754E5C; Mon, 23 Oct 2006 11:07:57 +0200 (CEST) Date: Mon, 23 Oct 2006 11:07:57 +0200 From: Bodo Moeller To: Pasi.Eronen@nokia.com Subject: Re: [TLS] Open issue: Record Version Numbers Message-ID: <20061023090757.GA10448@tau.invalid> References: <20061020070358.GA26457@tau.invalid> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Fri, Oct 20, 2006 at 03:26:12PM +0300, Pasi.Eronen@nokia.com wrote: > Bodo Moeller wrote: >> What remains is my main conclusion that the language in the >> specification in this regards is a total mess, and that we can't just >> look what we would *like* the specification to be, but mostly at what >> will work best with the implementations that are actually out there. > I agree. Here's some suggested text; let's see if we can improve on > it somehow... Your suggestion looks quite good! There are just two things I'd like to change: > E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0 > > For historical reasons and in order to avoid a profligate > consumption of reserved port numbers, application protocols which > are secured by various versions of TLS (1.0, 1.1, and 1.2) and SSL > (2.0 and 3.0) all frequently share the same connection port: for > example, the https protocol (HTTP secured by SSL or TLS) uses port > 443 regardless of which security protocol it is using. Thus, some > mechanism must be determined to distinguish and negotiate among the > various protocols. > > TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and > use compatible ClientHello messages; thus, supporting all of them > is relatively easy. > > [...] I'd remove the discussion of ports. If we really want to explain why the TLS protocol has to do version negotiation, then for completeness we'd also have to mention the various mechanisms of the STARTTLS variety. But I think all this distracts from what the TLS specification is about; I think that the basic concept of version negotiation is obvious enough that we don't have to explain the background it detail. Here's my proposal: E.1. Compatibility with TLS 1.0/1.1 and SSL 3.0 Since there are various versions of TLS (1.0, 1.1, 1.2, and any future versions) and SSL (2.0 and 3.0), means are needed to negotiate the specific protocol version to use. The TLS protocol provides a built-in mechanism for version negotiation so as not to bother other protocol components with the complexities of version selection. TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use compatible ClientHello messages; thus, supporting all of them is relatively easy. [...] My second change request is to specifically mention future protocol versions, since mishandling of these is a frequent cause of problems. So let's reword the second paragraph quoted above: TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use compatible ClientHello messages; thus, supporting all of them is relatively easy. Similarly, servers can easily handle clients trying to use future versions of TLS as long as the clients still support the highest protocol version available in the server. [...] Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Oct 23 16:43:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc6bz-0000PD-O4; Mon, 23 Oct 2006 16:41:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gc6bs-00004r-VU; Mon, 23 Oct 2006 16:41:24 -0400 Received: from ns0.neustar.com ([156.154.16.158]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gc6bs-0003aX-BE; Mon, 23 Oct 2006 16:41:24 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns0.neustar.com (Postfix) with ESMTP id A325C328F2; Mon, 23 Oct 2006 19:50:02 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1Gc5oA-0008P1-Gs; Mon, 23 Oct 2006 15:50:02 -0400 Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Message-Id: Date: Mon, 23 Oct 2006 15:50:02 -0400 X-Spam-Score: -2.5 (--) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: tls@ietf.org Subject: [TLS] I-D ACTION:draft-ietf-tls-rfc4346-bis-02.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : The TLS Protocol Version 1.2 Author(s) : T. Dierks, E. Rescorla Filename : draft-ietf-tls-rfc4346-bis-02.txt Pages : 113 Date : 2006-10-23 This document specifies Version 1.2 of the Transport Layer Security (TLS) protocol. The TLS protocol provides communications security over the Internet. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4346-bis-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-tls-rfc4346-bis-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-tls-rfc4346-bis-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2006-10-23122453.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-tls-rfc4346-bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-tls-rfc4346-bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2006-10-23122453.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --NextPart-- From tls-bounces@lists.ietf.org Tue Oct 24 13:19:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcPub-0002uk-Bt; Tue, 24 Oct 2006 13:18:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcPq9-0007q3-0k for tls@ietf.org; Tue, 24 Oct 2006 13:13:25 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcPhK-0005Ic-Ai for tls@ietf.org; Tue, 24 Oct 2006 13:04:21 -0400 Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id k9OH4AjB024835 for ; Tue, 24 Oct 2006 12:04:10 -0500 (CDT) Received: from phal.lucentradius.com (phil.aaa.lucent.com [135.140.160.4]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id k9OH4AAY012644 for ; Tue, 24 Oct 2006 12:04:10 -0500 (CDT) Received: from [135.140.160.28] (rocinante.lucentradius.com [135.140.160.28]) by phal.lucentradius.com (8.12.9+Sun/8.12.9) with ESMTP id k9OH48Xk012633 for ; Tue, 24 Oct 2006 10:04:08 -0700 (PDT) Message-ID: <453E478B.6010609@lucent.com> Date: Tue, 24 Oct 2006 10:04:11 -0700 From: Jan Nordqvist User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Subject: [TLS] TLS 1.1 and static DH X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Hi All, We have an implementation of a TLS 1.0/1.1 stack for which we are seeking candidates for interoperability testing. None of the publicly available implementations that we have found implements TLS1.1 and we are therefore interested in getting access to a TLS implementation that does both TLS1.0 and TLS1.1 for interoperability testing and preferably also for regression testing. Ideally we would like access to a trusted public domain implementation, but as an alternative we could either consider access over the public Internet or exchange a bundled test-suite with some other vendor under an NDA. Apart from the 1.1 support, an issue that surprises me somewhat is that the static DH cipher suites, i.e. the TLS_DH_DSA and TLS_DH_RSA suites rarely seems to be supported. None of the TLS RFC's makes any statement, perhaps rightly, about the AlgorithmIdentifier to use for DH keys in certificates. At the same time it seems that X.509 DH certificates are somewhat arcane and I have seen certificates using both 1.2.840.10046.2.1 (the X.509 suggested dhpublicnumber) and 1.2.840.113549.1.3.1 (RSA/DH) as the AlgorithmIdentifier as well as 1.2.840.113549.1.3.1 or 1.2.840.113549.1.5.16.1 (PKCS-8) for the private key id in the key-file. Could it be that the lack of consistency here has something to do with the lack of support for static DH in TLS? Any comments or clarification here would be appreciated. If anyone is interested in engaging in a mutual test setup, our interest would involve testing out all of the RFC-4346 mandated cipher suites, except the export suites, the Kerberos suites and the IDEA suite, with and without client authentication, with and without "standard" stateful session resumption and potentially stateful resumption per RFC-4507. Thank you, Jan Nordqvist Software Architect Lucent VitalAAA product group _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Oct 24 15:44:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcSBH-0003cq-8N; Tue, 24 Oct 2006 15:43:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcSBF-0003ch-NM for tls@ietf.org; Tue, 24 Oct 2006 15:43:21 -0400 Received: from ihemail3.lucent.com ([135.245.0.37]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcSBC-0001i1-FS for tls@ietf.org; Tue, 24 Oct 2006 15:43:21 -0400 Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id k9OJhHd1003927 for ; Tue, 24 Oct 2006 14:43:18 -0500 (CDT) Received: from phal.lucentradius.com (phil.aaa.lucent.com [135.140.160.4]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id k9OJhHN3022297 for ; Tue, 24 Oct 2006 14:43:17 -0500 (CDT) Received: from [135.140.160.28] (rocinante.lucentradius.com [135.140.160.28]) by phal.lucentradius.com (8.12.9+Sun/8.12.9) with ESMTP id k9OJhEXk013611 for ; Tue, 24 Oct 2006 12:43:14 -0700 (PDT) Message-ID: <453E6CD6.8010100@lucent.com> Date: Tue, 24 Oct 2006 12:43:18 -0700 From: Jan Nordqvist User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: Subject: [TLS] Comments on RFC-4346 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org After implementing a TLS 1.0/1.1 stack according to RFC-4346 and RFC-2246 (and other docs) intermixed with debugging sessions, mostly with a patched up version of puretls (thanks Eric Rescorla), I thought I would share some observations I have made about RFC-4346: 1. The specification is a bit vague about which exact bytes of the SSLv2 Hello are used to calculate the handshake hash. In section E.1 of RFC 4346 the client hello is presented as one contiguous chunk of bytes with the v2 record protocol header included, but doesn't specifically point out that the two first msg_length bytes of the record header must be omitted from the hash calculation. 2. There are few recommendations about what AlertLevel to use for each AlertDescription. It appears, as an example, that many implementations are using warning as the level for close_notify, although the RFC says nothing about what level to actually use. 3. The definition of the CertificateRequest message specifies certificate_types and certificate_authorities as criteria for requesting certificates, but there is no mentioning how the two sets of values are used to select a certificate, i.e. is a certificate qualified if it matches only one of the sets or does it have to qualify to both. 4. The only plausible reason for a server to request any of the rsa_fixed_dh or dss_fixed_dh certificate types is obviously after a static DH cipher suite has been negotiated and the server is "wishful" about getting a DH certificate whose engine parameters happens to match the server's certificate engine parameters in order to be able to exchange an empty ClientKeyExchange (section 7.4.7). In any other case, DH certificates should be disadvantageous since the key ownership cannot be verified. It might be useful if the specification made a note about this fact. 5. There is no mentioning of the details for how to perform the handshake with the TLS_NULL_WITH_NULL_NULL algorithm. Since the ClientKeyExchange message is specified as mandatory, one could assume that the ClientKeyExchange message would be specified with a case for a null algorithm in addition to rsa and diffie_hellman. Furthermore, the calculation of the verify_data in the Finished message is somewhat dubious since there is no master_secret to plug into the PRF, while at the same time the master_secret is defined to always be 48 bytes in length (section 8.1) The TLS_NULL_WITH_NULL_NULL issue may not be overly significant given its fairly low security level :). At the same time it is mentioned as a defined cipher-suite as part of the TLS 1.1 definition, and it may be useful for debugging purposes. Jan Nordqvist Lucent VitalAAA product group _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Oct 24 16:30:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcSuP-0007x9-1t; Tue, 24 Oct 2006 16:30:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcSuO-0007x4-Ha for tls@ietf.org; Tue, 24 Oct 2006 16:30:00 -0400 Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcStt-0001WB-Lo for tls@ietf.org; Tue, 24 Oct 2006 16:30:00 -0400 Received: by delta.rtfm.com (Postfix, from userid 1001) id 7A0F51CC61; Tue, 24 Oct 2006 13:26:38 -0700 (PDT) To: Jan Nordqvist Subject: Re: [TLS] Comments on RFC-4346 References: <453E6CD6.8010100@lucent.com> From: EKR Date: Tue, 24 Oct 2006 13:26:38 -0700 In-Reply-To: <453E6CD6.8010100@lucent.com> (Jan Nordqvist's message of "Tue, 24 Oct 2006 12:43:18 -0700") Message-ID: <86hcxtfojl.fsf@delta.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.2 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR 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: , Errors-To: tls-bounces@lists.ietf.org Jan Nordqvist writes: > 1. The specification is a bit vague about which exact bytes of the > SSLv2 Hello are used to calculate the handshake hash. In section > E.1 of RFC 4346 the client hello is presented as one contiguous > chunk of bytes with the v2 record protocol header included, but > doesn't specifically point out that the two first msg_length bytes > of the record header must be omitted from the hash calculation. > 2. There are few recommendations about what AlertLevel to use for > each AlertDescription. It appears, as an example, that many > implementations are using warning as the level for close_notify, > although the RFC says nothing about what level to actually use. Right. However, since fatal makes the session resumption unresumable, it seems like warning is what you want. > 3. The definition of the CertificateRequest message specifies > certificate_types and certificate_authorities as criteria for > requesting certificates, but there is no mentioning how the two > sets of values are used to select a certificate, i.e. is a > certificate qualified if it matches only one of the sets or does > it have to qualify to both. It mist match both. > 4. The only plausible reason for a server to request any of the > rsa_fixed_dh or dss_fixed_dh certificate types is obviously after > a static DH cipher suite has been negotiated and the server is > "wishful" about getting a DH certificate whose engine parameters > happens to match the server's certificate engine parameters in > order to be able to exchange an empty ClientKeyExchange (section > 7.4.7). In any other case, DH certificates should be > disadvantageous since the key ownership cannot be verified. It > might be useful if the specification made a note about this fact. > 5. There is no mentioning of the details for how to perform the > handshake with the TLS_NULL_WITH_NULL_NULL algorithm. Since the > ClientKeyExchange message is specified as mandatory, one could > assume that the ClientKeyExchange message would be specified with > a case for a null algorithm in addition to rsa and diffie_hellman. > Furthermore, the calculation of the verify_data in the Finished > message is somewhat dubious since there is no master_secret to > plug into the PRF, while at the same time the master_secret is > defined to always be 48 bytes in length (section 8.1) It's forbidden to negotiate this algorithm (see S A.5). -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Oct 24 16:43:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcT6M-0000Uh-7g; Tue, 24 Oct 2006 16:42:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcT6K-0000UP-Pk for tls@ietf.org; Tue, 24 Oct 2006 16:42:20 -0400 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcT6J-0003rz-DM for tls@ietf.org; Tue, 24 Oct 2006 16:42:20 -0400 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id WAA23579; Tue, 24 Oct 2006 22:42:12 +0200 (MESZ) From: Martin Rex Message-Id: <200610242042.WAA15485@uw1048.wdf.sap.corp> Subject: Re: [TLS] Comments on RFC-4346 To: jnordqvist@lucent.com (Jan Nordqvist) Date: Tue, 24 Oct 2006 22:42:13 +0200 (MET DST) In-Reply-To: <453E6CD6.8010100@lucent.com> from "Jan Nordqvist" at Oct 24, 6 12:43:18 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@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: , Errors-To: tls-bounces@lists.ietf.org Jan Nordqvist wrote: > > 3. The definition of the CertificateRequest message specifies > certificate_types and certificate_authorities as criteria for > requesting certificates, but there is no mentioning how the two > sets of values are used to select a certificate, i.e. is a > certificate qualified if it matches only one of the sets or does > it have to qualify to both. A very large installed base of SSLv3/TLSv1.0 seems to entirely ignore certificate_types for the selection (the vendor forgot to expose this information at the low level APIs, so the callers above it, e.g. Web Browser, can not use it for selecting the certificate). Let's hope that CA's are careful when issuing CA certificates, and do not use the exact same Subject DName but differing keys (different in type, size or even just different bits). -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Oct 24 18:17:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcUYr-0000yl-K6; Tue, 24 Oct 2006 18:15:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcUYq-0000ya-5T for tls@ietf.org; Tue, 24 Oct 2006 18:15:52 -0400 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcUYj-0002WM-P3 for tls@ietf.org; Tue, 24 Oct 2006 18:15:52 -0400 Received: from mailout5.microsoft.com (157.54.69.148) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.665.7; Tue, 24 Oct 2006 15:15:45 -0700 Received: from tuk-hub-01.redmond.corp.microsoft.com ([157.54.70.27]) by mailout5.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Tue, 24 Oct 2006 14:00:16 -0700 Received: from tk1-exhub-c103.redmond.corp.microsoft.com ([157.56.116.114]) by tuk-hub-01.redmond.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Tue, 24 Oct 2006 14:00:15 -0700 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk1-exhub-c103.redmond.corp.microsoft.com (157.56.116.114) with Microsoft SMTP Server id 8.0.665.7; Tue, 24 Oct 2006 14:00:15 -0700 Received: from WIN-MSG-21.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.25]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Tue, 24 Oct 2006 14:00:15 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] RFC 3456 - OCSP extension question Date: Tue, 24 Oct 2006 14:00:09 -0700 Message-ID: In-Reply-To: <4536B117.7060304@blueyonder.co.uk> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] RFC 3456 - OCSP extension question Thread-Index: AcbzCOKxmGK3AHbgSDiz44/3hZW9awEpTpSg References: <4536B117.7060304@blueyonder.co.uk> From: Joshua Ball To: , X-OriginalArrivalTime: 24 Oct 2006 21:00:15.0057 (UTC) FILETIME=[67454C10:01C6F7AF] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Hmmm... maybe I am misunderstanding the statement: "by prior arrangement" The way we are doing OCSP responses here is through AIA's, not through sending lists of ResponderID's around. The AIA is in the server cert, which the server uses to get the OCSP response that we send back to the client. Is this what is meant by "by prior arrangement"? It seems to me there are three different methods being called out here: 1. by prior arrangement - a closed environment in which the server knows which ResponderID's are OK to use. 2. send a list of ResponderID's - client sends a list, the server uses one from the list. 3. use of the AIA - server gets OCSP response from URL in AIA of cert. What I am trying to understand is how our client should be forming it's OCSP extension in this last case (or if I am misunderstanding the last case, when it really is part of #1). So, assuming the server is not going to parse or know anything about ResponderID's (we don't use them on the server), what should the client be sending? A responder_id_list<0..2^16-1> vector of 0?=20 Thanks. -----Original Message----- From: David Hopwood [mailto:david.nospam.hopwood@blueyonder.co.uk]=20 Sent: Wednesday, October 18, 2006 3:56 PM To: tls@ietf.org Subject: Re: [TLS] RFC 3456 - OCSP extension question Joshua Ball wrote: > In regards to the implementation of RFC 3546, in particular the OCSP extension. > When the client does not wish to send any list of responders, what is=20 > the correct sequence to send A zero-length vector. > (as a zero length vector apparently has a special meaning). If the client does not wish to send a list, then logically it *must* be the case that "the responders are implicitly known to the server - e.g., by prior arrangement." Otherwise how would the server know which responder to use? -- David Hopwood _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 25 03:06:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gccob-00073v-Kk; Wed, 25 Oct 2006 03:04:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gccn8-0004s2-77 for tls@ietf.org; Wed, 25 Oct 2006 03:03:10 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcch9-0006Va-Q4 for tls@ietf.org; Wed, 25 Oct 2006 02:57:01 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9P6usZi019816; Wed, 25 Oct 2006 09:56:58 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 09:56:35 +0300 Received: from 4FIL09356 ([172.21.42.147]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 25 Oct 2006 09:56:34 +0300 From: "Pasi Eronen" To: "'ext Jan Nordqvist'" , Subject: RE: [TLS] TLS 1.1 and static DH Date: Wed, 25 Oct 2006 09:56:36 +0300 Message-ID: <000001c6f802$b6bc61e0$932a15ac@NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: Acb3kL1klnFyA49EQ4qJgNexU0rEWQAcXCYw In-Reply-To: <453E478B.6010609@lucent.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-OriginalArrivalTime: 25 Oct 2006 06:56:34.0461 (UTC) FILETIME=[B57514D0:01C6F802] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Jan Nordqvist wrote: > We have an implementation of a TLS 1.0/1.1 stack for which we are > seeking candidates for interoperability testing. None of the > publicly available implementations that we have found implements > TLS1.1 and we are therefore interested in getting access to a TLS > implementation that does both TLS1.0 and TLS1.1 for interoperability > testing and preferably also for regression testing. Of the open source libraries, at least GnuTLS, TLS Lite, and Cryptlib implement TLS 1.1. Opera web browser also has it, as does Certicom's SSL-C library. (I'm not sure if any of those implement the static DH suites, though.) Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 25 04:52:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GceUE-00031C-8q; Wed, 25 Oct 2006 04:51:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GceUB-00030q-Sz for tls@ietf.org; Wed, 25 Oct 2006 04:51:43 -0400 Received: from mailhost.auckland.ac.nz ([130.216.190.14] helo=zeppo.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GceUA-0003BE-GJ for tls@ietf.org; Wed, 25 Oct 2006 04:51:43 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id E41853489B; Wed, 25 Oct 2006 21:51:37 +1300 (NZDT) Received: from zeppo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13900-18; Wed, 25 Oct 2006 21:51:37 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id DD1C836DCB; Wed, 25 Oct 2006 21:51:36 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 4E6E437750; Wed, 25 Oct 2006 21:51:36 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1GceUB-0005Lr-00; Wed, 25 Oct 2006 21:51:43 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: jnordqvist@lucent.com, pasi.eronen@nokia.com, tls@ietf.org Subject: RE: [TLS] TLS 1.1 and static DH In-Reply-To: <000001c6f802$b6bc61e0$932a15ac@NOE.Nokia.com> Message-Id: Date: Wed, 25 Oct 2006 21:51:43 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.5 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org "Pasi Eronen" writes: >Of the open source libraries, at least GnuTLS, TLS Lite, and Cryptlib >implement TLS 1.1. Opera web browser also has it, as does Certicom's SSL-C >library. (I'm not sure if any of those implement the static DH suites, >though.) cryptlib definitely doesn't do static DH... in fact does anything? Why would anyone do it at all, for that matter? Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 25 06:30:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcg0V-0004ne-Ez; Wed, 25 Oct 2006 06:29:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcg0U-0004nZ-Bq for tls@ietf.org; Wed, 25 Oct 2006 06:29:10 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gcg0R-0002gS-UA for tls@ietf.org; Wed, 25 Oct 2006 06:29:10 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9PAT1xE019314; Wed, 25 Oct 2006 13:29:01 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 13:28:52 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 13:28:51 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] TLS 1.1 and static DH Date: Wed, 25 Oct 2006 13:28:53 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] TLS 1.1 and static DH Thread-Index: Acb4EvzX9wj2Dr+GRbOh5Ra/c4sP4wADR2GQ From: To: , , X-OriginalArrivalTime: 25 Oct 2006 10:28:51.0647 (UTC) FILETIME=[5D696CF0:01C6F820] X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org pgut001@cs.auckland.ac.nz wrote: > cryptlib definitely doesn't do static DH... in fact does anything? > Why would anyone do it at all, for that matter? Based on a quick look at the source code, at least OpenSSL, Mozilla NSS, and PureTLS appear to support static DH.=20 But I don't know why they do it either (or whether that part of the code has actually ever been used or tested :-) Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 25 07:35:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gch0i-0000RZ-Lz; Wed, 25 Oct 2006 07:33:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcgxe-0007vc-W8 for tls@ietf.org; Wed, 25 Oct 2006 07:30:18 -0400 Received: from moutng.kundenserver.de ([212.227.126.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcgqN-0001OX-OD for tls@ietf.org; Wed, 25 Oct 2006 07:22:49 -0400 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1GcgqF1iMV-0004wg; Wed, 25 Oct 2006 13:22:40 +0200 Received: by tau.invalid (Postfix, from userid 1000) id 0F7504E38; Wed, 25 Oct 2006 13:22:39 +0200 (CEST) Date: Wed, 25 Oct 2006 13:22:38 +0200 From: Bodo Moeller To: Pasi.Eronen@nokia.com Subject: Re: [TLS] TLS 1.1 and static DH Message-ID: <20061025112238.GA26268@tau.invalid> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Wed, Oct 25, 2006 at 01:28:53PM +0300, Pasi.Eronen@nokia.com wrote: > pgut001@cs.auckland.ac.nz wrote: >> cryptlib definitely doesn't do static DH... in fact does anything? >> Why would anyone do it at all, for that matter? > Based on a quick look at the source code, at least OpenSSL, Mozilla > NSS, and PureTLS appear to support static DH. > > But I don't know why they do it either (or whether that part of the > code has actually ever been used or tested :-) OpenSSL doesn't support static DH, actually. There's anonymous and non-anonymous ephemeral DH, there's static and ephemeral ECDH, but no static DH with DH certificates. (There's also some code that doesn't totally neglect the possibility of having DH certificates, but this doesn't mean it is actually used anywhere.) Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 25 07:36:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gch3I-0004Vm-2r; Wed, 25 Oct 2006 07:36:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gch3F-0004Fw-RA for tls@ietf.org; Wed, 25 Oct 2006 07:36:05 -0400 Received: from anchor-post-30.mail.demon.net ([194.217.242.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gch3A-0004Xu-H4 for tls@ietf.org; Wed, 25 Oct 2006 07:36:05 -0400 Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.2]) by anchor-post-30.mail.demon.net with esmtp (Exim 4.42) id 1Gch39-0004LN-2S for tls@ietf.org; Wed, 25 Oct 2006 11:36:00 +0000 Message-ID: <453F4C37.8090403@drh-consultancy.demon.co.uk> Date: Wed, 25 Oct 2006 12:36:23 +0100 From: Dr Stephen Henson User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] TLS 1.1 and static DH References: In-Reply-To: X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Pasi.Eronen@nokia.com wrote: > pgut001@cs.auckland.ac.nz wrote: > >> cryptlib definitely doesn't do static DH... in fact does anything? >> Why would anyone do it at all, for that matter? > > Based on a quick look at the source code, at least OpenSSL, Mozilla > NSS, and PureTLS appear to support static DH. There is some code related to this in the SSL source but the relevant DH certificate support was never implemented. Well actually it is possible that PKCS#3 DH certificate support is present in OpenSSL 0.9.9 but that is as an indirect result of other changes. The PKCS#3 DH certificate request generation code isn't present though. I was at one point some years ago planning to add X9.42 DH support to OpenSSL for S/MIME v3 but I only received one comment asking me *not* to support it. Finding test vectors for the parameter generation algorithm was also a problem. The only ones I saw were either compatible with the DSA algorithm or clearly broken. Various calls in public mailing lists giving details about why I thought the existing ones were wrong met with silence. I ended up concluding that if no one else was implementing it, why should I? > > But I don't know why they do it either (or whether that part of the > code has actually ever been used or tested :-) > Just about the only reason I can think of is a lower connection overhead. 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@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 25 09:28:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcimf-00078j-KO; Wed, 25 Oct 2006 09:27:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gcimd-00075i-N6 for tls@ietf.org; Wed, 25 Oct 2006 09:27:03 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcimY-0005WX-Fd for tls@ietf.org; Wed, 25 Oct 2006 09:27:02 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9PDQfsb031687; Wed, 25 Oct 2006 16:26:54 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 16:26:17 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 25 Oct 2006 16:26:17 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Open issue: Record Version Numbers Date: Wed, 25 Oct 2006 16:26:15 +0300 Message-ID: In-Reply-To: <20061023090757.GA10448@tau.invalid> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Open issue: Record Version Numbers Thread-Index: Acb2gs4nln5sTXRrQla1fxlOWzpZWABr5K8A From: To: X-OriginalArrivalTime: 25 Oct 2006 13:26:17.0543 (UTC) FILETIME=[26DC3D70:01C6F839] X-Spam-Score: 0.2 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Hi Bodo, Thanks for your comments. I agree about the first change; the second change I would reword slightly... > TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and > use compatible ClientHello messages; thus, supporting all of them > is relatively easy. Similarly, servers can easily handle clients > trying to use future versions of TLS as long as the clients still > support the highest protocol version available in the server. This assumes the ClientHello format remains the same; perhaps this is worth mentioning explicitly: TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use compatible ClientHello messages; thus, supporting all of them is relatively easy. Similarly, servers can easily handle clients trying to use future versions of TLS as long as the ClientHello format remains compatible, and the client support the highest protocol version available in the server. And here's the slightly cleaned text about SSL 2.0 compatibility: E.2 Compatibility with SSL 2.0 TLS 1.2 clients that wish to support SSL 2.0 servers MUST send version 2.0 CLIENT-HELLO messages defined in [SSL2]. The message MUST contain the same version number as would be used for ordinary ClientHello, MUST use CHALLENGE-LENGTH of 32, and MUST encode the supported TLS ciphersuites in the CIPHER-SPECS-DATA field as described below. =20 Warning: The ability to send version 2.0 CLIENT-HELLO messages will be phased out with all due haste, since the newer ClientHello format provides better mechanisms for moving to newer versions and negotiating extensions. TLS 1.2 clients SHOULD NOT support SSL 2.0. However, even TLS servers that do not support SSL 2.0 SHOULD accept version 2.0 CLIENT-HELLO messages. The message is presented below in sufficient detail for TLS server implementors; the true definition is still assumed to be [SSL2]. For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same way as a ClientHello with a "null" compression method and no extensions. Note that this message MUST be sent directly on the wire, not wrapped as a TLS record. For the purposes of calculating Finished and CertificateVerify, the msg_length field is not considered to be a part of the handshake message. uint8 V2CipherSpec[3]; struct { uint16 msg_length; uint8 msg_type; ProtocolVersion version; uint16 cipher_spec_length; uint16 session_id_length; uint16 challenge_length; V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length]; opaque session_id[V2ClientHello.session_id_length]; opaque challenge[V2ClientHello.challenge_length; } V2ClientHello; msg_length The highest bit MUST be 1; the remaining bits contain the=20 length of the following data in bytes.=20 msg_type The message type for V2ClientHello is one (1). version Equal to ClientHello.client_version. cipher_spec_length This field is the total length of the field cipher_specs. It cannot be zero and MUST be a multiple of the V2CipherSpec=20 length (3). session_id_length The length of the session_id field in bytes; MUST be zero for a client that claims to support TLS 1.2. challenge_length=20 The length of the challenge field in bytes; MUST be 32 for=20 a client that claims to support TLS 1.2. cipher_specs This is a list of all CipherSpecs the client is willing and able to use. In addition to the 2.0 cipher specs defined in [SSL2], this includes the TLS cipher suites normally sent in ClientHello.cipher_suites, each cipher suite prefixed by a zero byte. For example, TLS ciphersuite {0x00,0x0A} would be sent as {0x00,0x00,0x0A}. session_id This field MUST be empty. challenge Equal to ClientHello.random. Note: Requests to resume a TLS session MUST use a TLS client hello. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 25 09:56:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcjEb-0007dJ-2L; Wed, 25 Oct 2006 09:55:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GcjEZ-0007dC-Tl for tls@ietf.org; Wed, 25 Oct 2006 09:55:55 -0400 Received: from moutng.kundenserver.de ([212.227.126.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GcjES-0002la-GF for tls@ietf.org; Wed, 25 Oct 2006 09:55:55 -0400 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis), id 0MKxQS-1GcjEP12Qp-0004X2; Wed, 25 Oct 2006 15:55:45 +0200 Received: by tau.invalid (Postfix, from userid 1000) id B725B4E38; Wed, 25 Oct 2006 15:55:44 +0200 (CEST) Date: Wed, 25 Oct 2006 15:55:44 +0200 From: Bodo Moeller To: Pasi.Eronen@nokia.com Subject: Re: [TLS] Open issue: Record Version Numbers Message-ID: <20061025135544.GA29987@tau.invalid> References: <20061023090757.GA10448@tau.invalid> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Wed, Oct 25, 2006 at 04:26:15PM +0300, Pasi.Eronen@nokia.com wrote: > Thanks for your comments. I agree about the first change; > the second change I would reword slightly... >> TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and >> use compatible ClientHello messages; thus, supporting all of them >> is relatively easy. Similarly, servers can easily handle clients >> trying to use future versions of TLS as long as the clients still >> support the highest protocol version available in the server. > This assumes the ClientHello format remains the same; This is true, but intentional. If the ClientHello format is ever changed in an incompatible way such that existing servers cannot handle it, then a client using this new format cannot support the highest protocol version available in such servers. (Unless they use some kind of future backwards-compatible ClientHello, in which case servers *can* easily handle such clients, after all.) Well, and if a client cannot support the highest protocol version available in the server, then the above "as long as"-clause does not pretend to apply. But I guess it still can't hurt to mention the format compatibility requirement, and use your proposed wording: > perhaps this > is worth mentioning explicitly: > > TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and > use compatible ClientHello messages; thus, supporting all of them > is relatively easy. Similarly, servers can easily handle clients > trying to use future versions of TLS as long as the ClientHello > format remains compatible, and the client support the highest > protocol version available in the server. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 25 12:10:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GclIz-0000p3-Rt; Wed, 25 Oct 2006 12:08:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GclIy-0000ov-Oj for tls@ietf.org; Wed, 25 Oct 2006 12:08:36 -0400 Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GclIv-0007rc-EN for tls@ietf.org; Wed, 25 Oct 2006 12:08:36 -0400 Received: by delta.rtfm.com (Postfix, from userid 1001) id 1D2DD1CC24; Wed, 25 Oct 2006 09:05:35 -0700 (PDT) To: Subject: Re: [TLS] TLS 1.1 and static DH References: From: EKR Date: Wed, 25 Oct 2006 09:05:34 -0700 In-Reply-To: (Pasi Eronen's message of "Wed, 25 Oct 2006 13:28:53 +0300") Message-ID: <86ac3k9y9d.fsf@delta.rtfm.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR 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: , Errors-To: tls-bounces@lists.ietf.org writes: > pgut001@cs.auckland.ac.nz wrote: > >> cryptlib definitely doesn't do static DH... in fact does anything? >> Why would anyone do it at all, for that matter? > > Based on a quick look at the source code, at least OpenSSL, Mozilla > NSS, and PureTLS appear to support static DH. I'm pretty sure that it hasn't been tested in PureTLS. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 25 12:17:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GclQm-0004AX-6w; Wed, 25 Oct 2006 12:16:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GclQl-00048z-8I for tls@ietf.org; Wed, 25 Oct 2006 12:16:39 -0400 Received: from chico.itss.auckland.ac.nz ([130.216.190.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GclQg-0001FC-R4 for tls@ietf.org; Wed, 25 Oct 2006 12:16:39 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by chico.itss.auckland.ac.nz (Postfix) with ESMTP id 492AB36B10; Thu, 26 Oct 2006 05:15:24 +1300 (NZDT) Received: from chico.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13972-29; Thu, 26 Oct 2006 05:15:23 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by chico.itss.auckland.ac.nz (Postfix) with ESMTP id E97193732E; Thu, 26 Oct 2006 05:07:45 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 324283774C; Thu, 26 Oct 2006 05:07:45 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1GclIJ-0004Sq-00; Thu, 26 Oct 2006 05:07:55 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: bmoeller@acm.org, Pasi.Eronen@nokia.com Subject: RE: [TLS] Open issue: Record Version Numbers In-Reply-To: Message-Id: Date: Thu, 26 Oct 2006 05:07:55 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.5 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org writes: >And here's the slightly cleaned text about SSL 2.0 compatibility: I know I've said this before, but can't we finally kill SSLv2? Both MSIE 7 and Firefox (Mozilla/whatever) have now removed support for it, which means that it's finally dead no matter what the spec still says about it. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 25 12:20:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GclTu-0007b0-DO; Wed, 25 Oct 2006 12:19:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GclTt-0007av-Pj for tls@ietf.org; Wed, 25 Oct 2006 12:19:53 -0400 Received: from smtpout1467.sc1.he.tucows.com ([64.97.157.167] helo=n007.sc1.cp.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GclTp-0001q5-35 for tls@ietf.org; Wed, 25 Oct 2006 12:19:53 -0400 Received: from [192.168.0.2] (67.188.127.211) by n007.sc1.cp.net (7.2.069.1) (authenticated as nelson@bolyard.com) id 453F8A2A000010E3 for tls@ietf.org; Wed, 25 Oct 2006 16:18:17 +0000 Message-ID: <453F8E48.3060809@bolyard.com> Date: Wed, 25 Oct 2006 09:18:16 -0700 From: Nelson B Bolyard Organization: Spam haters R US User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060824 SeaMonkey/1.5a MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] TLS 1.1 and static DH References: <20061025112238.GA26268@tau.invalid> In-Reply-To: <20061025112238.GA26268@tau.invalid> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Bodo Moeller wrote: > On Wed, Oct 25, 2006 at 01:28:53PM +0300, Pasi.Eronen@nokia.com wrote: >> pgut001@cs.auckland.ac.nz wrote: > >>> cryptlib definitely doesn't do static DH... in fact does anything? >>> Why would anyone do it at all, for that matter? > >> Based on a quick look at the source code, at least OpenSSL, Mozilla >> NSS, and PureTLS appear to support static DH. >> >> But I don't know why they do it either (or whether that part of the >> code has actually ever been used or tested :-) > > OpenSSL doesn't support static DH, actually. Neither does NSS. The static DH cipher suites are explicitly disabled, although much of the code necessary to support them is present in NSS. > There's anonymous and > non-anonymous ephemeral DH, there's static and ephemeral ECDH, but no > static DH with DH certificates. (There's also some code that doesn't > totally neglect the possibility of having DH certificates, but this > doesn't mean it is actually used anywhere.) Likewise, NSS has code to parse (and even create) DH certificates, but it is untested and unused because in the 10 years I've worked on NSS, I've never seen a DH cert from any CA. The Fortezza certs were DH certs, but they were a rather special case, and the special case Fortezza code is no longer supported in NSS. -- Nelson B _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 25 12:23:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GclWq-000155-Ef; Wed, 25 Oct 2006 12:22:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GclWp-00014z-O2 for tls@ietf.org; Wed, 25 Oct 2006 12:22:55 -0400 Received: from nwk-ea-fw-1.sun.com ([192.18.42.249]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GclWj-0002Ot-Vv for tls@ietf.org; Wed, 25 Oct 2006 12:22:55 -0400 Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9PGMiQq020082 for ; Wed, 25 Oct 2006 09:22:44 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J7P004019GDL600@d1-sfbay-09.sun.com> (original mail from nelson@bolyard.com) for tls@ietf.org; Wed, 25 Oct 2006 09:22:44 -0700 (PDT) Received: from [192.168.0.2] ([67.188.127.211]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J7P005ZA9HP7GPG@d1-sfbay-09.sun.com> for tls@ietf.org; Wed, 25 Oct 2006 09:22:43 -0700 (PDT) Date: Wed, 25 Oct 2006 09:22:36 -0700 From: Nelson B Bolyard Subject: Re: [TLS] TLS 1.1 and static DH In-reply-to: <20061025112238.GA26268@tau.invalid> To: tls@ietf.org Message-id: <453F8F4C.40604@bolyard.com> Organization: Spam haters R US MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <20061025112238.GA26268@tau.invalid> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060824 SeaMonkey/1.5a X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org (My apologies if you receive two copies of this email.) Bodo Moeller wrote: > On Wed, Oct 25, 2006 at 01:28:53PM +0300, Pasi.Eronen@nokia.com wrote: >> pgut001@cs.auckland.ac.nz wrote: > >>> cryptlib definitely doesn't do static DH... in fact does anything? >>> Why would anyone do it at all, for that matter? > >> Based on a quick look at the source code, at least OpenSSL, Mozilla >> NSS, and PureTLS appear to support static DH. >> >> But I don't know why they do it either (or whether that part of the >> code has actually ever been used or tested :-) > > OpenSSL doesn't support static DH, actually. Neither does NSS. The static DH cipher suites are explicitly disabled, although much of the code necessary to support them is present in NSS. > There's anonymous and > non-anonymous ephemeral DH, there's static and ephemeral ECDH, but no > static DH with DH certificates. (There's also some code that doesn't > totally neglect the possibility of having DH certificates, but this > doesn't mean it is actually used anywhere.) Likewise, NSS has code to parse (and even create) DH certificates, but it is untested and unused because in the 10 years I've worked on NSS, I've never seen a DH cert from any CA. The Fortezza certs were DH certs, but they were a rather special case, and the special case Fortezza code is no longer supported in NSS. -- Nelson B _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 25 12:32:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GclfZ-0006Xi-Bi; Wed, 25 Oct 2006 12:31:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GclfY-0006XL-82 for tls@ietf.org; Wed, 25 Oct 2006 12:31:56 -0400 Received: from nwk-ea-fw-1.sun.com ([192.18.42.249]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GclfW-0004Lp-D2 for tls@ietf.org; Wed, 25 Oct 2006 12:31:56 -0400 Received: from d1-sfbay-09.sun.com ([192.18.39.119]) by nwk-ea-fw-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k9PGVoKb016933 for ; Wed, 25 Oct 2006 09:31:50 -0700 (PDT) Received: from conversion-daemon.d1-sfbay-09.sun.com by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0J7P00I019U9I500@d1-sfbay-09.sun.com> (original mail from nelson@bolyard.com) for tls@ietf.org; Wed, 25 Oct 2006 09:31:50 -0700 (PDT) Received: from [192.168.0.2] ([67.188.127.211]) by d1-sfbay-09.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0J7P0058L9X27GTG@d1-sfbay-09.sun.com>; Wed, 25 Oct 2006 09:31:50 -0700 (PDT) Date: Wed, 25 Oct 2006 09:31:49 -0700 From: Nelson B Bolyard Subject: Re: [TLS] Open issue: Record Version Numbers In-reply-to: To: Peter Gutmann Message-id: <453F9175.7080302@bolyard.com> Organization: Spam haters R US MIME-version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060824 SeaMonkey/1.5a X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Peter Gutmann wrote: > writes: > >> And here's the slightly cleaned text about SSL 2.0 compatibility: > > I know I've said this before, but can't we finally kill SSLv2? Both MSIE 7 > and Firefox (Mozilla/whatever) have now removed support for it, which means > that it's finally dead no matter what the spec still says about it. Not quite. When FireFox 2 encounters a "TLS intolerant" server (one that fails to negotiate a handshake properly when the client hello specifies version 3,1) it reverts to a backward compatible mode in which it sends SSL2 format client hellos bearing version 3,0, just as it has done for over a decade. Yes, this appears to be necessary with some servers, and maximum interoperability is still the name of the browser game. -- Nelson B _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Oct 25 12:41:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gclo2-0004EG-Q3; Wed, 25 Oct 2006 12:40:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gclo1-0004E7-R2 for tls@ietf.org; Wed, 25 Oct 2006 12:40:41 -0400 Received: from zeppo.itss.auckland.ac.nz ([130.216.190.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gclnz-000662-6d for tls@ietf.org; Wed, 25 Oct 2006 12:40:41 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id 8A2E835961; Thu, 26 Oct 2006 05:40:37 +1300 (NZDT) Received: from zeppo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12073-31; Thu, 26 Oct 2006 05:40:37 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id 5F7D135605; Thu, 26 Oct 2006 05:40:37 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 8CE053774C; Thu, 26 Oct 2006 05:40:36 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1Gclo7-00054O-00; Thu, 26 Oct 2006 05:40:47 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: lists@drh-consultancy.demon.co.uk, tls@ietf.org Subject: Re: [TLS] TLS 1.1 and static DH In-Reply-To: <453F4C37.8090403@drh-consultancy.demon.co.uk> Message-Id: Date: Thu, 26 Oct 2006 05:40:47 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.5 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Dr Stephen Henson writes: >Finding test vectors for the parameter generation algorithm was also a >problem. The only ones I saw were either compatible with the DSA algorithm or >clearly broken. Various calls in public mailing lists giving details about >why I thought the existing ones were wrong met with silence. I ended up >concluding that if no one else was implementing it, why should I? I think this confusion over X9.42 details is pretty much universal, there's been the ongoing saga of the S/MIME test vectors where as soon as someone published vectors, someone else pointed out that they were wrong for one reason or another. Given their history, it's quite possible that they still have errors, but people gave up looking (actually looking at RFC 4134 I can't see any DH vectors in there at all, so I guess they used the ostrich algorithm to solve the problem :-). A related problem is that the X9.42 spec was never really a going concern in the first place, it more or less sleep-walked into becoming a standard after years in the doldrums when the contributors lost interest in it. As a result there are implementations based on all sorts of buggy drafts out there, in fact for most of the time when it was still being pushed all you could get were buggy drafts. So perhaps the best option for TLS is to deprecate the static DH suites. They seem to be pretty much entirely unsupported, and even if you did want to support them you'd end up in a quagmire from which extrication would prove difficult. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 26 03:58:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd06S-0006TQ-4q; Thu, 26 Oct 2006 03:56:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd05A-0003ts-PT for tls@ietf.org; Thu, 26 Oct 2006 03:55:20 -0400 Received: from smtp-out4.blueyonder.co.uk ([195.188.213.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gczzd-0006Ws-Gf for tls@ietf.org; Thu, 26 Oct 2006 03:49:38 -0400 Received: from [172.23.170.137] (helo=anti-virus01-08) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1Gczzc-0001XL-U1 for tls@ietf.org; Thu, 26 Oct 2006 08:49:36 +0100 Received: from 82-42-16-20.cable.ubr01.knor.blueyonder.co.uk ([82.42.16.20] helo=[127.0.0.1]) by asmtp-out2.blueyonder.co.uk with esmtp (Exim 4.52) id 1Gczzc-0002Hj-El for tls@ietf.org; Thu, 26 Oct 2006 08:49:36 +0100 Message-ID: <4540688B.9030002@blueyonder.co.uk> Date: Thu, 26 Oct 2006 08:49:31 +0100 From: David Hopwood User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] RFC 3456 - OCSP extension question References: <4536B117.7060304@blueyonder.co.uk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: david.nospam.hopwood@blueyonder.co.uk 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: , Errors-To: tls-bounces@lists.ietf.org Joshua Ball wrote: > Hmmm... maybe I am misunderstanding the statement: "by prior > arrangement" The important phrase is "implicitly known". "By prior arrangement" is an *example* of a way in which the responders could be implicitly known; it's not normative. -- David Hopwood _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Oct 26 06:29:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd2TO-0003OB-Qd; Thu, 26 Oct 2006 06:28:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gd2TO-0003O2-2R for tls@ietf.org; Thu, 26 Oct 2006 06:28:30 -0400 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gd2TL-0001rM-Oq for tls@ietf.org; Thu, 26 Oct 2006 06:28:30 -0400 Received: from pc6 (1Cust183.tnt1.lnd4.gbr.da.uu.net [62.188.130.183]) by ranger.systems.pipex.net (Postfix) with SMTP id 7C43CE0003B2; Thu, 26 Oct 2006 11:28:23 +0100 (BST) Message-ID: <0a1801c6f8e0$253aa180$0601a8c0@pc6> From: "tom.petch" To: "Peter Gutmann" References: Subject: Re: [TLS] Open issue: Record Version Numbers Date: Thu, 26 Oct 2006 11:18:59 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" 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: , Errors-To: tls-bounces@lists.ietf.org ----- Original Message ----- From: "Peter Gutmann" To: ; Cc: Sent: Wednesday, October 25, 2006 6:07 PM Subject: RE: [TLS] Open issue: Record Version Numbers > writes: > > >And here's the slightly cleaned text about SSL 2.0 compatibility: > > I know I've said this before, but can't we finally kill SSLv2? Both MSIE 7 Probably, but I am on MSIE6, because MSIE7 will not run on my OS and the relevant OS will not run on my hardware without an expensive upgrade so no IE7; and what is true for me at a personal level is true for many I work with. I do have SSLv2 support disabled, offering a choice of SSLv3 or TLS 1.0, and am not aware of any connection failures as a result but would not trust MS to tell me in an intelligible form:-( I will, soon, try disabling SSLv3 and see what happens. Tom Petch > and Firefox (Mozilla/whatever) have now removed support for it, which means > that it's finally dead no matter what the spec still says about it. > > Peter. > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Oct 27 04:50:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdNOa-0006j5-8C; Fri, 27 Oct 2006 04:48:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdNOY-0006h3-AR for tls@ietf.org; Fri, 27 Oct 2006 04:48:54 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdNOW-0003xr-T2 for tls@ietf.org; Fri, 27 Oct 2006 04:48:54 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9R8mmwS027164 for ; Fri, 27 Oct 2006 11:48:51 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 11:48:15 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 11:48:14 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 27 Oct 2006 11:48:15 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Conclusion of default PRF straw poll / new PRF selection Thread-Index: Acb5pKR8SsuB6HpqTPiZR/+L0G6vSQ== From: To: X-OriginalArrivalTime: 27 Oct 2006 08:48:15.0184 (UTC) FILETIME=[A439C500:01C6F9A4] X-Spam-Score: 0.2 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [TLS] Conclusion of default PRF straw poll / new PRF selection X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Based on the responses on the list, and the sense of the room at Montreal, I would say we have rough consensus that when TLS 1.2 is negotiated, ciphersuites that don't explicitly specify anything else (including all currently defined ciphersuites) will use the new TLS 1.2 PRF. We have not yet decided what that new PRF will be, though. To get a discussion started, I'd like to suggest the first candidate that=20 comes to my mind: P_SHA256 (current P_hash construction with SHA-256). Obviously, there are other good candidates as well. Comments or suggestions? Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Oct 27 05:31:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdO3C-0004st-C6; Fri, 27 Oct 2006 05:30:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdO3A-0004pq-Q8 for tls@ietf.org; Fri, 27 Oct 2006 05:30:52 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdO39-00023a-Cb for tls@ietf.org; Fri, 27 Oct 2006 05:30:52 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id k9R9UhDb031730; Fri, 27 Oct 2006 12:30:44 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 12:30:29 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 Oct 2006 12:30:29 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] TLS 1.1 and static DH Date: Fri, 27 Oct 2006 12:30:31 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] TLS 1.1 and static DH Thread-Index: Acb4VI7g3TgLeOshQNeTQIJdzlPjrwBVeqkA From: To: , X-OriginalArrivalTime: 27 Oct 2006 09:30:29.0369 (UTC) FILETIME=[8AB7B690:01C6F9AA] X-Spam-Score: 0.2 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Peter Gutmann wrote: > So perhaps the best option for TLS is to deprecate the static DH > suites. They seem to be pretty much entirely unsupported, and even > if you did want to support them you'd end up in a quagmire from > which extrication would prove difficult. This question may become important if we want to progress TLS 1.2 to Draft Standard, where we need two interoperable implementations for every feature. Based on the discussion so far, it looks like static DH suites might be one feature where meeting that bar could be difficult. Any opinions from the WG about this? Should we e.g. remove static=20 DH suites from TLS 1.2, move them to a separate document, or something else? Best regards, Pasi=09 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Oct 27 09:30:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdRlf-0001WY-G4; Fri, 27 Oct 2006 09:29:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdRld-0001WF-5o for tls@ietf.org; Fri, 27 Oct 2006 09:29:01 -0400 Received: from nat194.certicom.com ([66.48.18.194] helo=mail.ca.certicom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdRlZ-0003Rt-QU for tls@ietf.org; Fri, 27 Oct 2006 09:29:01 -0400 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 0F52F1038289F for ; Fri, 27 Oct 2006 09:28:49 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16149-34 for ; Fri, 27 Oct 2006 09:28:47 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 2BA70103B8289 for ; Fri, 27 Oct 2006 09:28:47 -0400 (EDT) In-Reply-To: To: tls@ietf.org Subject: RE: [TLS] TLS 1.1 and static DH MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Rob Dugal Date: Fri, 27 Oct 2006 09:28:03 -0400 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 7.0.1|January 17, 2006) at 10/27/2006 09:27:10 AM, Serialize complete at 10/27/2006 09:27:10 AM X-Spam-Score: 0.5 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Content-Type: multipart/mixed; boundary="===============2025001404==" Errors-To: tls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============2025001404== Content-Type: multipart/alternative; boundary="=_alternative 004A0A5085257214_=" This is a multipart message in MIME format. --=_alternative 004A0A5085257214_= Content-Type: text/plain; charset="US-ASCII" The Certicom SSL-C product does contain implementations of static DH ciphersuites. We don't currently have a public server available for testing this implementation. If there is enough interest we can add these ciphersuites to tls.secg.org ----------------------------------------------- Robert Dugal Member of Development Group Certicom Corp. EMAIL: rdugal@certicom.com PHONE: (905) 501-3848 FAX : (905) 507-4230 WEBSITE: www.certicom.com wrote on 10/27/2006 05:30:31 AM: > Peter Gutmann wrote: > > > So perhaps the best option for TLS is to deprecate the static DH > > suites. They seem to be pretty much entirely unsupported, and even > > if you did want to support them you'd end up in a quagmire from > > which extrication would prove difficult. > > This question may become important if we want to progress TLS 1.2 to > Draft Standard, where we need two interoperable implementations for > every feature. > > Based on the discussion so far, it looks like static DH suites might > be one feature where meeting that bar could be difficult. > > Any opinions from the WG about this? Should we e.g. remove static > DH suites from TLS 1.2, move them to a separate document, or > something else? > > Best regards, > Pasi > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls --=_alternative 004A0A5085257214_= Content-Type: text/html; charset="US-ASCII"
The Certicom SSL-C product does contain implementations of static DH ciphersuites.
We don't currently have a public server available for testing this implementation.
If there is enough interest we can add these ciphersuites to tls.secg.org


-----------------------------------------------
Robert Dugal
Member of Development Group
Certicom Corp.
EMAIL: rdugal@certicom.com
PHONE: (905) 501-3848
FAX  : (905) 507-4230
WEBSITE: www.certicom.com

<Pasi.Eronen@nokia.com> wrote on 10/27/2006 05:30:31 AM:

> Peter Gutmann wrote:
>
> > So perhaps the best option for TLS is to deprecate the static DH
> > suites.  They seem to be pretty much entirely unsupported, and even
> > if you did want to support them you'd end up in a quagmire from
> > which extrication would prove difficult.
>
> This question may become important if we want to progress TLS 1.2 to
> Draft Standard, where we need two interoperable implementations for
> every feature.
>
> Based on the discussion so far, it looks like static DH suites might
> be one feature where meeting that bar could be difficult.
>
> Any opinions from the WG about this? Should we e.g. remove static
> DH suites from TLS 1.2, move them to a separate document, or
> something else?
>
> Best regards,
> Pasi  
>
> _______________________________________________
> TLS mailing list
> TLS@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls
 --=_alternative 004A0A5085257214_=-- --===============2025001404== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============2025001404==-- From tls-bounces@lists.ietf.org Fri Oct 27 18:01:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdZjq-0002bh-G1; Fri, 27 Oct 2006 17:59:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GdZjp-0002aS-QD for tls@ietf.org; Fri, 27 Oct 2006 17:59:41 -0400 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GdZjo-0004YD-G7 for tls@ietf.org; Fri, 27 Oct 2006 17:59:41 -0400 Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id k9RLxdpY029757; Fri, 27 Oct 2006 16:59:39 -0500 (CDT) Received: from phal.lucentradius.com (phil.aaa.lucent.com [135.140.160.4]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id k9RLxcMw017881; Fri, 27 Oct 2006 16:59:39 -0500 (CDT) Received: from [135.140.160.28] (rocinante.lucentradius.com [135.140.160.28]) by phal.lucentradius.com (8.12.9+Sun/8.12.9) with ESMTP id k9RLxcXk008858; Fri, 27 Oct 2006 14:59:38 -0700 (PDT) Message-ID: <454280DA.10000@lucent.com> Date: Fri, 27 Oct 2006 14:57:46 -0700 From: Jan Nordqvist User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: Rob Dugal Subject: Re: [TLS] TLS 1.1 and static DH References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Well, since at least we went through the effort of implementing them it would be nice to test them out too... OTOH, if no one else implements or uses them, they may be of little use in the real world. In any case, we are interested to get through testing, preferably both client and server side. Jan Nordqvist Lucent Technologies Rob Dugal wrote: > > The Certicom SSL-C product does contain implementations of static DH > ciphersuites. > We don't currently have a public server available for testing this > implementation. > If there is enough interest we can add these ciphersuites to tls.secg.org > > > ----------------------------------------------- > Robert Dugal > Member of Development Group > Certicom Corp. > EMAIL: rdugal@certicom.com > PHONE: (905) 501-3848 > FAX : (905) 507-4230 > WEBSITE: www.certicom.com > > wrote on 10/27/2006 05:30:31 AM: > > > Peter Gutmann wrote: > > > > > So perhaps the best option for TLS is to deprecate the static DH > > > suites. They seem to be pretty much entirely unsupported, and even > > > if you did want to support them you'd end up in a quagmire from > > > which extrication would prove difficult. > > > > This question may become important if we want to progress TLS 1.2 to > > Draft Standard, where we need two interoperable implementations for > > every feature. > > > > Based on the discussion so far, it looks like static DH suites might > > be one feature where meeting that bar could be difficult. > > > > Any opinions from the WG about this? Should we e.g. remove static > > DH suites from TLS 1.2, move them to a separate document, or > > something else? > > > > Best regards, > > Pasi > > > > _______________________________________________ > > TLS mailing list > > TLS@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/tls > ------------------------------------------------------------------------ > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Oct 31 12:11:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gex6P-0001V7-Iz; Tue, 31 Oct 2006 12:08:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gex6M-0001UR-PW; Tue, 31 Oct 2006 12:08:39 -0500 Received: from carter-zimmerman.dyn.mit.edu ([18.188.3.148] helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gex6I-0007sr-HG; Tue, 31 Oct 2006 12:08:38 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id C2C43E0035; Tue, 31 Oct 2006 12:08:25 -0500 (EST) From: Sam Hartman To: tls@ietf.org,spkm@ietf.org Date: Tue, 31 Oct 2006 12:08:25 -0500 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Subject: [TLS] DTLS and GSS-API X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Monday morning at IETF 67 there is a really important BOF: SPKM. The purpose of this BOF is to decide how we will get a standards track solution for NFSV4 to use PKI credentials. Two modes are important: a mode where both parties have credentials and a mode where the server has a certificate and the client has a password. The current proposal is based off draft-adamson-rfc2847-01.txt. Several reviewers including Eric Rescorla and myself have expressed concerns about this draft. An alternate proposal for solving this problem was discussed in the past: construct a GSS-API mechanism based on DTLS. Advantages of this solution include reuse of code and specification between GSS-API and TLS implementations. When new ciphers are specified for TLS they would be available for NFS. We would not need to keep updating a GSS mechanism as public-key algorithms evolve and problems are found. There are two main drawbacks I've heard to the DTLS proposal. First, we don't have a draft. Second, it would not be interoperable with SPKM-3 deployments. I hope the BOF will answer the question of how much we care about SPKM-3 deployments. I only want to see one standards track solution in this space. Currently, there does not seem to be enough interest in the DTLS proposal for it to be a viable alternative. I would like to encourage the TLS community to take a look at draft-adamson-rfc2847-01 and to consider how a DTLS approach would work and think about whether advocating for such an approach would be a good idea. If so, someone at least needs to be prepared to give a brief presentation by next Monday on such a proposal. The BOF chair wanted to hear about anyone giving an alternative presentation by Wednesday of this week. I'm hoping he will be a bit flexible as I was supposed to write this message last Friday. Thanks for your consideration, --Sam _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls