Subject: [Uta] opportunistic keying / encryption considered of dubious value

From: Keith Moore <[email-masked]>
Date: Sat, 15 Mar 2014 14:34:54 -0400

I would like to just throw this out here to see how much consensus there 
is about this.

There might be particular applications for which it makes sense, but 
overall, I don't think opportunistic encryption [*] is worth much. To be 
more precise, I wonder whether it's worth the effort for us to specify, 
and for implementors to implement, uses of TLS that only provide 
encryption which is easily defeated by man in the middle attacks.  Yes, 
doing MITM pervasively requires a lot more resources than pervasive 
monitoring of cleartext, but I get the impression that there are several 
parties willing to make that investment - if not now, then probably 
before we get around to revising application security expectations 
again.   I think we have a window of opportunity now that we won't get 
again for another ten to twenty years, and we should take advantage of it.

Are there scenarios where we can do opportunistic encryption where we 
can't do significantly better with only a marginal amount of additional 
specification/implementation effort?  Trust on first use (TOFU), 
latching/racheting, and DANE/TLSA all seem likely to be better.   I'm 
not saying that such scenarios don't exist, but none come to mind offhand.

Keith

[*] I realize that some prefer the term "opportunistic keying", but I'm 
not sure that that term applies to situations like, for example, using 
STARTTLS when the peer offers it but being willing to fall back to 
cleartext if the peer doesn't.

---

From: Watson Ladd <[email-masked]>
Date: Sat, 15 Mar 2014 11:43:15 -0700

On Sat, Mar 15, 2014 at 11:34 AM, Keith Moore
<[email-masked]> wrote:
> I would like to just throw this out here to see how much consensus there is
> about this.
>
> more precise, I wonder whether it's worth the effort for us to specify, and
> for implementors to implement, uses of TLS that only provide encryption
> which is easily defeated by man in the middle attacks.  Yes, doing MITM
> pervasively requires a lot more resources than pervasive monitoring of
> cleartext, but I get the impression that there are several parties willing
> to make that investment - if not now, then probably before we get around to
> revising application security expectations again.   I think we have a window
> of opportunity now that we won't get again for another ten to twenty years,
> and we should take advantage of it.
>
> Are there scenarios where we can do opportunistic encryption where we can't
> do significantly better with only a marginal amount of additional
> latching/racheting, and DANE/TLSA all seem likely to be better.   I'm not
> saying that such scenarios don't exist, but none come to mind offhand.

All DANE/TOFU/latching imply a commitment by both sides to maintain
and manage identity. This cost is why we don't encrypt today.
Opportunistic encryption works even when a sysadmin is lazy.
Furthermore, with the new email headers, we can probably design
mechanisms to say "send only to nodes with verified identity. If you
run into trouble don't." vs "hide me from casual inspection" vs. "it
needs to get there".

I agree with you we should think about this harder, but the difference
between opportunistic encryption and real encryption is a PKI. We've
had many different attempts. DANE/TLSA is only the latest one. Maybe
it is possible: I understand XMPP has gotten identities for many of
the servers on the public XMPP network.

Sincerely,
Watson Ladd

>
>
> Keith
>
> [*] I realize that some prefer the term "opportunistic keying", but I'm not
> sure that that term applies to situations like, for example, using STARTTLS
> when the peer offers it but being willing to fall back to cleartext if the
> peer doesn't.
>
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Keith Moore <[email-masked]>
Date: Sat, 15 Mar 2014 14:52:43 -0400

> and manage identity. This cost is why we don't encrypt today.

I don't think so.  I think we don't encrypt today because many 
application protocols solidified in the late 1990s when there were more 
barriers to use of encryption, and there simply hasn't been sufficient 
pressure to update them and overcome the inertia of the installed base 
until (perhaps) now.

Also, I don't see how DANE implies a commitment by both sides.  And I 
don't think latching or TOFU requires (much) additional effort on the 
part of sysadmins.

> run into trouble don't." vs "hide me from casual inspection" vs. "it

I'd need to see a specific proposal, but offhand trying to embed such 
requests in email headers strikes me as poor design (i.e. layering 
violation) and also easy to defeat.

Keith

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 15 Mar 2014 12:07:09 -0700

On Mar 15, 2014, at 11:43 AM, Watson Ladd <[email-masked]> wrote:

> and manage identity.

A big +1 to Watson's simple explanation. DANE/TOFU/latching all specify that if the initiator gets a key that is wrong, they will prevent communication in order to protect the initiator. That works great until a management issue happens, at which point you have a pissed-off initiator who is likely to turn off more security than they should.

We have no measure about how attackers will become MITMs, so it is folly to say "it is happening more" or "it is becoming easier". We now have ways to measure the amount of passive attacks, and we know that those are partially thwarted if there is encryption.

--Paul Hoffman

---

From: Keith Moore <[email-masked]>
Date: Sat, 15 Mar 2014 15:45:49 -0400

On 03/15/2014 03:07 PM, Paul Hoffman wrote:
> A big +1 to Watson's simple explanation. DANE/TOFU/latching all specify that if the initiator gets a key that is wrong, they will prevent communication in order to protect the initiator.

How is that different/worse than using a CA?

>   That works great until a management issue happens, at which point you have a pissed-off initiator who is likely to turn off more security than they should.

I have heard several claims to the effect that "users will just click 
through warning messages" or "users will just turn off security if it 
doesn't work".   I'd like to push back on this a bit as I think this is 
making a lot of assumptions based mostly on experience with the web and 
web browsers, that aren't necessarily valid in other contexts.   Reading 
mail, sending mail, IM, and relaying mail, are all very different than 
the web - the first three because mail and IM clients tend to access the 
same few servers over and over, the last one because it's not 
interactive and there's lots of opportunity for retry (though effective 
reporting of errors is harder).

I think people click through for web sites partially because they get 
these popups often enough in contexts where there doesn't seem to be 
anything wrong with the server (e.g. self-signed cert) and all of these 
popups more-or-less look alike to the user - most users aren't in a 
position to analyze what the message is and decide whether it's 
reasonable.   This could be largely due to poor UI design.   If the UI 
instead said "site unreachable" in all but a few corner cases (like 
certificate expired or self-signed certificate), security would be 
tremendously improved with no changes to the actual protocols.   If the 
clients kept a bit of state from prior connections (e.g. have we 
successfully verified this key in the past?), they could do even better.

