Subject: Getting to Last Call

From: Mark Nottingham <[email-masked]>
Date: Thu, 15 Dec 2011 13:01:36 +1100

HTTPbis' first meeting was at IETF70, in Vancouver, almost exactly four years ago.

Our current charter <http://datatracker.ietf.org/wg/httpbis/charter/> says that we were supposed to have a Last Call for HTTPbis last November. That's 2010, not 2011.

While our emphasis has always been on quality over speed, we will soon (or perhaps already have) hit diminishing returns, and asking for the editors' time over such a span can also be an imposition.

Our list of design issues <http://trac.tools.ietf.org/wg/httpbis/trac/report/9> will have less than 10 remaining (probably around 7), once the current discussion runs its course and we publish -18 (planned for before the holidays). There are also a few editorial issues left, and some placeholders for changes in the drafts (e.g., p1 Section 7). 

As such, we're getting close to the beginning of the end. 

We're not quite ready for Working Group Last Call, but I do believe it's not far off. So, if you have issues to bring to the Working Group, please do so soon. Likewise, if you read the drafts and notice something that needs work, and isn't covered by an issue or note in the text itself, please bring it to our attention.

After we get -18 out, I expect to focus our discussion on the remaining issues and on the editorial quality of the drafts, since some sections may still need rearrangement or rewriting. 

Regards,

--
Mark Nottingham   http://www.mnot.net/

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 14 Dec 2011 19:09:15 -0700

On 12/14/11 7:01 PM, Mark Nottingham wrote:

> After we get -18 out, I expect to focus our discussion on the
> remaining issues and on the editorial quality of the drafts, since
> some sections may still need rearrangement or rewriting.

<hat type='AD'/>

Thanks, Mark. I will perform an "AD Review" of the -18 specs, although
WG participants have been so thorough that I don't expect to find much.

Peter

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

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 15 Dec 2011 07:38:37 +0100

Hi Mark,

On Thu, Dec 15, 2011 at 01:01:36PM +1100, Mark Nottingham wrote:
> We're not quite ready for Working Group Last Call, but I do believe it's not far off. So, if you have issues to bring to the Working Group, please do so soon.

Mid-April, we had a discussion with Adrien the suggestion of making UAs
connect to proxies using https instead of http so that we stop the horrors
that are currently performed for authentication in many corporate environments
(you know, redirect to https for auth + set-cookie for the target domain +
redirect again + failure quite often...), and apparently there was no ticket
for this.

Adrien even suggested the use of "GET https://" instead of CONNECT in
some cases so that filtering proxies can safely inspect the contents.

Since corporate proxies are a place where HTTP works very badly, I think
we should address these issues before the final release.

Best regards,
Willy

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 15 Dec 2011 20:42:21 +1300

> we should address these issues before the final release.

I'm wavering between "please, please, please!", and "What can HTTPbis do 
about it?".

In Squid we have supported SSL/TLS negotiation on incoming sockets for 
some years now. For us it is simply a matter of the UA adding TLS on its 
connections. AFAIK, only two UA have implemented it in all these years.

So what can HTTPbis do beyond what is already done in part 1 section 2.7.2 ?

I do take exception to the sentence which erases server admins choice 
over the public/private nature of secured resources:
"

Unlike the "http" scheme, responses to "https" identified requests
    are never "public" and thus MUST NOT be reused for shared caching.
"

IMHO, "Cache-Control: public" should be permitted to enable shared 
caching on resources, matching how it works on authenticated resources 
and any other default-private response in http://.

Better wording would perhapse be:

   Unlike the "http" scheme, responses to "https" identified requests
   default to "private" and thus MUST NOT be reused for shared caching
   unless the "public" cache control is sent to indicate otherwise.

This opens the door for shared caches to optimize high-bandwidth 
resources like images which are deemed by their sites to be non-secure 
but must be served within https:// due to security considerations about 
cross-scheme problems.

AYJ

---

From: Willy Tarreau <[email-masked]>
Date: Thu, 15 Dec 2011 09:04:11 +0100

Hi Amos,

> I'm wavering between "please, please, please!", and "What can HTTPbis do 

Simply suggest that proxies SHOULD support it and that UAs SHOULD use it.

> some years now.

Glad to know, but we're still waiting for UAs to use it !

> For us it is simply a matter of the UA adding TLS on its 

I've not even identified them :-(

> So what can HTTPbis do beyond what is already done in part 1 section 2.7.2 ?

