I agree with David. This seems like a low value change On Mon, Apr 3, 2017 at 9:36 AM, David Benjamin <david...@google.com> wrote:
> On Mon, Apr 3, 2017 at 12:29 AM Benjamin Kaduk <bka...@akamai.com> wrote: > >> On 04/02/2017 03:33 AM, Arnaud Venturi wrote: >> >> I could not think of any security or interoperability issue with this >> proposal, the only drawback I can see being the slight complexity added >> in ClientHello parsing. >> >> >> The ClientHello message needs to be interpreted in the same way by TLS >> servers running all versions of TLS. A TLS 1.0 server would not know to >> use the changed interpretation of the fields and would fail to negotiate a >> connection. Basically, no change in the format is possible while >> preserving the backwards and forwards compatibility of version negotiation. >> > > I believe the idea is that, if you support TLS 1.2 and below, you send a > 1.2-compatible ClientHello. If you don't, then you send the proposed > ClientHello. Servers would be required to support both formats. > > This change would save us all of 3 bytes in the ClientHello, so my feeling > is this isn't worth the trouble of having two formats and all the trouble > that entails. (Servers having to parse both formats, code in servers that > won't be exercised for years, clients worrying about whether servers > implemented that, etc.) > > David > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
