Re: [TLS] Point validation in 1.3
Le 2016-11-15 15:35, Ilari Liusvaara a écrit : On Tue, Nov 15, 2016 at 05:02:24PM +0900, Yoav Nir wrote: I think the performance enhancement (in terms of handshakes per second) that you get by reusing ephemeral keys is so great, that we have to assume people will do it. You don’t have to keep the keys indefinitely. It’s fine to generate a new key every second or ten seconds or so. Which makes running the point validation all the more important. There's two main reasons for point validation: 1) Preventing leaking of the secret exponent. 2) Preventing key collisions from low-order points. TLS 1.3 isn't vulernable to 2) like TLS 1.2 and below are (without EMS). X25519/X448 have been explicitly designed to resist 1). If you want to prevent using low-order points for some reason, there is a handy trick: Check if the output of X25519/X448 is all zeroes or not, and abort if it is. There is an unfortunately common mis-conception that X25519 doesn't need point validation for Diffie-Hellman which comes from the original PR of Bernstein et al. Curve25519 has an order 8 subgroup that can be used to do key collisions and transcript synchronization attacks (see III.B.2 in [1]). The proper validation is to exclude 0, 1, 325606250916557431795983626356110631294008115727848805560023387167927233504, 39382357235489614581723060781553021112529911719440698176882885853963445705823, 2^255 - 19 - 1, 2^255 - 19, 2^255 - 19 + 1, 2^255 - 19 + 325606250916557431795983626356110631294008115727848805560023387167927233504, 2^255 - 19 + 39382357235489614581723060781553021112529911719440698176882885853963445705823, 2(2^255 - 19) - 1, 2(2^255 - 19), and 2(2^255 - 19) + 1. Without this validation, any one peer of the connection can (mostly) control the session key, which is mitigated in TLS 1.3 but still an undesirable property in any compound authentication setting. Best, Antoine [1] http://antoine.delignat-lavaud.fr/doc/ndss15.pdf ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Point validation in 1.3
Le 2016-11-17 14:58, Antoine Delignat-Lavaud a écrit : Le 2016-11-15 15:35, Ilari Liusvaara a écrit : On Tue, Nov 15, 2016 at 05:02:24PM +0900, Yoav Nir wrote: I think the performance enhancement (in terms of handshakes per second) that you get by reusing ephemeral keys is so great, that we have to assume people will do it. You don’t have to keep the keys indefinitely. It’s fine to generate a new key every second or ten seconds or so. Which makes running the point validation all the more important. There's two main reasons for point validation: 1) Preventing leaking of the secret exponent. 2) Preventing key collisions from low-order points. TLS 1.3 isn't vulernable to 2) like TLS 1.2 and below are (without EMS). X25519/X448 have been explicitly designed to resist 1). If you want to prevent using low-order points for some reason, there is a handy trick: Check if the output of X25519/X448 is all zeroes or not, and abort if it is. There is an unfortunately common mis-conception that X25519 doesn't need point validation for Diffie-Hellman which comes from the original PR of Bernstein et al. Curve25519 has an order 8 subgroup that can be used to do key collisions and transcript synchronization attacks (see III.B.2 in [1]). The proper validation is to exclude 0, 1, 325606250916557431795983626356110631294008115727848805560023387167927233504, 39382357235489614581723060781553021112529911719440698176882885853963445705823, 2^255 - 19 - 1, 2^255 - 19, 2^255 - 19 + 1, 2^255 - 19 + 325606250916557431795983626356110631294008115727848805560023387167927233504, 2^255 - 19 + 39382357235489614581723060781553021112529911719440698176882885853963445705823, 2(2^255 - 19) - 1, 2(2^255 - 19), and 2(2^255 - 19) + 1. Without this validation, any one peer of the connection can (mostly) control the session key, which is mitigated in TLS 1.3 but still an undesirable property in any compound authentication setting. I misunderstood your message, if you check the output of the multiplication with the peer public key rather than the public key itself, checking for 0 is indeed the easiest (and safe) check to perform. Antoine ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [ALU] Re: extending the un-authenticated DTLS header
Hi Achim, On 16/11/2016 10:21, "TLS on behalf of Kraus Achim (INST/ESY1)" wrote: >I'm still wondering, why the "clashing" calculations (section 4) are only >based on the number of clients and not also on the length of the hash >chain. I guess you are right. The left column should say "sessions x window_size". ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for agenda items @ IETF 97
I’ve uploaded the slides for Friday as well as a revised WG Chair Slide deck (version 5), which reflects the revised agenda based on presentations that got moved to Wednesday. spt > On Nov 15, 2016, at 08:20, Sean Turner wrote: > > Please note that I’ve been uploading the presentations as I’ve been getting > them; I’m embedding links in the chair slides to the presenters slides. The > chair slides are up to revision 4 (in case you’ve downloaded them earlier). > Still waiting on a couple. > > Note that Martin will have no slides for the Example Handshake Traces in TLS > 1.3 agenda item. > > spt > >> On Oct 24, 2016, at 00:13, Sean Turner wrote: >> >> The final IETF 97 agenda is out: >> https://datatracker.ietf.org/meeting/97/agenda.html >> >> Please note that there are TWO tls sessions: >> 1. Tuesday @ 15:50-18:20 in Park Ballroom 1 >> 2. Friday @ 09:30-1130 in Grand Ballroom 2 >> >> spt >> >>> On Oct 18, 2016, at 14:07, Sean Turner wrote: >>> >>> The preliminary IETF 97 agenda is out: >>> https://datatracker.ietf.org/meeting/97/agenda.html. We’re currently >>> scheduled for Tuesday @ 15:50-18:20 in Park Ballroom 1. >>> >>> Please send in agenda requests. But, please note that TLS 1.3-related >>> issues and WG drafts will be given a priority during the sessions. We’re >>> also going to give preferential treatment to drafts that generated >>> discussion on the list. >>> >>> Cheers, >>> >>> J&S >> > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Call for agenda items @ IETF 97
New version uploaded v6 is now the current version. spt > On Nov 18, 2016, at 08:13, Sean Turner wrote: > > I’ve uploaded the slides for Friday as well as a revised WG Chair Slide deck > (version 5), which reflects the revised agenda based on presentations that > got moved to Wednesday. > > spt > >> On Nov 15, 2016, at 08:20, Sean Turner wrote: >> >> Please note that I’ve been uploading the presentations as I’ve been getting >> them; I’m embedding links in the chair slides to the presenters slides. The >> chair slides are up to revision 4 (in case you’ve downloaded them earlier). >> Still waiting on a couple. >> >> Note that Martin will have no slides for the Example Handshake Traces in TLS >> 1.3 agenda item. >> >> spt >> >>> On Oct 24, 2016, at 00:13, Sean Turner wrote: >>> >>> The final IETF 97 agenda is out: >>> https://datatracker.ietf.org/meeting/97/agenda.html >>> >>> Please note that there are TWO tls sessions: >>> 1. Tuesday @ 15:50-18:20 in Park Ballroom 1 >>> 2. Friday @ 09:30-1130 in Grand Ballroom 2 >>> >>> spt >>> On Oct 18, 2016, at 14:07, Sean Turner wrote: The preliminary IETF 97 agenda is out: https://datatracker.ietf.org/meeting/97/agenda.html. We’re currently scheduled for Tuesday @ 15:50-18:20 in Park Ballroom 1. Please send in agenda requests. But, please note that TLS 1.3-related issues and WG drafts will be given a priority during the sessions. We’re also going to give preferential treatment to drafts that generated discussion on the list. Cheers, J&S >>> >> > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] WGLC for draft-ietf-tls-ecdhe-psk-aead
This is the working group last call for the "ECDHE_PSK with AES-GCM and AES-CCM CSs for TLS" draft available at http://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-psk-aead/. Please review the document and send your comments to the list by 9 December 2016. Thanks, J&S ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
[TLS] Confirming consensus: TLS1.3->TLS*
At IETF 97, the chairs lead a discussion to resolve whether the WG should rebrand TLS1.3 to something else. Slides can be found @ https://www.ietf.org/proceedings/97/slides/slides-97-tls-rebranding-aka-pr612-01.pdf. The consensus in the room was to leave it as is, i.e., TLS1.3, and to not rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this decision on the list so please let the list know your top choice between: - Leave it TLS 1.3 - Rebrand TLS 2.0 - Rebrand TLS 2 - Rebrand TLS 4 by 2 December 2016. Thanks, J&S ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Confirming consensus: TLS1.3->TLS*
Bleh. Can’t we get AOL to release the SSL trademark so that we can call it SSLv4? I hummed for TLS 4, so I’ll stay consistent: TLS 4. Yoav > On 18 Nov 2016, at 11:12, Sean Turner wrote: > > At IETF 97, the chairs lead a discussion to resolve whether the WG should > rebrand TLS1.3 to something else. Slides can be found @ > https://www.ietf.org/proceedings/97/slides/slides-97-tls-rebranding-aka-pr612-01.pdf. > > The consensus in the room was to leave it as is, i.e., TLS1.3, and to not > rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this decision on > the list so please let the list know your top choice between: > > - Leave it TLS 1.3 > - Rebrand TLS 2.0 > - Rebrand TLS 2 > - Rebrand TLS 4 > > by 2 December 2016. > > Thanks, > J&S > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Confirming consensus: TLS1.3->TLS*
I also prefer TLS 4 but am fine with TLS 1.3 - Erik On Nov 17, 2016 9:41 PM, "Yoav Nir" wrote: > Bleh. Can’t we get AOL to release the SSL trademark so that we can call it > SSLv4? > > I hummed for TLS 4, so I’ll stay consistent: TLS 4. > > Yoav > > > On 18 Nov 2016, at 11:12, Sean Turner wrote: > > > > At IETF 97, the chairs lead a discussion to resolve whether the WG > should rebrand TLS1.3 to something else. Slides can be found @ > https://www.ietf.org/proceedings/97/slides/slides- > 97-tls-rebranding-aka-pr612-01.pdf. > > > > The consensus in the room was to leave it as is, i.e., TLS1.3, and to > not rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this > decision on the list so please let the list know your top choice between: > > > > - Leave it TLS 1.3 > > - Rebrand TLS 2.0 > > - Rebrand TLS 2 > > - Rebrand TLS 4 > > > > by 2 December 2016. > > > > Thanks, > > J&S > > ___ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Confirming consensus: TLS1.3->TLS*
I prefer TLS 1.3 but am also fine with TLS 4. On Fri, Nov 18, 2016 at 11:12 AM, Sean Turner wrote: > At IETF 97, the chairs lead a discussion to resolve whether the WG should > rebrand TLS1.3 to something else. Slides can be found @ > https://www.ietf.org/proceedings/97/slides/slides- > 97-tls-rebranding-aka-pr612-01.pdf. > > The consensus in the room was to leave it as is, i.e., TLS1.3, and to not > rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this decision > on the list so please let the list know your top choice between: > > - Leave it TLS 1.3 > - Rebrand TLS 2.0 > - Rebrand TLS 2 > - Rebrand TLS 4 > > by 2 December 2016. > > Thanks, > J&S > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Confirming consensus: TLS1.3->TLS*
I am a big fan of leaving it as TLS 1.3. It feels more like evolution than revolution, even with the addition of 0-RTT. I would like to see a future TLS 2.0, but one that makes fundamental changes which didn't make the cut for 1.3, e.g. moving to OPTLS. -- Tony Arcieri ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Confirming consensus: TLS1.3->TLS*
On Fri, Nov 18, 2016 at 11:12:48AM +0900, Sean Turner wrote: > At IETF 97, the chairs lead a discussion to resolve whether the WG should > rebrand TLS1.3 to something else. Slides can be found @ > https://www.ietf.org/proceedings/97/slides/slides-97-tls-rebranding-aka-pr612-01.pdf. > > The consensus in the room was to leave it as is, i.e., TLS1.3, and to not > rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this decision > on the list so please let the list know your top choice between: > > - Leave it TLS 1.3 > - Rebrand TLS 2.0 > - Rebrand TLS 2 > - Rebrand TLS 4 TLS 4 sounds about right to me: * Conveys the substantial protocol changes * Avoids any confusion from SSLv2/SSLv3 bearing higher numbers than TLS 1.x * If someone happens to call it SSLv4 it will not be confusing. * Matches the minor version on the wire protocol Though with this choice, the next version would likely be TLS 5, whether or not it is a major change or just incremental change, I don't think it will going forward be important to convey that some version updates are minor. A non-branching integral sequence feels about right. The only downside I see is that it becomes unclear what to call some future protocol version with a wire protocol major number not equal to 3. My take is that such a protocol would no longer be TLS (it would presumably have an incompatible HELLO and/or record layer format and would not be able to negotiate older protocol versions), so there's likely not much point in calling such a hypothetical beast "TLS". -- Viktor. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Confirming consensus: TLS1.3->TLS*
I already hummed in the room, but I think it should stay as TLS 1.3. Either of TLS 2 or TLS 4 makes the SSL/TLS silliness worse. One matches SSL 2.0 and the other just makes all this weirder. (Do we really want 2.0 < 3.0 < 1.0 < 1.1 < 1.2 < 4?) TLS 1.3 is the natural next number and doesn't make anything worse. Let's just use it. On Fri, Nov 18, 2016 at 3:04 PM Viktor Dukhovni wrote: > On Fri, Nov 18, 2016 at 11:12:48AM +0900, Sean Turner wrote: > > > At IETF 97, the chairs lead a discussion to resolve whether the WG should > > rebrand TLS1.3 to something else. Slides can be found @ > > > https://www.ietf.org/proceedings/97/slides/slides-97-tls-rebranding-aka-pr612-01.pdf > . > > > > The consensus in the room was to leave it as is, i.e., TLS1.3, and to not > > rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this decision > > on the list so please let the list know your top choice between: > > > > - Leave it TLS 1.3 > > - Rebrand TLS 2.0 > > - Rebrand TLS 2 > > - Rebrand TLS 4 > > TLS 4 sounds about right to me: > > * Conveys the substantial protocol changes > * Avoids any confusion from SSLv2/SSLv3 bearing higher numbers than > TLS 1.x > * If someone happens to call it SSLv4 it will not be confusing. > * Matches the minor version on the wire protocol > > Though with this choice, the next version would likely be TLS 5, > whether or not it is a major change or just incremental change, I > don't think it will going forward be important to convey that some > version updates are minor. A non-branching integral sequence feels > about right. > > The only downside I see is that it becomes unclear what to call > some future protocol version with a wire protocol major number not > equal to 3. My take is that such a protocol would no longer be > TLS (it would presumably have an incompatible HELLO and/or record > layer format and would not be able to negotiate older protocol > versions), so there's likely not much point in calling such a > hypothetical beast "TLS". > > -- > Viktor. > > ___ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] Confirming consensus: TLS1.3->TLS*
On Thursday, November 17, 2016 09:12:48 pm Sean Turner wrote: > The consensus in the room was to leave it as is, i.e., TLS1.3, and to not > rebrand it to TLS 2.0, TLS 2, or TLS 4. We need to confirm this decision on > the list so please let the list know your top choice between: > > - Leave it TLS 1.3 > - Rebrand TLS 2.0 > - Rebrand TLS 2 > - Rebrand TLS 4 In descending order of preference: 1) TLS 2.0 or TLS 2 2) TLS 1.3 3) TLS 4 There is no versioning here that doesn't have a confusion risk. Some people worry about an SSL/TLS 2.0 confusion. I worry that TLS 1.3 won't be taken with as much seriousness/urgency at a glance by those with a lower technical understanding (too many of us resort to "it's really like TLS 2" when trying to explain the leap). TLS 4 or elventybillion just forces people to answer the "what happened to TLS 3" question forever, without really making anything more clear. The confusion a big number jump tries to avoid is far better addressed by experts finally stopping with the SSL/TLS conflation. If the consensus is to keep the status quo, in spite of major changes that would normally dictate a major version bump, that's unfortunate... but the world will not implode. :/ Dave PS I suspect that a push for a major version bump a year and a half ago would've had more support, but many of us who are currently in favor of it were still in the "meh, whatever" camp. Oh well. ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
