Re: HTTP/TLS over a separate port draft

Per Tom Weinstein:

> This prevents an attack where Alice hijacks Bob's connection to
> www.bofa.com (who's cert is signed by VeriSign) but presents her own
> cert for www.badgirl.org, which has also been signed by VeriSign. ...
> 
> From this example, it's pretty clear that the DNS name check requires
> either:
>    a) the application protocol (HTTP) gets the cert from the TLS layer,
>       and then checks the name in the cert against what it was
>       expecting, or
>    b) the application protocol informs the TLS layer of the hostname it
>       was connecting to, and then TLS does the name check.
> 
> It seems to me that option a) is the best way to do this, since this name
> check is not appropriate for all protocols.

But for some appropriate usages of the term, HTTP(S) isn't the
application protocol -- it's just a request/response protocol with a
fair degree of infrastructure to dance through firewalls when that's
needed.  In this case I'd say "web browsing" is the application, and
the role of HTTPS is to be application infrastructure.

The role of the PKI here is just to authenticate.  The application (web
browser sometimes, but not always) needs to support some kind of
authorization policy.  I'd be happy adopting a policy that for "host
oriented services" the DNS name check SHOULD be the norm, particularly
if other services adopted that policy.  (LDAP/TLS, SMTP/TLS, etc.)

Of course, my "personal" web server should probably have my own name
there, not the name currently assigned by my ISP.

- Dave