Subject: [TLS] Second Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer Security (TLS) Extensions: Extension Definitions) to Proposed Standard

From: The IESG <[email-masked]>
Date: Fri, 9 Jul 2010 10:21:53 -0700 (PDT)

The IESG has received a request from the Transport Layer Security WG 
(tls) to consider the following document:

- 'Transport Layer Security (TLS) Extensions: Extension Definitions '
   <draft-ietf-tls-rfc4366-bis-09.txt> as a Proposed Standard

The purpose of this Second IETF Last Call is to confirm some changes
made as a result of the first IETF Last Call and subsequent
discussions.  The main issue was handling of the Server name
indications: dealing with multiple names and dealing with session
resumption.  Also a discussion in the security considerations on
why SHA-1 is acceptable for extensions that use it.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2010-07-23. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-tls-rfc4366-bis-09.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=16186&rfc_flag=0

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 9 Jul 2010 11:40:22 -0700

>why SHA-1 is acceptable for extensions that use it.

I support the new wording for both.

--Paul Hoffman, Director
--VPN Consortium

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 12 Jul 2010 00:46:11 +0200

All,

I have submitted a new cached info draft 09
http://tools.ietf.org/html/draft-ietf-tls-cached-info-09

Diff:
http://tools.ietf.org/rfcdiff?url2=draft-ietf-tls-cached-info-09.txt

This draft should reflect the agreed resolutions to all issues discussed on
the list.

The material changes are:
- The use of FNV is removed and replaced with a requirement to use the hash
algorithm (for each cached object) that was used to calculate the Finished
message of the handshake from which the data was cached.

- A hash algorithm identifier is added to the CachedObject structure to
identified the hash algorithm

- The options of the server has been reduced to either provide an empty
extension or to specify specific supported cached objects.

- The security consideration has been updated with respect to the discussion
concerning use of hash algorithms and with respect to cached information
from encrypted handshakes.

---

From: Michael D'Errico <[email-masked]>
Date: Sun, 11 Jul 2010 18:16:20 -0700

Is the goal for cached-info to only work with TLS 1.2 and later?  If
not, then I think there is a problem using the Finished hash function.
In TLS 1.0 and 1.1, both MD5 and SHA-1 are used in the PRF to compute
the verify_data.

That could be fixed by saying that SHA-1 is used for TLS 1.0 and 1.1.

Mike

---

From: Marsh Ray <[email-masked]>
Date: Sun, 11 Jul 2010 20:26:06 -0500

> That could be fixed by saying that SHA-1 is used for TLS 1.0 and 1.1.

Or it could be specified as a length of output from the appropriate PRF 
with a fixed secret.

- Marsh

---

From: Michael D'Errico <[email-masked]>
Date: Sun, 11 Jul 2010 19:02:18 -0700

The PRF requires computation of multiple HMAC's, which seems like
overkill when we just need a unique identifier.

Mike

---

From: Marsh Ray <[email-masked]>
Date: Sun, 11 Jul 2010 22:38:01 -0500

> overkill when we just need a unique identifier.

Maybe, but ${Deity} save us from an insufficiency of overkill! It won't 
actually need to be calculated very often and the function should be in 
the codebase already.

If we had only needed a statistically unique identifier we could have 
stuck with FNV. I thought it had been determined that collision 
resistance was probably a requirement. Then there was the whole 
discussion about which hash function to choose and...

> The Finished message
>    SHALL be calculated over the actual data exchanged in the handshake
>    protocol. That is, the Finished message will be calculated over the
>    hash values of cached information objects and not over the cached
>    information that were omitted from transmission.

Since this hash value is used as a proxy for the actual object, it seems 
like a conservative design would require it to provide the same or 
greater security as the Finished messages themselves. In all current 
specs this implies 24 bytes of output from the PRF.

The actual PRF is stronger for the use of the master_secret as the key 
to the MAC, but it doesn't look like we have any shared secrets 
available to use for that here.

- Marsh

---

From: Michael D'Errico <[email-masked]>
Date: Sun, 11 Jul 2010 21:22:26 -0700

> discussion about which hash function to choose and...

