Re: [TLS] A new TLS version negotiation mechanism

[Dave Garrett <[e-mail]>]

Thanks for the feedback.

On Tuesday, March 10, 2015 10:08:27 am Brian Smith wrote:
> Dave Garrett <[e-mail]> wrote:
> 1. Nit: It seems unnecessary to wrap a single data item in a struct.

Just following the general style of some other extensions. Technically, each index of extension_data itself could be used as-is without wrapping, but specifying it generically seems best.

> 2. I don't see why, for non-draft versions at least, the client needs
> to tell the server about any version it supports other than the newest
> version. It is not good to indicate support for older (worse) versions
> unnecessarily. Particularly for clients that support non-secure
> fallback, it is not good to tell the MitM the weakest version that the
> client would fall back to.

I did list that as one reason to consider against this.

My argument is that:
1) If we're replacing the version negotiation, we should make it better instead of merely kludging around intolerance.
2) No TLS 1.3+ client should be supporting insecure fallback AT ALL. This is a hard requirement for this.
3) Using an entirely different mechanism for draft and release could be prone to mistake. Better to test early.

> I don't think it is worth making the main version negotiation
> mechanism more complicated and error-prone just to support advertising
> draft versions. There could be a draft_subversion extension that could
> be used to indicate support for a draft revision of the version
> indicated in the client_version extension instead.

My initial idea was to have two essentially identical extensions, but with a different ID for release and draft. However, as I said above, this feels more complicated than needed and I'd rather just use one consistent mechanism for everything. Reserving part of the ID space for draft is not that complicated. It'd just be essentially turning the field into an enum value.

> > The ClientHello.version in this negotiation mechanism would be frozen to {3,3} (TLS 1.2) for clients willing to negotiate TLS 1.2.
> 
> I suggest also renaming ClientHello.client_version to
> ClientHello.always_0x03_0x03 to avoid confusion.

Renaming fields for clarity makes sense.

> > Clients could set this to {0,0} to force only the new mechanism with
> > no negotiation with servers not supporting it (i.e. if TLS 1.0-1.2 are
> > all undesirable).
> 
> { 0, 0 } would probably have even more issues with TLS intolerance
> than we've historically experienced. AFAICT, this "forcing" feature is
> not necessary so I suggest you just drop it.

It's to deal with a specific issue I thought of just before sending the email. If a client considers TLS 1.0-1.2 to be unsafe and attempts a connection of TLS 1.3+, then TLS 1.2 servers will still respond with ServerHellos due to the frozen field. Clients would have to essentially fake offers and abort on TLS 1.2. Any new mechanism should not have oddities like this that can't be resolved properly.

Server TLS version intolerance is essentially fine in the TLS 1.3+ only case. An abort instead of reject is fine. There could be issues with crap in the middle, though, yes.

This is essentially just a contingency that I think needs to be stated, but might never be needed.

> > Additionally, I propose dropping the TLSCiphertext.version field entirely.
> 
> I suggest doing that separately as its own proposal.

Yep. Just bringing it up here too.

> > 2) This method allows for non-continuous version support to be negotiated.
> >     (e.g. client supports 1.2, 1.3, 1.5; server without 1.5 can negotiate 1.3 instead of trying unsupported 1.4)
> 
> We don't need this.

If TLS actually puts out more iterations, then we do, and this could make negotiating more frequent iterations easier. If TLS 1.3 or 1.4 is the final version, then we don't.

For draft versions, though, it could really be useful. Think ALPN/NPN; HTTP/2 draft negotiation would not have worked very well without the ability to list multiple specific versions at once.

> > 3) Draft implementations would be easily negotiable using the same method as release.
> 
> That is a plus, but the added complexity on non-draft implementations
> is worse than the benefit.

Again, it depends on how long until TLS ends. If TLS intends to go up to 1.9+, then I think it's quite worth it. If TLS ends soon and everyone transitions to a TCP-replacement with a new security layer, then no, this could be too complex. To start, though, I decided to propose the full generic route.

> > 4) Client implementations are not encouraged to go back to the old habit of insecure fallback, nor rely on SCSV for TLS 1.3+.
> 
> Right. This is the primary motivation for moving
> ClientHello.client_version to an extension.
> 
> > 5) This could be used with TLS 1.0-1.2 as an alternative to SCSV that Microsoft could tolerate. They don't like SCSV as-is [3], and I tend to agree with their sentiment.
> 
> It doesn't seem worth making the protocol more complicated to
> facilitate performance optimizations of bad behavior.
> 
> > 6) In the event of handshake failure due to an unsuitable version selected by the server, the client will have received a SupportedVersions set from the server to know exactly what is and is not supported.
> 
> Only if the client is negotiating TLS 1.4 or later and the server
> supports at least TLS 1.3. IMO, not worth it.

Again, it depends on how much further TLS actually goes. Draft versions could also benefit more.

> Anyway, I support your proposal, if it is simplified.

If simplified to just a move of the field, I'd be more likely to propose just coordinating a block of the ~1.6% of the Internet that can't negotiate properly and keep the old mechanism. The only reason I agree a simplified version of this could be needed is that I don't believe implementers have the guts to do this properly. :/

A notable part of the Web really does warrant breaking, but nobody wants to do it.


Dave