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