Subject: Re: Proposed Statement on "HTTPS everywhere for the IETF"

From: Richard Barnes <[email-masked]>
Date: Mon, 1 Jun 2015 13:16:10 -0400

Do it.  Do it boldly and fearlessly.  Make the statement and implement it.

"""
However, as there may be tools that could be affected by this, and
recognising that there are a number of IETF participants who prefer to
continue to access materials via cleartext, or who have issues with using
standard confidentiality services, the IESG are also requiring that public
information continue to be made available in cleartext form.
"""

Don't be tied to legacy.  Anything that doesn't support HTTPS at this point
needs to upgrade and deserves to be broken.

The IETF needs to be a leader here.

--Richard

On Mon, Jun 1, 2015 at 12:43 PM, The IESG <[email-masked]> wrote:

> 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]
>
> * Comments about specific issues arising can be sent to [email-masked]
> or [email-masked] as appropriate (use [email-masked] if not sure)
>
> Regards,
> Terry & Stephen (for the IESG)
>
> [1] https://trac.tools.ietf.org/group/iesg/trac/wiki/HttpsEverywhere
>
>

---

From: Bob Hinden <[email-masked]>
Date: Mon, 1 Jun 2015 11:01:01 -0700

This has my support!

Bob

---

From: Niels Dettenbach <[email-masked]>
Date: Mon, 01 Jun 2015 20:55:57 +0200

> needs to upgrade and deserves to be broken.

...sorry guys, but please don't be so "blind" and "populistic".

I have no Problem with SSL/TLS as an general option (!) to access public IETF 
HTTP services / documents - but not as a general "fact". Pls implement DNSSEC 
and such stuff as far as not done att which makes more sense.

Beside the fact that the IETF has no own "accredited" SSL/x509 root in the 
major browsers and i assume the IETF would not use a non "certified" or "self 
signed" root - why should i "trust" and use any third party certification from 
any company i don't (want to and/or can) know? 

And why should (usually not thumb...) IETF readers / users are not able to 
decide if they want or "need" that TLS/SSL product the IETF would offer?

SSL/TLS would do no more then make shure that any third party company "trust" 
a connection to the IETF and as long as you "trust" them, the content (most of 
a still very public type) of your requests should not be readable by MitM - by 
their own policies which may be conform to the browsers / browser alliance 
policies (which is primarily a policy of high fees from my view...).

SSL/TLS does NOT deliver anonymity to the users - and the most parts of the 
IETF web content is public accessible. And people who need anonymity have 
other an probably even better ways to get that HTTP (i.e. cryptotunnels or TOR 
to anywhere who they are "safe").

Shure - TLS/SSL has their applications in different fields - but i can't 
follow this current "encrypt anything" attitude from different social vectors 
today (in germany we have the first politicans who would do that by law to any 
"internet communication"...). 

There are many scenarios where it is far from a "requirement" and even some 
where it is just non sense to block non encrypted / authenticated usage. 
Encryption costs energy (and even if you have the money - it generates at 
least further CO2) and other ressources - so it makes no sin to use it where 
it doesn't has a value at least from the users view. These effect is 
multiplied when even robots / agents / spiders and other automatized services 
where data integrity is not primarily or other reasons behind have only the 
option HTTPS.

The major resons the most peoples fighting today for that "encryping anything" 
thing i heared are usually:

	- "The NSA could read anything otherwise. We need our privacy integrity 
back..."

-> such services are much more interested in meta data of communication, which 
is even widely accessible for HTTPS / SSL / TLS "secured" connections and it 
IS accessible not at least because governments / democracies are giving them 
access top by law. Change the law if you would change that - but don't cripple 
the non-political net.

-> And if "the NSA" (or many others "services") want to get into a software 
product or encryption stack, they have many options by law - even in other 
countries.

	- "The Mozilla Team" and/or "well known peoples around" that scene has 
announced, that Firefox will block "unencrypted", "non ssl" HTTP in "future 
versions" as a "Feature" for their users.

-> Beside the fact that i wouldnÄ't use Firefox anymore at that time - even if 
Firefox is an Open Source product, but not a "pure" community project - the 
browser project still makes his own money - not at least by selling licenses 
to companies which want to print money by "certifying" for that browsers (in 
SSL / TLS / x509). Take a look at the (at least formerly) yearly fees 
("audition fees" or such called, but much higher then a certification does 
take as work...) they take and you will take a new voew onto their "high 
skilled arguments from a pure technical view"...

Ergo: The HTTP SSL and TLS technology and infrastructure is useful in much 
more special scenarios then most peoples think it is - because of very 
difficult and complex, intransparent collidation of interests of different 
parties in the current (trust) structure.

 - And: there ARE poeples and services which doen't allow encrypted access for 
legal or organisational reasons - it would not be nice to block interested 
poeples from such user "societies" which are not usually free to decide for an 
alternative byself.

And for me personal: I use a 7 year old cell phone to read http stuff in my 
spare time and do not understand why i should buy a new one for the very same 
application. "legacy" means that there are newer standards which offer ME more 
value i WANT - and not others mean that i HAVE TO WANT. Buying a new phone for 
just using encryption i don't want is non sense. I would could afford it, but 
i (personally) think the ressources are better to use otherwhere (or even not 
used).

in short:

+1 for SSL as an option (ideally with IETFs own x509 root CA)
-1 for blocking plain text HTTP at general

just my two cents - sorry for the noise,
and my (probably) bad english,

Niels.

-- 
 ---
 Niels Dettenbach
 Syndicat IT & Internet
 http://www.syndicat.com
 PGP: https://syndicat.com/pub_key.asc
 ---

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 01 Jun 2015 22:13:41 +0200

Just to put on record: I disagree with Niels and agree with the IESG. 
Encryption everywhere is good.

Once a connection is encrypted and certificate-protected, a whole class 
of worries can be removed from the threat models; having fewer things to 
worry about is great when designing protocol stacks.

The only issue I have with the document is that "great-cannon" is 
spelled as "great-canon" once.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 02 Jun 2015 08:15:06 +1200

Hi,

I think this is reasonable. However, it seems necessary to qualify it
by pointing out that users of HTTPS remain exposed to traffic analysis
(e.g. see https://arxiv.org/pdf/1403.0297).

    Brian

On 02/06/2015 04:43, The IESG wrote:
> .

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 01 Jun 2015 21:34:57 +0100

Hiya,

> (e.g. see https://arxiv.org/pdf/1403.0297).

Good point. We can add something to that effect I think.

Cheers,
S.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 1 Jun 2015 16:58:07 -0400

> (e.g. see https://arxiv.org/pdf/1403.0297).

Agreed.

But I would add a note to say that blocking traffic analysis is something
that requires link layer encryption. I don't think we can do much to
prevent that type of attack in IETF but we could stir IEEE to do something
useful.

---

From: Nico Williams <[email-masked]>
Date: Mon, 1 Jun 2015 16:03:21 -0500

> prevent that type of attack in IETF but we could stir IEEE to do something

Traffic analysis might be happening far from the client, and might be
happening on middle boxes controlled by the attacker.  (Which is not to
say that we shouldn't bother with link-layer encryption in addition to
end-to-end encryption.)

There are many traffic analysis considerations.  For this particular
purpose it should suffice to refer to traffic analysis in general.
Though it might be useful to add recommendations about things like
length masking (since otherwise even just the lengths of packets might
suffice to identify the resources a user is accessing).

Nico
--

---

From: "Niels Dettenbach (Syndicat.com)" <[email-masked]>
Date: Mon, 01 Jun 2015 23:18:39 +0200

>Encryption everywhere is good.
You mean  Evers public information should be encrypted? I.e. Radio vor TV? Can't see the "feature", sorry...

>Once a connection is encrypted and certificate-protectedhole class
>

This is correct by theory in many, but not all cases and not in practice.

A https geht takes up to multiple times of energy and computing resources. I prefer efficiency even in protocols - resources should be user for real (not only theoretic) added value.

Browser HTTP-SSL/TLS isn't "just encrypt and forget" as long as you really unterstand the whole infrastruture and setup in practice including their implications today - and not in theory only. This is not like and comparable with the migration from telnet to SSH and even not with SMTP TLS/SSL...

And getting a faked x509 i.e. for mitm is more a question of some money and/or third party CA securitiy and not at first of secure crypto algos or similiar.

And blocking plaintext http is no feature - it is at max a lack of...

Sorry...

best regards,

Niels.
- ---
Niels Dettenbach
Syndicat IT & Internet
http://www.syndicat.com

---

From: "Niels Dettenbach (Syndicat.com)" <[email-masked]>
Date: Mon, 01 Jun 2015 23:18:43 +0200

Sorry...

best regards,

Niels.
- ---
Niels Dettenbach
Syndicat IT & Internet
http://www.syndicat.com

---

From: Paul Wouters <[email-masked]>
Date: Mon, 1 Jun 2015 17:27:39 -0400 (EDT)

> poeples from such user "societies" which are not usually free to decide for an

And that resoning is exactly how we _got_ into this mess in the first
place. We had to cater to governments banning encryption for its users,
and we now see what that got them. I can no longer prevent goverments
interpreting my online self based on 20 years of data, but I sure hope
we can prevent that for future generations. We should have said no to
governments in the previous crypto war - and we definitely have to say
no now.

Enterprise users are no problem, they have enterprise-issued local policy
and can override all the TLS they want with MITM certs and proxies and
mandated software on the enterprise hardware.

> application.

A cell phone that cannot do SSL/TLS (or worse, 7 year old SSL only) is
a danger to its owner and possibly to the internet at large if it is
owned by botnets already.

Paul

---

From: "Roland Dobbins" <[email-masked]>
Date: Tue, 02 Jun 2015 05:41:17 +0700

On 2 Jun 2015, at 4:27, Paul Wouters wrote:

> We had to cater to governments banning encryption for its users, and 
> we now see what that got them.

They just go around the encryption and compromise the endpoints.  
They're *governments*, so they have the resources to do that (not 
debating whether or not they should, just stating observed fact).

Also, universal or near-universal encryption is a serious problem in 
terms of detection, classification, traceback, and mitigation of 
application-layer DDoS attacks.  It drastically limits the scaling 
capacity of defenders, and results in even more cost asymmetry between 
defenders and attackers (in favor of the attackers).

My guess is that those who make bold, sweeping statements about how 
everything ought to be encrypted all the time are rarely those who have 
to deal with the unintended consequences of overencryption.

In the final analysis, there are no technical solutions for social ills. 
  The entire issue of unwanted surveillance by government entities is a 
social and political problem; it seems pretty clear that since the 
social/political side of things aren't proving to be easily resolved, 
that some folks are advocating doing *something*, *anything*, 
irrespective of whether it will actually make a positive impact on the 
conditions to which they object and without regard to the non-trivial 
side-effects of what they're advocating.

The IESG and the IETF in general should concentrate on technical issues, 
and work on solving social and political problems should take place in 
other, more appropriate appropriate fora, IMHO.

-----------------------------------
Roland Dobbins <[email-masked]>

---

From: "Roland Dobbins" <[email-masked]>
Date: Tue, 02 Jun 2015 05:44:20 +0700

On 2 Jun 2015, at 3:13, Harald Alvestrand wrote:

> Once a connection is encrypted and certificate-protected, a whole 
> class of worries can be removed from the threat models; having fewer 
> things to worry about is great when designing protocol stacks.

However, as noted in my previous reply, other classes of worries are 
added.

TANSTAAFL.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 01 Jun 2015 23:54:20 +0100

> debating whether or not they should, just stating observed fact).

The proposed statement itself quotes two apparent counter examples
where (allegedly:-) governments used man on the side attacks and
at apparently significant scale.

> defenders and attackers (in favor of the attackers).

Please contribute concrete text on the technical details of that
to [1]. We do need to document the changes (including downsides)
caused by encrypting more. Text is very welcome for that. (Best
sent to [email-masked] or the authors.)

   [1] https://tools.ietf.org/html/draft-mm-wg-effect-encrypt

> to deal with the unintended consequences of overencryption.

I hope that this discussion doesn't go down the purely distracting
rathole of statements like "everything ought to be encrypted all
the time" - that is as related to this statement as pixie dust
security solutions are to reality, regardless of what position one
adopts in relation to encryption.

That said, I suppose it's inevitable that this discussion at least
looks at the top of that rathole;-) I do hope it's a passing glance
only though.

