Subject: Re: [core] #138: DTLS Clarification

From: Paul Duffy <[email-masked]>
Date: Tue, 03 May 2011 15:40:36 -0400

Channeling Dave McGrew...

What security claims are being made for a CMAC based PRF, and what 
analysis shows that they are valid?   Blockcipher-based constructions 
for extracting a secret key from a DH or ECDH shared secret are 
problematic.  As far as I know, they all rely on the ideal-cipher 
assumption, which is not very realistic, and which is shown to be a bad 
assumption for AES from the recent related key attacks.

Re: the ECC curves and Suite B...yes, Zigbee SE2.0 requires 128-bit 
security, and the ccm-ecc draft reflects a rough consensus of that group.

On 4/12/2011 2:25 AM, Juho Vähä-Herttua wrote:
> On Apr 12, 2011, at 12:56 AM, Eric Rescorla wrote:
>> On Fri, Apr 8, 2011 at 9:19 AM, Robert Moskowitz
>> <[email-masked]>  wrote:
>>> On 04/07/2011 11:34 PM, Carsten Bormann wrote:
>>>
>>> On Apr 8, 2011, at 00:34, Robert Cragie wrote:
>>>
>>> In my experience both SHA-256 and HMAC are not expensive.
>>>
>>> Clearly SHA-256 (and especially HMAC) are not particularly expensive in
>>> execution time when used as the PRF for establishing TLS connections.
>>>
>>> Still, on a highly constrained device, all other things being the same, it
>>> would be preferable not to spend the code space if existing AES encryption
>>> hardware (or even software) can be employed.
>> The problem is that all else isn't equal here: we have a well-understood PRF
>> that is already standardized. Not using that PRF reduces the general
>> applicability
>> of the proposed CCM modes. So, I think before making a change like that it
>> would be better to demonstrate that the SHA-256 code is actually an important
>> contributor to code size
> I'm new on this list, but thought to express some motivation behind this. I implemented Robert's HIP DEX protocol where he had successfully removed cryptographic hash functions, and in the progress mentioned it would be easy to make TLS similar by just using static ECDH or ECDH_anon and CMAC based PRF, possibly even easier than implementing the HIP DEX itself.
>
> I can't speak for anyone else, but I think you're misunderstanding my idea here. Currently draft-mcgrew-tls-aes-ccm-eec-01 defines only ECDSA_ECDHE cipher suites (which are written as ECDHE_ECDSA in the draft by the way, that is completely wrong order) and if one wants to use them they have to have a cryptographic hash function available anyway for signing the ephemeral Diffie-Hellman keys. Changing the PRF to AES based has no point there.
>
> However, using a CMAC based PRF that doesn't have a hash function would be useful as an _optional_ feature in the ECDH_anon and PSK-ECDHE cipher suites, which are apparently not defined yet. Just like the AES-GCM cipher suites are defining two PRFs (SHA-256 and SHA-384 based HMAC), the AES-CCM modes that don't use signing could define an additional PRF for low class devices. I would probably need some data about SHA-256 code space, because I very much agree that it is not expensive in execution time, have to get back to it. But it's clear that already the lookup tables of SHA-256 take some amount of space.
>
> I should probably also contact David McGrew about the same AES-CCM draft related to the elliptic curves requirement. It has the sentence and a list "The ECDHE_ECDSA key exchange is performed as defined in [RFC4492] with the following additional stipulations", where I disagree with most of the additional stipulations. They greatly reduce the general applicability of the proposed CCM modes, as you just said. I'm especially worried about that secp256r1 and secp384r1 MUST be supported, because I have already demonstrated that my wireless sensor node is NOT capable of even performing a secp256r1 handshake. The secp224r1 on the other hand works reasonably well, difference between those two is huge because of the different pseudo-Mersenne primes used in modular reduction.
>
> Only reason why I see the two curves required there is NSA Suite B and maybe something that's happening in the Zigbee group, but that shouldn't affect the generalness of AES-CCM cipher suites in TLS. I remember writing about this to David earlier, but apparently it wasn't changed when the draft was updated. Before this kind of major problems with general applicability are solved, I don't know how relevant it is to fight about PRFs. But I don't think a CMAC PRF in addition to HMAC PRF in some cipher suites would be a bad idea at all. What was the motivation behind making the PRF selectable in TLS 1.2 if you are going to argue against cipher suites selecting a different PRF as an option anyway?
>
>
> Juho
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 3 May 2011 22:04:13 +0200

On May 3, 2011, at 21:40, Paul Duffy wrote:

> What security claims are being made for a CMAC based PRF, and what analysis shows that they are valid?   

