Re: [dane] Extending TLSA RFC to operate with TLS's new raw public keys

[Viktor Dukhovni <[e-mail]>]

On Tue, Jun 03, 2014 at 10:23:39PM -0400, James Cloos wrote:

> VD> Suppose the only one that does is a "DANE-TA(2) Cert(0) SHA2-256(1)".
> VD> What then?
> 
> The oob requesting client aborts.  And, perhaps, tries again w/o oob.
> 
> Or, if the client also groks oob-via-ldap, it uses the ldap info instead
> of the tlsa.
> 
> I know (based on your posts) that you don't like that as a possible outcome.  
> But for many it is not a big deal.

Authentication unnecessarily failing is indeed a big deal.  There isn't
always a user to click OK, and stateful fallback is a pain to get right
and opens up opportunities for downgrade attacks.

Unreliable authentication protocols that fail even when both sides
are doing everything right are broken by design.

Needless corner cases need to be rounded out.  I am willing to say
"SHOULD" rather than MUST, but otherwise, I am not giving up without
a better argument than "IETF security protocols sport broken corner
case by design" and we're used to it.  Just like we're used to
broken implementations I guess.  I am from a design and implementation
culture where we do it well, or not at all.

The onus to get this corner case avoided needs to be either on the
client or on the server.  The client-side solution is simpler:

    * Avoid "oob public key" negotiation when authentication is
      via DANE and TLSA records may require a full certificate.

The server-side solution is more complex:

    * When publishing any "3 1 X" TLSA records, always publish
      records that match the current leaf keys.  When transitioning
      to/from "3 1 X" TLSA RRs to other usage/selector pairs, change
      one thing at a time.  Either change the keys while keeping
      the set of usage/selector pairs fixed (publishing these for
      both new and old keys during the transition), or else keep
      the keys fixed and publish both new and old usage/selector
      combinations during the transition.

If the group strongly prefers the server-side approach, speak up.
Silence on the issue leads to security protocol implementations
that break for no good reason for a multiple of the TLSA RR TTL.

The OPS draft needs to advise the use of either or both of the
above approaches.

-- 
	Viktor.