Re: [TLS] Treatment of (legacy_record_)version field [was Re: (strict) decoding of legacy_record_version?]

>>> Eric Rescorla 11/23/16 2:18 PM >>> > In general, it should ignore it. It's going to become increasingly common to > have this be a version you don't support given the recommendation to use > 0301 and the ongoing deprecation of TLS 1.0. I think it would be fine to > sanity >

Re: [TLS] Additional warnings on 0-RTT data

On Wednesday, November 23, 2016 7:20 PM, Colm MacCárthaigh wrote: > > Prior to TLS1.3, replay is not possible, so the risks are new, but the > end-to-end designers > may not realize to update their threat model and just what is required. I'd > like to spell > that out more than what's where at

Re: [TLS] Additional warnings on 0-RTT data

On Wed, Nov 23, 2016 at 8:40 PM, Martin Thomson wrote: > On 24 November 2016 at 15:11, Colm MacCárthaigh wrote: > > Do you disagree that the three specific example security issues provided > are > > realistic, representative and impactful? If so,

Re: [TLS] Additional warnings on 0-RTT data

On 24 November 2016 at 15:11, Colm MacCárthaigh wrote: > Do you disagree that the three specific example security issues provided are > realistic, representative and impactful? If so, what would persuade you to > change your mind? These are simply variants on "if someone hits

Re: [TLS] Additional warnings on 0-RTT data

On 24 November 2016 at 13:18, Colm MacCárthaigh wrote: > Can I break this into two parts then? First, do you agree that it would be > legitimate for a client, or an implementation (library), to deliberately > replay 0-RTT data? E.g. browsers and TLS libraries MAY implement this

Re: [TLS] Additional warnings on 0-RTT data

On Wed, Nov 23, 2016 at 3:03 PM, Martin Thomson wrote: > This seems like too much text to me. Maybe some people would > appreciate the reminder that replay might cause side-effects to be > triggered multiple times, or that side effects are just effects and > those

Re: [TLS] SNI and Resumption/0-RTT

On 24 November 2016 at 09:46, Victor Vasiliev wrote: > For concreteness, I wrote a pull request that describes (2): > At this point, I think that it would be more sensible to write a separate extension draft. There are a

Re: [TLS] Additional warnings on 0-RTT data

This seems like too much text to me. Maybe some people would appreciate the reminder that replay might cause side-effects to be triggered multiple times, or that side effects are just effects and those might also be observable. But I think that those reminders could be provided far more

Re: [TLS] SNI and Resumption/0-RTT

It seems that this issue has not been so far successfully resolved, and to the best of my knowledge it has not been discussed during the meeting in Seoul. I still believe that this is a valuable feature, and our experience with 0-RTT handshake deployment in QUIC has indicated that it's basically

Re: [TLS] record layer limits of TLS1.3

On Nov 23, 2016 10:22 AM, "Jeremy Harris" wrote: > > On 23/11/16 08:50, Yoav Nir wrote: > > As long as you run over a network that has a smallish MTU, you’re going to incur the packetization costs anyway, either in your code or in operating system code. If you have a 1.44 GB

Re: [TLS] record layer limits of TLS1.3

On 23/11/16 08:50, Yoav Nir wrote: > As long as you run over a network that has a smallish MTU, you’re going to > incur the packetization costs anyway, either in your code or in operating > system code. If you have a 1.44 GB file you want to send, it’s going to take > a million IP packets

Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis

>> - Section 1 >> "This is illustrated in the following table, based on [Lenstra_Verheul], >> which gives approximate comparable key sizes for symmetric- and >> asymmetric-key cryptosystems based on the best-known algorithms for >> attacking them." >> >> The key sizes for DH/DSA/RSA does not

[TLS] Additional warnings on 0-RTT data

I've submitted a PR with an expanded warning on the dangers of 0-RTT data for implementors: https://github.com/tlswg/tls13-spec/pull/776/files The text is there, and the TLDR summary is basically that time-based defenses aren't sufficient to mitigate idempotency bugs, so applications need to be

Re: [TLS] Draft 18 review : Message order

