Clarify interaction with DTLS 1.3

[davidben]

The draft claims to work with DTLS, but it's slightly ambiguous. We use ClientHello structures directly in ECH structures, but ClientHello is one of the structures that DTLS changes. Do we use the DTLS version or the TLS version? The differences are:

1. The legacy_version field is hardcoded to a different value.
2. There is a goofy legacy_cookie field.

The goofy legacy_cookie field is interesting. In principle, it should really should get the same treatment as legacy_session_id and be copied over, because there's nothing to hide there. But I think it's actually always empty, since HelloVerifyRequest is banned in DTLS 1.3. But then we probably need to answer dumb questions like:

1. What happens if a client sends an ECH-ful ClientHello and gets HelloVerifyRequest back?
2. What happens if a server receives an ECH-ful ClientHello but the legacy_cookie field isn't empty?
3. Do we have injectivity problems allowing the two ClientHellos in there? I think we're fine, because legacy_version distinguishes the two ClientHellos but, ugh, why oh why did we do this in DTLS??

Not terribly difficult, but it's ambiguous enough that I think we need to say something here. My inclination is to say that we use the DTLS ClientHello, and pick the least annoying answers for (1) and (2). But I think we do need to write them down somewhere.

[sftcd]

Urgh (I've not looked at ECH for DTLS at all). Could some or most of this be deferred to the upcoming work on a DTLS bis RFC?

[davidben]

I think we need to do something here, because the draft as-is says DTLS works. Whether that's a minimal fix, or temporarily saying that this is TLS- and QUIC-only, and fixing it in another document, I have no opinion.

[davidben]

This was, of course, brought to you by "oh yeah, I tried turning more of our DTLS tests on now that we're nearly done with our DTLS 1.3 implementation and noticed it was off". 😄

[richsalz]

Yes, please clarify that this is TLS 1.3-only

[sftcd]

Yes, please clarify that this is TLS 1.3-only

That'd work for me fwiw. ECH for QUIC/DTLS is a fine thing for 2025:-)

[davidben]

Correction: ECH for QUIC already works just fine and is already implemented. (If it didn't, HTTPS could not use it. If we force deployments to pick between ECH and QUIC, people are not going to pick ECH. It's important to let them pick both.)

[davidben]

@martinthomson did you all make it work in DTLS 1.3 when you implemented ECH? If we wanted to just fix it here, I suspect it would only take like 3-4 sentences. Ours doesn't work yet, but it'll probably just be like a days worth of fiddling to get it to work.

[davidben]

Thinking about this some more, I think there are natural answers here:

Do we use the DTLS version or the TLS version?

Given the TLS version has ProtocolVersion legacy_version = 0x0303; in it, I think the DTLS version is more straightforward? But I could go either way.

This does need some text, but just like one sentence saying which one we picked.

What happens if a client sends an ECH-ful ClientHello and gets HelloVerifyRequest back?

So there's a few questions to answer here:
a. How does a split mode server deal with a backend server sending it? I mean, this should not happen and the connection will blow up, same as a TLS 1.2 ServerHello, but I think this text is fine as-is.
b. How does the client reply? Does it recompute the ECH extension? This is the same as the PSK binders problem. I think we can probably just leave this strategically ambiguous until 9147bis fixes it properly.
c. How does the client complete the handshake? No text needed, it's just the same as any other TLS 1.2 handshake; client completes the handshake with ClientHelloOuter and does its thing.

What happens if a server receives an ECH-ful ClientHello but the legacy_cookie field isn't empty?

Nothing special, no text needed. Same thing that happens if the server receives an ECH-ful ClientHello where legacy_compression_methods contains random stuff. If it's in ClientHelloOuter, I guess we'll bind it into AAD but otherwise probably ignore it. If it's in ClientHelloInner, the ECH processing code will not care, but the actual handshaking code will then reject it.

---

Given that, I would suggest, if we can answer the first question in like O(days), let's just do that and avoid the fuss. Since it doesn't really matter either way, I think we can just pick one, informed by what existing implementations, if any (NSS is probably the only possible implementor), might have done. Otherwise punt it to later.

[richsalz]

I am fine with TLS1.3+QUIC only. Unless we can show that adding DTLS doesn't delay the doc.

[sftcd]

+1 for not delaying. That said I've not looked at OpenSSL DTLS code, so am almost certainly ok with any resolution of the issues above (so long as that doesn't take time).

[davidben]

Here's some draft spec text for what I suspect is the straightforward fix: #640

[martinthomson]

The rules for DTLS are pretty simple:

1. If you get a HelloVerifyRequest then you don't have DTLS 1.3. HelloRetryRequest works just like TLS.
2. legacy_cookie is included in the handshake, but it is left empty always, as defined in DTLS 1.3. If non-empty and DTLS 1.3 is present, then the handshake fails, as defined in DTLS 1.3 (with illegal_parameter in case you were wondering).
3. The transcript is ugly, but that's ECH for you. I don't understand this concern.

[davidben]

Oh, I'm thinking of a deployment that uses the same keys for DTLS and TLS ECH and whether we have cross-protocol problems between the two ClientHello syntaxes. But I think it's broadly fine because of those first two bytes. (Possibly we should eventually say that TLS and DTLS enforce the high bit to be really sure but whatever.)

[martinthomson]

I see. As long as the protocols have different versions, that helps. Though the addition of fields (legacy_cookie) makes any analysis along those lines fraught. I think that it helps that the value is fixed (it's a zero byte always), but I'm not really capable of reasoning that through right now.

[davidben]

Another source of ambiguity: we cite a section of RFC 8446 for HKDF-Expand-Label, but then RFC 9147 replaces HKDF-Expand-Label with a different function. Does that apply to ECH too? I assume so but we probably need a sentence to say it explicitly.

Why do we keeping doing this to ourselves? We should have picked a domain separation strategy that didn't cause an ambiguity in every TLS extension we ever write that calls HKDF-Expand-Label.

[davidben]

Another source of ambiguity: we cite a section of RFC 8446 for HKDF-Expand-Label, but then RFC 9147 replaces HKDF-Expand-Label with a different function.

#641 does the minimal thing here, but we really made a mess of HKDF-Expand-Label in RFC 8446. Implicitly including a "tls13" prefix was a mistake.