Subject: IESG meeting thoughts

From: IETF Chair <[email-masked]>
Date: Mon, 16 May 2016 18:59:01 -0400

I wanted to share some of my thoughts from a retreat we had with the IESG last week. This time our meeting discussed topics around IETF and Bluetooth collaboration, Internet privacy, IETF working group charters, the RFC series, area director job descriptions, mentoring, and many others.

Here is the article:

  https://www.ietf.org/blog/2016/05/iesg-retreat-2/

Jari Arkko, IETF Chair

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 17 May 2016 11:41:57 +0200

Jari, would you have some more info (maybe popinters) about

     The IESG also got an update on “Cryptowars” situation from Jeff Schiller.

When I look up "cryptowars" on google, I get many many hits on a wide
variety of "cryptowars". So I'd like to know which specific ones
were discussed or cause us specific worries.

Thanks,
Bert

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 May 2016 10:57:14 +0100

Hi Bert,

> were discussed or cause us specific worries.

No pointers to the talk, sorry - Jeff was kind enough to speak without
notes or slides, (which was great:-). He recounted the 1990's era
history of crypto export controls, the issues covered in their "keys
under doormats" report, [1] and some consideration of more recent
events such as the USG/Apple case and how similar issues might play
out in future. (My own not at all startling prediction: ongoing
tensions between law enforcement and all of us working to improve
security and privacy are sort of inevitable it seems.)

From my POV this was a great way to bring ADs who don't follow
the minutiae up to speed on these topics, but didn't set out any
particularly new direction for work in the IETF.

(Thanks go to Jeff for the talk and to Kathleen who organised it.)

Cheers,
S.

[1] http://115.69.40.134/files/editorials/files/MIT-CSAIL-TR-2015-026.pdf

>> I wanted to share some of my thoughts from a retreat we had with the
>> IESG last week. This time our meeting discussed topics around IETF and
>> Bluetooth collaboration, Internet privacy, IETF working group
>> charters, the RFC series, area director job descriptions, mentoring,
>> and many others.
>>
>> Here is the article:
>>

---

From: Randy Bush <[email-masked]>
Date: Tue, 17 May 2016 12:12:07 +0200

> issues covered in their "keys under doormats" report, [1]
> 

strongly recommended

randy

---

From: "Bert Wijnen (IETF)" <[email-masked]>
Date: Tue, 17 May 2016 13:59:05 +0200

thanks

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 17 May 2016 09:44:22 -0400

> [1] http://115.69.40.134/files/editorials/files/MIT-CSAIL-TR-2015-026.pdf

One thing we did in the 1990s which I now regret as a mistake was that we
ended up developing security protocols where the first priority was to
defeat government intercept rather than meet users needs.

Unlawful intercept is of course a very serious problem but it is not the
only problem our users face nor is it the necessarily the most serious
concern. Nor for that matter is targeted unlawful intercept the same
problem as mass surveillance.

One consequence of treating Louis Freeh's FBI as the principal threat was
that we ended up with a lot of security protocols that were perfectly
secure but almost nobody deployed and even fewer used. end to end security
is only good security when people use it.

Right now I am working on technology that makes end-to-end security
practical and usable. Using off the shelf mail applications with the
Mathematical Mesh is actually easier than using them without. But there are
some features I have added to meet real end user needs that we would never
have considered in the 1990s. In particular a key backup and recovery
option that is turned on by default.

Why do real users need key recovery? Well without the ability to recover a
lost key, a protocol that encrypts stored data becomes worse than
ransomware. There isn't even the option of paying a criminal to get your
data back.

Another mistake we made was to consider end to end security to be the
be-all and end-all of security. I like end to end security. The Mesh is
designed as an untrusted cloud precisely because I consider end-to-end
security important. The Mesh cannot be breached because none of the data
stored in the Mesh is confidential. The only places confidential data is
not encrypted is at the endpoints.

But end to end security has serious costs. You can't have end to end
security without a key infrastructure. And until the Mesh there hasn't
really been a key infrastructure that was designed for use by non-expert
users. And end to end security isn't the 'best' security, it is only one
form of security. End to end doesn't provide protection against metadata or
traffic analysis. The Mesh has end-to-end and transport layer security. The
most critical operations even have a third layer of encryption. And I can
give a security rationale for each.

Another critical security technology that we managed to allow ourselves to
be persuaded was 'evil' is trustworthy computing. As a result the WebPKI
and code signing infrastructures use private keys that are stored on the
machine itself, in many cases in plaintext but with security through
obscurity at best. But we have the technology that would allow us to bind
those private keys to servers in such a way that they can be used but not
extracted without physical access to the machine itself and a significant
degree of technical effort.