Hi, > On Tue, Nov 22, 2016 at 11:08 AM, Olivier Levillain < > olivier.levill...@ssi.gouv.fr> wrote: > >> = Message order = >> >> I believe the message P.27 section 4 is important, but not >> sufficient. As already expressed on the list, a formal automaton >> should be provided in the spec. >> >>

Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis

I’m not even sure what my position is on this. Specifying the use of a context here goes against the recommendation in the CFRG draft: Contexts SHOULD NOT be used opportunistically, as that kind of use is very error-prone. If contexts are used, one SHOULD require all

Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis

On Wed, Nov 23, 2016 at 03:39:38PM +0200, Yoav Nir wrote: > > > On 23 Nov 2016, at 12:22, John Mattsson wrote: > > > > On 2016-11-21, 06:31, "TLS on behalf of Yaron Sheffer" > > on behalf of > >

Re: [TLS] record layer limits of TLS1.3

> On 23 Nov 2016, at 09:50, Yoav Nir wrote: > > > On 23 Nov 2016, at 10:30, Nikos Mavrogiannopoulos wrote: > >> On Wed, 2016-11-23 at 10:05 +0200, Yoav Nir wrote: >>> Hi, Nikos >>> >>> On 23 Nov 2016, at 9:06, Nikos Mavrogiannopoulos

Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis

> On 23 Nov 2016, at 12:22, John Mattsson wrote: > > On 2016-11-21, 06:31, "TLS on behalf of Yaron Sheffer" > on behalf of > yaronf.i...@gmail.com > wrote: > >> So the key schedule

Re: [TLS] Draft 18 review : Hello Retry Request and supported groups cache

On Wed, Nov 23, 2016 at 5:25 AM, Olivier Levillain < olivier.levill...@ssi.gouv.fr> wrote: > >> There were actually two points in my message: > >> - I was not convinced by this way of signalling a preference without > >> enforcing it, but I understand that, if we keep supported_groups, it > >>

Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis

Hi, John Thanks for the review. See my responses below: > On 23 Nov 2016, at 12:15, John Mattsson wrote: > > I have not read the processing parts in detail. Here are comments on the > first and last sections of the document. > > Cheers, > John > > - Somewhere > I

Re: [TLS] Draft 18 review : Hello Retry Request and supported groups cache

>> There were actually two points in my message: >> - I was not convinced by this way of signalling a preference without >> enforcing it, but I understand that, if we keep supported_groups, it >> does not cost much and the client can safely ignore the server sent >> extension; >> - however, I

Re: [TLS] Treatment of (legacy_record_)version field [was Re: (strict) decoding of legacy_record_version?]

On Wed, Nov 23, 2016 at 3:39 AM, Andreas Walz wrote: > Dear all, > > bringing up this thread again > > In the course of studying the way TLS implementations treat the "version" > (or "legacy_record_version") field in the record header, we were wondering >

Re: [TLS] Draft 18 review : Hello Retry Request and supported groups cache

On Wed, Nov 23, 2016 at 12:19 AM, Olivier Levillain < olivier.levill...@ssi.gouv.fr> wrote: > Hi, > > >> Being able to send supported_groups does allow a server to choose to > make > >> a tradeoff between an extra round trip on the current connection and its > >> own group preferences. One

[TLS] Treatment of (legacy_record_)version field [was Re: (strict) decoding of legacy_record_version?]

Dear all, bringing up this thread again In the course of studying the way TLS implementations treat the "version" (or "legacy_record_version") field in the record header, we were wondering (please excuse if we missed some arguments here from past discussions): (1) What is an

Re: [TLS] WGLC for draft-ietf-tls-rfc4492bis

On 2016-11-21, 06:31, "TLS on behalf of Yaron Sheffer" wrote: >So the key schedule changed and therefore we think cross-version attacks >are impossible. Have we also analyzed other protocols to ensure that >cross protocol attacks, e.g.

Re: [TLS] Draft 18 review : Message splitting and interleaving

Le 23/11/2016 00:24, Eric Rescorla a écrit : > On Tue, Nov 22, 2016 at 2:18 PM, David Benjamin > wrote: > >> On Tue, Nov 22, 2016 at 2:05 PM Olivier Levillain < >> olivier.levill...@ssi.gouv.fr> wrote: >> >>> Hi list, >>> >>> I am sorry for the very late answer concerning

