Re: [Add] [Ext] Updated charter proposal for ADD

[Paul Hoffman <[e-mail]>]

> On Jan 15, 2020, at 8:48 AM, Ted Lemon <[e-mail]> wrote:
> 
> On Jan 15, 2020, at 11:18 AM, Paul Hoffman <[e-mail]> wrote:
>> The first sentence is well-intentioned but does not usually lead to useful text in documents. The second sentence assumes that there are methods that can be cryptographically validated: as I said above, I do not believe they exist.
> 
> Of course such mechanisms exist.   The problem is that they can’t happen without some explicit trust establishment mechanism, which necessarily requires manual intervention.

Fair point. They exist but they cannot be used in the Internet as we know it. That's why I believe they are not worth mentioning in the WG charter.

> What I want to capture is that any mechanism that the ADD WG comes up with that doesn’t have a trust establishment mechanism doesn’t override a mechanism where trust has been established explicitly unless there’s some specific reason why that’s the right thing to do.  E.g., Tommy I think mentioned, and this is a use case I deal with regularly as well, that you might be connected to a network that uses a split-dns configuration where if you query a public resolver, you just won’t get an answer for some domain.  I think that there is a pretty strong motivation from some of the participants to support a use case for CDNs; figuring out how to do this seems like it would be very much worthwhile, even if such a mechanism doesn’t come with an explicit trust relationship.
> 
> I would expect that a trust establishment mechanism based on the ANIMA on-boarding process (IETF) or the Thread commissioning process (Thread Group) would also be cryptographically verifiable, since devices commissioned using either mechanism can in fact cryptographically validate that they are connected to a particular network; it’s not a big step past that to validating the resolver.  

In both those models, I believe, an individual specifies a source of trust and a public key for that source of trust. From that point forward, the source of trust can announce anything it wants; all that remains to define is an announcement format and expected communications paths. That seems fine.

> If course, for a device that doesn’t have any such configuration established, a simple DHCP mechanism or RA mechanism for getting opportunistic security is still very much worth doing.

Fully agree.

> That said, I think it is in scope for the WG to talk about configuration mechanism that require manual intervention and do establish cryptographically verifiable trust.   Do you disagree with that?   To me this seems like an important part of the problem space.

I strongly disagree with the second part of the first sentence "and do establish cryptographically verifiable trust", which is why I disagree with the inclusion of text in the charter that hints that this WG has any part in the setup of trust. In my view (which at least some others seem to share), either you have cryptographic trust to a source already set up (ANIMA, old skool secure DHCP, Some Vendor Says So, ...), or you have none and whatever you hear on the network can only be trusted by leap of faith. All proposals between those have historically led to ratholes, and thus I would like to leave them out of the charter.

--Paul Hoffman