Subject: Re: Security for various IETF services

From: [email-masked] (Noel Chiappa)
Date: Wed, 9 Apr 2014 11:49:19 -0400 (EDT)

> From: Phillip Hallam-Baker <[email-masked]>

    > a security standard must have no impact at all or it won't be used.

While I agree with the conclusion part ("or .. used"), isn't the first part
sort of internally contradictory? Adding security almost always has some
cost, in that people have to set up the security, etc. (I'm thinking in very
broad terms here - e.g one has to lock one's car/house, enter a security code
to use an ATM card, etc, etc.) OK, so HTTPS has basically zero impact on the
average user - is the same level of user inattention really possible with
email security?

But I'm just being nitpicky about a background statement; on your main
point:

    > we currently have a big problem in that the IETF has two email security
    > standards, not one. ... Neither is a success at anything approaching
    > Internet scale.
    > ...
    > the way forward is pretty straightforward: Take the S/MIME message
    > format and graft the PGP web of trust and fingerprint trust models onto
    > it. 

I agree wholly with your prefatory observation, and like your suggested
solution.

	Noel

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 9 Apr 2014 12:37:20 -0400

> average user - is the same level of user inattention really possible with

What I currently have is a prototype that makes sending the email
completely transparent except in the case where I either want to only
send the mail if t can be sent encrypted or only if it can be sent
encrypted under particular security guarantees.

That bit is almost complete, I just need to finish one little bit and
its good to go. It works with the mail client you have right now
without any plug in or extension. The outbound mail is redirected
through a proxy which does all the necessary.

The second part is the configuration model. Right now the situation is
that configuration is a one time operation. But it is far from
painless because I am using the legacy clients and the configuration
model is, well stupid. It requires a lot of user intervention and
understanding.

I have a plan that will make that part easier than configuring a mail
client today. i can't make configuring crypto a zero effort operation
but I can make sure you only need to do it once per device (i.e.
subsequent updates are completely automatic). And I can make the joint
task of configuring the crypto and the mail account settings easier
than one or the other alone.

This is the part that I am coding now. It does have impact on the use
piece however since one of the ways I am simplifying the approach is
to have as much consistency as possible. Rather than deal with a
single key or dual keys for encryption and signature I require
everyone have dual keys. This makes it much easier to do recovery from
user blunders or machine failures.

-- 
Website: http://hallambaker.com/

---

From: Dave Crocker <[email-masked]>
Date: Wed, 09 Apr 2014 12:17:35 -0500

> I agree wholly with your prefatory observation, and like your suggested

The interesting premise in the suggestion is that a web of trust key 
management model is useful at Internet scale.

I don't understand why anyone believes that.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Ted Lemon <[email-masked]>
Date: Wed, 9 Apr 2014 13:31:40 -0400

On Apr 9, 2014, at 1:17 PM, Dave Crocker <[email-masked]> wrote:
> The interesting premise in the suggestion is that a web of trust key management model is useful at Internet scale.

It doesn't actually require a web of trust.   It could work as well (likely better) as a simple whitelisting system with no shared trust at all.

---

From: Theodore Ts'o <[email-masked]>
Date: Wed, 9 Apr 2014 16:08:14 -0400

> I don't understand why anyone believes that.

The problem is that nearly all solutions to the PKI problem I've seen
to date fall into three classes, all of which have problems (which is
why there is the oft-retold joke about how any protocol which requires
a PKI is doomed).

1) The current "race to the bottom" multiple competing CA model, which
while scalable, has had some rather spectacular failures, of which
Diginotar is only one example.

2) Trust the government to run the CA ("I'm from the government, and
I'm here to help!") --- which raises questions of "which government"
and "how do you trust that someone won't invoke 'national security' as
the root password to the Constitution / Fundamental Rights" to abuse
the trust that the government would have it served as the CA?

3) The PGP web of trust model, which doesn't scale to the Internet,
but which is good enough for small communities for which high trust is
extremely important (for example, such as Debian Developers and the
Linux kernel.org keyrings).

I suspect #1 could have gotten traction as far as usage is concerned,
if the pricing model for a given level of security had been attractive
enough and if it had been sufficiently easy for mere mortals to get
x509 user certificates.  But as it is, #3 has been winning out as far
as usage because the people who care enough about security to go do
the extra work are also the folks who (a) don't trust the CA's, and/or
(b) are too cheap to be willing to pay what the CA's want to charge,
and so the PGP web of trust model is quite suited for their needs.

