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

From: Robert Moskowitz <[email-masked]>
Date: Tue, 05 Apr 2011 12:42:56 +0200

I have a question about DTLS-PSK per:

draft-mcgrew-tls-aes-ccm-01.txt

In sec 4, PSK Based AES-CCM Cipher Suites, it states:

    These ciphersuites make use of the default TLS 1.2 Pseudorandom
    Function (PRF), which uses HMAC with the SHA-256 hash function.  The
    PSK and PSK-DHE key exchange is performed as defined in [RFC5487].

Does DTLS-PSK also use HMAC for the PRF?  And if so, where is the PRF 
used?  If we can't dodge this, we have a major hit on both code space 
and processing costs.

As a point of information, in HIP-DEX, I have designed the PRF to use 
CMAC.  This is NOT simple.  There are some security boundaries up have 
to work with to use CMAC for a PRF; I have had some guidance on this, 
but invite more review.

If we MUST use a PRF in DTLS-PSK we should really work with the TLS wg 
to get something other than an HMAC/SHA-256 based PRF.  But it might be 
that DTLS as already dealt with this, and I am just missing the 
pertinent references.

On 03/31/2011 12:17 AM, core issue tracker wrote:
> #138: DTLS Clarification
>
>   From the Prague coap-05 presentation:
>
>   Currently unclear if coap-05 is specifying IPSec or DTLS, and in what
>   modes.
>
>   This ticket is to clarify that DTLS is the must-implement security
>   mechanism for CoAP.
>
>   - SharedKey (PSK), MultiKey (PSK) and Certificate mode are related to DTLS
>
>   - Pre-shared key mode is must implement
>
>   - NoSec mode (thus no DTLS) may be used in combination with IPSec, L2
>   encryption or cases where security really isn’t needed
>
>   - IPSec section still needed, but to be moved and edited appropriately.
>

-- 
Robert Moskowitz
Senior Technical Director
ICSA Labs, an Independent Division of Verizon Business Systems
W:248-968-9809
F:248-968-2824
VoIP:248-291-0713
E:[email-masked]

There's no limit to what can be accomplished if it doesn't matter who 
gets the credit

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 5 Apr 2011 13:17:42 +0200

On Apr 5, 2011, at 12:42, Robert Moskowitz wrote:

> Does DTLS-PSK also use HMAC for the PRF?  And if so, where is the PRF used?  If we can't dodge this, we have a major hit on both code space and processing costs.

In TLS 1.2, the ciphersuite specifies the PRF.

draft-mcgrew-tls-aes-ccm-01.txt indeed specifies the default TLS 1.2 Pseudorandom Function, which uses HMAC with SHA-256.

Of course, this also means yet another ciphersuite could be specified that is similar to TLS_PSK_WITH_AES_256_CCM_8 but uses a different PRF that is simpler to implement on chips with AES hardware.  The obvious question is whether this can be done on a timeline that would still make it relevant for the MTI (mandatory to implement) security scheme of CoAP, and whether this introduction of new crypto will delay the overall progress of CoAP.

Gruesse, Carsten

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 05 Apr 2011 14:13:04 +0200

> Of course, this also means yet another ciphersuite could be specified that is similar to TLS_PSK_WITH_AES_256_CCM_8 but uses a different PRF that is simpler to implement on chips with AES hardware.…

I will bring this up with David, as I am currently asking him other 
related questions.

If our timeline is for Quebec City, there is time to 'add' a CMAC PRF.  
You want to look at all the places you do things like this and see if 
you are truly minimizing things or not.  You point out the 'cost' of the 
large number library, then miss still needing HMAC and SHA-256.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 7 Apr 2011 13:08:15 -0700

Bob,

Do you have some measurements that show that HMAC and SHA-256 are that
expensive?

HMAC, at least, is a very small number of lines of code. I'd like to
see some measurements
for SHA-256 before we get all ramped up to change PRFs.

-Ekr

