[TLS] record layer limits of TLS1.3

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 data transfers most likely he would prefer to use larger blocks. Given that the length field

Re: [TLS] Labels in HKDF-Expand-Label

Actually all future EXPORTERs need to start with EXPORTER-. But this does seem like a reasonable change so I have merged it -Ekr On Tue, Nov 22, 2016 at 9:25 PM, Martin Thomson wrote: > The grammar for the label permits the label to be 9 octets long. > That's the

[TLS] Labels in HKDF-Expand-Label

The grammar for the label permits the label to be 9 octets long. That's the exact length of the prefix. That means that it is valid to use an exporter with an empty label string. That seems dangerous. I propose that we require at least one octet: https://github.com/tlswg/tls13-spec/pull/774

Re: [TLS] Confirming consensus: TLS1.3->TLS*

Using the YEAR as Version was created to make sure that users having old versions of products that are constantly upgraded would feel the pressure to upgrade. This idea doesn't seem equally suitable for security protocols. TLS 4 would IMO be a logical choice since it is numerically higher than

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

On Tue, Nov 22, 2016 at 4:36 PM, Martin Thomson wrote: > On 23 November 2016 at 10:24, Eric Rescorla wrote: > >> [EncryptedExtensions Certifi] > >> [cateRequest Certificate Cer] > >> [tificateVerify Finished] > > > > > > Yeah, that's how this works

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

On 23 November 2016 at 10:24, Eric Rescorla wrote: >> [EncryptedExtensions Certifi] >> [cateRequest Certificate Cer] >> [tificateVerify Finished] > > > Yeah, that's how this works in NSS. To be clear, NSS buffers an entire flight of messages and then sends them. It might

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

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 draft 18, but we >> (ANSSI) have several remarks after

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

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 draft 18, but we > (ANSSI) have several remarks after proof-reading the current > specification. > > We are sorry for the multiple long messages.

Re: [TLS] Confirming consensus: TLS1.3->TLS*

(replies to a bunch of ideas in this thread) As the person who lit the match under this latest bikeshed debate, personally, I don't see a strong consensus building here. Leaving the bikeshed unpainted seems like the option we're headed for, at this rate. I'm fine with TLS 1.3 if that's the

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

On Tue, Nov 22, 2016 at 11:02 AM, Olivier Levillain < olivier.levill...@ssi.gouv.fr> wrote: > > = Extensions and message reuse = > > We were sorry to find that some TLS 1.2 extensions were reused with a > different meaning, or that some TLS 1.3 extensions were context > dependent, which does not

Re: [TLS] Draft 18 review : Message order

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. > > I think Ekr

Re: [TLS] Draft 18 review : Signature in certificates

On Tue, Nov 22, 2016 at 11:07 AM, Olivier Levillain < olivier.levill...@ssi.gouv.fr> wrote: > Hi list, > > I am sorry for the very late answer concerning draft 18, but we > (ANSSI) have several remarks after proof-reading the current > specification. > > We are sorry for the multiple long

Re: [TLS] Draft 18 review : PSK and PSK Binder

On Tue, Nov 22, 2016 at 11:06 AM, Olivier Levillain < olivier.levill...@ssi.gouv.fr> wrote: > Hi list, > > I am sorry for the very late answer concerning draft 18, but we > (ANSSI) have several remarks after proof-reading the current > specification. > > We are sorry for the multiple long

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

On Tue, Nov 22, 2016 at 11:09 AM, Steven Valdez wrote: > 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

Re: [TLS] Draft 18 review: Downgrade protection

Hi Olivier, 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. Thanks, -Ekr On Tue, Nov 22, 2016 at 11:01 AM, Olivier Levillain <

[TLS] Draft 18 review : Signature in certificates

Hi list, I am sorry for the very late answer concerning draft 18, but we (ANSSI) have several remarks after proof-reading the current specification. We are sorry for the multiple long messages. If the WG is interested by some of our concerns/proposals, we would be glad to propose some PRs. =

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

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 group and would

[TLS] Draft 18 review : Minor remarks and typos

Hi list, I am sorry for the very late answer concerning draft 18, but we (ANSSI) have several remarks after proof-reading the current specification. We are sorry for the multiple long messages. If the WG is interested by some of our concerns/proposals, we would be glad to propose some PRs. =

[TLS] Draft 18 review : Message order

Hi list, I am sorry for the very late answer concerning draft 18, but we (ANSSI) have several remarks after proof-reading the current specification. We are sorry for the multiple long messages. If the WG is interested by some of our concerns/proposals, we would be glad to propose some PRs. =

[TLS] Draft 18 review : Message splitting and interleaving

Hi list, I am sorry for the very late answer concerning draft 18, but we (ANSSI) have several remarks after proof-reading the current specification. We are sorry for the multiple long messages. If the WG is interested by some of our concerns/proposals, we would be glad to propose some PRs. =

[TLS] Draft 18 review : 0-RTT

Hi list, I am sorry for the very late answer concerning draft 18, but we (ANSSI) have several remarks after proof-reading the current specification. We are sorry for the multiple long messages. If the WG is interested by some of our concerns/proposals, we would be glad to propose some PRs. =

[TLS] Draft 18 review : PSK and PSK Binder

Hi list, I am sorry for the very late answer concerning draft 18, but we (ANSSI) have several remarks after proof-reading the current specification. We are sorry for the multiple long messages. If the WG is interested by some of our concerns/proposals, we would be glad to propose some PRs. =

[TLS] Draft 18 review : Extensions and message reuse

Hi list, I am sorry for the very late answer concerning draft 18, but we (ANSSI) have several remarks after proof-reading the current specification. We are sorry for the multiple long messages. If the WG is interested by some of our concerns/proposals, we would be glad to propose some PRs. =

[TLS] Draft 18 review: Downgrade protection

Hi list, I am sorry for the very late answer concerning draft 18, but we (ANSSI) have several remarks after proof-reading the current specification. We are sorry for the multiple long messages. If the WG is interested by some of our concerns/proposals, we would be glad to propose some PRs. =

Re: [TLS] housekeeping: uplift RFC 5289 to Proposed Standard

Seeing no objections I’ll get this process underway. spt > On Nov 15, 2016, at 20:10, Sean Turner wrote: > > Note that Russ pointed out during the meeting that even though we can use > this process a new RFC # will be minted at the end of the process. > > spt > >> On Nov 14,

Re: [TLS] Confirming consensus: TLS1.3->TLS*

I have a small preference for TLS 1.3. On Tue, Nov 22, 2016 at 10:04 AM, Scott Schmit 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.