At the end, because the use cases and the requirements for different
communities are quite different, I think the only thing that has a
chance is some kind of hybrid solution.  Because questions of format
aside, the main difference between all of these schemes is who do you
put in your trusted root, and how much cerifying delegation do you
allow?  

If you're the US military and you let the NSA handle all of your key
management needs, that's one answer.  If you're a web browser, you
mark several dozen or several hundred CA's (depending on how you
count), and that's another answer.  If you're a Linux kernel developer
and you want to get an account on kernel.org and be able to sign git
tags, you need to either be directly signed by one of four or five
trusted root individuals, or have 3 signatures by keys that are signed
by the root individuals, and that's yet another answer.

What we really need is widely deployed software which can support all
of these different use cases, and deal with the fact that there is
significant base deployed that will add resistance to switching to a
whole new certificate format.  (For example, x509 certs have a large
amount of infrastructure, but so do PGP --- there are smart card and
Yubikey NEO's that support storage of private keys for PGP and ssh on
hardware tokens.)  And so I might want to use one of PKI policy when
validating e-mail sent by a fellow kernel developer, and use a
different PKI policy if I'm talking to a stranger someone for whom the
only authentication path is via some "race to the bottom" cerifying
authority, and where my trust requirements might be different.

I'll note that I can mostly do that today, because my mail user agent
(mutt) supports both S/MIME and PGP.  So any proposed solution should
ideally be better than what we can do today with that kind of support
(namely, adding both S/MIME and PGP into the mail client).

Cheers,

						- Ted

---

From: Tim Bray <[email-masked]>
Date: Wed, 9 Apr 2014 13:15:00 -0700

While not a solution, I'm thinking the keybase.io work is a step in a
useful direction.  Just a directory of accounts where you can associate a
keypair with verifiable assertions that its holder controls a particular
Twitter/github account and Web server and DNS.

---

From: Steve Crocker <[email-masked]>
Date: Wed, 9 Apr 2014 16:15:53 -0400

My own opinion is related but not identical.  I agree solutions 1 and 3 are failures; 1 doesn’t provide the trust and 3 doesn’t scale.  Solution 2 is also problematic because the government tends to overreach and there isn’t a single government.

DNSSEC provides a base platform to build upon.  It doesn’t claim to provide the level of trust the CA system tried to provide.  That’s a key strength, not a weakness.

Steve

---

From: Dave Cridland <[email-masked]>
Date: Wed, 9 Apr 2014 21:36:15 +0100

On 9 April 2014 21:15, Steve Crocker <[email-masked]> wrote:

> My own opinion is related but not identical.  I agree solutions 1 and 3
> are failures; 1 doesn't provide the trust and 3 doesn't scale.  Solution 2
> is also problematic because the government tends to overreach and there
> isn't a single government.
>
> DNSSEC provides a base platform to build upon.  It doesn't claim to
> provide the level of trust the CA system tried to provide.  That's a key
> strength, not a weakness.
>

DNSSEC, and DANE, allow you to provide a "Domain Validated" public key,
much like the cheap/free certificates currently available from CAs, but
more reliably and simply. I think the same level of trust is there either
way, except that the cheap/free CA certs are very weakly validated in
practise.

CAs can provide actual identity assertions, and in private situations
authorization information.

I suspect that if we can get DANE deployed, we'll see most of the cheap and
somewhat useless CAs vanish, and only those with reasonable tust remaining
survive on fully validated, EV et al, certs, actually, but that's besides
the point.

I wonder if we can't use DANE, S/MIME, WebFinger and a little
sensibly-applied PKI, so that:

1) You could find out assertions of what CA (if any) users of a particular
domain use for end-user client certificates via a TLSA record. Say _users
IN TLSA ...

2) We can use WebFinger to find the certificate itself, and therefore a
possibly signed assertion of actual identity, both WebFinger and this
certificate protected currently by stock PKIX (and in the future, DANE).

I think this gives you essentially everything anyone might want, but for
added bonuses, we could do a web-of-trust thing hanging off WebFinger
(publish any signatures anyone else is prepared to give you) or via public
services.

However, it's probably been suggested before and shot down before, so feel
free to point me to its death notice. :-)

Dave.

---

From: Dave Crocker <[email-masked]>
Date: Thu, 10 Apr 2014 05:47:55 -0500

On 4/9/2014 3:36 PM, Dave Cridland wrote:
> more reliably and simply. I think the same level of trust is there
> either way, except that the cheap/free CA certs are very weakly
> validated in practise.

What deployment and use has DANE achieved, so far?