On Tue, Apr 5, 2011 at 5:13 AM, Robert Moskowitz
<[email-masked]> wrote:
>>> used?  If we can't dodge this, we have a major hit on both code space and
>>> processing costs.
>>
>> draft-mcgrew-tls-aes-ccm-01.txt indeed specifies the default TLS 1.2
>> Pseudorandom Function, which uses HMAC with SHA-256.
>>
>> Of course, this also means yet another ciphersuite could be specified that
>> is similar to TLS_PSK_WITH_AES_256_CCM_8 but uses a different PRF that is
>> simpler to implement on chips with AES hardware.  The obvious question is
>> whether this can be done on a timeline that would still make it relevant for
>> the MTI (mandatory to implement) security scheme of CoAP, and whether this
>> introduction of new crypto will delay the overall progress of CoAP.
>
> I will bring this up with David, as I am currently asking him other related
> questions.
>
> If our timeline is for Quebec City, there is time to 'add' a CMAC PRF.  You
> want to look at all the places you do things like this and see if you are
> truly minimizing things or not.  You point out the 'cost' of the large
> number library, then miss still needing HMAC and SHA-256.
>
>
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>

---

From: Robert Cragie <[email-masked]>
Date: Thu, 7 Apr 2011 23:34:09 +0100

In my experience both SHA-256 and HMAC are not expensive. We are using them
successfully on resource constrained devices using the TLS with AES-CCM
cipher suites.

Robert

On 7 Apr 2011 21:08, "Eric Rescorla" <[email-masked]> wrote:

Bob,

-Ekr

On Tue, Apr 5, 2011 at 5:13 AM, Robert Moskowitz
<[email-masked]> wrote:
> On 04/05/2011...

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 8 Apr 2011 05:34:24 +0200

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. So I do believe it is worth exploring an AES-based PRF, *if* it can provide the same security characteristics.

Gruesse, Carsten

---

From: "Garcia Morchon, Oscar" <[email-masked]>
Date: Fri, 8 Apr 2011 09:12:43 +0200

Hey,

SHA-256 is not big, but for very small devices,
one might try to find something smaller. May be this
document (section 4) is useful:

http://csrc.nist.gov/publications/nistpubs/800-108/sp800-108.pdf

regards,

        Oscar.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: Friday 8 April 2011 5:34
To: [email-masked]
Cc: [email-masked]
Subject: Re: [core] #138: DTLS Clarification

Gruesse, Carsten

The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 8 Apr 2011 12:29:22 +0200

> http://csrc.nist.gov/publications/nistpubs/800-108/sp800-108.pdf

That indeed points to SP800-38B (CMAC).
I don't know how to properly operate CMAC as a PRF for key derivation with TLS's 48-byte (pre-)master secrets while using AES-128 (which uses only 16-byte keys) -- what to do with the remaining 32 bytes of secret?  That's why I think this needs help from cryptographers...

Gruesse, Carsten

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 08 Apr 2011 12:19:08 -0400

> 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. So…

I will point out that in 802.15.4 where AES-CCM hardware is present and 
AES-CMAC is available, the trend is to use it an avoid the code cost for 
SHA-whatever.  And in CPU cost you are comparing a software 
implementation of SHA-whatever and HMAC with a hardware optimized CMAC.

We are suppose to be looking at everything we do and what is truly 
needed for the application and what is 'supporting functions'  And how 
the supporting functions add value with little cost.  Remember there is 
concerted effort in IEEE in 11073 for medical and (I think) 11074 for 
energy to NOT use any of this IP and HTTP cruft.

Further BTLE is now bringing their MAC into 6lowpan.  Now they may claim 
to have completely solved (for their systems) the security challenge...  
And it will be interesting what 802.11LE will be like next year.

The 'cost' in CPU and battery for the PRF should be small as it should 
be infrequent (rekeying only?).  It is a code size issue.  We have CMAC 
and we have CMAC PRFs.

---

From: Robert Moskowitz <[email-masked]>
Date: Fri, 08 Apr 2011 12:26:47 -0400

> I don't know how to properly operate CMAC as a PRF for key derivation with TLS's 48-byte (pre-)master secrets while using AES-128 (which uses only 16-byte keys) -- what to do with the remaining 32…

There is RFC 4615.

I do have a note here from Hugo Krawczyk somewhere that some 
improvements can be made on this.  I followed Hugo's recommendation in 
the PRF in HIP-DEX.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 11 Apr 2011 14:56:54 -0700

On Fri, Apr 8, 2011 at 9:19 AM, Robert Moskowitz
<[email-masked]> wrote:
> 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

