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 _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