So lets make sure we don't make the same mistake this time round. Transport
layer security and key escrow have security liabilities as well as
benefits. Trustworthy computing is a tool that we can and should be using
to make our users secure.

What is popular and commonly agreed in computing isn't always the right
thing. Security is allowing our users to control risk, not defeating the
political objectives of Louis Freeh or the RIAA.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 17 May 2016 11:11:31 -0400

> under doormats" report, [1] and some consideration of more recent

yes, It's important to remember that not everyone lived through that period
of time.

A TED talk or something about that history might be neat to have to help
socialize millenials about not repeating history.

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 17 May 2016 12:58:57 -0400

Phillip Hallam-Baker <[email-masked]> wrote:
    > Right now I am working on technology that makes end-to-end security practical
    > and usable.

This is awesome; I'm hoping that microsoft, apple and google will pay
attention and collaborate.  In the 1990s, I think that one reason we wound up
where we did was because the work was being done by academics and later by
dot-com startups.  Who has the resources to collaborate with you?

    > Using off the shelf mail applications with the Mathematical Mesh
    > is actually easier than using them without. But there are some features I
    > have added to meet real end user needs that we would never have considered in
    > the 1990s. In particular a key backup and recovery option that is turned on
    > by default.

    > lost key, a protocol that encrypts stored data becomes worse than ransomware.
    > There isn't even the option of paying a criminal to get your data back.

That's very true.
I have been wondering, in the context of Apple's improvement to device
security, how the untimely death of a person will be dealt with.

    > Another critical security technology that we managed to allow ourselves to be
    > persuaded was 'evil' is trustworthy computing. As a result the WebPKI

It wasn't trustworthy, because they refused peer review.
We couldn't even get Intel to reveal pre-whitened random numbers!
(correct me they ever fixed that...)

    > code signing infrastructures use private keys that are stored on the machine
    > itself, in many cases in plaintext but with security through obscurity at
    > best. But we have the technology that would allow us to bind those private
    > keys to servers in such a way that they can be used but not extracted without
    > physical access to the machine itself and a significant degree of technical
    > effort.

The cryptech.is effort needs more resources I think.

    > political objectives of Louis Freeh or the RIAA.

Agreed.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 17 May 2016 13:10:54 -0400

On Tue, May 17, 2016 at 12:58 PM, Michael Richardson <[email-masked]>
wrote:

> practical

Right now the problem seems to be that everyone wants to play to be the
only king of the castle like they did with instant messaging when it was
the hot thing.

A personal PKI isn't going to give people personal autonomy and freedom if
it binds them to only one provider with purposefully high switching costs.
Nor is it going to have an effective network effect if you can only
communicate with people in the same network as you.

I am busy working on reference code and specs. I should have a significant
system to show in Berlin. It is all open source, MIT license and on GitHub,

> ransomware.

These are serious problems that have to be planned for. Right now I have
code to do Shamir keysharing to escrow the long term escrow keys. But if
people want to use this as a life long personal security infrastructure,
they need to be able to identify some papers as being so personal that they
die with them and others that become public on their death. For example
where I buried Aunt Agatha's jewelry is something I want to make public.
Where I buried Aunt Agatha, is not.

> (correct me they ever fixed that...)

Well, see my recent work on multi-party key generation. When we make the
move to DH based crypto puzzles with Elliptic Curve and beyond, I have
schemes that allow you to make use of the security hardening properties of
onboard crypto without revealing all of the private key to that system.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 18 May 2016 10:15:46 +1200

> socialize millenials about not repeating history.

Well, it seems to me that it's the NSA and their friends in the US Congress,
and equivalent forces in other countries, that are trying to repeat history.

On the other hand, we shouldn't fall over our own feet in our enthusiasm.
As Kamp says, "More Encryption Means Less Privacy":
http://dl.acm.org/ft_gateway.cfm?id=2904894&ftid=1700648&dwn=1

And as Gutmann says, "Crypto Won't Save You Either":
http://www.cs.auckland.ac.nz/~pgut001/pubs/crypto_wont_help.pdf

    Brian

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 17 May 2016 23:57:52 +0100

Hiya,

> On the other hand, we shouldn't fall over our own feet in our enthusiasm.

Sure. However, I think this community have in fact been
quite properly active but also very responsible in what we've
done in the last 3 or so years since the latest iteration
of all this kicked off. That is a little boring of course
but we're (lots of us) doing the right things IMO in carefully
trying to find the places where we can enable real improvements
to be made by implementers and those deploying stuff.

> http://www.cs.auckland.ac.nz/~pgut001/pubs/crypto_wont_help.pdf

