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 _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
