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

[Martin Rex <[e-mail]>]

Matt McCutchen wrote:
>
> 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. 

But what if he does not?  As if he had a choice.

The only intention that can be reliably deduced from a user supplying
an hostname as a target address, is that a user wants to "enter"
exactly _that_ site.  And server endpoint identification does nothing
else than a plausibility check whether the user is entering where
he asked to enter.

What you describe, and what web browsers are doing, appears to be a
pretty bold and unwarranted assertion about what the users intentions
must be "by using a modern browser" (I don't think that is a _new_ browser
behaviour).


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

This transformation is _NOT_ authorized by the user, so if anything
deserves a scary warning page, then it's this transition.

The user only said "enter that site", I do not think it is
appropriate for the browser to turn this into "go to that site
and totally enslave me".  Not everyone might be thrilled by
such conduct as much as you make it appear.


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

The intention of this is right on the spot, but it falls short.

The important part is that the reference identifier comes only
from a source that is trusted by the user or admin of the system,
which may be a local preconfiguration, a persisted prior target
(e.g. bookmark), or a configuration for a non-interactive client
software.

If all web-servers on the internet would enable TLS (which is what
Google has suggested), your line of thought would mean that everyone
will trust everybode else with everything on the internet, starting
with a https://www.google.com search.  Perfect world? You sure?


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

It is expected behaviour for HTTP.
Retaining such behaviour for HTTPS will wash most of the original
security down the drain.

>
> These cases are not going to go away
> with the publication of the standard.

Correct.  But "new/modern" browsers are so extremely buggy and
dangerous^W^W^Wfeature-rich and constantly enhanced that people
will quickly and eagerly upgrade to every new version
coming out (so I've been told).


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


Doing server-id-check for the sole purpose of labeling a software
as "RFCxxxx compliant" would be somewhat of a waste of IETF resources.

The original idea behind server-id-check was that the client software
could ensure that a users valuable or sensitive information is NOT
going to be sent to some other site than the one the user requested.

By disconnecting the server-id-check requested by the user from
the server identity to which the users data will actually be sent,
there is nothing much left in terms of security from the
original server endpoint identification (which, when based on
a software suppliers pre-configured list of ~100 trust anchors,
wasn't terribly strong to begin with).


-Martin