Subject: [Dtls-iot] WGLC for DTLS Profile draft: 11/11/2014 - 11/25/2014

From: Dorothy Gellert <[email-masked]>
Date: Tue, 11 Nov 2014 13:18:21 -1000

Dear WG,

As discussed during the Dice WG meeting at IETF#91, this email starts a WGLC  for our DTLS profile draft:

https://tools.ietf.org/html/draft-ietf-dice-profile-05

Please review.  This WGLC will end on Tuesday, November 25, 2014.

Best Regards,
Dorothy and Zach

---

From: Dorothy Gellert <[email-masked]>
Date: Tue, 11 Nov 2014 14:17:36 -1000

Dear WG,

Based on Carsten’s comment at the Dice WG F2F, we will run the WGLC for 3 weeks, to give folks a chance to get home from the meeting. 
So, with this change in mind,the WGLC for the DTLS profile draft will conclude on December 2nd, 2014.

Apologies for the oversight.
Dorothy

---

From: Russ Housley <[email-masked]>
Date: Tue, 11 Nov 2014 19:37:34 -0500

DICE document requires TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8.  I have no problem with that choice.  It makes a lot of sense for small devices.

The HTTPbis is also taking a path that requires an AEAD algorithm.  It would be really nice if the two groups came to a place that allowed interoperability, but HTTPbis seems to be on a path for AES-GCM.  AES-CCM is better for small devices.

It seems to me that the two groups should talk to each other before WG Last Call is over.

Russ

---

From: Zach Shelby <[email-masked]>
Date: Wed, 12 Nov 2014 00:54:54 +0000

Russ,

Thanks for bringing this up, I absolutely agree. HTTP 2.0 will also be applicable to some classes of constrained devices, and even in those cases CCM is a better choice due to hardware support. Ideally we would want to see HTTPbis define support for *either* GCM or CCM. I would also point out that CoAP already requires the support of TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 with its DTLS binding.

We'll make a point to reach out to the HTTPbis WG.

Zach

On Nov 11, 2014, at 2:37 PM, Russ Housley <[email-masked]> wrote:

> _______________________________________________
> dtls-iot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtls-iot
>

Zach Shelby
Director of Technical Marketing
ARM Internet of Things BU
www.arm.com
US: +1 (408) 203-9434
Finland: +358 407796297
Skype: zdshelby
LinkedIn: fi.linkedin.com/in/zachshelby/

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2548782

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 11 Nov 2014 21:24:26 -1000

Also, they are talking about their preferred algorithm being “mandatory to deploy”.
This means a TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 HTTP/2 would not qualify as real HTTP/2.
(There is some pushback from the WG as well, e.g. for Russian sites that are legally required to use GOST cipher suites.)

Grüße, Carsten

> On 11 Nov 2014, at 14:37, Russ Housley <[email-masked]> wrote:
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 14 Nov 2014 20:57:53 +0100

Hi Russ,

thanks for bringing this up.

The ciphersuites selected for the DTLS profile draft have been heavily
influenced by the work done in the CORE working group.

We have been telling silicon partners that they should put AES-CCM into
their chips and they have indeed following that recommendation.

I believe, however, that this is not a problem as such since the UTA
work really has a different scope - they focus on Web/Messaging/Email
rather than the IoT space. I sent a mail to their list to request the
title to be adjusted.

Ciao
Hannes

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 14 Nov 2014 10:01:08 -1000

> rather than the IoT space. I sent a mail to their list to request the

This is not about UTA, but HTTP/2 (httpbis WG).

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 14 Nov 2014 21:05:20 +0100

The comment Russ raised during the SAAG was about the WGLC of
http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-07 in UTA and their
choice of the cryptographic algorithms.

I read through draft-ietf-uta-tls-bcp when working on the DTLS profile
draft and was fully aware of the misalignment but assumed it was caused
by the different scope.

Ciao
Hannes

---

From: Russ Housley <[email-masked]>
Date: Fri, 14 Nov 2014 15:05:41 -0500

Hannes:

I understand the hardware situation.  That was the point I was trying to make when I said, "It makes a lot of sense for small devices."  Please explain this situation in HTTPbis.  My hope is that they will join you by either picking AES-CCM or picking both AES-GCM and AES-CCM.

Russ

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 14 Nov 2014 22:55:16 +0000

Hi Russ,

<no-hats>

On 14/11/14 20:05, Russ Housley wrote:
> Hannes:
> 
> I understand the hardware situation.  That was the point I was trying
> to make when I said, "It makes a lot of sense for small devices."
> Please explain this situation in HTTPbis.  My hope is that they will
> join you by either picking AES-CCM or picking both AES-GCM and
> AES-CCM.

I'm not getting why we see having two AES modes as advantageous.

I get that there are devices out there with CCM and that that's
unlikely to go away, and that the same is true for GCM, but that
seems like a thing that's a pain to work around.

Or am I over interpreting "hope" there?

</no-hats>

S.

>> The ciphersuites selected for the DTLS profile draft have been
>> heavily influenced by the work done in the CORE working group.
>> 
>> We have been telling silicon partners that they should put AES-CCM
>> into their chips and they have indeed following that
>> recommendation.
>> 
>> I believe, however, that this is not a problem as such since the
>> UTA work really has a different scope - they focus on
>> Web/Messaging/Email rather than the IoT space. I sent a mail to
>> their list to request the title to be adjusted.
>> 
>> Ciao Hannes
>> 
>>> DICE document requires TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8.  I
>>> have no problem with that choice.  It makes a lot of sense for
>>> small devices.
>>> 
>>> The HTTPbis is also taking a path that requires an AEAD
>>> algorithm.  It would be really nice if the two groups came to a
>>> place that allowed interoperability, but HTTPbis seems to be on a
>>> path for AES-GCM.  AES-CCM is better for small devices.
>>> 
> _______________________________________________ dtls-iot mailing
> list [email-masked]

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Sat, 15 Nov 2014 03:02:40 +0000

HI Hannes

Can you clarify if the silicon vendors are implementing AES-CCM or plain AES in hardware (i.e. AES-ECB) with the CCM mode implemented in software?
If it is the former, do you know if they are flexible enough to implement AES-CCM with different nonce lengths. The reason I ask is because AES-CCM in IEEE 802.15.4 uses a nonce length of 13-octets while DTLS uses 12-octets. I have heard of some15.4 chips that hard-code (in hardware) the 13-octet nonce length making it useless for DTLS.

Regards
Sandeep

> -----Original Message-----
> From: dtls-iot [mailto:[email-masked]] On Behalf Of Hannes
> Tschofenig
> Sent: Friday, November 14, 2014 9:58 AM
> To: Russ Housley; [email-masked]
> Cc: Dorothy Gellert; Zach Shelby
> Subject: Re: [Dtls-iot] WGLC for DTLS Profile draft: 11/11/2014 - 11/25/2014
>
> Hi Russ,
>
> We have been telling silicon partners that they should put AES-CCM into their
> chips and they have indeed following that recommendation.
>
> I believe, however, that this is not a problem as such since the UTA work
> really has a different scope - they focus on Web/Messaging/Email rather
> than the IoT space. I sent a mail to their list to request the title to be
> adjusted.
>
> Ciao
> Hannes
>
> have no problem with that choice.  It makes a lot of sense for small devices.
> >
> > The HTTPbis is also taking a path that requires an AEAD algorithm.  It would
> be really nice if the two groups came to a place that allowed interoperability,
> but HTTPbis seems to be on a path for AES-GCM.  AES-CCM is better for small
> devices.
> >

________________________________
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: Rene Hummen <[email-masked]>
Date: Sat, 15 Nov 2014 07:05:24 +0000

Besides the fact that I would have liked this draft to consider both a constrained DTLS client and a constrained DTLS server, I have two main comments:

1) From my experience, the recommended timeout values for DTLS often lead to spurious retransmissions in constrained node networks. Especially for constrained devices with software ECC support, network delays in combination with ECDH and ECDSA operations quickly exceed a 1 sec timeout. Similarly, for long message flights (i.e., certificate-related flights), repeated loss of a handshake message causes extensive handshake delays. As the specific timeout values may be application dependent, pointing out these issues in sections 5.2 and 5.3 would be very useful.

2) Section 5.1: The paragraph about the “PSK identity hint” is unclear to me. What is the rationale behind recommending against sending the hint if the key selection is based on the domain name of the server in contrast to any other means of identification? Moreover, how does this tie in with the subsequent recommendation saying “A server using the identity hint needs to guide the selection based on a received SNI value from the client.”?

Some editorial comments (possibly personal preference):

- The end of the introduction starting from “The design of DTLS is intentionally very similar to TLS.” could be moved into an own section, e.g., called “Overview of the DTLS Protocol”. In my opinion, this would further improve readability.

- In the third bullet point of the same paragraph, I would also remove the sentence about IKEv2 as this information is distracting with respect to the subsequent recommendation. To highlight what I mean, I am copying the text from the draft here:
“... [The HelloVerifyRequest] is sent by the server and includes a stateless cookie, which is returned in a ClientHello message back to the server. This type of DoS protection mechanism has been incorporated into the design of IKEv2. Although the exchange is optional for the server to execute, a client implementation has to be prepared to respond to it.".

- It would may helpful for implementors to have a brief summary of the most important general recommendations at the end of the introduction. Something along the lines: “An implementation complying to this profile i) MUST not use compression for DTLS handshake messages, ii) MUST not use DTLS < 1.2, and MAY use any of the following authentication modes: PSK, raw public-key, certificates. Specific recommendations for each of these modes are given in sections 5 - 18.”

- Section 5.1: “Furthermore, credentials are provisioned into trusted hardware modules or in the firmware by the developers.” -> add “often/commonly/typically” as there may also be other forms of provisioning.

