On Thu, Aug 27, 2009 at 11:30:08AM +1200, Peter Gutmann wrote:
> Thor Lancelot Simon <t...@rek.tjls.com> writes:
> >the exercise of recovering from new horrible problems with SHA1 would be
> >vastly simpler, easier, and far quicker
> What new horrible problems in SHA1 (as it's used in SSL/TLS)?  What old
> horrible problems, for that matter?  The only place I can think of offhand
> where it's used in a manner where it might be vulnerable is for DSA sigs, and
> how many of those have you seen in the wild?

I think we're largely talking past one another.  As regards "new horrible
problems" I meant simply that if there _are_ "new horrible problems_ such
that we need to switch away from SHA1 in the TLS PRF, the design mistakes
made in TLS 1.1 will make it much harder.

As I read Ben's comments, they were _advocating_ those kinds of design
mistakes, advocating hard-wiring particular algorithms or their parameter
sizes into protocols, because -- as I understood him -- both replacing
and algorithm and replacing a whole protocol are just "software upgrades"
and all software upgrades are alike.

Well, I don't think it's true that all software upgrades are alike in the
relevant way.  In fact, it is radically harder to replace an entire
protocol, even with a related one, than to drop a new algorithm into an
existing, properly-designed protocol.  It may be no different for _users_,
but the difference for _implementers_ is vast, and that greatly delays the
availability of the relevant software upgrade to users, which is not a
good thing.

I think the current TLS 1.2 debacle is about the best evidence of this one
could ask for.  If TLS 1.{0,1} had been designed to make the hash functions
pluggagle everywhere they're used, then users would have new software which
didn't rely on SHA1 (even in a way we currently think is still safe)
available now, rather than having to wait quite a bit longer before the
possibility of upgrading even arose.


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Reply via email to