Subject: Re: [perpass] Few things the IETF might standardize for secure collaboration

From: Dan York <[email-masked]>
Date: Tue, 5 Nov 2013 00:00:58 +0000

Cullen,

Inline...  (and finally getting caught up on past conversations)

On 10/24/13 12:23 AM, "Cullen Jennings" <[email-masked]> wrote:

>No question that things are going the right direction. Let figure out how
>we could use this and likely when. In fairness it will take time to build
>something like I am proposing and DNSSEC will be better then than it is
>now.

Ack.

> 
>Using DANE for belt and suspenders on CAs seems good. I also think it
>would be well worth think about who is in the trust chain for a domain
>that was in .us vs say .cn and consider how that might all play out from
>security point of view. I had not thought much about this but it does
>deserve thinking about what we can do.

Agreed that it's worth thinking about how the trust chain may be different
for different TLDs.

>> 
>> Typo: slide 8 - I think you meant "in that you" - "The CA is "honest" is
>> that you can tell if it issues your certiﬁcate to someone else but there
>> is no way to stop it from doing that"
>
>oops - yes - The type of thing I was thinking about here are various
>proposal where CA publish all the certificates they have issued and there
>are various cryptographic hash chains that make it difficult for them to
>lie about this. That means a CA might be able to issue your cert to a bad
>guy but that it would later be possible to detect that.

But I want to detect the bad cert *before* someone goes to a site (or in
the process of going to a site).  I agree that this capability of tracking
issued certs would be VERY useful in detection of compromised certs... but
this doesn't necessarily seem to me something that can work in real-time.
It can be something used to figure out what happened after-the-fact... but
in the meantime someone has already gone to to the bad site that they
thought was legit.

The advantage of DNSSEC/DANE is that the bogus cert can be detected before
someone actually goes to the site.  If the fingerprint of the cert stored
in the TLSA record (and signed with DNSSEC) doesn't match the fingerprint
of the cert being offered by the server... then the app knows there is a
problem.

>>>Near the end is a list of things that it would be helpful if the IETF
>>> standardized.
>> 
>> Good list!
>
>Tell me what to add to this list for DNSSEC / DANE that we are not
>already doing

For DANE, I think we're doing pretty well right now with what is defined
in RFC 6698 and some of the other drafts.  There's a good document out in
the DANE working group that is aiming to capture operational experience of
using DANE:

http://tools.ietf.org/html/draft-dukhovni-dane-ops-01

I'd note that this document initially came about in the process of one of
the authors adding DANE support to the postfix email server. (And the
authors are seeking comment from other implementors.)

On the DNSSEC side, again I think DNSSEC is well-defined in terms of
standards... what is happening now, primarily in DNSOP, is looking at how
we standardize and automate some aspects of the DNSSEC provisioning
process.  (For example, tomorrow's DNSOP discussion around mechanisms to
facilitate communication of new key material from a child zone to a parent
zone.)  

So I guess what we need to add to your list for DNSSEC / DANE is really
documenting (and potentially standardizing in some cases)
operational/deployment experience of what needs to be done to get the
protocols in use.

Dan

--
Dan York
Senior Content Strategist, Internet Society
[email-masked] <mailto:[email-masked]>   +1-802-735-1624
Jabber: [email-masked] <mailto:[email-masked]>
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/deploy360/

---

From: Ben Laurie <[email-masked]>
Date: Wed, 6 Nov 2013 16:05:20 +0000

> of the cert being offered by the server... then the app knows there is a

However. there are several real-world downsides. Most glaring:

1. In quite a lot of cases (experiments suggest around 4%), clients
cannot fetch DNSSEC records (nor TLSA records).

2. DNSSEC has its equivalent of CAs: registries and registrars. Their
track records on misissuance are not better than CAs.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 06 Nov 2013 12:06:40 -0500

Ben,
> track records on misissuance are not better than CAs.
I don't argue with your first point, but I expect this problem to diminish
over time

The second statement, though, is not a reasonable comparison. registrars 
operate
with the equivalent of name constraints, from a cert issuance 
perspective, which
makes it much better that the WebPKI TA model. Even if the TAs in that 
model were
to issue certs including a name constraints extension, the effect would
not be as good as what we have in the DNSSEC/DANE environment.

Steve

---

From: Ben Laurie <[email-masked]>
Date: Wed, 6 Nov 2013 17:32:31 +0000

> I don't argue with your first point, but I expect this problem to diminish

So do I.

> with the equivalent of name constraints, from a cert issuance perspective,
> which
> makes it much better that the WebPKI TA model. Even if the TAs in that model
> were

