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. > Yes, I think the answer is "do nothing". TLS assumes that TCP correctly delivers and sequences packets. There are a number of situations in which the packet can be a size greater than 588 octets, and implementations simply need to handle those correctly. -Ekr > 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. > > 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:-) > > 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 >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
