Subject: [TLS] Issue 49: Finished.verify length

From: Eric Rescorla <[email-masked]>
Date: Thu, 13 Sep 2007 11:34:53 -0700

Pasi asks:

  Currently Finished.verify_data is always 12 octets. With newer PRFs
  and hashes, more might be useful. Should this depend on the PRF?
  
My take on this is that the 12-octet length is mostly independent
of the PRF. After all, it's already been truncated from either 
MD5 or SHA-1. Is there a good security reason to change this?

-Ekr

_______________________________________________
TLS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/tls

---

From: Mike <[email-masked]>
Date: Thu, 13 Sep 2007 17:18:39 -0700

> MD5 or SHA-1. Is there a good security reason to change this?

Since the Finished message is just the output of the PRF itself,
you can specify however much output you want.  In TLS 1.2, the
default PRF is based on HMAC-SHA-256, so 1 iteration of the PRF
generates 32 bytes.  With the Finished message currently using
only 12 bytes of PRF output, we are just throwing away 20 bytes
that could be utilized.  Therefore, the Finished message could
be increased to 32 bytes without impacting performance.

I am not a security expert, but I do know that 32 bytes is a lot
harder to guess than 12.

Mike

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 13 Sep 2007 21:07:40 -0700

At Thu, 13 Sep 2007 17:18:39 -0700,
> I am not a security expert, but I do know that 32 bytes is a lot

As I recall, the truncation was intended to *increase* security,
because it leaked less information about the MS to an active
attacker.

-Ekr

---

From: Mike <[email-masked]>
Date: Thu, 13 Sep 2007 22:38:14 -0700

> because it leaked less information about the MS to an active

Well, the Finished message follows ChangeCipherSpec, so it is
encrypted when the attacker receives it.  I was thinking about
the other direction where the attacker convinces you (via his
Finished message) that a session has been established, making
you think it's ok to send your sensitive information, which
he can then work offline to try to decode.  His Finished
message would also have to be correctly encrypted and MAC'ed,
so I imagine it would be extremely difficult to forge in any
case....

Mike

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 14 Sep 2007 11:08:53 +0200

>> be increased to 32 bytes without impacting performance.

Note quite true: Indeed, the additional plaintext of the Finished
message would be there at little cost -- however, this would also give
you more data to encrypt and decrypt at the record layer (e.g., more
cipher blocks, assuming a block size of 16 bytes or less).

> because it leaked less information about the MS to an active

I am not convinced that this is a good reason.  Assume that the
adversary tricks the parties into using weak encryption with some
non-ephemeral key exchange, say.  Then not only the verify_data will
be potentially visible to the adversary, but also the record-layer MAC
will be exposed, which can be a lot of additional data (both depending
on the master secret).

But you don't need a very long verify_data.  We also don't need very
long record-layer MACs.  Both are needed only for real-time
authentication, which cannot be attacked after the fact.  (This
is quite different from symmetric encryption, where we generally want
rather long keys for long-term security.)  The MAC cryptographically
ensures that the data has been sent by someone who knows the keys that
the client and the server have agreed upon.  The verify_data is needed
to check that no-one has disturbed the handshake agreement between
client and server, such as by modifiying the list of ciphersuites
offered by the client.  Here we are already trusting that at least the
MAC is secure, and has been properly keyed.

A 12-byte verify_data means that, if an adversary *has* changed the
handshake, there's a probability around 2^-96 that the server won't
notice this from the client's Finished message.  Thus if you have a
total of 2^64 connections (say) being attacked, then there's a
probabilty around 2^-32 that one of the attacks is not detected by the
server.  But if this ever happens and a connection under attack is
accepted by the server, then still we can expect the *client* to
reject the *server's* Finished message (except with probability around
2^-96).

In conclusion, a 12-byte verify_data means *192-bit* security in total
(2*12*8) for Finished verification, since Finished verification
happens twice!  Thus, I don't see a need to change the specification
in this regard.

Bodo

---

From: <[email-masked]>
Date: Fri, 14 Sep 2007 14:40:11 +0300

Bodo Moeller wrote:
> But you don't need a very long verify_data.  We also don't need 
> very long record-layer MACs.  Both are needed only for real-time
> authentication, which cannot be attacked after the fact. 

This is true; but reasonable people seem to have different opinions 
on what exactly is "sufficiently long". For example, RFC 4106 specifies
three different choices for ICV (MAC) length (128/192/256 bits).

My suggestion was *not* to increase the current length, but rather 
to add "agility" for this parameter as well (so that we don't
need to revisit the TLS base spec if, e.g., some future cipher 
suite wants to have all the pieces at 256-bit level).

Best regards,
Pasi

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 14 Sep 2007 14:03:10 +0200

> three different choices for ICV (MAC) length (128/192/256 bits).

IPsec is a different setting since it is not based on streams (which
would be aborted in case of a decryption error).  However, this
reminds me to take DTLS into account, so yes, we possibly might need
long record-layer MACs (just for consistency for DTLS, not for actual
TLS security reasons).

Of course, the Finished message payload (verify_data) still will have
to be processed just once.  (An incorrect record-layer MAC is just a
reason to discard this particular packet in DTLS, but if the
record-layer MAC is correct and the verify_data isn't, then this
is a very bad sign, and the session should be canceled.)