I don't think there are being claims made yet.
However, the numbers we have show that it may be useful to have a block-cipher based KDF available in our toolkit from an implementation cost point of view.  That's why we'd like to explore/better understand this space.

> Blockcipher-based constructions for extracting a secret key from a DH or ECDH shared secret are problematic.  As far as I know, they all rely on the ideal-cipher assumption, which is not very realistic, and which is shown to be a bad assumption for AES from the recent related key attacks.

I'm not a cryptographer, so I have to ask: does this invalidate the recommendations made in sp800-108?
Or are you saying that the problem is that "For a given KDF using HMAC or CMAC, the key KI is assumed to be computationally indistinguishable from one that has been selected uniformly at random from the set of all the binary strings with length of |KI|." from section 4 of that document is simply not fulfilled for DH/ECDH shared secrets?  I could see why this would be a bigger problem for CMAC than for HMAC.

> Re: the ECC curves and Suite B...yes, Zigbee SE2.0 requires 128-bit security, and the ccm-ecc draft reflects a rough consensus of that group.

For SE2.0, the complexity is already high enough that having to support SHA256 does not hurt that much (these devices have been called "class 2" devices in recent discussion).
For much simpler devices ("class 1"), we were interested in being able to support very basic PSK schemes.  Those PSKs wouldn't have to have the same properties that DH/ECDH shared secrets have, so CMAC may be more appropriate for this specific case.
For a tentative definition of "class 1" and "class 2", see the below excerpt of the draft LWIG Guidance document (to be submitted as an I-D any day now).

Gruesse, Carsten

2.1.  Classes of Devices

   Despite the overwhelming variety of Internet-connected devices that
   can be envisioned, it may, be worthwhile to have some succinct
   terminology for different classes of constrained devices.  In this
   document, the following class designations may be used as rough
   indications of device capabilities:

       +---------+-----------------------+-------------------------+
       | Name    | data size (e.g., RAM) | code size (e.g., Flash) |
       +---------+-----------------------+-------------------------+
       | Class 1 | ~ 10 KiB              | ~ 100 KiB               |
       |         |                       |                         |
       | Class 2 | ~ 50 KiB              | ~ 250 KiB               |
       +---------+-----------------------+-------------------------+

   As of the writing of this document, these characteristics correspond
   to distinguishable sets of commercially available chips and design
   cores for constrained devices.  While it is expected that the
   boundaries of these classes will move over time, Moore's law tends to
   be less effective in the embedded space than in personal computing
   devices: Gains made available by increases in transistor count and
   density are more likely to be invested in reductions of cost and
   power requirements than into continual increases in computing power.

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Tue, 3 May 2011 23:34:08 +0300

On May 3, 2011, at 10:40 PM, Paul Duffy wrote:
> What security claims are being made for a CMAC based PRF, and what analysis shows that they are valid?   Blockcipher-based constructions for extracting a secret key from a DH or ECDH shared secret are problematic.  As far as I know, they all rely on the ideal-cipher assumption, which is not very realistic, and which is shown to be a bad assumption for AES from the recent related key attacks.

It starts to look like this has been discussed before, partly by the same people. I found this mailing list message from 2009 http://www6.ietf.org/mail-archive/web/tcpm/current/msg04730.html which discusses AES-128-CMAC based KDF. (with McGrew mentioned and Rescorla replying) The people involved might know more details, it seems that the suggestion resulted in KDF_AES_128_CMAC alternative to HMAC in RFC 5926 with very similar motivation to the one presented here.

> Re: the ECC curves and Suite B...yes, Zigbee SE2.0 requires 128-bit security, and the ccm-ecc draft reflects a rough consensus of that group.

I think it is simply wrong that Zigbee SE2.0 security requirements direct the (general) specification of TLS cipher suites. I have had trouble getting Suite B handshakes to run in  real time on some devices, although problems have been mostly CPU bound not so much memory related. Does anyone have data of secp256r1 ECDH performance on target device classes? With well optimized libraries it might still be valid, but as mentioned the difference between secp224r1 and secp256r1 can be very big.

Juho

---

From: Paul Duffy <[email-masked]>
Date: Tue, 03 May 2011 16:48:36 -0400

> I think it is simply wrong that Zigbee SE2.0 security requirements direct the (general) specification of TLS cipher suites.

To be more accurate, Zigbee SE 2 had to have a Suite B compliant 
solution.  This due to US federal regulations re: cyber security 
requirements for critical infrastructure.

> I have had trouble getting Suite B handshakes to run in  real time on some devices, although problems have been mostly CPU bound not so much memory related. Does anyone have data of secp256r1 ECDH performance on target device classes? With well optimized libraries it might still be valid, but as mentioned the difference between secp224r1 and secp256r1 can be very big.
>
>
> Juho
>
>
>