Subject: [dane] Calling the naming issue...

From: Warren Kumari <[email-masked]>
Date: Tue, 10 Dec 2013 10:37:50 -0500

Dear DANE WG,

We (the chairs) have met and discussed this issue with our AD (CCed).

We still see there being consensus for the document itself, and have seen a number of cases and discussions where more memorable names for the ordinals would have been useful (the at mic discussions in Berlin spring to mind).

So, we are forging ahead with what is in the document (James’ suggestions — PKIX-TA, DANE-TA, PKIX-EE, DANE-EE) and will be forwarding this to our AD.

We understand that these names are not perfect and do not please everyone. Despite that, there is sufficient value in the document and we believe it will aid discussion and (hopefully) deployment. This will also allow us to move on and discuss things of more substance.

If you are still concerned that this document might cause the sky to fall, mail the list, and our AD will review when doing the AD review. There is also IETF LC, so we have another chance to discuss this, this time in a more public setting… :-P

W
--
It is a mistake to think you can solve any major problem just with potatoes. --Douglas Adams

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 10 Dec 2013 19:42:14 +0000

On Tue, Dec 10, 2013 at 10:37:50AM -0500, Warren Kumari wrote:

> We understand that these names are not perfect and do not please
> everyone. Despite that, there is sufficient value in the document
> and we believe it will aid discussion and (hopefully) deployment.
> This will also allow us to move on and discuss things of more
> substance.
> 
> If you are still concerned that this document might cause the
> sky to fall, mail the list, and our AD will review when doing the
> AD review. There is also IETF LC, so we have another chance to
> discuss this, this time in a more public setting? :-P

So long as server operators understand that PKIX-TA is not a TA,
and DANE-TA actually employs PKIX, and are not mislead into publishing
incorrect records, all is well.  The names could equally well be
"Chico, Harpo, Groucho and Zeppo".

I also hope that future implementors will have read the standard
thoroughly and will have thought carefully about how to validate
each of the four usages and will not be misled by the acronyms'
false dichotomy.

This said, the names are reasonably memorable, so I guess we can
hope that their use will promote ease of discussion without creating
confusion.  I am too steeped in the details now to know whether I
would have been confused initially.

-- 
	Viktor.

---

From: Richard Barnes <[email-masked]>
Date: Tue, 10 Dec 2013 16:13:12 -0500

I'm a little confused, since I see a message from Warren on 6 Dec saying
that the call would be extended until tomorrow.  I admit that I have not
been following this discussion closely, though.

