Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

On Thu, May 31, 2018 at 7:10 PM, Peter Gutmann wrote: > Eric Rescorla writes: > > >As noted earlier, it's premature for TLS-LTS to request a code point > because > >the enabling document has not yet been published, > > And yet -compression was allocated a codepoint without this. Compression

Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

David Benjamin writes: >Our problems with 26 and 40 are because we like to make "official" >allocations consecutively, and then "unofficial" allocations missed the >obvious corollary: do not mimic this. Yeah, based on being asked to wait for the registry draft I assumed nothing would be issued

Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

Eric Rescorla writes: >As noted earlier, it's premature for TLS-LTS to request a code point because >the enabling document has not yet been published, And yet -compression was allocated a codepoint without this. This whole mess was created because I asked for early allocation and was told to

Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

​David Benjamin writes: >I probed a bunch of servers yesterday and found evidence of yet another >collision at 26! It's possible these are TLS-LTS implementations, but a lot >of them additionally only support RSA decryption ciphers, which makes this >seem unlikely. Another reason why it should

Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

We might also want to mark 40 similarly given the ExtendedRandom collision that caused issues with key_share. On Thu, May 31, 2018 at 11:10 AM Benjamin Kaduk wrote: > I think there's also some room to just mark 26 as "Reserved - unauthorized > use has rendered this value unsuitable for official

Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

I think there's also some room to just mark 26 as "Reserved - unauthorized use has rendered this value unsuitable for official allocation". -Ben On Thu, May 31, 2018 at 07:50:46AM -0700, Eric Rescorla wrote: > Based on this, I propose that IANA allocates a new !26 Early Data code > point for

Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

Just picking a random high number for QUIC seems reasonable for this stage. None of this still will escape outside of draft QUIC versions (which, themselves, will be short-lived) and a collision at high numbers isn't likely anyway. Our problems with 26 and 40 are because we like to make "official"

Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

Based on this, I propose that IANA allocates a new !26 Early Data code point for compressed certificates (that's mechanical). As noted earlier, it's premature for TLS-LTS to request a code point because the enabling document has not yet been published, so we can defer the question of its use of

Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

I probed a bunch of servers yesterday and found evidence of yet another collision at 26! It's possible these are TLS-LTS implementations, but a lot of them additionally only support RSA decryption ciphers, which makes this seem unlikely. These servers do not appear to do anything with the

Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

I agree we should use a different number than 26 for certificate compression. I don't see a problem with assigning 27 and reserving 26 for now. On Wed, May 30, 2018 at 8:13 PM, Adam Langley wrote: > On Tue, May 29, 2018 at 6:16 PM Jeffrey Walton wrote: > > I also delivered an OpenSSL-based

Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

On Tue, May 29, 2018 at 6:16 PM Jeffrey Walton wrote: > I also delivered an OpenSSL-based TLS-LTS prototype to a Hoteliers > working group for their smart locks last year. I have no idea how much > of the code they are going to reuse (if any at all). Chrome / Google is blocked on code-point

Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

On Tue, May 29, 2018 at 4:21 PM, Salz, Rich wrote: >>There's a tradeoff between respecting the official allocation processes > and avoiding real-world breakage. I think we can all make our own > assessments > on the former, but for the latter, all the evidence we have so far is a >

Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

>There's a tradeoff between respecting the official allocation processes and avoiding real-world breakage. I think we can all make our own assessments on the former, but for the latter, all the evidence we have so far is a claim from Peter that there exists software that

Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

On Sun, May 27, 2018 at 09:56:30AM -0700, Eric Rescorla wrote: > Well, this is a bit premature because the document hasn't actually been > published, just approved. It's also not properly addressed -- regular allocations under the "specification required" policy go directly to IANA, whereas RFC

Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

> On May 28, 2018, at 12:38 AM, Peter Gutmann wrote: > > See my previous comment on why it was used, it was only because implementers > needed something to put in their code while I waited for the registry draft to > be published... I am curious whether (given the

Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

Eric Rescorla writes: >In any case, I don't think we should assign code point 26 to this extension. >I recognize that you have existing implementations that happen to use it, but >that's a result of the unfortunate decision to squat on a code point which >was right in the way of

Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

>In any case, I don't think we should assign code point 26 to this extension. I >recognize that you have existing implementations that happen to use it, but >that's a result of the unfortunate decision to squat on a code point which was >right in the way of near future assignments, and those

Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

Well, this is a bit premature because the document hasn't actually been published, just approved. In any case, I don't think we should assign code point 26 to this extension. I recognize that you have existing implementations that happen to use it, but that's a result of the unfortunate decision

Re: [TLS] Protocol Action: 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)' to Proposed Standard (draft-ietf-tls-iana-registry-updates-05.txt)

The IESG writes: >The IESG has approved the following document: >- 'IANA Registry Updates for Transport Layer Security (TLS) and Datagram > Transport Layer Security (DTLS)' > (draft-ietf-tls-iana-registry-updates-05.txt) as Proposed Standard Now that it's been