Subject: [keyassure] draft-hoffman-keys-linkage-from-dns-02 security considerations

From: "Carl Wallace" <[email-masked]>
Date: Thu, 23 Sep 2010 09:23:49 -0400

Section 5 says a "DNS administrator who goes rogue and changes both the
A and CERT records for a domain name can cause the user to go to an
unauthorized server that will appear authorized."

This should have ", unless the client performs certificate validation
and rejects the certificate" appended (along with any words about poorly
managed trust anchor stores potentially negating the value of the
certificate validation).

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 23 Sep 2010 07:56:26 -0700

At 9:23 AM -0400 9/23/10, Carl Wallace wrote:
>Content-class: urn:content-classes:message
>Content-Type: multipart/alternative;
>	boundary="----_=_NextPart_001_01CB5B22.8ED1E670"
>
>Section 5 says a "DNS administrator who goes rogue and changes both the A and CERT records for a domain name can cause the user to go to an unauthorized server that will appear authorized."
> 
>This should have ", unless the client performs certificate validation and rejects the certificate" appended (along with any words about poorly managed trust anchor stores potentially negating the value of the certificate validation).

Good catch, yes. Will add to the next version.

--Paul Hoffman, Director
--VPN Consortium

---

From: Tony Finch <[email-masked]>
Date: Thu, 23 Sep 2010 19:34:45 +0100

On 23 Sep 2010, at 14:23, "Carl Wallace" <[email-masked]> wrote:
> Section 5 says a “DNS administrator who goes rogue and changes both the A and CERT records for a domain name can cause the user to go to an unauthorized server that will appear authorized.”
> 
> This should have “, unless the client performs certificate validation and rejects the certificate” appended (along with any words about poorly managed trust anchor stores potentially negating the value of the certificate validation).
> 
This looks to me like a lot of words to say not very much. There's no way the protocol can help a server admin protect themselves against a rogue DNS admin.

Tony.
--
f.anthony.n.finch  <[email-masked]>  http://dotat.at/

---

From: "Carl Wallace" <[email-masked]>
Date: Thu, 23 Sep 2010 14:45:59 -0400

> This looks to me like a lot of words to say not very much. 

Just ten additional words.  

> There's no way the protocol can help a server admin protect themselves against a rogue DNS admin.

The text is referring to the relying party, who can be protected against a rogue server appearing as authorized if it manages its trust anchor store well and performs path validation.  Adding something about the server admin would be good too.

---

From: Tony Finch <[email-masked]>
Date: Fri, 24 Sep 2010 00:14:36 +0100

> The text is referring to the relying party, who can be protected against a rogue server appearing as authorized if it manages its trust anchor store well and performs path validation.  Adding somet…

It's practically impossible to manage a TLS trust anchor store. The only alternative is leap-of-faith (or rather jump-through-several-hoops-of-faith) for each of dozens of websites, and do it again every year or two when the certs expire.

What do you mean by "path validation"?

Tony.

---

From: "Carl Wallace" <[email-masked]>
Date: Thu, 23 Sep 2010 19:50:25 -0400

> What do you mean by "path validation"?

Sorry, I left out "certification".  I meant section 6 of RFC 5280 - http://tools.ietf.org/html/rfc5280#page-71.