René

--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Chair of Communication and Distributed Systems
RWTH Aachen University, Germany
tel: +49 241 80 21426
web: http://www.comsys.rwth-aachen.de/team/rene-hummen/

---

From: Robert Cragie <[email-masked]>
Date: Sun, 16 Nov 2014 02:19:50 +0000

Hi Sandeep,

 From my own personal experience, I would say AES-CCM implementations 
are normally done in software in conjunction with a hardware accelerated 
AES-128 block cipher. The biggest speed ups come from implementing the 
block cipher in hardware. However, there are implementations of full 
AES-CCM in hardware in certain devices for on-the-fly packet/buffer 
encryption/protection and decryption/verification. The implementations I 
am aware of can accommodate a variable length nonce in the AES-CCM engine.

However, it is possible that certain AES-CCM engines were designed for 
operations on a memory contiguous buffer, for example an 802.15.4 MAC 
packet. It is quite possible that the content of a DTLS record to be 
protected with AES-CCM is spread about, therefore it may need to be done 
in software in conjunction with a hardware accelerated AES-128 block 
cipher anyway.

I think UTA should state the use of approved AEAD ciphers as BCP, so 
that would include both AES-GCM and AES-CCM modes of operation. I 
realise the aim of a MTI cipher suite is for interoperability but it can 
become quickly outdated, e.g. the TLS 1.2 MTI cipher suite 
(TLS_RSA_WITH_AES_128_CBC_SHA).

Robert

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 18 Nov 2014 11:57:11 +0100

Hi Russ,

the HTTP 2.0 situation raises an additional question, namely what the
relevance of HTTP 2.0 is for Internet of Things. While HTTP 2.0 better
compresses headers (in comparison to HTTP 1.x) it adds other features
that are less relevant for the IoT environment. These features come at a
cost. CoAP is definitely a better fit for IoT scenarios than HTTP 2.0,
as research work by Markku Kojo in
http://link.springer.com/chapter/10.1007%2F978-3-319-11692-1_10

IMHO HTTPbis focuses on the Web and not on the IoT environment.

Ciao
Hannes

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Thu, 20 Nov 2014 09:28:22 +0000

Dear Hannes,
dear list

This is a great document and it is also quite important for the rollout of the IoT. Thanks Hannes for the good work in impressive time. Besides a few suggestions for improvement, I have the following critique: The document still implies that all IoT devices will be DTLS clients and that DTLS servers will be unconstrained, somewhere in the cloud. While I understand that this is one of the current use cases (from the OMA LWM2M Client Registration Interface), this implication undermines the idea and benefits of CoAP. The IoT devices are meant to be the origin/resource servers, as their sensors and actuators provide the information about the physical world. I hope this idea is clear and does not need further discussion (even LWM2M uses this communication model (Device Management, Service Enablement, and Information Reporting)).

"3. Communication Model" on page 5 is luckily not very clear about the roles and the restriction was not apparent to me. "7. Session Resumption" on page 15, however, states "the communication model described in Section 3 does not assume that the server is constrained".

This must be fixed because this document is a critical link for the overall software stack. We must make sure that it does not cripple the idea behind CoAP! In addition, it must also be applicable for constrained-device-to-constrained-device communication. Session resumption without server-side state can still be excluded by the profile, since the client can always be a constrained device. Some text on exceptions might be useful where a constrained server MAY utilize session resumption without server-side state when the client is unconstrained.

Other comments:

Page 7: "Some AEAD ciphersuites have shorter authentication tags"
It would be nice to briefly introduce the term authentication tag with its purpose in the previous paragraph where AEAD is explained.

Page 8: "[RFC4279] does not mandate the use of any particular type of identity."
On first reading, it was not clear to me what identity the document is talking about. Maybe "cryptographic identity" might help?

Page 9: The second paragraph about the PSK identity hint is very confusing. The case where a client has multiple keys is quite likely when thinking about ACE and should probably be the default model. The paragraph could be organized into the following three strategies:

1)      Only one key based on the domain name (does this include the IP?): no identity hint and clients MUST ignore

2)      Multiple keys: hint to select correct key for operation

3)      SNI: guide the selection based on the received SNI value from the client

Page 9: The third paragraph talks about identity and key lengths, but what are the restrictions that are not applicable? I am also not sure how the information about interfaces ties in.

Page 14: 6. Error Handling
For implementers, it would be really helpful to have a full list of the applicable error messages instead of a selection of not applicable ones. It would be great to have a short description for each when they occur and how the parties should proceed (e.g., state clean-ups, follow-up messages, etc.).

Page 14: "As stated in Section 2 of RFC 4279 the decryption_error error message may also be used instead."
It would be very nice to include the reason for this in the profile document. Engineers will always want to know why ;)
Furthermore, the correct name appears to be "decrypt_error".
In another RFC, I read about suppressing warning messages if the party wants to establish the session anyway. This recommendation could be mentioned in the profile as well (maybe even with a MUST NOT send warnings?).

Page 19: The second paragraph about the static relationship rather reflects the traditional way networked embedded devices were connected. This document should have an actual IoT in mind and look forward to networks and applications that converge and are all but static. If this is too speculative for an RFC, best delete this dusty paragraph.

Editorial hints:

Page 10: "To replace, delete, or add raw public keys" --> missing s
Page 11: "This ciphersuite makes" --> missing s
Page 12: "A device compliant with this protocol" confusing, as it is a profile
Page 17: "that the DTLS context is still in kept at the IOT device."
Page 17: "deployments the must constrained link" --> "most"
Page 18: "This RFC 6066 [RFC6066] extension" --> "The"? "This" sounds awkward here.
Page 18: "certificates and URLs instead" --> "send URLs instead"? A few more words on what is done might be helpful here.
Page 18: "This RFC 6066 extension" --> "The" again under 13. Trusted CA Indication
Page 20: "This RFC 6066 extension" --> "The"
Page 20: "the main benefit of this extension is it to allows" --> "that it"
Page 20: "implement this extension support this extension even though" --> pick one

Best regards
Matthias

From: dtls-iot [mailto:[email-masked]] On Behalf Of Dorothy Gellert
Sent: Dienstag, 11. November 2014 13:18
To: [email-masked]
Cc: Dorothy Gellert; Zach Shelby; Hannes Tschofenig
Subject: [Dtls-iot] WGLC for DTLS Profile draft: 11/11/2014 - 11/25/2014

Dear WG,

Best Regards,
Dorothy and Zach

---

From: Alexey Melnikov <[email-masked]>
Date: Sat, 22 Nov 2014 19:08:06 +0000

Hi,
My detailed comments are below.

> On 11 Nov 2014, at 23:18, Dorothy Gellert <[email-masked]> wrote:
> 
> Dear WG,
> 

While I think this document is on the right track (and mostly fine), there is a number of editorial issues that makes figuring out some requirements difficult. I suggest a revision before IETF LC.

On page 4: I suggest this document reference TLS WG document about deprecating RC4.

In Section 3, beginning of 3rd para:

   Clients are provisioned with information about the servers they need
   to initiate their DTLS exchange with and with credentials.

Did you mean "with and without"?

Section 4 is a good tutorial. Lots of Informative references are missing (e.g. for SHA1, SHA-256, AES, HMAC, CCM, GCM, etc)

In 5.1: is use of something like False Start common in IoT environment? As it reduces number of round trips, it might be advantageous and you should consider mentioning it.

In 5.2, the following paragraph seems out of place:

   Since many IoT devices will either have limited ways to log error or
   no ability at all, any error will lead to implementations attempting
   to re-try the exchange.  Implementers have to carefully evaluate the
   impact of errors and ways to remedy the situation since a commonly
   used approach for delegating decision making to users is difficult in
   a timely fashion (or impossible).

In particular, does it also apply to 5.1 and 5.3? Maybe you should move it somewhere else so that it is clear that it applies to all cases.

In 5.3:
   Support of the cached info extension is
   required.

Should this be REQUIRED?

   When DTLS is used to secure CoAP messages then the server provided
   certificates MUST contain the fully qualified DNS domain name or
   "FQDN".  The coaps URI scheme is described in Section 6.2 of
   [RFC7252].  This FQDN is stored

In order to avoid any doubt, I would insert "as dNSName" here.

    in the SubjectAltName or in the CN,

I think the correct way to say that is: "or in the leftmost CN component of subject name"

   as explained in Section 9.1.3.3 of [RFC7252],

At the end of section 7:

   Since the communication model described in Section 3 does not assume
   that the server is constrained.  RFC 5077 [RFC5077] describing TLS

I think you didn't intend dot here, maybe comma?

   session resumption without server-side state is not utilized by this
   profile.

In Section 10:

Client-Initiated, Regular Data Uploads

      This is a variation of the previous case whereby data gets
      uploaded on a regular basis, for example, based on frequent
      temperature readings.  With such regular exchange it can be
      assumed that the DTLS context is still in kept 

Delete "in"?

      at the IoT device.

      For this message exchange pattern the use of DTLS heartbeat
      messages is quite useful.  The MTU discovery mechanism, on the
      other hand, is less likely to be relevant since for many IoT
      deployments the must constrained link is the wireless interface at

I couldn't figure out what you are trying to say here.

      the IoT device itself rather than somewhere in the network.

In Section 17:

   Recommendation: Client implementations SHOULD implement this
   extension support this extension

Drop "support this extension".

   even though the ciphersuites
   recommended by this profile are not vulnerable this attack.

Missing "to".

In Section 18:

   CoAP demands version 1.2 of DTLS to be used and the earlier version
   of DTLS is not supported.  As such, there is no risk of downgrading
   to an older version of DTLS.  The work described in
   [I-D.bmoeller-tls-downgrade-scsv] is therefore also not applicable to
   this environment since there is no legacy server infrastructure to
   worry about.

