Re: Invariants draft

[Martin Thomson <[e-mail]>]

On Thu, Dec 7, 2017 at 6:56 AM, Spencer Dawkins at IETF
<[e-mail]> wrote:
> IIUC Roni's suggestion, I'm thinking that it's also worth adding information
> about why these invariants are invariant, in case we ever start arguing
> about taking an invariant away.

I can appreciate the desire for more detail, though the headline is
already there: we want to preserve the ability to deploy a new version
of QUIC.  The piece that is perhaps missing is one that Jana convinced
me to remove, namely the reasons for connection ID being in the draft.
Some of that is in the section on connection ID.

> I can easily imagine that some creative security person will, some day,
> think of some way that one of these invariants can be exploited to tell a
> third party something that the two endpoints didn't intend to share. If
> (when?) that happens, it would be good to have a clear understanding of the
> value of any invariant that's questioned, so we don't have to agree on that
> while we're trying to decide what to do, after an exploit is identified.

I worry less about exploitation of the invariants, but of the
not-invariants that we inadvertently expose by virtue of only
deploying a limited number of versions.  All the stuff in the
appendix, basically.  And that is a list that I wish were shorter.