This was infact the idea, even I thought of the gain much more in terms of removing something useless than in gaining a few bytes.
Anyway, thanks for your opinions and your time ! -- Arnaud On 04/04/2017 03:10 AM, Eric Rescorla wrote: > 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 > <mailto:david...@google.com>> wrote: > > On Mon, Apr 3, 2017 at 12:29 AM Benjamin Kaduk <bka...@akamai.com > <mailto: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 <mailto:TLS@ietf.org> > https://www.ietf.org/mailman/listinfo/tls > <https://www.ietf.org/mailman/listinfo/tls> > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
