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, and that's probably out of scope for this draft. For discussion's sake, how about changing the MUST NOT to SHOULD NOT and adding a big "here there be dragons" to the text? I might prefer leaving it as-is, since we can always write a new RFC that defines how the automated translation can be done in a safe way. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. [email protected], or [email protected] _______________________________________________ certid mailing list [email protected] https://www.ietf.org/mailman/listinfo/certid
