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

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Sep 2010 11:53:16 -0600

On 9/15/10 12:30 PM, Jeffrey Hutzelman wrote:
> --On Tuesday, September 14, 2010 05:39:40 PM -0400 Barry Leiba
> <[email-masked]> 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/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 22 Sep 2010 12:13:54 -0600

On 9/22/10 12:07 PM, Jeffrey Hutzelman wrote:
> --On Wednesday, September 22, 2010 11:53:16 AM -0600 Peter Saint-Andre
> <[email-masked]> wrote:
> 
> I have no issue with making that distinction, and indeed, many existing
> user agents do so.  I take issue only with the argument that user agents
> should disallow the "permanent" option in the name of "security", when
> doing so is in fact counterproductive.

I had not previously considered the point, but I think you're right.

> I'm not sure a reference is the best approach, since in fact we're not
> talking here about Kerberos and that might just be confusing.  But
> borrowing some of the language might be appropriate.

Yes, that's what I meant -- we shall probably engage in some creative
borrowing of the concept, which might be worded similarly or differently
(that's yet to be determined).

Peter

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

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Wed, 22 Sep 2010 14:07:28 -0400

-- Jeff

---

From: Martin Rex <[email-masked]>
Date: Fri, 24 Sep 2010 22:29:52 +0200 (MEST)

>       session, but not for connection attempts during future application

This whole paragraph is evil and completely wrong.

It's bad enough that the web browser crowds replaced a useful option
and important security feature with an extremely evil scary page.

The IETF should definitely not put this non-sense into a
BCP or standard.

Offering to end-users, in a single-time-only leap-of-faith approach similar
to what SSH has been successfully doing since its invention to memorize
the peers certificate is magnitudes more secure than the endpoint
identification linking to one of a hundred trust anchors, provisionally
preconfigured by your software supplier.

The IETF, its standards & BCPs ought to stand clear from
recommendations that impair the usability or incur additional cost
for using the TLS technology between components of home networks.

The scary-pages presented by newer Browsers and the UI suggestions
in the quoted paragraph amounts to turning the entire TLS technology
into "nagware" for commercial pre-trusted CAs.  The most recent
browser scary-pages are worse than most nagware.

I'm not intimidated on the initial install of my DSL-router,
neither when logging in to the webadmin page for the first time,
nor when configuring my WPA2-PSK key.  Why on earth am I intimidated
so badly when I activate TLS for the webadmin UI of my home NAS
and connect to it with my browser for the first time?

Can't we do better than specifying the use of HTTP over TLS instead
of HTTP-only to access devices on my home network should not be
allowed to users that are not "advanced", and even those must be
badly intimidated when they try?

Even when servers use server certs from commercial pre-trusted CAs,
the options for end users to manually confirm the server cert to
have it cached/memorized and verified on future visits will
significantly improve the security for the user, because it
protects from later subversion of (the issuing procedures)
of any of the thousands CAs signed by any of the hundred
preconfigured trust anchors as well as bugs such as the
OID-integer wraparound and NUL-character in Hostname.

-Martin

---

From: Robert Relyea <[email-masked]>
Date: Fri, 24 Sep 2010 15:00:46 -0700

> and important security feature with an extremely evil scary page.

No, this paragraph is exactly what should happen. Click through dialogs
are demonsterably useless. They train users to ignore them. The only
place for them is if you decide that validation is not necessary.
> preconfigured by your software supplier.
SSH is good for small numbers of point to point connections where the
user controls both sides. SSH model is not appropriate for the general
population connection to millions of webservers. That is why SSH is used
extensively in admin deployments (where the admin controls both
machines) and is not used for e-commerce. If you want that semantic use
SSH. If you want security for the masses, use SSL (with full PKI).

[ case where SSL is being used for an SSH use case deleted]

bob

---

From: Nicolas Williams <[email-masked]>
Date: Fri, 24 Sep 2010 23:22:17 -0500

> SSH. If you want security for the masses, use SSL (with full PKI).

It shall not surprise anyone that I don't quite agree with the above.
That is, I agree with the part about the pre-shared public keys (ssh
known_hosts files) not scaling (not even to a corporate network), and
the part about ssh leap-of-faith not being a great model (though you
were not that specific).  In particular, what PKI is this that you speak
of?  The PKI we have is not really.  Even leap-of-faith is better than
the "PKI" we have now.

The PKI we will have (DNSSEC) (one hopes) won't be a joke.  But even a
true PKI, with one root (or one root per-country or region of the world)
is not quite what we need -- though it just might well do well enough.

I would much prefer federated authentication mechanisms + channel
binding to TLS -- TLS is the secure transport that we have for HTTP, and
TLS is a decent enough secure transport, if you don't care about
authentication.  Yes, a combination of "PKI" (and "stickiness") may well
be part of how federated authentication mechanisms work, but even so,
the impact of "PKI" on the user agent and UIs would be minimized, and
that'd be a very good thing.

Nico
--