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

[Viktor Dukhovni <[e-mail]>]

On Mon, Nov 04, 2013 at 11:08:46AM -0800, Paul Hoffman wrote:

> If you're at the Vancouver IETF meeting and want to talk about
> DANE, hold the date.

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.

Rationale:

    Avoid algorithm switch flag days.  Once a widely used digest
    algorithm is deemed no longer robust, servers continue to
    include it in their TLSA records along with stronger digests.
    Correctly configured clients use only the stronger digests and
    are not exposed to the flaws of weaker algorithms.  Eventually,
    (once few clients remain that don't support strong digests)
    servers stop including weak digests in their TLSA RRsets.

Consequences:

    - 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.

    - Changes in the mixture of matching types (digest algorithms)
      used in a given TLSA RRset should be made when the set of
      keys is stable.  In other words, do either key rotation or
      change of digest algorithms, but not both at the same time.

      (Recall, that with key rotation, one must publish TLSA RRs
      for new keys before they are deployed in the field, as clients
      may for a short time see only the old RRs due to DNS caching).

Alternative:

    - Clients always accept all supported digests, without pruning
      for the strongest.

    - But then there is no good way to obsolete an algorithm, a
      server publishing a "weaker" digest exposes all clients
      risk.  A server publishing only the strongest digests risks
      not interoperating with many clients (flag day).

    - To avoid flag days, we need multiple strong *mandatory* to
      implement digest algorithms, and rely on them not all failing
      at the same time.

    - At this time RFC 6698 only mandates SHA256, so we don't have
      digest algorithm agility.

-- 
	Viktor.