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

[Toerless Eckert <[e-mail]>]

On Mon, Jul 19, 2021 at 10:03:30AM +1000, Martin Thomson wrote:
> 
> 
> 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 stand by my suggestion for better structurin by categorization of cases,
such as with unplanned middleboxes.

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

  "IP's version field was
   rendered useless when encapsulated over Ethernet, requring a new
   ethertype with IPv6 [RFC2462], due in part to layer 2 devices making
   version-independent assumptions about the structure of the IPv4
   header."

Aka: yes, routers are not unplanned middleboxes, but in -04 you wrote about
layer 2 devices, not routers. Btw: A pointer or more elaboration about that
incident would be nice, because i do not remember this type of incident with
L2 devices.

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

Indeed. And "participant" again has multiple aspects:
 - how many participants are allowed in a protocol communication
 - how many implementations are there
 - how many versions of implemenations are there
 - how many different operators deploy a subset of the participants

In IP for example, the upper bound of participants in a communications
is arguably 255 (TTL expiry of a packet), but the total number
of implementations * versions * operators is much much larger.

And this doesn't take into account unplanned participants.

> I think that's a clean argument construction.

Right. And my explanation above was trying to show a worst-case example
of why the number of participants alone isn't even an upper bound for the
complexity of the problem when you have a popular, widely implemented/deployed
protocol. 

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

Can't well comment as i do not know QUIC, but if there was something like a decision
tree over the extension poins with probabiliies on reaching any leaf based on
practical experience with deployments, then i wold not be surprised if many
leafs have a 0% probability to be reached in todays actual deployments,
and those leafs of course are the mayor concerns if/when they would get used
in the future.

Cheers
    Toerless

> 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), [...]

-- 
---
[e-mail]