While I-D.bmoeller-tls-downgrade-scsv is not currently needed, it might be useful when TLS 1.3/etc gets deployed and problems are found in TLS 1.2. Is this something we need to worry about in long term?

   TLS
   and DTLS allows a client and a server who already have a TLS
   connection to negotiate new parameters, generate new keys, etc by
   initiating a TLS handshake using a ClientHello message.
   Renegotiation happens in the existing TLS connection, with the new
   handshake packets being encrypted along with application data.

It is not clear what the above is trying to say. If this is explaining what renegotiation is, then it should be moved to the beginning of the same paragraph (I didn't include the first sentence of it). If this is a recommendation not to use renegotiation, then it needs rewording to make that clear.

Best Regards,
Alexey

---

From: "Rahman, Akbar" <[email-masked]>
Date: Tue, 25 Nov 2014 06:53:15 +0000

Hi Hannes,

Thank you for the very good work on the DTLS Profile draft.  I think it is ready for progression.  I do however have some comments for you to consider:

1)      I strongly agree with the comment below from Matthias that:

*         "The document still implies that all IoT devices will be DTLS clients and that DTLS servers will be unconstrained, somewhere in the cloud. While I understand that this is one of the current use cases (from the OMA LWM2M Client Registration Interface), this implication undermines the idea and benefits of CoAP. The IoT devices are meant to be the origin/resource servers, as their sensors and actuators provide the information about the physical world."

2)      In the abstract and elsewhere there are references to a constrained device providing sensor data.  I think that this should be clarified.  If you read the CoAP spec [RFC 7252] you will clearly see that the constrained device may either be read (GET - which corresponds to your sensor examples), or the device may have some data loaded onto it (PUT, POST, DELETE - and thus may be an actuator for example).  So you should indicate the dual nature of constrained devices.

*         See for example: https://tools.ietf.org/html/rfc7252#section-5.8

3)      Shouldn't the CoAP spec [RFC 7252] be classified as a Normative reference instead of an Informative reference (e.g. because you are aligning your security modes with RFC 7252)?

Best Regards,

Akbar

From: dtls-iot [mailto:[email-masked]] On Behalf Of Kovatsch Matthias
Sent: Thursday, November 20, 2014 4:28 AM
To: Dorothy Gellert; [email-masked]
Cc: Zach Shelby; Hannes Tschofenig
Subject: Re: [Dtls-iot] WGLC for DTLS Profile draft: 11/11/2014 - 11/25/2014

Dear Hannes,
dear list

Other comments:

Editorial hints:

Best regards
Matthias

To: [email-masked]<mailto:[email-masked]>

Dear WG,

Best Regards,
Dorothy and Zach

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 25 Nov 2014 08:21:37 +0100

Hi Akbar,

thanks for your review comments. A few notes below.

On 11/25/2014 07:53 AM, Rahman, Akbar wrote:
> Hi Hannes,
> 
>  
> 
>  
> 
> Thank you for the very good work on the DTLS Profile draft.  I think it
> is ready for progression.  I do however have some comments for you to
> consider:
> 
>  
> 
> ·         “The document still implies that all IoT devices will be DTLS
> clients and that DTLS servers will be unconstrained, somewhere in the
> cloud. While I understand that this is one of the current use cases
> (from the OMA LWM2M Client Registration Interface), this implication
> undermines the idea and benefits of CoAP. The IoT devices are meant to
> be the origin/resource servers, as their sensors and actuators provide
> the information about the physical world.”
> 
> 
I responded to this issue in a separate mail.

> 
> 2)      In the abstract and elsewhere there are references to a
> constrained device providing sensor data.  I think that this should be
> clarified.  If you read the CoAP spec [RFC 7252] you will clearly see
> that the constrained device may either be read (GET – which corresponds
> to your sensor examples), or the device may have some data loaded onto
> it (PUT, POST, DELETE – and thus may be an actuator for example).  So
> you should indicate the dual nature of constrained devices.
> 
> ·         See for example: https://tools.ietf.org/html/rfc7252#section-5.8
> 
I kept the description a bit more abstract without going into the
specific exchanges of CoAP itself and there might be a bit of a
terminology mismatch between the use of client and server in CoAP vs.
the use of client and server in DTLS.

In order for the DTLS scenario to work the IoT device initiates the
interaction with some server (cloud) and uploads data there. There may
also be the situation where the IoT device interacts with some server
(cloud) and downloads information (such as device configuration, etc.).

In any case, the important part is that the constrained IoT device
initiates the interaction with the server side infrastructure since
otherwise you run into all sorts of problems when the could
infrastructure starts to interact with an IoT device, such as discovery,
NAT and firewall traversal, the asymmetric nature of DTLS, etc.

There are certainly message exchange patterns in the CoAP specification
that are not covered by this DTLS profile document, as pointed out in
your comment #1.

Does this make sense to you?

> 3)      Shouldn’t the CoAP spec [RFC 7252] be classified as a Normative
> reference instead of an Informative reference (e.g. because you are
> aligning your security modes with RFC 7252)?

I decided against listing CoAP as a normative reference since there is
nothing in the spec that requires it. In fact, you could run another
protocol over DTLS and the recommendations would still be sound.

Ciao
Hannes

> 
>  
> 
>  
> 
> Best Regards,
> 
>  
> 
> Akbar
> 
>  
> 
>  
> 
>  
> 
>  
> 
> *From:*dtls-iot [mailto:[email-masked]] *On Behalf Of
> *Kovatsch Matthias
> *Sent:* Thursday, November 20, 2014 4:28 AM
> *To:* Dorothy Gellert; [email-masked]
> *Cc:* Zach Shelby; Hannes Tschofenig
> *Subject:* Re: [Dtls-iot] WGLC for DTLS Profile draft: 11/11/2014 -
> 11/25/2014
> 
>  
> 
> Dear Hannes,
> 
> dear list
> 
>  
> 
> This is a great document and it is also quite important for the rollout
> of the IoT. Thanks Hannes for the good work in impressive time. Besides
> a few suggestions for improvement, I have the following critique: The
> document still implies that all IoT devices will be DTLS clients and
> that DTLS servers will be unconstrained, somewhere in the cloud. While I
> understand that this is one of the current use cases (from the OMA LWM2M
> Client Registration Interface), this implication undermines the idea and
> benefits of CoAP. The IoT devices are meant to be the origin/resource
> servers, as their sensors and actuators provide the information about
> the physical world. I hope this idea is clear and does not need further
> discussion (even LWM2M uses this communication model (Device Management,
> Service Enablement, and Information Reporting)).
> 
>  
> 
> “3. Communication Model” on page 5 is luckily not very clear about the
> roles and the restriction was not apparent to me. “7. Session
> Resumption” on page 15, however, states “the communication model
> described in Section 3 does not assume that the server is constrained”.
> 
>  
> 
> This must be fixed because this document is a critical link for the
> overall software stack. We must make sure that it does not cripple the
> idea behind CoAP! In addition, it must also be applicable for
> constrained-device-to-constrained-device communication. Session
> resumption without server-side state can still be excluded by the
> profile, since the client can always be a constrained device. Some text
> on exceptions might be useful where a constrained server MAY utilize
> session resumption without server-side state when the client is
> unconstrained.
> 
>  
> 
> Other comments:
> 
>  
> 
> Page 7: “Some AEAD ciphersuites have shorter authentication tags”
> 
> It would be nice to briefly introduce the term authentication tag with
> its purpose in the previous paragraph where AEAD is explained.
> 
>  
> 
> Page 8: “[RFC4279] does not mandate the use of any particular type of
> identity.”
> 
> On first reading, it was not clear to me what identity the document is
> talking about. Maybe “cryptographic identity” might help?
> 
>  
> 
> Page 9: The second paragraph about the PSK identity hint is very
> confusing. The case where a client has multiple keys is quite likely
> when thinking about ACE and should probably be the default model. The
> paragraph could be organized into the following three strategies:
> 
> 1)      Only one key based on the domain name (does this include the
> IP?): no identity hint and clients MUST ignore
> 
> Page 9: The third paragraph talks about identity and key lengths, but
> what are the restrictions that are not applicable? I am also not sure
> how the information about interfaces ties in.
> 
>  
> 
> For implementers, it would be really helpful to have a full list of the
> applicable error messages instead of a selection of not applicable ones.
> It would be great to have a short description for each when they occur
> and how the parties should proceed (e.g., state clean-ups, follow-up
> messages, etc.).
> 
>  
> 
> Page 14: “As stated in Section 2 of RFC 4279 the decryption_error error
> message may also be used instead.”
> 
> It would be very nice to include the reason for this in the profile
> document. Engineers will always want to know why ;)
> 
> Furthermore, the correct name appears to be “decrypt_error”.
> 
> In another RFC, I read about suppressing warning messages if the party
> wants to establish the session anyway. This recommendation could be
> mentioned in the profile as well (maybe even with a MUST NOT send
> warnings?).
> 
>  
> 
> Page 19: The second paragraph about the static relationship rather
> reflects the traditional way networked embedded devices were connected.
> This document should have an actual IoT in mind and look forward to
> networks and applications that converge and are all but static. If this
> is too speculative for an RFC, best delete this dusty paragraph.
> 
>  
> 
> Editorial hints:
> 
>  
> 
> Page 10: “To replace, delete, or add raw public key*s*“ àmissing s
> 
> Page 11: “This ciphersuite make*s*” àmissing s
> 
> Page 12: “A device compliant with this *protocol*” confusing, as it is a
> profile
> 
> Page 17: “that the DTLS context is still *in*kept at the IOT device.”
> 
> Page 17: “deployments the m*u*st constrained link” à“most”
> 
> Page 18: “*This*RFC 6066 [RFC6066] extension” à“The”? “This” sounds
> awkward here.
> 
> Page 18: “certificates and URLs instead” à“send URLs instead”? A few
> more words on what is done might be helpful here.
> 
> Page 18: “*This*RFC 6066 extension” à“The” again under 13. Trusted CA
> Indication
> 
> Page 20: “*This*RFC 6066 extension” à“The”
> 
> Page 20: “the main benefit of this extension is *it to*allows” à“that it”
> 
> Page 20: “*implement this extension support this extension*even though”
> àpick one
> 
>  
> 
> Best regards
> 
> Matthias
> 
>  
> 
>  
> 
> *From:*dtls-iot [mailto:[email-masked]] *On Behalf Of
> *Dorothy Gellert
> *Sent:* Dienstag, 11. November 2014 13:18
> *To:* [email-masked] <mailto:[email-masked]>
> *Cc:* Dorothy Gellert; Zach Shelby; Hannes Tschofenig
> *Subject:* [Dtls-iot] WGLC for DTLS Profile draft: 11/11/2014 - 11/25/2014
> 
>  
> 
> Dear WG,
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 25 Nov 2014 09:01:59 +0100

