> No they don’t always look at the 16-bit field (although they might), but they > look at you funny when you tell them that 1.0 > 3.0 and that you should > totally disable 3.0 and prefer to use 1.2 instead. :) True, but when this happens, I simply tell them that all SSL versions are broken, so they have to use TLS. I'd rather have a consistent versioning story for TLS (1.0->1.1->1.2->2.0), rather than trying to fix the SSL3->TLS1.0 inconsistency at this point. It's already fun enough to explain why DTLS jumped from 1.0 to 1.2 (or Windows from 8 to 10, for that matter).
-----Original Message----- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Yoav Nir Sent: Wednesday, August 31, 2016 7:55 AM To: Daniel Kahn Gillmor <d...@fifthhorseman.net> Cc: <tls@ietf.org> <tls@ietf.org> Subject: Re: [TLS] TLS 1.3 -> TLS 2.0? > On 31 Aug 2016, at 12:21 AM, Daniel Kahn Gillmor <d...@fifthhorseman.net> > wrote: > > On Tue 2016-08-30 16:14:06 -0400, Hubert Kario wrote: >> On Tuesday, 30 August 2016 14:19:33 CEST Dave Garrett wrote: >>> * Keep the version ID as { 3, 4 } (already weird counting; changing >>> risks more intolerance) >> >> IMNSHO this alone is enough of a reason not to do this >> >> it's enough explaining to people that SSLv3.3 is really TLSv1.2, now >> we'll have SSLv3.4 == TLSv1.3 == TLSv2.0 >> >> it's silly at this point > > Who are you talking to who's fine with looking at the bytes on the > wire but isn't fine with understanding that a 16-bit field might not > map directly to our imagination of decimal? No they don’t always look at the 16-bit field (although they might), but they look at you funny when you tell them that 1.0 > 3.0 and that you should totally disable 3.0 and prefer to use 1.2 instead. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
