On Fri, Mar 15, 2024 at 2:23 PM Stephen Farrell
<stephen.farr...@cs.tcd.ie> 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? 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
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls



--
Astra mortemque praestare gradatim

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Reply via email to