Hi Stephen,

I personally don't care too much about the different AES modes of
operation. I don't have a particularly preference since both will have
more or less the same code size and performance (particularly when we
talk about small message sizes). Of course, it would have been useful to
think about this issue earlier when CCM and GCM were developed (funny
enough by two IETF folks, Russ and David McGrew). In any case, I don't
want to get dragged into this "my algorithm is better than yours" debate.

The issue is just that other SDOs have also selected AES-CCM, such as
Bluetooth Smart, Zigbee IP* (if that matters anymore today), and IEEE
802.11i (which isn't necessarily a low power radio but still used in
certain IoT deployments).

These silicon manufacturers then made these algorithms available for
developers as well (besides using them for the underlying radio
technology). Furthermore, they have also been added to SoCs even without
the radio technology.

In many cases these algorithm implementations cannot be updated (even if
they are just software running on the chip) rather than being really in
hardware.

Whether it is useful to put the entire algorithm in hardware or instead
just some primitives is yet another story but I guess it is a bit too
late for that discussion.

The question therefore is what could be done about this situation. Here
are the options:

a) Change the recommendations in the UTA document to AES-CCM
b) Change the recommendations in the DTLS profile document to AES-GCM
c) Indicate support for both (AES-CCM and AES-GCM)
d) Leave the documents as they are since they target different industry
segments/use cases.

As I argued earlier I think option (d) is the way to go.

Ciao
Hannes

*: According to my understanding Zigbee IP uses a variation of AES-CCM.

---

From: Zach Shelby <[email-masked]>
Date: Tue, 25 Nov 2014 08:25:37 +0000

In addition to actual hardware support for AES-CCM in the embedded SoC industry, which won't go away anytime soon, I would also point out that the required cipher suites in CoAP are CCM based as well. We really do need to support CCM in the DICE Profile. We could indicate support for GCM as well, but I don't think that is particularly important.

Regarding the UTA doc, considering that it is general recommendations for TLS and DTLS, this should really align with the needs of the DICE and CoRE working groups (and thus the IoT industry) as well. It is totally contradictory to indicate in draft-ietf-uta-tls-bcp that GCM is recommended, and then in several other RFCs dependent on DTLS recommend the use of CCM. At the minimum that document should have a reference to the use of CCM in IoT specifications.

That would be option c from your list Hannes?

Zach

Zach Shelby

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 25 Nov 2014 10:11:23 +0100

Hi Sandeep,

On 11/15/2014 04:02 AM, Kumar, Sandeep wrote:
> HI Hannes
> 
> Can you clarify if the silicon vendors are implementing AES-CCM or
> plain AES in hardware (i.e. AES-ECB) with the CCM mode implemented in
> software?

It is sometimes a bit hard to say whether functionality is implemented
in software or in hardware since everything is hidden on the chip.

Just take the Nordic Semiconductor Bluetooth Smart SoC (nRF51822)
https://www.nordicsemi.com/eng/Products/Bluetooth-Smart-Bluetooth-low-energy/nRF51822

Due to Bluetooth 4.1 specification it comes with AES-CCM support and the
firmware for this chip can be updated (and there are different versions
of the firmware available). What exactly can be updated is something I
don't know because the firmware image is provided by Nordic.

Of course, the main purpose of this chip is to run Bluetooth Smart-based
applications and there may not be enough space to run your entire IoT
software stack. You might have other radio technologies running on other
chips as well. As such, in your final product you might end up having
various places where you could run your cryptographic algorithms...

When I looked at the specifications to answer your question I actually
didn't find the needed info. Maybe I have not searched enough. I will
get in touch with the guys at Nordic to figure it out for this specific
example.

Your question is obviously quite good and I believe we should put more
text into the draft about this topic to give silicon vendors some
guidance about what to provide.

> If it is the former, do you know if they are flexible
> enough to implement AES-CCM with different nonce lengths. The reason
> I ask is because AES-CCM in IEEE 802.15.4 uses a nonce length of
> 13-octets while DTLS uses 12-octets. I have heard of some15.4 chips
> that hard-code (in hardware) the 13-octet nonce length making it
> useless for DTLS.
Is the issue caused by IEEE 802.15.4 or by Zigbee IP?

Ciao
Hannes

> 
> Regards Sandeep
> 
> 
> 
>> -----Original Message----- From: dtls-iot
>> [mailto:[email-masked]] On Behalf Of Hannes Tschofenig 
>> Sent: Friday, November 14, 2014 9:58 AM To: Russ Housley;
>> [email-masked] Cc: Dorothy Gellert; Zach Shelby Subject: Re:
>> [Dtls-iot] WGLC for DTLS Profile draft: 11/11/2014 - 11/25/2014
>> 
>> Hi Russ,
>> 
>>> algorithm.  It would
>> be really nice if the two groups came to a place that allowed
>> interoperability, but HTTPbis seems to be on a path for AES-GCM.
>> AES-CCM is better for small devices.
>>> 
>>> It seems to me that the two groups should talk to each other
>>> before WG
>> Last Call is over.
>>> 
>>> Russ
>>> 
> ________________________________ 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: Hannes Tschofenig <[email-masked]>
Date: Tue, 25 Nov 2014 10:16:27 +0100

Hi Zach,

it would be option #d in my list below. In fact, I have already dropped
a mail to the UTA list about their document and raised the issue of
scoping. Their document is really is about the Web. I fear that nobody
had really looked at their document in detail since otherwise someone
would have noticed that it also talks briefly about email and XMPP while
there is other work in the group that provides much greater detail on
those topic. In the same spirit I see the IoT case as something that
does not belong in their document at all. TLS (and DTLS) is just used in
a number of different deployments and they are a bit different.

Ciao
Hannes

On 11/25/2014 09:25 AM, Zach Shelby wrote:
>>>>>> before WG Last Call is over.
>>>>>>
>>>>>> Russ
>>>>

---

From: Zach Shelby <[email-masked]>
Date: Tue, 25 Nov 2014 01:23:23 -0800

Hannes,

Agreed that makes sense, if it would be scoped correctly.

Zach

Zach Shelby

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 25 Nov 2014 10:00:32 +0000

Hannes,

- - I don't think you're correct that the UTA BCP is only
  about the web but let's not debate that here.
- - It's probably best to not complicate the UTA BCP with
  any specifics of devices that cannot do GCM.
- - The GCM/CCM situation is IMO far from perfect but we
  have to live with it.
- - Any attempts to "win" here (e.g. to try push for use
  of a mode where it won't work) would be a bad plan - we
  should look at this as an interop problem that needs
  to be worked around and not have a silly "my mode is
  better than yours" argument (not saying you're doing
  that)
