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

[Toerless Eckert <[e-mail]>]

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"

So yes, i would very much appreciate if authentication without encryption
is explicitly mentioned as an option to limited arbitrary interaction
with a protocol:

"In particular, one of the consequences of an unencrypted protocol is that any element on path can
 interact with the protocol."

I don't think anyone would consider that a protocol with authentication
but without encryption is covered by that sentence. Likewise:

"Cryptography can be used to reduce the number of middlebox entities that can
 participate in a protocol or limit the extent of participation.  Using TLS or
 other cryptographic tools can therefore reduce the number of entities that can
 influence whether new features are usable."

With TLS-1.3 having removed null encryption, that text too is leading toward
only considering encryption.

Cheers
    Toerless

> Cheers,
> Martin
> 
> On Fri, Jul 16, 2021, at 17:14, Martin Thomson wrote:
> > Hi Toerless,
> > 
> > Thanks for the review.
> > 
> > It's going to take me a little while to just read your email.  If there 
> > are specific items that you think need to be drawn out in particular, I 
> > would encourage you to open issues or new threads on just those.  It 
> > will be easy to lose things with an email this long.
> > 
> > I'm just going to reply to your meta-level comments here.  I might try 
> > to turn the rest of this into issues on the repository.
> > 
> > On Fri, Jul 16, 2021, at 01:46, Toerless Eckert wrote:
> > > I think it would be good to write that the problems an solutions likely
> > > fall all into three high level categories:
> > > 
> > > a) p2p protocol extension considerations.
> > > b) 3 or more party protocol extension considerations
> > >    (including middleboxes as supported parties).
> > > c) 2 or more party protocol considerations plus undesirable middleboxes.
> > > 
> > > Separating b) and c) is IMHO most important, 
> > 
> > I disagree.  The draft does acknowledge the fact that difficulty scales 
> > poorly as more protocol participants are involved, but this is not the 
> > focus of the draft at all.  The text exists to acknowledge that as a 
> > problem, but the core thesis is not that these are different but that 
> > they are _fundamentally_ the same.  The number of participants just 
> > scales the problem (often very quickly out of reach).
> > 
> > Your category (c) is almost out of scope.  The text on limiting 
> > unwanted participation is very narrowly focused here.  It only exists 
> > because it was necessary to point out that unprotected protocols can 
> > have more participants than expected and that - once the problem is 
> > identified - the most obvious solution seemed worth noting (not that it 
> > is always a *practical* solution, of course).
> > 
> > See also https://martinthomson.github.io/tmi/draft-thomson-tmi.html
> > 
> > > The other high-level suggestion is that at least in my opinion
> > > there is more that could be written about reasons.
> > > 
> > > IMHO: The deeper the extension point is within a protocol, and the
> > > more complex the protocols starte machienry reaction to
> > > unsupported extensions hs to be in the state machinery,
> > > the more difficult it is to make sure it will work correctly
> > > when needed. Of course, the most easy case is when you have
> > > extensible data structures signalled and some parts can
> > > just be ignored, but that is not always the semantic required.
> > 
> > I think that this is just a matter of degree.  Whether an extension 
> > point is hard to reach hasn't seemed to affect its availability in the 
> > cases we've gathered thus far.  It's whether people have been motivated 
> > to seek it and actively use it that has mattered.  It's not like the IP 
> > version field is hard to find or complicated.  And - not in the draft - 
> > arguably some of the extension points in SDP are harder to reach than 
> > others, but the hard ones (a=extmap) are often more reliable than the 
> > easy ones (RTP/SAVPF).
> > 
> > -- 
> > Edm mailing list
> > [e-mail]
> > https://www.iab.org/mailman/listinfo/edm
> > 
> 
> -- 
> Edm mailing list
> [e-mail]
> https://www.iab.org/mailman/listinfo/edm

-- 
---
[e-mail]