Well, I'm not sure if anyone has ever wondered if either PHK or
Peter might ever have possibly overegged an argument just a tad:-)
Both do do very good work of course, as well, but I think the
content at both URLs are good examples of focusing too much on
the (real) negative aspects of what is an overall positive.

If we (the IETF) can provide RFCs that implementers and people
deploying consider can partly mitigate pervasive monitoring then
use of those same tools will also likely be very effective against
less capable attackers, of whom there are very many.

Personally I totally buy the argument in RFC7435 [1]- let's do the
best we can now, (which isn't necessarily at all easy) and then
iterate and improve that over time. I hope that's one of the high
level longer term take-aways from Snowdonia anyway.

Cheers,
S.

[1] https://tools.ietf.org/html/rfc7435

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 17 May 2016 20:04:17 -0400

Responding to Stephen.

Crypto doesn't actually solve any of your security problems. Not one,
zilch, zero.

What cryptography does is to reduce the size of your information security
problem. It can reduce it in size from megabytes or even terrabytes to a
128 bit key or deciding whether or not to trust one of millions of Web
sites to whether or not to trust the 50 WebPKI CAs (or ICANN if you are
feeling really brave). But that is all cryptography does for you. It
reduces the size of your security problem.

You still have to work out how to keep that key secure or make sure you
have the right trust anchor. Reducing problems in size is good but you
still have to solve them.

---

From: Nico Williams <[email-masked]>
Date: Thu, 19 May 2016 23:14:01 -0500

> still have to solve them.

Yes, indeed.  However, you can make HW that protects a small secret like
that really well, and that's what the dust up between the FBI and Apple
was about.  It turns out that Apple can make that HW even better, and
they even might.  The better that piece of hardware, the more expensive
to defeat it, the less likely it is that it will be defeated by
criminals -- and tyrants, but also legitimate state actors; HW and SW
doesn't know the difference.

Now, of course *convenience* is the achilles heel of any plan to secure
even a small secret.  Thus we see courts demanding that people unlock
their mobile devices (and why should this surprise anyone?  there's
nothing special about crypto in this regard).

But dead people don't care about convenience, which is how one murderous
terrorist bastard managed to single-handedly greatly increase the tempo
of the current crypto war.  One wonders whether that was their plan!

The important thing is to provide a clear and correct understanding of
the issues to the bureaucrats and politicians, and also of the
trade-offs implied by any proposed policy.  And the public too (but
that's much harder).

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 20 May 2016 12:04:14 -0400

> doesn't know the difference.

The point I am driving at is that security is a property of the system and
the role of cryptography is to reduce the system to manageable size so that
the problem becomes solvable.

I think that during the cryptowars a lot of us, myself included got way to
invested in crypto and failed to see the broader picture. We also got
rather too invested in public key over symmetric. Yes, public key is cool
but it doesn't reduce the role of symmetric to being a mere support
infrastructure like we suggested in the 90s.

> nothing special about crypto in this regard).

And I think Apple's approach is broken because they failed to put the
device beyond their power in the first place.

I am not going to pledge to go to jail rather than release the keys that
unlock the Mathematical Mesh. Nor am I going to pledge not to release the
keys if someone puts a gun to my head or my children's head.

Therefore to make the Mesh secure, I have to put it beyond my capability to
compromise it. That is the approach Apple should have taken.

What that leaves of course is the possibility of a backdoor built into the
hardware or the algorithms. A choice of DH modulus that has been cracked,
an RNG that is broken. But those types of backdoor would greatly compromise
everyone's national security, including the US. 99% of the civil service
would end up using the compromised devices which are made in China anyhow,

That said, see the techniques I demonstrated for hardening key generation.

> of the current crypto war.  One wonders whether that was their plan!

I doubt it. They physically destroyed all the phones that they might have
used in their attack.

The 1990s cryptowar was led by the NSA. I have recently spoken to people
who are in the very top ranks of that organization and I really do not
think they are leading the effort this time. What worries them today is
that they are losing the defensive side of cyber-engagement. Whatever
happens, US cyber command is never going to disable or destroy an ISIS
nuclear power plant because they haven't got any. We have hundreds and they
are all connected to the net in multiple ways in spite of all the airgap
requirements.

> trade-offs implied by any proposed policy.  And the public too (but

Well my contribution there is that I will shortly be giving a course
'Cryptography for Everyone'. It looks like the live course is
oversubscribed but the material will be on the Web as a series of free
podcasts.

First thing is to set the baseline for what cryptography is about. Yes we
all learn C.I.A. stands for Confidentiality, Integrity and something
starting with A.

But currently it takes us a decade of experience in the field to understand
that security is really all about integrity, not confidentiality and then
another decade to realize that it is availability.