- - It'd be good if those developing systems and lower
  layer standards recognised the interop problem and
  tried to help make it better (that might already be
  happening, I'm not sure)

S.

On 25/11/14 09:16, Hannes Tschofenig wrote:
> Hi Zach,
> 
> it would be option #d in my list below. In fact, I have already
> dropped a mail to the UTA list about their document and raised the
> issue of scoping. Their document is really is about the Web. I fear
> that nobody had really looked at their document in detail since
> otherwise someone would have noticed that it also talks briefly
> about email and XMPP while there is other work in the group that
> provides much greater detail on those topic. In the same spirit I
> see the IoT case as something that does not belong in their
> document at all. TLS (and DTLS) is just used in a number of
> different deployments and they are a bit different.
> 
> Ciao Hannes
> 
> 
>> In addition to actual hardware support for AES-CCM in the
>> embedded SoC industry, which won't go away anytime soon, I would
>> also point out that the required cipher suites in CoAP are CCM
>> based as well. We really do need to support CCM in the DICE
>> Profile. We could indicate support for GCM as well, but I don't
>> think that is particularly important.
>> 
>> Regarding the UTA doc, considering that it is general
>> recommendations for TLS and DTLS, this should really align with
>> the needs of the DICE and CoRE working groups (and thus the IoT
>> industry) as well. It is totally contradictory to indicate in
>> draft-ietf-uta-tls-bcp that GCM is recommended, and then in
>> several other RFCs dependent on DTLS recommend the use of CCM. At
>> the minimum that document should have a reference to the use of
>> CCM in IoT specifications.
>> 
>>> I personally don't care too much about the different AES modes
>>> of operation. I don't have a particularly preference since both
>>> will have more or less the same code size and performance
>>> (particularly when we talk about small message sizes). Of
>>> course, it would have been useful to think about this issue
>>> earlier when CCM and GCM were developed (funny enough by two
>>> IETF folks, Russ and David McGrew). In any case, I don't want
>>> to get dragged into this "my algorithm is better than yours"
>>> debate.
>>> 
>>> The issue is just that other SDOs have also selected AES-CCM,
>>> such as Bluetooth Smart, Zigbee IP* (if that matters anymore
>>> today), and IEEE 802.11i (which isn't necessarily a low power
>>> radio but still used in certain IoT deployments).
>>> 
>>> These silicon manufacturers then made these algorithms
>>> available for developers as well (besides using them for the
>>> underlying radio technology). Furthermore, they have also been
>>> added to SoCs even without the radio technology.
>>> 
>>> In many cases these algorithm implementations cannot be updated
>>> (even if they are just software running on the chip) rather
>>> than being really in hardware.
>>> 
>>> Whether it is useful to put the entire algorithm in hardware or
>>> instead just some primitives is yet another story but I guess
>>> it is a bit too late for that discussion.
>>> 
>>> The question therefore is what could be done about this
>>> situation. Here are the options:
>>> 
>>> a) Change the recommendations in the UTA document to AES-CCM b)
>>> Change the recommendations in the DTLS profile document to
>>> AES-GCM c) Indicate support for both (AES-CCM and AES-GCM) d)
>>> Leave the documents as they are since they target different
>>> industry segments/use cases.
>>> 
>>>>> I understand the hardware situation.  That was the point I
>>>>> was trying to make when I said, "It makes a lot of sense
>>>>> for small devices." Please explain this situation in
>>>>> HTTPbis.  My hope is that they will join you by either
>>>>> picking AES-CCM or picking both AES-GCM and AES-CCM.
>>>> 
>>>> I get that there are devices out there with CCM and that
>>>> that's unlikely to go away, and that the same is true for
>>>> GCM, but that seems like a thing that's a pain to work
>>>> around.
>>>> 
>>>>>> The ciphersuites selected for the DTLS profile draft have
>>>>>> been heavily influenced by the work done in the CORE
>>>>>> working group.
>>>>>> 
>>>>>> We have been telling silicon partners that they should
>>>>>> put AES-CCM into their chips and they have indeed
>>>>>> following that recommendation.
>>>>>> 
>>>>>> I believe, however, that this is not a problem as such
>>>>>> since the UTA work really has a different scope - they
>>>>>> focus on Web/Messaging/Email rather than the IoT space. I
>>>>>> sent a mail to their list to request the title to be
>>>>>> adjusted.
>>>>>> 
>>>>>> Ciao Hannes
>>>>>> 
>>>>>>> DICE document requires
>>>>>>> TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8.  I have no problem
>>>>>>> with that choice.  It makes a lot of sense for small
>>>>>>> devices.
>>>>>>> 
>>>>>>> The HTTPbis is also taking a path that requires an
>>>>>>> AEAD algorithm.  It would be really nice if the two
>>>>>>> groups came to a place that allowed interoperability,
>>>>>>> but HTTPbis seems to be on a path for AES-GCM.  AES-CCM
>>>>>>> is better for small devices.
>>>>>>> 
>>>>> _______________________________________________ dtls-iot
>>>>> mailing list [email-masked] 
>> Zach Shelby Director of Technical Marketing ARM Internet of
>> Things BU www.arm.com US: +1 (408) 203-9434 Finland: +358
>> 407796297 Skype: zdshelby LinkedIn:
>> fi.linkedin.com/in/zachshelby/
>> 
>> 
>> -- IMPORTANT NOTICE: The contents of this email and any
>> attachments are confidential and may also be privileged. If you
>> are not the intended recipient, please notify the sender
>> immediately and do not disclose the contents to any other person,
>> use it for any purpose, or store or copy the information in any
>> medium.  Thank you.
>> 
>> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1
>> 9NJ, Registered in England & Wales, Company No:  2557590 ARM
>> Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1
>> 9NJ, Registered in England & Wales, Company No:  2548782
>> 
> 
> 
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 25 Nov 2014 11:07:19 +0100

Hi Rene,

On 11/15/2014 08:05 AM, Rene Hummen wrote:
> Besides the fact that I would have liked this draft to consider both a
> constrained DTLS client and a constrained DTLS server,

I created another discussion thread about this topic.

It would be interesting to hear what use cases you have in mind and
whether you believe that such a write-up can wait for ACE or whether you
see this totally independent of ACE.

> I have two main comments:
> 
> 1) From my experience, the recommended timeout values for DTLS often
> lead to spurious retransmissions in constrained node networks.
> Especially for constrained devices with software ECC support, network
> delays in combination with ECDH and ECDSA operations quickly exceed a 1
> sec timeout. Similarly, for long message flights (i.e.,
> certificate-related flights), repeated loss of a handshake message
> causes extensive handshake delays. As the specific timeout values may be
> application dependent, pointing out these issues in sections 5.2 and 5.3
> would be very useful.

Your point is well taken. In response to my presentation about DTLS over
SMS this issue was also raised and the suggestion was made to include
these timer-settings in the DTLS profile.

> 
> 2) Section 5.1: The paragraph about the “PSK identity hint” is unclear
> to me. What is the rationale behind recommending against sending the
> hint if the key selection is based on the domain name of the server in
> contrast to any other means of identification? Moreover, how does this
> tie in with the subsequent recommendation saying “A server using the
> identity hint needs to guide the selection based on a received SNI value
> from the client.”?

Thanks for asking.

There are two types of "identities" (or identifiers as I would call
them) in use.

First, the client needs to tell the server some identifier so that it
can select the right key when verifying the message. This is called the
"PSK Identity".

Then, there is also the capability in the TLS-PSK RFC to allow the
server to indicate what key the client should use. This is the "PSK
Identity Hint". Obviously, this is only an issue if the client has more
than one PSK to begin with.

The concept of this PSK identity hint was inspired by the realm
parameter of the HTTP digest algorithm where a single server can host
multiple resources and the server then challenges the client (or user)
accordingly.

In the IoT context the scenario is hopefully a bit simpler. I suspect
that in normal circumstances the client will select the key based on the
domain name.

At the time when the TLS-PSK algorithm was written the concept of SNI
did not exist since the use of hosted services wasn't that common. If
someone would want to use a hosted environment for their IoT deployment
then they would most likely support SNI.

Does this make sense?

> Some editorial comments (possibly personal preference):

Thanks for the editorial remarks. Will incorporate them into the next
draft version.

Ciao
Hannes

> René
> 
> 
> On 12 Nov 2014, at 00:18, Dorothy Gellert <[email-masked]
> <mailto:[email-masked]>> wrote:
>> Dear WG,
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Zach Shelby <[email-masked]>
Date: Tue, 25 Nov 2014 10:18:48 +0000

Stephen,

I don't agree that the situation should just be left as-is. You are correct that that UTA BCP is very broad ranging in scope in -07 of the draft. In order to not totally contradict ourselves, there are two options. This isn't about winning, just not confusing the community when they read our specifications.

Option 1 - Fix the scope of the UTA BCP to specifically not include IoT. I think this is what Hannes was suggesting.

Option 2 - Include a reference in the UTA BCP to the CCM based cipher suites already recommended for use with DTLS in CoAP, and other industry standards.

This could potentially cause interoperability if the specifications cause confusion. But I don't see an interoperability problem today, for CoAP over DTLS the must implement cipher suites are very clearly defined.

Zach

On Nov 25, 2014, at 12:00 PM, Stephen Farrell <[email-masked]> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> Hannes,
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJUdFM5AAoJEC88hzaAX42i29kH/3Zqs/yCbiHPvrutVDamGdFv
> 3OilgYSeaOxeOa5xlA04hrDuN312i0CW010DokkmuWiYQyT8nH4C4i5PWsVnS9E/
> USeWuBBYOdfs34CJUKwBGSLcqOfxoomx+aUtbSh32ZwMOFho2HWpTbu2GZUlMFKG
> tvUqgwbtz1UNPUT0UtHODy7CsKb4fLdCpoXzzjy6C1mM6QH/+xGA5jBn1ZLeUOlO
> 71P8JnK5mO6F7dIDuYHyq+6Wq4qUMlCHi6VYEl/FAJ0+/NfPxSjRoVMvyfryTDwg
> 0rseyugM4e1zaPBplvpKPLpbrYGgCTB98Q4uyn+G+xcU+yKtLGg/fGukJFxQ2jk=
> =bDdV
> -----END PGP SIGNATURE-----
>

Zach Shelby

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 25 Nov 2014 11:18:26 +0100

Hi Stephen,

On 11/25/2014 11:00 AM, Stephen Farrell wrote:
> 
> Hannes,
> 
> - I don't think you're correct that the UTA BCP is only

Maybe a discussion for UTA but the scope of draft-ietf-uta-tls-bcp seems
relevant here as well.

> - It's probably best to not complicate the UTA BCP with

Fine with me.

> - The GCM/CCM situation is IMO far from perfect but we
>   have to live with it.

This is inline with my assessment.

