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

[Matt McCutchen <[e-mail]>]

On Fri, 2013-11-15 at 05:45 +0000, Viktor Dukhovni wrote:
> On Tue, Nov 05, 2013 at 05:40:43PM -0800, Matt McCutchen wrote:
> 
> > > 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.
> 
> Thanks, yes, so my proposal requires no changes to the DANE RRset,
> rather it requires sensible DNS operator practice.  For each 
> (usage, selector) combination the mapping:
> 
>     "data" -> SET OF mtype for RRs that correspond to "data"
> 
> must be the same for all "data" that use the same (usage, selector).
> I think this is the "Cartesian Product" option in your ticket, but
> the set of mtypes may differ from one (usage, selector) pair to another.

Right.

Sensible as this practice may seem, it's not required by the standard,
which may reduce the likelihood that any given zone administrator will
be willing to follow it.  You may get fewer interoperability failures at
the cost of missing some attacks by having the zone opt into an
algorithm agility scheme by publishing additional RRs.

Matt