Encourage its use by default ?

Also, decide whether proxies should perform https request on behalf of UAs
when they emit "https://" proxy requests. This would :
  - permit proxies to filter inappropriate requests (important in schools
    where you don't want you kids to visit adult sites)
  - make it possible to disable use of the CONNECT method which right
    now is a big security issue (I'm even regularly using it to SSH outside)
  - make it possible for content filtering proxies to filter responses
  - all of this without emitting fake certificates.

(...)
>   unless the "public" cache control is sent to indicate otherwise.

I agree this would help a lot !

Best regards,
Willy

---

From: Amos Jeffries <[email-masked]>
Date: Thu, 15 Dec 2011 21:41:03 +1300

> I've not even identified them :-(

curl and Opera have the ability, although I've not personally seen Opera 
do it.

AYJ

---

From: Julian Reschke <[email-masked]>
Date: Fri, 16 Dec 2011 15:15:11 +0100

On 2011-12-15 03:01, Mark Nottingham wrote:
> Our current charter<http://datatracker.ietf.org/wg/httpbis/charter/>  says that we were supposed to have a Last Call for HTTPbis last November. That's 2010, not 2011.
>
> Our list of design issues<http://trac.tools.ietf.org/wg/httpbis/trac/report/9>  will have less than 10 remaining (probably around 7), once the current discussion runs its course and we publish -18 (planned for before the holidays). There are also a few editorial issues left, and some placeholders for changes in the drafts (e.g., p1 Section 7).
>
> ...

+1

Also, looking at the subsequent thread:

- when raising new topics please do so in separate threads with 
meaningful subject lines, and

- try to avoid requests for new features or breaking changes 
(essentially everything we're not chartered for -- we'll get to that 
once HTTPbis is done).

Best regards, Julian

---

From: William Chan (陈智昌) <[email-masked]>
Date: Fri, 16 Dec 2011 07:53:58 -0800

> curl and Opera have the ability, although I've not personally seen Opera

FWIW, Chrome has this ability, and we use it to also support SPDY proxies.

---

From: Mark Nottingham <[email-masked]>
Date: Sat, 24 Dec 2011 08:52:35 -0500

Hi Willy,

This is certainly desirable, but just making it a requirement would make pretty much every proxy non-conformant, so that's a big step.

Would it be sufficient to just encourage use / support of HTTPS with proxies?

--
Mark Nottingham
http://www.mnot.net/

---

From: Willy Tarreau <[email-masked]>
Date: Sun, 25 Dec 2011 21:04:30 +0100

Hi Mark,

> Would it be sufficient to just encourage use / support of HTTPS with proxies?

I think that's what a SHOULD is made for. Do you think SHOULD would be
too strong here ?

Best regards,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 29 Dec 2011 19:44:31 -0500

SHOULD affects conformance. At most, I think we'd add something to the security considerations saying that proxies "ought to" or "are encouraged to."

Cheers,

--
Mark Nottingham
http://www.mnot.net/

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 29 Dec 2011 19:55:41 -0800

> SHOULD affects conformance. At most, I think we'd add something to the security considerations saying that proxies "ought to" or "are encouraged to."

FWIW, I consider it to be a security hole for any user agent
to automatically change the configured proxy authority.  If
the user/org wants to connect via TLS, then the user/org should
configure the proxy with an https URI.  There is no guarantee
that a proxy on port 443 is controlled by the same org as the
one on port 80.

OTOH, the spec already allows communication on port 80 to be
Upgraded to TLS.  No changes are necessary to support that.

....Roy

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 30 Dec 2011 07:07:54 +0100

Hi,

> > SHOULD affects conformance. At most, I think we'd add something to the security considerations saying that proxies "ought to" or "are encouraged to."

OK. But UAs are even more encouraged to do so too, as they're the
bigest blocking factor right now.

> to automatically change the configured proxy authority.

Agreed.

> If
> configure the proxy with an https URI.

That's what I meant. Basically have the UA add a check box in the
proxy settings "Use TLS to connect to proxy".

> There is no guarantee

It can be even worse: the proxy might be running on port 8080 or
3128 as is often encountered, and automatically detect SSL/TLS vs
HTTP and still not forward the request to the same place.

> Upgraded to TLS.  No changes are necessary to support that.

Indeed. Not sure it's much deployed though, especially considering
it adds one round trip to the connection setup.

Regards,
Willy