Subject: [TLS] Serious crypto problem fixed by envelope HMAC method instead of currently used prefix

From: "Omirjan Batyrbaev" <[email-masked]>
Date: Sun, 19 Nov 2006 21:26:09 -0500

Hi,

I propose to use envelope method instead of currently used prefix method in
HMAC. The measure is important especially since it was pointed out that the
NULL cipher suites have a real use and since some ciphers are intentionally
weak. With the NULL cipher (or the 40 bits cipher) the current HMAC
construct is exploitable by an active attacker who appends to the message
and substitutes the new message and the newly generated HMAC value for the
original. On the server side the HMAC operation will succeed. Of course it
can be the server message that gets compromised this way. This attack is
well known in the crypto community and is well documented in HAC (Handbook
of Applied Cryptography). The book is available online and I can send you a
page reference if you are not familiar with the attack on the HMAC prefix
method.

I quote TLS 1.2:
"The MAC is generated as:

       HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
                     TLSCompressed.version + TLSCompressed.length +
TLSCompressed.fragment));

   where "+" denotes concatenation."

This is subject to the above mentioned attack.

Instead I propose the HMAC construct which is not prone to the above stated
exploit:

       HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type +
                     TLSCompressed.version + TLSCompressed.length +
TLSCompressed.fragment + MAC_write_secret));

addition of the MAC_write_secret as the last bits of the input to the HMAC
makes it envelope method which is secure against the above stated exploit.

Versions affected TLS 1.2; 1.1; 1.0 and SSL v3, etc.

PS: it makes no difference if the plaintext compressed or not I just quoted
from the draft/specs.

Thanks.
Regards,
Omirjan Batyrbaev, CTO B3 Security Corp.
[email-masked]

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

---

From: [email-masked] (Peter Gutmann)
Date: Mon, 20 Nov 2006 15:48:52 +1300

"Omirjan Batyrbaev" <[email-masked]> writes:

>weak.

To quote one of the endless Police Academy films, "Is all this crap really
necessary?".  We've now got to the point where people are proposing to make
significant, incompatible changes to core portions of TLS just to support
broken, insecure mechanisms that should never be used in the first place.  If
people want to have weak security, let them have weak security, but don't make
the rest of TLS suffer because of it.  Or of you really think this is needed,
put it in a separate profile of TLS so everyone else can stick with the
standard mechanisms.

Peter "little sympathy has been extended" (from the Vax assembler manual)

---

From: EKR <[email-masked]>
Date: Sun, 19 Nov 2006 19:45:45 -0800

> page reference if you are not familiar with the attack on the HMAC prefix

I'm familiar with the appending attack on prefix-based keyed hashes
such as H(Key || Message) but AFAIK, it doesn't apply to HMAC. Indeed,
HMAC was designed in part in response to known problems in a variety
of ad hoc keyed hash MAC constructions. The reason that you can
append in H(Key || Message) is that the digest output includes the
hash state and therefore can be extended. However, because HMAC
has two hash operations, one of which only digests the output of the
first, the state after processing the message is hidden.

Even if there were an appending attack on HMAC, because the length
value is included in the MAC, I don't believe you can apply the
attack in the context of TLS.

-Ekr

---

From: "Omirjan Batyrbaev" <[email-masked]>
Date: Mon, 20 Nov 2006 10:08:35 -0500

Hi, please see inserted:
----- Original Message ----- 
From: "EKR" <[email-masked]>
To: "Omirjan Batyrbaev" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, November 19, 2006 10:45 PM
Subject: Re: [TLS] Serious crypto problem fixed by envelope HMAC method
instead of currently used prefix

> attack in the context of TLS.

I agree that the inclusion of the length value has merit. But only if the
peer checks the length value.
With the proposed envelope method even if the peer does not check the length
value the MAC can not be forged.
Isn't it better to use a more robust envelope method instead? It is a small
change to the spec and implementations.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 20 Nov 2006 07:23:58 -0800

> peer checks the length value.

I'm not sure what you mean by "check" in this context. The length 
value is explicit in the record and is used to find the record
boundary (recall that TCP has no explicit record boundaries). 
The length field from the record is then used to compute the
MAC.

Let's take the case you suggest where we have record R, consisting of

  {
    ContentType = 23 (application_data)
    Version = {3, 1}
    length = 8 (for example)
    data = "testdata"
    MAC = "XXX"
  } 

The MAC here is computed as: 

       HMAC_hash(MAC_write_secret, seq_num + 23 +
                     {3, 1} + 8 + "testdata")

The attacker modifies the application data to be 
"testdataMOREDATA" and mounts the extension attack on the MAC

       HMAC_hash(MAC_write_secret, seq_num + 23 +
                     {3, 1} + 8 + "testdataMOREDATA")

[I'm ignoring the fact that in order to mount extension attacks
you need to include the hash padding as part of the extension]

Note that because this is an extension attack he can't modify
data already hashed so length MUST be 8. He then formats
this into a record.

  {
    ContentType = 23 (application_data)
    Version = {3, 1}
    length = ???
    data = "testdataMOREDATA"
    MAC = "YYY"
  } 
    
Now, the question is: what length value does he use. If he uses
8, then the receiver will interpret "MOREDATA" as part of the MAC
and the MAC won't match. On the other hand, if he uses 16, then
the receiver will compute:

       HMAC_hash(MAC_write_secret, seq_num + 23 +
                     {3, 1} + 16 + "testdataMOREDATA")
                              ^^
                        New length value   

This produces the wrong MAC and thus a MAC error.

There's no need to explicitly check the length field: you just copy
it from the header into the MAC input. 

