Re: [TLS] Application-Layer Protocol Settings

Hi David,

I think that there is an important difference between something that is hard to realize in practice (as many aspects of this clearly are) and using that to say that the fundamental protocol definition is wrong.

I appreciate - at least superficially - the complexities involved here.  Having implemented them, and having worked around many of the problems you have identified, it was not trivial to implement 0-RTT or 0.5-RTT (the latter was pretty-much trivial for much the same reason that false start works, but I'll concede that I probably didn't fully explore all of the potential problems).

But as much as recognizing implementation complexity is important, that doesn't necessarily translate into a requirement to change the protocol.

Let's take an example of a feature you are trying to negotiate in HTTP (/2 or /3).  I don't think that it is unreasonable to say to a client that it cannot attempt anything that depends on this feature until it receives SETTINGS.  You can then require servers that support this extension to send SETTINGS in 0.5-RTT so that the client is only blocked on the extra bytes and not additional round trips.  All of which implies that you need TLS 1.3 for the feature.

The drawback there is that the client that wants to use the feature might not receive the SETTINGS in time and they don't get a clear indication that this is not happening.  Ben's suggestion to use a new version if you care about avoiding that case is entirely appropriate.  It depends on what sort of extensions are being contemplated here to determine whether this is indeed necessary.  I tend to think a h2_tls13 ALPN that mandated use of 0.5-RTT for SETTINGS would put a big dent in this negotiation problem.

Either way, your stack might require new changes to support the writing of some fixed amount of data on all new connections.  This might turn into a requirement on TLS terminators to have per-backend configuration to support this new information.  But these don't necessarily turn into new protocol mechanisms.  Indeed, these changes are far less disruptive overall than a completely new TLS extension, particularly if the TLS extension involves all of the same coordination.

I concede that saying that SETTINGS is sufficient isn't free, and that there is some additional cost on implementations.  On the other hand, the "cost" is that implementations improve some aspects of an existing protocol that provide other benefits to those implementations.

On the other hand, new mechanisms like this require the same amount of coordination, more work at the TLS layer, and all the delays imposed by standardization.

