Re: Security for various IETF services

[Brian Trammell <[e-mail]>]

On 07 Apr 2014, at 11:40, Stewart Bryant <[e-mail]> wrote:

> On 05/04/2014 18:29, Tim Bray wrote:
>> On Sat, Apr 5, 2014 at 1:50 AM, Stewart Bryant (stbryant) <[e-mail]> wrote:
>> 
>> > Please confirm that "friendly" implies that the user gets to
>> > choose the degree of security privacy that they consider
>> > appropriate, and that their applications and devices are not
>> > encumbered  with the overheads unless they choose to invoke
>> > the privacy and security mechanisms.
>> 
>> Here, I think, is a key issue.  I disagree with Stewart.  WHAT?!  How can I possibly disagree with  ​user choice?  Because, a huge majority of people
>> 
>> (a) aren’t aware that there is a choice to be made, and shouldn’t need to be
>> (b) do not understand the technical issues surrounding the choice, and shouldn’t have to
>> (c) do not understand the legal/policy issues surrounding the choice, and shouldn’t have to
>> 
>> This includes both the people who use online services and the people who offer them.  Thus, the only sane ethical position is to operate in a mode that is private by default, because the consequences of a negative failure (the user really didn’t need privacy but got it anyhow) are immensely less damaging than the consequences of a positive failure (the user really needed privacy but didn’t get it).
> I could be persuaded towards "crypto by default", but I hear in these discussions "crypto as an exclusive mode", and I do not think that is an acceptable constraint on implementations.

Then let's talk about crypto by default, which I think is a useful position in the case of IETF services, which is of course the subject of the thread. Here the specific threats posed by an adversary are:

(1) Leakage of browsing history. It may be tempting to presume that there is no value to the information that person X was interested in IETF documents w, y, and z, at time t, but that is indeed a presumption. We don't know X, and we can't presume to know why X might think their interest in the work of the IETF (or their presence at a particular point in time when they were accessing our services) is private, so we should make it as easy as possible to use TLS to at least limit the passively-observable information to that about the flow. And it doesn't get any easier than on-by-default. :)

(One could say that post-Snowden there is no reasonable practical presumption of privacy over HTTP, and that people using HTTP are knowingly serving up their browsing history to all observers. I have to agree with Tim on this point, though. As far as I am concerned this threat is justification enough to provide TLS by default for IETF web services. The details of how to do this to best "upgrade" initial landings without breaking access for deep-links and/or automated processes are just that, details of implementation.)

(2) Credential theft and subsequent impersonation: unencrypted access to the datatracker could allow eavesdroppers to impersonate anyone who logs in over HTTP. Yes, there are non-TLS ways to deal with this, though I'm not sure how universally reliable they are. (We also send mailing list credentials in plaintext at incredibly predictable times, so it would be relatively easy for someone to bulk-unsubscribe most of the IETF from most of our mailing lists, but that's unrelated to web services.)

I think the practical risk here is only of vandalism, creating a mess in the datatracker that it would take a fair amount of work to clean up. Any impersonation materially impacting the process would presumably (hopefully) be detected by the impersonated themselves. And the possibility of someone actually doing this certainly seems far-fetched, but so do so many of the things one reads in the press these days on this subject.

Protecting credential exchange by default via TLS for IETF web services requiring a login is a nice side-benefit to addressing (1) above, but if we think we have really good reasons for addressing (2) without addressing (1), there are ways to do so that are slightly computationally less expensive. It would take some effort to convince me that this is the correct tradeoff though.

(3) Injection/deletion/modification of RFC or draft content inline. There are already lots and lots and lots of places that mirror our documents anyway, so TLS won't help much here. The appropriate way to handle this is to sign the documents, not to provide protection on the wire. As I understand it this is an ongoing project anyway. Ignoring issues with the web PKI, TLS provides a practical bootstrap to this process by ensuring authenticity and integrity of public keys for verification retrieved from a known source.

There are probably a few others, but I think I've used all my Narten points for the week.

So there are specific reasons to do this, beyond simply increasing the cost of bulk collection by adding a few drops to the growing ocean of traffic encrypted on the wire.

> Privacy and authentication always ends up taking CPU, memory and bandwidth, which in turn costs money, silicon, power, weight and complexity. If a specific application requires privacy and or authentication, then fine, but each case needs to be examined on its own merits.

Yep. And I think in the case of the IETF services the real question comes down to "is the impact on 'restricted execution environments' worth the benefit (especially wrt threat 1) to default-on TLS for *.ietf.org?"

> Now you may say "ah but we are getting so much better at the engineering that who cares about such things", to which I would point out that such thinking stunts our ability to build things that are orders of magnitude smaller, lighter, cheaper and more power efficient than we can conceive of oday.

Agree completely.

Cheers,

Brian