d/

---

From: Theodore Ts'o <[email-masked]>
Date: Thu, 10 Apr 2014 10:14:06 -0400

On Wed, Apr 09, 2014 at 04:15:53PM -0400, Steve Crocker wrote:
> My own opinion is related but not identical.  I agree solutions 1
> and 3 are failures; 1 doesn’t provide the trust and 3 doesn’t scale.
> Solution 2 is also problematic because the government tends to
> overreach and there isn’t a single government.
> 
> DNSSEC provides a base platform to build upon.  It doesn’t claim to
> provide the level of trust the CA system tried to provide.  That’s a
> key strength, not a weakness.

DNSSEC basically has the same properties as the "race to the bottom
certifying authorities" model, except it's a "race to the bottom of
the DNS registraries" --- and some cases, the same company runs both a
CA and a DNS registry.  "Meet the new boss, same as the old boss"....

So if you're willing to disclaim the amount of trust that the CA
system purports to provide, it's really a question of "IPSEC" vs "TLS"
--- i.e., at which layer of the stack you are applying the protection.

Cheers,

					- Ted

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 10 Apr 2014 10:35:27 -0400

> I don't understand why anyone believes that.

Perhaps they believe that I have the solution because they actually
read my proposal where I suggest something very different and back it
with like actual math and an attack model.

The actual code is designed in such a way that people can plug in any
trust model of their choice however.

https://datatracker.ietf.org/doc/draft-hallambaker-prismproof-trust/
http://www.youtube.com/watch?v=PBFnBpWkK8M

There are problems with both the S/MIME and the Web of Trust models
which I discuss in the video presentation.

What I am proposing is to combine features of both trust models and in
addition ground the system in time using Certificate Transparency.
What this means is that a given key can be accredited in both models
simultaneously.

The metric that I apply is the time based work factor for the
attacker. Timestamping documents against an append only notary that is
a member of a federation of such notaries can effectively raise the
work factor for the attacker to infinity after that point in time.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 10 Apr 2014 10:38:58 -0400

> which I discuss in the video presentation.

Are these documented in the draft?   Because I'm not going to watch the video.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 10 Apr 2014 10:57:13 -0400

> DNSSEC provides a base platform to build upon.  It doesn’t claim to provide the level of trust the CA system tried to provide.  That’s a key strength, not a weakness.

I agree as long as you continue to use the indefinite article. DNSSEC
is A platform to build on, so is PGP and so is S/MIME. There is
actually a considerable built out base of S/MIME that is just as large
as PGP and in fact gets a lot more use.

On Monday I was in a room where over half the audience put their hand
up when I asked it they had used encrypted mail that week.

The way forward as I see it is to separate out the trust model
question from the steps necessary to support encryption in the client.
At the very least for development purposes. My prototype is designed
to allow anyone to plug their favorite trust model in as a web
service. So we can share 95% of the code that is the hardest to write
and has to be supported on every platform. We only need to implement
the 5% where the difference lies.

Given this week's Heartbleed news, I think we can stop hearing
conclusions drawn from DigiNotar. No crypto is ever going to be
perfect, get over it. If people want to hold CAs up to a 'zero
tolerance' standard, thats fine. Just make sure you hold OpenSSL up to
the same standard and pull them from the code base as well. And kick
anyone who might have been implicated in an NSA plot out of the IETF.
And stop using all their specs. And.. and., and..

The problem with the CA model for email is that as a CA it is really
difficult for me to actually validate individuals. The best I can do
is to check their government issued ID. Which really does not help me
in a country like Iran. The CA model does give me a lot of leverage if
I am looking to authenticate an institution however.

Web of trust has a scaling problem that I illustrate in the video.
Basically a web of trust with 1000 members that is ten hops away from
me has a work factor of essentially zero as I have no way to tell if
it is genuine or fake. But the curious thing is that if we combine the
two models, the work factor for the attacker increases over the CA
model alone and we get scaling. If there are 50 members of that web of
trust with CA validated certificates with a work factor of X, the web
of trust might have an average work factor approaching 20-30X for a
given cert.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 10 Apr 2014 11:00:49 -0400

> Are these documented in the draft?   Because I'm not going to watch the video.

The draft does discuss them but the draft was written 3 months before
the video and my thinking has developed since I started writing code.

I don't plan to update the draft again till the code is finished. At
that point I plan to release a new set of drafts and a video showing
how to use the actual code.

---

From: Sam Hartman <[email-masked]>
Date: Wed, 09 Apr 2014 13:50:54 -0400

