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

[Ted Lemon <[e-mail]>]

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?

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 unnecessary since this is what is expected in the IETF anyway, but it sets the stage for the sentences that follow.   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.