[saag] [Eric Rescorla <ekr@rtfm.com>] [ietf-tls] Re: RFC2817 or RFC2818 ?

[Eric Rescorla]

NOTE: When I replied to this on ietf-tls I forgot to cc SAAG. if you 
followup to this message please cc ietf-tls@certicom.com as well.

"Paul V Ford-Hutchinson" <paulfordh@uk.ibm.com> writes:
> I was under the impression that the IETF direction was to negotiate SSL
> within an application exchange (RFC2817 for http) and not perform SSL
> blindly upon connection (RFC2818).
> 
> (Quote from RFC 2817
> "At the Washington DC IETF meeting in December 1997, the Applications
>    Area Directors and the IESG reaffirmed that the practice of issuing
>    parallel "secure" port numbers should be deprecated. The HTTP/1.1
>    Upgrade mechanism can apply Transport Layer Security [6] to an open
>    HTTP connection.")
That's the official word, yes.

> It appears clear that the TLS community is trying to preserve the
> Informational RFC2818 approach over the Standards Track RFC2817 by the
> proposal of DNS name in the TLS extensions draft.
>
> Is this deliberate ?
I'm not necessarily sure that this necessarily follows from the
introduction of dns_name. Rather, think of it as accepting that
HTTPS isn't going away anytime soon.

> Is there tacit agreement that RFC2817 is a pipe dream ?
It's important to distinguish between the general idea of
an upward negotiation strategy and the realization of that idea in
RFC 2817. RFC 2817 is pretty badly broken:

(1) There's no adequate way to use upgrade with proxies because
Upgrade is a hop-by-hop header and what you really want is to negotiate 
TLS end-to-end. In order to get Upgrade to work you need to tunnel
through the proxy using CONNECT. Obviously this is bad since it
means that proxies become essentially useless.

(2) There's no way to indicate in the URL that RFC 2817-style
upgrade is expected. This has nasty consequences:
	(a) If the client ever wants TLS to be used for his requests
	he needs to send an OPTIONS request (to probe for Upgrade)
	before sending his actual request. (The server can request TLS
	but the client has already sent his request at that
	point). This creates an unacceptable performance cost.
	(b) No reference integrity, even of the "require security sort"
	that is allowed by the "https://" URL. This means that an attacker
	can downgrade you to ordinary HTTP.

However, this isn't to say that you couldn't design an upward-negotiation
strategy for HTTP that would work. You certainly could.

-Ekr

---
You are currently subscribed to ietf-tls as: ekr@rtfm.com
To unsubscribe send a blank email to leave-ietf-tls-3174256S@lists.certicom.com