Re: [Edm] Please review draft-iab-use-it-or-lose-it-01

[Martin Thomson <[e-mail]>]

On Sat, Jul 17, 2021, at 08:37, Toerless Eckert wrote:
> So put all the text about undesirable middleboxes into a separate section,
> including the conclusions about encrypted protocols, because i don't
> think the document has arguments about encryption applicable to b).

I just reviewed the document and while there is mention of the multi-participant problem in a few places, the only substantive pieces are a dedicated section on the subject (which I think is worthwhile) and a separate section that mentions cryptography as a means of controlling participation.  I think that it is OK as it is.
 
> I think you are contradicting yourself.
> 
> Yes, the IP version field is indeed maybe the most easily reached
> extension point across the examples given. And IMHO we do not
> need to invent New IP Versions regularily just to keep the
> extension point greased (although i think there are other good
> reasons to do so, but thats a different discussion, happy to
> point you to a draft of mine for that too if there is interest ;-).
> 
> The example problem with the IP version extension point was
> one of c) - unplanned middleboxes. 

Routers are not unexpected protocol participants in IP.  What was unexpected there was that routers were forwarding v6 packets without understanding any of their contents.

Maybe this is a problem with approaching it from the perspective of the number of participants.  The key point is that other participants might not allow extension, regardless of how many participants there are.  The corollary is that more participants increases the chances that extension is blocked by a participant.  The supporting observation is that sometimes there are more participants than you might have expected.

I think that's a clean argument construction.

The unexpected participation observation doesn't really apply to the IP version example as you have to expect that every router on path needs to participate.  The >>2 corollary applies in full though.

> The more fundamental reason for this proposed characterization
> of some metric for difficulty of extension points (depth inside
> state machinery) is of course experience from testing suites and code
> coverage measurements. The deeper the extension point in the state
> machinery, the more code in the suite you need to get it covered.

I don't think that necessarily holds.  When we built QUIC, one of the most difficult pieces of code to build is the transport parameters.  It's right at the end of a long sequence of things that you need to get right with a bunch of interactions between encryption levels, transport stuff, TLS internals, and 0-RTT interactions.  It's about as deep in the state machine as I have ever experienced in building protocols.

QUIC transport parameters are nonetheless pretty completely reliable as a means of extending the protocol.  Maybe it's just because it is early days, but my belief is that it is the fact that we already have lots of uses of extensions that rely on them: https://github.com/quicwg/base-drafts/wiki/Temporary-IANA-Registry#quic-transport-parameters

On Sat, Jul 17, 2021, at 09:17, Toerless Eckert wrote:
> On Fri, Jul 16, 2021 at 06:06:17PM +1000, Martin Thomson wrote:
> > Just one note.  Throughout you mention authentication where the draft uses the word "cryptography".  My understanding of cryptography is that it encompasses a broad discipline that includes encryption and integrity protection and authentication and a bunch of related things.  Are you perhaps reading that word with the narrow meaning of "encryption"?
> 
> https://en.wikipedia.org/wiki/Cryptography
>   "More generally, cryptography is about constructing and analyzing protocols
>    that prevent third parties or the public from reading private messages"

https://en.wiktionary.org/wiki/cryptography is a better match with my understanding:

> The discipline concerned with communication security (eg, confidentiality of messages, integrity of messages, sender authentication, non-repudiation of messages, and many other related issues), [...]