Hiya,
On 15/03/2024 21:55, Watson Ladd wrote:
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?
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 TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls-- Astra mortemque praestare gradatim
OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
