Subject: HTTPBis BOF followup - should RFC 2817/2818 be in scope for the WG?

From: Alexey Melnikov <[email-masked]>
Date: Sat, 11 Aug 2007 17:30:34 +0100

Hi folks,
Answers to this question during the BOF were not conclusive, so I would 
like to poll mailing list members on whether revision of RFC 2817 
(Upgrading to TLS Within HTTP/1.1) and RFC 2818 (HTTP Over TLS) should 
be in scope for the proposed WG.

Question: Should RFC 2817 and/or RFC 2818 revision be in scope for the WG?

Please chose one of the following answers:

1). No
2). Yes, only add RFC 2818bis to the charter
3). Yes, only add RFC 2817bis to the charter
4). Yes, add both RFC 2817bis and RFC 2818bis to the charter
5). Maybe (this includes "yes, but when the WG completes the currently 
proposed milestones" and "yes, but this should be done in another WG")
6). I have another opinion, which is ....

Please send answers to the mailing list, or directly to me *and* Mark 
Nottingham <[email-masked]>.
And of course feel free to ask clarifying questions/correct list of answers.

---

From: Julian Reschke <[email-masked]>
Date: Sun, 12 Aug 2007 15:21:23 +0200

> And of course feel free to ask clarifying questions/correct list of 

5.

Best regards, Julian

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 13 Aug 2007 08:03:17 +0200

2) Yes, only add RFC 2818bis to the charter

My reasoning:
Another Proposed Standard that few people work on and even fewer implement 
(2817) doesn't really harm anything. An Informational reference for the 
in-fact-implemented security technology is harmful; if there are other 
issues with the document, it's harmful too.

Work on what's important.

--On 11. august 2007 17:30 +0100 Alexey Melnikov 
<[email-masked]> wrote:

> (Upgrading to TLS Within HTTP/1.1) and RFC 2818 (HTTP Over TLS) should be
> in scope for the proposed WG.
>

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 27 Aug 2007 21:20:34 +0100

Alexey Melnikov wrote:

> Hi folks,
> Answers to this question during the BOF were not conclusive, so I 
> would like to poll mailing list members on whether revision of RFC 
> 2817 (Upgrading to TLS Within HTTP/1.1) and RFC 2818 (HTTP Over TLS) 
> should be in scope for the proposed WG.
>

Folks, I've seen very little answers to my question. I would like to 
encourage people to be more active on this.
I would also like to set a deadline for this question: please send your 
response before September 3rd.

---

From: John Leslie <[email-masked]>
Date: Mon, 27 Aug 2007 20:36:16 +0000

>>6). I have another opinion, which is ....

   I tend towards 1) no.

   It's not obvious that TLS is central to this work: before we add what
looks like a can of worms, we'd better be sure it's needed.

--
John Leslie <[email-masked]>

---

From: Keith Moore <[email-masked]>
Date: Tue, 28 Aug 2007 15:37:46 -0400

I'm thinking that these are security RFCs and perhaps not proper scope
for an apps group.  however I don't know why an httpbis group shouldn't
make recommendations for things to change in these RFCs if it can
identify problems with them. 

Keith
>> 5). Maybe (this includes "yes, but when the WG completes the
>> currently proposed milestones" and "yes, but this should be done in
>> another WG")
> I would also like to set a deadline for this question: please send
> your response before September 3rd.
>
>
>

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 30 Aug 2007 01:55:38 +0200

5.

Not convinced they need a revision. But I also have not studied them in
full detail. From a quick reading they do seem to contain a bit too much
details and should be cut down, for example referencing the HTTP/1.1
message delimiting rules instead of miserably trying to mirror it
again..

I consider it within the charter to consider if a reference to add a
reference to these from the HTTP/1.1 security considerations section
reasonable, and probably desireable.

It's also worth noting that I don't see it likely that RFC2817 will ever
get any momentum given how wide spread HTTP over TLS is combined with
the lack of capability negotiation in HTTP and it's resulting security
issues of having to first send the request in plain in order to discover
the TLS capability of the server. This is quite different from the other
IETF protocols having "TLS upgrade" capabilities.. (i.e. IMAP, SMTP,
POP, etc.. all negotiate the TLS upgrade before the acutal request
exchange, as part of the normal negotiation phase of respective
protocol)

I do concider it fully in scope to incorporate the definition of CONNECT
into HTTP/1.1.

Regards
Henrik