> - Any attempts to "win" here (e.g. to try push for use

In full agreement.

> - It'd be good if those developing systems and lower

But what does this mean for me as a document editor?

So far, the use of CCM was not seen as a problem for the IoT community.
I could point out that there is this other mode of operation (GCM) and
it is suggested in draft-ietf-uta-tls-bcp. But what should I recommend?
ignore it? implement it?

Ciao
Hannes

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 25 Nov 2014 10:32:52 +0000

On 25/11/14 10:18, Zach Shelby wrote:
> Stephen,
> 
> I don't agree that the situation should just be left as-is. You are
> correct that that UTA BCP is very broad ranging in scope in -07 of
> the draft. In order to not totally contradict ourselves, there are
> two options. This isn't about winning, just not confusing the
> community when they read our specifications.
> 
> Option 1 - Fix the scope of the UTA BCP to specifically not include
> IoT. I think this is what Hannes was suggesting.

The scope of the UTA BCP is not broken IMO. If you think it is
you'll have an IETF LC shortly where saying that would be the
thing to do.

> 
> Option 2 - Include a reference in the UTA BCP to the CCM based cipher
> suites already recommended for use with DTLS in CoAP, and other
> industry standards.

Was discussed and I think rejected on UTA list. That could
have been done though as a footnote.

> This could potentially cause interoperability if the specifications
> cause confusion. But I don't see an interoperability problem today,

Really? We have two pointlessly different modes that won't talk
to one another? Seems like a crystal clear interop issue to me.
There is no confusion though we just have devices that can't talk
to the rest of the Internet easily because of this.

> for CoAP over DTLS the must implement cipher suites are very clearly
> defined.

Sure. It's clear and it works. But I don't think I've seen any
TLS usage stats that show up CCM ciphersuites whether for the
web or mail or other applications. Might be useful to go looking
but I'm not sure if folks have done that.

The fact that CCM is required by CoAP or DICE is unfortunate
and not a good thing since the rest of the Internet isn't afaik
using CCM. (It's still probably the right thing, even if
regrettable due to platform constraints.)

S.

> - I don't think you're correct that the UTA BCP is only about the web
> but let's not debate that here. - It's probably best to not
> complicate the UTA BCP with any specifics of devices that cannot do
> GCM. - The GCM/CCM situation is IMO far from perfect but we have to
> live with it. - Any attempts to "win" here (e.g. to try push for use 
> of a mode where it won't work) would be a bad plan - we should look
> at this as an interop problem that needs to be worked around and not
> have a silly "my mode is better than yours" argument (not saying
> you're doing that) - It'd be good if those developing systems and
> lower layer standards recognised the interop problem and tried to
> help make it better (that might already be happening, I'm not sure)
> 
> S.
> 
>>>> it would be option #d in my list below. In fact, I have
>>>> already dropped a mail to the UTA list about their document and
>>>> raised the issue of scoping. Their document is really is about
>>>> the Web. I fear that nobody had really looked at their document
>>>> in detail since otherwise someone would have noticed that it
>>>> also talks briefly about email and XMPP while there is other
>>>> work in the group that provides much greater detail on those
>>>> topic. In the same spirit I see the IoT case as something that
>>>> does not belong in their document at all. TLS (and DTLS) is
>>>> just used in a number of different deployments and they are a
>>>> bit different.
>>>> 
>>>> Ciao Hannes
>>>> 
>>>> 
>>>>> embedded SoC industry, which won't go away anytime soon, I
>>>>> would also point out that the required cipher suites in CoAP
>>>>> are CCM based as well. We really do need to support CCM in
>>>>> the DICE Profile. We could indicate support for GCM as well,
>>>>> but I don't think that is particularly important.
>>>>> 
>>>>> recommendations for TLS and DTLS, this should really align
>>>>> with the needs of the DICE and CoRE working groups (and thus
>>>>> the IoT industry) as well. It is totally contradictory to
>>>>> indicate in draft-ietf-uta-tls-bcp that GCM is recommended,
>>>>> and then in several other RFCs dependent on DTLS recommend
>>>>> the use of CCM. At the minimum that document should have a
>>>>> reference to the use of CCM in IoT specifications.
>>>>> 
>>>>>> I personally don't care too much about the different AES
>>>>>> modes of operation. I don't have a particularly preference
>>>>>> since both will have more or less the same code size and
>>>>>> performance (particularly when we talk about small message
>>>>>> sizes). Of course, it would have been useful to think about
>>>>>> this issue earlier when CCM and GCM were developed (funny
>>>>>> enough by two IETF folks, Russ and David McGrew). In any
>>>>>> case, I don't want to get dragged into this "my algorithm
>>>>>> is better than yours" debate.
>>>>>> 
>>>>>> The issue is just that other SDOs have also selected
>>>>>> AES-CCM, such as Bluetooth Smart, Zigbee IP* (if that
>>>>>> matters anymore today), and IEEE 802.11i (which isn't
>>>>>> necessarily a low power radio but still used in certain IoT
>>>>>> deployments).
>>>>>> 
>>>>>> available for developers as well (besides using them for
>>>>>> the underlying radio technology). Furthermore, they have
>>>>>> also been added to SoCs even without the radio technology.
>>>>>> 
>>>>>> In many cases these algorithm implementations cannot be
>>>>>> updated (even if they are just software running on the
>>>>>> chip) rather than being really in hardware.
>>>>>> 
>>>>>> Whether it is useful to put the entire algorithm in
>>>>>> hardware or instead just some primitives is yet another
>>>>>> story but I guess it is a bit too late for that
>>>>>> discussion.
>>>>>> 
>>>>>> a) Change the recommendations in the UTA document to
>>>>>> AES-CCM b) Change the recommendations in the DTLS profile
>>>>>> document to AES-GCM c) Indicate support for both (AES-CCM
>>>>>> and AES-GCM) d) Leave the documents as they are since they
>>>>>> target different industry segments/use cases.
>>>>>> 
>>>>>>>> I understand the hardware situation.  That was the
>>>>>>>> point I was trying to make when I said, "It makes a lot
>>>>>>>> of sense for small devices." Please explain this
>>>>>>>> situation in HTTPbis.  My hope is that they will join
>>>>>>>> you by either picking AES-CCM or picking both AES-GCM
>>>>>>>> and AES-CCM.
>>>>>>> 
>>>>>>> that's unlikely to go away, and that the same is true
>>>>>>> for GCM, but that seems like a thing that's a pain to
>>>>>>> work around.
>>>>>>> 
>>>>>>>>> The ciphersuites selected for the DTLS profile draft
>>>>>>>>> have been heavily influenced by the work done in the
>>>>>>>>> CORE working group.
>>>>>>>>> 
>>>>>>>>> We have been telling silicon partners that they
>>>>>>>>> should put AES-CCM into their chips and they have
>>>>>>>>> indeed following that recommendation.
>>>>>>>>> 
>>>>>>>>> I believe, however, that this is not a problem as
>>>>>>>>> such since the UTA work really has a different scope
>>>>>>>>> - they focus on Web/Messaging/Email rather than the
>>>>>>>>> IoT space. I sent a mail to their list to request the
>>>>>>>>> title to be adjusted.
>>>>>>>>> 
>>>>>>>>> Ciao Hannes
>>>>>>>>> 
>>>>>>>>>> TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8.  I have no
>>>>>>>>>> problem with that choice.  It makes a lot of sense
>>>>>>>>>> for small devices.
>>>>>>>>>> 
>>>>>>>>>> AEAD algorithm.  It would be really nice if the
>>>>>>>>>> two groups came to a place that allowed
>>>>>>>>>> interoperability, but HTTPbis seems to be on a path
>>>>>>>>>> for AES-GCM.  AES-CCM is better for small devices.
>>>>>>>>>> 
>>>>>>>> dtls-iot mailing list [email-masked] 
>>>>> attachments are confidential and may also be privileged. If
>>>>> you are not the intended recipient, please notify the sender 
>>>>> immediately and do not disclose the contents to any other
>>>>> person, use it for any purpose, or store or copy the
>>>>> information in any medium.  Thank you.
>>>>> 
>>>>> ARM Limited, Registered office 110 Fulbourn Road, Cambridge
>>>>> CB1 9NJ, Registered in England & Wales, Company No:  2557590
>>>>> ARM Holdings plc, Registered office 110 Fulbourn Road,
>>>>> Cambridge CB1 9NJ, Registered in England & Wales, Company No:
>>>>> 2548782
>>>>> 
>>>> 
>>>> 
>>>> 
> Zach Shelby Director of Technical Marketing ARM Internet of Things
> BU www.arm.com US: +1 (408) 203-9434 Finland: +358 407796297 Skype:
> zdshelby LinkedIn: fi.linkedin.com/in/zachshelby/
> 
> 
> -- IMPORTANT NOTICE: The contents of this email and any attachments
> are confidential and may also be privileged. If you are not the
> intended recipient, please notify the sender immediately and do not
> disclose the contents to any other person, use it for any purpose, or
> store or copy the information in any medium.  Thank you.
> 
> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
> Registered in England & Wales, Company No:  2557590 ARM Holdings plc,
> Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in
> England & Wales, Company No:  2548782
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 25 Nov 2014 11:44:07 +0100

> This is an IEEE 802.15.4 issue. Not sure what Bluetooth smart uses for the nonce length, will have to check.

A quick look at the specification tells me that the nonce in the
Bluetooth 4.1 spec is also 13 octets. Ooops.

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Tue, 25 Nov 2014 10:55:13 +0000

Snip..
> The concept of this PSK identity hint was inspired by the realm parameter of
> the HTTP digest algorithm where a single server can host multiple resources
> and the server then challenges the client (or user) accordingly.

This seems to be a good feature for authorization where the server can ask if the client possesses a specific key to perform operations on specific resources. Maybe this is not straightforward but something to keep in mind for ACE?

Sandeep