> other, more appropriate appropriate fora, IMHO.

I don't see how that corresponds to the proposed IESG statement at
all.

S.

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 01 Jun 2015 23:59:13 +0100

Paul,

On 01/06/15 22:27, Paul Wouters wrote:
> We should have said no to

I don't think this statement is anywhere near so directly related to
governments. While the recent man on the side attacks were
(allegedly:-) carried out by governments, that seems to be mostly a
matter of who did what first. Changes like using https by default have
much broader justifications.

S.

---

From: "Roland Dobbins" <[email-masked]>
Date: Tue, 02 Jun 2015 06:00:42 +0700

On 2 Jun 2015, at 5:59, Stephen Farrell wrote:

> Changes like using https by default have much broader justifications.

They also have much broader objections.

---

From: Nico Williams <[email-masked]>
Date: Mon, 1 Jun 2015 18:22:08 -0500

> They also have much broader objections.

Broad enough to stop the IETF from making the statement we're
discussing?  Your objections w.r.t. DoS attack characterization are
hardly "broad" enough.

Nico
--

---

From: "Mark Baugher (mbaugher)" <[email-masked]>
Date: Mon, 1 Jun 2015 23:56:59 +0000

+1
On Jun 1, 2015, at 3:41 PM, Roland Dobbins <[email-masked]> wrote:

>> We had to cater to governments banning encryption for its users, and we now see what that got them.
> 
> They just go around the encryption and compromise the endpoints.  They're *governments*, so they have the resources to do that (not debating whether or not they should, just stating observed fact).
> 
> Also, universal or near-universal encryption is a serious problem in terms of detection, classification, traceback, and mitigation of application-layer DDoS attacks.  It drastically limits the scaling capacity of defenders, and results in even more cost asymmetry between defenders and attackers (in favor of the attackers).
> 
> My guess is that those who make bold, sweeping statements about how everything ought to be encrypted all the time are rarely those who have to deal with the unintended consequences of overencryption.
> 
> In the final analysis, there are no technical solutions for social ills.  The entire issue of unwanted surveillance by government entities is a social and political problem; it seems pretty clear that since the social/political side of things aren't proving to be easily resolved, that some folks are advocating doing *something*, *anything*, irrespective of whether it will actually make a positive impact on the conditions to which they object and without regard to the non-trivial side-effects of what they're advocating.
> 
> The IESG and the IETF in general should concentrate on technical issues, and work on solving social and political problems should take place in other, more appropriate appropriate fora, IMHO.
>

---

From: Sam Hartman <[email-masked]>
Date: Mon, 01 Jun 2015 20:21:01 -0400

>>>>> "Paul" == Paul Wouters <[email-masked]> writes:

    Paul> On Mon, 1 Jun 2015, Niels Dettenbach wrote:
    >> - And: there ARE poeples and services which doen't allow
    >> encrypted access for legal or organisational reasons - it would
    >> not be nice to block interested poeples from such user
    >> "societies" which are not usually free to decide for an
    >> alternative byself.

I've heard this assertion made multiple times.

As a software developer, I'd really appreciate  some concrete examples
of places that

* Generally permit public access to the Internet

* Prohibit https access.

I'm aware of organizations that:

* Don't want public access to the Internet.  For example please don't
surf the web from your cash register; isolated networks; white-list only
access.

* Places that require https traffic to go through a proxy that attempts
  to examine everything

* Places that inject an https root so they can MITM traffic

I don't think it's our job to make it easy to access the ietf's
resources from places that are trying to block access to us either in a
targeted manner or because they block large chunks of the internet whose
criteria would include the ietf.  Similarly, if an organization's policy
is that you have to use some proxy to access the IETF, I don't see a
problem with that.  Where are these places that block encrypted traffic
but are generally interested in public internet access?  I would like to
better understand real-world examples of these so I can factor them into
software design decisions.

---

From: S Moonesamy <[email-masked]>
Date: Mon, 01 Jun 2015 17:54:26 -0700

>for the IETF," please see [1] for the current text.

The rules for "HTTPS Everywhere" are:

   from "^http://(www\.)?ietf\.org/" to "https://www.ietf.org/"
   from "^http://(tools|datatracker)\.ietf\.org/" to "https://$1.ietf.org/"

My reading of the proposed statement is that "all IETF information 
must, by default, be made available in a privacy friendly form" 
(HTTPS [1]) and that "all links to such information (e.g. href's in 
html) should default to causing access via" HTTPS [1].  Is the first 
part of that some kind of rewrite rule on the server-side?

I did a quick test by accessing www.ietf.org and it took about two 
seconds without the "S" and about seven seconds with the "S".  The 
extra seconds is a bit slow but it is okay if the objective is to 
have some confidentiality.  The note in the proposed statement covers 
more than the title of the proposed statement.

Regards,
S. Moonesamy

1. HTTPS URIs and appropriate TLS cipher-suites

---

From: "John Levine" <[email-masked]>
Date: 2 Jun 2015 01:22:56 -0000

>> legal or organisational reasons - 

It doesn't have to be anything that deliberate.  On my mobile phone, I
run into web sites all the time where for some reason the phone
doesn't like the SSL certificate and makes it very difficult to click
through.  They work fine on my Mac and Linux boxes, so who knows
what's wrong.  Given the absurd number of CAs, it's probably some
mismatch of intermediate certs, and I could track it down and fix it
eventually, but in the meantime, it would be nice if I still had the
option to look at the fripping stuff.

We should be able to assume our users are big girls and boys who can make
reasonable tradeoffs in the face of the inevitable failure of some of the
moving parts.

R's,
John

---

From: Eliot Lear <[email-masked]>
Date: Tue, 02 Jun 2015 06:44:05 +0200

