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

[Paul Hoffman <[e-mail]>]

On Jan 15, 2020, at 7:46 AM, Ted Lemon <[e-mail]> wrote:
> 
> On Jan 15, 2020, at 10:13 AM, Paul Hoffman <[e-mail]> wrote:
>> Any mechanisms that specify interactions between clients and
>> servers must provide the security properties expected of IETF
>> protocols, e.g., confidentiality protection, integrity protection,
>> and authentication with strong work factor.
>> 
>> Any mechanism whose understanding of the network and network services comes from interactions that were not cryptographically authenticated (such as DHCP and RA) cannot meet those requirements.
> 
> Rather than just deleting this text, which I agree is probably not what we want, how about fixing it?

Because I don't think we can get consensus on the fixed wording *for the charter*. I would prefer to have the consensus discussions for the documents themselves.

> Any specification must include a clear and thorough discussion of the privacy and security implications of using the method or methods it describes.  Methods where a mechanism that cannot be cryptographically validated for integrity or which do not provide a cryptographically validatable trust establishment mechanism will clearly describe the use case(s) in which such an override is thought to be needed, should have a clear applicability statement limiting the scope of the specification to those use case(s), and should clearly describe the risks and benefits of such a choice.

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.

> The first sentence is unnecessary since this is what is expected in the IETF anyway,

Fully agree.

> but it sets the stage for the sentences that follow.

...and thus is unnecessary.

>   The point of this is not to prevent the WG specifying methods that can’t be cryptographically validated for integrity and/or trust, but rather to make it clear that such a specification would not be in charter if it didn’t meet the stated requirements.

Again, we disagree here because I (and others) don't agree that such methods exist.

--Paul Hoffman