> Sent: Tuesday, November 25, 2014 11:07 AM
> To: Rene Hummen; Dorothy Gellert
> Cc: Zach Shelby; [email-masked]
> Subject: Re: [Dtls-iot] Retransmission timeout and PSK identity hint
>
> Hi Rene,
>
> It would be interesting to hear what use cases you have in mind and whether
> you believe that such a write-up can wait for ACE or whether you see this
> totally independent of ACE.
>
> > delays in combination with ECDH and ECDSA operations quickly exceed a
> > 1 sec timeout. Similarly, for long message flights (i.e.,
> > causes extensive handshake delays. As the specific timeout values may
> > be application dependent, pointing out these issues in sections 5.2
> > and 5.3 would be very useful.
>
> SMS this issue was also raised and the suggestion was made to include these
> timer-settings in the DTLS profile.
>
>
> >
> > 2) Section 5.1: The paragraph about the "PSK identity hint" is unclear
> > tie in with the subsequent recommendation saying "A server using the
> > identity hint needs to guide the selection based on a received SNI
> > value from the client."?
>
> Thanks for asking.
>
> First, the client needs to tell the server some identifier so that it can select
> the right key when verifying the message. This is called the "PSK Identity".
>
> Then, there is also the capability in the TLS-PSK RFC to allow the server to
> indicate what key the client should use. This is the "PSK Identity Hint".
> Obviously, this is only an issue if the client has more than one PSK to begin
> with.
>
> The concept of this PSK identity hint was inspired by the realm parameter of
> the HTTP digest algorithm where a single server can host multiple resources
> and the server then challenges the client (or user) accordingly.
>
> In the IoT context the scenario is hopefully a bit simpler. I suspect that in
> normal circumstances the client will select the key based on the domain
> name.
>
> At the time when the TLS-PSK algorithm was written the concept of SNI did
> not exist since the use of hosted services wasn't that common. If someone
> would want to use a hosted environment for their IoT deployment then they
> would most likely support SNI.
>
> Does this make sense?
>
>
> >
> >
> Thanks for the editorial remarks. Will incorporate them into the next draft
> version.
>
> Ciao
> Hannes
>
> > René
> >
> >
> > Dipl.-Inform. Rene Hummen, Ph.D. Student Chair of Communication and
> > Distributed Systems RWTH Aachen University, Germany
> > tel: +49 241 80 21426

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Tue, 25 Nov 2014 10:35:09 +0000

> > If it is the former, do you know if they are flexible enough to
> > implement AES-CCM with different nonce lengths. The reason I ask is
> > because AES-CCM in IEEE 802.15.4 uses a nonce length of 13-octets
> > while DTLS uses 12-octets. I have heard of some15.4 chips that
> > hard-code (in hardware) the 13-octet nonce length making it useless
> > for DTLS.

Sandeep

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Tuesday, November 25, 2014 10:11 AM
> To: Kumar, Sandeep; Russ Housley; [email-masked]
> It is sometimes a bit hard to say whether functionality is implemented in
> software or in hardware since everything is hidden on the chip.
>
> firmware for this chip can be updated (and there are different versions of
> the firmware available). What exactly can be updated is something I don't
> know because the firmware image is provided by Nordic.
>
> chips as well. As such, in your final product you might end up having various
> places where you could run your cryptographic algorithms...
>
> When I looked at the specifications to answer your question I actually didn't
> find the needed info. Maybe I have not searched enough. I will get in touch
> with the guys at Nordic to figure it out for this specific example.
>
> Your question is obviously quite good and I believe we should put more text
> into the draft about this topic to give silicon vendors some guidance about
> what to provide.
>
>
> > If it is the former, do you know if they are flexible enough to
> > implement AES-CCM with different nonce lengths. The reason I ask is
> > because AES-CCM in IEEE 802.15.4 uses a nonce length of 13-octets
> > while DTLS uses 12-octets. I have heard of some15.4 chips that
> > hard-code (in hardware) the 13-octet nonce length making it useless
> > for DTLS.
> >> into their chips and they have indeed following that recommendation.
> >>
> >>> It seems to me that the two groups should talk to each other before
> >>> WG
> >> Last Call is over.
> >>>
> >>> Russ
> >>>
> > 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: Rene Struik <[email-masked]>
Date: Tue, 25 Nov 2014 10:30:20 -0500

Hi Hannes:

I raised the topic of deliberately incompatible nonce formats with 
draft-mcgrew-tls-aes-ccm-01 (August 5, 2011). At the time, people did 
not seem to care. For email archive, see, e.g., 
http://www.ietf.org/mail-archive/web/tls/current/msg07976.html.

The decision how to implement an AEAD cipher is of course up to the 
manufacturer. I know of several cases where chip vendors implemented a 
cipher for a MAC radio in hardware without any interface that would 
allow reuse of the same engine by a higher layer (in at least one case 
forcing a complete chip redesign due to this oversight).

Best regards, Rene

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 25 Nov 2014 16:53:54 +0100

On 11/25/2014 11:55 AM, Kumar, Sandeep wrote:
> This seems to be a good feature for authorization where the server
> can ask if the client possesses a specific key to perform operations
> on specific resources. Maybe this is not straightforward but
> something to keep in mind for ACE?

Might be worthwhile to keep in mind for the ACE work but I couldn't see
it as useful for the device-to-cloud communication.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 25 Nov 2014 17:03:08 +0100

Hi Rene,

> http://www.ietf.org/mail-archive/web/tls/current/msg07976.html.

Thanks for the pointer to the earlier discussion. I missed that
discussion thread.

> forcing a complete chip redesign due to this oversight).

I could imagine.

We should encourage chip manufacturers to make these functions available
for higher layer protocols. Maybe they just haven't thought about the
use case. Again something to capture in the document.

Ciao
Hannes

---

From: Rene Struik <[email-masked]>
Date: Tue, 25 Nov 2014 11:14:36 -0500

Hi Stephen:

Wifi devices (and, thereby, almost every consumer device on the planet that connects to the internet via a wireless link) use the CCM mode of operation. So, arguably your term "rest of the Internet" is somewhat imprecise.

BTW - while the CCM mode may be not that pretty from a mathematical appeal perspective, I do not see how it practically would fare worse than the GCM mode for typical IP packet sizes.

Best regards, Rene

==

---

From: Michael Richardson <[email-masked]>
Date: Tue, 25 Nov 2014 15:39:43 -0500

Rahman, Akbar <[email-masked]> wrote:
    > 2) In the abstract and elsewhere there are references to a constrained
    > device providing sensor data.  I think that this should be clarified.
    > If you read the CoAP spec [RFC 7252] you will clearly see that the
    > constrained device may either be read (GET - which corresponds to your
    > sensor examples), or the device may have some data loaded onto it (PUT,
    > POST, DELETE - and thus may be an actuator for example).  So you should
    > indicate the dual nature of constrained devices.

And isn't it also the case that a sensor might PUT/POST sensor data to the
device that wants it?  This is clearly the "lightswitch" -> "lightbulb"
situation, but also the (far too common today) sensor-behind-nat+cloud-storage situation.

A lightbulb might also GET it's current state from the cloud.

It seems that all combinations are possible.

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Tue, 25 Nov 2014 15:56:42 -0500

Hannes Tschofenig <[email-masked]> wrote:
    > would have noticed that it also talks briefly about email and XMPP
    > while there is other work in the group that provides much greater
    > detail on those topic. In the same spirit I see the IoT case as
    > something that does not belong in their document at all. TLS (and DTLS)
    > is just used in a number of different deployments and they are a bit
    > different.

There are DTLS uses in the Internet of "Web" which are not constrainted 
and do have hardware acceleration concerns.  This would include:
radius/diameter, SIP, RTP (under webrtc and also under XMPP/Jingle), and I
understand that DPRIVE (DNS privacy) considers DTLS too.

---

From: Ludwig Seitz <[email-masked]>
Date: Thu, 27 Nov 2014 10:04:01 +0100

> situation, but also the (far too common today) sensor-behind-nat+cloud-storage situation.

Just to support Michael's point:

Think about publish-subscribe scenarios, where the sensor might be the 
publisher that PUT/POSTs data to it's subscribers (or to an aggregator 
that manages the subscriptions).

/Ludwig

-- 
Ludwig Seitz, PhD
SICS Swedish ICT AB
Ideon Science Park
Building Beta 2
Scheelevägen 17
SE-223 70 Lund

Phone +46(0)70-349 92 51
http://www.sics.se

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 27 Nov 2014 10:40:57 +0100

Hi Ludwig,

I also do not see a problem with using PUT/POST by a sensor for
uploading data to some non-constrained server.

In an earlier message Akbar had, however, a different message exchange
in mind where the server-side issues a GET towards the sensor (instead
of having the sensor upload the data to the server):
http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00469.html

In http://trac.tools.ietf.org/wg/dice/trac/ticket/16 I made an attempt
to explain how his exchange can also be supported by the document as is.

Ciao
Hannes

On 11/27/2014 10:04 AM, Ludwig Seitz wrote:
>> constrained
>> situation, but also the (far too common today)
>> sensor-behind-nat+cloud-storage situation.
>>
>

---

From: "Kovatsch Matthias" <[email-masked]>
Date: Thu, 27 Nov 2014 12:54:30 +0000

> I also do not see a problem with using PUT/POST by a sensor for uploading data to some non-constrained server.

The main problem is that such devices must be pre-programmed with the address of the could service. It is somewhat the old model where you can actually use any kind of protocol since your device is tightly coupled with the service. No need for interoperability whatsoever.

For an infrastructure of IoT devices that can serve any application, you need the server role, both for DTLS and CoAP. The CoAP server can also serve for configuration of the client role to later act on some initiative and send requests. That means, the IoT device will also need DTLS client and server capabilities (just like many envisioned devices are also CoAP clients and servers; see core-interfaces for instance).

Ciao
Matthias

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 28 Nov 2014 13:07:26 +0100

Hi Alexey,

thanks for the great review.

I incorporated most of your comments. A few remarks below.

On 11/22/2014 08:08 PM, Alexey Melnikov wrote:
> On 11 Nov 2014, at 23:18, Dorothy Gellert <[email-masked]
> While I think this document is on the right track (and mostly fine),
> there is a number of editorial issues that makes figuring out some
> requirements difficult. I suggest a revision before IETF LC.
> 

Good point.

> Did you mean "with and without"?

I changed the entire paragraph to

