I sense topic-drift and a rat-hole here.
I'm gonna try to put a concise box over the hole..
Martin replied:
>
> Matt replied:
>
>> Martin wrote:
>>
> 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.
>
> ...
>
>> > 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".
The redirect behavior you are complaining about is (as we all know) a core
facet of the HTTP protocol. Said protocol doesn't differentiate such behavior
based on whether it is running over secure transport or not. This is simply how
it works, for better or worse.
Also, generously cross-mapping domain names for administrative and user
convenience is a common practice.
From Google's perspective, the "name" gmail.com maps to mail.google.com, and
that's their decision to make since it's their web application they are
offering. Its probably more straightforward in their app code for all the app
URIs to use the authority component of "mail.google.com" rather than that of
whatever entry point (e.g. "gmail.com") the user selected (by whatever means).
Kudos to them for doing it all properly over TLS/SSL such that no errors pop up.
In any case, HTTP redirects are a fact, as are multiple (DNS) names for (web)
applications/services/servers/entities. "the Web" is built on both of these.
Doing it all over secure transport isn't *necessarily* different than doing it
over unsecured transport.
We (who're working on -tls-server-id-check) are not going to address or change
the above (in this spec) and so I feel further stepping down this rat-hole is
inappropriate in discussing this spec.
That said, I acknowledge that HTTP redirects can be put to all sorts of evil
use, and perhaps the "Web Security Context: User Interface Guidelines (WSC-UI)"
<http://www.w3.org/TR/wsc-ui/> should more explicitly and thoroughly discuss
user agent behavior in terms of when one is "redirected away from" a "secure
web app". Note that the user agent on its own, without guidance from such an
app or prior configuration, determine whether any particular redirect is
"authorized" or not (and neither can the user) due to aforementioned DNS name
mapping, app linking, etc. We've all seen those app warnings from time to time
"you're about to be redirected away from our site/app, just be aware, click
here to follow the link..." -- this doesn't appear to be mentioned in WSC-UI.
HTH,
=JeffH
_______________________________________________
certid mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/certid
