From kmigoe@nsa.gov Wed Jan 4 05:15:31 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E871121F85BA; Wed, 4 Jan 2012 05:15:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y6fvyeFjYwPX; Wed, 4 Jan 2012 05:15:31 -0800 (PST) Received: from msux-gh1-uea01.nsa.gov (msux-gh1-uea01.nsa.gov [63.239.65.39]) by ietfa.amsl.com (Postfix) with ESMTP id 2A25521F8716; Wed, 4 Jan 2012 05:15:30 -0800 (PST) Received: from MSCS-GH1-UEA02.corp.nsa.gov (localhost [127.0.0.1]) by msux-gh1-uea01.nsa.gov (8.12.10/8.12.10) with ESMTP id q04DFPM6004461; Wed, 4 Jan 2012 13:15:29 GMT Received: from MSIS-GH1-UEA06.corp.nsa.gov ([10.215.228.137]) by MSCS-GH1-UEA02.corp.nsa.gov with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Jan 2012 08:14:37 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Wed, 4 Jan 2012 08:14:37 -0500 Message-ID: <80F9AC969A517A4DA0DE3E7CF74CC1BB425B8F@MSIS-GH1-UEA06.corp.nsa.gov> In-Reply-To: <10c1dacc5c5001fbaf130c3098f37dd8.squirrel@www.trepanning.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Cfrg] password-based key exchange Thread-Index: Acy/X7Yum82oOjagRhO3T6IYweJmAwLgcKcw References: <10c1dacc5c5001fbaf130c3098f37dd8.squirrel@www.trepanning.net> From: "Igoe, Kevin M." To: "Dan Harkins" , X-OriginalArrivalTime: 04 Jan 2012 13:14:37.0865 (UTC) FILETIME=[CF719990:01CCCAE2] X-Mailman-Approved-At: Wed, 04 Jan 2012 07:43:49 -0800 Cc: tls@ietf.org Subject: Re: [TLS] [Cfrg] password-based key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 13:15:32 -0000 I really like this idea & can find no problems. One nitpicking detail: HashToElement should return an element of a=20 cryptographic subgroup of (Z/pZ)*, i.e. an element of a cyclic subgroup=20 of prime order q, q suitably large. (Of course both sides should use the=20 same subgroup, but in practice this isn't a problem since the standard mod p=20 groups specify both q and an element g of order q which generates the=20 cryptographic subgroup.) I'm curious as to what size parameters are under consideration by IEEE. > -----Original Message----- > From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of > Dan Harkins > Sent: Tuesday, December 20, 2011 4:38 PM > To: cfrg@irtf.org > Cc: tls@ietf.org > Subject: [Cfrg] password-based key exchange >=20 >=20 > Hello, >=20 > I proposed a new TLS ciphersuite using a zero knowledge proof at > IETF 82 in Taipei. The draft is here: >=20 > http://tools.ietf.org/html/draft-harkins-tls-pwd-01 >=20 > At the TLS WG meeting I was requested to ask people on the CFRG list > with expertise in this field to take a look at it. So here I am, > asking. > If someone has some spare cycles this holiday season, if you just gotta > get away from the relatives, or you are just feeling in the giving > mood, > please take a look and comment. Any analysis on this would be greatly > appreciated. (I tried to do a formal proof but I cannot, and that's > what's prompting this). >=20 > I can describe the key exchange broadly here. There are subtle > differences in the draft-- like one side keeps a salted version of the > password and communicates the salt during a HELLO message-- that don't > affect the exchange. It is symmetric so I can describe it from one > side's > perspective. The side being described is "local" and the other side is > "peer", it goes like this: >=20 > Given: local ID, peer ID, password, an agreed-upon set of domain > parameters defining a finite field group (it works will elliptic > curve crypto too) and using two function: >=20 > - E =3D HashToElement(d) which takes some data, d, and hashes into > the finite field to return an element, E. > - x =3D H(y) returns a random stream, x, given some input, y. >=20 > The key exchange works like this: >=20 > 1. PE =3D HashToElement(local_ID | peer_ID | password) > gets a "password element" >=20 > There is an ordering defined in the draft to ensure that the IDs > are put in the same order on each side. >=20 > 2. generate 2 random numbers between 0 and the order of the group, q: >=20 > 0 < local_rand, local_mask < q >=20 > 3. compute a scalar and an element: > local_scalar =3D (local_rand + local_mask) mod q > local_element =3D 1/(PE^local_mask) mod p >=20 > where p is the prime and q is the order. Send local_scalar and > local_element to other side >=20 > 4. receive peer_scalar and peer_element from other side >=20 > 5. compute shared key, K >=20 > K =3D (PE^peer_scalar * peer_element)^local_rand mod p =3D > (PE^(peer_rand + peer_mask) * PE^(-peer_mask))^local_rand mod p > =3D > PE^(peer_rand*local_rand) mod p >=20 > 6. compute a confirmation >=20 > local_confirm =3D H(K, local_scalar | local_element | > peer_scalar | peer_element) >=20 > send confirmation to peer >=20 > 7. receive peer's confirmation, calculate verifier >=20 > verifier =3D H(K, peer_scalar | peer_element | local_scalar | > local_element) >=20 > if verifier equals peer's confirmation the peer is authenticated. >=20 > The peer does the same thing but from its perspective it is "local" > and the side described above is "peer". >=20 > Thank you in advance for any analysis that can be provided on this > exchange. >=20 > regards, >=20 > Dan. >=20 >=20 > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From dharkins@lounge.org Wed Jan 4 10:30:09 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5854D21F8798 for ; Wed, 4 Jan 2012 10:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.506 X-Spam-Level: X-Spam-Status: No, score=-5.506 tagged_above=-999 required=5 tests=[AWL=0.759, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TmvikPI+X7Jv for ; Wed, 4 Jan 2012 10:30:08 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id E511021F8788 for ; Wed, 4 Jan 2012 10:30:08 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id 859C1A88810C; Wed, 4 Jan 2012 10:30:08 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 4 Jan 2012 10:30:08 -0800 (PST) Message-ID: <4ef8068ab2486a8f2ba8e067c07be426.squirrel@www.trepanning.net> In-Reply-To: <80F9AC969A517A4DA0DE3E7CF74CC1BB425B8F@MSIS-GH1-UEA06.corp.nsa.gov> References: <10c1dacc5c5001fbaf130c3098f37dd8.squirrel@www.trepanning.net> <80F9AC969A517A4DA0DE3E7CF74CC1BB425B8F@MSIS-GH1-UEA06.corp.nsa.gov> Date: Wed, 4 Jan 2012 10:30:08 -0800 (PST) From: "Dan Harkins" To: "Igoe, Kevin M." User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: cfrg@irtf.org, tls@ietf.org Subject: Re: [TLS] [Cfrg] password-based key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2012 18:30:09 -0000 Hi Kevin, Thank you very much for reviewing this draft. On Wed, January 4, 2012 5:14 am, Igoe, Kevin M. wrote: > I really like this idea & can find no problems. > > One nitpicking detail: HashToElement should return an element of a > cryptographic subgroup of (Z/pZ)*, i.e. an element of a cyclic subgroup > of prime order q, q suitably large. (Of course both sides should use > the > same subgroup, but in practice this isn't a problem since the standard > mod p > groups specify both q and an element g of order q which generates the > cryptographic subgroup.) I believe the two techniques used in section 4.1-- one for FFC groups, another for ECC groups-- return an element from a subgroup of prime order q. > I'm curious as to what size parameters are under consideration by IEEE. The specification of this key exchange in IEEE 802.11 uses the IANA registry created by IKE for "diffie-hellman groups" so it can use the NIST elliptic curves, and the safe prime FFC groups (from 1024 bits up to 8192 bits). Implementations are required to support NIST's 256 bit random ECP group (group 19 from IKE's IANA registry). regards, Dan. From jkatz@cs.umd.edu Wed Jan 4 17:27:35 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CC0621F856B for ; Wed, 4 Jan 2012 17:27:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 89hsQrh8G-7x for ; Wed, 4 Jan 2012 17:27:35 -0800 (PST) Received: from bacon.cs.umd.edu (router-304.cs.umd.edu [128.8.127.145]) by ietfa.amsl.com (Postfix) with ESMTP id 3295E21F8551 for ; Wed, 4 Jan 2012 17:27:34 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) (Authenticated sender: jkatz) by bacon.cs.umd.edu (Postfix) with ESMTPSA id E7018B40644 for ; Wed, 4 Jan 2012 20:27:30 -0500 (EST) Received: by iabz21 with SMTP id z21so68813iab.31 for ; Wed, 04 Jan 2012 17:27:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.219.226 with SMTP id pr2mr68396348igc.30.1325726850542; Wed, 04 Jan 2012 17:27:30 -0800 (PST) Received: by 10.231.49.65 with HTTP; Wed, 4 Jan 2012 17:27:30 -0800 (PST) Date: Wed, 4 Jan 2012 20:27:30 -0500 Message-ID: From: Jonathan Katz To: cfrg@irtf.org Content-Type: text/plain; charset=ISO-8859-1 X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.3.8 (bacon.cs.umd.edu [0.0.0.0]); Wed, 04 Jan 2012 20:27:30 -0500 (EST) X-CSD-MailScanner-ID: E7018B40644.A90C2 X-CSD-MailScanner: Found to be clean X-CSD-MailScanner-SpamCheck: not spam, SpamAssassin (cached, score=-50, required 5, autolearn=not spam, ALL_TRUSTED -50.00) X-CSD-MailScanner-From: jkatz@cs.umd.edu X-CSD-MailScanner-Watermark: 1326331651.24548@kNbO2FU/EU5Sol8Aj8QImA X-Mailman-Approved-At: Wed, 04 Jan 2012 17:32:36 -0800 Cc: tls@ietf.org Subject: Re: [TLS] password-based key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 01:27:35 -0000 You don't specify your threat model. One formal model for password-based key exchange is the one introduced by Bellare, Pointcheval, and Rogaway in 2000 and used in several papers since then. What threat model did you have in mind? (In fact, the protocol seems susceptible to attacks within the [BPR00] model, although I didn't manage to find any full-fledged attack.) Some other "obvious" things you may want to consider: - It's usually considered a bad idea to let the final session key be one that was also used for key confirmation. So you may want to add a step where the final session key is derived (using a suitable KDF) from the intermediate key K. - To head off potential avenues of attack, it is probably a good idea to have peer check that local_scalar \neq 0 and local_element \neq 1, and vice versa. > -----Original Message----- > From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf Of > Dan Harkins > Sent: Tuesday, December 20, 2011 4:38 PM > To: cfrg@irtf.org > Cc: tls@ietf.org > Subject: [Cfrg] password-based key exchange > > > Hello, > > I proposed a new TLS ciphersuite using a zero knowledge proof at > IETF 82 in Taipei. The draft is here: > > http://tools.ietf.org/html/draft-harkins-tls-pwd-01 > > At the TLS WG meeting I was requested to ask people on the CFRG list > with expertise in this field to take a look at it. So here I am, > asking. > If someone has some spare cycles this holiday season, if you just gotta > get away from the relatives, or you are just feeling in the giving > mood, > please take a look and comment. Any analysis on this would be greatly > appreciated. (I tried to do a formal proof but I cannot, and that's > what's prompting this). > > I can describe the key exchange broadly here. There are subtle > differences in the draft-- like one side keeps a salted version of the > password and communicates the salt during a HELLO message-- that don't > affect the exchange. It is symmetric so I can describe it from one > side's > perspective. The side being described is "local" and the other side is > "peer", it goes like this: > > Given: local ID, peer ID, password, an agreed-upon set of domain > parameters defining a finite field group (it works will elliptic > curve crypto too) and using two function: > > - E = HashToElement(d) which takes some data, d, and hashes into > the finite field to return an element, E. > - x = H(y) returns a random stream, x, given some input, y. > > The key exchange works like this: > > 1. PE = HashToElement(local_ID | peer_ID | password) > gets a "password element" > > There is an ordering defined in the draft to ensure that the IDs > are put in the same order on each side. > > 2. generate 2 random numbers between 0 and the order of the group, q: > > 0 < local_rand, local_mask < q > > 3. compute a scalar and an element: > local_scalar = (local_rand + local_mask) mod q > local_element = 1/(PE^local_mask) mod p > > where p is the prime and q is the order. Send local_scalar and > local_element to other side > > 4. receive peer_scalar and peer_element from other side > > 5. compute shared key, K > > K = (PE^peer_scalar * peer_element)^local_rand mod p = > (PE^(peer_rand + peer_mask) * PE^(-peer_mask))^local_rand mod p > = > PE^(peer_rand*local_rand) mod p > > 6. compute a confirmation > > local_confirm = H(K, local_scalar | local_element | > peer_scalar | peer_element) > > send confirmation to peer > > 7. receive peer's confirmation, calculate verifier > > verifier = H(K, peer_scalar | peer_element | local_scalar | > local_element) > > if verifier equals peer's confirmation the peer is authenticated. > > The peer does the same thing but from its perspective it is "local" > and the side described above is "peer". > > Thank you in advance for any analysis that can be provided on this > exchange. > > regards, > > Dan. > > > _______________________________________________ > Cfrg mailing list > Cfrg@irtf.org > http://www.irtf.org/mailman/listinfo/cfrg From dharkins@lounge.org Wed Jan 4 18:47:28 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0947411E808C for ; Wed, 4 Jan 2012 18:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.759 X-Spam-Level: X-Spam-Status: No, score=-5.759 tagged_above=-999 required=5 tests=[AWL=0.506, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lZKTtpfZaG2n for ; Wed, 4 Jan 2012 18:47:27 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC7E21F84EE for ; Wed, 4 Jan 2012 18:47:27 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id C12CDA88810C; Wed, 4 Jan 2012 18:47:25 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Wed, 4 Jan 2012 18:47:26 -0800 (PST) Message-ID: In-Reply-To: References: Date: Wed, 4 Jan 2012 18:47:26 -0800 (PST) From: "Dan Harkins" To: "Jonathan Katz" User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: cfrg@irtf.org, tls@ietf.org Subject: Re: [TLS] password-based key exchange X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 02:47:28 -0000 Hello, Thank you for looking at this protocol. On Wed, January 4, 2012 5:27 pm, Jonathan Katz wrote: > You don't specify your threat model. One formal model for > password-based key exchange is the one introduced by Bellare, > Pointcheval, and Rogaway in 2000 and used in several papers since > then. What threat model did you have in mind? That is one I had in mind. I think this protocol can be described in that model. Each side is an instance of the protocol controlled by a principle. Each side consumes and produces flows until they accept. While the distinction is not apparent in the TLS version of this key exchange, the 802.11 one does note that "acceptance" (obtaining a good session key) is different than "termination" (quitting the protocol run). I looked closely at their paper "Authenticated Key Exchange Secure Against Dictionary Attacks" but I do not have the information-theoretic background to complete a proof of this protocol in that model. If you happen to know a student who wants make a name for himself or herself by finding a flaw in the latest version of 802.11 (and hopefully in a new TLS ciphersuite) please have him or her take a look. I imagine there could be a paper in it. :-) > (In fact, the protocol seems susceptible to attacks within the [BPR00] > model, although I didn't manage to find any full-fledged attack.) Can you elaborate on what seems susceptible to attack? > Some other "obvious" things you may want to consider: > - It's usually considered a bad idea to let the final session key be > one that was also used for key confirmation. So you may want to add a > step where the final session key is derived (using a suitable KDF) > from the intermediate key K. The key becomes the pre-master secret in TLS and that does get input into a KDF to derive a suitable set of keys for protecting the application data. This was not obvious in the brief overview I presented below, my bad. > - To head off potential avenues of attack, it is probably a good idea > to have peer check that local_scalar \neq 0 and local_element \neq 1, > and vice versa. Thank you for this. Such a check is made upon receipt of the peer's scalar and element, and at generation time there is a check that local_scalar is not equal to 0 but there is no check that local_element is valid (for FFC, between 1 and p, and exponentiation of the element with the order does equal 1; and, for ECC, the coordinates satisfy the equation of the curve and the element is not the "point at infinity"). I will add the missing element check at generation time. regards, Dan. > >> -----Original Message----- >> From: cfrg-bounces@irtf.org [mailto:cfrg-bounces@irtf.org] On Behalf > Of >> Dan Harkins >> Sent: Tuesday, December 20, 2011 4:38 PM >> To: cfrg@irtf.org >> Cc: tls@ietf.org >> Subject: [Cfrg] password-based key exchange >> >> >> Hello, >> >> I proposed a new TLS ciphersuite using a zero knowledge proof at >> IETF 82 in Taipei. The draft is here: >> >> http://tools.ietf.org/html/draft-harkins-tls-pwd-01 >> >> At the TLS WG meeting I was requested to ask people on the CFRG list >> with expertise in this field to take a look at it. So here I am, >> asking. >> If someone has some spare cycles this holiday season, if you just > gotta >> get away from the relatives, or you are just feeling in the giving >> mood, >> please take a look and comment. Any analysis on this would be greatly >> appreciated. (I tried to do a formal proof but I cannot, and that's >> what's prompting this). >> >> I can describe the key exchange broadly here. There are subtle >> differences in the draft-- like one side keeps a salted version of the >> password and communicates the salt during a HELLO message-- that don't >> affect the exchange. It is symmetric so I can describe it from one >> side's >> perspective. The side being described is "local" and the other side is >> "peer", it goes like this: >> >> Given: local ID, peer ID, password, an agreed-upon set of domain >> parameters defining a finite field group (it works will elliptic >> curve crypto too) and using two function: >> >> - E = HashToElement(d) which takes some data, d, and hashes into >> the finite field to return an element, E. >> - x = H(y) returns a random stream, x, given some input, y. >> >> The key exchange works like this: >> >> 1. PE = HashToElement(local_ID | peer_ID | password) >> gets a "password element" >> >> There is an ordering defined in the draft to ensure that the IDs >> are put in the same order on each side. >> >> 2. generate 2 random numbers between 0 and the order of the group, q: >> >> 0 < local_rand, local_mask < q >> >> 3. compute a scalar and an element: >> local_scalar = (local_rand + local_mask) mod q >> local_element = 1/(PE^local_mask) mod p >> >> where p is the prime and q is the order. Send local_scalar and >> local_element to other side >> >> 4. receive peer_scalar and peer_element from other side >> >> 5. compute shared key, K >> >> K = (PE^peer_scalar * peer_element)^local_rand mod p = >> (PE^(peer_rand + peer_mask) * PE^(-peer_mask))^local_rand mod p >> = >> PE^(peer_rand*local_rand) mod p >> >> 6. compute a confirmation >> >> local_confirm = H(K, local_scalar | local_element | >> peer_scalar | peer_element) >> >> send confirmation to peer >> >> 7. receive peer's confirmation, calculate verifier >> >> verifier = H(K, peer_scalar | peer_element | local_scalar | >> local_element) >> >> if verifier equals peer's confirmation the peer is authenticated. >> >> The peer does the same thing but from its perspective it is "local" >> and the side described above is "peer". >> >> Thank you in advance for any analysis that can be provided on this >> exchange. >> >> regards, >> >> Dan. >> >> >> _______________________________________________ >> Cfrg mailing list >> Cfrg@irtf.org >> http://www.irtf.org/mailman/listinfo/cfrg > From Kenny.Paterson@rhul.ac.uk Thu Jan 5 08:43:24 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05D1B21F8737 for ; Thu, 5 Jan 2012 08:43:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.739 X-Spam-Level: X-Spam-Status: No, score=-0.739 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RaE+iggJn5Sw for ; Thu, 5 Jan 2012 08:43:23 -0800 (PST) Received: from gse-mta-17.emailfiltering.com (ixe-mta-17-tx.emailfiltering.com [194.116.198.149]) by ietfa.amsl.com (Postfix) with ESMTP id DF11121F8723 for ; Thu, 5 Jan 2012 08:43:22 -0800 (PST) Received: from exch-hub01.rhul.ac.uk ([134.219.208.107]) by gse-mta-17.emailfiltering.com with emfmta (version 4.8.5.70) by TLS id 2931973312 for tls@ietf.org;28d8ffffcafe1c78; Thu, 05 Jan 2012 16:43:21 +0000 Received: from exch-cas01.cc.rhul.local (2002:86db:d06d::86db:d06d) by EXCH-HUB01.cc.rhul.local (2002:86db:d06b::86db:d06b) with Microsoft SMTP Server (TLS) id 14.1.339.1; Thu, 5 Jan 2012 16:43:20 +0000 Received: from EXCH-MB02.cc.rhul.local ([169.254.1.242]) by exch-cas01.cc.rhul.local ([2002:86db:d06d::86db:d06d]) with mapi id 14.01.0339.001; Thu, 5 Jan 2012 16:43:20 +0000 From: "Paterson, Kenny" To: "tls@ietf.org" Thread-Topic: [TLS] DTLS implementation attack? Thread-Index: AQHMy8khtVqi5LLXF02jRRe7qFt/3w== Date: Thu, 5 Jan 2012 16:43:19 +0000 Message-ID: <26E4ABB2-E0AF-4502-9307-9EB3C1B0AC50@rhul.ac.uk> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [78.147.248.116] Content-Type: multipart/alternative; boundary="_000_26E4ABB2E0AF450293079EB3C1B0AC50rhulacuk_" MIME-Version: 1.0 Subject: Re: [TLS] DTLS implementation attack? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2012 16:43:24 -0000 --_000_26E4ABB2E0AF450293079EB3C1B0AC50rhulacuk_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable On Tue, Dec 6, 2011 at 5:56 PM, Marsh Ray > wrote: > Anyone have more info on this? > Even just a CVE or 'fixed in' version would be helpful. > http://www.isoc.org/isoc/conferences/ndss/12/program.shtml#1a > Plaintext-Recovery Attacks Against Datagram TLS The OpenSSL version of this attack, to be presented at NDSS 2011, has now b= een given CVE-2011-4108. A paper describing the attack can be found at: www.isg.rhul.ac.uk/~kp/dtls.= pdf Cheers, Kenny Paterson --_000_26E4ABB2E0AF450293079EB3C1B0AC50rhulacuk_ Content-Type: text/html; charset="us-ascii" Content-ID: <8B8236E09188804CAB15DA1970DFEBED@rhul.ac.uk> Content-Transfer-Encoding: quoted-printable 
On Tue, Dec 6, 2011 at 5:56 PM, Marsh Ray <marsh at extendedsubset.com> wrote:

> Anyone have more info on this?
> Even just a CVE or 'fixed in' version would be helpful.
> http://www.isoc.org/isoc/conferences/ndss/12/program.s=
html#1a
> Plaintext-Recovery Attacks Against Datagram TLS
The OpenSSL version of this attack, to be presented at NDSS 2011, has = now been given CVE-2011-4108.

A paper describing the attack can be found at: www.isg.rhul.ac.uk/~kp/dtls.pdf

Cheers,

Kenny Paterson
--_000_26E4ABB2E0AF450293079EB3C1B0AC50rhulacuk_-- From internet-drafts@ietf.org Sun Jan 8 20:51:55 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 850E021F8623; Sun, 8 Jan 2012 20:51:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MvCUq5cGyHw7; Sun, 8 Jan 2012 20:51:54 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCE3E21F85EE; Sun, 8 Jan 2012 20:51:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120109045154.21988.41420.idtracker@ietfa.amsl.com> Date: Sun, 08 Jan 2012 20:51:54 -0800 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-oob-pubkey-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 04:51:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Layer Security Working Grou= p of the IETF. Title : TLS Out-of-Band Public Key Validation Author(s) : Paul Wouters John Gilmore Samuel Weiler Tero Kivinen Hannes Tschofenig Filename : draft-ietf-tls-oob-pubkey-00.txt Pages : 10 Date : 2012-01-07 This document specifies a new TLS certificate type for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) for use with out-of-band authentication. Currently, TLS authentication can only occur via PKIX or OpenPGP certificates. By specifying a minimum resource for raw public key exchange, implementations can use alternative authentication methods. One such method is using DANE Resource Records secured by DNSSEC, Another use case is to provide authentication functionality when used with devices in a constrained environment that use whitelists and blacklists, as is the case with sensors and other embedded devices that are constrained by memory, computational, and communication limitations where the usage of PKIX is not feasible. The new certificate type specified can also be used to reduce the latency of a TLS client that is already in possession of a validated public key of the TLS server before it starts a (non-resumed) TLS handshake. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-oob-pubkey-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-oob-pubkey-00.txt From frantz@pwpconsult.com Mon Jan 9 15:30:57 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BCE221F84FC for ; Mon, 9 Jan 2012 15:30:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wMZlcRhw0STU for ; Mon, 9 Jan 2012 15:30:56 -0800 (PST) Received: from elasmtp-kukur.atl.sa.earthlink.net (elasmtp-kukur.atl.sa.earthlink.net [209.86.89.65]) by ietfa.amsl.com (Postfix) with ESMTP id 93D8A21F84EA for ; Mon, 9 Jan 2012 15:30:56 -0800 (PST) Received: from [173.75.83.82] (helo=Bill-Frantzs-MacBook-Pro.local) by elasmtp-kukur.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1RkOg3-0006Lc-RY for tls@ietf.org; Mon, 09 Jan 2012 18:30:56 -0500 Date: Mon, 9 Jan 2012 15:30:55 -0800 From: Bill Frantz To: tls@ietf.org X-Priority: 3 In-Reply-To: <20120109045154.21988.41420.idtracker@ietfa.amsl.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79620e23a25fa58b37144a3076c064fc38350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.82 Subject: Re: [TLS] I-D Action: draft-ietf-tls-oob-pubkey-00.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2012 23:30:57 -0000 On 1/8/12 at 20:51, internet-drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line=20 >Internet-Drafts directories. This draft is a work item of the=20 >Transport Layer Security Working Group of the IETF. > >Title : TLS Out-of-Band Public Key Validation >Author(s) : Paul Wouters >John Gilmore >Samuel Weiler >Tero Kivinen >Hannes Tschofenig >Filename : draft-ietf-tls-oob-pubkey-00.txt >Pages : 10 >Date : 2012-01-07 Just a nit, but section 2.1 starts: In order to indicate the support of out-of-bound raw public keys, Shouldn't that be: In order to indicate the support of out-of-band raw public keys, This extension should help support YURLs=20 , where authentication=20 information is included in a URL. The resistance of YURLs to=20 fishing attacks is described in . Cheers - Bill ----------------------------------------------------------------------- Bill Frantz | If the site is supported by | Periwinkle (408)356-8506 | ads, you are the product. | 16345=20 Englewood Ave www.pwpconsult.com | | Los Gatos,=20 CA 95032 From yuhongbao_386@hotmail.com Thu Jan 12 23:30:00 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5748E21F84E0 for ; Thu, 12 Jan 2012 23:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.5 X-Spam-Level: *** X-Spam-Status: No, score=3.5 tagged_above=-999 required=5 tests=[BAYES_99=3.5] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hx6e899C7S4t for ; Thu, 12 Jan 2012 23:29:59 -0800 (PST) Received: from snt0-omc3-s48.snt0.hotmail.com (snt0-omc3-s48.snt0.hotmail.com [65.54.51.85]) by ietfa.amsl.com (Postfix) with ESMTP id 786D921F84A5 for ; Thu, 12 Jan 2012 23:29:59 -0800 (PST) Received: from SNT125-W32 ([65.55.90.137]) by snt0-omc3-s48.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 12 Jan 2012 23:29:59 -0800 Message-ID: X-Originating-IP: [76.178.157.127] From: Yuhong Bao To: Date: Thu, 12 Jan 2012 23:29:58 -0800 Importance: Normal Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 Jan 2012 07:29:59.0225 (UTC) FILETIME=[27BB4A90:01CCD1C5] Subject: [TLS] MS12-006 released X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 07:30:00 -0000 Have anyone took a look at it? Yuhong Bao = From marsh@extendedsubset.com Fri Jan 13 07:44:28 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06B4621F8577 for ; Fri, 13 Jan 2012 07:44:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MzV8NjutCZTi for ; Fri, 13 Jan 2012 07:44:27 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by ietfa.amsl.com (Postfix) with ESMTP id 4968521F8572 for ; Fri, 13 Jan 2012 07:44:26 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1RljIo-00016Q-Cb; Fri, 13 Jan 2012 15:44:26 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id A7D5A63C1; Fri, 13 Jan 2012 15:44:25 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+V6ObdxYGpszAZ6FipQ4XU9rc3Sx+pZTY= Message-ID: <4F105159.7050103@extendedsubset.com> Date: Fri, 13 Jan 2012 09:44:25 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: Yuhong Bao References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] MS12-006 released X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 15:44:28 -0000 On 01/13/2012 01:29 AM, Yuhong Bao wrote: > > Have anyone took a look at it? http://technet.microsoft.com/en-us/security/bulletin/ms12-006 Links to http://technet.microsoft.com/en-us/security/advisory/2588513 which links to http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3389 the BEAST attack. I haven't looked at it on the wire, but my understanding is that Microsoft's patch is a "one byte record" fix similar to the other implementations. - Marsh From agl@google.com Fri Jan 13 07:47:11 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8F421F8607 for ; Fri, 13 Jan 2012 07:47:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hUtceIRlIyxb for ; Fri, 13 Jan 2012 07:47:10 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8949E21F85B9 for ; Fri, 13 Jan 2012 07:47:10 -0800 (PST) Received: by ggnr5 with SMTP id r5so1963791ggn.31 for ; Fri, 13 Jan 2012 07:47:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:x-system-of-record:content-type; bh=HHstq9vrtafmefxi/ED5HtR1ZSsIrTcrT2R2FIj0+A8=; b=IuVPZ3MFmWerNQqZ1Y18UHTnVaF6dB2XCyRn/EIZwGU2sAW7YDOJPkvWVC4Job4RQN 4hXxJs9lJeBefMXBb3RAQi8JzDNWYjtj0cvdShgIHBQ2BzQQbA1Aj4gWscurcVHM1Y0n Kvf+yVk7Cl11c4TQm+vLQoqnp5mA671RNGXKc= Received: by 10.50.193.229 with SMTP id hr5mr1316102igc.15.1326469628877; Fri, 13 Jan 2012 07:47:08 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.193.229 with SMTP id hr5mr1316089igc.15.1326469628763; Fri, 13 Jan 2012 07:47:08 -0800 (PST) Received: by 10.231.122.69 with HTTP; Fri, 13 Jan 2012 07:47:08 -0800 (PST) In-Reply-To: <4F105159.7050103@extendedsubset.com> References: <4F105159.7050103@extendedsubset.com> Date: Fri, 13 Jan 2012 10:47:08 -0500 Message-ID: From: Adam Langley To: Marsh Ray X-System-Of-Record: true Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] MS12-006 released X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 15:47:11 -0000 On Fri, Jan 13, 2012 at 10:44 AM, Marsh Ray wrote: > I haven't looked at it on the wire, but my understanding is that Microsoft's > patch is a "one byte record" fix similar to the other implementations. >From looking at packet dumps, the SChannel change appears to be exactly the same 1/n-1 record splitting as implemented in Chrome 16 and Firefox 10. http://support.microsoft.com/kb/2643584 describes how it's off by default (per a registry setting), but that IE explicitly enables it. Cheers AGL From stephen.farrell@cs.tcd.ie Fri Jan 13 10:26:34 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF87121F84E1; Fri, 13 Jan 2012 10:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.507 X-Spam-Level: X-Spam-Status: No, score=-102.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9hw88tmRiJ4y; Fri, 13 Jan 2012 10:26:34 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:889f:cdff:fe8d:ccd2]) by ietfa.amsl.com (Postfix) with ESMTP id 48C5821F849D; Fri, 13 Jan 2012 10:26:19 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id 66CB1171CC3; Fri, 13 Jan 2012 18:26:19 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1326479178; bh=3R2RTxtYEZE96C 1vaPyq8mMqTa5543cjo2S9hxXqPb8=; b=2iWKMAG/oVVEKOMcLDwf0qsQ59fyCo UnnPfLOn3Vc2D9jN0f8R60XiRTS0VgYS4fSp/mAoTW3pqiQhZP3f6qiB3vtJLlDO efY5gyGovQ10Py9L4DLbWyTCfpQmOr4f/7ik9V6ZYRwGg2UKqNm/FBjB+4t8SGwv BEaiAlERvAW/mvxP9MK3q0l6QUC6ZbySmcUBDW0qnQXul/NxnnnpYw8StIX985t1 2/8tmSu3tRPyBbwPpCxPokZ7MlhYhZJBsidBpigmyJXE8WB9DAMfKnFQevczDcny o3KFA2jvsl/E1f+7GMFGDj+6UkhgnNtkDOvw5fM9d7mzDjaem7wUzlEg== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id vhvCUBUgTFFA; Fri, 13 Jan 2012 18:26:18 +0000 (GMT) Received: from [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c] (unknown [IPv6:2001:770:10:203:a288:b4ff:fe9c:bc5c]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id D8F19171CC2; Fri, 13 Jan 2012 18:26:18 +0000 (GMT) Message-ID: <4F10774A.4030003@cs.tcd.ie> Date: Fri, 13 Jan 2012 18:26:18 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "saag@ietf.org" , pkix , "tls@ietf.org" , dane References: <20120113182358.143B621F8579@ietfa.amsl.com> In-Reply-To: <20120113182358.143B621F8579@ietfa.amsl.com> X-Forwarded-Message-Id: <20120113182358.143B621F8579@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [TLS] Fwd: New Non-WG Mailing List: therightkey X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 18:26:34 -0000 FYI please sign up if interested but wait a few days to give folks a chance to sign up before starting in on discussion. Stephen & Sean. -------- Original Message -------- Subject: New Non-WG Mailing List: therightkey Date: Fri, 13 Jan 2012 10:23:58 -0800 (PST) From: IETF Secretariat To: IETF Announcement list CC: therightkey@ietf.org, turners@ieca.com, stephen.farrell@cs.tcd.ie A new IETF non-working group email list has been created. List address: therightkey@ietf.org Archive: http://www.ietf.org/mail-archive/web/therightkey/ To subscribe: https://www.ietf.org/mailman/listinfo/therightkey Purpose: A number of people are interested in discussing proposals that have been developed in response to recent attacks on the Internet security infrastructure, in particular those that affected sites using TLS and other protocols relying on PKI. This list is intended for discussion of those proposals and how they might result in potential work items for the IETF. One short-term outcome may be the holding of a non-wg-forming BoF at IETF-83. For additional information, please contact the list administrators. From lists@eitanadler.com Fri Jan 13 10:42:09 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7FE721F8525; Fri, 13 Jan 2012 10:42:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1SvjINYrfYy; Fri, 13 Jan 2012 10:42:09 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4CEC521F8510; Fri, 13 Jan 2012 10:42:08 -0800 (PST) Received: by lagv3 with SMTP id v3so554572lag.31 for ; Fri, 13 Jan 2012 10:42:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=eitanadler.com; s=0xdeadbeef; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=zEqiSTI0kUfE8t0d2rhU9cggrqdYyj8NdkjEUvWr5Hs=; b=mqYgv976GacNbjYqfoQ4W9CSpXruFChLFmSXq11fihe7mRYy5TsidU3Lp+Vo5T88ky yNKMbK4yNlPceNNplYOE32RSLcoYqxTULBTZ+49dQejIxDAmndmeDbtayV69+2fLW/0a 3uidnRNYe8+b6+s9HAdLrvG4QxoX5XSiKrekY= Received: by 10.112.84.170 with SMTP id a10mr542543lbz.22.1326480127218; Fri, 13 Jan 2012 10:42:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.17.163 with HTTP; Fri, 13 Jan 2012 10:41:36 -0800 (PST) In-Reply-To: <4F10774A.4030003@cs.tcd.ie> References: <20120113182358.143B621F8579@ietfa.amsl.com> <4F10774A.4030003@cs.tcd.ie> From: Eitan Adler Date: Fri, 13 Jan 2012 13:41:36 -0500 Message-ID: To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Cc: pkix , dane , "saag@ietf.org" , "tls@ietf.org" Subject: Re: [TLS] Fwd: New Non-WG Mailing List: therightkey X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 18:42:09 -0000 On Fri, Jan 13, 2012 at 1:26 PM, Stephen Farrell wrote: > Archive: http://www.ietf.org/mail-archive/web/therightkey/ This link is dead. Typo, or not yet available? -- Eitan Adler From Jeff.Hodges@KingsMountain.com Fri Jan 13 14:04:13 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0887911E8072 for ; Fri, 13 Jan 2012 14:04:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.862 X-Spam-Level: X-Spam-Status: No, score=-99.862 tagged_above=-999 required=5 tests=[AWL=0.633, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpQoH3jPMOVC for ; Fri, 13 Jan 2012 14:04:12 -0800 (PST) Received: from oproxy1-pub.bluehost.com (oproxy1.bluehost.com [IPv6:2605:dc00:100:2::a1]) by ietfa.amsl.com (Postfix) with SMTP id 65F9821F853F for ; Fri, 13 Jan 2012 14:04:12 -0800 (PST) Received: (qmail 16918 invoked by uid 0); 13 Jan 2012 22:04:11 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy1.bluehost.com with SMTP; 13 Jan 2012 22:04:11 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=K5fLWk9NdcjZ1wMxoZ7a/vmj2xkxoDzn7PpB5ok02iA=; b=Mqm3PJic+5lIyaHAzT1cYeBbxaZcyMPGnFl7i59gmkvQ8FuL/Bx6eKiLG5iMYte7kl5i3+kkeL7M14pyQcH9sibLLKQBIOBFftjyEV8LUdDTQK1tR4Qw7peR0pX24FA3; Received: from outbound4.ebay.com ([216.113.168.128] helo=[10.244.137.162]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RlpEJ-00033q-32; Fri, 13 Jan 2012 15:04:11 -0700 Message-ID: <4F10AA5B.8050503@KingsMountain.com> Date: Fri, 13 Jan 2012 14:04:11 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: pkix , dane , "saag@ietf.org" , "tls@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 216.113.168.128 authed with jeff.hodges+kingsmountain.com} Subject: Re: [TLS] Fwd: New Non-WG Mailing List: therightkey X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2012 22:04:13 -0000 > On Fri, Jan 13, 2012 at 1:26 PM, Stephen Farrell > wrote: >> Archive: http://www.ietf.org/mail-archive/web/therightkey/ > > This link is dead. Typo, or not yet available? works for me! see also: https://www.ietf.org/mailman/listinfo/therightkey HtH, =JeffH From ynir@checkpoint.com Sat Jan 14 01:03:54 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A26121F85BB; Sat, 14 Jan 2012 01:03:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1689OwFduWb; Sat, 14 Jan 2012 01:03:53 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 6B76221F85AF; Sat, 14 Jan 2012 01:03:52 -0800 (PST) X-CheckPoint: {4F11425B-0-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q0E93o71011172; Sat, 14 Jan 2012 11:03:51 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 14 Jan 2012 11:03:50 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Sat, 14 Jan 2012 11:03:49 +0200 From: Yoav Nir To: =JeffH Date: Sat, 14 Jan 2012 11:03:50 +0200 Thread-Topic: [dane] Fwd: New Non-WG Mailing List: therightkey Thread-Index: AczSm25ntan/4oQoRnu1dXwzszgw8A== Message-ID: <4218085B-5136-4ADF-AD00-50DB3C7EB72F@checkpoint.com> References: <4F10AA5B.8050503@KingsMountain.com> In-Reply-To: <4F10AA5B.8050503@KingsMountain.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: pkix , "saag@ietf.org" , "tls@ietf.org" , dane Subject: Re: [TLS] [dane] Fwd: New Non-WG Mailing List: therightkey X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 14 Jan 2012 09:03:54 -0000 On Jan 14, 2012, at 12:04 AM, =3DJeffH wrote: >> On Fri, Jan 13, 2012 at 1:26 PM, Stephen Farrell >> wrote: >>> Archive: http://www.ietf.org/mail-archive/web/therightkey/ >>=20 >> This link is dead. Typo, or not yet available? >=20 > works for me! +1 From yuhongbao_386@hotmail.com Sat Jan 14 20:06:59 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59B2D21F8475 for ; Sat, 14 Jan 2012 20:06:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.38 X-Spam-Level: * X-Spam-Status: No, score=1.38 tagged_above=-999 required=5 tests=[AWL=2.120, BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1lGWhBt8mdk1 for ; Sat, 14 Jan 2012 20:06:58 -0800 (PST) Received: from snt0-omc2-s47.snt0.hotmail.com (snt0-omc2-s47.snt0.hotmail.com [65.54.61.98]) by ietfa.amsl.com (Postfix) with ESMTP id CE76A21F8473 for ; Sat, 14 Jan 2012 20:06:58 -0800 (PST) Received: from SNT125-W42 ([65.55.90.72]) by snt0-omc2-s47.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 14 Jan 2012 20:06:58 -0800 Message-ID: X-Originating-IP: [76.178.157.127] From: Yuhong Bao To: , Date: Sat, 14 Jan 2012 20:06:56 -0800 Importance: Normal In-Reply-To: References: , <4F105159.7050103@extendedsubset.com>, Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 15 Jan 2012 04:06:58.0800 (UTC) FILETIME=[20756F00:01CCD33B] Cc: tls@ietf.org Subject: Re: [TLS] MS12-006 released X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Jan 2012 04:06:59 -0000 > On Fri=2C Jan 13=2C 2012 at 10:44 AM=2C Marsh Ray wrote: > > I haven't looked at it on the wire=2C but my understanding is that Micr= osoft's > > patch is a "one byte record" fix similar to the other implementations. > > From looking at packet dumps=2C the SChannel change appears to be > exactly the same 1/n-1 record splitting as implemented in Chrome 16 > and Firefox 10. http://support.microsoft.com/kb/2643584 describes how > it's off by default (per a registry setting)=2C but that IE explicitly > enables it. But I am particularly thinking of the "incorrect version checking on the pr= emaster secret" bug. Yuhong Bao = From mkobetic@cincom.com Tue Jan 17 23:54:39 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5098621F86E8 for ; Tue, 17 Jan 2012 23:54:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.714 X-Spam-Level: X-Spam-Status: No, score=-3.714 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4wJPsLvVgqsN for ; Tue, 17 Jan 2012 23:54:38 -0800 (PST) Received: from em03.cincom.com (em03.cincom.com [198.8.67.13]) by ietfa.amsl.com (Postfix) with ESMTP id B8DFB21F86E1 for ; Tue, 17 Jan 2012 23:54:38 -0800 (PST) Received: from im02.cincom.com ([10.1.1.87]) by em03.cincom.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jan 2012 02:54:37 -0500 Received: from central.parcplace.com ([10.100.1.17]) by im02.cincom.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 18 Jan 2012 02:54:37 -0500 Received: from localhost (pickle2 [192.168.1.169]) by central.parcplace.com (8.12.8+Sun/8.12.8) with ESMTP id q0I7sYOr024779 for ; Tue, 17 Jan 2012 23:54:37 -0800 (PST) Message-Id: <201201180754.q0I7sYOr024779@central.parcplace.com> Date: Wed, 18 Jan 2012 02:54:34 -0500 From: mkobetic@cincom.com To: tls@ietf.org Mime-version: 1.0 Content-type: text/plain;charset=iso-8859-1 User-agent: Stampy(7.7 - 79,mkobetic)= / VisualWorks 7.8.1 Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 18 Jan 2012 07:54:37.0599 (UTC) FILETIME=[6CFA02F0:01CCD5B6] X-TM-AS-Product-Ver: SMEX-10.0.0.4211-6.800.1017-18652.004 X-TM-AS-Result: No--19.297200-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Subject: [TLS] Proper server response for certificate mismatch with supported_signature_algorithms? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 07:54:39 -0000 I'm wondering what is the proper behavior of a TLS1.2 server when none of it= s certificates satisfy the supported_signature_algorithms extension sent by = the client. The spec indicates that the extension should guide the selection= of the certificate, and even if there's only one to choose from, the server= "... SHOULD attempt to validate that it meets these criteria." But the spec= is silent about what should happen if that validation fails. I'm guessing t= he proper response is a fatal alert, but none seems to fit very well. Maybe = handshake_failure, given that if you squint hard enough, this could be inter= preted as a failure to "negotiate an acceptable set of security parameters" = ? Searching the archives I ran across this thread http://www.ietf.org/mail-arc= hive/web/tls/current/msg07608.html from last year, which concludes with the = observation that most implementations simply ignore this bit of the spec alt= ogether. Is it reasonable to take that as a generally accepted consensus to = follow at this point ? Thanks, Martin From ynir@checkpoint.com Wed Jan 18 08:48:33 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0CC11E80AD for ; Wed, 18 Jan 2012 08:48:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.481 X-Spam-Level: X-Spam-Status: No, score=-10.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P7eK77gdKWPZ for ; Wed, 18 Jan 2012 08:48:32 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2F35B21F859F for ; Wed, 18 Jan 2012 08:48:31 -0800 (PST) X-CheckPoint: {4F16F517-0-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id q0IGmRra032606; Wed, 18 Jan 2012 18:48:27 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Wed, 18 Jan 2012 18:48:27 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Wed, 18 Jan 2012 18:48:27 +0200 From: Yoav Nir To: "mkobetic@cincom.com" , "tls@ietf.org" Date: Wed, 18 Jan 2012 18:48:25 +0200 Thread-Topic: [TLS] Proper server response for certificate mismatch with supported_signature_algorithms? Thread-Index: AczWAP/wPXe0UjVVQaWZgim9IQarBA== Message-ID: In-Reply-To: <201201180754.q0I7sYOr024779@central.parcplace.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.14.0.111121 acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Subject: Re: [TLS] Proper server response for certificate mismatch with supported_signature_algorithms? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 16:48:33 -0000 Hi Martin. First, I think you have confused supported_signature_algorithms, which is sent by the server with signature_algorithms, which is sent in a ClientHello extension. Section 7.4.2 is very clear here: If the client provided a "signature_algorithms" extension, then all certificates provided by the server MUST be signed by a hash/signature algorithm pair that appears in that extension. But the requirement does seem to fade down to a SHOULD when there's only one certificate.=20 I guess most implementations would send the certificate, and let the client figure out the proper alert. Yoav On 1/18/12 9:54 AM, "mkobetic@cincom.com" wrote: >I'm wondering what is the proper behavior of a TLS1.2 server when none of >its certificates satisfy the supported_signature_algorithms extension >sent by the client. The spec indicates that the extension should guide >the selection of the certificate, and even if there's only one to choose >from, the server "... SHOULD attempt to validate that it meets these >criteria." But the spec is silent about what should happen if that >validation fails. I'm guessing the proper response is a fatal alert, but >none seems to fit very well. Maybe handshake_failure, given that if you >squint hard enough, this could be interpreted as a failure to "negotiate >an acceptable set of security parameters" ? > >Searching the archives I ran across this thread >http://www.ietf.org/mail-archive/web/tls/current/msg07608.html from last >year, which concludes with the observation that most implementations >simply ignore this bit of the spec altogether. Is it reasonable to take >that as a generally accepted consensus to follow at this point ? > >Thanks, > >Martin >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls > >Scanned by Check Point Total Security Gateway. From mrex@sap.com Wed Jan 18 12:48:59 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F139F11E80A0 for ; Wed, 18 Jan 2012 12:48:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.079 X-Spam-Level: X-Spam-Status: No, score=-10.079 tagged_above=-999 required=5 tests=[AWL=0.170, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGuOLt5DwdN3 for ; Wed, 18 Jan 2012 12:48:59 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 264FF11E809D for ; Wed, 18 Jan 2012 12:48:58 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0IKmtfQ021571 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 18 Jan 2012 21:48:55 +0100 (MET) From: Martin Rex Message-Id: <201201182048.q0IKmskx003677@fs4113.wdf.sap.corp> To: mkobetic@cincom.com Date: Wed, 18 Jan 2012 21:48:54 +0100 (MET) In-Reply-To: <201201180754.q0I7sYOr024779@central.parcplace.com> from "mkobetic@cincom.com" at Jan 18, 12 02:54:34 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Proper server response for certificate mismatch with X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2012 20:49:00 -0000 mkobetic@cincom.com wrote: > > I'm wondering what is the proper behavior of a TLS1.2 server when > none of its certificates satisfy the supported_signature_algorithms > extension sent by the client. The spec indicates that the extension > should guide the selection of the certificate, and even if there's > only one to choose from, the server "... SHOULD attempt to validate > that it meets these criteria." But the spec is silent about what > should happen if that validation fails. > > I'm guessing the proper response is a fatal alert, but none seems > to fit very well. Maybe handshake_failure, given that if you squint > hard enough, this could be interpreted as a failure to "negotiate > an acceptable set of security parameters" ? The definition of the signature algorithms extension in TLSv1.2 (rfc5280) is overly restrictive (read: defective) with respect to signature algorithms on _certificate_ chains. > > Searching the archives I ran across this thread > http://www.ietf.org/mail-archive/web/tls/current/msg07608.html > from last year, which concludes with the observation that most > implementations simply ignore this bit of the spec altogether. > Is it reasonable to take that as a generally accepted consensus > to follow at this point ? Using the information as a guidance/hint in selecting among alternative certificates is OK--but trying to enforce it remotely, as one MUST somewhere in rfc5280 suggest, would be unreasonable. The original purpose of the TLS handshake, and the protected negotiation, is to improve the chances for _completing_ the handshake successfully, with the most desirable common characteristics between the peers, not for the opposite (=handshake failures). If the client cares strongly about specific algorithms,(=client policy decision) then the decision to abort the handshake can not be offloaded to the peer/server anyway (because that peer can be buggy or an imposter/attacker)-- it is something that the client will have to enforce himself when performing certificate path validation on the server certificate. Reasonably implemented, the client will then be in a *much* better position to produce a clear and comprehensible error message, describe which certificate it rejects and why, compared to a receiving some unspecific fatal SSL Alert from the server--or worse, being faced with a sudden closure of the network connection mid-handshake. (Microsoft IIS seems to not send fatal SSL Alerts on the wire after handshake failures and prior to terminating the network connection). So yes, the proper response will be to ignore the contents of the signature_algorithm extensions in case that the server does not have alternatives to choose from of the hints contained in the signature_algorithm extension do not match any of the certificate that the server has. -Martin From hannes.tschofenig@gmx.net Thu Jan 19 07:07:24 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A88B21F8677 for ; Thu, 19 Jan 2012 07:07:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.009 X-Spam-Level: X-Spam-Status: No, score=-102.009 tagged_above=-999 required=5 tests=[AWL=-0.029, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Leo94wAwYnvU for ; Thu, 19 Jan 2012 07:07:23 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 1DE7821F8678 for ; Thu, 19 Jan 2012 07:07:22 -0800 (PST) Received: (qmail invoked by alias); 19 Jan 2012 15:07:21 -0000 Received: from unknown (EHLO [10.255.135.235]) [192.100.123.77] by mail.gmx.net (mp022) with SMTP; 19 Jan 2012 16:07:21 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18ca0ZiXGAcF30lyXGCSTRn4hHYZQo6hBM3FfJDo/ K5zBnygbiHj3Ur Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Apple Message framework v1084) From: Hannes Tschofenig Date: Thu, 19 Jan 2012 17:07:20 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: tls@ietf.org X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Subject: [TLS] Fwd: Smart Object Security Workshop Announcement X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2012 15:07:24 -0000 Hi all,=20 there are two working group items in the TLS working group that are also = relevant for smart object security deployments. Those of you who have some experience with TLS/DTLS implementations and = deployments on constrained devices please consider attending the = workshop. Ciao Hannes Begin forwarded message: > From: Hannes Tschofenig > Date: January 19, 2012 2:46:10 PM GMT+02:00 > To: smartobject-participants@lists.i1b.org > Cc: Hannes Tschofenig > Subject: Smart Object Security Workshop Announcement >=20 > Hi all, >=20 > you all have been attending the Smart Object workshop last March in = Prague. We have worked on a follow-up workshop focused on security. It = will take place on the 23rd March 2012 in Paris; it is again attached to = the IETF meeting. >=20 > We are seeking input from participants to share their thoughts about = the ability to utilize existing and widely deployed security mechanisms = for smart objects. >=20 > In particular, we are interested to hear about: > - What techniques for issuing credentials have been deployed? > - What extensions are useful to make existing security protocols more = suitable for smart objects? > - What type of credentials are frequently used? > - What experience has been gained when implementing and deploying = application layer, transport layer, network layer, and link layer = security mechanisms (or a mixture of all of them)? > - How can =93clever=94 implementations make security protocols a = better fit for constrained devices? > - Are there lessons we can learn from existing deployments? >=20 > More workshop details can be found on the webpage of our host: > http://www.lix.polytechnique.fr/hipercom/SmartObjectSecurity/ >=20 > If you plan to participate at the workshop please drop us a message = (with a short description of what you are planning to contribute) and we = can give you an early notice regarding your participation.=20 >=20 > It would be great to see you at the workshop and hear your thoughts.=20= >=20 > Ciao > Hannes >=20 From pgut001@login01.cs.auckland.ac.nz Fri Jan 20 04:17:24 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51D9C21F852E for ; Fri, 20 Jan 2012 04:17:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YrAuX2oRdIVV for ; Fri, 20 Jan 2012 04:17:22 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 713EE21F8512 for ; Fri, 20 Jan 2012 04:17:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1327061842; x=1358597842; h=from:to:subject:in-reply-to:message-id:date; bh=u7ui6oOBy3RLJC+n2KVgErOxjdyI4lwjNQTnqxSWor8=; b=gBHGj1Pker2N1t/jIE95jwZnFnyHA+Pgoc90cbf7ldFvY3kSoAIpIPZr 3Ync0DULMqpD+6URcAtJ5DOgpsIncZbOXkY4GTudOW+VtZCguyJ2k7I+T IrYbPF8YaFAfMXCAqwR/Df9JV3ArqHryWZn0LbwotScZsLvw3igHtgnE+ M=; X-IronPort-AV: E=Sophos;i="4.71,541,1320577200"; d="scan'208";a="99071924" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.34.40 - Outgoing - Outgoing Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 21 Jan 2012 01:17:20 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1RoDPD-00077o-Vb; Sat, 21 Jan 2012 01:17:19 +1300 From: Peter Gutmann To: mkobetic@cincom.com, tls@ietf.org In-Reply-To: <201201180754.q0I7sYOr024779@central.parcplace.com> Message-Id: Date: Sat, 21 Jan 2012 01:17:19 +1300 Subject: Re: [TLS] Proper server response for certificate mismatch with supported_signature_algorithms? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 12:17:24 -0000 writes: >Searching the archives I ran across this thread >http://www.ietf.org/mail-archive/web/tls/current/msg07608.html from last year, >which concludes with the observation that most implementations simply ignore >this bit of the spec altogether. Is it reasonable to take that as a generally >accepted consensus to follow at this point ? It seems so. It's not so much "most" as "all known implementations", and AFAIK the situation hasn't changed since last year. This has always been a nonsensical requirement whose sole effect is to hurt interoperability, so the best approach is to ignore it. Peter. From internet-drafts@ietf.org Fri Jan 20 15:06:03 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B94C421F86C1; Fri, 20 Jan 2012 15:06:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbXeKrGOB0uq; Fri, 20 Jan 2012 15:05:59 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3102A21F86B0; Fri, 20 Jan 2012 15:05:45 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120120230545.4217.11117.idtracker@ietfa.amsl.com> Date: Fri, 20 Jan 2012 15:05:45 -0800 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-oob-pubkey-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 23:06:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Layer Security Working Grou= p of the IETF. Title : TLS Out-of-Band Public Key Validation Author(s) : Paul Wouters John Gilmore Samuel Weiler Tero Kivinen Hannes Tschofenig Filename : draft-ietf-tls-oob-pubkey-01.txt Pages : 10 Date : 2012-01-20 This document specifies a new TLS certificate type for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) for use with out-of-band authentication. Currently, TLS authentication can only occur via PKIX or OpenPGP certificates. By specifying a minimum resource for raw public key exchange, implementations can use alternative authentication methods. One such method is using DANE Resource Records secured by DNSSEC, Another use case is to provide authentication functionality when used with devices in a constrained environment that use whitelists and blacklists, as is the case with sensors and other embedded devices that are constrained by memory, computational, and communication limitations where the usage of PKIX is not feasible. The new certificate type specified can also be used to reduce the latency of a TLS client that is already in possession of a validated public key of the TLS server before it starts a (non-resumed) TLS handshake. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-oob-pubkey-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-tls-oob-pubkey-01.txt From wwwrun@rfc-editor.org Fri Jan 20 15:51:59 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2818E21F85CD; Fri, 20 Jan 2012 15:51:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.13 X-Spam-Level: X-Spam-Status: No, score=-102.13 tagged_above=-999 required=5 tests=[AWL=-0.130, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WEiIODuUVlji; Fri, 20 Jan 2012 15:51:55 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 087D721F8578; Fri, 20 Jan 2012 15:51:54 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 8E963B1E002; Fri, 20 Jan 2012 15:48:41 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20120120234841.8E963B1E002@rfc-editor.org> Date: Fri, 20 Jan 2012 15:48:41 -0800 (PST) Cc: tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] RFC 6347 on Datagram Transport Layer Security Version 1.2 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 23:51:59 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6347 Title: Datagram Transport Layer Security Version 1.2 Author: E. Rescorla, N. Modadugu Status: Standards Track Stream: IETF Date: January 2012 Mailbox: ekr@rtfm.com, nagendra@cs.stanford.edu Pages: 32 Characters: 73546 Obsoletes: RFC4347 I-D Tag: draft-ietf-tls-rfc4347-bis-06.txt URL: http://www.rfc-editor.org/rfc/rfc6347.txt This document specifies version 1.2 of the Datagram Transport Layer Security (DTLS) protocol. The DTLS protocol provides communications privacy for datagram protocols. The protocol allows client/server applications to communicate in a way that is designed to prevent eavesdropping, tampering, or message forgery. The DTLS protocol is based on the Transport Layer Security (TLS) protocol and provides equivalent security guarantees. Datagram semantics of the underlying transport are preserved by the DTLS protocol. This document updates DTLS 1.0 to work with TLS version 1.2. [STANDARDS-TRACK] This document is a product of the Transport Layer Security Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From paul@nohats.ca Fri Jan 20 15:55:11 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D671921F86D6 for ; Fri, 20 Jan 2012 15:55:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.935 X-Spam-Level: X-Spam-Status: No, score=-0.935 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBUdlWUYPd1a for ; Fri, 20 Jan 2012 15:55:11 -0800 (PST) Received: from letoams.cypherpunks.ca (unknown [76.10.157.69]) by ietfa.amsl.com (Postfix) with ESMTP id 4E89B21F86C8 for ; Fri, 20 Jan 2012 15:55:11 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by letoams.cypherpunks.ca (Postfix) with ESMTP id C289183FF1 for ; Fri, 20 Jan 2012 18:54:36 -0500 (EST) Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.5/8.14.5/Submit) with ESMTP id q0KNsaME010056 for ; Fri, 20 Jan 2012 18:54:36 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Fri, 20 Jan 2012 18:54:36 -0500 (EST) From: Paul Wouters To: tls@ietf.org Message-ID: User-Agent: Alpine 2.02 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: [TLS] New Version Notification for draft-ietf-tls-oob-pubkey-01.txt (fwd) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 23:55:12 -0000 The only changes to the document is a typo (out of bound -> out of band) found by Bill Frantz and an updated reference to a newer draft-ietf-dane-protocol version. http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tls-oob-pubkey-01.txt I believe this document is ready for WGLC. Paul ---------- Forwarded message ---------- Date: Fri, 20 Jan 2012 18:06:02 From: internet-drafts@ietf.org Cc: hannes.tschofenig@gmx.net, weiler@tislabs.com, paul@nohats.ca, gnu@toad.com, kivinen@iki.fi To: paul@nohats.ca Subject: New Version Notification for draft-ietf-tls-oob-pubkey-01.txt A new version of I-D, draft-ietf-tls-oob-pubkey-01.txt has been successfully submitted by Paul Wouters and posted to the IETF repository. Filename: draft-ietf-tls-oob-pubkey Revision: 01 Title: TLS Out-of-Band Public Key Validation Creation date: 2012-01-20 WG ID: tls Number of pages: 10 Abstract: This document specifies a new TLS certificate type for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) for use with out-of-band authentication. Currently, TLS authentication can only occur via PKIX or OpenPGP certificates. By specifying a minimum resource for raw public key exchange, implementations can use alternative authentication methods. One such method is using DANE Resource Records secured by DNSSEC, Another use case is to provide authentication functionality when used with devices in a constrained environment that use whitelists and blacklists, as is the case with sensors and other embedded devices that are constrained by memory, computational, and communication limitations where the usage of PKIX is not feasible. The new certificate type specified can also be used to reduce the latency of a TLS client that is already in possession of a validated public key of the TLS server before it starts a (non-resumed) TLS handshake. The IETF Secretariat From mrex@sap.com Fri Jan 20 17:23:26 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2AD421F86D8 for ; Fri, 20 Jan 2012 17:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.093 X-Spam-Level: X-Spam-Status: No, score=-10.093 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2y5rVfCmFUNh for ; Fri, 20 Jan 2012 17:23:26 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0159121F86C5 for ; Fri, 20 Jan 2012 17:23:25 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0L1NOWm006429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 21 Jan 2012 02:23:24 +0100 (MET) From: Martin Rex Message-Id: <201201210123.q0L1NOwX000859@fs4113.wdf.sap.corp> To: paul@nohats.ca (Paul Wouters) Date: Sat, 21 Jan 2012 02:23:23 +0100 (MET) In-Reply-To: from "Paul Wouters" at Jan 20, 12 06:54:36 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] New Version Notification for draft-ietf-tls-oob-pubkey-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2012 01:23:27 -0000 Paul Wouters wrote: > > A new version of I-D, draft-ietf-tls-oob-pubkey-01.txt has been successfully > submitted by Paul Wouters and posted to the IETF repository. > > Filename: draft-ietf-tls-oob-pubkey > Revision: 01 > Title: TLS Out-of-Band Public Key Validation > Creation date: 2012-01-20 > WG ID: tls > Number of pages: 10 > > > The new certificate type specified can also be used to reduce the > latency of a TLS client that is already in possession of a validated > public key of the TLS server before it starts a (non-resumed) TLS > handshake. (1) I'm confused about this paragraph with respect to later parts of the document. Maybe I've read the document too quickly, but I didn't find an explanation how exactly this new certificate type could be used to "reduce the latency of a TLS client that is already in posession of a validated public key". Since the new certificate type "RawPublicKey" is in reality a PKIX SubjectPublicKeyInfo, every server in posession of an X.509 cert could simply agree to this extension when proposed by the client, extract the SubjectPublicKeyInfo from this X.509 server certificate and send it as RawPublicKey in the ServerCertificate handshake message. This would reduce the amount of data in the Server's Certificate and optional CertificateRequest Handshake message. (and when the server requested it, it would reduce the size of the Client's Certificate handshake message as well, provided the client had a credential). Is is that reduction in size of the handshake message that was meant? (2) Personally, I believe it would be quite reasonable, for servers implementing this in addition to regular X.509 support, to also use X.509 certs as containers for the raw public keys so that no changes whatsoever are required for the adminstrative parts (creation and management of server TLS credentials). Is the intention to actively suggest to (server) implementations of this document to generally extract and use of the SubjectPublicKeyInfo as RawPublicKey for whatever X.509 certificate the server might have, then this requirement, that was copied from rfc6091, would become superfluous: This extension MUST be omitted if the client only supports X.509 certificates. btw. I believe that MUST (from rfc6091) is in conflict with rfc2119 section 6. Likewise, is the intention to actively suggest to (client) implementations of this document to extract SubjectPublicKeyInfo from X.509 Server Certificates that they received on a full handshake with that server and where available to validate (PKIX/DANE/whathaveyou) and attempt to use it in a sucessor TLS handshake with that server as a RawPublicKey with the TLS extension defined in this document? (3) I'm wondering about any kind of "server has more than one credential scenario", which comes in two different flavours (and mixtures thereof): (a) virtual hosting, several distinct server certificates and their selection guided by TLS extension SNI (b) ciphersuites that require distinct keypairs (RSA,DSA,ECDSA) I believe with respect to (a) the interaction of the extension defined in this document with TLS extension SNI should be specified. This would be essential if the intention of (2) applies that clients&servers are expected to extract SubjectPublicKey Infos from X.509 certificates that they would use as X.509 certs in regular TLS handshakes without this extension. With respect to (b), I believe that it should be spelled out that clients(!) may have to restrict the list of TLS cipher suites that they propose in ClientHello, when using the TLS extension defined in this document, to those algorithms for which they actually have server RawPublicKeys available. -Martin From mkobetic@cincom.com Mon Jan 23 15:47:12 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5637121F8568 for ; Mon, 23 Jan 2012 15:47:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.714 X-Spam-Level: X-Spam-Status: No, score=-3.714 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aR89FJxL+WhZ for ; Mon, 23 Jan 2012 15:47:11 -0800 (PST) Received: from em03.cincom.com (em03.cincom.com [198.8.67.13]) by ietfa.amsl.com (Postfix) with ESMTP id C85A121F855D for ; Mon, 23 Jan 2012 15:47:11 -0800 (PST) Received: from im02.cincom.com ([10.1.1.87]) by em03.cincom.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jan 2012 18:47:11 -0500 Received: from central.parcplace.com ([10.100.1.17]) by im02.cincom.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jan 2012 18:47:11 -0500 Received: from localhost (pickle2 [192.168.1.169]) by central.parcplace.com (8.12.8+Sun/8.12.8) with ESMTP id q0NNlAOr018479; Mon, 23 Jan 2012 15:47:10 -0800 (PST) Message-Id: <201201232347.q0NNlAOr018479@central.parcplace.com> Date: Mon, 23 Jan 2012 18:47:10 -0500 From: mkobetic@cincom.com To: "Peter Gutmann" Mime-version: 1.0 Content-type: text/plain;charset=iso-8859-1 User-agent: Stampy* / VisualWorks 7.8.1 Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 23 Jan 2012 23:47:11.0123 (UTC) FILETIME=[53326E30:01CCDA29] X-TM-AS-Product-Ver: SMEX-10.0.0.4211-6.800.1017-18664.001 X-TM-AS-Result: No--24.141800-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No Cc: tls@ietf.org Subject: Re: [TLS] Proper server response for certificate mismatch with supported_signature_algorithms? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 23:47:12 -0000 "Peter Gutmann" wrote: > >Searching the archives I ran across this thread > >http://www.ietf.org/mail-archive/web/tls/current/msg07608.html from last = year, > >which concludes with the observation that most implementations simply ign= ore > >this bit of the spec altogether. Is it reasonable to take that as a gener= ally > >accepted consensus to follow at this point ? > > It seems so. It's not so much "most" as "all known implementations", and > AFAIK the situation hasn't changed since last year. This has always been = a > nonsensical requirement whose sole effect is to hurt interoperability, so = the > best approach is to ignore it. Thank you all for the answers, but this makes me wonder about the similar re= quirement from TLS 1.0 and 1.1 where it mandates that the server key algorit= hm must be the same as the algorithm used to sign the certificate. That seem= s to have the same sort of issues, right? Does that mean it's also generally= ignored ? Thanks, Martin From mrex@sap.com Mon Jan 23 16:39:31 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E040D21F8605 for ; Mon, 23 Jan 2012 16:39:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.099 X-Spam-Level: X-Spam-Status: No, score=-10.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XxRl+BqYPAgj for ; Mon, 23 Jan 2012 16:39:31 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 31F6A21F8604 for ; Mon, 23 Jan 2012 16:39:30 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0O0dLah015640 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Jan 2012 01:39:21 +0100 (MET) From: Martin Rex Message-Id: <201201240039.q0O0dLW9009268@fs4113.wdf.sap.corp> To: mkobetic@cincom.com Date: Tue, 24 Jan 2012 01:39:21 +0100 (MET) In-Reply-To: <201201232347.q0NNlAOr018479@central.parcplace.com> from "mkobetic@cincom.com" at Jan 23, 12 06:47:10 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Proper server response for certificate mismatch with X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 00:39:32 -0000 mkobetic@cincom.com wrote: > > Thank you all for the answers, but this makes me wonder about the > similar requirement from TLS 1.0 and 1.1 where it mandates that the > server key algorithm must be the same as the algorithm used to sign > the certificate. That seems to have the same sort of issues, right? > Does that mean it's also generally ignored ? I suppose you're now refering to statenent (2>) in the paragraph at bottom of pg.49: http://tools.ietf.org/html/rfc5246#page-49 1> If the client provided a "signature_algorithms" extension, then all 1> certificates provided by the server MUST be signed by a 1> hash/signature algorithm pair that appears in that extension. Note that this implies that a certificate containing a key for one signature algorithm MAY be signed using a different signature 2> algorithm (for instance, an RSA key signed with a DSA key). This is 2> a departure from TLS 1.1, which required that the algorithms be the 2> same. The previous discussion (1>) was about the bogosity of the signature algorithms extension restricting signatures of certificates (and applies to TLSv1.2 only) The statement (2>) makes an bogus++ claim about prior TLS protocol versions, because such a restriction NEVER existed in any previous protocol specs (SSLv3,TLSv1.0,TLSv1.1), and none of the implementations that I've checked contain any such restriction (they all worked fine with an RSA server cert signed by a DSA root key). -Martin From ekr@rtfm.com Mon Jan 23 16:50:57 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C03F921F853B for ; Mon, 23 Jan 2012 16:50:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.853 X-Spam-Level: X-Spam-Status: No, score=-102.853 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCj1cmXDXwP6 for ; Mon, 23 Jan 2012 16:50:57 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2590021F8518 for ; Mon, 23 Jan 2012 16:50:57 -0800 (PST) Received: by vcbfk14 with SMTP id fk14so2577070vcb.31 for ; Mon, 23 Jan 2012 16:50:56 -0800 (PST) Received: by 10.220.155.142 with SMTP id s14mr6400480vcw.20.1327366255568; Mon, 23 Jan 2012 16:50:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.93.163 with HTTP; Mon, 23 Jan 2012 16:50:14 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: <201201240039.q0O0dLW9009268@fs4113.wdf.sap.corp> References: <201201232347.q0NNlAOr018479@central.parcplace.com> <201201240039.q0O0dLW9009268@fs4113.wdf.sap.corp> From: Eric Rescorla Date: Mon, 23 Jan 2012 16:50:14 -0800 Message-ID: To: mrex@sap.com X-Gm-Message-State: ALoCoQlX/rKQjp1iKhLMOa7zmfP6lmQumYX5Fn0L20HnKAFO4wouPTg4wMZAFl6bVay0cUj5o2zz Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Proper server response for certificate mismatch with X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 00:50:57 -0000 On Mon, Jan 23, 2012 at 4:39 PM, Martin Rex wrote: > mkobetic@cincom.com wrote: >> >> Thank you all for the answers, but this makes me wonder about the >> similar requirement from TLS 1.0 and 1.1 where it mandates that the >> server key algorithm must be the same as the algorithm used to sign >> the certificate. That seems to have the same sort of issues, right? >> Does that mean it's also generally ignored ? > > I suppose you're now refering to statenent (2>) in the paragraph at > bottom of pg.49: > > =A0 http://tools.ietf.org/html/rfc5246#page-49 > > 1> =A0If the client provided a "signature_algorithms" extension, then all > 1> =A0certificates provided by the server MUST be signed by a > 1> =A0hash/signature algorithm pair that appears in that extension. =A0No= te > =A0 =A0that this implies that a certificate containing a key for one > =A0 =A0signature algorithm MAY be signed using a different signature > 2> =A0algorithm (for instance, an RSA key signed with a DSA key). =A0This= is > 2> =A0a departure from TLS 1.1, which required that the algorithms be the > 2> =A0same. > > The previous discussion (1>) was about the bogosity of the signature > algorithms extension restricting signatures of certificates (and applies > to TLSv1.2 only) > > The statement (2>) makes an bogus++ claim about prior TLS protocol versio= ns, > because such a restriction NEVER existed in any previous protocol specs > (SSLv3,TLSv1.0,TLSv1.1), http://tools.ietf.org/html/rfc4346#section-7.4.2 The certificate type MUST be appropriate for the selected cipher suite's key exchange algorithm, and is generally an X.509v3 certificate. It MUST contain a key that matches the key exchange method, as follows. Unless otherwise specified, the signing algorithm for the certificate MUST be the same as the algorithm for the certificate key. Unless otherwise specified, the public key MAY be of any length. Substantively the same text appears in RFC 2246. -Ekr From mrex@sap.com Mon Jan 23 17:16:14 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46CEF21F8615 for ; Mon, 23 Jan 2012 17:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.103 X-Spam-Level: X-Spam-Status: No, score=-10.103 tagged_above=-999 required=5 tests=[AWL=0.146, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IbrJIKaNGn1F for ; Mon, 23 Jan 2012 17:16:13 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 75C1E21F85FD for ; Mon, 23 Jan 2012 17:16:08 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0O1G5o5018745 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 24 Jan 2012 02:16:05 +0100 (MET) From: Martin Rex Message-Id: <201201240116.q0O1G4oU011614@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Tue, 24 Jan 2012 02:16:04 +0100 (MET) In-Reply-To: from "Eric Rescorla" at Jan 23, 12 04:50:14 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Proper server response for certificate mismatch with X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 01:16:14 -0000 Eric Rescorla wrote: > > On Mon, Jan 23, 2012 at 4:39 PM, Martin Rex wrote: > > mkobetic@cincom.com wrote: > >> > >> Thank you all for the answers, but this makes me wonder about the > >> similar requirement from TLS 1.0 and 1.1 where it mandates that the > >> server key algorithm must be the same as the algorithm used to sign > >> the certificate. That seems to have the same sort of issues, right? > >> Does that mean it's also generally ignored ? > > > > I suppose you're now refering to statenent (2>) in the paragraph at > > bottom of pg.49: > > > >   http://tools.ietf.org/html/rfc5246#page-49 > > > > 1>  If the client provided a "signature_algorithms" extension, then all > > 1>  certificates provided by the server MUST be signed by a > > 1>  hash/signature algorithm pair that appears in that extension.  Note > >    that this implies that a certificate containing a key for one > >    signature algorithm MAY be signed using a different signature > > 2>  algorithm (for instance, an RSA key signed with a DSA key).  This is > > 2>  a departure from TLS 1.1, which required that the algorithms be the > > 2>  same. > > > > The previous discussion (1>) was about the bogosity of the signature > > algorithms extension restricting signatures of certificates (and applies > > to TLSv1.2 only) > > > > The statement (2>) makes an bogus++ claim about prior TLS protocol versions, > > because such a restriction NEVER existed in any previous protocol specs > > (SSLv3,TLSv1.0,TLSv1.1), > > > http://tools.ietf.org/html/rfc4346#section-7.4.2 > > The certificate type MUST be appropriate for the selected cipher > suite's key exchange algorithm, and is generally an X.509v3 > certificate. It MUST contain a key that matches the key exchange > method, as follows. Unless otherwise specified, the signing > algorithm for the certificate MUST be the same as the algorithm > for the certificate key. Unless otherwise specified, the public > key MAY be of any length. > > Substantively the same text appears in RFC 2246. Well, OK. I'm sorry. Thanks for the pointer to this text, which is actually fenced off into insignificance with the line "Meaning of this message:" (not quoted above). But this text seems to be an invalid backwards-incompatible change to SSLv3: http://tools.ietf.org/html/rfc6101#section-5.6.2 So expecting any implementor to notice or even honour such a backwards-incompatible MUST would per rfc-2119 section 6 require a convincing rationale, otherwise it is in clear conflict with rfc2119 and essentially null and void. The wording (algorithm for the certificate ...) at least for me (non-native english) appears to refer to a certificate _selection_ mechanism for the server -- which an implementor of a server that supports only a single cert (per handle) is likely to completely ignore (a selection mechanims is not applicable to a no-selection situation). -Martin From ekr@rtfm.com Mon Jan 23 17:23:23 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12F4421F8618 for ; Mon, 23 Jan 2012 17:23:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.86 X-Spam-Level: X-Spam-Status: No, score=-102.86 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7IDjyhZLT4Ej for ; Mon, 23 Jan 2012 17:23:22 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5D73021F8615 for ; Mon, 23 Jan 2012 17:23:22 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so2568296vbb.31 for ; Mon, 23 Jan 2012 17:23:21 -0800 (PST) Received: by 10.52.71.33 with SMTP id r1mr4959519vdu.113.1327368201845; Mon, 23 Jan 2012 17:23:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.93.163 with HTTP; Mon, 23 Jan 2012 17:22:40 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: <201201240116.q0O1G4oU011614@fs4113.wdf.sap.corp> References: <201201240116.q0O1G4oU011614@fs4113.wdf.sap.corp> From: Eric Rescorla Date: Mon, 23 Jan 2012 17:22:40 -0800 Message-ID: To: mrex@sap.com X-Gm-Message-State: ALoCoQkzZK3ck7qZ5wGoBxPGlAeLE6xS050VxaxXx+G/qk4QLTBGruVr3ZocJGQCUs7VhLF42KOJ Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Proper server response for certificate mismatch with X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 01:23:23 -0000 On Mon, Jan 23, 2012 at 5:16 PM, Martin Rex wrote: > Eric Rescorla wrote: >> >> On Mon, Jan 23, 2012 at 4:39 PM, Martin Rex wrote: >> > mkobetic@cincom.com wrote: >> >> >> >> Thank you all for the answers, but this makes me wonder about the >> >> similar requirement from TLS 1.0 and 1.1 where it mandates that the >> >> server key algorithm must be the same as the algorithm used to sign >> >> the certificate. That seems to have the same sort of issues, right? >> >> Does that mean it's also generally ignored ? >> > >> > I suppose you're now refering to statenent (2>) in the paragraph at >> > bottom of pg.49: >> > >> > =A0 http://tools.ietf.org/html/rfc5246#page-49 >> > >> > 1> =A0If the client provided a "signature_algorithms" extension, then = all >> > 1> =A0certificates provided by the server MUST be signed by a >> > 1> =A0hash/signature algorithm pair that appears in that extension. = =A0Note >> > =A0 =A0that this implies that a certificate containing a key for one >> > =A0 =A0signature algorithm MAY be signed using a different signature >> > 2> =A0algorithm (for instance, an RSA key signed with a DSA key). =A0T= his is >> > 2> =A0a departure from TLS 1.1, which required that the algorithms be = the >> > 2> =A0same. >> > >> > The previous discussion (1>) was about the bogosity of the signature >> > algorithms extension restricting signatures of certificates (and appli= es >> > to TLSv1.2 only) >> > >> > The statement (2>) makes an bogus++ claim about prior TLS protocol ver= sions, >> > because such a restriction NEVER existed in any previous protocol spec= s >> > (SSLv3,TLSv1.0,TLSv1.1), >> >> >> http://tools.ietf.org/html/rfc4346#section-7.4.2 >> >> =A0 =A0 =A0 The certificate type MUST be appropriate for the selected ci= pher >> =A0 =A0 =A0 suite's key exchange algorithm, and is generally an X.509v3 >> =A0 =A0 =A0 certificate. =A0It MUST contain a key that matches the key e= xchange >> =A0 =A0 =A0 method, as follows. =A0Unless otherwise specified, the signi= ng >> =A0 =A0 =A0 algorithm for the certificate MUST be the same as the algori= thm >> =A0 =A0 =A0 for the certificate key. =A0Unless otherwise specified, the = public >> =A0 =A0 =A0 key MAY be of any length. >> >> Substantively the same text appears in RFC 2246. > > Well, OK. =A0I'm sorry. > > Thanks for the pointer to this text, which is actually fenced off into > insignificance with the line "Meaning of this message:" (not quoted above= ). Seeing as SSLv3 had no formal IETF standing, and was just an input document to TLS 1.0, I'm not sure I agree with your arguments below. However, since I wasn't the author of this text or the "Meaning of this message:", and since it has been changed in RFC 5246 I don't really see a lot of value in debating it. -Ekr > But this text seems to be an invalid backwards-incompatible > change to SSLv3: > =A0http://tools.ietf.org/html/rfc6101#section-5.6.2 > > So expecting any implementor to notice or even honour such > a backwards-incompatible MUST would per rfc-2119 section 6 > require a convincing rationale, otherwise it is in clear > conflict with rfc2119 and essentially null and void. > > > The wording (algorithm for the certificate ...) at least for me > (non-native english) appears to refer to a certificate _selection_ > mechanism for the server -- which an implementor of a server that > supports only a single cert (per handle) is likely to completely > ignore (a selection mechanims is not applicable to a no-selection > situation). > > > -Martin From ietf@augustcellars.com Mon Jan 23 22:30:28 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A45F21F855A for ; Mon, 23 Jan 2012 22:30:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.332 X-Spam-Level: X-Spam-Status: No, score=-3.332 tagged_above=-999 required=5 tests=[AWL=0.267, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbPKFQYSKI75 for ; Mon, 23 Jan 2012 22:30:27 -0800 (PST) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) by ietfa.amsl.com (Postfix) with ESMTP id 53C2C21F8507 for ; Mon, 23 Jan 2012 22:30:27 -0800 (PST) Received: from Tobias (exodus.augustcellars.com [207.202.179.27]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: schaad@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 21CBC38F1B; Mon, 23 Jan 2012 22:30:22 -0800 (PST) From: "Jim Schaad" To: "'Paul Wouters'" , References: In-Reply-To: Date: Mon, 23 Jan 2012 22:29:40 -0800 Message-ID: <030701ccda61$90aea7f0$b20bf7d0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQKAP4icwNQ8ML7kpJEhx7swZ8Yd6pS0D2WA Content-Language: en-us Subject: Re: [TLS] New Version Notification for draft-ietf-tls-oob-pubkey-01.txt (fwd) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 06:30:28 -0000 I am going to have to disagree with the statement that the document is ready for WGLC. I have refrained from reading this document before because I am not truly convinced that this is a good idea. 1. I have a hard time with the second paragraph in the abstract - firstly the concept of a black list seems to be problematic as a method of deciding that an oob key is or is not good. A white list could essentially be a list of names and keys and thus work. However there are going to be issues of trust in terms of how the white list is updated that are exactly the same for getting PKIX to work. 2. In section 1.1 you state "...a TLS server must always send a list of trusted CA keys and..." this does not make sense to me. There is no list of trusted CA keys, there is an EE certificate and then the list of CA certificates that certify the EE certificate (and each other). There is no statement that these are trusted CA keys. 5246 explicitly says that the trust anchor (i.e. the TRUSTED CA key) does not need to be sent in the chain of certificates. Even more troubling is that I cannot find anything that defines an extension which says - I know who you are don't send me any certificates (or perhaps only the EE certificate). However I do note that you state that RFC 6066 does have the flag to say don't send me the chain - this appears to greatly lessen the argument that you have a large problem in terms of not sending the EE certificate. Why do you not just have an extension to say - don't send me the EE certificate I already think I know who you are. That would solve you issue without any need for the new certificate extension type. I don't believe that this provides a good motivation for the document. The small embedded device is a better motivation that is presented here. 3. For section 1.2 - see previous item. Again I think the small embedded device is a much better statement of applicability. You should be looking at cases for raw public keys not for PKIX. 4. I have absolutely no idea how to create a certificate which contains only the subject public key info structure. Many of these fields are not optional and therefore cannot be omitted. Also you have said that the entire problem is that you cannot deal with the PKIX structure, and how you are suddenly doubling the amount of code that I need to deal with PKIX since I now have both a certificate with fields and a certificate w/o fields. Why do you not say that your data structure for a "raw key certificate" is just going to be the SubjectPublicKeyInfo DER encoded structure? This would be much simpler and clearer as well as reducing the amount of ASN.1 processing substantially. 5. You are missing text that needs to be in place about the use of client authentication from a raw key. I don't know if this is what you really want to do or not. It is going to be much harder for a server to do the oob authentication without registration of some type. Additionally this would mean that your justification of wanting to suppress the sending of the server certificate would need to be documented as not working at all if you want to do client authentication. Since one case where you might want to do the suppression would be a re-authentication process for protected client auth, this does not make any since (in this case you already have the servers certificates from the previous handshake). Does this mean that you want to have the ability to have an asymmetric method of specifying the "certificate type" so that one can do bare key from server to client, but pkix certificate from client to server? This is not an issue for the case of PGP since one can assume that both the server and the client are going to use PGP certificates for the purpose of authentication. 6. Security considerations - para #2 - It is easy to establish the authenticity of the public key - just see if the cryptography works. What you want to be able to authenticate is the binding between the public key and the entity or service you are attempting to contact. 7. Security considerations - does not talk about client/public key binding authentication by the server at all - this is a short coming > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Paul > Wouters > Sent: Friday, January 20, 2012 3:55 PM > To: tls@ietf.org > Subject: [TLS] New Version Notification for draft-ietf-tls-oob-pubkey-01.txt > (fwd) > > > The only changes to the document is a typo (out of bound -> out of band) > found by Bill Frantz and an updated reference to a newer draft-ietf-dane- > protocol version. > > http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-tls-oob- > pubkey-01.txt > > I believe this document is ready for WGLC. > > Paul > > ---------- Forwarded message ---------- > Date: Fri, 20 Jan 2012 18:06:02 > From: internet-drafts@ietf.org > Cc: hannes.tschofenig@gmx.net, weiler@tislabs.com, paul@nohats.ca, > gnu@toad.com, > kivinen@iki.fi > To: paul@nohats.ca > Subject: New Version Notification for draft-ietf-tls-oob-pubkey-01.txt > > A new version of I-D, draft-ietf-tls-oob-pubkey-01.txt has been successfully > submitted by Paul Wouters and posted to the IETF repository. > > Filename: draft-ietf-tls-oob-pubkey > Revision: 01 > Title: TLS Out-of-Band Public Key Validation > Creation date: 2012-01-20 > WG ID: tls > Number of pages: 10 > > Abstract: > This document specifies a new TLS certificate type for exchanging raw > public keys in Transport Layer Security (TLS) and Datagram Transport > Layer Security (DTLS) for use with out-of-band authentication. > Currently, TLS authentication can only occur via PKIX or OpenPGP > certificates. By specifying a minimum resource for raw public key > exchange, implementations can use alternative authentication methods. > > One such method is using DANE Resource Records secured by DNSSEC, > Another use case is to provide authentication functionality when used > with devices in a constrained environment that use whitelists and > blacklists, as is the case with sensors and other embedded devices > that are constrained by memory, computational, and communication > limitations where the usage of PKIX is not feasible. > > The new certificate type specified can also be used to reduce the > latency of a TLS client that is already in possession of a validated > public key of the TLS server before it starts a (non-resumed) TLS > handshake. > > > > > The IETF Secretariat > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From mrex@sap.com Tue Jan 24 20:36:49 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D54A11E80AE for ; Tue, 24 Jan 2012 20:36:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.147 X-Spam-Level: X-Spam-Status: No, score=-10.147 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xdlmtnhxFUGe for ; Tue, 24 Jan 2012 20:36:48 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id A343F11E80A5 for ; Tue, 24 Jan 2012 20:36:48 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0P4aesH020733 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Jan 2012 05:36:40 +0100 (MET) From: Martin Rex Message-Id: <201201250436.q0P4aduN014001@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Wed, 25 Jan 2012 05:36:39 +0100 (MET) In-Reply-To: from "Eric Rescorla" at Jan 23, 12 05:22:40 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Proper server response for certificate mismatch with X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 04:36:49 -0000 Eric, Eric Rescorla wrote: > > > >> > 2>  algorithm (for instance, an RSA key signed with a DSA key).  This is > >> > 2>  a departure from TLS 1.1, which required that the algorithms be the > >> > 2>  same. > >> > > >> > >> http://tools.ietf.org/html/rfc4346#section-7.4.2 > >> > >>        Unless otherwise specified, the signing > >>       algorithm for the certificate MUST be the same as the algorithm > >>       for the certificate key. > >> > >> Substantively the same text appears in RFC 2246. > > > > Well, OK.  I'm sorry. > > > > Thanks for the pointer to this text, which is actually fenced off into > > insignificance with the line "Meaning of this message:" (not quoted above). > > Seeing as SSLv3 had no formal IETF standing, and was just an input > document to TLS 1.0, I'm not sure I agree with your arguments below. > However, since I wasn't the author of this text or the "Meaning of this > message:", and since it has been changed in RFC 5246 I don't really > see a lot of value in debating it. Curiously, rfc2246 does not reference rfc2119... anyhow I'm using the rfc2119 section-6 guidance when reading specification -- and in particular for specifications that are at maturity level "Proposed", because Proposed documents *MUST* be assumed to contain defects, and in particular detrimental imperatives. http://tools.ietf.org/html/rfc2119#section-6 6. Guidance in the use of these Imperatives Imperatives of the type defined in this memo must be used with care and sparingly. In particular, they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmisssions) For example, they must not be used to try to impose a particular method on implementors where the method is not required for interoperability. That newly added MUST that was added to TLS-1.0 7.4.2 in a rash and without rational amounts to "MUST abort" the TLS handshake, if followed, i.e. total non-interoperability. Total non-interoperability the extreme opposite of the purpose of imperatives per 2246 section 6, and the only permissible exemption would be "potential for causing harm". So without describing the harm that continuing the handshake would cause in comparison to fatally aborting the handshake, this MUST is null and void. What could have been among the original motiviation (and here it would have helped extremely if any rationale would have been provided!!), could have been that it is difficult to infer the cryptographic algorithms that a client might support for certificate path validation of the server certificate chain from the information that the client has provided through ClientHello. Recommending conservative assumptions about the clients capabilities would be OK -- but only for the situation where the server actually has several different server certificates to choose from. But even when the server can choose among several different server certificates with different crypto algorithms, even the worst of his choices has a non-marginal potential for resulting in interoperability, while aborting the handshake per that MUST has exactly ZERO potential for interoperability. No matter which way I look at it, that requirement is thoroughly non-sensical on my scorecard, and is probably the most extreme example, that I know, of a misplaced imperative with respect to rfc2119 section 6. -Martin From ekr@rtfm.com Wed Jan 25 08:17:34 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E161A21F8621 for ; Wed, 25 Jan 2012 08:17:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.886 X-Spam-Level: X-Spam-Status: No, score=-102.886 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h3YmTz4SIkqv for ; Wed, 25 Jan 2012 08:17:34 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 2C36621F8620 for ; Wed, 25 Jan 2012 08:17:34 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so4034520vbb.31 for ; Wed, 25 Jan 2012 08:17:33 -0800 (PST) Received: by 10.52.20.78 with SMTP id l14mr10284211vde.62.1327508252216; Wed, 25 Jan 2012 08:17:32 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.93.163 with HTTP; Wed, 25 Jan 2012 08:16:51 -0800 (PST) X-Originating-IP: [74.95.2.169] In-Reply-To: <201201250436.q0P4aduN014001@fs4113.wdf.sap.corp> References: <201201250436.q0P4aduN014001@fs4113.wdf.sap.corp> From: Eric Rescorla Date: Wed, 25 Jan 2012 08:16:51 -0800 Message-ID: To: mrex@sap.com X-Gm-Message-State: ALoCoQnPMH4u8hpepl8DWv9UfBuwo7ItSOObv+WO5NjkQ90ZnyDPxfKWpAn5/63TMLPuEtZd+5va Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Proper server response for certificate mismatch with X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 16:17:35 -0000 On Tue, Jan 24, 2012 at 8:36 PM, Martin Rex wrote: > Eric, > > Eric Rescorla wrote: >> > >> >> > 2> =A0algorithm (for instance, an RSA key signed with a DSA key). = =A0This is >> >> > 2> =A0a departure from TLS 1.1, which required that the algorithms = be the >> >> > 2> =A0same. >> >> > >> >> >> >> http://tools.ietf.org/html/rfc4346#section-7.4.2 >> >> >> >> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Unless otherwi= se specified, the signing >> >> =A0 =A0 =A0 algorithm for the certificate MUST be the same as the alg= orithm >> >> =A0 =A0 =A0 for the certificate key. >> >> >> >> Substantively the same text appears in RFC 2246. >> > >> > Well, OK. =A0I'm sorry. >> > >> > Thanks for the pointer to this text, which is actually fenced off into >> > insignificance with the line "Meaning of this message:" (not quoted ab= ove). >> >> Seeing as SSLv3 had no formal IETF standing, and was just an input >> document to TLS 1.0, =A0I'm not sure I agree with your arguments below. >> However, since I wasn't the author of this text or the "Meaning of this >> message:", and since it has been changed in RFC 5246 I don't really >> see a lot of value in debating it. > > Curiously, rfc2246 does not reference rfc2119... There's nothing curious about it. 2246 and 2119 were written more or less concurrently and 2246 spent a long time in IESG processing and the RFC Ed queue. Honestly, Martin, I have no idea why you're arguing this point: (1) This text isn't in the current spec. (2) Neither I or anyone on this thread wrote it. What's your point? -Ekr > anyhow I'm using > the rfc2119 section-6 guidance when reading specification -- > and in particular for specifications that are at maturity level "Proposed= ", > because Proposed documents *MUST* be assumed to contain defects, > and in particular detrimental imperatives. > > > http://tools.ietf.org/html/rfc2119#section-6 > > =A0 6. Guidance in the use of these Imperatives > > =A0 Imperatives of the type defined in this memo must be used with care > =A0 and sparingly. =A0In particular, they MUST only be used where it is > =A0 actually required for interoperation or to limit behavior which has > =A0 potential for causing harm (e.g., limiting retransmisssions) =A0For > =A0 example, they must not be used to try to impose a particular method > =A0 on implementors where the method is not required for > =A0 interoperability. > > > That newly added MUST that was added to TLS-1.0 7.4.2 in a rash > and without rational amounts to "MUST abort" the TLS handshake, > if followed, i.e. total non-interoperability. > > Total non-interoperability the extreme opposite of the purpose of > imperatives per 2246 section 6, and the only permissible exemption > would be "potential for causing harm". =A0So without describing the > harm that continuing the handshake would cause in comparison to > fatally aborting the handshake, this MUST is null and void. > > > What could have been among the original motiviation (and here it > would have helped extremely if any rationale would have been > provided!!), could have been that it is difficult to infer > the cryptographic algorithms that a client might support for > certificate path validation of the server certificate chain > from the information that the client has provided through > ClientHello. > > Recommending conservative assumptions about the clients capabilities > would be OK -- but only for the situation where the server actually > has several different server certificates to choose from. > > But even when the server can choose among several different > server certificates with different crypto algorithms, > even the worst of his choices has a non-marginal potential > for resulting in interoperability, while aborting the > handshake per that MUST has exactly ZERO potential for > interoperability. > > > No matter which way I look at it, that requirement is thoroughly > non-sensical on my scorecard, and is probably the most extreme example, > that I know, of a misplaced imperative with respect to rfc2119 section 6. > > > > -Martin From mrex@sap.com Wed Jan 25 14:09:01 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D7921F856D for ; Wed, 25 Jan 2012 14:09:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.153 X-Spam-Level: X-Spam-Status: No, score=-10.153 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aRKFkSAnH4Ju for ; Wed, 25 Jan 2012 14:09:00 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 47CC721F8554 for ; Wed, 25 Jan 2012 14:09:00 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0PM8q68018408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 25 Jan 2012 23:08:57 +0100 (MET) From: Martin Rex Message-Id: <201201252208.q0PM8pbu013149@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Wed, 25 Jan 2012 23:08:51 +0100 (MET) In-Reply-To: from "Eric Rescorla" at Jan 25, 12 08:16:51 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Proper server response for certificate mismatch with X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 22:09:01 -0000 Eric Rescorla wrote: > > Honestly, Martin, I have no idea why you're arguing this point: > > (1) This text isn't in the current spec. The current spec for TLSv1.0 is rfc2246 The current spec for TLSv1.1 is rfc4346 and even the current spec for TLSv1.2 contains the claim that this restriction applies to TLSv1.0 and TLSv1.1 so it is a defect in _all_3_ current TLS specifications. from the above three, TLSv1.2 (rfc5246) is factually still the least relevant spec, as it applies to much less than half of the implementations, while rfc2246 applies to 98% of the implementations and rfc4346 applies to maybe 70% of the implementations. > > (2) Neither I or anyone on this thread wrote it. Agreed. I will file erratas for all three current specifications. -Martin From mrex@sap.com Wed Jan 25 17:30:09 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5798A21F84E0 for ; Wed, 25 Jan 2012 17:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.158 X-Spam-Level: X-Spam-Status: No, score=-10.158 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tz9tYzfE3gRI for ; Wed, 25 Jan 2012 17:30:08 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8F80321F84DE for ; Wed, 25 Jan 2012 17:30:08 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id q0Q1U6TL023344 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 26 Jan 2012 02:30:07 +0100 (MET) From: Martin Rex Message-Id: <201201260130.q0Q1U6dL024859@fs4113.wdf.sap.corp> To: tls@ietf.org Date: Thu, 26 Jan 2012 02:30:06 +0100 (MET) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Subject: [TLS] DTLS lacking TLS extensions ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 01:30:09 -0000 I'm somewhat confused about whether TLS extensions apply to DTLS. DTLS 1.0 and 1.2 redefine the ClientHello PDU: http://tools.ietf.org/html/rfc4347#page-12 http://tools.ietf.org/html/rfc6347#page-16 but I did not see the Forward Compatibility Notice from rfc2246 http://tools.ietf.org/html/rfc2246#page-36 for data trailing the Compression Methods in that new DtlsClientHello PDU in rfc4347 and rfc6347, nor do I see a definition of an ExtendedDtlsClientHello PDU in TLS extensions (rfc4366). The most confusing part: You can not implement rfc5746 (TLS extension renegotiation_info) for DTLS without that. -Martin From ekr@rtfm.com Wed Jan 25 17:40:53 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A713E11E8095 for ; Wed, 25 Jan 2012 17:40:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.889 X-Spam-Level: X-Spam-Status: No, score=-102.889 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ss6QUnQu5sS7 for ; Wed, 25 Jan 2012 17:40:53 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id BAA7F11E808C for ; Wed, 25 Jan 2012 17:40:47 -0800 (PST) Received: by vbbfr13 with SMTP id fr13so51067vbb.31 for ; Wed, 25 Jan 2012 17:40:47 -0800 (PST) Received: by 10.52.28.238 with SMTP id e14mr503vdh.96.1327542047173; Wed, 25 Jan 2012 17:40:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.93.163 with HTTP; Wed, 25 Jan 2012 17:40:07 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: <201201260130.q0Q1U6dL024859@fs4113.wdf.sap.corp> References: <201201260130.q0Q1U6dL024859@fs4113.wdf.sap.corp> From: Eric Rescorla Date: Wed, 25 Jan 2012 17:40:07 -0800 Message-ID: To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] DTLS lacking TLS extensions ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 01:40:53 -0000 Good point. DTLS is intended to support extensions--and OpenSSL, at least, supports them in the same way as it does for TLS. There probably should be a definition of ExtendedClientHello in 4346 and 6347, but it's exactly the PDU you would expect. I.e., the extensions come after the CompressionMethod. -Ekr On Wed, Jan 25, 2012 at 5:30 PM, Martin Rex wrote: > I'm somewhat confused about whether TLS extensions apply to DTLS. > > DTLS 1.0 and 1.2 redefine the ClientHello PDU: > =A0http://tools.ietf.org/html/rfc4347#page-12 > =A0http://tools.ietf.org/html/rfc6347#page-16 > > but I did not see the Forward Compatibility Notice from rfc2246 > > =A0http://tools.ietf.org/html/rfc2246#page-36 > > for data trailing the Compression Methods in that new DtlsClientHello PDU > in rfc4347 and rfc6347, nor do I see a definition of an > ExtendedDtlsClientHello PDU in TLS extensions (rfc4366). > > > The most confusing part: You can not implement rfc5746 > (TLS extension renegotiation_info) for DTLS without that. > > > -Martin > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From mrex@sap.com Wed Jan 25 18:13:39 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74C5611E8096 for ; Wed, 25 Jan 2012 18:13:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.16 X-Spam-Level: X-Spam-Status: No, score=-10.16 tagged_above=-999 required=5 tests=[AWL=0.089, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oQzouneWdA3 for ; Wed, 25 Jan 2012 18:13:39 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id B1AC111E808C for ; Wed, 25 Jan 2012 18:13:38 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id q0Q2Dbdv014720 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 26 Jan 2012 03:13:37 +0100 (MET) From: Martin Rex Message-Id: <201201260213.q0Q2Dadk027323@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Thu, 26 Jan 2012 03:13:36 +0100 (MET) In-Reply-To: from "Eric Rescorla" at Jan 25, 12 05:40:07 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] DTLS lacking TLS extensions ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 02:13:39 -0000 Eric Rescorla wrote: > > Good point. > > DTLS is intended to support extensions--and OpenSSL, at least, > supports them in the same way as it does for TLS. > > There probably should be a definition of ExtendedClientHello > in 4346 and 6347, but it's exactly the PDU you would expect. > I.e., the extensions come after the CompressionMethod. That is what I would have expected. But I'm not a DTLS implementor, so I can not comment on implementations. Maybe it is what everyone has been silently doing. Trying to implement rfc5746 in DTLS should have raised some eyebrowse if this was "unexpected", I would assume. suggested changes: 4347: add this into the DTLS ClientHello PDU definition on page-12 as last element following CompressionMethod: Extension client_hello_extension_list<0..2^16-1>; add a normative reference to rfc4366 to section 8.1 for a description of the new Extension element: [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006. 6347: add this into the DTLS ClientHello PDU definition on page-16 as last element following CompressionMethod: select (extensions_present) { case false: struct {}; case true: Extension extensions<0..2^16-1>; }; re-using the existing normative reference to rfc5246 -Martin From marsh@extendedsubset.com Wed Jan 25 22:21:35 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6962C21F8690 for ; Wed, 25 Jan 2012 22:21:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6lrpUU3qjcNK for ; Wed, 25 Jan 2012 22:21:34 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF2921F8680 for ; Wed, 25 Jan 2012 22:21:34 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1RqIiD-000CzW-Mg; Thu, 26 Jan 2012 06:21:33 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id D5AB86023; Thu, 26 Jan 2012 06:21:31 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19U2w6o8ESktnFed7wrcTu2pNUYSTn2bhM= Message-ID: <4F20F0EB.2040006@extendedsubset.com> Date: Thu, 26 Jan 2012 00:21:31 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.24) Gecko/20111108 Thunderbird/3.1.16 MIME-Version: 1.0 To: mrex@sap.com References: <201201260213.q0Q2Dadk027323@fs4113.wdf.sap.corp> In-Reply-To: <201201260213.q0Q2Dadk027323@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] DTLS lacking TLS extensions ? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 06:21:35 -0000 On 01/25/2012 08:13 PM, Martin Rex wrote: > > Maybe it is what everyone has been silently doing. Trying to > implement rfc5746 in DTLS should have raised some eyebrowse if this > was "unexpected", I would assume. As I recall it, there were indeed a few eyebrows raised at RFC 5746! There was no shortage of discussion about the protocol "legality" of sending extensions on an SSLv3 Client Hello. (Scare quotes because there appear to have been multiple versions of the SSL 3.0 spec published on the web at different times). Given the reality of the huge number of SSLv3 implementations in use, the relative rarity of DTLS and the fact that it is an actively maintained spec, we probably didn't feel it necessary to revise more for DTLS than what was added in 5746: http://tools.ietf.org/html/rfc5746 > This extension also can be used with Datagram TLS (DTLS) [RFC4347]. > Although, for editorial simplicity, this document refers to TLS, all > requirements in this document apply equally to DTLS. - Marsh From turners@ieca.com Thu Jan 26 06:42:53 2012 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2268921F860E for ; Thu, 26 Jan 2012 06:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.017 X-Spam-Level: X-Spam-Status: No, score=-102.017 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E3i6-510ouDZ for ; Thu, 26 Jan 2012 06:42:52 -0800 (PST) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [67.18.137.86]) by ietfa.amsl.com (Postfix) with ESMTP id A7F2521F8603 for ; Thu, 26 Jan 2012 06:42:52 -0800 (PST) Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id A825D3138E251; Thu, 26 Jan 2012 08:42:51 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway14.websitewelcome.com (Postfix) with ESMTP id 8DE1D3138E20A for ; Thu, 26 Jan 2012 08:42:51 -0600 (CST) Received: from [96.231.128.155] (port=43537 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from ) id 1RqQXK-0000YZ-Ks for tls@ietf.org; Thu, 26 Jan 2012 08:42:51 -0600 Message-ID: <4F21666A.1090402@ieca.com> Date: Thu, 26 Jan 2012 09:42:50 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: tls@ietf.org References: <20120112151638.8772.89829.idtracker@ietfa.amsl.com> In-Reply-To: <20120112151638.8772.89829.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20120112151638.8772.89829.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-96-231-128-155.washdc.east.verizon.net (thunderfish.local) [96.231.128.155]:43537 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [TLS] Fwd: Last Call: (TLS encryption for RADIUS) to Experimental RFC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2012 14:42:53 -0000 Last call ends today, but if anybody has any concerns please let me know. spt -------- Original Message -------- Subject: Last Call: (TLS encryption for RADIUS) to Experimental RFC Date: Thu, 12 Jan 2012 07:16:38 -0800 From: The IESG Reply-To: ietf@ietf.org To: IETF-Announce CC: radext@ietf.org The IESG has received a request from the RADIUS EXTensions WG (radext) to consider the following document: - 'TLS encryption for RADIUS' as an Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2012-01-26. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies security on the transport layer (TLS) for the RADIUS protocol when transmitted over TCP. This enables dynamic trust relationships between RADIUS servers. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-radext-radsec/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-radext-radsec/ No IPR declarations have been submitted directly on this I-D. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce