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

[Brian Trammell (IETF) <[e-mail]>]

Back from holidays. Slowly digging out of the mailpile...

> On 3 Aug 2018, at 04:03, Martin Thomson <[e-mail]> wrote:
> 
<snip>

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

This reminds me a bit of some defensive computer architecture work done about a decade ago, that attempted to fix buffer overflow attacks by dynamically compiling executables to an encrypted instruction set, with the idea that the shell code would not decrypt to a valid instruction stream without a key. Applying this analogy to protocol design (where it seems to be a generalization of the TLS every six weeks approach), complicated sub-parts of the version number space would act in effect as encryption “keys” for the protocol’s codepoint and state transition space.

IMO the challenge here is to make sure that the cost of the complexity added is much less than the amortized cost of the complexity of dealing with ossification after the fact. The encrypted state/codepoint space idea is reductio ad absurdum: iirc the POC for the encrypted instruction set (basically valgrind-as-VM) made it into one of the top three security conferences because it only induced a four-order-of-magnitude performance penalty.

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

This is the main reason I’d like to see the document expand beyond TLS/H2-derived experience: I'm mostly convinced that version-negotiation-agility is a desirable protocol feature in its own right, but evidence that greasing's effect isn't just a property of the vagaries of how TLS 1.2 negotiation was supposed to work would be nice to have.

Cheers,

Brian

> 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.)
> 
> _______________________________________________
> Stackevo mailing list
> [e-mail]
> https://www.iab.org/mailman/listinfo/stackevo