Re: [TLS] record layer limits of TLS1.3

Maybe a solution would be a better maximum fragment length extension which allows the size can be negotiated in a more fine-grained way, as pointed in: https://www.ietf.org/mail-archive/web/tls/current/msg12472.html I also found these requests asking for larger packet sizes.

Re: [TLS] Re-use and export of DH shares

And if it wasn’t clear, this *is* a WGLC comment on the TLS 1.3 draft based on discussion in Tuesday’s session in Seoul. Yoav > On 20 Nov 2016, at 12:21, Yoav Nir wrote: > > Hi. > > I’ve created a PR for TLS 1.3 > https://github.com/tlswg/tls13-spec/pull/768 > > It adds

Re: [TLS] Draft 18 review : 0-RTT

Le 23/11/2016 01:28, Martin Thomson a écrit : > On 23 November 2016 at 06:07, Olivier Levillain > wrote: >> In 4.2.8 (P.47), the server receiving early_data "can behave in one of >> two ways"... followed by three cases. Beside the typo, the first case >> could be

Re: [TLS] Draft 18 review : Extensions and message reuse

Le 22/11/2016 22:19, Eric Rescorla a écrit : > On Tue, Nov 22, 2016 at 11:02 AM, Olivier Levillain < > olivier.levill...@ssi.gouv.fr> wrote: >> The first example of such a problem is the signature_scheme and >> signature_algorithms enums. In practice, the signature_algorithm must >> contain

Re: [TLS] record layer limits of TLS1.3

On 23 Nov 2016, at 10:30, Nikos Mavrogiannopoulos wrote: > On Wed, 2016-11-23 at 10:05 +0200, Yoav Nir wrote: >> Hi, Nikos >> >> On 23 Nov 2016, at 9:06, Nikos Mavrogiannopoulos >> wrote: >> >>> >>> Hi, >>> Up to the current draft of TLS1.3 the record

Re: [TLS] record layer limits of TLS1.3

I worry about the buffer sizes required on embedded devices. Hopefully the other endpoint would be programmed to limit record sizes, but is that something we want to rely on? This could be a parameter agreed upon during the handshake, but that seems bad. On Wed, Nov 23, 2016 at 12:41 AM, Nikos

Re: [TLS] record layer limits of TLS1.3

Can you send multiple records in one data transfer to achieve whatever gains are desired? On Wed, Nov 23, 2016 at 12:30 AM, Nikos Mavrogiannopoulos wrote: > On Wed, 2016-11-23 at 10:05 +0200, Yoav Nir wrote: > > Hi, Nikos > > > > On 23 Nov 2016, at 9:06, Nikos Mavrogiannopoulos

Re: [TLS] Draft 18 review: Downgrade protection

Hi, > Thanks for your comments. I do want this section to be clear. > > It would be very helpful if you formatted this as a PR. That would make it > easier to understand the changes in this text. The text has been proposed as PR 775 (https://github.com/tlswg/tls13-spec/pull/775). olivier

Re: [TLS] record layer limits of TLS1.3

On Wed, 2016-11-23 at 10:05 +0200, Yoav Nir wrote: > Hi, Nikos > > On 23 Nov 2016, at 9:06, Nikos Mavrogiannopoulos > wrote: > > > > > Hi, > >  Up to the current draft of TLS1.3 the record layer is restricted > > to > > sending 2^14 or less. Is the 2^14 number something we

Re: [TLS] Draft 18 review : Hello Retry Request and supported groups cache

Hi, >> Being able to send supported_groups does allow a server to choose to make >> a tradeoff between an extra round trip on the current connection and its >> own group preferences. One example where a server might want to do this is >> where it believes that X25519 is likely a more future-proof

Re: [TLS] record layer limits of TLS1.3

Hi, Nikos On 23 Nov 2016, at 9:06, Nikos Mavrogiannopoulos wrote: > Hi, > Up to the current draft of TLS1.3 the record layer is restricted to > sending 2^14 or less. Is the 2^14 number something we want to preserve? > 16kb used to be a lot, but today if one wants to do fast