> suite wants to have all the pieces at 256-bit level).

OK, this makes perfect sense!  The question as cited here was,
should the verify_data length depend *on the PRF*.  It shouldn't;
but that doesn't mean we can't allow individual ciphersuites to
specify their preferred verify_data lengths.

Bodo

---

From: Bodo Moeller <[email-masked]>
Date: Fri, 14 Sep 2007 14:13:50 +0200

> is a very bad sign, and the session should be canceled.)

Oops, I forgot to make explicit what follows from this --:

While longer MACs makes sense for protocols such as IPsec and DTLS,
this doesn't mean that we have a similar reason to use longer
verify_data fields with DTLS.

Bodo

---

From: <[email-masked]>
Date: Fri, 14 Sep 2007 15:56:43 +0300

> specify their preferred verify_data lengths.

The PRF depends on the ciphersuite, so having the verify_data length
depend on the PRF (or in other words: specifying the verify_data
length at the same place as the PRF) would be one relative simple
approach. 

(But we could allow different ciphersuites using the same PRF
to use different verify_data lengths as well)

Best regards,
Pasi

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 14 Sep 2007 07:17:04 -0700

At Fri, 14 Sep 2007 11:08:53 +0200,
> will be exposed, which can be a lot of additional data (both depending

Me neither, BTW. I just seem to recall that that was the reason :)

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 14 Sep 2007 07:18:09 -0700

> to use different verify_data lengths as well)

I'm still trying to understand the rationale for why it makes sense
to have a verify_data != 12 bytes. Pasi, could you elaborate?

Thanks,

-Ekr

---

From: <[email-masked]>
Date: Fri, 14 Sep 2007 17:28:24 +0300

> to have a verify_data != 12 bytes. Pasi, could you elaborate?

Again, I'm not suggesting changing it from 12 bytes; just allowing
the agility to change it in the future without new TLS version.

One (somewhat hypothetical) use would be a cipher suite that tries 
to have _everything_ at 256-bit security level (maybe for some 
government approval reasons; not today, but maybe 5 years from now).

You might argue that this kind of security level isn't really
needed, but then again, some people seem to be willing to go
to great lengths to match these "security levels" (just think
of SHA-224.. :-)

Best regards,
Pasi

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 14 Sep 2007 11:36:32 -0700

> to great lengths to match these "security levels" (just think

OK, I see where you're going with this, but I'm not sure it requires
us to do anything now. If we're confronted with such a cipher suite,
we can just have the document Update TLS 1.2, since it would only
be applicable to that new cipher suite. I don't think this needs
a version revision.

Unless you're proposing making this a variable length vector, whcih
seems like a bad idea, since it should be defined in the cipher
suite.
				   
-Ekr

---

From: <[email-masked]>
Date: Sun, 16 Sep 2007 11:36:20 +0300

Eric Rescorla wrote:

> OK, I see where you're going with this, but I'm not sure it
> requires us to do anything now. If we're confronted with such a
> cipher suite, we can just have the document Update TLS 1.2, since
> it would only be applicable to that new cipher suite. I don't
> think this needs a version revision.
> 
> Unless you're proposing making this a variable length vector,
> whcih seems like a bad idea, since it should be defined in the
> cipher suite.

Yes, the length should be defined by the cipher suite, but I'd like
to avoid the "Updates: TLS 1.2" part (in general, ciphersuites
shouldn't need that). And we could avoid that by changing the wire 
encoding to a variable-length vector now, i.e. change

   struct {
       opaque verify_data[12];
   } Finished;

to 

   struct {
       opaque verify_data<0..255>;
   } Finished;

(And say that the verify_data length is 12 octets unless explicitly
specified otherwise by the ciphersuite)

Best regards,
Pasi

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 16 Sep 2007 10:18:34 -0700

> specified otherwise by the ciphersuite)

Well, I don't think changing the encoding is needed. The
verify_data is the only thing in the Finished message so it's
already implicitly encoded. If we want to allow this to change
length without doing an Update, then why not change it to:

   struct {
       opaque verify_data[SecurityParameters.finished_length];
   } Finished;

This leaves a hole but doesn't require changing the wire encoding.

That said, I'd sort of like to discourage changing the length without
good reason, so I'd actually like the first cipher suite to do
this to have to Update: TLS 1.2. However, using the technique above,
we could make this cahnge later without having to impact 
implemenations that didn't support the new cipher suite.

-Ekr

---

From: <[email-masked]>
Date: Mon, 17 Sep 2007 10:03:16 +0300

> This leaves a hole but doesn't require changing the wire encoding.

This would work, too.

> implemenations that didn't support the new cipher suite.

Ciphersuites should be able to do algorithm agility without updating
TLS 1.2, and things like MAC lengths are IMHO part of that agility...

Best regards,
Pasi

---

From: Russ Housley <[email-masked]>
Date: Mon, 17 Sep 2007 09:36:45 -0400

>implemenations that didn't support the new cipher suite.

I like this way forward, but I do not see any reason to wait.  A 
ciphersuite should not need to update the base protocol specification.

Russ