Re: [TLS] Connection ID Draft

[Martin Thomson <[e-mail]>]

Going back to the start, it seems like there is an implied problem
with the draft in that connections with the identifier are hard to
distinguish from connections without.  Is that the main problem?

I can't see how an explicit marking helps.  If we admit the
possibility that some connections will not support this new feature,
then the recipient of packets is forced to identify those connections
by 5-tuple.  That's invariant.  Mixed deployments have some
challenges, but it's not completely unworkable.

My conclusion is that peers without connection ID support monopolize
the 5-tuple that they use, so that other connections can't migrate to
that 5-tuple.  They also cannot migrate to another 5-tuple.
Otherwise, things work out.

To reach that point, you have to realize that a mixed deployment has
to use 5-tuple as a primary key.  Packets that come in on a new
5-tuple are matched to connections opportunistically on what might or
might not be a connection ID.  If it is, then great (better make sure
you ask for the same length ID from all peers, or match on
prefixes...).  If it isn't, then the ciphertext will be read as a
connection ID, but even if it does identify a connection it will fail
to decrypt.

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.)

You can only truly dispense with the 5-tuple mapping if you can
guarantee that all of your clients support connection ID; at which
point you can drop that table and route on connection ID alone.

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.

The middlebox issue is somewhat more interesting.  If it is *your*
middlebox, then there might be a case for routing connections with a
connection ID differently.  Based on the above, I would have said that
it might be better to only deploy that sort of configuration when you
can insist on receiving a connection ID.  An explicit marking helps,
but the cost is pretty high if we care about saving bits.

My suggestion for the middlebox is to use a longer connection ID and
include a MAC inside the connection ID.  It ends up being a longer
connection ID than the one QUIC uses, but it would allow the stateless
routing middlebox to identify packets with and without a connection ID
without any explicit marking.  That doesn't require any change to the
design.



On Fri, Oct 13, 2017 at 10:13 AM, Eric Rescorla <[e-mail]> wrote:
> Hi folks,
>
> I have just posted a first cut at a connection ID draft.
> https://tools.ietf.org/html/draft-rescorla-tls-dtls-connection-id-00
>
> Comments welcome.
>
> -Ekr
>
>
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>