I also think that if you're running a server that uses encryption, you 
should be regularly and frequently monitoring your certs, DNS records, 
etc. for validity and correctness.   So users shouldn't be the first to 
find out when these things fail.   That doesn't solve all possible 
problems (in particular, I wonder about the potential for various 
brain-damaged kinds of DNS proxies to defeat DANE) but clearly it's 
possible to raise the bar over what now seems to be common practice in 
such a way that might actually lower an operator's user support costs.

Bottom line:  before we just dismiss new approaches out-of-hand, can we 
dig a bit deeper and actually do some analysis?   And when we find 
issues, can we see if we can address them instead of just giving up?

> We have no measure about how attackers will become MITMs, so it is folly to say "it is happening more" or "it is becoming easier".
It's also folly to pretend that such threats doesn't exist.   We know of 
multiple documented cases of MITM attacks, we're just not sure how 
pervasive they are or will be in the future.

> We now have ways to measure the amount of passive attacks, and we know that those are partially thwarted if there is encryption.

Yes we do.  But note that even if users sometimes "click through" when 
key validation fails with interactive apps, you do no worse than 
opportunistic encryption for the other cases.

Keith

---

From: Michael Richardson <[email-masked]>
Date: Sat, 15 Mar 2014 16:17:29 -0400

Paul Hoffman <[email-masked]> wrote:
    > A big +1 to Watson's simple explanation. DANE/TOFU/latching all specify
    > that if the initiator gets a key that is wrong, they will prevent
    > communication in order to protect the initiator. That works great until
    > a management issue happens, at which point you have a pissed-off
    > initiator who is likely to turn off more security than they should.

by "management issue", do you mean, the boss says, "make my email work"?
or something else.

In the SMTP case, I think that some headers and other things might well
indicate what happened such that if one decides to fail to clear, that at
least the receiver knows it happened (and has a list which nodes were
involved).

