Subject: Rough minutes

From: Mark Nottingham <[email-masked]>
Date: Tue, 5 Nov 2013 16:41:19 -0800

… are up at:
  http://trac.tools.ietf.org/wg/httpbis/trac/browser/wg_materials/ietf88/minutes.txt

Cheers,

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

---

From: Tim Bray <[email-masked]>
Date: Tue, 5 Nov 2013 18:08:59 -0800

I would have said the weakness of the #3 and #4 hums was very, very close.

---

From: Yoav Nir <[email-masked]>
Date: Wed, 6 Nov 2013 02:17:34 +0000

And #2 was only slightly stronger.

On Nov 5, 2013, at 6:08 PM, Tim Bray <[email-masked]<mailto:[email-masked]>>
 wrote:

On Tue, Nov 5, 2013 at 4:41 PM, Mark Nottingham <[email-masked]<mailto:[email-masked]>> wrote:
… are up at:
  http://trac.tools.ietf.org/wg/httpbis/trac/browser/wg_materials/ietf88/minutes.txt

Cheers,

Email secured by Check Point

---

From: Peter Lepeska <[email-masked]>
Date: Sat, 9 Nov 2013 16:04:28 -0500

I never did understand option #3. What is opportunistic encryption with
authentication? I thought opportunistic encryption is TLS-relaxed, which is
encryption without server authentication.

Also, I think  the choices are different for HTTP 1 and 2 b/c HTTP/2.x
doesn't involve a performance trade-off.

For HTTP 1.x, the only realistic choice (assuming do nothing is off the
table) in my opinion is:
1) Add support for TLS-relaxed in HTTP/1.x web servers and browsers but
make it OFF by default. Performance impact is too great for HTTP 1.x so
many deployments will not want this.

For HTTP 2.x, I believe the choices are:
1) Add support for TLS-relaxed in HTTP/2.x web servers and browsers but
make it ON by default.
2) Require Full TLS in HTTP 2.x.

Peter

On Tue, Nov 5, 2013 at 9:17 PM, Yoav Nir <[email-masked]> wrote:

>  On Nov 5, 2013, at 6:08 PM, Tim Bray <[email-masked]>
>  wrote:
>

---

From: Yoav Nir <[email-masked]>
Date: Sun, 10 Nov 2013 04:11:20 +0000

I'm stumped about #3 myself.

The literal interpretation is that you follow (or type in) an http:// link, get a response, and in the response learn that this is also available with SSL. So the client attempts to upgrade to SSL, and receives a valid certificate. So, yay!

But in that case, why is the http:// link out there at all, and if anybody types it in, why not immediately redirect to https:// as pretty much all sites using SSL do?

Also, I don't like the implication:  No valid certificate --> No encryption --> No HTTP/2. That's a far higher bar than the goal that's set in the charter.  We could at least give you ADH ciphersuites with no certificates.

Yoav

On Nov 9, 2013, at 11:04 PM, Peter Lepeska <[email-masked]<mailto:[email-masked]>> wrote:

I never did understand option #3. What is opportunistic encryption with authentication? I thought opportunistic encryption is TLS-relaxed, which is encryption without server authentication.

Also, I think  the choices are different for HTTP 1 and 2 b/c HTTP/2.x doesn't involve a performance trade-off.

For HTTP 1.x, the only realistic choice (assuming do nothing is off the table) in my opinion is:
1) Add support for TLS-relaxed in HTTP/1.x web servers and browsers but make it OFF by default. Performance impact is too great for HTTP 1.x so many deployments will not want this.

For HTTP 2.x, I believe the choices are:
1) Add support for TLS-relaxed in HTTP/2.x web servers and browsers but make it ON by default.
2) Require Full TLS in HTTP 2.x.

Peter

On Tue, Nov 5, 2013 at 9:17 PM, Yoav Nir <[email-masked]<mailto:[email-masked]>> wrote:
And #2 was only slightly stronger.

Cheers,

---

From: Julian Reschke <[email-masked]>
Date: Sun, 10 Nov 2013 10:53:00 +0100

On 2013-11-10 05:11, Yoav Nir wrote:
> The literal interpretation is that you follow (or type in) an http://
> link, get a response, and in the response learn that this is also
> available with SSL. So the client attempts to upgrade to SSL, and
> receives a valid certificate. So, yay!
>
> But in that case, why is the http:// link out there at all, and if
> anybody types it in, why not immediately redirect to https:// as pretty
> much all sites using SSL do?

Redirecting means changing the URI (bookmarks etc), and also implies 
running the service both on port 80 and 443.

> ...

Best regards, Julian

---