-Ekr

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Tue, 12 Apr 2011 09:25:07 +0300

> would be better to demonstrate that the SHA-256 code is actually an important

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

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Tue, 12 Apr 2011 09:41:30 +0300

On Apr 12, 2011, at 9:25 AM, Juho Vähä-Herttua wrote:
> 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)

Sorry, you can ignore that part, ECDHE_ECDSA is the correct order. It is the PSK_DHE in draft-mcgrew-tls-aes-ccm-01 that is in the wrong order (compared with RFC 4279) and I got confused here looking at them both. In TLS notation the key exchange is always first and additional parameters (signature, PSK) are after.

Juho

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 12 Apr 2011 08:33:14 -0400

A team of students at Aalto University have implemented HIP DEX

http://code.google.com/p/hip-dex/source/checkout

to analyze its performance.  They have submitted a paper to

http://www.ieee-pimrc.org/

I expect at a later date this paper can be made available (after the 
conference, probably).  Meanwhile I am making some improvements to the 
protocol based on their findings.  Watch for a new draft.

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 12 Apr 2011 16:38:36 +0200

On Apr 11, 2011, at 23:56, Eric Rescorla wrote:

> So, I think before making a change like that it

I can't claim really solid numbers here, but a quick check here at TZI produced the following sizes:

Processor	Code+Constants (bytes)
8051		6337			(A)
MSP430		3642			(A)
ATmega		3472			(B)
x86-64		2340			(A)

Where (A) is a generic C implementation of SHA-256 and (B) is code optimized for the specific processor family; all of these were compiled with optimizer settings optimizing for code size.
Clearly, it is possible to generate more compact implementations, but the order of magnitude is certainly right.

For what we have been calling class-2 devices (~50 KiB data/~250 KiB code), there is no problem, as Robert has indicated.  For class-1 devices (~10/~100), this *is* a problem (there is more stuff competing for these 48 to 128 KiB).

I strongly believe the MTI (mandatory-to-implement) scheme needs to address class-1 devices or it will be ignored, so I think spending some time to look at alternative key derivation functions is well-justified.
(Of course, it is not a foregone conclusion that a good one will pop up.)

Gruesse. Carsten

---

From: Robert Moskowitz <[email-masked]>
Date: Tue, 12 Apr 2011 11:18:39 -0400

> (Of course, it is not a foregone conclusion that a good one will pop up.)

Am I correct that DTLS-PSK only needs PRF for key refresh?

Key refresh pretty much has to be a part of a good KMP.  HIP does this 
in 1 round trip using the UPDATE packets (unless PFS is needed, but then 
you would not be using HIP DEX, rather HIP BEX, IKEv2, etc.).

TLS-PSK SHOULD be able to function as other security encapsulating 
protocols to instruct the KMP to produce fresh keys and not be manditory 
to do it internally.

Plus a lot of class-1 devices will NOT be sending more than 2^61 
datagrams over their lifetime thus perhaps never issuing a key refresh.  
In HIP DEX the key refresh is basically a call into the basic 
machinery.  It is needed for the initial keying and is there if rekeying 
is ever needed.

Thus two approaches, both should be included:  TLS-PSK MAY use an 
external key refresh mechanism and TLS-AES-CCM MAY use a CMAC PRF.

BTW, the PRF in HIP DEX is based on RFC 4615 with an improvement 
recommended by Hugo Krawczyk.  Which is to use a nonce for the key not ZERO.

---

From: Robert Cragie <[email-masked]>
Date: Tue, 12 Apr 2011 17:08:02 +0100

So some figures I have:

     Module                             ro code  ro data  rw data
     sha256.o                             1 364       41       64 IAR 
compiler, ARM7TDMI, thumb mode
     sha256.o                             1 376       45       64 IAR 
compiler, ARM Cortex M3

This is code written purely in C so could no doubt be optimised in 
assembler. As already mentioned, HMAC on top is trivial. CMAC will also 
require subkey and MAC generation code on top of the block cipher 
invocation.

SHA-256 becomes a fundamental building block for ECDHE_ECDSA cipher 
suites as we also used for signature generation. We are actually trying 
to deprecate SHA-1, which seems to persist in certain places (x509 for 
example).

