Re: [quicwg/base-drafts] Change connection ID with Transport Parameters (#1041)

[Martin Thomson <[e-mail]>]

It's possible to use the declarations in transport parameters to effect negotiation, sure.  If I declare feature A and you do too, then it's safe to assume that using feature A won't cause problems.  I'd say that we probably need that for - for example - changing the ACK frame format to support new information.  And calling that negotiation isn't a stretch.  Right now, we don't have anything that negotiates and the text reflects that.

As for NEW_CONNECTION_ID, sure, an attacker can insert a connection ID.  The likely effect is to cause packets to be routed incorrectly, likely disrupting the handshake.  We've agreed that if an attacker is able to disrupt the handshake to this degree, then we're not going to try to stop them.  An attacker with that capability could also choose to block the handshake or tamper with it in other ways that would cause failure.  If the concern is misrouting, they could easily rewrite the connection ID.

If the server is able to (maybe because it didn't use the connection ID) and decides to accept the incorrectly-marked packets, then it just became complicit and I'm not sure that we need to worry about that.

One thing that I was wrong about here was that transport parameters are available to a client because the TLS handshake is complete.  There's a nasty race condition there though.  The handshake is really only complete once the client has sent its last flight, and that means using handshake packet protection keys, but using transport parameters from the completed handshake.  It's rather awkward.

We would also need to be clear about what connection ID is used for Handshake packets that the client sends when there is packet loss and it has to acknowledge server Handshake packets.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1041#issuecomment-356489098