Subject: [saag] POODLE in detail (was Re: NTP security, and thoughts on Hawaii)

From: Watson Ladd <[email-masked]>
Date: Mon, 3 Nov 2014 22:29:03 -0800

On Mon, Nov 3, 2014 at 8:59 AM, Kathleen Moriarty
<[email-masked]> wrote:
> On Mon, Nov 3, 2014 at 10:42 AM, Kathleen Moriarty
> <[email-masked]> wrote:
>> Hello,
>>
>> Thanks for sharing your thoughts.
>>
>> On Sun, Nov 2, 2014 at 4:56 PM, Watson Ladd <[email-masked]> wrote:
>>> Dear all,
<snip>
>>>
>>> I also hope that in Hawaii SAAG carefully examine the role of IETF
>>> working groups in promoting security, the lack of effective
>>> depreciation of old protocols, the relations between implementors,
>>> standards bodies, and administrators, and how we are going to get to a
>>> world in which every packet is encrypted with security protocols that
>>> work. I don't think that the current agenda or drafts advance this
>>> goal.
>>
>> We've started a little bit of discussion on this topic between a few
>> of the ADs, but have not taken it far enough yet.  It's a bit tricky
>> to figure out what the right approach will be and more discussion is
>> needed.  I'll see if there is time to add this on the agenda, but
>> would encourage more suggestions to be discussed on the SAAG list in
>> the meantime.  I don't like the idea of waiting for something to break
>> before fixing it as what happened with POODLE.  It's also hard to get
>> everyone to make the switch or enough to have the impact.  This
>> particular topic does require more consideration and I think anything
>> we do would need to be coupled with marketing (even twitter in a
>> positive way - praising those who have made updates) to motivate
>> change.
>>
>
> I should have mentioned phasing out SSL 3 here as the example.  Some
> of the difficulties we'll have to consider in how the IETF can
> influence change and phasing out older protocols, algorithms, etc. is
> the way vulnerability disclosure is handled between companies.  For
> good reason, it is a very private process between those effected with
> strict disclosure rules prior to any announcements.  Often, vendors
> will want to be ready with the actions they plan to take prior to
> announcements to mitigate the effect (ability to exploit) the
> vulnerability could have once announced.

Let's look at the SSLv3 situation in detail. SSLv3 only websites were
a vanishingly small fraction of the Internet, and SSLv3 only browsers
a vanishingly small percentage of the population. SSLv3 was
depreciated successfully, if we look at how often it was used. But
that depreciation meant nothing so long as a man in the middle could
cause both sides to fallback. The solution was extremely simple, but
we're only deploying it now, after knowing for years fallback could be
a problem, and how to solve that problem.

This wasn't because of the closed nature of vuln disclosure (which
didn't help/has changed over the years), or because of compatibility
issues. It was because the TLS WG ignored the reality of fallback
logic, and the need to protect it. This work didn't need to wait until
POODLE and BEAST, which themselves were anticipated by well-publicized
but not well understood attacks on the record layer. Likewise, the
decision not to flip the MAC and encryption was made, and made again,
and now we've finally fixed it.

Similarly, the failure of autokey to protect pool.ntp.org was apparent
from the begining of the design effort, as was the reality that CAs
can be broken and that we have no defense. We should consider what can
go wrong, and prepare for it to go wrong, so when it goes wrong,
nothing happens. I don't see how "responsible" disclosure to some
plays into being proactive, or affects the depreciation of protocols
with well-known flaws.

(I am amused to see an IPv4 sunsetting WG. Someone is being
extraordinarily optimistic about our depreciation abilities)

Sincerely,
Watson Ladd
>
>
>> Thanks,
>> Kathleen
>>
>>>
>>> Sincerely,
>>> Watson Ladd
>>>
>>> _______________________________________________
>>> saag mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/saag
>>
>>
>>
>> --
>>
>> Best regards,
>> Kathleen
>
>
>
> --
>
> Best regards,
> Kathleen

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

---

From: Yoav Nir <[email-masked]>
Date: Tue, 4 Nov 2014 10:09:48 +0200

On Tue, Nov 4, 2014 at 8:29 AM, Watson Ladd <[email-masked]> wrote:

> logic, and the need to protect it.

I think this has little to do with the TLS working group. Fallback logic is
a relatively new phenomenon. Microsoft chose to make TLS disabled by
default when IE was 95% of browsers. Websites weren't punished for not
tolerating TLS, so the "small" browsers like Firefox and Opera had to
implement fallback logic or have a bunch of sites that don't work on their
browser.

