Re: [dane] Digest algorithm agility (possible discussion topic for: Informal lunch meeting in Vancouver on Thursday)

[Matt McCutchen <[e-mail]>]

On Mon, 2013-11-04 at 22:32 +0000, Viktor Dukhovni wrote:
> Though I am not attending the Vancouver IETF meeting, I am interested
> in feedback on the below DANE-related issue:
> 
>     - Suppose some day we discover that SHA256 is flawed and is
>       subject to effective second-preimage attacks.
> 
>     - Suppose that hypothetically SHA512 remains secure.
> 
>     - How would clients and servers gracefully cut-over to only
>       use SHA512 and avoid SHA256?
> 
> My proposal is as follows:
> 
> When a TLSA RRset contains multiple RRs of the form:
> 
>         _<port>._tcp.server.example.com. IN TLSA <U> <S> <M> <D>
> 
> with the same values of "U" and "S" but different values of the
> matching type, a client MAY ignore a "weaker" matching type
> (deprecated digest algorithm) when a "stronger" matching type for
> the same usage and selector is present.  Which matching types are
> considered "weaker" is generally at the client's discretion.

>     - TLSA records that specify multiple certificates or public
>       keys for a single (U,S) combination (e.g. multiple trust
>       anchors, or multiple EE certificates during key roll-over)
>       MUST use the same set of matching types for all of them!
> 
>       Otherwise, clients may fail to support one of the desired
>       certificates, when they choose to support only the RRs with
>       the strongest matching type.

I.e., the same solution that is de facto used by DNSSEC DS records
(https://www.ietf.org/mail-archive/web/dnsext/current/msg11008.html).

I believe in the need for algorithm agility and proposed three possible
solutions including the above during the original design process
(https://trac.tools.ietf.org/wg/dane/trac/ticket/22), but got no
traction.

Matt