Shared keys in TLS bug

Joseph Salowey has pointed out a problem with draft-ietf-tls-
sharedkeys-01.txt.  I was using the TLS PRF as a black-box PRF (which it was
in the SSL original), when in fact the TLS variant isn't a "pure" black-box
PRF.  Specifically, it splits the input secret value in half, so as used in
the draft it would in effect be reinventing crypt16.  Even as a general PRF
(used outside of the shared-keys draft) it's not safe to use without providing
large amounts of secret material, for example an otherwise-adequate 128-bit
key is split into two independent 64-bit keys by the PRF.

(Aside: Does anyone have any idea why TLS does this?  I can't see any good
 reason for it, and it acts as a booby-trap for anyone who's counting on the
 PRF being a black box.  If this problem hadn't been pointed out, I'd never
 have noticed it, since I was thinking of it as an SSL-style black box).

Anyway, the result of this is pretty ugly: Instead of just feeding the shared
secret into the PRF, it's necessary to be aware of its internal structure and
pre- process the input in a way that negates what the PRF does.  If the PRF is
changed in future versions of TLS, the pre-processing will need to change as
well in a PRF-dependent manner, unless it's made a true black box by
eliminating the secret-splitting step (hint, hint).

Some of the possible options to fix the problem are:

1. Synthesise a new PRF from HMAC to pre-PRF the input to the TLS PRF.

   Downsides: Yuck.  Also, this violates the minimal code-change requirement
   for TLS implementations that the shared-keys draft is supposed to provide,
   instead of just feeding data in via a standard mechanism you'd now need to
   extend the implementation to introduce new crypto mechanisms.

Re: Shared keys in TLS bug

At 02:19 AM 9/22/2003, Peter Gutmann wrote:
>Joseph Salowey has pointed out a problem with draft-ietf-tls-
>sharedkeys-01.txt.  I was using the TLS PRF as a black-box PRF (which it was
>in the SSL original), when in fact the TLS variant isn't a "pure" black-box
>PRF.  Specifically, it splits the input secret value in half, so as used in
>the draft it would in effect be reinventing crypt16.  Even as a general PRF
>(used outside of the shared-keys draft) it's not safe to use without providing
>large amounts of secret material, for example an otherwise-adequate 128-bit
>key is split into two independent 64-bit keys by the PRF.
>
>(Aside: Does anyone have any idea why TLS does this?  I can't see any good
>  reason for it, and it acts as a booby-trap for anyone who's counting on the
>  PRF being a black box.  If this problem hadn't been pointed out, I'd never
>  have noticed it, since I was thinking of it as an SSL-style black box).

IIRC, salving someone's fears that there could be a problem using both 
hashes keyed with the same key.

Can you describe why this is a problem? IANAC, but it's not obvious to me 
how you could take advantage of this, as long as either hash algorithm is 
secure. I don't see how you could recover information about the output of 
either "half" of the PRF from the output of the black box, and it seems 
that's what would be needed to be able to attack the halves of the keys 
seperately.

  - Tim

Re: Shared keys in TLS bug

At 12:27 AM 9/27/2003, Peter Gutmann wrote:
>Tim Dierks <tim <at> dierks.org> writes:
> >At 02:19 AM 9/22/2003, Peter Gutmann wrote:
> >>(Aside: Does anyone have any idea why TLS does this?  I can't see any good
> >>  reason for it, and it acts as a booby-trap for anyone who's counting 
> on the
> >>  PRF being a black box.  If this problem hadn't been pointed out, I'd 
> never
> >>  have noticed it, since I was thinking of it as an SSL-style black box).
> >
> >IIRC, salving someone's fears that there could be a problem using both 
> hashes
> >keyed with the same key.
> >
> >Can you describe why this is a problem? IANAC, but it's not obvious to 
> me how
> >you could take advantage of this, as long as either hash algorithm is 
> secure.
> >I don't see how you could recover information about the output of either
> >"half" of the PRF from the output of the black box, and it seems that's what
> >would be needed to be able to attack the halves of the keys seperately.
>
>Hmm, that sounds like a self-contradiction.  If it's not possible to recover
>the output of only one half of the PRF, then an attack that takes advantage of
>the fact that both halves use the same key wouldn't be possible either because
>you'd need to compromise both halves (you can't, for example, find a preimage
>for the MD5 half because you don't know what the SHA-1 half is doing to the
>output).

I only have a vague memory of the specific concern, but it was my 

RE: WG Last Call: Transport Layer Security Protoco l Compression Methods

> -----Original Message-----
> From: Win Treese [mailto:treese <at> acm.org] 
> Sent: Monday, July 14, 2003 12:55 PM
> To: IETF Transport Layer Security WG
> Subject: [ietf-tls] RE: WG Last Call: Transport Layer 
> Security Protocol Compression Methods
> 
> 
> 
> > Win,
> > 
> > What was the result of the WG last call for the document 
> described below?  I
> > didn't receive any private comments and I didn't see 
> anything sent to the
> > mailing list.
> 
> I received no comments. I'm making one last pass over it for 
> nits before
> submitting it to the IESG.

Win,

How is that last pass coming along?

-Scott-

Re: Shared keys in TLS bug

Tim Dierks <tim <at> dierks.org> writes:
>At 02:19 AM 9/22/2003, Peter Gutmann wrote:
>>(Aside: Does anyone have any idea why TLS does this?  I can't see any good
>>  reason for it, and it acts as a booby-trap for anyone who's counting on the
>>  PRF being a black box.  If this problem hadn't been pointed out, I'd never
>>  have noticed it, since I was thinking of it as an SSL-style black box).
>
>IIRC, salving someone's fears that there could be a problem using both hashes
>keyed with the same key.
>	
>Can you describe why this is a problem? IANAC, but it's not obvious to me how
>you could take advantage of this, as long as either hash algorithm is secure.
>I don't see how you could recover information about the output of either
>"half" of the PRF from the output of the black box, and it seems that's what
>would be needed to be able to attack the halves of the keys seperately.

Hmm, that sounds like a self-contradiction.  If it's not possible to recover
the output of only one half of the PRF, then an attack that takes advantage of
the fact that both halves use the same key wouldn't be possible either because
you'd need to compromise both halves (you can't, for example, find a preimage
for the MD5 half because you don't know what the SHA-1 half is doing to the
output).

The problem with splitting the input is that the most significant bytes/first
half of the premaster secret only affects MD5.  If you have a key size of
anything less than ( premaster_secret / 2 ) size bytes, the SHA-1 half is
keyed with an all-zero key.  With the SSL PRF this isn't a problem (both
halves use all the keying material) but with TLS it's an accident waiting to
happen - it would have happened in this case if Joseph hadn't spotted it, and
it may happen again in the future for people trying to add additional features

ICSA Labs' Modular SSL-TLS Certification Criteria, version 0.9