"
   Before a client can initiate the DTLS handshake it needs to know the
   IP address of that server and what credentials to use.  Application
   layer protocols, such as CoAP, conveyed on top of DTLS may need
   additional information, such information about URLs of the endpoints
   the CoAP needs to register and publish information to.  This
   configuration information (including credentials) may be conveyed to
   clients as part of a firmware/software package or via a configuration
   protocol.
"

> 
> Section 4 is a good tutorial. Lots of Informative references are missing
> (e.g. for SHA1, SHA-256, AES, HMAC, CCM, GCM, etc)

Added.

> 
> In 5.1: is use of something like False Start common in IoT environment?
> As it reduces number of round trips, it might be advantageous and you
> should consider mentioning it.

Good question. I added it to the issue tracker:
https://tools.ietf.org/wg/dice/trac/ticket/20

> In particular, does it also apply to 5.1 and 5.3? Maybe you should move
> it somewhere else so that it is clear that it applies to all cases.
> 

Fixed.

>    Support of the cached info extension is

Fixed.

> In order to avoid any doubt, I would insert "as dNSName" here.

Done.

> I think the correct way to say that is: "or in the leftmost CN component

Done.

> I think you didn't intend dot here, maybe comma?

Fixed.

>       assumed that the DTLS context is still in kept 

Fixed.

> I couldn't figure out what you are trying to say here.

Changed the wording of the paragraph to:

"
   Server-Initiated Messages

      In the two previous scenarios the client initiated the protocol
      interaction but in this case we consider server-initiated
      messages.  Since messages to the client may get blocked by
      intermediaries, such as NATs (including IPv4/IPv6 protocol
      translators) and stateful packet filtering firewalls, the initial
      connection setup is triggered by the client and then kept alive.
      Since state at middleboxes expires fairly quickly (according to
      measurements described in [HomeGateway]), regular heartbeats are
      necessary whereby these keep-alive messages may be exchanged at
      the application layer or within DTLS itself.

      For this message exchange pattern the use of DTLS heartbeat
      messages is quite useful.  The MTU discovery mechanism, which is
      also part of [RFC6520], is less likely to be relevant since for
      many IoT deployments the most constrained link is the wireless
      interface between the IoT device and the network itself (rather
      than some links along the end-to-end path).  Only in more complex
      network topologies, such as multi-hop mesh networks, the situation
      is.
"

> Drop "support this extension".

Fixed.

>    recommended by this profile are not vulnerable this attack.
Fixed.

> While I-D.bmoeller-tls-downgrade-scsv is not currently needed, it might
> be useful when TLS 1.3/etc gets deployed and problems are found in TLS
> 1.2. Is this something we need to worry about in long term?
> 

I created an issue for this item:
https://tools.ietf.org/wg/dice/trac/ticket/21

> It is not clear what the above is trying to say. If this is explaining
> what renegotiation is, then it should be moved to the beginning of the
> same paragraph (I didn't include the first sentence of it). If this is a
> recommendation not to use renegotiation, then it needs rewording to make
> that clear.

I changed the text to:

"
18.  Re-Negotiation Attacks

   TLS and DTLS allows a client and a server who already have a TLS
   connection to negotiate new parameters, generate new keys, etc by
   using a feature in TLS called re-negotiation.  Renegotiation happens
   in the existing TLS connection, with the new handshake packets being
   encrypted along with application data.  Upon completion of the re-
   negotiation procedure the new channel replaces the old channel.

   As described in RFC 5746 [RFC5746] there is no cryptographic binding
   between the two handshakes, although the new handshake is carried out
   using the cryptographic parameters established by the original
   handshake.

   To prevent the TLS re-negotiation attack [RFC5746] this specification
   RECOMMENDS not to use the TLS re-negotiation feature.  Clients MUST
   respond to server-initiated renegotiation attempts with an Alert
   message (no_renegotiation) and clients MUST NOT initiate them.
"

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 28 Nov 2014 13:57:02 +0100

Hi Rene,

although I responded to your remarks already I wanted to get back to you.

On 11/15/2014 08:05 AM, Rene Hummen wrote:
> constrained DTLS client and a constrained DTLS server, I have two main
> comments:
> 

Here is suggested text based on your remark, the feedback during the
last IETF meeting and from the DTLS over SMS draft:
http://trac.tools.ietf.org/wg/dice/trac/ticket/15

> identity hint needs to guide the selection based on a received SNI value

Here is my earlier feedback:
http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00452.html

> - The end of the introduction starting from “The design of DTLS is
> intentionally very similar to TLS.” could be moved into an own section,
> e.g., called “Overview of the DTLS Protocol”. In my opinion, this would
> further improve readability.
> 
> - In the third bullet point of the same paragraph, I would also remove
> the sentence about IKEv2 as this information is distracting with respect
> to the subsequent recommendation. To highlight what I mean, I am copying
> the text from the draft here:
> “... [The HelloVerifyRequest] is sent by the server and includes a
> stateless cookie, which is returned in a ClientHello message back to the
> server. This type of DoS protection mechanism has been incorporated into
> the design of IKEv2. Although the exchange is optional for the server to
> execute, a client implementation has to be prepared to respond to it.".
> 
> - It would may helpful for implementors to have a brief summary of the
> most important general recommendations at the end of the introduction.
> Something along the lines: “An implementation complying to this profile
> i) MUST not use compression for DTLS handshake messages, ii) MUST not
> use DTLS < 1.2, and MAY use any of the following authentication modes:
> PSK, raw public-key, certificates. Specific recommendations for each of
> these modes are given in sections 5 - 18.”
> 
> - Section 5.1: “Furthermore, credentials are provisioned into trusted
> hardware modules or in the firmware by the developers.” -> add
> “often/commonly/typically” as there may also be other forms of provisioning.

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

I added this additional overview section and made the suggested wording
changes.

Ciao
Hannes

---

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

Hi Alexey,

> https://tools.ietf.org/wg/dice/trac/ticket/20

I believe TLS False Start would be a good fit. I added a section about
it into the draft. Here is the text:

-----

25.  TLS False Start

   A full TLS handshake as specified in [RFC5246] requires two full
   protocol rounds (four flights) before the handshake is complete and
   the protocol parties may begin to send application data.

   An abbreviated handshake (resuming an earlier TLS session) is
   complete after three flights, thus adding just one round-trip time if
   the client sends application data first.

   If the conditions outlined in [I-D.bmoeller-tls-falsestart] are met,
   application data can be transmitted when the sender has sent its own
   "ChangeCipherSpec" and "Finished" messages.  This achieves an
   improvement of one round-trip time for full handshakes if the client
   sends application data first, and for abbreviated handshakes if the
   server sends application data first.

   The conditions for using the TLS False Start mechanism are met by the
   public-key-based ciphersuites in this document.  In summary, the
   conditions are

   o  Modern symmetric ciphers with an effective key length of 128 bits,
      such as AES-128-CCM

   o  Client certificate types, such as ECDHE_ECDSA

   o  Key exchange methods: ecdsa_sign

   Based on the improvement over a full roundtrip for the full TLS/DTLS
   exchange this specification RECOMMENDS the use of the TLS False Start
   mechanism when clients send application data first.

-----

Ciao
Hannes

---

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

Hi Michael,

a quick response to your remarks.

On 11/25/2014 09:56 PM, Michael Richardson wrote:
> radius/diameter,

Diameter does not use UDP.

https://tools.ietf.org/html/rfc7360 defines DTLS protection for RADIUS
but I do not know how widely it is used. I am also not sure whether any
deployment experience had been taken into account with regard to RADIUS
in the UTA document. If I remember correctly then there was more
interest in supporting a TCP/TLS transport in RADIUS since the large
EAP-TLS packets caused problems for network access authentication.

 SIP, RTP (under webrtc and also under XMPP/Jingle), and I

There has indeed been work on SRTP-based media security that used DTLS
and I was involved in that work. I have not followed it closely during
the last few years and the WebRTC work is a recent addition to it. I
believe a separate document would be needed to describe that use of DTLS
in form of a BCP since the communication model is somewhat different to
the others currently captured in the UTA documents. With VoIP we are
talking about a p2p exchange between two SIP devices/two browsers rather
than the classical client-server interaction. I believe there are enough
differences to cover that in a separate document.

> understand that DPRIVE (DNS privacy) considers DTLS too.
This work has just been started and it might be a bit premature to put
it into a BCP document.

Ciao
Hannes

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Fri, 28 Nov 2014 21:38:11 +0100

>    mechanism when clients send application data first.

TLS false start is only described in an expired draft since 2010. Apart
from taking the TLS security guarantees to its limits (attacks that may
require significant online effort on TLS can be converted to off-line
attacks with false start), and having very little review from crypto
community, there is no guarantee that an IETF false start (or even an
informational RFC of the same document) would be compatible with it. So
at least a more stable reference should available before recommending it
in a standard's track document.

regards,
Nikos

---

From: Hannes Tschofenig <[email-masked]>
Date: Sat, 29 Nov 2014 10:08:47 +0100

Hi Nikos,

when I attend the TLS interim meeting in Paris I got a different
perception about the status of the TLS False Start work.

First, I was told that TLS False Start is widely deployed.

Second, the TLS chairs asked Bodo to resubmit his document and to push
it through the standardization process.

Here is a recent mail to the TLS mailing list on that topic:
http://www.ietf.org/mail-archive/web/tls/current/msg14530.html

Here is the recently submitted draft:
http://tools.ietf.org/html/draft-bmoeller-tls-falsestart-01

Finally, the text I propose for the DTLS profile draft recommends its
usage but does not mandate the implementation nor the deployment.

I did, however, had questions when reading through the draft in terms of
applicability for the IoT context, which I raised on the TLS mailing
list yesterday:
http://www.ietf.org/mail-archive/web/tls/current/msg14787.html

Ciao
Hannes