Re: [TLS] Additional TLS 1.3 results from Chrome

2017-12-19 Thread Adam Langley
On Tue, Dec 19, 2017 at 5:07 AM, Stephen Farrell wrote: > I'm not sure I agree renumbering is the right reaction, > though I don't object to that. This could be a case where > it's overall better that those specific devices suffer > breakage, and hopefully then do get

Re: [TLS] Additional TLS 1.3 results from Chrome

2017-12-19 Thread Tim Hollebeek
> I'm not sure I agree renumbering is the right reaction, though I don't > object to > that. This could be a case where it's overall better that those specific > devices > suffer breakage, and hopefully then do get firmware updated to support > TLS1.3 or TLS-without-extended-random-or-dual-ec >

Re: [TLS] Additional TLS 1.3 results from Chrome

2017-12-19 Thread Stephen Farrell
Hiya, On 19/12/17 13:56, Salz, Rich wrote: > “dropped as a bad idea” is an interesting end-state. Also “on hold > for now” (which is how I want to see the TLS-breaking proposals). > > Having more I-D workflow options seems like something the IESG should > take up. > Well, TBH I doubt it'd be

Re: [TLS] Additional TLS 1.3 results from Chrome

2017-12-19 Thread Salz, Rich
“dropped as a bad idea” is an interesting end-state. Also “on hold for now” (which is how I want to see the TLS-breaking proposals). Having more I-D workflow options seems like something the IESG should take up. ___ TLS mailing list TLS@ietf.org

Re: [TLS] Additional TLS 1.3 results from Chrome

2017-12-19 Thread Stephen Farrell
Hiya, On 19/12/17 01:59, Salz, Rich wrote: > However, since extension numbers are essentially infinite, this WG may > consider renumbering key_share to avoid the issue. > >> I think this would be fine, but not imperative. > > I think it would almost be hypocritical if we did not do it. > I'm