Theoretically, this could be an issue with a datagram protocol such as
DTLS [again, assuming HMAC was in fact broken, which I'm not convinced
is true], but since more than one DTLS record can be packed into a
transport-layer datagram, you use the length field to decode the
records there as well, so I don't see that there's a problem.

> change to the spec and implementations.

Again, I believe that the claim that HMAC is susceptible to this
attack is incorrect. I understand how to mount appending attacks
on simple prefix-type keyed hashes but I don't see how this applies
to HMAC. Please describe in detail how you believe you would
mount this attack with HMAC.

-Ekr

---

From: Bodo Moeller <[email-masked]>
Date: Mon, 20 Nov 2006 16:24:07 +0100

> change to the spec and implementations.

TLS uses HMAC, which *is* a "robust envelope method", and is not
subject to the attacks that you mentioned -- so there's no need to
change any of this in TLS.  Your attacks would apply to a plain SHA-1
of the key followed by the message, but that's not what HMAC does:

    http://www-cse.ucsd.edu/~mihir/papers/hmac.html
    http://en.wikipedia.org/wiki/HMAC

Bodo

---

From: "Omirjan Batyrbaev" <[email-masked]>
Date: Mon, 20 Nov 2006 16:29:52 -0500

Hi Eric,
I've seen the TLS reference to the "Request for Comments: 2104" so this is
(probably) the HMAC used in TLS. Quoting to be on the same page:
"To compute HMAC over the data `text' we perform
                    H(K XOR opad, H(K XOR ipad, text))"

However, this RFC was produced in 1997 but SSL was from 1995 (or earlier?).
Do you know which HMAC they used in say SSL v3 and v2 (which is still an
option in my browser, etc.)?

-Best,
Omirjan
----- Original Message ----- 
From: "Eric Rescorla" <[email-masked]>
To: "Omirjan Batyrbaev" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, November 20, 2006 10:23 AM
Subject: Re: [TLS] Serious crypto problem fixed by envelope HMAC method

> >> > I propose to use envelope method instead of currently used prefix
method
> > in
> >> > HMAC. The measure is important especially since it was pointed out
that
> > the
> >> > and substitutes the new message and the newly generated HMAC value
for
> > the
> >> > original. On the server side the HMAC operation will succeed. Of
course
> > it

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 20 Nov 2006 13:42:40 -0800

> option in my browser, etc.)?

SSLv3 used a variant of the original HMAC (pre-2104). IIRC, SSLv2
didn't use HMAC and *did* have an extension attack, but that's
hardly our problem at this point.

-Ekr

---

From: Casey Marshall <[email-masked]>
Date: Mon, 20 Nov 2006 13:51:36 -0800

> option in my browser, etc.)?

In SSLv3:

  hash(MAC_write_secret, pad_2 +
       hash(MAC_write_secret + pad_1 + data));

For hash == MD5 or SHA-1, and pad_1 is 0x36 48 or 40 times (depending  
on the hash) and pad_2 is 0x5c 48 or 40 times. This is all available  
in Netscape's document describing SSLv3. I don't know what SSLv2  
used, but v2 has more problems than the MAC. I'm also fairly certain  
that the HMAC construction long predated the RFC describing it.

It's pointless to start suggesting revising SSLv3, because they did  
that already, and TLSv1 was the result. If you are paranoid  
(unnecessarily, IMO) you can disable SSLv3 in your browser. Disabling  
SSLv2 is probably a good idea, unless you are using some backwards  
service that still only supports v2.

Cheers.

---

From: "Omirjan Batyrbaev" <[email-masked]>
Date: Mon, 20 Nov 2006 17:51:15 -0500

>The length
> value is explicit in the record and is used to find the >record
> boundary (recall that TCP has no explicit record >boundaries).

Slightly OT: when client/server writes the TLS fragment or/and messages the
TCP then puts it in one TCP packet? So it becomes one TCP packet per one TLS
fragment. Is this what happens in the real world implementations?

-Omirjan

---

From: "Jan Mikkelsen" <[email-masked]>
Date: Tue, 21 Nov 2006 10:12:47 +1100

> fragment. Is this what happens in the real world implementations?

No.

TCP provides a reliable byte stream service.  As stated in the message you
are responding to, TCP has no explicit record boundaries.  Specifically, an
implementor of any TCP based service (including TLS) should not assume that
recipient reads will match sender writes.

What happens with TCP packets depends on many variables. These are
irrelevant to TLS and are hidden by a TCP implementation.

TLS has a record layer to provide a record abstraction on top of TCP.

Regards,

Jan Mikkelsen

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Mon, 20 Nov 2006 18:14:33 -0500

> fragment. Is this what happens in the real world implementations?

TCP offers no guarantees on that; you cannot predict what will happen.  It
can even change if TCP has to retransmit something.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: Mike <[email-masked]>
Date: Mon, 20 Nov 2006 16:27:34 -0800

> fragment. Is this what happens in the real world implementations?

A TLS fragment can be up to 16383 bytes, plus some extra data.  A TCP
packet is usually around 1500 bytes or less, so you will normally see
a fair amount of fragmentation.

Mike

---

From: "Omirjan Batyrbaev" <[email-masked]>
Date: Mon, 20 Nov 2006 21:12:03 -0500

Then I apologies for a premature alert. When I was browsing the TLS RFC I've
got a wrong impression that "HMAC" in the example I originally quoted meant
a MD5, SHA-1 or a similar hash function.

PS: did the vendors fix the SSLv2 extension attack problem?

PPS: can ekr give me a URL to his web page please?

---

From: "Omirjan Batyrbaev" <[email-masked]>
Date: Mon, 27 Nov 2006 14:26:21 -0500

> hardly our problem at this point.

But does SSL v2 has the lenth field protection (as we discussed) against an
extension attack? Can somebody send me the function used in SSL v2?
-Omirjan