Re: [certid] Fwd: secdir review of draft-saintandre-tls-server-id-check-09

[Matt McCutchen <[e-mail]>]

On Wed, 2010-09-15 at 16:58 -0700, Henry B. Hotz wrote:
> On Sep 15, 2010, at 1:20 PM, Peter Saint-Andre wrote:
> 
> > -- Page 22, sec 5.1:
> >   When the connecting application is an interactive client, the source
> >   domain name and service type MUST be provided by a human user (e.g.
> >   when specifying the server portion of the user's account name on the
> >   server or when explicitly configuring the client to connect to a
> >   particular host or URI as in [SIP-LOC]) and MUST NOT be derived from
> >   the user inputs in an automated fashion (e.g., a host name or domain
> >   name discovered through DNS resolution of the source domain).  This
> >   rule is important because only a match between the user inputs (in
> >   the form of a reference identifier) and a presented identifier
> >   enables the client to be sure that the certificate can legitimately
> >   be used to secure the connection.
> > 
> > Does this mean that a client specifically designed for the "gumbo"
> > service can't automatically use the service type "gumbo", without the
> > user's involvement?  Or that a client put out by example.net can't
> > assume a host name of services.example.net in the absence of user
> > input that says otherwise?
> > 
> > Further, it's entirely reasonable for a program to have a user enter
> > something like "gmail", and have the client turn that into something
> > like "mail.google.com", deriving it from the user's input in an
> > automated fashion.  Do we really want to forbid that sort of thing?
> 
> 
> That strikes me as an awfully blase comment for a security review.
> Whatever process translates the user input into the name that's used
> to verify the server's id is a critical part of the verification.  If
> you can subvert the translation, then you can subvert the server ID
> check, which is the whole point of this draft.
> 
> I'm not opposed to the idea of name canonicalization, but it has to be
> done in an authoritative, secure fashion

Exactly.

> and that's probably out of scope for this draft.

Is it?  We may be able to make a useful general statement.  There are
two issues here:

1. "Authoritative": different applications and even users may have
different ideas of what name canonicalization processes are
"authoritative", so all we can ask of compliant implementations is to
document which processes they use.  "Profiles" of server-id-check may
fill in more details.

2. "Secure": given that the point of TLS is to protect against network
attackers, it makes no sense to use a name canonicalization process that
is vulnerable to them.  We can say, "Any process by which the source
domain is derived from user input MUST NOT be subject to subversion by
network attackers", or some such.

Tangent: I know we want to avoid implementations that do foolish things
being claimed as compliant, but IMO, the requirement that input come
from a "human user" is goofy for a technical specification and in
practice a non-starter.  A web browser that followed a HTTP redirection
to a https: URL would violate it.  The web has evolved toward complex
applications in which all pretense that the user is mediating the
issuance of HTTP requests has been abandoned, which brings major
productivity benefits as well as major security implications; ignoring
this would be a mistake.

-- 
Matt