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

[Mirja Kühlewind <[e-mail]>]

Hi Martin, hi all,

I agree with the main point this document makes which is only using a versioning mechanism actively helps to avoid ossification. And reading through the doc, I also thought that maybe we should recommend to have a versioning plan while developing the protocol (as you say below is under discussion for TLS). However, thinking further about it and given were TLS is right now, I have the feeling that we really don’t have enough experience to make a recommendation here. So I wonder, should we maybe rather try to just document what we have experienced so far and not even try to give a recommendation, or it that not what we want in the StackEvo program?

Mirja



> Am 03.08.2018 um 10:03 schrieb 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.)