On Wed, Jul 8, 2020, at 05:11, David Benjamin wrote:
> Hi Martin,
> 
> You’re right that this is closely related to half-RTT data. However, I 
> don’t think this is a no-op for HTTP/2.
> 
> I’m not aware of HTTP/2 clients that wait for the SETTINGS frame today. 
> Doing so costs a round-trip with servers that don’t send SETTINGS in 
> half-RTT, and there's no indicator for whether the server will send it. 
> I’ll see about testing some sites here and will report back, but I 
> expect most do not. We (correctly) designed TLS 1.3 as a drop-in 
> replacement for TLS 1.2, which means that we don't get to key new I/O 
> patterns on it. Half-RTT data is a very weird state and wouldn’t get 
> used by default. This is the problem with “no standards change is 
> required” style of thinking around simply changing I/O patterns. A 
> protocol is more than its wire image. Changing the I/O patterns is a 
> protocol change.
> 
> This means we cannot get efficient and reliable feature negotiation 
> today. Moreover, HTTP/2 servers today may send ServerHello..Finished 
> without application data in their first flight, so we need *some* 
> change to the TLS flight, be it ALPS or just some indicator.
> 
> Let’s look at what it’d take to make half-RTT SETTINGS work. We need 
> some “I will send half-RTT data, so you can safely wait for it” 
> indicator. Then the client needs to know when it is done waiting. We 
> could say it’s one SETTINGS frame, but that only allows integer values. 
> (Related: EXTENDED_SETTINGS 
> <https://tools.ietf.org/id/draft-bishop-httpbis-extended-settings-01.html> and discussion <https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0127.html>.) Those currently need separate frames, and one cannot wait for the absence of a frame. Maybe we need an HTTP-level SETTINGS_WILL_SEND_HALF_RTT_XYZ_FRAME indicator to keep the delimiter in HTTP, or a TLS-level “end of half-RTT data” delimiter. (Now consider how that works in QUIC...)
> 
> Next we need to tackle 0-RTT. Waiting for half-RTT data costs a 
> round-trip in 0-RTT, so we need something to persist across the 
> session, with semantics around mismatch and whatnot. (Another 
> TLS-visible change.) Anything persisted in the session must have 
> bounded size, and be delivered in something ordered with 
> NewSessionTicket.
> 
> If we place those bytes inside the handshake, we’ve reinvented ALPS. If 
> we place them outside, the NewSessionTicket ordering becomes complex, 
> especially in QUIC 
> <https://github.com/quicwg/base-drafts/issues/2945#issuecomment-519338186>. To your question about the server repeating its configuration vs. the client remembering it, I believe the issue was exactly that ordering mishap. ALPS avoids this because EncryptedExtensions and NewSessionTicket are ordered.
> 
> On top of this, the half-RTT point in a non-0-RTT connection is a weird 
> state. Not all connection properties (e.g. client certs) have been 
> established yet, and writes out of turn are tricky. This message 
> <https://mailarchive.ietf.org/arch/msg/tls/hymweZ66b2C8nnYyXF8cwj7qopc/> discusses some of the challenges here. I would argue something like ALPS is the settings design we should have had all along.
> 
> David
> 
> On Tue, Jul 7, 2020 at 1:10 AM Martin Thomson <mt@lowentropy.net> wrote:
> > Hi Victor,
> > 
> >  For HTTP/2, this is essentially a noop, as endpoints are required to send SETTINGS immediately. Whether these bytes appear before Finished or not only affects endpoints that aren't inclined to wait for SETTINGS. This is somewhat complicated by the way that TLS 1.2 and TLS 1.3 differ, but if we assume TLS 1.3 here, any uncertainty is easily avoided.
> > 
> >  The main justification here appears to be based on the lack of 0.5-RTT send capability at some servers. I don't know how to assess whether the cost of greater integration with the TLS stack is preferable to fixing the 0.5-RTT send problem.
> > 
> >  For HTTP/3, this has some incremental effect beyond that. In effect, this deliberately introduces head-of-line blocking for settings. You can already do that in HTTP/3 if you are not prepared to deal with settings being in an ambiguous state. There's a little more determinism here in terms of where you look for the data that unblocks progress, but with retransmissions, this is not a difference worth worrying about.
> > 
> >  What this head-of-line blocking might allow is the development of new extensions that are unable to deal with uncertainty regarding SETTINGS. But isn't it also possible to address that problem by saying "if you implement extension X, then you MUST NOT send requests prior to receiving SETTINGS?"
> > 
> >  In QUIC, we decided that having the server repeat its configuration after 0-RTT was preferable to remembering it. This was after a non-trivial number of questions about that part of the specification. You seem to have taken the opposite approach. Is that deliberate? If so, why?
> > 
> >  On Tue, Jul 7, 2020, at 05:12, Victor Vasiliev wrote:
> >  > Hello TLS and HTTP working groups,
> >  > 
> >  > (QUIC WG bcc'd as this has been discussed there before)
> >  > 
> >  > Currently, we use SETTINGS frames as an extensibility mechanism in 
> >  > HTTP/2 and HTTP/3. The SETTINGS frame is sent at the very beginning of 
> >  > TLS application data; this approach, while simple, has some drawbacks. 
> >  > The most notable one is that when SETTINGS are used to negotiate 
> >  > extensions, there is an entire round-trip where the client can send 
> >  > requests, but doesn't know yet about any server extensions, thus making 
> >  > any extension-dependant requests take an extra RTT.
> >  > 
> >  > The proposed solution to this problem is to move HTTP SETTINGS frame 
> >  > into the TLS handshake. Here are some issues where this has been 
> >  > discussed before:
> >  > * https://github.com/quicwg/base-drafts/issues/3086
> >  > * https://github.com/quicwg/base-drafts/issues/3622
> >  > * https://github.com/WICG/client-hints-infrastructure/pull/30
> >  > I wrote up a draft for the TLS extension that would solve this problem: 
> >  > https://tools.ietf.org/html/draft-vvv-tls-alps-00
> >  > 
> >  > I also wrote up a draft that explains how to use that extension with 
> >  > HTTP, and defines some settings (the ones discussed here 
> >  > <https://github.com/quicwg/base-drafts/issues/3622>) that would not be 
> >  > possible without it: 
> >  > https://tools.ietf.org/html/draft-vvv-httpbis-alps-00
> >  > 
> >  > I would appreciate feedback on those drafts.
> >  > 
> >  > Thanks,
> >  > Victor.
> >  > _______________________________________________
> >  > 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

Received on Wednesday, 8 July 2020 01:28:47 UTC