Re: [Stackevo] draft-thomson-use-it-or-lose-it

[Martin Thomson <[e-mail]>]

Thanks for reading Mirja,  Comments inline.

On Fri, Aug 3, 2018 at 12:42 AM Mirja Kühlewind
<[e-mail]> wrote:
>
> Hi Martin,
>
> I finally reviewed the doc completely and I really like the „use-it-or-lose-it“ message and the background explanations. However, I’m less sure about the migration techniques you propose (sec 4).
>
> First section 4.1. (Active Use), I think, could be more concrete: does it make sense to specify two versions in parallel just to use this mechanism? Or just make sure you actually have a plan to specify a next version soon. And does it also mean that you should not have a versioning mechanism if you don’t plan to specify another version soon?

I don't think that we know the answer to this question just yet.  So
I'm not confident in writing anything concrete.

I seriously doubt that deploying two versions from day 0 would be
effective.  There were cases of TLS extension points that shipped with
a small set of options, which ultimately ossified: though each of
those values would work, new values couldn't be deployed.  That
happened because the entire set remained unchanged over a fairly long
period.  Greasing revealed and ultimately fixed those, hence some of
the enthusiasm for that mechanism - but you might easily argue that
this was something that could be found by other means (and I would
agree with you).

TLS version negotiation is another example of this as well.  SSLv3,
TLS 1.0 through 1.2 could all be negotiated, but even attempting to
advertise TLS 1.3 caused enough things to break that deployment was
untenable.  And TLS version negotiation couldn't be greased.  Moving
to a new mechanism means that it can be greased now, but we don't know
how effective that will be.

So my guess is that shipping with any small N isn't effective.  What
we know is effective is continual addition of new values.  That plan
you have for v2 isn't useful until you ship v2.  And you don't know
that v3 can be shipped until you ship v3.  As long as N is small, I
don't think that you can ever be confident that N+1 will work.  I
don't know what the value of N is when you can be confident in the
success of N+1 either.  Maybe the only measure of defense is velocity
- any sufficiently stable target will be nailed down, but a moving
target evades capture.

There is talk now about shipping new TLS versions every few months.
Not major revisions, but revisions that rearrange the protocol in
different ways that exercise various capabilities that we might like
to preserve.  It's still essentially grease, so apply the same
skepticism, but the idea is that you can't just say that x&0x0f0f ==
0x0a0a is safe to ignore because everything changes.  For instance,
one change might add 13 to all extension codepoints, another might
reorder the fields in some messages.

> Then I’m really not sure about section 4.2. Maybe I’m just not a full believer in greasing but I really think it worked „well" for TLS because you used it as a mechanism to detect deployed brokenness afterwards. I really don’t think you will have the same result if you reserve something for greasing at the time of the first specification, because then people will implement this as an extra case (even if it would be easier to just implement the versioning mechanism correctly, because this is just how people work).

I tried hard to capture some of this skepticism, because I share your
view.  That it sort of worked for TLS isn't a great proof that the
general technique is effective.  As it says "Incorrect implementations
might still be able to correctly identify these code points and ignore
them."  I've added some more negative language as well :)

> Also section 4.3: I have the feeling that the middlebox problem is a bit a different question. It’s a good note to spell out that middleboxes are protocol participants (as done in section 2.2), however, explicitly only exposing what should be expose is rather the message of the path-signals and wire-image drafts and I think I would rather refer to these drafts instead.

I will do that.  That document had rather uncertain status when this
was first written.  That no longer true :)

> Not sure if section 4.4. should be rather an own section because it is something additional and not really a migration technique/design principle for protocols, is it?

It's a separate concept, but Section 4 is more broadly about
strategies, and while Section 4.4 isn't a strategy on its own, it's
complementary to the other strategies.  I've made this clearer in the
lead-in to prevent there from being any misapprehension about why that
section is there.  (I was originally going to put this with grease,
because it's so essential there, but it's really a separate
technique.)