Subject: [TLS] Last Call: RFC 2818 (HTTP Over TLS) to Proposed Standard

From: IESG Secretary <[email-masked]>
Date: Fri, 01 Jun 2012 09:42:05 -0700

The IESG has received a request from the TLS Working Group to reclassify RFC 2818 (HTTP Over TLS) to Proposed Standard.

The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf at ietf.org mailing lists by 2012-06-15. Exceptionally, comments may be sent to iesg at ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting.

Abstract     

This memo describes how to use TLS to secure HTTP connections over the Internet. Current practice is to layer HTTP over SSL (the predecessor to TLS), distinguishing secured traffic from insecure traffic by the use of a different server port. This document documents that practice using TLS. A companion document describes a method for using HTTP/TLS over the same port as normal HTTP [RFC2817].

The file can be obtained via
http://www.rfc-editor.org/rfc/rfc2818.txt

No IPR declarations have been submitted directly on this I-D.

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 01 Jun 2012 10:45:35 -0600

> The IESG has received a request from the TLS Working Group to reclassify RFC 2818 (HTTP Over TLS) to Proposed Standard.

Interesting. Are there also plans to modernize this spec by working on
2818bis?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: "Kyle Hamilton" <[email-masked]>
Date: Fri, 1 Jun 2012 10:15:48 -0700 (Pacific Daylight Time)

This is damaging, and I recommend against.  This is something which must be handled by HTTP and its demands of its transports, not TLS and its claim to support what it thinks its clients want.

Among other things, this RFC more than any other is responsible for the "Server Name Indication" requirement.  If it had not been the case, SNI would never have been necessary, and IESG/IETF would never have had to deal with it.

I suggest instead that it be moved to HISTORIC, and a 2818bis drafted which describes how the various TLS extensions play with HTTP.

-Kyle H

On Fri, Jun 1, 2012 at 9:42 AM, IESG Secretary <[email-masked]> wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 1 Jun 2012 10:28:51 -0700

On Fri, Jun 1, 2012 at 10:15 AM, Kyle Hamilton <[email-masked]> wrote:
> This is damaging, and I recommend against.  This is something which must be
> handled by HTTP and its demands of its transports, not TLS and its claim to
> support what it thinks its clients want.
>
> Among other things, this RFC more than any other is responsible for the
> "Server Name Indication" requirement.  If it had not been the case, SNI
> would never have been necessary, and IESG/IETF would never have had to deal
> with it.

Huh? As stated in the abstract, RFC 2818 documented what was already
established practice at the time it was published. Yes, that practice
leads directly to SNI, but it's not like it's the fault of 2818.

> I suggest instead that it be moved to HISTORIC, and a 2818bis drafted which
> describes how the various TLS extensions play with HTTP.

I don't understand what that would mean. At the time 2818 was published,
there were already complaints about the HTTPS mechanism (though
primarily directed towards the use of a separate port) and the IETF
took a stab at trying to define a protocol that it liked better (2817).
That was hardly a success. It's hard to believe that we're going to
make fundamental architectural changes now, given that HTTPS
is far more entrenched.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 1 Jun 2012 10:29:58 -0700

> Interesting. Are there also plans to modernize this spec by working on

I would be willing to work on this if we could come up with
a clear list of improvements.

-Ekr

---

From: [email-masked] (Martin Rex)
Date: Fri, 1 Jun 2012 19:44:22 +0200 (CEST)

Kyle Hamilton wrote:
> This is damaging, and I recommend against.  This is something which must
> be handled by HTTP and its demands of its transports, not TLS and its
> claim to support what it thinks its clients want.
> 
> "Server Name Indication" requirement.  If it had not been the case,
> SNI would never have been necessary, and IESG/IETF would never have
> had to deal with it.

The RFC(s) responsible for the "Server Name Indication" requirement is/are
2068/2616 "HTTP/1.1", which introduced the concept of virtual hosting:

  http://tools.ietf.org/html/rfc2068#section-14.23
  http://tools.ietf.org/html/rfc2616#section-14.23

> 
> I suggest instead that it be moved to HISTORIC, and a 2818bis drafted
> which describes how the various TLS extensions play with HTTP.

While I would be OK with creating rfc2818bis that explicitly describes
additional requirements implied by the virtual hosting concept of HTTP/1.1
and refers to TLS extension SNI rfc4366 (for TLSv1.0+v1.1) and
rfc6066 (for TLSv1.2+),  I fail to see why we should move rfc2818
to historic _before_ such a 2818bis is ready for publication.

