On Mon, 19 Jan 2009 10:45:55 +0100 Bodo Moeller <[email protected]> wrote:
> On Sat, Jan 17, 2009 at 5:24 PM, Steven M. Bellovin > <[email protected]> wrote: > > > I've mentioned it before, but I'll point to the paper Eric Rescorla > > wrote a few years ago: > > http://www.cs.columbia.edu/~smb/papers/new-hash.ps or > > http://www.cs.columbia.edu/~smb/papers/new-hash.pdf . The bottom > > line: if you're running a public-facing web server, you *can't* > > offer a SHA-2 certificate because you have no way of knowing if the > > client supports SHA-2. Fixing that requires a TLS fix; see the > > above timeline for that. > > The RFC does exit (TLS 1.2 in RFC 5246 from August 2008 makes SHA-256 > mandatory), so you can send a SHA-256 certificate to clients that > indicate they support TLS 1.2 or later. You'd still need some other > certificate for interoperability with clients that don't support > SHA-256, of course, and you'd be sending that one to clients that do > support SHA-256 but not TLS 1.2. (So you'd fall back to SHA-1, which > is not really a problem when CAs make sure to use the hash algorithm > in a way that doesn't rely on hash collisions being hard to find, > which probably is a good idea for *any* hash algorithm.) > So -- who supports TLS 1.2? (Btw -- note the date of that RFC: August 2008. That's almost exactly 3 years after ekr and I published our paper. Since ekr is co-chair of the TLS working group, we can assume that that group was aware of the problem. See what Peter and I said about how long it takes to get any changes deployed.) --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to [email protected]
