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

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

On 9/15/10 12:30 PM, Jeffrey Hutzelman wrote:
> --On Tuesday, September 14, 2010 05:39:40 PM -0400 Barry Leiba
> <[e-mail]> wrote:

<snip/>

>> -- Page 21, sec 4.6.3.1, security note:
>>       caution, for example by first encouraging the user to terminate
>>       the connection, forcing the user to view the entire certification
>>       path, and allowing the user to accept the certificate only on a
>>       temporary basis (i.e., for this connection attempt and all
>>       subsequent connection attempts for the life of the application
>>       session).
>>
>> Same comment as for 4.6.2.  Most users will not understand certificate
>> problems, and will have no idea what they should do about them.
>> Always remember the "Barry's mother problem".  My mother will *never*
>> want to see an "entire certification path", let alone appreciate being
>> "forced" to.
> 
> In fact, I see two problems with the quoted advice.  First, since we're
> talking about a certificate name mismatch, the rest of the certification
> chain really isn't relevant.  It would be if the problem were a chain
> that doesn't lead to a suitable trust anchor, but that's not what this
> document is about. 

For context, the "quoted advice" is mostly a description of current
usage in some existing user agents. Incorporating Barry's suggestions,
that text currently reads as follows in our working copy:

      Security Note: Some existing interactive user agents give advanced
      users the option of proceeding despite an identity mismatch.
      Although this behavior can be appropriate in certain specialized
      circumstances, in general it ought to be exposed only to advanced
      users and even then needs to be handled with extreme caution, for
      example by first encouraging even an advanced user to terminate
      the connection and, if the advanced user chooses to proceed
      anyway, by forcing the user to view the entire certification path
      and only then allowing the user to accept the certificate on a
      temporary basis (i.e., for this connection attempt and all
      subsequent connection attempts for the life of the application
      session, but not for connection attempts during future application
      sessions).

Your document editors will take up this issue during our discussion of
open issues with the spec.

> That said, Barry, your mother is not an "advanced
> user" in the sense intended by this document, and should never even be
> given the option to accept a certificate that doesn't validate.
> 
> The second issue is the advice that the user should be allowed to accept
> a certificate with a mismatched name only on a temporary basis.  This is
> almost certain to be the wrong thing to do; if a name mismatch is
> acceptable, it's also not likely to change anytime soon, and requiring
> the user to accept the certificate again in a later session just because
> the client has restarted is just annoying with no security benefit.

That's an interesting point. In feedback we received from implementers
of interactive user agents (most browsers), we heard that at least some
user agents do enforce a distinction between accepting an identity
mismatch temporarily and accepting it permenantly. The security
properties of that distinction did not come up in previous mailing list
threads about this I-D, but your editorial team will do a bit more
research and might return with proposed text changes.

> If we were talking about path validation rather than server naming, I'd
> point out that accepting a certificate only temporarily doesn't give you
> the benefit of being able to detect future changes, and so actually
> _reduces_ security.  With names, this isn't a big deal, as it's
> relatively easy to decide whether foo.bank.com and foo.attacker.org are
> the same or not (well, unless the bank and attacker have the same name).
> 
>> -- 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?
> 
> I don't think it does.  If a user is running a gumbo client, I think
> it's implied that he meant to talk to the gumbo service.  But if he's
> running a web browser, the browser should not decide that the user meant
> to use the gumbo service by the presence of gumbo.example.com (or a
> corresponding SRV record) in the DNS, any more than it should assume
> from the presence of an alias www.example.com => gumbo.example.com that
> gumbo.example.com is an acceptable server name when the user typed
> www.example.com.
> 
> 
>> 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?
> 
> Again, I think this is fine; the client defines the lack of a
> user-specified name to mean something specific.  What's not fine is to
> take the name given by the user and apply an insecure translation such
> as an unprotected DNS lookup.
> 
> I think the advice in this paragraph is a little over-restrictive.  What
> should be prohibited is not automated rewriting, but automated rewriting
> based on the use of insecure sources.  RFC4120 has the following to say
> on this subject, as it relates to Kerberos:
> 
> 
>   One can also rely on trusted third parties to make this
>   determination, but only when the data obtained from the third party
>   is suitably integrity-protected while resident on the third-party
>   server and when transmitted.  Thus, for example, one should not rely
>   on an unprotected DNS record to map a host alias to the primary name
>   of a server, accepting the primary name as the party that one intends
>   to contact, since an attacker can modify the mapping and impersonate
>   the party.

Thanks for the pointer to RFC 4120. We're looking into how to
appropriate reference that in the next version of this spec.

>> 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.
> 
> Not if the client does so by rewriting "gmail" as "www.gmail.com",
> looking that up in the DNS, and using the target of the resulting
> alias.  Most web browsers already get this right, thankfully.

Again, we agree with you that secure service delegation is outside the
scope of this I-D, as we expressed in our reply to Barry's review.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/