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

[Jeffrey Hutzelman <[e-mail]>]

--On Tuesday, September 14, 2010 05:39:40 PM -0400 Barry Leiba 
<[e-mail]> 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 => 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