Robert

---

From: Juho Vähä-Herttua <[email-masked]>
Date: Tue, 12 Apr 2011 19:41:09 +0300

> Am I correct that DTLS-PSK only needs PRF for key refresh?

Short answer: Yes.
Long answer:

TLS (and DTLS)  PSK suites generate "master secret" using PRF, shared secret, client nonce and server nonce. The shared secret includes the PSK and optionally RSA/DH/ECDH handshake. The actual keys are then generated from this "master secret" by using the same PRF, client nonce and server nonce. If the "master secret" is cached it can be reused in following handshakes with different nonces. (and therefore it generates different keys)

> Key refresh pretty much has to be a part of a good KMP.  HIP does this in 1 round trip using the UPDATE packets (unless PFS is needed, but then you would not be using HIP DEX, rather HIP BEX, IKEv2, etc.).

TLS has actually two ways to refresh keys, either by caching the session and doing a new TLS handshake, or by performing renegotiation. There are several things in renegotiation which make it a bit complicated, personally I might just stick with caching the session info and doing a new handshake. In both cases it requires a 4-way handshake though.

> TLS-PSK SHOULD be able to function as other security encapsulating protocols to instruct the KMP to produce fresh keys and not be manditory to do it internally.
> 
> Plus a lot of class-1 devices will NOT be sending more than 2^61 datagrams over their lifetime thus perhaps never issuing a key refresh.  In HIP DEX the key refresh is basically a call into the basic machinery.  It is needed for the initial keying and is there if rekeying is ever needed.
> 
> Thus two approaches, both should be included:  TLS-PSK MAY use an external key refresh mechanism and TLS-AES-CCM MAY use a CMAC PRF.
> 
> BTW, the PRF in HIP DEX is based on RFC 4615 with an improvement recommended by Hugo Krawczyk.  Which is to use a nonce for the key not ZERO.

This is actually a bit misleading, the PRF in HIP DEX is not really based on RFC 4615. It is almost identical with RFC 5869 (by Hugo Krawczyk) simply replacing the HMAC with CMAC. In HIP DEX the nonce is defined as the block size of CMAC and in case of AES-128 the block size is the same as key length, so RFC 4615 is not really relevant there.

Juho

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 Apr 2011 15:25:30 -0700

On Tue, Apr 12, 2011 at 8:18 AM, Robert Moskowitz
<[email-masked]> wrote:
>> Where (A) is a generic C implementation of SHA-256 and (B) is code
>> optimized for the specific processor family; all of these were compiled with
>> optimizer settings optimizing for code size.
>> For what we have been calling class-2 devices (~50 KiB data/~250 KiB
>> code), there is no problem, as Robert has indicated.  For class-1 devices
>> (~10/~100), this *is* a problem (there is more stuff competing for these 48
>> to 128 KiB).
>>
>> I strongly believe the MTI (mandatory-to-implement) scheme needs to
>> address class-1 devices or it will be ignored, so I think spending some time
>> to look at alternative key derivation functions is well-justified.

I don't know what you mean by "key refresh" here. DTLS-PSK generatess a new
set of traffic keys based on the  master secret for each association.

> TLS-PSK SHOULD be able to function as other security encapsulating protocols
> to instruct the KMP to produce fresh keys and not be manditory to do it
> internally.

I don't understand "internally". TLS has an integrated key management
protocol. There's
no notion of an external KMP.

-Ekr

---

From: "core issue tracker" <[email-masked]>
Date: Thu, 28 Apr 2011 11:39:42 -0000

#138: DTLS Clarification

Changes (by zach@…):

  * status:  new => closed
  * resolution:  => fixed

Comment:

 Done in coap-06.

-- 
----------------------------------+-----------------------------------------
 Reporter:  zach@…                |        Owner:  zach@…            
     Type:  protocol enhancement  |       Status:  closed            
 Priority:  minor                 |    Milestone:                    
Component:  coap                  |      Version:                    
 Severity:  -                     |   Resolution:  fixed             
 Keywords:                        |  
----------------------------------+-----------------------------------------

Ticket URL: <http://wiki.tools.ietf.org/wg/core/trac/ticket/138#comment:1>
core <http://tools.ietf.org/core/>