Re: Security for various IETF services


On 07 Apr 2014, at 11:40, Stewart Bryant <stbryant(_at_)cisco(_dot_)com> wrote:

On 05/04/2014 18:29, Tim Bray wrote:

On Sat, Apr 5, 2014 at 1:50 AM, Stewart Bryant (stbryant) 
<stbryant(_at_)cisco(_dot_)com> 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

signature.asc
Description: Message signed with OpenPGP using GPGMail