-Martin

---

From: Sean Turner <[email-masked]>
Date: Fri, 01 Jun 2012 14:49:33 -0400

So....I wasn't clear enough when I asked for this IETF LC.  I initiated 
this process as an AD not at the request of the WG.

My rationale was that it's in the downref registry and that there's 66 
or so RFCs that refer to 2818 and a lot of them are normative.  If it 
ends up that folks prefer the 2818bis -> PS coupled with 2818 -> 
Historic.  I'd be all right with that too.

spt

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Fri, 01 Jun 2012 21:15:54 +0200

On Fri, 01 Jun 2012 19:29:58 +0200, Eric Rescorla <[email-masked]> wrote:

>>> The IESG has received a request from the TLS Working Group to  
>>> reclassify RFC 2818 (HTTP Over TLS) to Proposed Standard.
>>

My list for a bis:

- Update protocol reference to TLS 1.2, preferably with a suggestion to  
support at least that version, and a reiteration of version and extension  
tolerance for servers.
- Update sec. 3.1 to use RFC 6125 for the server identity.
- Reference the HTTP CONNECT method for connecting through a proxy.
- As I recall, more recent TLS versions have changed the requirements for  
unexpected connection closure and session reuse, so sec 2.2 should  
probably reflect that.

-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 23 69 32 60              Fax:    +47 23 69 24 01
********************************************************************

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 1 Jun 2012 12:16:36 -0700

On Jun 1, 2012, at 11:49 AM, Sean Turner wrote:

> So....I wasn't clear enough when I asked for this IETF LC.  I initiated this process as an AD not at the request of the WG.
> 
> My rationale was that it's in the downref registry and that there's 66 or so RFCs that refer to 2818 and a lot of them are normative.  If it ends up that folks prefer the 2818bis -> PS coupled with 2818 -> Historic.  I'd be all right with that too.

That seems the best way to go, given how much things have changed in the last decade.

--Paul Hoffman

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 01 Jun 2012 13:25:18 -0600

On 6/1/12 1:16 PM, Paul Hoffman wrote:
>> So....I wasn't clear enough when I asked for this IETF LC.  I
>> initiated this process as an AD not at the request of the WG.
>> 
>> My rationale was that it's in the downref registry and that there's
>> 66 or so RFCs that refer to 2818 and a lot of them are normative.
>> If it ends up that folks prefer the 2818bis -> PS coupled with 2818
>> -> Historic.  I'd be all right with that too.
> 

Agreed. I don't see any harm in having lots of RFCs pointing to this
entry in the downref registry, and it seems better to update 2818 than
to have people thinking that 2818 is standards-track as it is today.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Nico Williams <[email-masked]>
Date: Fri, 1 Jun 2012 14:30:50 -0500

> to have people thinking that 2818 is standards-track as it is today.

+1.

Moving an RFC to Proposed Standard should come with a discussion of
whether that RFC is OK as-is.  It looks like RFC2818 isn't/

Nico
--

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 1 Jun 2012 12:45:42 -0700

On Fri, Jun 1, 2012 at 12:15 PM, Yngve N. Pettersen (Developer Opera
Software ASA) <[email-masked]> wrote:
>>>> The IESG has received a request from the TLS Working Group to reclassify
>>>> RFC 2818 (HTTP Over TLS) to Proposed Standard.
>>>
>>>

Agreed.

> - Update sec. 3.1 to use RFC 6125 for the server identity.

I'm not sure I agree with this. 2818 is intended to document HTTPS client
behavior. This may or may not be what we recommend for other protocols
(and indeed, the terms under which 6125 was approved included that
it not override 2818 for HTTPS).

> - Reference the HTTP CONNECT method for connecting through a proxy.

IIRC, this is documented in 2817. We would have to decide if we wanted
to move that, ref it, or...

> unexpected connection closure and session reuse, so sec 2.2 should probably
> reflect that.

Probably.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 1 Jun 2012 12:50:17 -0700

> whether that RFC is OK as-is.  It looks like RFC2818 isn't/

FWIW, I don't really care what the status of this RFC is.

That said, it looks kinda silly to have a document that describes a huge chunk
of how the Internet works and that is referred to normatively all over
the place be Informational because the IESG of 2000 thought that
HTTP and HTTPS should run over the same port.

-Ekr

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 01 Jun 2012 14:43:49 -0600

> behavior. This may or may not be what we recommend for other protocols

I see two approaches:

1. Profile 6125 in 2818bis, as we've done for email and XMPP.