I accept that _registries_ are name constrained. Registrars less so.

Not sure I get why this is better than name constrained certificate chains, tho?

---

From: Nicholas Weaver <[email-masked]>
Date: Wed, 6 Nov 2013 09:35:33 -0800

> Not sure I get why this is better than name constrained certificate chains, tho?

You are assuming that the protocol is a "single name -> data"

If you use DNSSEC in the context of "{multiple names} -> same data", you can now require that the attacker either attack multiple chains or that the multiple chains collude.

Thus, eg, you only need to assume that BOTH mydomain.com and mydomain.ru are not compromised by the same attacker.

--
Nicholas Weaver                  it is a tale, told by an idiot,
[email-masked]                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc

---

From: Ben Laurie <[email-masked]>
Date: Wed, 6 Nov 2013 17:54:16 +0000

> You are assuming that the protocol is a "single name -> data"

That is the protocol.

> Thus, eg, you only need to assume that BOTH mydomain.com and mydomain.ru are not compromised by the same attacker.

Sure, I agree you can invent new protocols with different security
properties. I have several of my own :-)

---

From: Stephen Kent <[email-masked]>
Date: Wed, 06 Nov 2013 12:56:37 -0500

> I accept that _registries_ are name constrained. Registrars less so.
yes, I was sloppy in my terminology.
> Not sure I get why this is better than name constrained certificate chains, tho?
because the constrained chains begin somewhere below the TA, which 
leaves EVERY
TA free to create ANY subordinate CA.  Also, ccTLDs represent the sort of
sovereign alignment to a PKI that many folks find attractive.

Steve

---

From: Carl Wallace <[email-masked]>
Date: Wed, 06 Nov 2013 10:01:26 -0800

On 11/6/13 9:56 AM, "Stephen Kent" <[email-masked]> wrote:

>>>perspective,
>>>model

TAs can be constrained (at least in theory).  The specs are there - just
no widely used implementation.  There is no good reason to stick with the
unconstrained TA model we've been using, though name constraints at
internet scale are hard to define.

---

From: Ben Laurie <[email-masked]>
Date: Wed, 6 Nov 2013 18:16:01 +0000

On 6 November 2013 17:56, Stephen Kent <[email-masked]> wrote:
> because the constrained chains begin somewhere below the TA, which leaves
> EVERY

For exactly the reason many find it unattractive :-)

---

From: Stephen Kent <[email-masked]>
Date: Wed, 06 Nov 2013 13:32:45 -0500

Carl,

>> ..

Many of the WebPKI TAs are revenue producing entities, and this they have no desire
to be constrained in the range of names they can insert into the certs they issue.

Of course one can imagine other TA models, which is why DANE is, IMHO, a great
alternative.

Steve

---

From: Stephen Kent <[email-masked]>
Date: Wed, 06 Nov 2013 13:37:40 -0500

Ben,
> For exactly the reason many find it unattractive :-)
I am not a fan of viewing the Internet as an extra-national entity.
Maybe that makes me a heretic WRT Google's idea of cyberspace and 
reality ;-) .

Countries have a right to manage a lot of things within their borders,
and managing their DNS name spaces seems quite reasonable.

Steve

---

From: George Michaelson <[email-masked]>
Date: Wed, 6 Nov 2013 10:41:05 -0800

the useful thing about what Steve said, is that its the convergence of
desire and reality. Well, 'desire' might be a stretch, but I think he
recognizes national laws as a concrete reality we can't pretend doesn't
exist.

there is a forcing function in reality here, which I find compelling.

btw: I actually like ideas I pick up from 'sunlight on certs' anyway,
irrespective of DANE or DNSSEC based things. I see no reason not to have
more community consciousness of what TA are seen to be good actors and are
understood. and more light shining on bad actors.

On Wed, Nov 6, 2013 at 10:37 AM, Stephen Kent <[email-masked]> wrote:

> Maybe that makes me a heretic WRT Google's idea of cyberspace and reality
> ;-) .
>
> _______________________________________________
> perpass mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/perpass
>

---

From: Ben Laurie <[email-masked]>
Date: Tue, 12 Nov 2013 15:21:21 +0000

> and managing their DNS name spaces seems quite reasonable.

Sure. But we were talking about key management.

---

From: Stephen Kent <[email-masked]>
Date: Tue, 12 Nov 2013 13:45:03 -0500

Ben,

> Sure. But we were talking about key management.
My text talks about ccTLDs, irrespective of what types of records are 
stored in
the DNS.

Steve