Subject: [Tools-discuss] Proposed Statement on "HTTPS everywhere for the IETF"

From: Benson Schliesser <[email-masked]>
Date: Mon, 01 Jun 2015 19:20:04 -0700

Reading the IESG statement on HTTPS Everywhere (link forwarded below), 
something remains unclear to me. I'm hopeful that somebody on this 
list has an informed view of this question. Otherwise I can ask on the 
IETF list.

My overall impression is that the IESG's intent is to go beyond simply 
making everything available via HTTPS, and to actually make everything 
*default* to HTTPS so that it is the preferred mechanism. In specific 
practice, I could imagine this as something like 1) redirect HTTP gets 
of the web root to the HTTPS equivalent, and 2) change tools and 
documents so that all embedded links are HTTPS.

However the IESG statement also says that people and/or tools that wish 
to use HTTP will continue to be able to do so. Is this as simple as just 
making everything simultaneously available via HTTP? I note that this 
would potentially require the client to translate embedded links from 
HTTPS back to HTTP. Or is something more complicated required, such as a 
per-user setting (profile, cookie, or whatever), webhost regex, client 
request header, etc?

It's not entirely clear to me how we are going to implement this. Has 
somebody already figured this out? I'd be glad to learn that the answer 
is obvious and simple, and that my question is naive.

Thanks,
-Benson

---------- Forwarded message ----------
From: *The IESG* <[email-masked] 
<javascript:_e(%7B%7D,'cvml',[email-masked]');>>
Date: Mon, Jun 1, 2015 at 12:43 PM
Subject: Proposed Statement on "HTTPS everywhere for the IETF"
To: IETF Announcement List <[email-masked] 
<javascript:_e(%7B%7D,'cvml',[email-masked]');>>

Hi All,

The IESG are planning to agree an IESG statement on "HTTPS Everywhere
for the IETF," please see [1] for the current text.

We are seeking community feedback on this and welcome assistance
from the community in identifying any cases where a change or
additional guidance is needed to put this into effect.

The IESG plans to finalise this statement just after IETF-93 in Prague.

* Please send general feedback intended for discussion to [email-masked] 
<javascript:_e(%7B%7D,'cvml',[email-masked]');>

* Comments about specific issues arising can be sent to [email-masked] 
<javascript:_e(%7B%7D,'cvml',[email-masked]');>
or [email-masked] 
<javascript:_e(%7B%7D,'cvml',[email-masked]');> as appropriate 
(use [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');> if 
not sure)

Regards,
Terry & Stephen (for the IESG)

[1] https://trac.tools.ietf.org/group/iesg/trac/wiki/HttpsEverywhere

---

From: "Scott O. Bradner" <[email-masked]>
Date: Mon, 1 Jun 2015 22:25:23 -0400

the statement seems contradictory

if they are going to redirect http to https
then the “can keep using http” does not make much sense

Jari?

Scott

> On Jun 1, 2015, at 10:20 PM, Benson Schliesser <[email-masked]> wrote:
> 
> Reading the IESG statement on HTTPS Everywhere (link forwarded below), something remains unclear to me. I'm hopeful that somebody on this list has an informed view of this question. Otherwise I can ask on the IETF list.
> 
> My overall impression is that the IESG's intent is to go beyond simply making everything available via HTTPS, and to actually make everything *default* to HTTPS so that it is the preferred mechanism. In specific practice, I could imagine this as something like 1) redirect HTTP gets of the web root to the HTTPS equivalent, and 2) change tools and documents so that all embedded links are HTTPS.
> 
> However the IESG statement also says that people and/or tools that wish to use HTTP will continue to be able to do so. Is this as simple as just making everything simultaneously available via HTTP? I note that this would potentially require the client to translate embedded links from HTTPS back to HTTP. Or is something more complicated required, such as a per-user setting (profile, cookie, or whatever), webhost regex, client request header, etc?
> 
> It's not entirely clear to me how we are going to implement this. Has somebody already figured this out? I'd be glad to learn that the answer is obvious and simple, and that my question is naive.
> 
> Thanks,
> -Benson
> 
> 
> 
> From: *The IESG* <[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> To: IETF Announcement List <[email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>>
> 
> 
> Hi All,
> 
> * Please send general feedback intended for discussion to [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> 
> * Comments about specific issues arising can be sent to [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');>
> or [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');> as appropriate (use [email-masked] <javascript:_e(%7B%7D,'cvml',[email-masked]');> if not sure)
> 
> Regards,
> -- 
> Tools-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tools-discuss
> 
> Please report datatracker.ietf.org bugs at http://tools.ietf.org/tools/ietfdb
> Please report tools.ietf.org bugs at http://tools.ietf.org/tools/issues or
> send email to [email-masked]

---

From: Martin Thomson <[email-masked]>
Date: Tue, 2 Jun 2015 12:58:53 -0700

> then the “can keep using http” does not make much sense

My understanding was:

a) all services will be provided over https
b) "public" services will be provided over http (for some definition
of public that probably needs extra work)

---

From: Adam Roach <[email-masked]>
Date: Tue, 02 Jun 2015 16:13:01 -0500

On 6/1/15 21:20, Benson Schliesser wrote:
> 2) change tools and documents so that all embedded links are HTTPS

Incidentally, you can have constructs like this:

<a href="//datatracker.ietf.org/submit/">Submit a draft</a>

This link will use https: if it is in an https: page, and http: if it is 
in an http: page.

/a

---

From: Joe Touch <[email-masked]>
Date: Tue, 02 Jun 2015 17:08:07 -0700

> This link will use https: if it is in an https: page, and http: if it is

It's known as a "protocol relative URL", and referred to in RFC3986 as a
network-path reference. It's a variant of relative reference (e.g.,
"/goo.html" or "bah/goo.html", except that it also includes the network
path too.

Joe

---

From: Benson Schliesser <[email-masked]>
Date: Tue, 02 Jun 2015 18:12:48 -0700

> This link will use https: if it is in an https: page, and http: if it is

Yes. Off the cuff, I sort of feel like we should generally be using 
relative links anyway. I suspect that the #2 in my previous message 
(which is quoted above) would probably break stuff. Use of relative 
links seem like a better choice.

Building on this, would it be safe to redirect some set of HTTP requests 
to HTTPS? I'm thinking specifically of things like the web root where 
users might naturally navigate, and I'm assuming that we wouldn't want 
to do this for more specific URLs.

Further, I personally don't know nearly enough about these technologies, 
but I imagine that we should look into the use of 
upgrade-insecure-requests [1] and HSTS [2].

Finally, I noticed a message on the IETF list [3] in which Stephen 
Farrell says he's keeping a list of things we should do... So now I'm 
looking forward to seeing that list and hearing more feedback from this 
community.

Cheers,
-Benson

[1] - http://www.w3.org/TR/upgrade-insecure-requests/
[2] - http://tools.ietf.org/html/rfc6797
[3] - https://www.ietf.org/mail-archive/web/ietf/current/msg93300.html

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 03 Jun 2015 09:11:25 +0100

Hiya,

(note: I'm not on tools-discuss. I've read this thread in
the archive, but please do cc me if needed)

> links seem like a better choice.

Yep.

> upgrade-insecure-requests [1] and HSTS [2].

Right, there's a bit of figuring out to be done wrt HSTS and
the various (sub)domains we operate.

> looking forward to seeing that list and hearing more feedback from this

Yep, I'll do that in a few days. Right now I just have the
raw comments, but I'll try organise 'em a bit before making
that list available.

Cheers,
S.