On 9/15/10 9:47 PM, Matt McCutchen wrote:
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.
Over a year ago, Alexey Melnikov suggested adding text along those lines
and somehow it got lost during the revision process. We'll add something
to that effect back to the spec. The text that Alexey suggested was
similar to text from RFC 4513, and you can see it in version -02 of
draft-saintandre-tls-server-id-check:
4. Before attempting to find a match in relation to a particular
presented identity, the client MAY map the reference identity to
a different identity type. Such a mapping MAY be performed for
any available subjectAltName type to which the reference identity
can be mapped; however, the reference identity SHOULD be mapped
only to types for which the mapping is either inherently secure
(e.g., extracting the DNS name from a URI to compare with a
subjectAltName of type dNSName or SRVName) or for which the
mapping is performed in a secure manner (e.g., using [DNSSEC], or
using a user-configured or admin-configured lookup table for
host-to-address or address-to-host translations).
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.
Wes Hardaker also raised this issue in his review. Jeff and I agree that
this is an open issue and are working to address it.
Peter
--
Peter Saint-Andre
https://stpeter.im/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf