Hi Martin, On 17/10/2017, 00:42, "Martin Thomson" <martin.thom...@gmail.com> wrote: > Thomas mentioned a heuristic, but I don't think that we need that. > The only case that is difficult, and it's one that you might not care > about, is one where a connection migrates to the same 5-tuple as an > another connection. There, you will match to an existing connection > and find that the packet doesn't decrypt. If the connection that you > have associated with the 5-tuple supports and uses a connection ID, > you can recover without trial decryption. Otherwise, you just have to > drop the packet when it doesn't decrypt. (You could look up all the > connections without connection IDs and use trial decryption, but why > bother spending the effort and undermine the strength of your ciphers > in that way.)
The following case (NAT box reboot) is problematic: 1. Application '1' on host A (A.1) uses DTLS+CID with application '1' on host B (B.1); 2. Application '2' on host A (A.2) uses plain-old DTLS with B.1; 3. The NAT box reboots (all previous 5-tuple mappings are lost); 4. B.1 receives a record from A.1 (whose 5-tuple has changed in the meanwhile); How is B.1 supposed to correctly interpret the bytes starting at offset +11? (For what it knows, it could be CID from A.1 or the length field from A.2.) That's where the heuristic I mentioned in the other email comes in, I think. > Packet inspection boxes will have maintain state, I don't see a way > around that. The point here being that you need state to know how > long the connection ID is, as well as how long it is. I might be missing something fundamental here, but isn't the length encoded in the CID field on the wire? Cheers _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
