Subject: [certid] fwd: jhut: Re: [secdir] secdir review of draft-saintandre-tls-server-id-check-09

From: =JeffH <[email-masked]>
Date: Thu, 16 Sep 2010 13:37:56 -0700

X-Mailer: exmh version 2.7.2 01/07/2005 (debian 1:2.7.2-18) with nmh-1.3
From: Jeffrey Hutzelman <[email-masked]>
date: Wednesday, September 15, 2010 11:31 AM
To: [email-masked]; 
[email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [secdir] secdir review of draft-saintandre-tls-server-id-check-09
Mime-Version: 1.0
Content-Type: text/plain

--On Tuesday, September 14, 2010 05:39:40 PM -0400 Barry Leiba
<[email-masked]> wrote:

 > Second, there's a mixture of "natural person" and "human user" in the
 > document, and my sense is that you mean the same thing by both.  If
 > you do, you should switch to one term (I prefer the latter; "natural
 > person" sounds odd).  If they're meant to be different, you should
 > make it clear what the difference is.

When I hear "natural person", I think "as opposed to corporation".  I'm
pretty sure that's not what's meant here, and I agree it sounds odd.

 > -- Page 21, sec 4.6.2:
 >    client MUST verify that the presented certificate matches the cached
 >    certificate and (if it is an interactive client) MUST notify the user
 >    if the certificate has changed since the last time a secure
 >    connection was successfully negotiated (where causes of change
 >    include but are not limited to changes in the DNS domain name,
 >    identifiers, issuer, certification path, and expiration date).
 >
 > I worry about this kind of advice.  It violates my rule that says,
 > "Don't ask the user a question that he's not qualified to answer."  Of
 > course, "notify the user" can mean a lot of things, but too many
 > clients will implement something like this with a popup that will be
 > meaningless to 99% of the people who use it.

In practice, this advice is meaningless, as the described situation cannot
happen.  This case happens only when "a natural person has permanently
accepted the certificate", which implies the presented certificate is the
same as the cached certificate.

I think what this section is trying to describe is a situation where the
user has permanently accepted _some_ certificate for the service in
question.  In this situation, the presented certificate should be accepted
if it matches the cached one, and should not be accepted if it does not.
In the latter case, the UI experience will not end up being noticeably
different from that of 4.6.3 -- the presented cert can be accepted
temporarily, permanently, or not at all, but someone or some policy has to
make that decision.

However, I think there does need to be a difference in how the user is
presented with a mismatched certificate for a service with an existing
cached cert as opposed to one without.  In a leap-of-faith model, you want
to accept a certificate for a previously-unknown service, but reject a
wrong certificate for an already-known service.

 > -- Page 21, sec 4.6.3, last graf:
 >    Instead, the client MUST proceed as follows.
 >
 > I like a colon there, instead of the full stop.
 >
 > -- 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.  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.

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 =3D> 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.

 > 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.

-- Jeff