Point taken, but this is only to make cached-info work with TLS 1.0
and 1.1.  If you upgrade to TLS 1.2 you get to use a better hash
function (SHA-256).

Mike

---

From: "Brian Smith" <[email-masked]>
Date: Mon, 12 Jul 2010 00:39:01 -0500

Michael D'Errico
> Point taken, but this is only to make cached-info work with TLS 1.0 and
1.1.  If
> you upgrade to TLS 1.2 you get to use a better hash function (SHA-256).

There should be no problem with requiring TLS 1.2 as the minimum version for
this extension, snap start, and false start. In fact, you could even require
even a brand new TLS version for them at this point in time, and things
would work out just fine.

Regards,
Brian

---

From: Marsh Ray <[email-masked]>
Date: Mon, 12 Jul 2010 15:34:07 -0500

> would work out just fine.

Individually cached info, false start, and snap start seem like 
significant extensions. Since security is not generally composable, even 
if each extension is shown to be secure independently they should also 
be considered in combination. Perhaps it would be simpler 
administratively to bring them under a new TLS version number.

Taken together they seem to be a significant rework of the protocol, 
especially considering the changes to the Finished.verify_data message 
calculation. Snap start on its own is coming close to defining a new 
protocol that (for external reasons) happens to send a TLS-compatible 
Client Hello and runs on TCP port 443.

By loosening various constraints they give additional flexibility to an 
active attacker to modify the handshake, putting additional stress on 
the hash/MAC functions. It may be that verify_data needs lengthening, in 
which case a new protocol version number is probably indicated.

That said, they each have their independent merits and so it may not be 
fair to queue them all behind a new protocol version.

- Marsh

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 12 Jul 2010 23:45:04 +0200

Replying to the whole thread by replying to the original message.

I don't see the benefit of using a hash that is stronger than the hash
function used to generate the finished message.

We only need an identifier. The only security requirement identified after a
very long debate is that we want to make sure that we preserve the security
properties of the Finished message. That we do if we use the same hash
function.

We had a very long debate about this and we finally reached an agreement.
Can we stick with it or do we have to redesign this over and over again?

/Stefan

---

From: Marsh Ray <[email-masked]>
Date: Mon, 12 Jul 2010 18:37:18 -0500

> Can we stick with it or do we have to redesign this over and over again?

We're almost there!

> We only need an identifier.

Note that the Finished message was not designed to be used as an identifier.

> The only security requirement identified after a

One little wrinkle is that it's not just a simple hash function that 
generates the Finished message. It's from the PRF which is a redundant, 
recursive application of HMAC (itself redundant). In order to calculate 
his Finished verify_data, a TLS 1.0 server has to invoke hash functions 
a total of 16 times (AFAICT, might be off a factor of two there). IMHO 
it's the most robust part of TLS by far.

Since HMAC is dynamically keyed by the master secret it eliminates a lot 
of precomputation attacks. Perhaps this is why verify_data was not 
expected to need collision resistance and is only 12 bytes (96 bits) 
long. For some purposes the client and server's Finished messages may 
function as a longer 24 byte value.

So the Finished.verify_data has some very particular properties that are 
impossible to duplicate precisely for the cached_info identifier.

from -09:
>    The hash algorithm used to calculate hash values SHALL be the hash
>    algorithm that was used to generate the Finished message in the
>    handshake exchange from which the hashed information was cached. Hash

For TLS 1.0 and 1.1, would this amount to MD5(data)+SHA-1(data)? That's 
36 bytes.

I think the closest we can come is by using the PRF with a static 
secret. For collision resistance we could go with the total amount of 
verify_data, 24 bytes.

How about something like:

[...]

The hash values SHALL be generated using the same PRF that was used to 
generate the Finished messages in the handshake exchange from which the 
hashed information was cached. Although normally the PRF would be 
initialized from the master_secret, this usage requires a hashing 
algorithm which remains stable across multiple handshakes. To accomplish 
this the fixed label string is simply supplied again in place of the 
secret input for PRF initialization.

