Re: [TLS] Connection ID Draft

["Fossati, Thomas (Nokia - GB/Cambridge, UK)" <[e-mail]>]

Hi Martin,

On 17/10/2017, 00:42, "Martin Thomson" <[e-mail]> 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