From: Yoav Nir <[email-masked]>
Date: Sun, 10 Nov 2013 21:29:41 +0000

On Nov 10, 2013, at 11:53 AM, Julian Reschke <[email-masked]> wrote:

> Redirecting means changing the URI (bookmarks etc), and also implies running the service both on port 80 and 443.

Right. But that's a good thing for a site with a valid certificate, no?  Even port 80 doesn't have the same service as port 443, but just something that redirects all requests to the https equivalent. 

I just don't see why opportunistic encryption is useful for sites with a valid certificate. I think OE is needed for the 70% of websites ([1]) that don't have a valid certificate.

Yoav

[1] http://w3techs.com/technologies/overview/ssl_certificate/all

---

From: "Nicolas Mailhot" <[email-masked]>
Date: Sun, 10 Nov 2013 23:44:33 +0100

> running the service both on port 80 and 443.

OTOH redirecting to a different URL is what makes caches work.

-- 
Nicolas Mailhot

---

From: "Christian Huitema" <[email-masked]>
Date: Sun, 10 Nov 2013 16:10:34 -0800

> I just don't see why opportunistic encryption is useful for sites with a
valid certificate. I think OE is needed for the 70% of websites ([1]) that
don't 
> have a valid certificate.

That's certainly an argument. But then, there are design implications.
Consider the sites that do not have a valid certificate today. Is it because
they don't want to pay the CA, or is it because they don't want to bother
with certificate maintenance? If the argument is really about cost of
managing the certificate, expiry date, etc., then the opportunistic mode
should be truly "zero administration." Can we achieve that with short-lived
self-signed certificates?

-- Christian Huitema

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 11 Nov 2013 02:54:02 +0200

> self-signed certificates?

The reasons I have heard are:
1) Price

- Basic Certificates are pretty cheap nowadays.
- EV certs are expensive, but who need those surely can afford it.

=> Minor issue.

2) Maintenance

- Generating CSRs
- Installing certifificates.
- Renewing before expiry.
- Significant potential for software improvments.

=> Significant issue.

3) Performance

- The startup overhead is significant.
- But modern hardware is pretty much powerful enough.
- HTTP/2 helps here (due to long-lived connections).

=> Minor issue in HTTP/2, might be issue in HTTP/1.

4) Mixed content

- Not all external services are available over TLS.
- Big issue for some sites (even quoted as THE showstopper).
- Of course, some view those services as security problems in
themselves (unwanted surveilance and possiblity of injecting
hostile scripts).

=> Major issue.

5) URL schemes

- Site might have http:// links to itself in the database
(major issue for some types of sites).
- Main blocker on at least one site I know.

=> Might be significant issue, depending on type of site.

-Ilari

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Mon, 11 Nov 2013 03:05:24 +0100

>=> Might be significant issue, depending on type of site.

Could you elaborate on what the problem is? How, for example, does HSTS
not help to mitigate the problem? Julian mentioned having to run on :80;
is that a notable problem?
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 11 Nov 2013 04:47:12 +0200

> is that a notable problem?

Basically, if the site code constructs pages by pulling in text fragments
from the database, and those fragments include direct http:// links/
references to the site itself.

Sometimes those links might point to other subdomains, so relative paths
will not work (and of course sometimes users do things incorrectly).

If those fragments are internal markup, one could convert when converting
the text to HTML, but if those fragments are HTML, that's considerably
harder.

And rewriting the stuff in the DB might be a big effort.

HSTS doesn't fully solve this (aside from any possible issues in 
deployment), because if A refers to B, and B has active HSTS, the reference
is still insecure (even if the request to B will be over HTTPS because
of the HSTS). Or it is like that at least in Firefox 24.

On the one site, I think the plan was to use client-side JS to rewrite
the links/references to use https:// (none should be active content).

-Ilari

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 12 Nov 2013 11:56:55 +0800

> But in that case, why is the http:// link out there at all, and if anybody types it in, why not immediately redirect to https:// as pretty much all sites using SSL do?

Yes, pretty much. Unfortunately, we didn’t have time to follow the discussion to this conclusion in the room, but many conversations I had afterwards reflected this.

> Also, I don't like the implication:  No valid certificate --> No encryption --> No HTTP/2. That's a far higher bar than the goal that's set in the charter.  We could at least give you ADH ciphersui…

The charter itself doesn’t address this topic explicitly; the discussion leading up to it did, of course. What we’re doing now is effectively revisiting that discussion to see where we sit, based upon new information that’s become available.

Cheers,

> 
> Yoav
> 
> On Nov 9, 2013, at 11:04 PM, Peter Lepeska <[email-masked]> wrote:
>