Subject: [keyassure] Special, four issues (#2, #9, #13, #18) for the price of one....

From: Warren Kumari <[email-masked]>
Date: Thu, 10 Feb 2011 21:43:16 -0500

Hello again.

It appears to me that the current wording on trust anchors neatly resolves a bunch of issues namely:
#2: Relying parties policies (http://trac.tools.ietf.org/wg/dane/trac/ticket/2)
#9: Self-Signed Certificates (http://trac.tools.ietf.org/wg/dane/trac/ticket/9)
#13: Hostnames in Certificates (http://trac.tools.ietf.org/wg/dane/trac/ticket/13) 
#18: Certificate Properties and Relationship with PKIX (http://trac.tools.ietf.org/wg/dane/trac/ticket/18)

I would like to hear your views on this -- if you have substantive comments on any of the issues *please* start a new thread so that we can keep the discussions separate and organized.

W
(Not donning the shirt and baldricks as this is not an official consensus call or opening of an issue).

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 10 Feb 2011 18:59:09 -0800

> I would like to hear your views on this -- if you have substantive comments on any of the issues *please* start a new thread so that we can keep the discussions separate and organized.

Jakob and I would definitely like to hear more on this. If we need to 
say more about what a trust anchor is, we can do that. If people think 
we have over-restricted it in -04, that's good input as well. The -04 
text in question is:

A TLS client conforming to this protocol MUST treat the certificate
for association in a TLSA resource record for a domain name as a
trust anchor for that domain name at the specific port number and
transport name that was queried. This trust anchor MUST only be used
for the domain name of the resource record. The trust anchor MUST NOT
be loaded for longer than the TTL on the TSLA record.

--Paul Hoffman

---

From: Matt McCutchen <[email-masked]>
Date: Thu, 10 Feb 2011 22:36:19 -0500

On Thu, 2011-02-10 at 18:59 -0800, Paul Hoffman wrote:
> we have over-restricted it in -04, that's good input as well.

I haven't fully considered the issue, I just have two nits to pick:

> The -04 
> for the domain name of the resource record.

And port number and transport protocol name.

> The trust anchor MUST NOT

I think you want the RRSIG validity.  Requiring that clients limit the
trust anchor to the TTL would be false security.  However, clients would
be allowed to do so.

-- 
Matt

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 10 Feb 2011 20:07:53 -0800

> And port number and transport protocol name.

Why should we put on that requirement? That is, if I get a trust anchor 
for _443._tcp.www.example.com, what is the security issue if I also want 
to use it for TLS on port 4443? There is no attack that an MITM can 
mount on 4443 that they cannot also mount on 443.

> trust anchor to the TTL would be false security.  However, clients would

Good call. I'm not sure I agree, but it should definitely be discussed.

--Paul Hoffman

---

From: Simon Josefsson <[email-masked]>
Date: Fri, 11 Feb 2011 07:22:53 +0100

Paul Hoffman <[email-masked]> writes:

> Why should we put on that requirement? That is, if I get a trust
> anchor for _443._tcp.www.example.com, what is the security issue if I
> also want to use it for TLS on port 4443? There is no attack that an
> MITM can mount on 4443 that they cannot also mount on 443.

You may want to run a commercial CA on port 443 to get good interop with
deployed https clients, but you may want to use a trustworthy CA on port
4443 to get good security for some other services.  Having the
commercial CA be able to MITM the connection on 4443 sounds counter to
what I perceive DANE is aiming to achieve.

/Simon

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 11 Feb 2011 08:38:54 -0800

On 2/10/11 10:22 PM, Simon Josefsson wrote:
> 4443 to get good security for some other services.

Absolutely.

> Having the

Quite right, but that is not what the text in the document says. A 
highly-cautious client would not want to use the 443-trust-anchor for 
any other port, but I do not see the reason to force that policy on 
them, particularly if they want to reduce DNS round trips. It makes 
sense to force them to only use the trust anchor on the domain name 
given, because that sets the administrative boundary to the 
administrator of the domain name service; however, beyond that, it 
should be a client policy option.

Would you be OK if we left this as-is and put in a security 
consideration with the scenario you give?

--Paul Hoffman