Subject: [Dtls-iot] Tracking Review Feedback for the DTLS Profile Document

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 28 Nov 2014 12:56:20 +0100

Hi all,

I went through the review comments and the discussions on the list and
added issues to the tracker. You can find the complete list here:
https://tools.ietf.org/wg/dice/trac/report/1

- Issue#12: Updated text for the PFS section
https://tools.ietf.org/wg/dice/trac/ticket/12

- Issue#16: New section explaining how to deal with constrained servers
(as discussed on the list)
https://tools.ietf.org/wg/dice/trac/ticket/16

- Issue#15: New section giving guidance on timeouts
https://tools.ietf.org/wg/dice/trac/ticket/15

- Issue#13: New section with key length recommendations
https://tools.ietf.org/wg/dice/trac/ticket/13

- Issue#11: Question about applicability of text to TLS
https://tools.ietf.org/wg/dice/trac/ticket/11

- Issue#14: New section about the signature algorithm extension
https://tools.ietf.org/wg/dice/trac/ticket/14

- Issue#17: AES-CCM nonces in DTLS records.
https://tools.ietf.org/wg/dice/trac/ticket/17

- Issue#18: AES-CCM: 12-octet or 13-octet nonce
https://tools.ietf.org/wg/dice/trac/ticket/18

- Issue#19: Issue about AES-CCM vs. AES-GCM
https://tools.ietf.org/wg/dice/trac/ticket/19

I suspect that issue #16 and #11 could trigger some discussion. Issue
#19 does not have a resolution yet.

I thought that the tracker would send mails to the list but it did not
seem so. Instead of copying all the issues to the list take a look at
the tracker.

I am planning to release a new draft snapshot late next week.

Ciao
Hannes

PS: I am also in the process of incorporating various editorial
suggestions. Here is the draft snapshot:
https://github.com/hannestschofenig/tschofenig-ids/blob/master/dice-profile/draft-ietf-dice-profile-06.txt

---

From: Robert Cragie <[email-masked]>
Date: Sat, 29 Nov 2014 17:36:29 +0000

Hi Hannes,

Firstly, I will start by outlining some general considerations in 
respect of the charter and the profile document. I do this to frame some 
of the responses I give later.

Consider the charter text. It is quite general: "focuses on supporting 
the use of DTLS Transport-Layer Security in these [constrained] 
environments". So, what is DTLS (or more generally, TLS) used for in 
constrained environments? Primarily it is used for securing application 
layer communication. However, it is also being considered for network 
access as well due to DTLS' general properties of providing 
authentication via the handshake and a subsequent secure channel. The 
primary reason for this overloading is code re-use through use of a DTLS 
library, which can be used for both application layer and network access 
security.

The current profile draft does not mention DTLS use for network access 
security and there has already been some discussion about narrowing the 
focus for particular communication patterns. I don't see this as a 
problem providing the credentials relating to the cipher suites are 
dealt with in a general way (which they are). It may also help to at 
least acknowledge that there may be a desire to to re-use cipher suites 
and indeed credentials for network access purposes. With regard to the 
communication patterns, it is probably more relevant to consider client 
and server roles as it is possible that once a secure channel has been 
set up, client and server roles may reverse when it comes to application 
layer transactions. Again, I think the document does generally do this 
but it might help to clarify the role of client and server in the 
document and distinguish their roles wrt. authentication and 
authorization and subsequent application layer transactions.

Re-use is a recurring theme when considering constrained environments 
and is behind a lot of the directions taken in developments for 
constrained environments. The corollary of re-use is to not add 
functionality if it can be avoided. For example, the development of the 
CCM cipher suites instead of selecting the GCM cipher suites was 
predicated on:

* The use of CCM for lower layer security (often with accompanying 
hardware accleration) and the ability to re-use it
* Eliminating the need for additional functionality required by GCM, 
namely GF2^128 multiplier

So whilst such a direction does not guarantee re-use in a particular 
implementation, it certainly makes it more likely to be achievable.

With regard to the particular tickets raised:

Regarding the list of possible cipher suites, It is possible that PAKEs 
may be used in the future as well, although these are more likely for 
network access.

This goes some of the way to address the comment I have above re. client 
and server roles as it clearly shows the sensor as the DTLS client but 
acting more as a constrained server with regard to the actual 
application layer transactions.

Some suggested changes:

---
"DTLS added a fragmentation and reassembly mechanism to TLS since each 
DTLS message must fit within a single transport layer datagram, as 
described in Section 4.2.3 of [RFC6347], and the underlying transport 
protocol does not provide such capabilities. Since handshake messages 
are potentially bigger than the maximum record size the mechanism for 
fragmenting a handshake message over a number of records, each of which 
can be transmitted separately, avoids IP fragmentation."

to

"The DTLS handshake protocol adds a fragmentation and reassembly 
mechanism to the TLS handshake protocol since each DTLS record must fit 
within a single transport layer datagram, as described in Section 4.2.3 
of [RFC6347]. Since handshake messages are potentially bigger than the 
maximum record size, the mechanism fragments a handshake message over a 
number of DTLS records, each of which can be transmitted separately."

Rationale: A datagram is the element (PDU) of the transport layer 
therefore there is no concept of fragmenting it further at the transport 
layer. IP fragmentation doesn't really come into it - a transport layer 
PDU could still be fragmented at the IP layer and it would make no 
difference.

---
"To deal with the unreliable message delivery provided by UDP DTLS added 
timeouts and re-transmissions, as described in Section 4.2.4 of 
[RFC6347]. Although the timeout values are implementation specific 
recommendations are provided in Section 4.2.4.1 of [RFC6347] with an 
initial timer value of 1 second and twice the value at each 
retransmission, up to no less than 60 seconds. Due to the nature of some 
radio technologies these values are too aggressive and lead to spurious 
timeouts when messages in flight need longer."

to

"To deal with the unreliable message delivery provided by UDP, DTLS adds 
timeouts and re-transmissions, as described in Section 4.2.4 of 
[RFC6347]. Although the timeout values are implementation specific, 
recommendations are provided in Section 4.2.4.1 of [RFC6347], with an 
initial timer value of 1 second and twice the value at each 
retransmission up to no less than 60 seconds. Due to the nature of some 
radio technologies, these values are too aggressive and lead to spurious 
failures when messages in flight need longer."

Rationale: Mostly grammatical cleanups; changed "timeouts" to "failures" 
as the timeouts themselves aren't spurious but the rate at which they 
occur causes the spurious failure of sending the message by the DTLS 
handshake protocol.

---
"each of which is then mapped on to one or more lower layer PDUs using 
the segmentation and reassembly (SaR)"

to

"each of which is then mapped on to one or more DTLS records using the 
segmentation and reassembly (SaR)"

Rationale: "lower layer PDU" is not really the right term here. It is 
specifically the DTLS record.

---
"In fact, Record Layer messages are never fragmented and MUST fit within 
a single transport layer datagram, whatever be the limit imposed by the 
underlying transport."

to

"In fact, DTLS records are never fragmented and MUST fit within a single 
transport layer datagram."

Rationale: "DTLS record" is the right term. No need to elaborate on limits.

---
Regarding the discussion about concatenated SMS messages, surely this 
applies more to the UDP datagram size as opposed to the DTLS record 
size? Also, it doesn't seem obviously clear that SMS SaR shouldn't be 
used; this is only like using 6LoWPAN fragmentation, which also carries 
an overhead. I don't think we would necessarily say a DTLS record has to 
fit into one 802.15.4 packet?

---
In Section A.2, (1) If the SMS user has some robust SaR mechanism then 
that would be a reason not to use the Concatenated SMS, however DTLS 
really makes no difference as there is no recovery mechanism using DTLS 
handshake protocol. (2) is a valid reason for not using Concatenated 
SMS. I can't see (3) making much of a difference either - reordering 
could occur anyway, you would just handle it at a different layer.

NIST SP 800-57 and NIST SP 800-131 give comprehensive guidance on key 
lengths - it may be worth referencing those documents.

I agree that TLS should be mentioned as well.

I agree with the proposed text.

As mentioned on the mailing list, the CCM cipher suites were based on 
the GCM cipher suites, which has the same issue. Header compression 
(RFC7400) would solve this. It might be an idea to show how this could 
be achieved.

I think this is probably a non-issue. AES-CCM use with DTLS is to secure 
the DTLS record. Many of the AES-CCM hardware implementations are aimed 
at securing layer 2 packets and the ability to re-use the full AES-CCM 
engine is limited. In these cases, it may still be possible to use the 
basic AES-128 block cipher and the construction of the higher layer 
packet may dictate a different approach to how it may be done at layer-2 
anyway. Therefore, the different length nonces for DTLS using a CCM 
cipher suite and the use of CCM at layer 2 is unlikely to be that 
significant even if the layer-2 oriented AES-CCM engine is hardcoded to 
use 13-byte nonces.