2. Define something 6125-ish (but shorter) in 2818bis.

> it not override 2818 for HTTPS).

Indeed.

Another topic it would be good to clarify (or affirm) in 2818bis is
wildcards.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Sean Turner <[email-masked]>
Date: Fri, 01 Jun 2012 16:55:31 -0400

On 6/1/12 4:43 PM, Peter Saint-Andre wrote:
>> Software ASA)<[email-masked]>  wrote:
>>

That would address the errata filed against 2818.

spt

---

From: Geoffrey Keating <[email-masked]>
Date: 01 Jun 2012 13:55:37 -0700

> it not override 2818 for HTTPS).

One substantive change here is that instead of "MUST" for using the
commonName field, it would become "MAY".  I think this is an
appropriate change, especially given that clients will not always
accept the commonName field (for example, if it contains spaces, or if
it isn't in DNS 'preferred name syntax', or if the certificate does
not have an extendedKeyUsage field indicating it is intended for
server authentication).

Another change is that wildcards are also optional in RFC 6215, and in
particular 6215 recommends a more restricted wildcard match than 2818
requires.  I think to promote interoperability, 2818bis should specify
that wildcards MUST be accepted but SHOULD be accepted only in the
left-most label.

Since 2818 is presently just Informational, and was intended to
describe current practice, I wouldn't describe these as changes, but
rather as corrections.  Or, perhaps, an 'update', since current
practice has changed in the 12 years since the RFC was published!

I would oppose moving 2818 to Proposed Standard without the commonName
correction, as this would introduce a security flaw.

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 1 Jun 2012 14:05:50 -0700

On Fri, Jun 1, 2012 at 1:55 PM, Geoffrey Keating <[email-masked]> wrote:
> it isn't in DNS 'preferred name syntax',

I'm not sure I follow this. If the CN isn't a valid domain name, then
won't it fail to match the DNS name it is intended to match?
What am I missing?

> or if the certificate does

My read of this note suggests that at least NSS (and thus potentially
Firefox and Chrome) does not enforce EKU's presence.

http://www.mozilla.org/projects/security/pki/nss/tech-notes/tn3.html

> practice has changed in the 12 years since the RFC was published!

My view is that if we republish this document (at any level) , it should
be made to conform to common practice.

-Ekr

---

From: Geoffrey Keating <[email-masked]>
Date: 01 Jun 2012 14:51:11 -0700

> won't it fail to match the DNS name it is intended to match?

Suppose you have a cookie for ".example.com" which I'd like to steal.
I MITM you but you're using SSL and the cookie is marked as 'secure'
so I can't just grab it.  I manage to acquire a valid e-mail
certificate with a common name of "[email-masked]".  Now I
fake your DNS so that [email-masked]' appears to be a valid
hostname (that is, I cause your DNS request to return an A record for
'somename@mail' in the domain 'example.com') pointing at my server, and
wait for you to open a non-TLS web page, in which I inject HTML which
includes a frame or an image from
'https://somename%40mail.example.com/somefile'.  The cookie will be sent
as part of this request, and it'll be sent to my server.

The name 'somename@mail' is not in the 'preferred name syntax' but DNS
will quite happily serve it---DNS labels are 8-bit strings that can
even contain NUL characters.

Another approach is that I could get a certificate with a common name
of 'Some Name'.  If your DNS search path is set to include
'example.com' (or if I can force this by controlling your DHCP), I
might be able to do the same thing with a URL of
'https://Some%20Name/somefile'.

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 01 Jun 2012 15:51:30 -0600

> won't it fail to match the DNS name it is intended to match?

Jeff and I covered the Common Name topic in RFC 6125 (see for instance
Section 2.3 and Section 6.4.4). Basically we tried to push folks in the
direction of deprecating Common Name in favor of subjectAltName entries
of type dNSName (or other strongly typed data fields such as SRVName and
uniformResourceIdentifier). We had some degree of success, but we still
allow CN checking if the presented certificate does not contain DNS-ID,
SRV-ID, or URI-ID.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 1 Jun 2012 14:58:53 -0700

> even contain NUL characters.

OK, I see the issue. I do wonder how a browser would actually behave in this
case. I.e., I would hope that it would either parse this as
https://mail.example.com/
with a username of somename or alternately expect that the certificate contain
the %40, but regardless I agree it's not great.

> 'https://Some%20Name/somefile'.

Wouldn't this be an issue with or without a space? I.e., I get a certificate
with CN "foo" and then serve https://foo/?

-Ekr