I don't always agree with Steve but I think he has made a good case on
several occasions against the traditional 'menu choices' approach to
crypto algorithms.
The mere ability to specify a different algorithm ID is not sufficient
to provide an upgrade path. Unless both the sender and receiver know
which algorithm to expect the ability to specify different algorithms
can result in a situation where the security of the system is the
security of the weakest of the algorithms on offer rather than the
strongest.
The strength of the cryptographic algorithm is only one factor in
determining the security of the system, in most cases the least
important. We still have no confirmed cases of a criminal exploit based
on the known insecurity of 40bit SSL or WEP. MD5 is much more secure
than either of them.
It is important to understand the difference between the preferred
cryptographic algorithm and an acceptable one. At this point there is no
hash algorithm that is entirely satisfactory. SHA 256 is the nearest to
being acceptable but the design of SHA 256 is based on SHA-1 which has
issues.
From a security point of view the weaknesses in the hash algorithms are
like finding that the floor in your wood framed house drops 3 inches
over a 12ft span. The problem is not the roll to the floor, its what the
roll might indicate about what is under the floor (possibly termites).
The actual compromise known in MD5, SHA-1 and related algorithms are
only of immediate concern to a handful of applications. The criteria we
demand of hash algorithms are exceptionally conservative.
There are realy two sets of recommendations that are needed for crypto
algorithms:
1) Algorithms recommended for use in new applications
2) Algorithms that are acceptable for use in legacy applications without
concern
And then there are:
3) Algorithms that are acceptable for use in legacy applications after
careful analysis of the specif use
4) Algorithms that should be avoided at all costs.
For example, RSA 2048 would be in the first category, RSA 1024 and SHA1
in the second, DES and MD5 in the third, RSA 512 would be in the fourth.
I think that in general there should only be one or at most two
algorithms recommended for a certain type of operation.
The performance differences between SHA1 and SHA256 are so marginal that
I don't think they should be accepted as cause for allowing an algorithm
option.
I have in the past been very much opposed to ECC but the current level
of backing for ECC and 'SuiteB' crypto from the NSA does come with some
powerful arguments. There is certainly a sharp drop off in performance
of RSA above 2048 bits. There are IPR issues but these may well solve
themselves within an acceptable time frame (no patent lasts forever).
Phill
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On
Behalf Of Steven M. Bellovin
Sent: Monday, November 28, 2005 11:49 AM
To: Ted Lemon
Cc: iesg(_at_)ietf(_dot_)org; dhcwg(_at_)ietf(_dot_)org;
namedroppers(_at_)ops(_dot_)ietf(_dot_)org;
Pekka Savola; ietf(_at_)ietf(_dot_)org
Subject: Re: DHCID and the use of MD5 [Re: Last Call:
'Resolution of FQDNConflicts among DHCP Clients' to Proposed
Standard]
In message <200511261243(_dot_)21694(_dot_)mellon(_at_)fugue(_dot_)com>, Ted
Lemon writes:
Making a hash function interchangeable in DHCID makes the
conflict detection
algorithm hugely more complicated, and possibly not workable
at all. Think
about how that would work.
I confess that I don't see the problem. The updater would do
a DNS query for DHCID RRs; it would be given all of the
stored records. The updater would then use local policy --
that is, an ordered list of preferred hash functions -- until
it found one that was in the response. That one would be
used. If no locally-known hash functions are in the list, it
should behave as if there were no DHCID records present for
that name. DNSSEC could protect against downgrade attacks.
(Speaking of which -- were I still AD, I'd ding this document
for an inadequate Security Considerations section -- apart
from the lack of discussion of brute force attacks, you
should cite 3833 for DNS attacks and explain what the risks
are if someone can crack the hash function by any means,
including brute force or eavesdropping on the wire or
(perhaps) a misbehaving updater.)
If you don't agree, I'd strongly suggest using SHA-256
instead of MD5.
Yes, it's more expensive, but I doubt that that's a major hit
on overall system performance here. It would also be useful
to include in the document some discussion of upgrade
strategy -- how would we ever switch to a new hash function?
That's non-trivial even for protocols designed for agility,
as Eric Rescorla and I have shown. No matter how it's done,
this one is among the very hardest, since DNS servers would
have to supply DHCID records for several hashes for a number of years.
--Steven M. Bellovin, http://www.cs.columbia.edu/~smb
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf