Subject: Re: [TLS] Last Call: <draft-kanno-tls-camellia-00.txt> (Addition of the Camellia Cipher Suites to Transport Layer Security (TLS)) to Informational RFC

From: Sean Turner <[email-masked]>
Date: Tue, 08 Mar 2011 10:29:13 -0500

On 2/28/11 3:45 AM, Nikos Mavrogiannopoulos wrote:
> On Mon, Feb 28, 2011 at 7:35 AM, Satoru Kanno
> <[email-masked]>  wrote:
>
>>> I see that this document defines ciphersuites with a PRF based on
>>> SHA384... However it does not specify the verify_data_length, thus
>>> the default value of 12 applies, and the SHA384 PRF is being truncated
>>> to 96 bits. Is this intentional? If yes, then what is the purpose to
>>> use the SHA384 as PRF?
>> Hi Nikos,
>> Thank you for your comment.
>> I think that the verify_data_length with a PRF based on
>> SHA384 is specified in RFC5246.
>> As a result, I refer to RFC5246 as well as other documents( e.g., RFC5289,
>> RFC5487, and draft-nsri-tls-aria etc.,) in our document.
>> I think that your comment is not only our draft but all documents specifying
>> the PRF base on SHA384 for TLS.
>
> Yours was the first document I noticed to use SHA384 as PRF. If there
> are other documents that specify that, and don't set the verify_data_length
> size then it applies to those as well. (just noticed that applies to RFC5288
> as well).

If the verify_data_length default is 12 (from 5246) then saying nothing 
means that it's still 12 right?  Or, do you think an explicit statement 
saying "the default value for verify_data_length of 12 is used" is needed?

spt

---

From: Martin Rex <[email-masked]>
Date: Tue, 8 Mar 2011 16:59:47 +0100 (MET)

> saying "the default value for verify_data_length of 12 is used" is needed?

Truncating the PRF output to 12 octets for TLSv1.2 seems like an error.

If truncating a SHA-1 based PRF in TLSv1.0/TLSv1.1 to 12 Octets is
considered adequate (20/12), then truncation in TLSv1.2 with
a SHA-256 based PRF should have been (32/20) and truncation for
a SHA-384 based PRF should be more like (48/28) or (48/32).

To me, Truncating the output of a SHA-384 PRF to 12 Octets looks like
unreasonable cutdown of the security margin for the Finished messages.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 8 Mar 2011 08:29:14 -0800

I don't understand this reasoning. Why does the output size of the
pre-truncated PRF
influence the desirable length of the verify_data (provided that the
output size is > than
the length of the verify_data of course).

-Ekr

On Tue, Mar 8, 2011 at 7:59 AM, Martin Rex <[email-masked]> wrote:
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: Martin Rex <[email-masked]>
Date: Tue, 8 Mar 2011 18:20:31 +0100 (MET)

> the length of the verify_data of course).

One of the purposes of a cryptographic hash function is to protect
from collisions (both random and fabricated collisions).

Cutting down the SHA-384 output from 48 to 12 octets significantly impairs
its ability to protect from collisions.  It's comparable to
truncating the SHA-1 output from 20 to 5 octets.

Unless you have _a_very_good_reason_ to truncate a hash output
so severely, you very probably should not do it.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 8 Mar 2011 09:33:59 -0800

> truncating the SHA-1 output from 20 to 5 octets.

I don't understand this analysis. Consider two ideal PRFs:

* R-160 with a 160-bit output
* R-256 with a  256-bit output

Now, consider the function R-256-Reduced, which takes the first 160
bits of R-256.
Are you arguing that R-256-Reduced is weaker than R-160? If so, why?

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Tue, 8 Mar 2011 19:07:50 +0100 (MET)

Eric Rescorla wrote:
> Now, consider the function R-256-Reduced,
> which takes the first 160 bits of R-256.

What we're having are the two cases:

  1)  R-160 truncated to 96 bits
  2)  R-256 truncated to 96 bits
  3)  R-160 with full 160-bits

If your primary focus was collision avoidance, then
3) is stronger than 1) and 2) by a huge margin.

There may be reasons why you don't want (3), like an attackers ability
to verify when he guesses keys correctly that are input to the PRF.

When 20/12 is a good truncation ratio for a 160-bit PRF,
then 48/12 looks like a poor truncation ratio for a 384-bit PRF
(and SHA-384 is already a truncated SHA-512 anyway).
Applying the 20/12 tradeoff to R-256 results in approximately (32/20)
and to R-384 results in approximately (48/28) -- with (48/32) probably
sufficiently close.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 8 Mar 2011 10:11:38 -0800

> 3) is stronger than 1) and 2) by a huge margin.

Yes, I totally agree.

> and to R-384 results in approximately (48/28) -- with (48/32) probably

I don't understand this analysis at all. Again, are you arguing that
(1) and (2) have
different security properties?

If not, then why does it matter what the size of the input PRF is, as
long as it is >=
the size to which it is truncated?

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 8 Mar 2011 10:22:27 -0800

On Tue, Mar 8, 2011 at 10:15 AM, Marsh Ray <[email-masked]> wrote:
> On 03/08/2011 11:33 AM, Eric Rescorla wrote:
>>
>> On Tue, Mar 8, 2011 at 9:20 AM, Martin Rex<[email-masked]>  wrote:

> I think it's more comparable truncating SHA-1 down to 12 octets.

Yes, this matches my analysis.

> I think he's arguing that anything cut down to 96 bits represents a lousy
> hash function allowing practical collisions on today's hardware.

Perhaps, but this isn't a digest but rather
a MAC, and so the attack model is different. Without knowing the key, you
basically have a 2^{-b} chance of producing an input which will pass the MAC
check, where b is the length of the MAC. Note that additional computational
power doesn't help much here because you still need to search the entire
key space, not the output space, in order to break the MAC.

However, the answer to *this* question is a distinct from whether a different
size hash function used as the basis for a MAC demands a different truncation.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Tue, 8 Mar 2011 19:30:39 +0100 (MET)

Eric Rescorla wrote:
> (1) and (2) have different security properties?

In case they were both "ideal" - no.

But in that case, asking anyone for the effort to replace
1) with 2) would be a complete waste of resources.

If we move in a new, stronger crypto-algorithm, then we should not
unreasonably spoil its properties.

Truncating a SHA-384 based PRF to 12 octets is like using
an sha384WithRsaEncryption signature with a 1024 bit RSA key,
it is an imbalanced pairing of algorithms&keys.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 8 Mar 2011 10:35:26 -0800

> it is an imbalanced pairing of algorithms&keys.

Again, I don't understand this: TLS already (as of TLS 1.0) truncated
the PRF down
to 12 bytes, so we are already producing an output that is
substantially shorter than
the digest that is the basis of the function. If the security
arguments for why that
is good are valid (and FWIW I think they are) then as far as I can
tell they are
equally applicable to SHA-384.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Tue, 8 Mar 2011 19:45:12 +0100 (MET)

Eric Rescorla wrote:
> Marsh Ray wrote:
> Perhaps, but this isn't a digest but rather a MAC, and so the attack
> model is different.

You seem to be forgetting that the finished messages have been reused
for other purposes already:

   RFC-5929 TLS Channel Bindings
   RFC-5746 TLS extension Renegotiation indication

I'm sorry, but I think it is a bad idea to use a flawed design for
the TLS finished message by subverting the collision resistence
of stronger secure hash functions that are used for the PRF.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 8 Mar 2011 10:51:05 -0800

> for other purposes already:

No, I'm not forgetting that. That doesn't change the fact that the
computation is
a MAC.

> of stronger secure hash functions that are used for the PRF.

Yes, I realize you think that, but until you offer a cryptographic
argument for that
opinion I guess we're just going to have to disagree.

-Ekr

---

From: Martin Rex <[email-masked]>
Date: Tue, 8 Mar 2011 19:58:48 +0100 (MET)

Eric Rescorla wrote:
> the PRF down to 12 bytes, so we are already producing an output that is
> substantially shorter than the digest that is the basis of the function.
> If the security arguments for why that is good are valid (and FWIW I
> think they are) then as far as I can tell they are

The truncation of hashes/PRFs/HMACs is a trade-off.

A trade-off between collision-resistance and how much clue
is provided about the input.

A (20/0) trade-off provides the smalles possible clue,
but completely spoils the collision-resistance (i.e. it becomes
useless for verification purposes).

A (20/20) trade-off retains the full collision resistance,
but provides the largest amount of clue for verification
of input paramters.

The trade-off that was chosen for SHA-1 was (20/12) or (160/96).
which is 1.666666666

TLS uses a different trade-off, but I'm not aware of any rationale
why the original trade-off in TLSv1.0/TLSv1.1 should have been
inappropriate.  The logical choice in TLSv1.2 would therefore
have been to use (32/20) = 1.6 for a PRF that uses SHA-256.
And any _other_ trade-off (such as the one in rfc-5246) should
require a _new_ justification.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 8 Mar 2011 20:23:47 +0100 (MET)

Eric Rescorla wrote:
> argument for that opinion I guess we're just going to have to disagree.

You got it backwards.  I say that it is a bad idea to truncate
a PRF based on SHA-256 to 96, and even worse idea to truncate a
PRF based on SHA-384  -- and anyone who wants to do that should
better provide a good cryptograhic argument.

Truncating HMACs and PRFs may have become first popular in
the IETF within IPSEC.

Looking at this table:

     http://tools.ietf.org/html/rfc4868#section-2.6

   +------------------+--------+--------+--------+--------+------------+
   |    Algorithm     | Block  | Output | Trunc. |  Key   | Algorithm  |
   |       ID         |  Size  | Length | Length | Length |   Type     |
   +==================+========+========+========+========+============+
   | HMAC-SHA-256-128 |   512  |   256  |  128   |  256   | auth/integ |
   +------------------+--------+--------+--------+--------+------------+
   | HMAC-SHA-384-192 |  1024  |   384  |  192   |  384   | auth/integ |
   +------------------+--------+--------+--------+--------+------------+
   | HMAC-SHA-512-256 |  1024  |   512  |  256   |  512   | auth/integ |
   +------------------+--------+--------+--------+--------+------------+
   | PRF-HMAC-SHA-256 |   512  |   256  | (none) |  var   |     PRF    |
   +------------------+--------+--------+--------+--------+------------+
   | PRF-HMAC-SHA-384 |  1024  |   384  | (none) |  var   |     PRF    |
   +------------------+--------+--------+--------+--------+------------+
   | PRF-HMAC-SHA-512 |  1024  |   512  | (none) |  var   |     PRF    |
   +------------------+--------+--------+--------+--------+------------+

If there existed a cryptographic argument (which you insist on) then
I'm sure there would be an HMAC-SHA-394-96 in the above list.

What is your argument why there should be a HMAC-SHA-384-96 in that list?
(which would apply to a ciphersuite with a SHA-384 based PRF and
finished messages truncated to 12 octets).

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 8 Mar 2011 21:15:50 +0100 (MET)

> is provided about the input.

  TLSv1.0 (rfc2246) references RFC-2104 (HMAC)
  TLSv1.1 (rfc4346) contains a normative reference to RFC-2104 (HMAC)
  TLSv1.2 (rfc5246) contains a normative reference to RFC-2104 (HMAC)

http://tools.ietf.org/html/rfc2104#section-5

  5. Truncated output

                                                            Applications
   of HMAC can choose to truncate the output of HMAC by outputting the t
   leftmost bits of the HMAC computation for some parameter t (namely,
   the computation is carried in the normal way as defined in section 2
!  above but the end result is truncated to t bits). We recommend that
!  the output length t be not less than half the length of the hash
!  output (to match the birthday attack bound) and not less than 80 bits
   (a suitable lower bound on the number of bits that need to be
   predicted by an attacker).

That rfc-5246 did not increase the finished messages to at least
16 octets (128) when using a SHA-256 based PRF, without providing
any rationale, seems like a defect to me, since it is clearly against
the rationale in the normative reference.  The difference is not so
much about TLSv1.2 itself, where truncation to 96 bits is used
with SHA-256 instead of the recommended minimum length of 128,
but the bad precedent for successor specs using longer hashes,
suggesting a truncation of 96 for a PRF-386 based hash, which
is extremely far off the recommended minimum length of 192 bits.

I think that a TLS cipher suite definition that uses a PRF based
on SHA-384 ought to be required to provide a rationale when
truncating the finished messages to 96 bits, instead of the
minimum "half the length of the hash" recommended by rfc-2104.

-Martin

---

From: Martin Rex <[email-masked]>
Date: Tue, 8 Mar 2011 21:19:41 +0100 (MET)

resend (Sorry, for the typos.)

  5. Truncated output

                                                            Applications

That rfc-5246 did not increase the finished messages to at least
16 octets (128) when using a SHA-256 based PRF, without providing
any rationale, seems like a defect to me.  It is clearly against the
recommendation in the normative reference.  The difference is not so
much about TLSv1.2 itself, where truncation to 96 bits is used
with SHA-256 instead of the recommended minimum length of 128,
but the bad precedent for successor specs using longer hashes,
suggesting a truncation to 96 bits for a SHA-384 based PRF, which
is extremely far off the recommended minimum HMAC truncation
length of 192 bits for SHA-384.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 8 Mar 2011 13:45:35 -0800

>   predicted by an attacker).

Ok, but this is just a handwavy rationale. As far as I'm aware, the
actual cryptographic
analysis is as Hovav has stated.

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 8 Mar 2011 17:08:38 -0800

On Tue, Mar 8, 2011 at 3:55 PM, Peter Gutmann <[email-masked]> wrote:
>
> Martin Rex <[email-masked]> writes:
>
>>Truncating HMACs and PRFs may have become first popular in the IETF within
>>IPSEC.
>
> It wasn't any "may have become first popular", there was only room for 96 bits
> of MAC data in the IP packet, so MD5 was truncated to that size.

This is an odd claim, since:

(a) RFC 1828 (http://tools.ietf.org/html/rfc1828) originally specified
not HMAC but a keyed MD5 variant
with a 128-bit output.
(b) The document that Martin points to has MACs > 96 bits long.

Can you please point to where in IP there is a limit that requires a
MAC no greater than 96 bits.

-Ekr

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 9 Mar 2011 10:10:17 +0100

> No, I'm not forgetting that. That doesn't change the fact that the

I'm not a specialist in MAC algorithms but by checking
the ECRYPT II[0] report of 2009-2010, I can try making some points.
A MAC has a security level that depends on the size of the MAC
and the size of the key. That is a 12-byte MAC has security level of
MIN(2^{key_size}, 2^{96}) [1], irrespective of the key size used.

As I understand the addition of SHA-384 as PRF was to increase
the security margin of TLS comparing to the SHA-1 PRF. This
is not occuring now because a MAC based on algorithm that
returns 384-bits and truncates it  to 96 can offer nothing more
than an algorithm that outputs 160 bits and are trucated to 96.
Hence there is no significant difference than SHA-1 or SHA-384
in that case, so why define SHA-384 anyway?

For me the ciphersuites defined in TLS should have a uniform
security level. I.E. why use AES-256 with security level of 2^256
but use a MAC for a handshake of 2^96 bits?

regards,
Nikos

[0]. http://www.ecrypt.eu.org/documents/D.SPA.13.pdf

[1]. For an HMAC the square root of
the internal state of the hash algorithm is also affecting the
security level.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 9 Mar 2011 06:32:04 -0800

Overflowing by another 32 bits is hardly the same as "there was only room for"

-Ekr

On Wed, Mar 9, 2011 at 1:57 AM, Peter Gutmann <[email-masked]> wrote:
> Eric Rescorla <[email-masked]> writes:
>
>>Can you please point to where in IP there is a limit that requires a MAC no
>>greater than 96 bits.
>
> The AH had room for exactly 96 bits of MAC value, any more and it'd have to
> overflow to another 32 bits worth (the size of the non-MAC data is 96 bits and
> the MAC data adds the other 96 bits), see RFC 2402.  The original AH used a
> 64-bit data field (RFC 1826) and didn't truncate MD5 (RFC 1828), so it was
> also 192 bits long.  With the expansion of the non-MAC data to 96 bits, it was
> necessary to truncate the MAC to keep the same overall size.
>
> Peter.
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 9 Mar 2011 06:34:54 -0800

> in that case, so why define SHA-384 anyway?

If you recall, the reason why TLS 1.2 was done was not primarily because
of concerns about SHA-1's 160-bit output being large enough but because
people started developing analytic attacks on MD5 and SHA-1 that brought
it's security level down below the nominal level.

In other words, there are many applications where 80 bits of security is
fine, but people don't want to use SHA-1 because they don't trust it.

> but use a MAC for a handshake of 2^96 bits?

Because the attack model for MACs is not the same as the attack model
for encryption. The encryption is susceptible to offline attack, whereas
with a MAC all you need to do is get the guessing probability sufficiently
low because *any* failed forgery causes connection termination.

-Ekr

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 9 Mar 2011 16:28:03 +0100

> fine, but people don't want to use SHA-1 because they don't trust it.

Such things should be explicit then. In any case I think there is a mistake
here since RFC5288 defines the AES-256 ciphersuites with SHA-384 as
PRF, and the AES-128 ciphersuites with SHA-256, thus there was
intention to match the security strength of the cipher with the size
of the hash.

If this wasn't the intention, then it is pretty much misleading, and should
be explicit. E.g. Although we define SHA-384 as PRF in this ciphersuite, it
is being truncated in 96 bits. The choice for SHA-384 was because .....

> low because *any* failed forgery causes connection termination.

This depends on the threat model you have. There might be cases where
the case you describe is no problem for the adversary.

regards,
Nikos

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 9 Mar 2011 07:44:49 -0800

> is being truncated in 96 bits. The choice for SHA-384 was because .....

I'm not one of the authors of that draft, but I imagine for the usual
reason of tiling
the space of algorithms (not that I consider it a great reason.)

-Ekr

---

From: Marsh Ray <[email-masked]>
Date: Tue, 08 Mar 2011 10:52:29 -0600

> unreasonable cutdown of the security margin for the Finished messages.

I agree.

Last I looked into it, I came to the conclusion that collisions of any 
efficient 96 bit hash function are likely within range of today's 
supercomputers and botnets.

But the logistics of it probably make it impractical for an actual 
attack. You need the master secret to manipulate the verify_data in any 
valid way (and if the attacker had that there'd be no security left to 
attack anyway). Otherwise, a useful attack on the finished message 
probably has to involve 2^48 or so live network connections to collide 
among.

- Marsh

---

From: Marsh Ray <[email-masked]>
Date: Tue, 08 Mar 2011 12:15:30 -0600

On 03/08/2011 11:33 AM, Eric Rescorla wrote:
>>> output size is>  than

As I mentioned, that appears not to be the case here, but I have found 
no written rationale for this design subtlety. I could be missing something.

It's also possible that some cipher suite or mode could be added in the 
future that makes a collision on the verify_data significant.

> Are you arguing that R-256-Reduced is weaker than R-160? If so, why?

I think he's arguing that anything cut down to 96 bits represents a 
lousy hash function allowing practical collisions on today's hardware.

The implication for TLS protocol evolution (and anything else 
interpreting bytes-on-the-wire) is to keep in mind that the 
Finished.verify_data is simply not designed to resist offline collision 
attacks.

Remember to bring this up the next time somebody suggests permitting 
endpoints to use lousy RNGs, particularly in conjunction with 
certificates with fixed DH parameters.

- Marsh

---

From: Marsh Ray <[email-masked]>
Date: Tue, 08 Mar 2011 13:32:18 -0600

>     RFC-5746 TLS extension Renegotiation indication

Yes, it would be bad if those could be collided.

> of stronger secure hash functions that are used for the PRF.

Here's how my reasoning goes. I could be wrong.

The Finished.verify_data represents a 96-bit MAC, not a general-purpose 
cryptographic hash function.

The attacker is presumed to have the ability to modify data at some 
points in the protocol stream. The protocol relies on correct 
validiation of the verify_data to detect this condition and abort.

Master_secret is not known to the attacker, if the connection is 
properly authenticated. The authentication only depends on the 
verify_data to prevent downgrade attacks. But if the authentication is 
broken, the attacker can simply issue the proper MAC and has no need to 
collide them.

Master_secret is very long, changes every full handshake, and is 
required to compute the MAC.

Any offline precomputation the attacker could do in support of collision 
finding requires the ability to compute the MAC function for the actual 
master_secret (as computed by the client or the server including 
locally-generated entropy not received from the attacker).

Therefore, collisions on the Finshed.verify_data require active sessions 
to be useful and the attacker will need to amass a pool of about 2^48 of 
them to collide between.

- Marsh

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 09 Mar 2011 12:45:55 +1300

>Truncating the PRF output to 12 octets for TLSv1.2 seems like an error.

It's not an error, it's IPsec cargo cult design.  OK, using cargo cult design 
for a security protocol probably rates as an error, but the choice of exactly 
96 bits was deliberate rather than the full size was deliberate.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 09 Mar 2011 12:55:06 +1300

It wasn't any "may have become first popular", there was only room for 96 bits 
of MAC data in the IP packet, so MD5 was truncated to that size.  Since then an
army of cargo-cult designers have copied it without knowing why, but if IPsec
did it it had to be good, right?

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 09 Mar 2011 22:57:37 +1300

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 10 Mar 2011 12:50:54 +1300

>Overflowing by another 32 bits is hardly the same as "there was only room

If you've decided that the size is going to be 192 bits and, due to other
changes, you have only 96 bits left, I don't see how this is anything other
than "there was only room for".  You can't get 128 bits into 96 no matter how
hard you try.

Could we perhaps get past the semantic nitpicking and back to the normal
bikeshedding?  Or at least take it off-list?

Peter.

---

From: Stephen Kent <[email-masked]>
Date: Thu, 10 Mar 2011 18:28:47 -0500

>MAC no greater than 96 bits.

What Peter probably meant to say was that IPsec chose to truncate the HMAC
value to 96 bits because that preserved IPv4 and IPv6 byte-alignment for
the payload.  Also, as others have noted, the hash function used here is
part of an HMAC calculation, and any collisions have to be real-time 
exploitable to be of use to an attacker.  Thus 96 buts was viewed as 
sufficient.

Steve

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 11 Mar 2011 08:20:59 +0100

On 03/11/2011 12:28 AM, Stephen Kent wrote:

>>> It wasn't any "may have become first popular", there was only
>>> room for 96 bits of MAC data in the IP packet, so MD5 was
>>> truncated to that size.
>> 
>> (a) RFC 1828 (http://tools.ietf.org/html/rfc1828) originally
>> specified not HMAC but a keyed MD5 variant with a 128-bit output. 
>> Can you please point to where in IP there is a limit that requires
>> a MAC no greater than 96 bits.
>> 
>> -Ekr
> 
> What Peter probably meant to say was that IPsec chose to truncate the
> HMAC value to 96 bits because that preserved IPv4 and IPv6
> byte-alignment for the payload.  Also, as others have noted, the hash
> function used here is part of an HMAC calculation, and any collisions
> have to be real-time exploitable to be of use to an attacker.  Thus
> 96 buts was viewed as sufficient.

This sounds pretty awkward decision because HMAC per record is full
(e.g. 160-bits on SHA-1), but the MAC on the handshake message
"signature" is truncated to 96-bits. Why wasn't the record MAC
truncated as well? In any case saving few bytes per handshake
is much less of value than saving few bytes per record. Was
there any other rationale for truncation?

regards,
Nikos

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 11 Mar 2011 06:49:53 -0800

If your question is why did the TLS WG decide to do this back in like
1996 or so?

If so, it would require a real archive search to get a definitive
answer, but my vague
memory is that (a) it was suggested by one of the cryptographers in
the group, e.g.
Hugo Krawczyk or Ran Canetti and (b) it was motivatated by the desire to
limit the amount of information disclosed about the MS (remember that it used to
be 36 bits!). I don't recall why 12 bytes rather than 16 bytes or 20 was chosen.

Best,
-Ekr

---

From: Martin Rex <[email-masked]>
Date: Fri, 11 Mar 2011 17:07:34 +0100 (MET)

Eric Rescorla wrote:
> answer

A very superficial scan of the first ietf-tls 1996 archive I came across
turned out an an interesting thread "Additional suggested cleanups for TLS"

Index page:  http://lists.w3.org/Archives/Public/ietf-tls/1996OctDec/

started on 16-Dec-1996 by Dan Simon with this message:

  http://lists.w3.org/Archives/Public/ietf-tls/1996OctDec/0218.html

and the whole thread is a very interesting read.

e.g. excerpt from Dan Simon's message
  http://lists.w3.org/Archives/Public/ietf-tls/1996OctDec/0224.html

   [...]
  On the other hand, there's simply no justification for using a weaker
  construction in the (more crucial) finished message than in the standard
  data MAC.  Since you vehemently opposed anything weaker than HMAC for
  data MACing, even for the sake of efficiency (right here on this mailing
  list, in fact, when we were discussing pre-MAC'd data), I assume you'd
  never support using a weaker function in the finished message--right,
  Phil? 

  In any event, the function used in SSL 3.0's finished message is flawed,
   [...]

In case that Dan Simon stands to his message from 1996, it seems unlikely
to me that he would consider a TLS cipher suite design reasonably
balanced that uses HMAC-SHA-384 for data MACs, but keeps truncating
"the (more crucial) finished message" to 12 octets.

Another interesting excerpt from the first message of Dan Simon which started
this discussion thread:

  http://lists.w3.org/Archives/Public/ietf-tls/1996OctDec/0218.html

   [...]
  Standardized key generation using PRFs

  Hugo Krawczyk recently suggested to the WG on this list that an explicit
  PRF primitive be introduced into the spec, so that the protocol could be
  based on an easily replaceable function whose assumed properties would
  be clearly defined and well understood.

   [...]

  As well as standardizing the key derivation process, this change to a
  uniform PRF-based method would encourage implementers to make the PRF
  pluggable, allowing more secure or more efficient functions to replace
  the current one in the future as needed.  (In fact, we might consider
  switching to a better PRF immediately, if we are already breaking
  backward compatibility by changing HMAC.)  Ideally the current cipher
  suites would either implicitly or explicitly specify the current default
  PRF, so that additional PRF options could be added, if necessary, simply
  by adding new cipher suites.

So the design of the PRF plugabbility was actually invented 1996,
and an integral design element of TLSv1.0 (rfc2246 published in Jan-1999).
It was never conceived to be limited to only TLSv1.2, and might explain
why it is actually pluggable for third parties in Windows XP schannel
(which is TLSv1.0) -- Dan Simons signature on these messages
reads "Cryptographer, Microsoft Corp.".

>
> I don't recall why 12 bytes rather than 16 bytes or 20 was chosen.

It is not unusual when a two group of folks (IPSEC and TLS) sourcing from
the same pool of engineers and experts (IETF) have to do two very
similar decisions (truncating HMAC-SHA-1) within a fairly short time,
end up with the same conclusion.

  http://www.ietf.org/html/rfc2404  Jan-1998  HMAC-SHA-1-96 (for IPSEC)
  http://www.ietf.org/html/rfc2246  Jan-1999  TLSv1.0

The dates vs. rfc-numbers of these two documents look strange:
The dates indicate they were published one year apart, but given
their rfc-numbers, one would intuitively expect their dates to
be just the other way round.

-Martin

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 11 Mar 2011 08:15:04 -0800

> be just the other way round.

TLS 1.0 was held up in process for a long time due to normative
dependency issues
vis-a-vis PKIX.

-Ekr

---

From: Stephen Kent <[email-masked]>
Date: Mon, 14 Mar 2011 11:41:19 -0400

At 8:20 AM +0100 3/11/11, Nikos Mavrogiannopoulos wrote:
>...

I think you lost the context here.  I was explaining why IPsec chose 
to truncate the hash, not TLS.

Steve

---

From: Martin Rex <[email-masked]>
Date: Mon, 14 Mar 2011 18:28:33 +0100 (MET)

> there any other rationale for truncation?

Are you wondering why the HMAC on the TLS data records is is sent
in its full beauty, while the TLS Finished.verify_data is a
truncated output of the PRF (which in the abstract definintion
uses HMAC as the outermost function, but in the case of TLSv1.0
is actually the XOR of two different HMACs over half the secret).

The reason might be about the "secret" input to the HMAC, which in
case of the TLS data records is a derived traffic key, while in
case of the Finished.verify_data, is the "master secret" of the session.

That was, what I assume, the fear, based on the second part of this
message from Dan Simon

and the second part of this message from Hugo Krawczyk

   http://lists.w3.org/Archives/Public/ietf-tls/1996OctDec/0231.html 

Since the TLSv1.0 finished message was defined based on the output
of the TLS PRF (a function with indefinite output length),
defining a truncation was inevitable.  :)

A Finished message of 20 bytes size would have required A(1) for SHA-1
and A(2) for MD5, a 16 bytes size would only have required A(1) from
both, but truncated the P_SHA1() output by 32 bits while leaving
the P_MD5() output in full.  For 12 bytes size, both P_SHA1() and
P_MD5() output is truncated (by 64 and 32 bits respectively), while
still remaining in the "safe truncation" area of "no less than half
the output size of the underlying hash function" (rfc-2104, section-5)
for both MD5 and SHA-1.

Recall how the TLS PRF is defined in TLSv1.0 (rfc-2246):

   http://tools.ietf.org/html/rfc2246#page-12

first as a generic TLS PRF:

       P_hash(secret, seed) = HMAC_hash(secret, A(1) + seed) +
                              HMAC_hash(secret, A(2) + seed) +
                              HMAC_hash(secret, A(3) + seed) + ...

       Where + indicates concatenation.

       A() is defined as:
           A(0) = seed
           A(i) = HMAC_hash(secret, A(i-1))

Then as a specific PRF for use with TLSv1.0 (reused by TLSv1.1)

   http://tools.ietf.org/html/rfc2246#page-12

   S1 and S2 are the two halves of the secret and each is the same
   length. S1 is taken from the first half of the secret, S2 from the
   second half. Their length is created by rounding up the length of the
   overall secret divided by two; thus, if the original secret is an odd
   number of bytes long, the last byte of S1 will be the same as the
   first byte of S2.

       L_S = length in bytes of secret;
       L_S1 = L_S2 = ceil(L_S / 2);

   The secret is partitioned into two halves (with the possibility of
   one shared byte) as described above, S1 taking the first L_S1 bytes
   and S2 the last L_S2 bytes.

   The [TLSv1.0] PRF is then defined as the result of mixing the two
   pseudorandom streams by exclusive-or'ing them together.

       PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR
                                  P_SHA-1(S2, label + seed);

and how it is used in the TLSv1.0 Finished message:

   http://tools.ietf.org/html/rfc2246#page-46

       struct {
           opaque verify_data[12];
       } Finished;

       verify_data
           PRF(master_secret, finished_label, MD5(handshake_messages) +
           SHA-1(handshake_messages)) [0..11];

-Martin

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Mon, 14 Mar 2011 21:30:49 +0100

> defining a truncation was inevitable.  :)

Indeed. It seems the messages you list summarize that design decision
in a nice way. The concerns for the one-wayness of the MAC used lead
to that truncation. That way one-wayness is ensured by discarding data
at the cost of having a weaker MAC. I don't know if the current
construction can be extended for a longer size without implications.

regards,
Nikos

---

From: Martin Rex <[email-masked]>
Date: Mon, 14 Mar 2011 23:49:15 +0100 (MET)

> construction can be extended for a longer size without implications.

The concern with the one-wayness of the hashes was about >SSLv3<
and how it computed its Finished message:

     enum { client(0x434C4E54), server(0x53525652) } Sender;

     struct {
         opaque md5_hash[16];
         opaque sha_hash[20];
     } Finished;

     md5_hash       MD5(master_secret + pad2 +
                        MD5(handshake_messages + Sender +
                            master_secret + pad1));
     sha_hash        SHA(master_secret + pad2 +
                         SHA(handshake_messages + Sender +
                             master_secret + pad1));

     handshake_messages    All of the data from all handshake messages
                           up to but not including this message.  This
                           is only data visible at the handshake layer
                           and does not include record layer headers.

Personally, I'm having difficulties to see how exactly it would leak the
master_secret if MD5 was found to be fully invertable.

The MD5 output is 128 bits = 16 bytes, and the input is *MUCH* larger
than 128 bits.  The master_secret should is 48 bytes alone.  Even if one is
successful at inverting MD5, one can not undo the collisions from
the Finished computation caused by the compression of a much larger
input into a 128 bit output value.

Anyhow, I do see the new Finished computation algorithm in TLSv1.0 as a
sensible change in the TLS design.

-Martin

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Tue, 15 Mar 2011 15:52:13 +0100

Hello,
 I had some discussion with Bart Preneel[0] on the use of a 96-bit
MAC for the Finished messages. His comments were:

"My general advice to IETF was to keep half the bits of the internal
state of the hash function. For HMAC-MD5 this would be 64 bits, for
HMAC-SHA-1 this would be
80 bits and for HMAC-SHA-256 this would be 128 bits.

We now have key recovery attacks on HMAC-MD4 and HMAC-MD5; these
attacks become somewhat harder if the output is truncated (so
I believe that I was right ;-)
NO forgery attacks have been found that exploit the truncation.

In practice, it is better to output the same MAC length for alignment.
64 bits seemed reasonable in 1996.  It turned out that 96 bits gave
better alignment properties than 64 bits.

I believe that a 64-bit MAC is sufficient for most applications, and
a 96-bit MAC is more than enough. I can't see a reason to use a 128-bit MAC."

That said, he suggested against decoupling data authentication from
the security level of the cipher-suites:
"If you are paranoid about security (which you are of you use AES-256)
you should output half the bits of the internal state, so 128 for
SHA-256."

My comments on that is that the discussion on MAC truncation should
apply both to the handshake MAC and the record MAC. If recovering the
master secret was an issue for the handshake MAC, recover of the session
MAC key, should also be an issue, especially since chosen-message
attacks should be considered possible during application data exchange.

To extend it further I think TLS cipher-suites should have a target security
level (e.g. 96 bits, 128 bits) and this should include the TLS Finished
messages MAC as well. Otherwise we end up with combinations of AES-256
and SHA-384 as MAC truncated to 96-bits for the finished messages but
the full 384 bits for the record messages, that IMO does not make much sense.

regards,
Nikos

[0]. http://homes.esat.kuleuven.be/~preneel/

---

From: Marsh Ray <[email-masked]>
Date: Mon, 14 Mar 2011 18:53:11 -0500

> input into a 128 bit output value.

You could accumulate multiple samples, perhaps even with session 
resumption where the Finished message is sent by the server without the 
chance to authenticate the client first.

Normally you even don't get to see the Finished.verify_data without 
breaking the encryption or downgrading to no encryption. But 40-bit 
encryption and "integrity only" connections were fully supported use 
cases back in those days.

If they had really wanted to leverage the 16 or 20 byte bottleneck of 
MD5 and SHA-1, they should have padded the master_secret from 384 to 512 
bits (the input block size) before putting it into the hash function.

- Marsh