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

[Peter Saint-Andre <[e-mail]>]

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/