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

"dane issue tracker" <trac+dane@trac.tools.ietf.org> Mon, 21 March 2011 18:18 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: dane issue tracker <trac+dane@trac.tools.ietf.org>
Precedence: bulk
Auto-Submitted: auto-generated
To: matt@mattmccutchen.net
Date: Mon, 21 Mar 2011 18:19:35 -0000
Message-ID: <061.e0845de87f7a8d8d863b8ef546890255@trac.tools.ietf.org>
Cc: keyassure@ietf.org
Subject: [keyassure] [dane] #22: Provide the security of the strongest digest supported by both sides

#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/>

[keyassure] [dane] #22: Provide the security of t… dane issue tracker
Re: [keyassure] [dane] #22: Provide the security … dane issue tracker