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

[Brian Dickson <[e-mail]>]

On Fri, Jan 17, 2020 at 7:16 AM Patrick McManus <[e-mail]>
wrote:

> Discovery requires authentication - otherwise the encryption is just snake
> oil security. everyone wants to apply policy (even if the policy is
> 'unfiltered') and you can't deliver that policy without authentication. And
> you can't seriously offer confidentiality without authentication either.
> The proposed charter is clear on this. A charter that allowed the creation
> of a an unauthenticated "secure" protocol in 2020 would fail to recognize
> what is possible and really ought to be irrelevant.
>

The scope of the proposed charter extends beyond exclusively public
resolvers and exclusively web browsers, at least as I read it currently.

For the purposes of clarity, we should be careful about the scope of
statements such as this, for which I propose some alternate wording for
what you wrote.

E.g.:
"Use of discovered resources which have globally-scoped names requires
authentication of those names as part of the protocol being used."

I.e. authentication is a "must" IFF the name is an FQDN rooted in the
public DNS tree (as served via the IANA root zone).

(This would leave open the question of authentication in other
environments, which is important for use cases that have been discussed.
Obviously any work encompassing those use cases would need to clearly
document security and privacy implications of the mechanisms used for
authentication.)

There is a  separate issue is on how identity on public FQDN certificates
is authenticated, from a protocol perspective, in terms of what is
mandatory to implement (MTI), including dependencies.

(Again, this is specifically ONLY about the authentication of resolver
identities for establishing the TLS connection from client to resolver, and
does not relate to subsequent client behavior in any other context, such as
HTTPS generally.)

This relates to establishing a privacy-protecting channel from the client
to resolver, which arguably is much broader in scope than the privacy
attributes for a TLS connection to a single end-point on the WWW.

The open question is whether WebPKI (using some set of CAs) should be MTI,
or whether use of other validation mechanisms such as DANE TLSA records
anchored at the IANA DNS Root Trust Anchor should be MTI?

As a point of relevance, IETF standards achieve the greatest degree of
interoperability when all necessary parameters are published by (or managed
by) IANA. This includes the DNS Root Trust Anchor, and all of the protocol
parameter tables.

Similarly, at least for the non-CCTLDs, ICANN has an oversight and
contractual relationship with registries, and the accreditation of
registrars.

By contrast, neither ICANN nor IANA are directly involved (at least to my
knowledge) in the management or certification of CAs. For the specific
purposes of authentication for a "secure" protocol in 2020, is it
appropriate to "bake in" the role of CAs and the CA/B to the MTI aspects of
the protocol?

I think it is something that needs to be taken into consideration in the WG
charter.

Brian