Subject: Re: [keyassure] draft-ietf-dane-protocol-02 posted

From: Yaron Sheffer <[email-masked]>
Date: Sat, 15 Jan 2011 23:00:38 +0200

Hi,

I have an issue with the name of the DNS record type. "TLSA" implies one 
specific protocol. The working group's scope includes additional ones, 
and those and possibly others will want to use the same record type, 
hopefully. How about adopting a protocol-agnostic name? To throw 
something out, I suggest NEE: Named End Entity.

Thanks,
	Yaron

Date: Sat, 15 Jan 2011 08:21:17 -0800
> From: Paul Hoffman<[email-masked]>
> Subject: [keyassure] draft-ietf-dane-protocol-02 posted
> To: "[email-masked]"<[email-masked]>
> Message-ID:<[email-masked]>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> The main change is the definition of the wire format to match the
> consensus call made yesterday closing issue #4. Jakob and I intend to
> keep pumping out drafts as issues are closed. We probably won't do one
> draft per consensus call, but hope to do one when each "big" issue is
> closed.
>
> --Paul Hoffman

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 15 Jan 2011 23:15:42 +0200

Hi,

Sec. 3.1.2 of the draft singles out self-signed certs, where "host 
names" (in the section title) or "all data other than the key" (first 
paragraph) is ignored.

I have two issues here:

- The first paragraph should have a normative SHOULD, instead of "can". 
The data is indeed untrustworthy and clients SHOULD ignore it unless 
validated otherwise.

- The exact same considerations apply to non-self signed certs. I don't 
see a reason to talk specifically about self-signed certs. Just because 
someone presents a cert that has, say, Verisign as the Issuer, doesn't 
mean it is a valid Verisign certificate unless validated in the 
traditional manner. So none of the certificate data can be trusted, 
including the important Subject and SubjectAltName fields. Sec. 3.1.4 
kind of implies this fact, but the incorrect differentiation between 
regular and self-signed certs remains.

Thanks,
	Yaron

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 15 Jan 2011 17:00:44 -0800

On 1/15/11 1:00 PM, Yaron Sheffer wrote:

> hopefully.

This would be issue #5 on our open issues list (reminder: 
<http://trac.tools.ietf.org/wg/dane/trac/report/1>). Are you trying to 
get the chairs to start this discussion sooner than the others they 
might want? :-) [1]

--Paul Hoffman

[1] The smiley there is because Yaron is co-chair of the IPsecME WG with 
me and we tend to run our group off the issue tracker.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 15 Jan 2011 17:08:11 -0800

> The data is indeed untrustworthy and clients SHOULD ignore it unless

This was argued about previously, I think. This should be a new open 
issue because it deals with adding a 2119-level restriction. Also, why 
"SHOULD" and not "MUST"? When is is OK to not ignore the data? (FWIW, I 
don't have strong feelings either way on any of this).

> see a reason to talk specifically about self-signed certs.

We disagree here. The Issuer field in a CA certificate cannot be ignored 
when doing PKIX chaining.

> Just because
> traditional manner.

Um, exactly. But self-signed certs are not "validated in the traditional 
manner", which is why this section exists.

> So none of the certificate data can be trusted,

I believe there is a strong differentiation between "was validated" and 
"wasn't validated". If you and I are saying the same thing, I would love 
to see text to clarify what we have written.

--Paul Hoffman