Subject: Re: [TLS] SHA-2 in TLS 1.0 and 1.1 -- Was: Remarks on draft-popov-prohibiting-rc4-01

From: Peter Gutmann <[email-masked]>
Date: Tue, 31 Dec 2013 02:20:37 +0000

Watson Ladd <[email-masked]> writes:

>Even if SHA-1 is utterly broken, this won't necessarily break HMAC based on
>it.

Exactly.  SHA-1 and HMAC-SHA1 are very different things, and concerns about
SHA-1 don't really affect HMAC-SHA1.

Peter.

---

From: Alyssa Rowan <[email-masked]>
Date: Tue, 31 Dec 2013 03:42:11 +0000

On 31/12/2013 02:20, Peter Gutmann wrote:
> Exactly.  SHA-1 and HMAC-SHA1 are very different things, and 
> concerns about SHA-1 don't really affect HMAC-SHA1.

On 30/12/2013 23:18, Watson Ladd wrote:
> Even if SHA-1 is utterly broken, this won't necessarily break HMAC 
> based on it.

Fair point. There's nothing to currently suggest the NSA have a
preimage on SHA-1, especially not one that'd endanger HMAC, unless (of
course) I've missed something, or just don't know something!

It's not ideal; it's not as good as Poly1305; but especially as a
fallback, it's not cataclysmic.

On 30/12/2013 23:18, Watson Ladd wrote:
> I also don't like the idea of backporting: if we are going to be 
> patching systems and forcing upgrades, why not to TLS 1.2 which 
> doesn't have these issues?

Complex question. Why not indeed? The deployment/inertia issue.

• TLS1.2 server / intolerant clients?
• TLS1.2 intolerant middleware?
  - Isn't that a dangerous downgrade?
• TLS1.2 client / intolerant servers?

I'm sure someone here (agl?) has specific "doghouse" examples of which
things are effectively holding back universal TLS1.2 deployment. These
might be useful as test cases: can we have a few names?

Clients with it but that don't turn it on by default (concern for
intolerant servers?) may be more common than we often think. To name a
few: Windows Schannel under Windows 7, Vista, IIS under 2008R2...
(Of course, they're still supported, and we could encourage MS to
issue an important patch enabling it... if people'd install it.)

Would a ChaCha20_SHA { draft-mavrogiannopoulos-chacha20-tls } that we
can still use with TLS1.0 & 1.1 be helpful as well as an fallback
augment to the better (and preferred) ChaCha20_Poly1305 for TLS 1.2?

• Downgrading: QUANTUMCOPPER can probably do this en-masse
  - As I said, we _really_ need { draft-bmoeller-tls-downgrade-scsv-01 }
  - But ChaCha20_SHA _might_ rescue us from using RC4_SHA
  - Unless, you know, they downgrade us back to SSLv3 and we don't bail
    on that. Then we're boned.
• Potential negative effect?
  - May be perceived as extending useful service life of TLS1.0 & 1.1
  - Simpler & less confusing to say TLS 1.0 and 1.1 are cooked?

Not sure about this one.

On 30/12/2013 23:18, Watson Ladd wrote:
> Chacha20+Poly1305 is a good addition to TLS 1.2 for devices without
> hardware support.

Absolutely agreed: and actually, I think it may be better than AES-GCM.

On 30/12/2013 23:18, Watson Ladd wrote:
> The one place we really depend on hash functions is in the 
> signatures that tie the key negotiation to the certificate chain. 
> There are ways around it like MQV, but that is patented.

Menezes-Qu-Vanstone had plenty of reasons to dislike it. Weaknesses;
patents; being dropped even from NSA Suite B; no PFS; HMQV also weak;
and with FHMQV we're back to being tied with hashes, so no point.

I reckon that's a dead-end. Besides, we've got good hash functions,
and can have excellent ones.

- -- 
/akr