[...]

    opaque hash_value<hash_value_length>;

    hash_value
       PRF(fixed_value, cached_info_label, Hash(cached_object_data))
           [0..hash_value_length-1];

    hash_value_length
       Twice the length of a single Finished.verify_data message for
       the current handshake. For all current versions of TLS, this
       is 24 bytes.

    fixed_value and cached_info_label
       The string "cached info" for both.

- Marsh

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 13 Jul 2010 16:27:03 +0200

Marsh,

I would rather fix the issue with the following updated text:

"The hash algorithm used to calculate hash values SHALL be the Finished
message hash algorithm of the handshake exchange from which the hashed
information was cached. The Finished message hash algorithm in this context
is the hash algorithm used to hash handshake messages in the calculation of
verify_data (i.e. Hash(handshake_messages) as defined in section 7.4.9 of
RFC 5246)."

I see no reason to involve the PRF function here. It only adds unnecessary
complexity as far as I can see.

/Stefan

---

From: Marsh Ray <[email-masked]>
Date: Tue, 13 Jul 2010 10:21:23 -0500

> complexity as far as I can see.

Is this intended to be a TLS 1.2-only feature?

If not, how is it to be interpreted for 1.0 and 1.1? They don't use this 
"Hash(handshake_messages)" definition because the unified hash mechanism 
was introduced in 1.2.

To me, the PRF seems simpler because it's consistently defined in each 
TLS version.

- Marsh

---

From: Martin Rex <[email-masked]>
Date: Tue, 13 Jul 2010 17:44:42 +0200 (MEST)

> Is this intended to be a TLS 1.2-only feature?

I do not see a convincing argument to cripple this extension to TLSv1.2,
The idea of TLS extensions is that they can be added to an existing
implementation of TLS, and the installed base of pre-TLSv1.2 is huge.

> "Hash(handshake_messages)" definition because the unified hash mechanism 

Spelling it out for all three existing TLS protocol versions might
avoid confusions and incorrect conclusions.
for TLSv1.0 & TLSv1.1 use SHA-1, for TLSv1.2 use SHA-256.

> To me, the PRF seems simpler because it's consistently defined in each 

How come?

>From the TLS spec:

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

There is neither a secret nor a seed involved in the cache identifier,
and we also do not need an arbitrary length output, so the PRF() looks
like a square peg to a round hole.

What we wanted is a hash over the omitted handshake data, not unlike
what the certificate URL extension does.

The original idea is about caching data from a previous handshake
(which shares some characteristics with TLS session caching) and
caching on one side only (which shares some characteristics
with the TLS session ticket extension).  When used for caching
it is sufficient when the client learns the hash algorithm to use
on receipt of the ServerHello handshake message that creates
the cache entry.

-Martin

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 13 Jul 2010 18:07:33 +0200

How about MUST use SHA-1 for TLS <1.2 and the proposed solution for =< 1.2?

/Stefan

---

From: Marsh Ray <[email-masked]>
Date: Tue, 13 Jul 2010 11:54:35 -0500

On 07/13/2010 11:07 AM, Stefan Santesson wrote:
> How about MUST use SHA-1 for TLS<1.2 and the proposed solution for =<
> 1.2?

Does it meet the requirements? What were the requirements again?

Does it need collision resistance?
If so, SHA-1 is deprecated:
http://csrc.nist.gov/groups/ST/hash/policy.html
 > Federal agencies should stop using SHA-1 for digital signatures,
 > digital time stamping and other applications that require collision
 > resistance as soon as practical, and must use the SHA-2 family of
 > hash functions for these applications after 2010.

If it doesn't need collision resistance, does it need preimage resistance?
If not, FNV is the way to go.
If so, SHA-1 probably works but it is certainly going out of style. If 
you're going to pick a hash function, SHA-256 might be a better choice.

Sorry to be such a curmudeon, but it seems like if we're going to use 
some bit string as a proxy for an object in the handshake I think the 
default assumption needs be that it must not weaken the Finished 
computation. If it wasn't important, we could have used FNV. But we 
decided it was too security critical for FNV, if not for the object 
types defined now, perhaps for other object types that will be defined 
in the future.

