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

[Matt McCutchen <[e-mail]>]

On Fri, 2010-09-24 at 17:11 +0200, Martin Rex wrote: 
> Matt McCutchen wrote:
> > 
> > On Thu, 2010-09-23 at 03:48 +0200, Martin Rex wrote:
> > > 
> > > Thinking about it, I feel slightly uneasy about some redirects, such as
> > > https://gmail.com  -> 301 ->  https://mail.google.com/mail
> > 
> > The point from the draft was about a service that maps source domains to
> > target domains.  A HTTP redirect is different: it is an instruction to
> > restart the process with a new source domain.
> 
> 
> Admittedly, the processing of redirects happens at application software
> layers higher up the stack and for seperate TLS handshakes, whereas
> server endpoint identification is performed for a single TLS-Handshake
> directly above TLS.  But that does not mean that there is no security
> problem.

OK, so you are alleging a security problem that is unrelated to the
provision in server-id-check for name-mapping services.

> I'm trying to describe this behaviour in real world terms, maybe
> it becomes clearer that way.
> 
> 
> The current "server endpoint identification" would mean for the
> real world that you perform the matching when you enter the
> building (a store, gov. agency, bank, hotel, ...), and from
> that point on, blindly trust everything what happens to you.
> 
> Now imagine a subsidiary of Western Union on an exceptionally
> busy time of the day with several people waiting in line
> waiting to arrage for a money order with cash they're carrying.
> 
> Someone approaches a customer waiting in line and tells him
> that they've set up an additional teller in a camping truck
> across the street where they can place their money order.
> The browser behaviour, to blindly following 301 to other
> servers without second thoughts is a serious security problem.

This is a false analogy.  In the Western Union building, it's expected
that there may be other people you don't necessarily trust.  But on
https://gmail.com, assuming your browser and the server are designed
properly and the trusted CAs don't mess up, there is no way for an
attacker to introduce a redirect that is not authorized by the
registrant of gmail.com.

> The "secure link" between the end users intention (who supplied
> https://gmail.com) and what the browser actually does
> (blindly follow the redirect to https://mail.google.com) is missing.

A user who visits https://gmail.com with a modern browser intends the
browser to do whatever https://gmail.com says, which in this case is to
follow a redirect. 

> The reference identifier that is passed into the server endpoint
> identification for the TLS handshake performed with https://mail.google.com
> results from an untrusted name transformation, and this
> is very relevant for the security considerations of this I-D.

I'm not sure what kind of trust you were expecting here, but the
transformation is authorized by https://gmail.com, so there is no reason
the user shouldn't trust it for the purpose of interacting with the
service she knows as https://gmail.com .

It's true that the security considerations section of the draft states,
"When the connecting application is an interactive client, the source
domain name and service type MUST be provided by a human user", but I
think that is pretty bogus.  HTTP redirects in a web browser are one of
many cases in which using a source domain from a source other than the
user is the expected behavior.  These cases are not going to go away
with the publication of the standard.

I would prefer to limit the scope of server-id-check to what happens
after the source domain is provided (e.g., as an argument to an API call
of the client library) and simply emphasize that a conformant client is
only as secure as the source domain it is given.  In a larger
application, it's necessary to ensure that the manner in which the
source domain is obtained meets the user's security expectations, but
that's something to address in the documentation or standard for the
application.

-- 
Matt