As for protecting fallback, this was suggested as far back as 2006:
https://tools.ietf.org/html/draft-pettersen-tls-interop-experience-00
It's a shame that it took so long to act upon this.

> This work didn't need to wait until

Not quite. There is an RFC that's hardly implemented. TLS 1.3 will fix
this, but that's a long way off.

> extraordinarily optimistic about our depreciation abilities)

The IETF doesn't get to tell the market what to do. The idea is that IPv4
is being deprecated anyway (by countries like China and Romania who were
late to the party and didn't get to grab a lot of the IPv4 space), and that
the IETF needs to build transition mechanisms. Whether the market will use
them is up to the market, not us. That is why we would like to have more
operators participate. Similarly, if we had more people who manage
websites, it would be a good thing for TLS and HTTPBIS.

Yoav

---

From: ianG <[email-masked]>
Date: Tue, 04 Nov 2014 12:30:57 +0000

On 4/11/2014 08:09 am, Yoav Nir wrote:

> I think this has little to do with the TLS working group. ...
> Whether the market will use them is up to the market, not us.

That may be the way IETF thinks.  Meanwhile, there are great swathes of
industry that think this way:

  "OK, you're right.  Security is screwed.  But we can't do
   anything about it because we only implement standards.

   Go speak to the IETF!"

The best bit about this deadly embrace of insecurity is that both sides
are perfectly right, logical, just, consistent.

Meanwhile the users get screwed.

> That is why we would
> like to have more operators participate. Similarly, if we had more
> people who manage websites, it would be a good thing for TLS and HTTPBIS.

Yeah, that's the other thing I noticed in my lost decade of trying to
get someone anyone to do something.  No users are represented on any
committees.  Sometimes for understandable reasons, like committees are
boring and repetitive and filled with argumentative curmudgeons like
myself.  Other times because the charter or group is explicitly set up
to exclude them.  (In the SSL business, that was the norm.)

I'm on a group of users called BetterCrypto.org.  Here's their current
recommendation:

  SSLProtocol All -SSLv2 -SSLv3

  SSLCipherSuite
'EDH+CAMELLIA:EDH+aRSA:EECDH+aRSA+AESGCM:EECDH+aRSA+SHA384:\
EECDH+aRSA+SHA256:EECDH:+CAMELLIA256:+AES256:+CAMELLIA128:+AES128:\
	+SSLv3:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:\
	!ECDSA:CAMELLIA256-SHA:AES256-SHA:CAMELLIA128-SHA:AES128-SHA'

They worked like dervishes and got it down to that, last was about
double!  A big thank you to the TLS WG for making the lives of the poor
sysadm darn near impossible, sisyphean.

iang

---

From: "Salz, Rich" <[email-masked]>
Date: Tue, 4 Nov 2014 11:15:41 -0500

> I'm on a group of users called BetterCrypto.org.  Here's their current

First, I don't think you can blame the TLS WG for adding national ciphers to the protocol. It's a constant battle, apparently, but SEED GOST CAMELLIA, etc., aren't the TLS group's fault. Once national politics got into it, there's not much the IETF can do.

Second, that cipher suite is, well, gross complicated and confusing.  Also not the TLS WG fault. Blame it on poor use of OpenSSL (and where you then divide that blame isn't clear) if you must.

I ran the list through 'openssl ciphers.'  The ordering is strange, intermixing AES-GCM with AES and Camellia.  I'd put AES-GCM first, and then drop Camellia for simplicity. And then only list the algorithms I do want.  Avoid OpenSSL magic keywords that change meaning over time (like EXPORT or HIGH). Prefer ECDHE over DHE and perhaps allow RSA for legacy interop.  That gives the following cipher list:
  ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256: \
  ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256: \
  ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA: \
  DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256: \
  DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256: \
  DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA: \
  AES256-SHA:AES128-SHA:
Which is easy to understand and reason about.  And yes, it requires explicit reconfiguration to add new ciphers if and when desired.

Given your oft-stated feelings on protocol flexibility, I am surprised you didn't strongly argue against Camellia.  Or did you just lose that fight?

	/r$

---

From: ianG <[email-masked]>
Date: Tue, 04 Nov 2014 17:12:17 +0000

On 4/11/2014 16:15 pm, Salz, Rich wrote:
> First, I don't think you can blame the TLS WG for adding national ciphers to the protocol.

Yeah, but!  No offense, picking up the devil's advocacy, here, but:

This is exactly the sort of not-my-faultism that created the mess in the
first place.  It's always someone else's problem, someone else's fault.

It's not us, it's the OpenSSL dullards / naive browser fools / criminal
CAs / NSA devils / evil vendors / stupid effing users...

> It's a constant battle, apparently, but SEED GOST CAMELLIA, etc., aren't the TLS group's fault.

WG inherited the SSL system they got, so yes, algorithm vanity was in
there before the group existed.

But, they've shown no desire to remove this system.  Indeed, they've
shown the reverse:  we all know that complexity in general and multiple
algorithms in particular [0] are a crock, yet the WG promotes the
ability to add in more insecurity.

> Once national politics got into it, there's not much the IETF can do.

Where in the IETF charter or the WG charter does it say, "and we pander
to national politics?"

Surely, the role of the IETF security area is to deliver protocols *that
secure the users*.

Correct me if I'm wrong, but surely the role of the IETF is *NOT* to
fall to one or other of the various interest groups that might claim a
special status?

Or is it?  Correct me if I'm wrong?  Who does the IETF serve?  Why am I
here?  Why are you here?

> Second, that cipher suite is, well, gross complicated and confusing.

That is the point:  that's an expert group of users, as good as it gets.
 It's turtles down from there.

>  Also not the TLS WG fault. Blame it on poor use of OpenSSL (and where you then divide that blame isn't clear) if you must.

TLS WG can solve that with a single decision in its next release:

     there is one cipher suite, and it is numbered Number 1.

Can you really shift the blame to OpenSSL and others when the WG walks
blindfolded & backwards in security history and hands them a system that
isn't possible to secure?

> Which is easy to understand and reason about.  And yes, it requires explicit reconfiguration to add new ciphers if and when desired.

I've cc'd the ach group, so they can look at your proposal.

> Given your oft-stated feelings on protocol flexibility, I am surprised you didn't strongly argue against Camellia.  Or did you just lose that fight?

:) I lost that fight, big time.  But rest assured, I won't forget ...

iang

[0] If you disagree that multiple algorithms are the worst possible
idea, then read it this way:

    "other algorithms than my favourite..."

---

From: Yoav Nir <[email-masked]>
Date: Tue, 4 Nov 2014 21:57:50 +0200

> On Nov 4, 2014, at 7:12 PM, ianG <[email-masked]> wrote:
> 

I don’t think it’s a fault at all.

> ability to add in more insecurity.

Complexity is bad, but having a bunch of extra ciphersuites that you are not required to support is not the kind of complexity that causes pain.

> to national politics?”

It’s in the second letter - Engineering. Engineers build things to meet requirements. Russian Internet users are required to use GOST for certain things. A TLS or IPsec that didn’t allow the use of GOST would not meet their requirements. It doesn’t matter what we think about the requirements. Fortunately, it’s fairly easy to not support GOST or Camelia or whatever. .

> Or is it?  Correct me if I'm wrong?  Who does the IETF serve?  Why am I

To make protocols that are useful to all Internet users?

>     there is one cipher suite, and it is numbered Number 1.

There are different needs and different environments. Do you really want the lowest common denominator as the one and only ciphersuite?  You know that it’s going to be defined by the weakest smartobject. 

> isn't possible to secure?

What do you mean “impossible to secure” ? Banks, government agencies, and vendors make trillions of dollars in transactions protected by TLS and IPsec. They lose no money in attacks that have anything to do with breaking the crypto. That is by far the most solid link in the chain of securing both privacy and commerce.

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 04 Nov 2014 21:47:05 +0100

> First, I don't think you can blame the TLS WG for adding national ciphers to the protocol. It's a constant battle, apparently, but SEED GOST CAMELLIA, etc., aren't the TLS group's fault. Once natio…

On the contrary. National ciphers are all we got so far, because crypto
competitions are expensive and only big nations can organize it (AES was
US NIST's competition, Camellia was EU ECRYPT's competition, GOST was
USSR's cipher). Why should they US national ciphers (AES+3DES)
monopolize IETF, and disallow other national ciphers? Having Camellia
defined for TLS was a very good thing.

regards,
Nikos

---

From: Nico Williams <[email-masked]>
Date: Tue, 4 Nov 2014 14:52:00 -0600

The argument about national ciphers seems OT to me.  The IETF does not
keep out non-U.S. ciphers.  The IETF insists on a small
required-to-implement profile.  That's all.

Nico
--

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 04 Nov 2014 22:07:17 +0100

On Tue, 2014-11-04 at 21:47 +0100, Nikos Mavrogiannopoulos wrote:
> US NIST's competition, Camellia was EU ECRYPT's competition,

To correct myself. Camellia was a winner of the EU's Nessie [0]
competition and Japan's cryptrec. Not ECRYPT (thanks to Kenny Paterson
for noticing).

regards,
Nikos

[0]. https://en.wikipedia.org/wiki/NESSIE
[1]. https://en.wikipedia.org/wiki/CRYPTREC

---

From: ianG <[email-masked]>
Date: Wed, 05 Nov 2014 12:34:59 +0000

> I don’t think it’s a fault at all.

I also don't think it helps to "allocate blame."  Far better to think
about what we can do fix the situation.

> Complexity is bad, but having a bunch of extra ciphersuites that you are not required to support is not the kind of complexity that causes pain.

What a browser needs to support and what a server needs to support is
the crux of this argument.  Have a look at that very tight apache config
in prior posts which Rich critiqued, evidence that browsers and servers
*are required to serve those things* even though they have no benefit.

What legitimate benefit is gained from any of them other than the first
(or last)?

Yet, I can faithfully claim that the creation of that BetterCrypto
apache config ran into order of man-months over the last 2 years.

Huh?  Just the string?  That's complexity.  Equals loss.  Just
configuring the string represents utter loss for no benefit to users.

> It’s in the second letter - Engineering. Engineers build things to meet requirements. Russian Internet users are required to use GOST for certain things. A TLS or IPsec that didn’t allow the use of…

The NSA requires backdoors.  GCHQ demand them [0].  So by extension, it
doesn't matter what we think, American and British engineers are
required to insert them into IETF protocols.

Or?

> To make protocols that are useful to all Internet users?

Yes.

> There are different needs and different environments. Do you really want the lowest common denominator as the one and only ciphersuite?  You know that it’s going to be defined by the weakest smarto…

I think the problem here is that nobody's ever been asked to pick one
generally good ciphersuite.

BTW, what are these different needs and environments?  What wouldn't say
chacha20/poly1305 whip, which is the informal, consensual standard of
the day?

> What do you mean “impossible to secure” ?

There are probably a million sysadms out there that install SSL on an
"install, copy a config from a mate, move on" basis.  They probably have
to manage o(100) packages.  They have no time for anything that requires
detailed knowledge and configuration.

As the vast majority of them are likely to make basic mistakes, it is
therefore approximately impossible to secure, in the aggregate.

You might be thinking that "impossible to secure" can be easily shown in
lab conditions to be wrong;  but lab conditions aren't the benchmark.
What the average sysadm does, is.

> Banks, government agencies, and vendors make trillions of dollars in transactions protected by TLS and IPsec.

Nah.  Banks, government agencies, vendors make trillions of dollars by
using transaction systems that are *reversible*.

Bitcoin OTOH moves money without reversibility, and it's currently in
the process of removing openssl, because it's ... impossible to use
securely.  Indeed, it was directly implicated in a lost money situation,
albeit the PRNG not the encryption.

> They lose no money in attacks that have anything to do with breaking the crypto.

Indeed.  But that's because they have easier ways to lose money.
Security is a relative game, the crypto is by far the strongest thing we
have.

> That is by far the most solid link in the chain of securing both privacy and commerce.

Right.  Agreed.  Except, the recent Heartbleed event was by one count a
cost of $500m.  Since 2011, the attack profile has shifted up a notch,
and software is under attack more pervasively.

Which is not to say that any one particular product is bad, but it is to
say that the easy game over the last 2 decades is over.  Every time here
is a big breach, we'll likely find it is because we're using software
that is at least a decade old, probably deprecated and probably with
known bugs in it.

What part does the IETF play in this question?  None, as of right now.
It's still in throw-it-over-the-wall mode.  Time to tear the wall down?

iang

[0] "The web is a terrorist’s command-and-control network of choice"
Robert Hannigan

GCHQ and its sister agencies, MI5 and the Secret Intelligence Service,
cannot tackle these challenges at scale without greater support from the
private sector, including the largest US technology companies which
dominate the web. I understand why they have an uneasy relationship with
governments. They aspire to be neutral conduits of data and to sit
outside or above politics. But increasingly their services not only host
the material of violent extremism or child exploitation, but are the
routes for the facilitation of crime and terrorism. However much they
may dislike it, they have become the command-and-control networks of
choice for terrorists and criminals, who find their services as
transformational as the rest of us. If they are to meet this challenge,
it means coming up with better arrangements for facilitating lawful
investigation by security and law enforcement agencies than we have now.

http://www.ft.com/cms/s/2/c89b6c58-6342-11e4-8a63-00144feabdc0.html