Re: Invariants draft

[Spencer Dawkins at IETF <[e-mail]>]

Speaking with no hats ...

On Wed, Dec 6, 2017 at 4:44 AM, Roni Even <[e-mail]> wrote:

> Hi,
> I think that the document needs some more information about why these
> fields are invariants.
> For example, we can have a new version with a message type that will mean
> that the header format from the next message changes and the connection ID
> will be in a different position from the next message with higher packet
> number.  I assume that this is not something we want if there is a need to
> support routing based on connection ID by intermediary who will not support
> this new version. So if routing support is mandatory it will be good to
> mention it in this document.
>

I want to thank Martin for putting together version -00 of this draft. It's
already very helpful.

When I made the suggestion to progress work on invariants as a separate
draft, I was thinking that the problem that solves, is making it easier to
update QUIC specifications without simultaneously reopening the list of
invariants and/or arguing about adding to that list.

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

Again, wearing no hats.

Spencer


> Roni
>
> > -----Original Message-----
> > From: QUIC [mailto:[e-mail]] On Behalf Of Martin Thomson
> > Sent: יום ו 01 דצמבר 2017 06:10
> > To: QUIC WG
> > Subject: Invariants draft
> >
> > I've just submitted a personal draft that describes the invariants that
> I think
> > we agreed to in Singapore.
> >
> > https://datatracker.ietf.org/doc/html/draft-thomson-quic-invariants
> >
> > This is just me for the moment (though Jana and Mike were very helpful in
> > reviewing an even draftier draft).  It also assumes a few things about
> the
> > current drafts that aren't yet true, and may not even become true.  Don't
> > focus too much on the specific content of what is in or out, because
> that sort
> > of detail is easy to fix.
> >
> > More than content, I'd like to concentrate on the general approach and
> > scope.  My hope is that we can agree that those are more or less correct.
> > And then adopt the draft.  A draft like this should help address
> questions
> > people have been asking about what can and cannot change between QUIC
> > versions.
>
>