>>>>> "Dave" == Dave Crocker <[email-masked]> writes:

I have no idea how we got from security for ietf.org services to this.
I hope we're not going to pilot Phil's e-mail trust model in the IETF,
even though I think his work has significant value.

    Dave> The interesting premise in the suggestion is that a web of
    Dave> trust key management model is useful at Internet scale.

    Dave> I don't understand why anyone believes that.

I'm not sure that's actually an implied premise.

I guess bulk mailers do need to communicate with people at Internet
scale.

The rest of us not so much though.
Yes, I can communicate with anyone on the Internet.
However, the set of people that I communicate with is smaller than
that.  The set of people for whom I need trusted communication is even
smaller.

>From my experience in the open-source and product-security communities
(some of the larger web of trust users), web-of-trust tends to work well
when people are communicating with a small enough set of people that
they can make individual authorization decisions but where that set is
drawn from a large enough infrastructure that shared key management is
valuable.

We're seeing something similar as we're putting together the Moonshot
deployment of ABFAB federation.  There's value in some environments  in
having a large trust infrastructure from which I actually trust only
some principals.

I think that the same is likely true for some uses of secure e-mail.

---

From: Dave Cridland <[email-masked]>
Date: Thu, 10 Apr 2014 16:37:26 +0100

> What deployment and use has DANE achieved, so far?
Like all new security technology it's slow going. In the DANE case, we're
obviously limited by the deployment of DNSSEC itself as well.

Within the XMPP community, which is really the only place I'm able to
track, https://xmpp.net/stats.php will give you the live information, but
to save you looking, the percentages are still pretty low. 83 sites out of
3283, so about 2.5%, support DANE. 6.3% deploy DNSSEC signed SRV records.
We have, on those servers tested, 100% TLS deployment, but only about 49.4%
of those use trusted certificates (there's a lot of CACert.org which are
considered untrusted here).

Given that DANE itself is not yet fully specified for XMPP, and is less
than two years old, I think this is reasonable traction.

These stats are gathered and maintained by Thijs Alkemade's excellent
software, by the way, I don't mean to take any credit for this. I just read
'em.

Dave.

---

From: Dave Cridland <[email-masked]>
Date: Thu, 10 Apr 2014 22:34:47 +0100

On 10 April 2014 16:37, Dave Cridland <[email-masked]> wrote:

> track, https://xmpp.net/stats.php will
>

not, because I'm an idiot who didn't check the URI he typed, but
https://xmpp.net/reports.php will

> give you the live information, but to save you looking, the percentages
> are still pretty low. 83 sites out of 3283, so about 2.5%, support DANE.
> 6.3% deploy DNSSEC signed SRV records. We have, on those servers tested,
> 100% TLS deployment, but only about 49.4% of those use trusted certificates
> (there's a lot of CACert.org which are considered untrusted here).
>

---

From: Mark Andrews <[email-masked]>
Date: Fri, 11 Apr 2014 10:32:31 +1000

> CA and a DNS registry.  "Meet the new boss, same as the old boss"....

No quite the same.  A CA could issue a cert without any checking
for any domain.  Here you need to be the registrar of record to add
records to the registry.  Also a registry can only add records for
the namespace it manages not any arbitary name.

So to get a bad DS added you need to be a corrupt registry or a
corrupt employee of registry or you need to compromise the registrants
credentials or you need to succeed in transfering the zone to you.

The registry can provide some protection for some of these threats.

This is a smaller attack surface than the plain CA attack surface.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Theodore Ts'o <[email-masked]>
Date: Thu, 10 Apr 2014 20:57:12 -0400

> credentials or you need to succeed in transfering the zone to you.

Or you have to be the corrupt registry operator or an employee for the
registry operator (i.e., Verisign for the .com domain)....

    	 	       		    	- Ted

---

From: Jelte Jansen <[email-masked]>
Date: Fri, 11 Apr 2014 10:06:01 +0200

> registry operator (i.e., Verisign for the .com domain)....

But at least you have the option to switch away from the corrupt
registry operator. An expensive option, since it would involve changing
your domain names, but an option you don't have with x509 (well, you can
switch, but that doesn't protect you, which was the point). Far from
perfect, but for that specific problem much better than the current x509
model.

Jelte

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Apr 2014 09:57:47 -0400

Ted,

The fact that, within the DNS each CA-like entity is syntactically 
constrained,
is very important. It addresses the fundamental flaw of the Web PKI, 
that was
illustrated by the DigiNotar debacle.

Steve