If I understand the intent of this statement, that this is for IETF
services to be encrypted via TLS at this point in time, and that clear
text will continue to be supported, then I strongly support that tooling
approach, statement or no statement, being pursued by the secretariat. 
I support this approach not because the IETF communications contain
massive amounts of private data (I wouldn't imagine this is not true),
but because we need to be eating our own dog food so that we understand
the sorts of pitfalls others will face when we emplore them to encrypt. 
This way we can first face those issues and perhaps address them.

It would be helpful to understand what this statement will mean in
practical terms in the near future.  If what we are saying is that the
secretariat will pursue alternatives to the current rsync / ftp
approaches, that's fine.  It's what I was suggesting in the last round
of discussions.  Is git in our near future (not objecting, just wondering)?

With regard to plain text, it would be helpful if the secretariat could
report how much plaintext is actually accessed, and if at all possible,
by the number of different "users", so that we can determine when – if
ever – to turn off plain text.  It may also help us understand if there
are certain geographies that are not accessing encrypted information.

And yes, as always, I prefer decisions to be documented in RFCs but I
care far less in this case, since it is a policy that would direct the
secretariat and not participants.

Eliot

---

From: "Patrik Fältström" <[email-masked]>
Date: Tue, 02 Jun 2015 07:34:33 +0200

> * Places that inject an https root so they can MITM traffic

Last time I encountered this was at Pain de Quotidien in Washington DC on 17th street.

And I discovered it when I saw my IMAP connection was hijacked.

   Patrik

---

From: Eliot Lear <[email-masked]>
Date: Tue, 02 Jun 2015 07:40:12 +0200

This is what I get for sending BEFORE coffee:

On 6/2/15 6:44 AM, Eliot Lear wrote:
> massive amounts of private data (I wouldn't imagine this is not true)
Make that "I would imagine this is not true."

Eliot

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 02 Jun 2015 08:24:56 +0200

On 06/01/2015 11:18 PM, Niels Dettenbach (Syndicat.com) wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>

have you looked at your cable TV lately? Or your DAB radio?
> A https geht takes up to multiple times of energy and computing resources. I prefer efficiency even in protocols - resources should be user for real (not only theoretic) added value.

See the Great Cannon attack. Allowing in-flight modification of 
resources (which using HTTP is) is not just a theoretical danger to 
yourself, it's a practical danger to anyone on the Net.

But since you're not convinced by the language of the IESG note, me 
repeating it won't make you more convinced. Sorry 'bout that.
> Browser HTTP-SSL/TLS isn't "just encrypt and forget" as long as you really unterstand the whole infrastruture and setup in practice including their implications today - and not in theory only. This…

It's more comparable with the transition from bang-path addresses to DNS 
notation, yes.
> And blocking plaintext http is no feature - it is at max a lack of...

Not a part of this proposal.
>
> Sorry...
>
>
> best regards,
>
> Niels.
> - ---
> Niels Dettenbach
> Syndicat IT & Internet
> http://www.syndicat.com
> -----BEGIN PGP SIGNATURE-----
>
> iQJZBAEBCABDPBxOaWVscyBEZXR0ZW5iYWNoIChTeW5kaWNhdCBJVCAmIEludGVy
> bmV0KSA8bmRAc3luZGljYXQuY29tPgUCVWzMLwAKCRANu1qIRZIqRBm5D/43u9NJ
> Ex2CxQwIXUcuPaPEr/2geCTgGgRBnUb46fzVwf5OlPnQqA+urr1EajpY3XRdWF5r
> jmqnfS/ESYL4q3DV3CC8mW1a4uZWQX85+2fvCra8/nzyKP653jAZvSuqGZAnzGuq
> ZDM33932y5GKcPLl86C7WG/QqZ7Yb6SPukTUnDY5z0DcbyBIgqAwF0D3N5P7dk49
> iaZY31z1F7rI1PvPS874sH4NVnSUh1N8OakRy5tCtQn4WVlaN1WBu+bzzCmsudgw
> Oh7o/BWKFGzDTNGpfsyqmzcepHsmoAPcCtbrQOadX2HFxjqzB+NJwwSLSn9koQlH
> xnDhDkx0avolGa3nciubPTSJkAp1wFXj9e0zeJX8dGTOjzyJTDrDxNnYkszTnSS/
> X0HnoDo3Uo638Ho9sAcweZJ3XNibNNn5ekdU9kd/rBAIHaWG1m4zshMglupJPyst
> u0fvqBJi8AXznQ2Qv27CwjNWQSV37NFZcrkzg22f4GB43MJ1+utgTvEX2ft7uhrz
> HJug38x8BH0vrLXpcvlKA2f6SaOCfIhCoqv4+SLVHQLE7IoG2ZxdoY4795ORGHFc
> NsyfMB1ah52E3/pZjS1NhFhr4ndUQg5jp0eaLF5XhteRS2Zlw8wmYlP2qicpe3T2
> S4tO7+56PhnsZQhB8GnDZMnPN9HgD9KsMNEWGg==
> =5dba
> -----END PGP SIGNATURE-----
>

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 02 Jun 2015 15:45:00 +0900

Hi,

Though the proposal relies on BCP195, I'm afraid there is a serious
contradiction between the following statements in BCP195:

   o  Ticket keys MUST be changed regularly, e.g., once every week, so
                                                   ^^^^^^^^^^^^^^^
      as not to negate the benefits of forward secrecy (see Section 6.3
      for details on forward secrecy).

and

   o  If exponents are reused for too long (e.g., even more than a few
                                                  ^^^^^^^^^^^^^^^^^^^^
      hours), an attacker who gains access to the host can decrypt
      ^^^^^
      previous connections.  In other words, exponent reuse negates the
      effects of forward secrecy.

that it must be revised to shorten the duration of the former
statement before being used for the real world security.

Also, it should be honest to state that HTTPS for IETF may be
useless against USG surveillance.

							Masataka Ohta

---

From: Jari Arkko <[email-masked]>
Date: Tue, 2 Jun 2015 09:54:43 +0300

Folks,

We shouldn’t assign a bigger meaning for this change than what it really is.
Of course it is important that we eat our own dogfood, and of course there
are some privacy benefits.

But ultimately, this is a change about the defaults for our own web services.
Today, in a lot of the cases the default is cleat ext and while I can access the
secure content, I have to edit the URL to add ’s’. Tomorrow, this would be
reversed.

In other words, people can still select their method of access when they
need to. There are obviously broader issues in the Internet around
confidentiality, but this particular action is about our own website
and traffic to it.

We will (and have) of course participate the broader discussion and 
contribute technology that can help make the Internet more privacy
friendly. But that is more about the various solutions we produce,
such as improving efficiency of turning on crypto which HTTP/2 and
TLS 1.3 help, or fixing bad algorithms or issues in protocols. Lets
get to continuing that work!

Jari

---

From: "Roland Dobbins" <[email-masked]>
Date: Tue, 02 Jun 2015 13:59:22 +0700

On 2 Jun 2015, at 6:22, Nico Williams wrote:

> Your objections w.r.t. DoS attack characterization are hardly "broad" 
> enough.

If the IETF wish to make HTTP/S the default access mechanisms for RFCs, 
drafts, etc., that's fine.  My point is that the larger 'HTTP/S 
everywhere' campaign has serious drawbacks, and that the problems it 
causes in broadening the DDoS attack surface while at the same time 
making it more difficult and expensive for defenders to mitigate DDoS 
attacks are both broad and quite serious.

And I strongly suggest that the IETF stay out of socio-political issues 
and stick to its knitting with regards to technical innovation.

---

From: "Niels Dettenbach (Syndicat.com)" <[email-masked]>
Date: Tue, 02 Jun 2015 09:09:25 +0200

>get to continuing that work!

full ack,
thanks
+1

Niels.
- ---
Niels Dettenbach
Syndicat IT & Internet
http://www.syndicat.com

---

From: Niels Dettenbach <[email-masked]>
Date: Tue, 02 Jun 2015 10:40:01 +0200

> have you looked at your cable TV lately? Or your DAB radio?
Encrypting publically accessible TV vor radio content just could bring added value for the Distributor / provider - i.e. by avoiding any not paid usage by thirds or using other Hardware.

There is usually no value for the recipient (possibly except Pay-TV products), but significant less freedom and for this reason i.e. basic TV encryption in cable networks was prohibited by the federal cartel office these days here in germany (german):
http://www.heise.de/newsticker/meldung/TV-Grundverschluesselung-Freie-Sicht-bei-Unity-Media-1776052.html

> yourself, it's a practical danger to anyone on the Net.
HTTPS "Encryption" byself is not targeting MitM "modifications" - this is mainly a part of signatures (in HTTPS "realized" by "certificates"). Avoiding modifications MitN is (technically) possible "just" by signatures or hashes (in theory...).

HTTPs rely fully on signatures from any third Party a user has to trust in full plus he has to check the FULL certification path for each website he want to use (by theory...). 

It is not a simple question of "is it green in the Browsers line?" as the very most of users think today in practice... The browser distributors has no interest in changing that view, because the status quo leads to more dependence from their licensing politics. This is why some browsers i.e. make it more and more diffucult to use HTTPS in private networks where they have no fitting "SSL" product for.

If you just find ONE of the up to hundreds of Browser CAs (or at least some cross/sub CA contractor) today where one is providing you a certificate for and third Party you have it compromized "silently" even it it uses a "very famous and reliable and expansive CA product byself" - the browsers line "is green" while MitM - voila. Same happens with compromized CAs (remember i.e. the publically known Comodo hack some years ago...).

Beside the fact that HTTPs even delivers no "privacy" for the users of public static web content (public web sites, focussed document archives and mailing list archives i.e.) - what leaves as "added value" for them if you BLOCK HTTP for such content - i mean value which makes the costs of energy and resources worth?

> repeating it won't make you more convinced. Sorry 'bout that.
Sorry if i really misunderstanded a part of (reacted mainly onto other posts in this topic). If HTTP will be available for any public ("static") part of the IETF HTTP this would be fully OK for me - even "preferring" HTTPS over HTTP by HTTP redirects or similiar while offering a "button"/link (SSL/TLS "on/off" or "by hand") or similiar options (i.e. while using relative URL's)

Sorry for the noise, if so...

It would be nice if the IETF would be one instance helping to develope new and transparent standards the "todays" x509 HTTPS for trust and encryption, i.e. where users can decide which "CA" / "trustee" they want to trust (and possibly which algorithms) etc.pp. and don't have to "trust" any single third party company, government or organisation and away from the todays still static view onto SSL/HTTPS "security" (the incorrect "is it secure or not" paradigm).

I wrote (possibly a bit more then) "enough" now in this topic - will retract from now - sorry for the noise...

best regards,

Niels.

---

From: Niels Dettenbach <[email-masked]>
Date: Tue, 02 Jun 2015 10:52:53 +0200

> And I discovered it when I saw my IMAP connection was hijacked.
around five years ago in a Marriot Hotel in Canada (Hamilton / Ontario). 

IMAPs and POP3s was blocked, IMAP, POP3 and SMTP TLS ("inline") was blocked by 
a proxy. The proxy seemed to stay anywhere in the US. But after some fiddeling 
i was able to tunnel out there otherwise at that time...

Don't know if it is the same today...

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 2 Jun 2015 20:27:51 +1000

I support this policy.

I'd suggest that if it's felt that cleartext content needs to be available, it NOT be at <http://www.ietf.org/> (and similar); it should be on a different hostname; e.g., <http://www.cleartext.ietf.org/>. The http version of the URL should 301 to the corresponding https resource, and HSTS should be in use. 

Also, part of the reason for requiring HTTPS is that the Web platform is becoming more powerful, and so it's more vulnerable to a wide variety of attacks on the capabilities of the browser (e.g., camera, geolocation, local storage, etc.) — not just information leakage. See: <https://w3ctag.github.io/web-https/>.

Regards,

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

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 02 Jun 2015 11:51:49 +0100

I agree with the comments that the IETF should lead on
the technology and leave the societal and political
issues alone. Technology is our core skill and remit,
but sociology and politics are not.

- Stewart

---

From: Jari Arkko <[email-masked]>
Date: Tue, 2 Jun 2015 14:41:08 +0300

> I support this policy.

Thanks.

> I'd suggest that if it's felt that cleartext content needs to be available, it NOT be at <http://www.ietf.org/> (and similar); it should be on a different hostname; e.g., <http://www.cleartext.ietf…

That’s very good feedback - thanks. We will take it into consideration.

Jari

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 02 Jun 2015 12:55:33 +0100

Hi Eliot,

I think the work to be done is fairly obvious for most things,
for example replacing http URIs with https URIs in new I-Ds,
though HSTS over all our domains has a bit of trickiness. We'll
also probably want to talk with the meetecho folks to see what
can be done there, that makes sense to do. More generally, I'd
expect this'll basically turn into a standing requirement (like
IPv6) that the secretariat will build into consideration of
ongoing or new work and it'll just be handled as we go.

One thing we'll all want (I hope:-) to do is to go edit our
bookmarks - I used have a load of those with http URIs and it's
really easy to forget to update those.

Cheers,
S.

---

From: <[email-masked]>
Date: Tue, 2 Jun 2015 12:00:49 +0000

see TimBL's "don't break the web" request to keep the uris the same, regardless of method of access.

http://www.w3.org/DesignIssues/Security-NotTheS.html
________________________________________
From: ietf <[email-masked]> on behalf of Jari Arkko <[email-masked]>
Sent: Tuesday, 2 June 2015 9:41:08 PM
To: Mark Nottingham
Cc: [email-masked]
Subject: Re: Proposed Statement on "HTTPS everywhere for the IETF"

Thanks.

Jari

---

From: Ted Lemon <[email-masked]>
Date: Tue, 2 Jun 2015 08:48:07 -0400

On Jun 2, 2015, at 8:00 AM, <[email-masked]> <[email-masked]> wrote:
> see TimBL's "don't break the web" request to keep the uris the same, regardless of method of access

With hsts, Sir Tim's broken url objection goes away, I think. The idea of doing http and having a certificate appear as a UI indication that the document was downloaded securely is bad design. It's too easy to fake, and users typically don't understand anyway. The goal should be to make it secure, not to tell the users it is secure.

---

From: Joe Touch <[email-masked]>
Date: Tue, 02 Jun 2015 09:59:27 -0700

> Do it.  Do it boldly and fearlessly.  Make the statement and implement it.
...
> Don't be tied to legacy.  Anything that doesn't support HTTPS at this
> point needs to upgrade and deserves to be broken.

Leaving out the have-nots - or those whose access is blocked by others
when content cannot be scanned - isn't moving forward.

HTTP isn't legacy. It's open. I thought the IETF was too.

Joe

PS - I noticed you didn't PGP-sign this post. Hello, pot.

(ref: http://en.wikipedia.org/wiki/The_pot_calling_the_kettle_black)

---

From: Ted Lemon <[email-masked]>
Date: Tue, 2 Jun 2015 14:02:27 -0400

> when content cannot be scanned - isn't moving forward.

That would certainly be a problem if the consensus were not to provide both a secure and an, as you call it, "open" version of all IETF documents.

---

From: Joe Touch <[email-masked]>
Date: Tue, 02 Jun 2015 11:05:38 -0700

On 6/2/2015 11:02 AM, Ted Lemon wrote:
> That would certainly be a problem if the consensus were not to
> provide both a secure and an, as you call it, "open" version of all IETF documents.

The IETF is more than just the documents.

All IETF content should be accessible via non-secure means.

Joe

---

From: Ted Lemon <[email-masked]>
Date: Tue, 2 Jun 2015 14:13:48 -0400

> All IETF content should be accessible via non-secure means.

Yes, I agree, and as I said I think that's the consensus.   What I mean by "IETF documents" is what you mean by "IETF content," and I apologize for my lack of clarity—I was not merely referring to RFCs and internet drafts.

That said, there's clearly some reason why you responded, I think to something that I said, by raising the concern that some public IETF content might not be accessible in this way.   So probably the right thing to do is figure out if you still think that someone is proposing a solution which would have that as its result, and if so, explain why you think that, since it likely means that some technical problem was overlooked either in what I said or what was said previously.

---

From: Joe Touch <[email-masked]>
Date: Tue, 02 Jun 2015 11:19:29 -0700

...
> Yes, I agree, and as I said I think that's the consensus. 

Agreed.

I was primarily addressing the concerns raised in Richard Barnes' post.

I do not think we need to revisit this issue for either HTTP or email
for the IETF.

Joe

---

From: Richard Barnes <[email-masked]>
Date: Tue, 2 Jun 2015 14:51:20 -0400

> when content cannot be scanned - isn't moving forward.

[citation-required]

Where is this place where the entire HTTPS web is not accessible?  How do
they do their banking, or buy things?

That said, though, I agree with you and Ted that there's consensus to
proceed with *adding* HTTPS-based access.  Let's turn on HTTPS and HSTS as
a first step, see how many 9s of the user base that gets us.

--Richard

---

From: Joe Touch <[email-masked]>
Date: Tue, 02 Jun 2015 11:59:03 -0700

On 6/2/2015 11:51 AM, Richard Barnes wrote:
> 
> 
> On Tue, Jun 2, 2015 at 12:59 PM, Joe Touch <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> Where is this place where the entire HTTPS web is not accessible? 

http://en.wikipedia.org/wiki/Censorship_of_Wikipedia

Search for HTTPS.

> How do they do their banking, or buy things?

Often through state-run companies (i.e., whose HTTPS content they can
screen).

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 03 Jun 2015 09:05:49 +1200

Hi Stewart,
> but sociology and politics are not.

Correct, but we have consistently (since the debate that led to
RFC 1984) taken the position that regulation that damages security
or privacy (e.g. by restricting encryption or mandating back doors)
is technically undesirable.

However, that isn't at issue here. It's simply the IETF following
some version of best practice, without sacrificing our commitment to
open development of open standards.

   Brian

---

From: Richard Barnes <[email-masked]>
Date: Tue, 2 Jun 2015 17:19:12 -0400

> http://en.wikipedia.org/wiki/Censorship_of_Wikipedia

This is all that that search turns up:
"""
Chinese authorities started blocking access to the secure (https) version
of the site on 31 May 2013, although the non-secure (http) version is still
available – the latter is vulnerable to keyword filtering allowing
individual articles to be selectively blocked. Greatfire urged Wikipedia
and users to circumvent the block by using https access to other IP
addresses owned by Wikipedia.
"""

If censors want to block the IETF website, they can do it with or without
HTTPS.  Non-secure HTTP just gives them more information.

Try again?

--Richard

---

From: Joe Touch <[email-masked]>
Date: Tue, 02 Jun 2015 14:26:20 -0700

On 6/2/2015 2:19 PM, Richard Barnes wrote:
> 
> 
> On Tue, Jun 2, 2015 at 2:59 PM, Joe Touch <[email-masked]
>     > On Tue, Jun 2, 2015 at 12:59 PM, Joe Touch <[email-masked] <mailto:[email-masked]>
>     > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>     >
> Chinese authorities started blocking access to the secure (https)
> version of the site on 31 May 2013, although the non-secure (http)
> version is still available – the latter is vulnerable to keyword
> filtering allowing individual articles to be selectively blocked.
> Greatfire urged Wikipedia and users to circumvent the block by using
> https access to other IP addresses owned by Wikipedia.
> """
> 
> If censors want to block the IETF website, they can do it with or
> without HTTPS. 

But that's not what they DID.

They blocked the activity they couldn't monitor.

Joe

---

From: Richard Barnes <[email-masked]>
Date: Tue, 2 Jun 2015 17:30:40 -0400

> They blocked the activity they couldn't monitor.

I would rather not preemptively knuckle under to censorship.  If it turns
out that we turn on HTTPS and nobody can see it, we can adapt to that fact.

--Richard

---

From: Joe Touch <[email-masked]>
Date: Tue, 02 Jun 2015 14:39:43 -0700

On 6/2/2015 2:30 PM, Richard Barnes wrote:
...
> I would rather not preemptively knuckle under to censorship.

You have that luxury.

Don't make that decision for others.

> If it
> turns out that we turn on HTTPS and nobody can see it,

This isn't a hypothetical. There's harm even if blocking isn't universal.

> we can adapt to that fact.  

We are (by consensus) - by continuing to use HTTP.

Joe

---

From: Mark Andrews <[email-masked]>
Date: Wed, 03 Jun 2015 11:54:43 +1000

In message <2036457.vXnxjqSTLC@gongo>, Niels Dettenbach writes:
> Am Dienstag, 2. Juni 2015, 07:34:33 schrieb Patrik Fältström:>
> > Last time I encountered this was at Pain de Quotidien in Washington DC
> on
> > 17th street.
> >

And almost always they are trying to get to you agree to the terms
required to use the network (which no one reads) and go away once
you do so.  Basically is pointless nonsence to get you to click a
button.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Sam Hartman <[email-masked]>
Date: Tue, 02 Jun 2015 22:23:04 -0400

>>>>> "Mark" == Mark Andrews <[email-masked]> writes:

to be clear, none of this is the sort of thing I was looking for.  All
of this is discussions of parts of the Internet that aren't particularly
transparent or interested in letting you have open access to large
portions of the net.
I don't care if the ietf website is accessible from a hotel before you
accept the network's terms.

Based on the discussion so far I'd like to see better justification for
the claim that there are portions of the network that block TLS before
we make it.

---

From: Jari Arkko <[email-masked]>
Date: Wed, 3 Jun 2015 06:55:06 +0300

I am not sure the discussion about blocking is relevant. We will change defaults, but cleartext is still available.

Jari

---

From: Xiaoyin Liu <[email-masked]>
Date: Wed, 3 Jun 2015 04:51:15 -0400

> Date: Tue, 2 Jun 2015 14:26:20 -0700
> From: [email-masked]
> To: [email-masked]
> CC: [email-masked]; [email-masked]
> 
> 
> 
 
This information is outdated. The https version of Wikipedia is no longer blocked in China, but the http versions of Chinese Wikipedia, Chinese Wikisource, Chinese Wikinews, and Uyghur Wikipedia are blocked in China.[1] Actually the Wikimedia Foundation is considering forcing HTTPS for every Wikipedia visitors, even if the censorship of Wikipedia exists.[2]
 
[1] https://zh.wikipedia.org/wiki/Template:Wiki-accessibility-CHN (in Chinese)
[2] https://phabricator.wikimedia.org/T49832#1240760
 
> They blocked the activity they couldn't monitor.
 
Another example is that http://www.worldcat.org/ is blocked in China, but https://www.worldcat.org/ is accessible.
 
So my opinion is that, in general, HTTPS is more accessible than HTTP.
 
Xiaoyin

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 03 Jun 2015 10:20:57 +0100

> All IETF content should be accessible via non-secure means.
s/should/MUST/

Stewart

---

From: t.p. <[email-masked]>
Date: Wed, 3 Jun 2015 11:56:01 +0100

----- Original Message -----
From: "Stewart Bryant" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, June 03, 2015 10:20 AM
> > All IETF content should be accessible via non-secure means.

Which I don't think is the case at present.

I have never managed to get
http://www.ietf.org/mailman/listinfo/ietf
to resolve to anything other than a blank screen.
https://www.ietf.org/mailman/listinfo/ietf
works as I would expect it to.

Information on other mailing lists and their archives that I look at I
can access with http: (even if the IETF website first offers me https:).

Tom Petch

---

From: t.p. <[email-masked]>
Date: Wed, 3 Jun 2015 11:47:20 +0100

----- Original Message -----
From: "Jari Arkko" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: "Richard Barnes" <[email-masked]>; <[email-masked]>
Sent: Wednesday, June 03, 2015 4:55 AM

I am not sure the discussion about blocking is relevant. We will change
defaults, but cleartext is still available.

<tp>

I note that the statement makes TLS 1.2 a MUST and earlier versions of
TLS a SHOULD NOT.

In practical terms, what levels of browser will we be required to have
in order to be able to use TLS 1.2?

Tom Petch

Jari

---

From: Tim Bray <[email-masked]>
Date: Wed, 3 Jun 2015 08:03:49 -0700

I travel  heavily and visit many different kinds of public & private
institutions; and it has been many years since I’ve observed HTTPS
blockage. Even in China, it seems the blockage is more domain-based than
protocol-based.

So yes, I’d like to hear evidence for the claim of protocol blockage.

-- 
- Tim Bray (If you’d like to send me a private message, see
https://keybase.io/timbray)

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 03 Jun 2015 16:40:07 +0100

Hiya,

> I note that the statement makes TLS 1.2 a MUST and earlier versions of

The statement refers to BCP195, which is our very recent IETF
consensus document on generic use of TLS and which says the
above and a bit more about versions. [1] I can't see we would
want to ignore that output from the UTA working group here - if
that BCP really doesn't work for IETF content, then we would
presumably need get the WG to fix the BCP and not the statement;-)

> in order to be able to use TLS 1.2?

I'm not sure to be honest, but for me, up-to-date ff and chromium
(on Linux) are both fine, e.g. when accessing [1] I end up with
TLS1.2 with both of those.

Cheers,
S.

[1] https://tools.ietf.org/html/bcp195#section-3.1.1

---

From: Joe Touch <[email-masked]>
Date: Wed, 03 Jun 2015 10:15:12 -0700

On 6/3/2015 1:51 AM, Xiaoyin Liu wrote:
...
> Actually the Wikimedia Foundation is considering forcing
> HTTPS for every Wikipedia visitors, even if the censorship of Wikipedia
> exists.[2]
...
> [2] https://phabricator.wikimedia.org/T49832#1240760

You're pointing to a discussion that hasn't reached resolution, not an
announced policy change.

There could be good reasons for users to want to use private access (to
hide what they're looking for or the response). But we shouldn't be
forcing that decision on users unless WE care about privacy from the
IETF-server side of things.

I haven't seen anyone make that case yet, and I would argue it's counter
to the notion of our NOTE WELL statement anyway.

Joe

---

From: Warren Kumari <[email-masked]>
Date: Wed, 03 Jun 2015 18:15:15 +0000

In 2011 there was the DNS-EASY ( Workshop on DNS health and security ) held
at in Rome (http://www.gcsec.org/event/dns-easy-2011-workshop )
It was organized by the "Global Cyber Security Center" and held in some
building that was somehow affiliated with the postal service / postel.it.

This location blocked all port 443 (and 22, and.. and.. and...). This made
people sad, and so I ended up spinning up a VPN server on port 80 for most
of the attendees...

Sure, anecdotal info, but....

W

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 3 Jun 2015 18:31:13 +0000

This is too little too late. 

This wishy washy "we believe in security but don't like to actually use it ourselves" is not the leadership IETF should be providing to the internet. The internet has already been harmed by too many years of security that is not turned on. 

Take a hum at next plenary and find out if people want the IETF to actually use security or not.

> On Jun 1, 2015, at 10:43 AM, The IESG <[email-masked]> wrote:
> 
> Hi All,
>

---

From: Niels Dettenbach <[email-masked]>
Date: Wed, 03 Jun 2015 21:09:38 +0200

Am Mittwoch, 3. Juni 2015, 18:31:13 schrieb Cullen Jennings:
> The internet has already been harmed by too many years of security that is
> not turned on. 
If so - why not using signatures in YOUR mails btw.?

HTTPS x509 SSL/TLS isn't simply "security on" (this is btw THE major technical 
misunderstanding/-interpretation of HTTPS out today, leading to huge new 
scurity holes and attack vectors in practice) - this may be correct for i.e. 
with telnet->ssh or partly SMTP-> SMTPs/TLS (where it is still not applicable 
and/or applicated correctly until today in most practical cases), just btw...

> Take a hum at next plenary and find out if people want the IETF to actually
...sorry, but This was NOT a question here - assume you mis- (or even not) 
readed correctly.

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 3 Jun 2015 13:00:34 -0700

While I don't object to making the IETF content available via https/tls, this proposed statement reads as political knee-jerk BS that is both unnecessary and uncalled for. What the statement MUST focus on is 'data integrity', and SHOULD NOT stoop to fear mongering over 'privacy'. "It is public data ..." For the very small subset that is truly restricted access, it is fine to acknowledge 'privacy' as a concern, but for the vast majority of the content in question, 'data integrity' is the only real concern. 

As such, I oppose the statement as written. Fix the tone and I will be a strong supporter.

Tony

> -----Original Message-----
> From: IETF-Announce [mailto:[email-masked]] On Behalf
> Of The IESG
> Sent: Monday, June 01, 2015 9:44 AM
> To: IETF Announcement List
> Subject: Proposed Statement on "HTTPS everywhere for the IETF"
> 
> 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.
> 
> * Comments about specific issues arising can be sent to [email-masked] or
> [email-masked] as appropriate (use [email-masked] if not sure)
> 
> Regards,

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 03 Jun 2015 21:16:03 +0100

Hi,

On 03/06/15 21:00, Tony Hain wrote:
> While I don't object to making the IETF content available via
> https/tls, 

That's been done for ages. This just makes it the default. Which
does require some minor changes.

> this proposed statement reads as political knee-jerk BS
> that is both unnecessary and uncalled for. What the statement MUST
> focus on is 'data integrity', and SHOULD NOT stoop to fear mongering
> over 'privacy'. 

I have to say the above seems somewhat overstated. (Where my use of
"somewhat" is understatement:-)

> "It is public data ..." For the very small subset
> that is truly restricted access, it is fine to acknowledge 'privacy'
> as a concern, but for the vast majority of the content in question,
> 'data integrity' is the only real concern.

I would assert that the existence of the dprive WG is good evidence
that the IETF does not consider data-integrity as the only real
concern for public data.

I'd also note that there is no TLS ciphersuite that satisfies BCP195
and that only provides data integrity. That very recent IETF consensus
document says one MUST NOT negotiate any of the ciphersuites with
NULL encryption (essentially outside of testing/debug). So what you
appear to want this statement to say would seem to be inconsistent
with IETF consensus.

Cheers,
S.

>> -----Original Message----- From: IETF-Announce
>> [mailto:[email-masked]] On Behalf Of The IESG Sent:
>> Monday, June 01, 2015 9:44 AM To: IETF Announcement List Subject:
>> Proposed Statement on "HTTPS everywhere for the IETF"
>> 
>> Hi All,
>> 
>> The IESG are planning to agree an IESG statement on "HTTPS
>> Everywhere for the IETF," please see [1] for the current text.
>> 
>> * Comments about specific issues arising can be sent to
>> [email-masked] or [email-masked] as appropriate (use
>> [email-masked] if not sure)
>> 
>> Regards, Terry & Stephen (for the IESG)
>> 
>> [1]
>> https://trac.tools.ietf.org/group/iesg/trac/wiki/HttpsEverywhere
> 
> 
>

---

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

Hiya,

On 03/06/15 19:31, Cullen Jennings (fluffy) wrote:
> This wishy washy "we believe in security but don't like to actually
> use it ourselves" is not the leadership IETF should be providing to
> the internet. The internet has already been harmed by too many years
> of security that is not turned on.
> 

Or we can put this in place and then measure who continues to access
in clear and see what that tells us.

Maybe a hum at a plenary is a bit too large a hammer to bring out for
this fairly modest nail.

S.

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Wed, 3 Jun 2015 20:32:34 +0000

> On Jun 3, 2015, at 2:18 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 

I suspect it will largely be in the clear. But I see the leaders encrypting, I wish we were leading. 

> Maybe a hum at a plenary is a bit too large a hammer to bring out for

Fair enough. I'll leave the bike shed alone :-)

---

From: John C Klensin <[email-masked]>
Date: Wed, 03 Jun 2015 16:42:00 -0400

--On Wednesday, June 03, 2015 21:18 +0100 Stephen Farrell
<[email-masked]> wrote:

> Maybe a hum at a plenary is a bit too large a hammer to bring
> out for this fairly modest nail.

Stephen,

Independent of the substance of the statement itself -- for the
reasons Tony Hain and others have given and because, as you
point out, things have been available over HTTPS for years and
this is just a change in defaults, this still feels to me more
like theater than like something substantive.  Maybe that is ok
-- theater is sometimes useful.

However, if, in your view and that of the IESG this is a "fairly
modest nail", then I have to question whether the IESG might
have better ways to allocate and prioritize its time and that of
the community.  Put differently, this is either significant
enough (substantively or as theater) to justify whatever time
the IESG has spent on it and will spend in the future, plus the
time the community is spending reading, commenting, and reacting
to comments, or it is not.   If it is not, then the IESG has
made a bad decision about the use of its time and the time of
the community regardless of whether, in a perfect world, HTTPS
would be the default.

So how modest and minor do you really think it is?
  
   best,
    john

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 3 Jun 2015 14:03:59 -0700

Stephen Farrell wrote:
> That's been done for ages. This just makes it the default. Which does
> require some minor changes.
> 
> > this proposed statement reads as political knee-jerk BS that is both
> > unnecessary and uncalled for. What the statement MUST focus on is
> > 'data integrity', and SHOULD NOT stoop to fear mongering over
> > 'privacy'.
> 

How is taking a position that technical accuracy of the IETF content is critical an overstatement? 

> 
> > "It is public data ..." For the very small subset that is truly
> > restricted access, it is fine to acknowledge 'privacy'
> I would assert that the existence of the dprive WG is good evidence that the
> IETF does not consider data-integrity as the only real concern for public
> data.

And I would assert that it shows a group-think knee-jerk overreaction to threats that hypothetically could be applied in broader contexts than history documents. We are both free to express our own assertions.

> 
> I'd also note that there is no TLS ciphersuite that satisfies BCP195 and that
> only provides data integrity. That very recent IETF consensus document says
> one MUST NOT negotiate any of the ciphersuites with NULL encryption
> (essentially outside of testing/debug). So what you appear to want this
> statement to say would seem to be inconsistent with IETF consensus.

I never argued FOR null encryption. My point was that 'privacy' is not a technical need in this case. It may come about as a side effect, but the proposed statement as written is not focused on the technical requirement of the IETF. It is instead a political statement that has no technical justification based on the needs of the community. To be clear, the technical need is data integrity. The implementation MAY provide privacy, and given current technologies likely will. 

Tony

> from

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 03 Jun 2015 22:08:41 +0100

> So how modest and minor do you really think it is?

It's minor in terms of impact on users and current web content.
But less so perhaps as setting the default we want to use for
other cases in future as those arise. And it impacts on tooling
as well (e.g. the URLs in the boilerplate produced by xml2rfc,
and in the tracker) and it impacts on the secretariat in minor
ways (URLs embedded in mails they send out).

The above and the fact that we do have a set of IETF folks
who seemingly don't like any of this are I think reason enough
for the iesg to solicit comment before just adopting something
like this, or just putting it in place without that.

Personally, I do wish we didn't have to have essentially
the same points discussed over and over, but it seems we
do.

Cheers,
S.

---

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

On 03/06/15 22:03, Tony Hain wrote:
> And I would assert that it shows a group-think knee-jerk overreaction
> to threats that hypothetically could be applied in broader contexts
> than history documents. We are both free to express our own
> assertions.
> 

Disagreeing is of course fine but does not require that those
with whom one disagrees are stuck in a group-think knee-jerk
mixed metaphor;-)

Looking at the actual text of the statement though [1] I could
agree that the 3rd paragraph is maybe more justified on security
grounds, so maybe s/privacy/security&privacy/ would be better there.

That said, there is a real threat to privacy (cf. tempora) when it
is credible to assume that any of our traffic that transits undersea
cables is recorded, and traffic to the IETF is a part of that even
if it's quite unlikely, by itself, to be privacy sensitive.

(Someone else already pointed out that it'd be worth noting that
HTTPS isn't perfect in the face of traffic analysis, so adding
text on that would also make sense just so's we're clear that
we're not claiming that there's a panacea hereabouts, and is
worth a mention here too.)

S.

---

From: John C Klensin <[email-masked]>
Date: Wed, 03 Jun 2015 18:49:31 -0400

Hmm.  Let me try to make my main point in another way, and then
I'll follow my own advice and drop back out of this
conversation...

> the same points discussed over and over, but it seems we

Let me suggest a bit of cost-analysis arithmetic.  IESG and
other community members regularly complain that there are too
few thoughtful and competent reviews of standards track specs on
Last Call.   This topic has generated a lot of messages, plus
even more messages associated with the (probably inevitable)
spinoffs and side-threads.  It is possible that many of the
people commenting just like process arguments and wouldn't be
doing useful work anyway but, from looking at the names, I don't
think that is generally true.  To pick a completely arbitrary
number, assume that, had this thread not started, 10% of the
comments (or even 10% of the respondent count) might instead
have gone into reviews of standards-track technical specs.
Would you think the discussion worth it?  Would your answer
change is the question hypothesized 20%?  5%?

The question is rhetorical, but the issue of allocation of
resources is not.   Unlike the references to existing materials
that have been the focus of most of the comments, some of the
examples you give really could have consequences for
accessibility of materials in the future.  The point is that
change --both discussing the changes and making them-- has
costs.  Even if I saw much more positive value in this proposed
action than I happen to do (I do see some, and am not opposed,
but...), I don't think you have made a persuasive case that the
costs of discussing and making the change are worth it in terms
of opportunity costs within the community and its workload.

I sometimes wish the community were willing to give the IESG a
lot more flexibility to just make decisions, that the IESG were
willing to take the responsibility that goes with that rather
than feeling a need to ask questions (but know that they would
be held accountable for getting things wrong), and that there
were convenient and efficient ways for the community to express
the equivalent of a "no confidence" vote in the IESG (not
individuals) if things got sufficiently out of synch.

  best,
    john

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 3 Jun 2015 20:06:45 -0700

Stephen Farrell wrote:
> Disagreeing is of course fine but does not require that those with whom one
> disagrees are stuck in a group-think knee-jerk mixed metaphor;-)
> 
> Looking at the actual text of the statement though [1] I could agree that the
> 3rd paragraph is maybe more justified on security grounds, so maybe
> s/privacy/security&privacy/ would be better there.

No, more below.

> 
> That said, there is a real threat to privacy (cf. tempora) when it is credible to
> assume that any of our traffic that transits undersea cables is recorded, and
> traffic to the IETF is a part of that even if it's quite unlikely, by itself, to be
> privacy sensitive.

I never argued that there is not a general threat to privacy due to recording, just that it does not apply here. My point was that the IETF does not have a general technical REQUIREMENT for privacy. There are many that WANT privacy in everything they do, but that does not equate to a real requirement for the public content of an open organization. Substituting security&pirvacy only makes a bad choice of words worse. The IETF has no business case for either, and if there was a case something would have been done about it long before now. 

It is clear that a solution has been chosen and language is being collected to justify that solution. Again, I am not opposed to the solution, just the unnecessary method being used to justify it. All you need to do is state the clearly justifiable requirement for data integrity. The fact that the chosen implementation goes beyond the requirement is a bonus for those who want the privacy. 

Put another way; if the IESG believes it has the excess time to make clearly political statements (rather than focus on the justifiable technical requirement), maybe we need to revisit the workload on the NomCom and reduce the number of ADs...

Tony

> 
> (Someone else already pointed out that it'd be worth noting that HTTPS isn't
> perfect in the face of traffic analysis, so adding text on that would also make
> sense just so's we're clear that we're not claiming that there's a panacea
> hereabouts, and is worth a mention here too.)
> 
> S.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 04 Jun 2015 15:27:16 +1200

Hi Tony,
> I never argued that there is not a general threat to privacy due to recording, just that it does not apply here. My point was that the IETF does not have a general technical REQUIREMENT for privacy…

It isn't the content that is private, of course. However, if there are IETF
participants who require a degree of privacy about their use of IETF public
information, it is entirely reasonable for the IETF to support that with a
straightforward measure like HTTPS. As has been pointed out already, that
is insufficient to provide a high degree of privacy.

Try "...the act of accessing public information required for routine tasks
can be privacy sensitive *on the user's side*..."

I don't see anything political about that. It's factual.

    Brian

---

From: Yoav Nir <[email-masked]>
Date: Thu, 4 Jun 2015 10:06:23 +0300

> On Jun 4, 2015, at 6:27 AM, Brian E Carpenter <[email-masked]> wrote:
> 

That’s a big “if”. I don’t believe there are IETF participants who require privacy about accessing IETF information. 

> can be privacy sensitive *on the user's side*…"

This is very true for Wikipedia, very true about news sites and many other sites. Not the IETF.

> I don't see anything political about that. It's factual.

The statement (made by Richard Barnes, not by the IESG) that the IETF should lead by example and move to all HTTPS is very political. The proposal prioritizes the concerns of some group (small or large) and levies a burden on the entire community (TLS is not free; finding www.cleartext.ietf.org takes effort). That is a political decision. It’s a small one. I agree with John Klensin that this is something the IESG could (and should) have done on its own without starting a discussion on a proposed statement. 

Yoav

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 4 Jun 2015 08:37:39 -0700

Brian E Carpenter wrote:
> >>> And I would assert that it shows a group-think knee-jerk
> >>> overreaction to threats that hypothetically could be applied in
> >>> broader contexts than history documents. We are both free to express
> >>> our own assertions.
> >>>
> >>
> >> Disagreeing is of course fine but does not require that those with
> >> whom one disagrees are stuck in a group-think knee-jerk mixed
> >> metaphor;-)
> >>
> >> Looking at the actual text of the statement though [1] I could agree
> >> that the 3rd paragraph is maybe more justified on security grounds,
> >> so maybe s/privacy/security&privacy/ would be better there.
> >
> > No, more below.
> >
> >>
> >> That said, there is a real threat to privacy (cf. tempora) when it is
> >> credible to assume that any of our traffic that transits undersea
> >> cables is recorded, and traffic to the IETF is a part of that even if
> >> it's quite unlikely, by itself, to be privacy sensitive.
> >
> > I never argued that there is not a general threat to privacy due to
> recording, just that it does not apply here. My point was that the IETF does
> not have a general technical REQUIREMENT for privacy. There are many that
> WANT privacy in everything they do, but that does not equate to a real
> requirement for the public content of an open organization. Substituting
> security&pirvacy only makes a bad choice of words worse. The IETF has no
> business case for either, and if there was a case something would have
> been done about it long before now.
> 
> Try "...the act of accessing public information required for routine tasks can
> be privacy sensitive *on the user's side*..."

So that text exposes the silliness of this effort. IF there are people that really need privacy of their access of IETF content, they had better be using more than HTTPS. If they are not using something like TOR they are toast, because it doesn't take much traffic analysis to figure out which documents are being read. Anyone can create a mirror, and with that data they will know which documents and requests create which byte stream lengths. 

> I don't see anything political about that. It's factual.

It is dangerous to imply that simple https provides any privacy when the original content is public information. If true privacy is the requirement then the IETF needs to be serious about expanding TOR. This proposed text is unnecessary theater to make a political statement. If the I* wants to make a political statement, the ISOC or maybe IAB should make it. The IESG has no business making anything more than a technical statement, and the only thing they need to say is that data-integrity is important so we are making https the default. The clear refusal to drop the word privacy from the statement just underscores how much this is politically driven rather than a serious effort to ensure that the IETF content is delivered intact. 

My overall concern here is that statements like this undermine the integrity of the organization. I understand people wanting to improve overall privacy, but this step does not do that in any meaningful way. 

Tony

---

From: Nico Williams <[email-masked]>
Date: Thu, 4 Jun 2015 11:31:35 -0500

On Thu, Jun 04, 2015 at 10:06:23AM +0300, Yoav Nir wrote:
> > Try "...the act of accessing public information required for routine
> > tasks can be privacy sensitive *on the user's side*…"
> 

Internet RFCs tell the user much of what they need to implement
technology that might be deemed subversive or otherwise prohibited where
the user resides.

Also, the more useful "harmless" sites require HTTPS, the harder it is
for great firewalls to block it indiscriminately.  That might be a
politically-desirable effect to the IETF.

---

From: "Joe Hildebrand" <[email-masked]>
Date: Thu, 04 Jun 2015 10:53:56 -0600

On 4 Jun 2015, at 9:37, Tony Hain wrote:

> My overall concern here is that statements like this undermine the 
> integrity of the organization. I understand people wanting to improve 
> overall privacy, but this step does not do that in any meaningful way.

Encrypting the channel does provide some small amount of privacy for the 
*request*, which is not public information.  Browser capabilities, 
cookies, etc. benefit from not being easily-correlated with other 
information.

It would be interesting to define an HTTP header of "Padding" into which 
the client would put some random noise to pad the request to a 
well-known size, in order to make traffic analysis of the request 
slightly more difficult.  This is the sort of thing that comes up when 
we talk about doing more encryption for the IETF's data, which shows the 
IESG's suggested approach to be completely rational.

-- 
Joe Hildebrand

---

From: Christian Huitema <[email-masked]>
Date: Thu, 4 Jun 2015 17:17:57 +0000

On Thursday, June 4, 2015 9:54 AM, Joe Hildebrand wrote:
> *request*, which is not public information.  Browser capabilities, cookies, etc.
> benefit from not being easily-correlated with other information.

What Joe says. Encrypting data is just one component of providing privacy, but it is a very useful component. Clear text headers leak various kinds of "meta-data," which facilitate correlation and traffic analysis. For example, if people access the IETF from a public Wi-Fi and manages to leak meta-data on that hot spot, their traffic will be very hard to analyze and correlate with their identity. Of course, that takes more than just encrypting the end-to-end application traffic, but encryption is definitely a key component of the solution.

> It would be interesting to define an HTTP header of "Padding" into which the
> client would put some random noise to pad the request to a well-known size, in
> order to make traffic analysis of the request slightly more difficult.  This is the
> sort of thing that comes up when we talk about doing more encryption for the
> IETF's data, which shows the IESG's suggested approach to be completely
> rational.

Yes.

-- Christian Huitema

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 4 Jun 2015 10:20:40 -0700

> *request*, which is not public information.  Browser capabilities,
cookies, etc.
> benefit from not being easily-correlated with other information.

The set of possible requests is inherently public information. Pairing a
request length with the possible set of return lengths seriously reduces the
set, and that is before you factor in who is being watched and what they
might be looking for.

> It would be interesting to define an HTTP header of "Padding" into which
the
> IETF's data, which shows the IESG's suggested approach to be completely

On  the contrary, it only further exposes how much of an irrational
knee-jerk this effort is. If you have to define something new, then get it
deployed, it is not ready for prime-time and therefore this effort is
premature at best. A more rational thing that could be part of the tooling
effort without much delay would be to define a random COMMENT padding which
would vary the length of the returned stream. 

Again, I am not objecting to encrypting the content. I am concerned that the
IESG is "out of scope" by making a political statement, particularly when it
is not necessary. It is completely rational and within scope for the IESG to
be concerned about data-integrity, and stating they are turning on https by
default to accomplish that. There is no need for the word 'privacy' to occur
within the statement, and is blatantly misleading without taking more steps
than are being outlined here.

Tony

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Jun 2015 13:34:31 -0400

> The statement (made by Richard Barnes, not by the IESG) that the IETF should lead by example and move to all HTTPS is very political. The proposal prioritizes the concerns of some group (small or l…

I don't disagree that TLS is not free.   However, a useful measure of the importance of your statement here would be to ask you whether in fact https-by-default would actually be expensive enough to motivate you to change your behavior?   I suspect the answer is no.   Virtually all data that goes over the Internet is encrypted.   Of course most of that is video streams, but think about how much data that is.

Compared to the puny amount of data that you can get by downloading content from the IETF, it's hard to imagine anyone using cleartext.ietf.org for any reason other than that they happen to live in a repressive society, in which case the need to use this feature will be a fairly minor inconvenience compared to the rest of the hassle that they are no doubt dealing with on a daily basis.

So why are we still arguing about this?

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Jun 2015 13:39:22 -0400

> set, and that is before you factor in who is being watched and what they

No.   RFC numbers are all the same length, except for the very early ones.   Plus, the headers in a request vary enough that it's unlikely that this attack would be as easy as you say; furthermore, https used for privacy is most effective at preventing passive attacks, and in this case the expense of doing the sort of analysis you are describing would be significant.

---

From: Joe Touch <[email-masked]>
Date: Thu, 04 Jun 2015 11:53:16 -0700

On 6/3/2015 8:06 PM, Tony Hain wrote:
> Put another way; if the IESG believes it has the excess time to make
> clearly political statements (rather than focus on the justifiable
> technical requirement), maybe we need to revisit the workload on the
> NomCom and reduce the number of ADs...

+1

---

From: Benson Schliesser <[email-masked]>
Date: Thu, 04 Jun 2015 12:07:17 -0700

> So why are we still arguing about this?

For whatever it's worth, my personal view is that the proposed statement
is useful in an administrative context, in determining how we should
construct IETF services / tools. Whether it is also part of a broader
political statement is not particularly relevant.

It makes sense to me that we should employ the technology that we
produce, as we recommend it to be employed by the larger Internet
community, regardless of the specific privacy needs of the IETF. So, I
don't think there is anything to argue about here. Unless somebody knows
of material issues in the technology, such as ways that the
recommendation will break things, it seems safe for the IESG to rely on
prior consensus (i.e. about privacy etc) to make this statement.

Cheers,
-Benson

---

From: Nico Williams <[email-masked]>
Date: Thu, 4 Jun 2015 14:15:09 -0500

> NomCom and reduce the number of ADs...

You do realize that the IETF *is* a political body...  It being an
organization with more than one participant and all.

The process for publishing RFCs is... political.  The process for
changing the process (but I repeat myself) is political.

How can the IETF be utterly non-political?

I would agree that the IETF should stay away from certain kinds of
political statements, but this isn't it, not least because I can't see
what is controversial or politically objectionable about this statement
in the wider world outside just the IETF.  Will the public in the U.S.
object?  Doubtful.  How about the public in the UK?  Also doubtful.  And
so on and on.  Did the public complain about all the https-only sites
out there?  No, the public did not.

Can we stop it with this thread?  What a waste of time!  For goodness'
sakes, go ahead and make all IETF services TLS-capable, and then someday
let's throw the switch see what happens when we redirect http resources
to https for one day -- if nothing breaks badly that we don't mind
breaking, then let's make that permanent.  How can that possibly be so
damned controversial?  github, for example, did it, and so did many
others -- sites with paying customers.

Nico
--

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 4 Jun 2015 13:57:24 -0700

> On Jun 4, 2015, at 9:53 AM, Joe Hildebrand <[email-masked]> wrote:
> 
> Encrypting the channel does provide some small amount of privacy for the *request*, which is not public information.  Browser capabilities, cookies, etc. benefit from not being easily-correlated with other information.

That is message confidentiality, not privacy.  Almost all of the privacy bits (as in, which
person is doing what and where) are revealed outside of the message.

> It would be interesting to define an HTTP header of "Padding" into which the client would put some random noise to pad the request to a well-known size, in order to make traffic analysis of the request slightly more difficult.  This is the sort of thing that comes up when we talk about doing more encryption for the IETF's data, which shows the IESG's suggested approach to be completely rational.

Browsers don't send singular messages containing anonymous information.  They send a complex
sequence of messages to multiple parties with an interaction pattern and communication state.
The more complex and encrypted the communication, the more uncommon state and direct
communication is required, which makes it easier to track a person across multiple requests
until the user's identity is revealed.  Furthermore, with TLS in place, it becomes easy and
commonplace to send stored authentication credentials in those requests, without visibility,
and without the ability to easily reset those credentials (unlike in-the-clear cookies).

Padding has very little effect.  It isn't just the message sizes that change -- it is all
of the behavior that changes, and all of the references to that behavior in subsequent
requests, and the effects of those changes on both the server and the client.

TLS does not provide privacy.  What it does is disable anonymous access to ensure authority.
It changes access patterns away from decentralized caching to more centralized authority control.
That is the opposite of privacy.  TLS is desirable for access to account-based services wherein
anonymity is not a concern (and usually not even allowed).  TLS is NOT desirable for access to
public information, except in that it provides an ephemeral form of message integrity that is
a weak replacement for content integrity.

If the IETF wants to improve privacy, it should work on protocols that provide anonymous
access to signed artifacts (authentication of the content, not the connection) that is
independent of the user's access mechanism.

I have no objection to the IESG proposal to provide information *also* via https.  It would
be better to provide content signatures and encourage mirroring, just to be a good example,
but I don't expect eggs to show up before chickens.  However, I agree with Tony's assessment:
most of the text is nothing more than a pompous political statement, much like the sham of
"consensus" that was contrived at the Vancouver IETF.

TLS everywhere is great for large companies with a financial stake in Internet centralization.
It is even better for those providing identity services and TLS-outsourcing via CDNs.
It's a shame that the IETF has been abused in this way to promote a campaign that will
effectively end anonymous access, under the guise of promoting privacy.

....Roy

---

From: Niels Dettenbach <[email-masked]>
Date: Fri, 05 Jun 2015 10:54:11 +0200

Am Donnerstag, 4. Juni 2015, 13:57:24 schrieb Roy T. Fielding:
> TLS does not provide privacy.  What it does is disable anonymous access to
> ensure authority. It changes access patterns away from decentralized
> caching to more centralized authority control. That is the opposite of
> privacy.  TLS is desirable for access to account-based services wherein
> anonymity is not a concern (and usually not even allowed).  TLS is NOT
> desirable for access to public information, except in that it provides an
> ephemeral form of message integrity that is a weak replacement for content
> integrity.
Yes,
i remember and know several scenarios where providers (mainly in the middle 
east and africa, where bandwidth is still "expensive") still are using large 
scale HTTP caching (wie build a few of it in the past) - to "save bandwidth" 
(costs) and/or improve "surf performance" from their view. 

HTTPS stuff isn't "usually" cached (except they try to break it by faking all 
SSL by their own (MitM) "working" certificate, which is afaik less the case in 
provider networks). 

This means users have to use the outer side networks to get static HTTP docs 
in any case / for "each request" - these networks are still often not secured 
physically or logically (i.e. unencrypted satellite or microwave trunks or 
fiber over neighbour country territory - encryption still costs 
ressources/money here...) and so (at least) very easy to sniff by anyone with 
very small equipment - i.e. jouranlists, hobbyists and - of course - any kind 
of other guys within i.e. the same satellite footprint.

HTTPS brings centralization which leads to the opposite of "privacy" in such 
cases, but even if smaller networks are running caches this could make user 
tracking by third parties much more difficult.

To provide data integrity (by the entity [like the IETF] BYSELF and not any 
third party the user has to trust additionally and to read/check by hand each 
time using a browser session!) content signing would be much more helpful 
while it allows further access over HTTP caches or even mirrors. 

And not at least: caching and mirroring could hardly rise data availability - 
by redundancy and it is more difficult to block access to. See i.e. the former 
wikileaks mirror network working this way (and i remember how my collegue was 
tried pressed by german services / police to hand out access to the german 
wikileaks web domain some years ago...).

> If the IETF wants to improve privacy, it should work on protocols that
> provide anonymous access to signed artifacts (authentication of the
> content, not the connection) that is independent of the user's access
> mechanism.
+1

I'm not a crypto geek, but for me something what allows i.e. using my own pgp 
public key to sign (HTTP) documents on request - integrated in browsers / web 
security standards or similiar, would be a helpful solution. 

F.i., PGP still needs improvements in the possibilities of (decentralized) 
trust handling and transparent, dynamic "security levels" (a user has to 
"decide" which entities he trust in which way on a still more transparent and 
easier to "manage" level) - but i think that a person or entity should be able 
to manage trust from his own view onto it - and not mainly/only single others 
(or a complete branche of as in HTTPS/x509 the case in practice). The PGP 
principle is the nearest to that att.

many thanks,

Niels.

---

From: <[email-masked]>
Date: Fri, 5 Jun 2015 11:03:35 +0000

> However, I agree with Tony's assessment:
> most of the text is nothing more than a
> pompous political statement, much like the sham of

+1

L.
________________________________________
From: ietf <[email-masked]> on behalf of Roy T. Fielding <[email-masked]>
Sent: Friday, 5 June 2015 6:57:24 AM
To: Joe Hildebrand
Cc: [email-masked]
Subject: Re: Proposed Statement on "HTTPS everywhere for the IETF"

....Roy

---

From: Hector Santos <[email-masked]>
Date: Sat, 06 Jun 2015 11:25:26 -0400

>> get to continuing that work!

+1.

Design note to HTTPS implementations:

Figure out how to update an HTTPS client under a forced (redirected) 
HTTPS condition/environment where the client is failing because of 
deprecated, obsolete and now even removed SSL/TLS support options.  In 
other words, it can't update itself because of the new HTTPS forced 
conditions.  Example, Google Chrome.  It could not update because the 
HTTPS URL was failing due the browser seeing an erroneous "Invalid 
Certificate" display with no option to accept, temporary or otherwise. 
  You have to download via another browser that isn't so strict, yet.

I guess that would go under a "chicken and egg" problem.

--
HLS

---

From: Xiaoyin Liu <[email-masked]>
Date: Sat, 6 Jun 2015 23:08:39 -0400

> Date: Sat, 6 Jun 2015 11:25:26 -0400
> From: [email-masked]
> To: [email-masked]; [email-masked]; [email-masked]
> It could not update because the 
 
Why does the IETF use invalid certificates in the first place? If this is due to a wrong system clock, then the user probably cannot visit Google, Facebook, GitHub, etc. as well, and at least Firefox and Chrome advise users to fix the clock in such situation.

Xiaoyin

---

From: Hector Santos <[email-masked]>
Date: Sun, 07 Jun 2015 01:57:02 -0400

On 6/6/2015 11:08 PM, Xiaoyin Liu wrote:
> Why does the IETF use invalid certificates in the first place? If this
> is due to a wrong system clock, then the user probably cannot visit
> Google, Facebook, GitHub, etc. as well, and at least Firefox and
> Chrome advise users to fix the clock in such situation.
>
> Xiaoyin

Most likely because the HTTPS server is now fully PCI/DSS v3.1 
compliant which only supports TLS v1.1 or TLS v1.2.  I believe PCI/DSS 
v3.1 takes effects July 2015 so you are going to see a lot of this.

     PCI/DSS (Payment Card Industry/Data Security Standard) v3.0 to 
v3.1 changes
 
https://www.pcisecuritystandards.org/documents/PCI_DSS_v3-1_Summary_of_Changes.pdf 

If the HTTPS server only enables TLS v1.1/v1.2 as required by PCI/DSS 
v3.1, this can fail older/current HTTPS clients which does not not 
support TLS v1.1/v1.2. It could/may display an erroneous "invalid 
certificate" display or even show an unknown site page because the 
non-compliant HTTPS socket request was broken.

For product update scenarios, if the site forces HTTPS transactions 
only, then its not possible for it to update itself via HTTPS.

This is more about implementations and how they need to learn how up 
"update" users using any current secured frontend. For PCI/DSS, I 
predict we will see many of these issues that in short will force 
users to update their client software on their machines, whether they 
like it or not.

-- 
HLS

---

From: Hector Santos <[email-masked]>
Date: Sun, 07 Jun 2015 02:11:41 -0400

Small correction, July 2016, not July 2015, is the new TLS v1.1/1.2 
compliant deadline for PCI v3.1.  From the PCI/DSS reference below:

Removed SSL as an example of a secure
technology. Added note that SSL and early
TLS are no longer considered to be strong
cryptography and cannot be used as a security
control after June 30, 2016. Additional
guidance provided in Guidance column. Also
impacts Requirements 2.3 and 4.1.

-- 
HLS