Subject: [keyassure] [dane] #22: Provide the security of the strongest digest supported by both sides

From: "dane issue tracker" <[email-masked]>
Date: Mon, 21 Mar 2011 18:19:35 -0000

#22: Provide the security of the strongest digest supported by both sides

 I posit that as a general principle, security protocols that support
 several alternative algorithms should provide the strength of the
 strongest algorithm supported by both sides.  (TLS generally does this in
 the absence of active attacks.)  For DANE, this principle means that I
 should be able to publish SHA-256 and SHA-512 digests in such a way that a
 client that supports SHA-512 gets the strength of SHA-512 and a client
 that supports only SHA-256 still works.

 This is not possible under the current design of the TLSA RRset.  If I
 publish SHA-256 and SHA-512 digests, then clients that support SHA-512
 will still accept any certificate that matches the SHA-256 digest.
 Indeed, there is no way for them to distinguish this scenario from one in
 which I have published the SHA-256 of one certificate and the SHA-512 of a
 different certificate.  The necessary and sufficient fix is to indicate
 which digests refer to the same certificate, either via an ID number or by
 just putting all the digests of the same certificate in the same RR.

 The TLSA RRset is based on the DNSSEC DS RRset, which has the same
 problem.  The DS RR contains a key tag, which could almost be used as an
 ID number, but [https://tools.ietf.org/html/rfc4034#appendix-B RFC 4034
 Appendix B] says, "Implementations MUST NOT assume that the key tag
 uniquely identifies a DNSKEY RR."  I would like to get the problem fixed
 in DNSSEC too, but I have not looked into that yet.

-- 
------------------------------------+---------------------------------------
 Reporter:  matt@…                  |       Owner:     
     Type:  defect                  |      Status:  new
 Priority:  major                   |   Milestone:     
Component:  protocol                |     Version:     
 Severity:  -                       |    Keywords:     
------------------------------------+---------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/dane/trac/ticket/22>
dane <http://tools.ietf.org/dane/>

---

From: "dane issue tracker" <[email-masked]>
Date: Thu, 24 Mar 2011 03:19:15 -0000

Comment(by matt@…):

 For the curious: [https://www.ietf.org/mail-
 archive/web/dnsext/current/msg11006.html George Barwood took my claim that
 the issue affects DNSSEC DS to the dnsext list] and discussion ensued.  It
 turns out DNSSEC DS has a solution that I was unaware of: assume that the
 DS RRset is formed as a Cartesian product of DNSKEYs with digest
 algorithms, and then the client uses the strongest algorithm it supports
 that appears in the set.

 This makes three possible solutions:
  1. Allow each RR to contain a set of (digest type, digest value) pairs
 for the same certificate.
  1. Require the RRset to be a Cartesian product of certificates with
 digest algorithms.
  1. Add an ID field to each RR to cross-reference all digests of the same
 object.
 IMO, solution 1 is the cleanest.

Ticket URL: <http://tools.ietf.org/wg/dane/trac/ticket/22#comment:1>
dane <http://tools.ietf.org/dane/>