Re: [dane] Digest Algorithm Agility discussion

[Wes Hardaker <[e-mail]>]

Viktor Dukhovni <[e-mail]> writes:

> The SMTP draft specifies a digest algorithm agility protocol for DANE.

So, trying to review this thread for where things stood and a number of
things jumped out at me.  Specifically, there is a lot of violent
agreement on some things.  So let me get the most important out of the
way that I'm firmly convinced everyone agrees on:  local policy always
trumps everything.  EG this is perfectly acceptable:

   if moon == full:
      acceptable_alg_list = [GOST]
   else if elvis == reborn or the_beetles == on_tour:
      acceptable_alg_list = [MD5, SHA51]
      prefer = any_match
   else 
      acceptable_alg_list = [SHA512, SHA256]
      prefer = first_existing_alg_published_from_list

And that (wacky) policy would always trump any other decision tree in
the code base.

Where things have been falling apart are

   o 
   o What is the default for "prefer", any_match [most people's opinion] or
     first_existing_alg_published_from_list [Viktor's opinion]?

To really consider this, we have to take a few things into account:

   o The server is unable to publish, for their clients, their
     preference order.  There is no way to make the statement "please
     authenticate my certificate using SHA256.  Unless you don't
     understand it, in which case just use SHA1".  The *only* thing it
     can do is publish things it trusts and hope the client uses the
     best one available, for which it has no say.

   o The client gets to pick what it's willing to accept and what it's not.

   o But, there are two sides to DANE.

     1. DANE is augmented security to the base infrastructure.  Rather
        than allowing 1300+ X.509 CAs, it restricts the connection to a
        single, linear X.509 path (tied to a single, linear DNSSEC
        path).  This is certainly the case for the HTTP case.  Even a
        MD5 hash to double check the CA path is likely an improvement
        to the non-DANE case.  It's an *added* check to the existing
        infrastructure.  So clients are more likely to be willing to
        accept nearly anything "not broken".

     2. DANE is *the* security mechanism, and without it you simply
        can't do some aspect of security.  In the SMTP case, it is
        impossible to do authentication without a DNSSEC/DANE solution.
        6698 was not originally written to cover this case (and, as
        discussed recently, this all hinges on "discovery" and that was
        deliberately left out of past solutions).  In this case, it's
        much more likely someone may want a policy of "if they indicated
        they can do my most preferred algorithm, then don't transmit the
        message if that algorithm is failing.  I don't care if there is
        another match to a less preferred one.

    o Now for case #2, it'd be easy to simply thing "look, just don't
      specify MD5 if you don't trust it".  But that's not so simple when
      it comes to connecting to random machines in the world.  It'd be
      great to have a policy of "Only accept SHA256 from example.com,
      but accept either SHA256 or SHA512 from example.org if either
      works".  That that's not a manageable policy to maintain for the
      internet at large.

      So where does that leave us?  With a choice.  What do we want as a
      policy knob.

The choice:

   Do you, Mr. System Administrator defining the local policy for the
   *client*, want:

   A) Accept any published hashing algorithm out of my "unordered set"
      to validate the remotely presented certificate.  [Ordering it
      doesn't buy you anything since you'll simply accept a match and it
      doesn't matter which you try first, since any success in any
      algorithm will equally indicate "ok"; in fact in an implementation
      aiming for speed, it might be best to choose the order based on
      how fast you can execute the algorithm].  If the server fails to
      publish a perfect record set, as long as one matches I'm ok with that.

   B) Believe that the server will always publish perfect records, and
      if my "ordered set" of algorithms is [SHA512, SHA256] and they
      publish SHA512, then I never want to accept SHA256 because I fear
      an attack more than I fear a server administrator blowing their
      configuration.

So to recap, first: either of those is fine in local policy knob setting
scheme.  Implementations can let administrators of clients configure
sane or insane policies they want.


But the real question, is what is the *default* that we should suggest
an implementation do?

RFC6698 indicates choice A ("accept anything that matches in my
unordered set").  But, what about other specific protocols?

I) what should we do generically?  RFC6698 already laid this out as A in
   absence of local policy.

II) what should we do in SMTP?  This is where Viktor, considering case
    #2 above, is wanting to do B ("accept just the 'best' in an ordered set
    of algorithms) instead of A.  The arguments, though, from both sides
    are probably talking about different cases (generic vs SMTP) and I
    think that is ending up with some of the confusion.

Here's the multiple choice quiz to cap all this off:

1. For generic DANE, is the right *default* choice:

   A) Accept any successful matching hash, regardless of "strength".
      (This is what 6698 says to do today)

   B) Accept only the strongest hash, from an ordered list, that the
      server has published (and DNSSEC has validated the RRSET for).

2. For SMTP, is the right (SMTP-application-specific) *default* choice:

   A) Accept any successful matching hash, regardless of "strength".
      (This is what 6698 says to do today)

   B) Accept only the strongest hash, from an ordered list, that the
      server has published (and DNSSEC has validated the RRSET for).

3. For XMPP:

   A) Accept any successful matching hash, regardless of "strength".
      (This is what 6698 says to do today)

   B) Accept only the strongest hash, from an ordered list, that the
      server has published (and DNSSEC has validated the RRSET for).

4. For HTTP:

   A) Accept any successful matching hash, regardless of "strength".
      (This is what 6698 says to do today)

   B) Accept only the strongest hash, from an ordered list, that the
      server has published (and DNSSEC has validated the RRSET for).

5. For IMAP:
....



-- 
Wes Hardaker
Parsons