I don't think the "it needs to be secure but not that secure, so we need 
more than X but less than Z how about Y" is a good method of selecting 
the hash. If folks feel this usage doesn't require 24 bytes out of the 
PRF like the Finished messages it would be good for someone to post just 
a little bit of quantitative justification. (E.g., ...therefore it needs 
x bits of resistance to ...)

- Marsh

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 13 Jul 2010 19:15:11 +0200

Seems like we will never dig us out of this worm hole :)

I have to admit that I just learned some new stuff. The idea was to not
degrade the security properties of the finished message. I was under the
impression that we would not do that for TLS <1.2 if we use SHA-1.

I guess we are back to square 1.

I'm currently on vacation and may have to rest my case until the meeting in
Maastricht.

/Stefan

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 13 Jul 2010 19:19:48 +0200

> Does it meet the requirements? What were the requirements again?

That is a very good question.  Did we establish that FNV is not good
enough?  Could we add a succinct writeup of the requirements to the
document?  I'm not sure I recall what the long discussions resulted in
any more..  It is difficult to know whether SHA-1 is good enough if we
don't know what it should be good enough for.

/Simon

> I don't think the "it needs to be secure but not that secure, so we
> need more than X but less than Z how about Y" is a good method of
> selecting the hash. If folks feel this usage doesn't require 24 bytes
> out of the PRF like the Finished messages it would be good for someone
> to post just a little bit of quantitative justification. (E.g.,
> ...therefore it needs x bits of resistance to ...)
>
> - Marsh

---

From: Marsh Ray <[email-masked]>
Date: Tue, 13 Jul 2010 12:26:09 -0500

> I do not see a convincing argument to cripple this extension to TLSv1.2,

I agree. This could save lots of overhead in the right circumstances.

> for TLSv1.0&  TLSv1.1 use SHA-1, for TLSv1.2 use SHA-256.

Yes, a valid example never hurts.

>> To me, the PRF seems simpler because it's consistently defined in each

PRF("cached info", "cached info", <as defined for Finished>)
       [0..object_hash_length - 1];

Hard to get much simpler. And it already exists in everyone's 
implementation!

> There is neither a secret nor a seed involved in the cache identifier,

Where that "seed" it's just meaning the third input parameter to PRF().

True there is no secret key for the MAC, this is inherent in the usage.

> like a square peg to a round hole.

It's not a perfect match, but neither is SHA-1. In order to match TLS 
1.0-1.1, we need (SHA-1||MD5). Compared to 36 bytes of lousy hash, that 
arbitrary length output looks pretty good.

> When used for caching

If "the server" proposed that you cache some object using MD5 as the 
identifier, would you want your client to accept it?

TLS 1.0 doesn't use bare SHA-1 anywhere (except where it's due to some 
certificate limitations). So the choice comes down to unkeyed PRF, or 
SHA-256.

Personally, I'd go with SHA-256. I suggested it earlier, but it did not 
get a very enthusiastic response.

- Marsh

---

From: Michael D'Errico <[email-masked]>
Date: Tue, 13 Jul 2010 10:40:10 -0700

> Can we stick with it or do we have to redesign this over and over again?

I'm not sure if you were disagreeing with me, so I'll clarify.  My point
was that this struct:

       struct {
            CachedInformationType type;
            HashAlgorithm hash;
            opaque hash_value<1..255>;
       } CachedObject;

uses HashAlgorithm from RFC 5246.  There is no value for the MD5/SHA-1
combo hash used in TLS 1.0 and 1.1, so we need to pick something that
has an identifier.

Mike

---

From: Simon Josefsson <[email-masked]>
Date: Tue, 13 Jul 2010 19:42:52 +0200

> Hard to get much simpler. And it already exists in everyone's

+1, although consider using EXPORTER-* to comply with RFC 5705:

http://tools.ietf.org/html/rfc5705

/Simon

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 13 Jul 2010 21:19:27 +0200

Michael,

You are absolutely right and I was totally wrong.

In order to preserve the security properties of TLS 1.1 and below we would
have to use a combo which is not compatible with the current syntax.

Using the PRF seems however to have a similar problem. You would have to
indicate which PRF you are using, and if TLS 1.2 PRF is used, what hash
algorithm to use. That doesn't feel trivial either.

/Stefan