Re: [TLS] should we say anything about ECH in the face of fragmentation?

[Stephen Farrell <[e-mail]>]

Hiya,

On 15/03/2024 21:55, Watson Ladd wrote:
> On Fri, Mar 15, 2024 at 2:23 PM Stephen Farrell
> <[e-mail]> wrote:
>>
>>
>> Hiya,
>>
>> I think the outcome here is maybe most likely to do nothing but
>> since the WGLC is ongoing I figured it best to bring it up in
>> case others have better ideas.
>>
>> I got a mail yesterday from someone who had played with the nginx
>> "stream module" setup ECH-split-mode PoC stuff we've done and found
>> a difference in how IP fragmentation affected that configuration,
>> depending on whether or not ECH was enabled.
> 
> I am very confused here. Is this over TCP? 

Yeah, sorta, but...

TBH  I only looked at how to get ECH split-mode decryption working but
IIUC the nginx stream modules enable examining packets for load
balancing so that the TCP (and TLS) session ends up between the client
and back-end. So in that mode, nginx (or haproxy similarly) is mostly
looking into the 1st packet seen, maybe for a CH with an SNI, and
then uses what it finds to route the packet to some back-end. It
(nginx) then also sets itself as a proxy between the client and
server for remaining packets in the connection.

If the 1st packet has an outer CH then we can attempt to ECH decrypt
that and then do whatever nginx would've done in stream-mode and that
does work.

I never did look at what else nginx does at the IP or TCP layer,
once I got stuff to work, but I suppose I should, to do it right.

Handling split-more + HRR was even more fun so I'd not be surprised
if IP fragmentation caused issues there too.

All that said, I'm still not sure that even attempting to support
split-mode ECH in the face of IP fragmentation would be a good plan
though.

Cheers,
S.

> If so, why isn't the MSS
> preventing IP fragmentation? Is this in QUIC?
> 
>>
>> The pcaps I've seen show fragmentation of the CH after 588 octets.
>>
>> In the ECH-using case, nginx aborts the connection as it sees a
>> malformed outer CH. In the non-ECH case, nginx can decide how to
>> forward the packets as it can decode into the partially rx'd CH
>> and see the SNI (which is what's used to decide where to fwd the
>> connection). I don't (yet) know what'd happen if fragmentation
>> happened in the middle of the SNI in the non-ECH case. (I'd bet
>> it'd not be good though:-)
> 
> This sounds like an NGINX bug/misfeature. How the data ends up on the
> wire below TCP shouldn't affect what happens beyond e.g. timing out.
> 
>>
>> The reason for the difference is relatively obvious but I guess
>> could be stated in the draft: an ECH split-mode front-end can't
>> decrypt the ECH until it's seen the entire CH, due to the use of
>> the ClientHelloOuterAAD as aad.
>>
>> I've not yet thought about whether it'd make sense to try to
>> buffer up partially rx'd fragments to see if those eventually
>> do turn out to be a nicely encoded outer CH - I suspect that
>> may be more of a footgun than useful;-(
>>
>> I think all the exact same things would happen with our haproxy
>> split-mode PoC, so this isn't an nginx specific issue.
>>
>> Cheers,
>> S.
>>
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
> 
> 
> 
> --
> Astra mortemque praestare gradatim