In case the window for comments / proposals is still open, my only insight
here is that usages 0/1 are very much like the "pinning" work being done in
draft-ietf-websec-key-pinning, so it might be helpful to re-use that term
here.  For 2/3, it seems like people I've talked to understand the verbs
"assert" (since that's what the domain holder is doing) or "trust" (since
that's what the recipient is being asked to do).

        0 - PIN-CA
        1 - PIN-EE
        2 - ASSERT-CA or TRUST-CA
        3 - ASSERT-EE or TRUST-EE

So that's my favorite color for the bike shed.

--Richard

On Tue, Dec 10, 2013 at 2:42 PM, Viktor Dukhovni
<[email-masked]>wrote:

> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

---

From: Guido Witmond <[email-masked]>
Date: Tue, 10 Dec 2013 23:10:29 +0100

On 12/10/13 22:13, Richard Barnes wrote:
> In case the window for comments / proposals is still open, my only
> insight here is that usages 0/1 are very much like the "pinning" work
> being done in draft-ietf-websec-key-pinning, so it might be helpful to
> re-use that term here.  For 2/3, it seems like people I've talked to
> understand the verbs "assert" (since that's what the domain holder is
> doing) or "trust" (since that's what the recipient is being asked to do).
> 
>         0 - PIN-CA
>         1 - PIN-EE

To add my own color:

DANE can only specify *intent*. Intent of the domain owner what they
choose for their certificate source.

Without *verification* that intent is worthless.

1. The owner of the domain must regularly validate that their chosen
DNS-registrar still publishes the owners' intent, preferably with
something like Perspectives that registers and remembers historic
measurements.

2. People doing a lookup for the current value of TLSA records should
validate these against the Perspectives history. When it matches, it's
OK. When there is a mismatch, there is a problem. The only solution for
the resolver is to fail fast and for the user to twitter about it. Make
it public and let the community resolve the problem. It could be lousy
DNS-registrar, the domain owner looks for a better one. It could be a
MitM-device, the end user learns of its existence.

In short, without *verification* DANE doesn't do so much. With
verification, it's a big leap ahead. CT protects in the 0/1 cases,
Perspectives in the 2/3 cases.

IMHO, the naming should reflect the source of the certificate:
0: Global trusted CA;
1: End certificate in a chain from a Global trusted CA;
2: My own CA;  ( from the perspective of the domain owner)
3: My own Certificate; (same perspective)

Cheers, Guido.

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 10 Dec 2013 22:58:39 +0000

> choose for their certificate source.

The intent of the holder of the current zone signing key.

> Without *verification* that intent is worthless.

The intent is conveniently verified by an RRSIG generated by the
zone signing public key.

Arguing against the DANE security model has no bearing on the acronyms.

> IMHO, the naming should reflect the source of the certificate:

Except that the record value is not a global trusted CA.  Rather
its value is a CA constraint on the chain from some trusted CA
requiring the presence of some intermediate at or below such a CA.

The record should be named after what is specifies, which is a CA
required in your chain, not a trusted root.  This was my objection
to the change from PKIX-CA to PKIX-TA.  The change from PKIX-CA to
PKIX-TA is still wrong (even if I am willing to let it slide), as
it will perpetuate confusion by many people who don't understand
usage 0 or usage 2, but think they do.

> 1: End certificate in a chain from a Global trusted CA;

Sure.  But I don't see an ancronym here...

> 2: My own CA;  ( from the perspective of the domain owner)

Your own trust-anchor.

> 3: My own Certificate; (same perspective)

Still no actual acronym.

-- 
	Viktor.

---

From: Guido Witmond <[email-masked]>
Date: Wed, 11 Dec 2013 00:45:13 +0100

> The intent is conveniently verified by an RRSIG generated by the

Which could be changed by a malicious Register. Ie. That's what needs to
be verified by both the domain owner and the end user.

> Arguing against the DANE security model has no bearing on the acronyms.

I'm arguing to propose names that the matches the End Users'
expectation. That might lead to some smart domain owners to consider how
their TLSA-records are received. Can't protect against Stupid, regrettably.

> usage 0 or usage 2, but think they do.

My misunderstanding. I believed it would specify my chosen CA for my
domain, I understand it could be more specific than that: A certain
subCA from that CA. Would it mean that that specific CA has *less*
options to get coerced to issue a fake certificate for my domain?

> Sure.  But I don't see an acronym here...
> 

I left acronyms to those better able to decide. I just wanted to point
out my ideas. Especially the idea to frame the acronyms in the mind-set
of the end-user. Because I believe, that's the person we need to protect.

Regards, Guido.

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 11 Dec 2013 00:31:40 +0000

> options to get coerced to issue a fake certificate for my domain?

[ EXACTLY.  This is the misunderstanding I want to discourage by NOT
naming "0" DANE-TA, but that is exactly what is is NOT.  My objection
to DANE-TA is looking stronger.  Please REVERT it to DANE-CA, and
the draft can then move forward without reinforcing confusion. ]

Yes, one can exclude various reseller subordinate CAs, or other
intermediates issued by some trusted CA, and thus protect verifiers
of your domain for being fooled by certificates issued by unrelated
rogue intermediates.  Provider your intermediate CA is not rogue,
you're safe(r).

> of the end-user. Because I believe, that's the person we need to protect.

I agree.  Thus my earlier posts suggesting we use name components
more familar to every-day users.  This excludes "PKIX" (almost
nobody knows what that means), "TA" and "EE".  The only proposed
name component that might mean something to people is "DANE" but
that applies to *all* the usages, they are all "DANE".  So the
proposed names are somewhat memorable, but meaningless.

The following would be much better:

	- LIMIT-ISSUING-AUTHORITY
	- LIMIT-LEAF-ENTITY
	- ASSERT-TRUSTED-ISSUER
	- ASSERT-LEAF-ENTITY

but unless the author decides to propose a revision, perhaps we're
stuck with the broken names and any confusion they may entrench.
I encourage the author to boldly change the names if he has seen
any merit in my arguments.  It is of course possible that I'm not
convincing anyone at all.  That's fine, I have actual code to write
and test.

-- 
	Viktor.