Regarding the UTA document generally, I believe it is short-sighted not 
to consider the wider uses of TLS/DTLS beyond web application security. 
For example, EAP-TLS already specifies the use of TLS in a different 
scenario (AAA) and to me there is no reason to also consider TLS/DTLS 
use in constrained environments in IoT-type uses as well, including AAA 
and locally-authorized network access. Had these been considered in the 
UTA document, greater consideration might have been given to the fact 
that CCM cipher suites were developed for constrained environments for 
the re-use reasons given earlier. However, also note the layering 
discussion for Issue #18; in practice, it may not actually be an issue 
for implementations using DTLS/TLS with AES-GCM at the transport layer 
and AES-CCM at layer 2.

Robert

On 28/11/2014 11:56 AM, Hannes Tschofenig wrote:
> _______________________________________________
> dtls-iot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtls-iot

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 29 Nov 2014 20:15:48 +0100

Hi Robert,

thanks for your detailed review.

A few remarks inline:

> authorization and subsequent application layer transactions.

It is indeed good to mention the use of network access authentication
and I should probably do that in the introduction and maybe also in an
example.

I created a ticket for this issue:
http://trac.tools.ietf.org/wg/dice/trac/ticket/22

> may be used in the future as well, although these are more likely for

Are you suggesting to add a PAKE ciphersuite to the list of credential
types that were considered?

I would actually add it as a separate item (in addition to certificates,
raw public keys, and PSKs) since it is qualitatively different.

The problem I see is what exactly should we reference (which is a
question I already have for the earlier suggestion about considering
network access authentication)?

> application layer transactions.

While I hadn't gotten any feedback on the text proposal I indeed think
that adding a few message exchanges helps to clarify the exchanges (and
as you mention, also the roles).

If we add network access authentication then I believe an example would
be appropriate as well.

> could occur anyway, you would just handle it at a different layer.

Thanks for the text proposals. I have incorporated them into the document.

Here is the updated version:
https://github.com/hannestschofenig/tschofenig-ids/blob/master/dice-profile/draft-ietf-dice-profile-06.txt

I have re-read Appendix A.2 and I have to admit that I agree with your
assessment. I have changed the text accordingly and focused on item #2
and the fact that the same mechanism is already applied at the DTLS
layer anyway.

Reason (1) is really only true if DTLS would provide selective
acknowledgements and the ability to re-send fragments. The reordering
aspect (3) and the buffering (4) aren't really issues that are too
different to DTLS either.

> lengths - it may be worth referencing those documents.

I included this reference to http://www.keylength.com/en/ and it does
reference the NIST work and other relevant documents. Of course, it
might be better to just reference the original specifications instead.

What would you prefer? Maybe I could reference a recent ENISA document
that surveys the requirements from various bodies. Here is the link to
that document:
http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report

> I agree that TLS should be mentioned as well.

Thanks. That was my understanding as well. Particularly when we consider
the network access authentication context things get pretty muddy
anyway. For example, in context of EAP-TLS the underlying transport
isn't TCP but, similarly to the SMS context, some other protocol.

> I agree with the proposed text.

Thanks.

> (RFC7400) would solve this. It might be an idea to show how this could

I will take a look at RFC 7400 to figure out how text could look like.

> significant even if the layer-2 oriented AES-CCM engine is hardcoded to

It would be an interesting exercise to figure out whether chip
manufacturers make their AES hardware implementation accessible without
actually using the entire AES-CCM bundle.

In any case, it might be worthwhile to make the recommendation to chip
manufacturers to make their AES hardware implementation accessible to
developers working on security implementations at higher layers.

This case would serve as a nice example for why this is indeed useful
(and maybe not entirely obvious at first sight).

> the re-use reasons given earlier. 

I think having a scope is a good thing for the UTA document. You want to
make the document readable for the target audience and there are subtle
issues when using TLS / DTLS in different context.

On top of that the UTA group has already started to write application
specific guidance document as well (see XMPP document at
draft-ietf-uta-xmpp-04). You would like to at least avoid overlap
between specifications in your own working group....

> However, also note the layering

That's a good point. We could say that the common aspect is the AES and
that might be good enough already.

Ciao
Hannes