(Faking an MX record to redirect email is a different thing than doing an
active MITM attack against a TCP connection.  If you can intercept the TCP,
then the logs/Received lines all show the normal set of IPs, but might in the
TOFU case, flag the ends to say, "hmm. why wasn't this encrypted like last
time?")

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting for hire =-

---

From: Keith Moore <[email-masked]>
Date: Sat, 15 Mar 2014 16:24:42 -0400

> least the receiver knows it happened (and has a list which nodes were

Given that the receiver is rarely in a position to do anything about a 
problem with the path by which mail arrived, why does it actually matter 
in most cases?   (I mean, I'm fine with gathering statistics, but stats 
don't solve the problem of pervasive eavesdropping on mail transmissions.)

Keith

---

From: Michael Richardson <[email-masked]>
Date: Sat, 15 Mar 2014 16:48:20 -0400

> problem with the path by which mail arrived, why does it actually matter in
    > most cases?   (I mean, I'm fine with gathering statistics, but stats don't
    > solve the problem of pervasive eavesdropping on mail transmissions.)

awareness of a problem is the first step to fixing it?
I think that perpass said that detection was valuable.

---

From: Keith Moore <[email-masked]>
Date: Sat, 15 Mar 2014 16:56:37 -0400

> I think that perpass said that detection was valuable.
Detection/awareness are indeed valuable.  But I'm hoping that UTA can 
set the bar higher than that.

Keith

---

From: Yan Zhu <[email-masked]>
Date: Sat, 15 Mar 2014 15:20:14 -0700

> I would like to just throw this out here to see how much consensus there

In the browser world, opportunistic encryption is still hugely
controversial. At least one major vendor seems to be mostly against it.

> again.  

It's unclear that raising the cost of dragnet surveillance by
opportunistic encryption is meaningful against real-world adversaries.
Brad Hill is convinced that it would actually do more harm than good in
HTTP/2 and has written a good blog post here:
http://hillbrad.typepad.com/blog/2014/02/trusted-proxies-and-privacy-wolves.html.

-Yan

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 15 Mar 2014 23:22:39 +0000

Keith,

On 03/15/2014 06:34 PM, Keith Moore wrote:
> overall, I don't think opportunistic encryption [*] is worth much. 

You need to specify what you're measuring against though.

If compared to plaintext, then yes OK/OE has real value IMO.
TEMPORA demonstrates that as far as I can see.

Even if compared to server auth or mutally authenticated TLS,
OK/OE still has value as an intermediate interoperable state
that's far closer to authenticated endpoints than to plaintext.
I have heard many claims that e.g. Diameter is not run over
TLS even though it could easily be done. If OK/OE can be done
out of the box, then that will be an improvement for such cases.

> To be

You seem to be assuming that there is one right answer for how to
handle endpoint authentication. IMO there is not and when we've
made protocols that had that assumption built in that has been
problematic.

OK/OE is however a good state to which to add TOFU or whatever.
I would love to see us end up with OK/OE being the minimal thing
that is done with all new protocols. (Yes, its not that simple but
it would be beneficial I think.)

My bottom line: yes, there is significant value in specifying OK/OE
in many cases but mostly in those where it has a chance of being
widely used. And we have an abundance of news that tells us that
that would be worthwhile if done well.

> controversial. At least one major vendor seems to be mostly against

Their argument seems to be that we should try migrate the web to
https URIs instead because of some mythical "damage" that might
be caused by sending http URIs over TLS. Every single time I've
heard this (since last Nov) I've asked if these fans of big data
have any evidence whatsoever for that argument and every single
time they have admitted that no they have no evidence whatsoever,
even as recently as IETF89. The argument is frankly risible IMO
given that in 25 years of the web, we have only so far managed
to get 30% or so of sites to even be able to do some https.

S.

---

From: Alyssa Rowan <[email-masked]>
Date: Sun, 16 Mar 2014 00:14:52 +0000

On 15/03/2014 18:34, Keith Moore wrote:

> I wonder whether it's worth the effort for us to specify, and for
> implementors to implement, uses of TLS that only provide encryption
> which is easily defeated by man in the middle attacks.

Yes.

HTTP/2 (and other protocols) need it as their new baseline instead of
cleartext. It should never be presented as secure (https:), but it
defeats passive content analysis/manipulation. That is critical to
defeating deployed pervasive surveillance.

We should _also_ always try to defeat MITMs if possible as well, and
we should try to ensure a passive attacker can't detect if an MITM
would be detected or not, so that if they fire a broad MITM, they
stand a reasonable probability of being detected by someone.

But the lack of authentication shouldn't prevent us from encrypting
anyway, because cleartext is always worse.

Gosh, that was easy.

- -- 
/akr

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sun, 16 Mar 2014 08:31:49 +0100

On 15 Mar 2014, at 19:52, Keith Moore <[email-masked]> wrote:

>> All DANE/TOFU/latching imply a commitment by both sides to maintain and manage identity. This cost is why we don't encrypt today.
> 
> I don't think so.  I think we don't encrypt today because many application protocols solidified in the late 1990s when there were more barriers to use of encryption, and there simply hasn't been sufficient pressure to update them and overcome the inertia of the installed base until (perhaps) now.
> 
> Also, I don't see how DANE implies a commitment by both sides.  And I don't think latching or TOFU requires (much) additional effort on the part of sysadmins.
> 
> I'd need to see a specific proposal, but offhand trying to embed such requests in email headers strikes me as poor design (i.e. layering violation) and also easy to defeat.

The SIPS: URI was meant to be a way to request only transmission using verified TLS connections - but not on the last hop. This was later changed, but it is still a bit of a mess. There was never any way for a phone to verify if this really happened, especially with all the MITM boxes installed (SBCs PBXs = b2buas).  No error messages was defined to tell the client why a connection failed if TLS verification failed - it was just a connection error. 

The current feeling is that this was a bad idea from start and not a good solution. Due to lack of interest of security in the telephony space, nothing was designed to fix this. Maybe that too can change.

/O

---

From: Keith Moore <[email-masked]>
Date: Sun, 16 Mar 2014 05:21:11 -0400

On 03/15/2014 08:14 PM, Alyssa Rowan wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
Maybe I should have made my question a bit clearer.   My concern is that 
we'll go to the effort to specify, and implementors will go to the 
effort to implement, measures that only provide protection against 
passive eavesdropping.   Then MITM attacks will become more common, and 
we'll have squandered our opportunity to thwart them.

I do, however, recognize that when the client has no reliable way of 
knowing whether or not the the server supports TLS, it's difficult to 
raise the bar in such a way that doesn't invite MITM attacks. HTTP is an 
especially difficult case because clients talk to arbitrary numbers of 
servers.   Other protocols present other challenges.   But even in those 
cases I think we should do what we can to make MITM attacks less likely 
to succeed:  TOFU or latches or something similar.

For new protocols, I wonder if there's ever any reason to consider 
opportunistic encryption acceptable.
> anyway, because cleartext is always worse.

I agree with the above.

Keith

---

From: Leif Johansson <[email-masked]>
Date: Sun, 16 Mar 2014 15:01:22 +0100

> we'll have squandered our opportunity to thwart them.

Speaking as an individual...

You seem to be assuming that it is possible to "just switch to MITM". I
believe there is evidence to suggest that active MITM attacks are either
targeted and expensive or pervasive and hilariously, possibly
prohibitively expensive.

I think that the point of the exercise: dramatically increase the cost
of pervasive attacks on the system so that a real cost/benefit analysis
has to be made before investing in them.

	Cheers Leif

---

From: Alan Johnston <[email-masked]>
Date: Sun, 16 Mar 2014 10:14:45 -0400

The other important point is that one cannot accidentally MitM a session. A conscious effort and decision has to be made, and this is extremely important for both technical and policy/legal aspects of dealing with pervasive monitoring. 

- Alan -

> On Mar 16, 2014, at 10:01 AM, Leif Johansson <[email-masked]> wrote:
>

---

From: Keith Moore <[email-masked]>
Date: Sun, 16 Mar 2014 10:23:35 -0400

> targeted and expensive or pervasive and hilariously, possibly

To me it seems like there's a big spectrum ranging from narrowly 
targeted (relatively cheap) to widely pervasive (very expensive), and 
the attacks probably aren't all concentrated at one end of that spectrum.

Interception proxies aren't that expensive; lots of operators impose 
them on their customers for various kinds of traffic.   Getting a CA to 
generate bogus certs isn't necessarily that expensive either, especially 
if other kinds of coercion are available, though the CA will naturally 
want to avoid exposing itself and losing its status (and the attacker 
will presumably want to avoid exposing the CA).

> has to be made before investing in them.
I would define it slightly differently - whenever possible, raise the 
cost of attacks on network protocols to the point that they can only be 
justified if narrowly targeted.    That's a higher bar than merely 
requiring a cost/benefit analysis.

(of course, that merely means that more pervasive attacks will target 
operators' servers where the information will generally still be 
available in cleartext.   still, that seems like an improvement.)

Keith

---

From: Keith Moore <[email-masked]>
Date: Sun, 16 Mar 2014 10:29:58 -0400

> The other important point is that one cannot accidentally MitM a session. A conscious effort and decision has to be made, and this is extremely important for both technical and policy/legal aspects…
Well, it's also pretty difficult to "accidentally" eavesdrop on a 
cleartext session.   The attacker might not have cared about every 
single flow, but there was still deliberate action to get those bits.   
Though MITM targeting is likely to be narrower than that for passive 
attacks, neither MITM nor passive attacks are necessarily targeted to 
particular flows or users.

I've seen evidence of MITM attacks on ssh sessions on IETF's conference 
network.   Maybe that's not pervasive according to some people's 
definition, but neither do I suspect it was targeted at particular 
individuals.

Keith

---

From: Yan Zhu <[email-masked]>
Date: Sun, 16 Mar 2014 15:35:09 -0700

> available in cleartext.   still, that seems like an improvement.)

I agree that zero cleartext is an improvement; however, I fear that
sanctioning opportunistic encryption (OE) will hinder our long-term goal
of getting every server to use real TLS with key pinning, certificate
transparency, etc.

In other words, if lazy sysadmins get the impression that OE is "good
enough", they'll have even less motivation than they do now to deploy
authenticated TLS, which is the minimum level of security that we should
be asking for, given the scale of active MITM attack infrastructure that
NSA has allegedly been developing (ex:
https://www.eff.org/deeplinks/2014/03/new-nsa-slides-reveal-tailored-access-run-amok).

As a side note, I think some folks in this discussion may be
exaggerating the cost of active MITM attacks in a world with OE,
compared to the cost of passively collecting traffic. The cost
difference may be prohibitive to someone on their laptop sniffing
traffic at a coffeeshop, but it's unlikely to force ISPs and government
spy agencies to move to "narrowly targeted" surveillance; they can
easily MITM every OE connection or force a downgrade.

A security engineer for a large browser vendor who has more perspective
than I do on this particular issue wishes to anonymously contribute the
following argument:

"""
OO: Opportunistic Obfuscation. I won't honor unauthenticated encraption
with the name "encryption".

Many site operators are looking for any reason at all to not do any work
to authenticate or otherwise secure their services. The stronger the "OO
is OK" view is presented, the more they will tend to believe that when
HTTP2 rolls out, the less work they will have to do. "OO is Better Than
Nothing," they'll say. "That should be good enough for our users." It is
not. OO would slow the adoption of real security.

There is a range of options on the continuum between passive and active
attack, at varying cost levels. Meditate on the Snowden documents,
especially the QUANTUM stuff. And in any case, attacks always get better
(cheaper, more powerful), never worse. Even if OO were sufficient now
(it's not), it would not suffice next year.

Our reasonable fear is that states have compromised CAs, making
fully-authenticated, real HTTPS ineffective or less effective. (Hence
PKP, TACK, and CT.) The idea that OO is enough to stymie the most
powerful militaries in the world does not pass the giggle test.
"""

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Sun, 16 Mar 2014 21:28:41 -0400

On 03/15/2014 03:45 PM, Keith Moore wrote:
>> A big +1 to Watson's simple explanation. DANE/TOFU/latching all
>> specify that if the initiator gets a key that is wrong, they will
>> prevent communication in order to protect the initiator.
 [...]
> etc. for validity and correctness.

Just to clarify, the work you're describing *is* the "commitment ... to
maintain and manage identity" that Watson and Paul are identifying as a
major barrier that has kept systems administrators from deploying strong
crypto.

This maintenance work is extra work that does not have to be done by a
server operator who only runs cleartext services.

Opportunistic keying (OK) also doesn't require this extra work.

OK doesn't replace or supplant encryption with properly authenticated
endpoints.  It replaces and supplants cleartext communications, while
placing no additional demands on system administrators.

Those administrators still really should move to proper strong crypto,
and software developers should produce tools with a sane UI/UX that can
minimize the hassle involved with ongoing cryptographic credential
maintenance work, to reduce the barrier that still remains.

	--dkg

---

From: Keith Moore <[email-masked]>
Date: Sun, 16 Mar 2014 21:42:43 -0400

> server operator who only runs cleartext services.
Even if you're only running cleartext services, you need to monitor your 
servers to make sure your machines are up and running within reasonable 
parameters, your DNS servers are answering queries, your application 
servers are servicing requests.   You also generally need to make sure 
that your OS and application servers are maintained and security fixes 
are up-to-date.   Checking certificates and security-related DNS records 
are just a couple of additional variables to monitor, and maintaining 
current certificates is a small amount of additional burden on top of 
maintaining current OS and application servers and security patches.    
If monitoring systems can't do this already, it's just a SMOP to fix 
that (and I'm sure we can scare up some people to write the code).

I suspect that a much more significant barrier is operator reluctance to 
do anything that will make their servers appear to customers to be less 
reliable, and/or increase the operator's support cost.   Increasing 
security without increasing operator pain (much) is likely to require 
very careful engineering, and we should not pretend otherwise.

> placing no additional demands on system administrators.

I see no reason that IETF should endorse opportunistic obfuscation (I 
agree with the anonymous source that both OK and OE are misleading) for 
any protocol that is capable of doing better, and I have yet to see a 
protocol that isn't capable of doing better.  OO simply doesn't meet the 
basic "no known technical omissions" requirement of Proposed Standard 
status.

Keith

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 17 Mar 2014 02:41:57 +0000

Anonymous reporting in this venue from such sources should
get the respect it deserves: i.e zero. The bogus non-argument
stated has in fact already been better made (it would be hard
to do as poorly TBH) in public by named broswer folk and is
crap both in that guise nbut even moreso as reported anonymously
at second hand.

>> requiring a cost/benefit analysis.

Cost/benefit is gibberish. The main PM attacker here is
government who care less about costs and are willing to
construe benefits to justify the spent-cost.

ISTM far more credible to assume that the attacker here
cares nothing about costs and would actually prefer higher
costs in order to assist with empire building.

> I agree that zero cleartext is an improvement;

That's very hard to believe. At least that's the only conclusion
I can reach based on the entire mail. Feel free to disabuse me of
my confusion but it really appears as if you prefer cleartext.

There are arguments to be made against OK/OE encryption but you
seem to utterly miss all of those below.

> however, I fear that

Nonsense says me with exactly as much evidence as you, i.e. none.

However, I do additionally have some evidence - we know that
ciphertext != plaintext and we have many reports from credible sources
that plaintext helps pervasive monitoring a lot. And in fact that
is logically as plain as the noses on all our faces.

That kind of "if we do something, some other bad thing may happen"
argument is utterly bogus IMO.

If we do nothing, then the current bad things will just keep on
happening, but increasingly on behalf of more and more bad actors
as others jump on NSA and GCHQ's bandwagon.

If you have evidence of some negative effect, relate it. If you
have logical argument, then relate that. If you have neither then
please do not promote gibberish - silence would be better in that
case. Thus far, you are IMO only promoting gibberish.

The rest of your mail is simply negative nonsense but I will
respond nonetheless. Readers short of time can stop reading here
though since neither the supposed argument nor the obvious
refutations are at all content-ful.

> 
> In other words, if lazy sysadmins 

"lazy sysadmins" is pure BS rhetoric

> get the impression that OE is "good
> enough", 

"good enough" for what? please make a non-empty statement that
is amenable to evaluation.

> they'll have even less motivation than they do now to deploy

Even less than now, according to what body of evidence?
None? Ah ok. So you're just spreading baseless rumour then?
If so, it really is better to be clear about that. A label
that says "fiction" is the usual way to deal with that.

> authenticated TLS, which is the minimum level of security that we should

"the minimum" begs the overall question which you started out
(pretending?) to wonder about. There is no need to accumulate
logical fallacies for fun, honestly.

> https://www.eff.org/deeplinks/2014/03/new-nsa-slides-reveal-tailored-access-run-amok).

There are many news releases that imply that plaintext is either
the meat for their monitoring or else is required for launching
a man on the side attack.

There is no evidence so far that I know of that indicates that
MITM attacks against even moderately well implemented crypto can
be done at anything similar in scale. Do correct me in detail
if I am wrong.

There is an abundance of evidence that endpoint authentication
is a sufficient barrier to make turning on crypto too hard for
enough folks for that to be important.

> compared to the cost of passively collecting traffic. 

Feel free to supply us with facts. No? Ah ok.

Feel free to quote someone who argues for OK/OE who has
misrepresented its benefits. I don't recall such.

> The cost

Earlier you asserted cost/benefit analysis as an argument, now
you assert that cost is irrelevant and for an as-far-as-we-kmow
much more costly attack than recording plaintext.

And your base assertion is highly questionable. Plaintext is
free if the attacker can keep up with traffic speeds. If we
can add even crappy crypto (say DES brute-force) overhead to
that then we win.

Feel free to argue in detail that I am wrong here.

> than I do on this particular issue wishes to anonymously contribute the

BS. There are no significant browser makers who have not spoken
up on this as part of the HTTP/2.0 discussion that I know of. If
there are internal arguments within such organisations, I hope
they are of far higher quality than this piece of innuendo laden
nonsense.

S.

---

From: Keith Moore <[email-masked]>
Date: Mon, 17 Mar 2014 03:52:29 -0400

On 03/16/2014 10:41 PM, Stephen Farrell wrote:
> Cost/benefit is gibberish. The main PM attacker here is government who 
> care less about costs and are willing to construe benefits to justify 
> the spent-cost. ISTM far more credible to assume that the attacker 
> here cares nothing about costs and would actually prefer higher costs 
> in order to assist with empire building. 

I think we do ourselves (and the Internet community) a disservice to 
assume that there's just one (kind of) attacker against whom we need to 
defend.
> argument is utterly bogus IMO.

It's not utterly bogus to realize that attackers who apparently have few 
constraints on their funding are going to keep attacking even if they 
have to spend more money to do it.  Nor is it even that difficult to 
understand what their next steps are likely to be.

Absolutely we do know that ciphertext, even between unauthenticated 
parties, is better than plaintext.  There's no question about that, and 
I don't see anyone arguing that we shouldn't try to raise the bar.   
What we don't know is whether that kind of ciphertext will deter the 
well-funded major-state-supported SIGINT organization, to any 
significant degree, over the long term.    And while that's not the only 
kind of threat that we're concerned about, it is one of them.
> as others jump on NSA and GCHQ's bandwagon.

I don't see anyone advocating doing nothing, so I'm not sure why you're 
saying this.
> be done at anything similar in scale. Do correct me in detail
If the only threat you're concerned about involves intercepting fibers 
that carry huge amounts of traffic, I'd agree - MITM attacks against all 
of the traffic in that fiber there are very hard to implement.   But I 
don't see any reason to assume that those are the only threats against 
which we need to be concerned.

> enough folks for that to be important.

Do I misunderstand you, or are you really arguing that we don't need to 
do any more than defend against passive attacks?

Keith

---

From: Michael Richardson <[email-masked]>
Date: Mon, 17 Mar 2014 08:30:46 -0400

To a pervasive monitor that sees/intercepts traffic only the middle
(i.e. they did not monitor/intercept DNS/OCSP/etc. requests),
OK enabled traffic is hard to distinguish from pre-configured security.

As such, the more crypto traffic there is, the harder it is to decide
which traffic can be MITM without detection.

(IKE/IPsec is slightly better in terms of traffic analysis of
crypto-identities and port numbers here)

>argument is utterly bogus IMO.

Or, "better is the enemy of good enough".
Throughout the over-long review of 4322, I came to understand that the people
who kept saying that were the NSA pawns/moles.  Pawn, because I came to
understand that many of them were unaware of what they were doing.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 17 Mar 2014 14:47:32 +0100

I'd like suggest a change of direction for this discussion.  If we get a
bit more specific about the use cases, it will become clear when it is
reasonable to make use of fully authenticated (bidirectional) TLS; when
it might make sense to do *some* form of opportunistic keying and when
it makes sense to do nothing (there are, I think some limited cases for
not encrypting).  Keith well knows the situation with email, and in fact
the draft that he and Chris seems like a good place to go back to.

Keeping in mind that the ecosystem for email clients is extremely
diverse, ranging from complex UIs to PHP modules to age-old shell
scripts, and from private environments to the wild and woolly Internet,
if our goal is to get TLS to be the default then one has to ask this
question: why is it not already so?  The answer might be a useful
addition to the draft.

So for instance, if clients are meant to speak TLS either by default or
all the time, what does it look like on the server end in an enterprise,
we know that enterprises have great difficulty managing certificates,
both in terms of initial configuration and ongoing maintenance.  Some of
it is just not wanting to go to a CA for a cert again and again.  Some
of it is simply keeping track of what expires when.

Also, perhaps there are some enterprise environments where DANE is
perhaps more feasible than in the wild Internet.  The authors take this
into account in Section 2.2.12 (I think), but perhaps some support text
about when and how DANE is used would prove useful.  It might also
motivate those who are writing MUAs to actually implement DANE.

Anyway, hopefully you'll find this food for thought.

Eliot

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 17 Mar 2014 09:55:22 -0400

> But the lack of authentication shouldn't prevent us from encrypting anyway, because cleartext is always worse.

You're not worried about imbuing a false sense of security?

> Gosh, that was easy.

Maybe not.

	/r$

--  
Principal Security Engineer
Akamai Technology
Cambridge, MA

---

From: Alyssa Rowan <[email-masked]>
Date: Mon, 17 Mar 2014 14:03:45 +0000

On 16 March 2014 14:23:35 GMT+00:00, Keith Moore <[email-masked]> wrote:
>Getting a CA to generate bogus certs isn't necessarily that expensive either, especially if other kinds of coercion are available, though the CA will naturally want to avoid exposing itself and losing its status (and the attacker will presumably want to avoid exposing the CA).

The Certificate Transparency initiative will successfully expose this, I believe, and radically increase the "cost" (in credibility and, therefore, in hard currency) of a CA collaborating with an attacker, wittingly or unwittingly. It will make any such actions uncomfortably overt: they'll 'burn' a CA every time. Browsers should be (and I believe are) considering imposing this requirement on all CAs in the public trust pool going forward, at some point.

DANE will also help, limiting the pool of applicable CAs usable for any such attack so that the attacker need not just attack the weakest in the pool.

Where governmental CAs exist, maybe they should be limited to the scope of their ccTLD (does PKIX actually have any facilities for this; if so, why aren't we using it)?

It's clear to me that any and every public CA needs to guarantee to be impervious to targeted attack by any determined nation-state adversary, including the one in which they reside, or they are simply not trustworthy enough: and that's an _incredibly_ daunting and challenging threat model to address (I'm not even sure where I'd start: with an open '140-2 L4+'-class HSM?), but that's the guarantee we need them to keep to.

I suppose we shall see, in time, which are up to that challenge, and which are not...

- --
/akr

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 17 Mar 2014 15:09:46 +0100

> Where governmental CAs exist, maybe they should be limited to the scope of their ccTLD (does PKIX actually have any facilities for this; if so, why aren't we using it)?

That is not going to fly. Many CCTLDs have rules that make it hard to stay within the ccTLD, even for governments. Things have changed for the better, but we had a lot of public web sites in other domains than .se here in Sweden 
and propably still have.

/O

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Mon, 17 Mar 2014 10:14:13 -0400

> You're not worried about imbuing a false sense of security?

To whom might we be imbuing a false sense of security?  Every proposal
I've seen for OK suggests that indications to normal users should be
identical to cleartext.  So we're not giving them any sense of security
(and rightly so).

If you're concerned about server administrators, i think anyone who
administers a server on the internet needs to be able to understand
"this is no more secure than cleartext if your adversary can control any
part of the network path", even if they don't understand the details
about why.

So who are we concerned about?  Management?  Their message is "users
won't see any security indicators, because your OK-wrapped service is
not fully secured".

I agree that the messaging around this is critical, because we don't
want people to misunderstand it.  The general message needs to be as
simple as " Opportunistic Keying can't even defend against a malicious
coffeehouse wifi access point" -- which is something most people have
actually encountered.

The argument for why it is socially useful if widely deployed as a
cleartext replacement (i.e. the increased cost of universal
surveillance) is more subtle, but arguably fewer people need to
understand it, since there should be very little user or admin
interaction to enable it.

	--dkg

---

From: Alyssa Rowan <[email-masked]>
Date: Mon, 17 Mar 2014 14:35:09 +0000

On 17 March 2014 14:09:46 GMT+00:00, "Olle E. Johansson" <[email-masked]> wrote:
>That [limiting scope of governmental CAs to respective ccTLDs] is not going to fly. Many CCTLDs have rules that make it hard to
>stay within the ccTLD, even for governments.

One might suggest that's their own issue to solve.

Punch trust anchor exceptions with DANE?

- --
/akr

---

From: Alyssa Rowan <[email-masked]>
Date: Mon, 17 Mar 2014 14:37:17 +0000

>You're not worried about imbuing a false sense of security?

User-agents MUST NOT indicate that an unauthenticated connection is secure.

There. Done. No locks, no https:.

>Maybe not.
Seems easy enough to me. :-)

- --
/akr

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 17 Mar 2014 14:51:46 +0000

> You're not worried about imbuing a false sense of security?

Protocols do not imbue any sense of security, true, false
or purple. Implementations do that.

All the sensible people here are assuming that if OK
is used, then there ought be no UI indication at all
(for foo/TLS protocols where UI is even relevant).

I think that has been repeated ad-nauseum.

S

> 
>> Gosh, that was easy.
> 
> Maybe not.
> 
> /r$
> 
> -- Principal Security Engineer Akamai Technology Cambridge, MA
> 
> _______________________________________________ Uta mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/uta
>

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 17 Mar 2014 14:51:50 +0000

Eliot is correct IMO.

S

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 17 Mar 2014 14:56:09 +0000

Keith,

Please point out *anywhere* that I have said that passive
attacks are the only thing to worry about, or where I have
said that pervasive monitoring is the only attack to worry
about. You will not find that since I have repeatedly said
the opposite. PM is one more thing to worry about, but is
one where we've (security eggheads like me) previously not
done a very good job. That plus the news fully explains the
current focus. And that's blatantly obvious.

And (hopefully) lastly, I have no clue as to why you started
this thread if you believe that "Absolutely we do know that
ciphertext, even between unauthenticated parties, is better
than plaintext." OK/OE-has-value follows immediately from
that.

S.

---

From: "Olle E. Johansson" <[email-masked]>
Date: Mon, 17 Mar 2014 16:01:53 +0100

On 17 Mar 2014, at 15:51, Stephen Farrell <[email-masked]> wrote:

>> scripts,

After reading the PHP project RFCs that was referred to earlier in this thread,
I am wondering if we should write a best current practise for embedding
http (and possibly other TCP based) protocol calls in another language or toolkit.

In my own world, both Kamailio and Asterisk has a mix of CURL and raw hacks
that do HTTP and HTTPS without exposing much or anything to the developer
of the configurations. Where to configure crypto is a mystery to me, how certificate
matching happens (if at all) is poorly documented and I see no error codes 
that apply to TLS.

I wonder how it is in LUA and other script languages that can be embedded in
other products. We have LUA in both Asterisk and Kamailio. Something I need
to check up after my Javascript and WebSocket depression.

We could - based on the PHP stuff maybe - come up with some guidelines.

"If you make it possible to script use of HTTPS - make sure that X is documented,
that the developer/sysadmin can change Y and possibly handle Z, Q and R errors
in connection setup".

As long as everyone copies from another language or another usage of CURL,
we're not improving. The PHP team seems to have taken a lead here.

/O

---

From: Keith Moore <[email-masked]>
Date: Mon, 17 Mar 2014 15:25:03 -0400

> current focus. And that's blatantly obvious.

Stephen,

I'm probably just missing some context, since I've been out of the loop 
for several of these discussions for some time.   But at IETF I heard 
several people talking only about PM and OE and this seemed to me to be 
odd given that there are clearly other threats that aren't well 
addressed by our current ways of using TLS in applications. And that's 
why I started this thread, because if there were any significant 
sentiment in the group that all we needed to do was OE, I'd want to know 
about it (and probably try to convince people otherwise) ASAP.  Of 
course, if there's no significant sentiment along these lines, that's 
also useful information.

I think Eliot Lear made a good point that different solutions may be 
appropriate in different use cases.   There may be some use cases in 
which OE is the best we can reasonably hope to do.

> than plaintext." OK/OE-has-value follows immediately from
To clarify, I never intended to question whether OE has value.  It was 
more of a question of whether it's worth the trouble to _only_ specify 
and implement OE (without anything else, like TOFU or latching), and 
also whether we shouldn't take advantage of this rare opportunity when 
there's widespread interest in fixing things, to try to raise the bar 
more than that.   But again, this is probably something that needs to be 
evaluated on a case-by-case basis.

Keith

---

From: "Orit Levin (LCA)" <[email-masked]>
Date: Tue, 18 Mar 2014 04:56:22 +0000

On this positive note, could we continue the O* discussion (and hopefully the work itself) on SAAG instead of UTA for now, as it had been agreed earlier? ;-)

Between SAAG and UTA lists, we do have a plenty of experts' opinions on different techniques now. They need to get organized in terms of their value and applicability to different use cases. That needs to happen before we start writing new O* procedures for TLS 1.2 and below. (We also should be attentive to the TLS 1.3 discussions/arguments happing right now on TLS.)

After all, right now we do have a full plate of things to do in UTA to increase TLS secure use by applications with or without O*.

Cheers,
Orit.

> -----Original Message-----
> From: Uta [mailto:[email-masked]] On Behalf Of Keith Moore
> Sent: Monday, March 17, 2014 12:25 PM
> To: Stephen Farrell; Yan Zhu
> Cc: [email-masked]; Leif Johansson; Eliot Lear
> Subject: Re: [Uta] opportunistic keying / encryption considered of dubious
> value
>

---

From: Rick Andrews <[email-masked]>
Date: Wed, 19 Mar 2014 13:42:02 -0700

-----Original Message-----
From: Alyssa Rowan [mailto:[email-masked]] 
Sent: Monday, March 17, 2014 7:04 AM
To: [email-masked]
Subject: Re: [Uta] opportunistic keying / encryption considered of dubious value

On 16 March 2014 14:23:35 GMT+00:00, Keith Moore <[email-masked]> wrote:
>>Getting a CA to generate bogus certs isn't necessarily that expensive either,
>>especially if other kinds of coercion are available, though the CA will
>>naturally want to avoid exposing itself and losing its status (and the attacker

>The Certificate Transparency initiative will successfully expose this, I believe,
>and radically increase the "cost" (in credibility and, therefore, in hard currency)
>of a CA collaborating with an attacker, wittingly or unwittingly. It will make any
>such actions uncomfortably overt: they'll 'burn' a CA every time. Browsers
>should be (and I believe are) considering imposing this requirement on all CAs
>in the public trust pool going forward, at some point.

Keep in mind that CT is only intended for public EV certs for now (certs chaining up to a public root in a browser's trust store); eventually it may expand to OV and DV, but it will still only cover public certs. If OE/OK makes use of non-public SSL certs, CT won't help.

-Rick

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 20 Mar 2014 10:53:02 +0000

Just clarifying, this has no partcular impact on the thread.

On 03/19/2014 08:42 PM, Rick Andrews wrote:
> Keep in mind that CT is only intended for public EV certs for now
> (certs chaining up to a public root in a browser's trust store);
> eventually it may expand to OV and DV, 

I think you're conflating chrome's plans for how to use CT
and the CT protocol, which has nothing to say about EV that
I recall.

> but it will still only cover
> public certs.

That's true for rfc6962, but the trans WG have a ticket open
to discuss that. Mostly that discussion is not about self
signed certs but about certs used e.g. within enterprises
that chain up to a public CA.

S.

---

From: Trevor Perrin <[email-masked]>
Date: Fri, 21 Mar 2014 17:22:49 -0700

> crap both in that guise nbut even moreso as reported anonymously

Catching up on this list.

The rest of Stephen's response to Yan is below.

Yan made a well-reasoned argument deserving of respect.  The inclusion
of some comments from a browser developer added insight into how this
debate is viewed by people who matter.

I probably agree with Stephen's argument more than Yan's, but I found
the level of vitriol in Stephen's response to be startling, and not
the sort of tone our Area Director should be setting.

Trevor

---

From: Stephen Farrell <[email-masked]>
Date: Sat, 22 Mar 2014 14:16:43 +0000

> the sort of tone our Area Director should be setting.

Well, to err is human and I am. So yes, maybe the tone was a bit
harsh.

However, I don't like to see anonymous quotes. I also don't like to
see the same bogus argument raised over and over without its
proponents ever addressing the obvious criticism made the very first
time the argument was raised. (The criticism being "you have no
evidence whatsoever.") And in this particular case, the folks
making the bogus argument are from the same set of folks who constantly
make arguments based on their relatively privileged access to
bulk data about the web. So when that set of folks start making
utterly unfounded arguments without a shred of evidence offered they
should expect to be beaten up using their own style of argument.
(Many swords do have two edges:-)

So maybe a bit harsh. But I don't regret it a bit.

S.

---

From: Trevor Perrin <[email-masked]>
Date: Sat, 22 Mar 2014 13:00:42 -0700

On Sat, Mar 22, 2014 at 7:16 AM, Stephen Farrell
<[email-masked]> wrote:
> evidence whatsoever.")

Widespread TLS for HTTP is an experiment that hasn't been tried yet.
We don't have "evidence" either way.  All we can do is hear out the
arguments and try to weigh them.

The argument that TLS for HTTP might have some ill effects is not
obviously "bogus".  Even Mark Nottingham, a proponent, has a fair
summary of some potential downsides:

(see "Why Not?")
http://www.mnot.net/blog/2014/03/17/trying_out_tls_for_http_urls

At the IETF, Opportunistic Encryption is one of the major initiatives
responding to "Pervasive Monitoring".  Thus it's claiming attention
that could possibly be directed at other things (pinning,
transparency, e2e messaging, better crypto, better PKI or client auth,
etc).

It's reasonable to consider whether we'll get a good return on the investment.

> And in this particular case, the folks

You mean the browser devs who support the world's main TLS libraries
and TLS applications, understand the HTTPS ecosystem better than
anyone, and are the implementors (and thus gatekeepers) for any
changes?

We should be encouraging more of their participation and viewpoints.

It's frustrating when they don't race to support your great new idea.
I've been there.  But working to "beat up" and alienate them is not
the solution.

Trevor

---

From: Watson Ladd <[email-masked]>
Date: Sat, 22 Mar 2014 14:25:57 -0700

> anyone, and are the implementors (and thus gatekeepers) for any

Personally I have never understood why connecting to a site with a bad
certificate shows me a warning, while visiting a site over HTTP does
not.

It should simply not indicate security. Perhaps an exemption should be
made for some websites which have known good certificates but then the
UI should never permit bypassing checks. Current behavior amounts to
limiting the use of alternatives to the current PKI, without actually
providing a gain in security. Browser vendors are working on DANE,
TACK, and CT, which I think are much more promising for encrypting
everything if we can reduce the administrative load involved.

Sincerely,
Watson Ladd

---

From: "Christian Huitema" <[email-masked]>
Date: Sat, 22 Mar 2014 23:08:07 -0700

> certificate shows me a warning, while visiting a site over HTTP does

That's probably the hardest part of the "opportunistic encryption" effort.
The user interface that you describe was developed in accordance to the
principles of PKI, for which the norm is a valid certificate signed by an
approved authority. We know that these principles lead to severe deployment
issues. There is of course the financial cost of paying for the certificate,
but that's probably not the biggest problem. There is a cost in installing a
certificate on a web server. Having an expiration date in the certificate
forces periodic administrative action that are cumbersome for small sites,
and have occasionally tripped large sites. If a site wants to switch to a
longer key, they need a new certificate, yet another cumbersome process. And
then there is the whole issue of authorities being able to spoof
certificate.

We know all that, but at the same time we do not have yet a good
alternative. How does a  client distinguish between a legitimate self-signed
certificate and a clumsy man-in-the-middle attack? If a client sees an
expired certificate, how does it distinguish between a lazy administrator
and an attacker reusing an expired and possibly compromised certificate? If
we can answer these questions, and agree on better user interface
guidelines, then we can possibly reduce the friction associated with the
deployment of TLS in small sites.

-- Christian Huitema

---

From: t.p. <[email-masked]>
Date: Tue, 25 Mar 2014 09:37:47 +0000

----- Original Message -----
From: "Watson Ladd" <[email-masked]>
To: "Trevor Perrin" <[email-masked]>
Cc: <[email-masked]>; "Stephen Farrell" <[email-masked]>
Sent: Saturday, March 22, 2014 9:25 PM
> >.

In a similar vein, but perhaps at a slight tangent, I have never
understood why every browser I have installed has CRL checking turned
off.  Or perhaps I do, since when I turn it on, I find that there are
those on IETF lists who send e-mails which invoke CRLs over 1Mbyte in
size which take 30s to download every time I want to view their e-mail
(round trips, not bandwidth, being the problem).

So do we continue to recommend that CRL checking is turned off and so
open certificates to another attack vector?

Tom Petch

---

From: Adam Langley <[email-masked]>
Date: Tue, 25 Mar 2014 06:59:29 -0400

> certificate shows me a warning, while visiting a site over HTTP does

Because if you request a secure connection (https://) and we can't
provide it then there needs to be a very clear indication of that. If,
instead, the result was simply that it looked like an HTTP site then
everyone would "need" to check whether they actually got a secure
connection after requesting one and I don't think that people would.

Cheers

AGL

---

From: t.p. <[email-masked]>
Date: Tue, 25 Mar 2014 11:52:33 +0000

----- Original Message -----
From: "Adam Langley" <[email-masked]>
To: "Watson Ladd" <[email-masked]>
Cc: "Trevor Perrin" <[email-masked]>; <[email-masked]>; "Stephen Farrell"
<[email-masked]>
Sent: Tuesday, March 25, 2014 10:59 AM
> connection after requesting one and I don't think that people would.

Around me, the media are forever telling people to check for the padlock
at the bottom of the screen; padlock present, secure connection, safe to
go banking and shopping - padlock absent, do not pass go.  I cannot
recall when last I heard any such mentioning the difference between
http: and https:.

That is the reality for those here who know no better, and I imagine
that that attitude is widespread.  I also recall that, until not all
that long ago, the PC at my local 'cybercafe' had SSL 2 as a valid
option, TLS above 1.0 not.  They were, of course, using the browser of a
major vendor with its default settings.  I do not know their policy with
respect to Security Patches.

Tom Petch

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 26 Mar 2014 10:26:59 -0600

On 3/17/14, 7:47 AM, Eliot Lear wrote:
> I'd like suggest a change of direction for this discussion.

I would, too. :-)

My recollection from conversations in Vancouver is that we were seeking 
a quick win of documenting best practices for the existing use of TLS 
and PKI - TLS versions, cipher suites, etc. With all the conversations 
over terminology, unauthenticated encryption, DANE as a new mode in 
addition to PKI, etc., I wonder if we could at least push forward 
quickly with the TLS-PKI recommendations and, in parallel, work out the 
thornier issues.

Peter