Subject: Re: [Uta] Recommendations for Secure Use of TLS and DTLS

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 09 Dec 2014 11:36:46 +0100

Hi Orit,

On 11/16/2014 05:44 AM, Orit Levin (LCA) wrote:
> In addition, Section 5 contains the detailed discussion on the
> applicability of this BCP to various application protocols. XMPP is
> an example of an application to rely on the BCP as the baseline and
> specify further clarifications and/or deviations in
> https://tools.ietf.org/html/draft-ietf-uta-xmpp-03 . Email
> application (with its various entities and protocols) is the next on
> the UTA agenda. It would be great to see IoT following the same path,
> i.e. using the BCP baseline recommendations, either within or outside
> of UTA.

The problem is only that the communication and usage model of different
application protocols are very different.

Where do you best see this difference? For example, the UTA BCP
completely lacks the discussion about client authentication in TLS. This
is of course not very surprising if you come from an XMPP, Web, Email
world where client authentication happens at the application layer.

When it comes to the recommendations for the use of DTLS let us look at
the DTLS use in SIP. The problem there is that (a) the community that
has experience with DTLS in SIP (and media security in particular) is
not on this list and (b) there is not that much experience with DTLS in
SIP in the first place (at least compared to the experience of using TLS
in XMPP, Email and on the Web). Finally, again related to the
communication model one has to point out that the use of DTLS for SRTP
in SIP is not following the classical client-sever model but rather a
peer-to-peer model (as described in RFC 5763). For the use of DTLS in
WebRTC we can hardly speak about best current practice when we are
currently at the point of "oh it rings".

Ciao
Hannes

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 09 Dec 2014 11:36:51 +0100

Hi Peter,

thanks for trying to work out suitable text.

On 11/26/2014 03:46 AM, Peter Saint-Andre - &yet wrote:
>> Picking a "foo" I'd suggest adding this to 4.2 maybe
>>
>>    "There are some environments that have hardware support for
>>     AES-CCM but not AES-GCM. Where interoperability with such
>>     devices is needed, the TLS_ECDHE_ECDSA_WITH_AES_128_CCM
>>     ciphersuite is RECOMMENDED. There may also be niches where
>>     this kind of device cannot use that ciphersuite perhaps
>>     because they do not public key cryptography at all - this
>>     BCP does not cover those niches."
> 
> I haven't seen substantive comments on this proposal.

One possible reason for not getting these substantive comments is that
the relevant community is just not on this mailing list. There are other
groups, such as DICE, where these folks hang around.

> 
> Simplifying further, I suggest:
> 
>    Some devices have hardware support for AES-CCM but not AES-GCM.
>    There are even devices that do not public key cryptography at all.
>    This BCP does not cover such devices.

It is not clear what this BCP is not covering. Is it not covering
devices that do not even do public key crypto, is the statement focused
on devices that have hardware support for AES-CCM, or both? If an IoT
device does not have hardware support for AES-CCM does the UTA document
then apply?

It would also be nice to include a reference to the DTLS profile
document for the interested reader. (The DTLS profile document also
references the UTA BCP...)

Just to explain you a bit more about the concern I have. I am worried
that readers less involved in the IETF process (i.e., the audience I am
dealing with) suddenly sees 4 recommendations for TLS/DTLS. They will
get confused.

They get info about MTI from the TLS spec, one from CoAP (if they use
CoAP or some other application protocol), another one from the UTA BCP
document, and yet another from the DTLS profile.

Unfortunately, most of the recommendations contradict each other. The
underlying problem is that certain parts of the spec require changes
over time while others do not. The MTI for ciphersuites seems to change
somewhat frequently and issuing a new RFC ever time an old ciphersuite
becomes out-dated seems to be a challenge. (Of course, the UTA BCP nor
the DTLS profile document aim to tackle that problem; just saying...)

In any case, getting the embedded community to use standardized,
off-the-shelf security protocols is an up-hill battle. Adding confusion
isn't going to make it easier for us.

Ciao
Hannes

---

From: "Orit Levin (LCA)" <[email-masked]>
Date: Wed, 10 Dec 2014 07:28:08 +0000

Hannes,
I am commenting on this and the related thread.

The strong interest in the UTA work  (e.g., the number of  experts in different areas, who contributed to the bcp and the pressure to publish this bcp ASAP coming from multiple constituencies) indicate that the merits of publishing this document overweight your concern about confusing the community.

The goal of UTA is to document the best practices for using TLS (and using DTLS where it follows the TLS design) based on the lessons learned from  a range of popular applications that have been using TLS for quite some time. The idea behind the bcp is to analyze the situation and to provide guidance for those application communities that choose to use this information as an input to their application-specific recommendations. It is up to these communities to decide whether to extend, amend, or ignore the bcp altogether. I believe that the existing  text in the Introduction is very clear about that.

In the same time, TLS/DTLS features or modes of operations that haven't been deployed in various real life scenarios (yet), are left for future study to the most parts. DTLS with SIP and IoT are some of such examples. The next version of the bcp would certainly benefit if the experts in additional applications using TLS/DTLS share their experience and contribute to UTA going forward.

Cheers,
Orit.

> -----Original Message-----
> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Tuesday, December 09, 2014 2:37 AM
> To: Orit Levin (LCA); Leif Johansson; [email-masked]
> Subject: Re: [Uta] Recommendations for Secure Use of TLS and DTLS
> 
> Hi Orit,
>

---

From: Peter Saint-Andre - &yet <[email-masked]>
Date: Wed, 10 Dec 2014 20:52:40 -0700

> document, and yet another from the DTLS profile.

If you implement CoAP, use what the CoAP spec says.

If you implement XMPP, use what the XMPP spec says.

If you implement IMAP, use what the IMAP spec says.

Etc.

For XMPP, we've written a spec that builds on the UTA BCP (and that 
formally updates the core XMPP spec):

https://datatracker.ietf.org/doc/draft-ietf-uta-xmpp/

We could have similar specs for CoAP, IMAP, etc.

The UTA BCP basically says that this is the best we know at this time, 
in general, all other things being equal. But all other things are not 
always equal. If things are different for your application protocol, 
then write an Internet-Draft.

> Unfortunately, most of the recommendations contradict each other.

That's a strong claim.

> The
> becomes out-dated seems to be a challenge.

That's an exaggeration. We will keep this as up to date as we can. Step 
one is to get a first version of the BCP out the door.

> (Of course, the UTA BCP nor

It's unrealistic to expect one BCP to cover every particular application 
protocol, every implementation limitation, every deployment scenario. We 
have done the best we can based on everything we know about TLS in the 
most common scenarios and application communities. If the folks in a 
particular application community have needs that differ, they need to 
get organized and figure out what's best for them.

Hannes, I appreciate your concerns, but I don't see an actionable 
suggestion for what needs to change other than "please remove the 
contradictions and more clearly state that this doesn't apply to the 
community I represent". If you can propose text, that would be appreciated.

Peter

-- 
Peter Saint-Andre
CTO @ &yet
https://andyet.com/

---

From: Ralph Holz <[email-masked]>
Date: Thu, 11 Dec 2014 15:47:45 +1100

I am with Peter on this one. I could imagine that we add a sentence to that
effect, too, and I hope Hannes would like to contribute one?

On 11 December 2014 at 14:52, Peter Saint-Andre - &yet <[email-masked]>
wrote:

> The UTA BCP basically says that this is the best we know at this time, in
> general, all other things being equal. But all other things are not always
> equal. If things are different for your application protocol, then write an
> Internet-Draft.
>
> have done the best we can based on everything we know about TLS in the most
> common scenarios and application communities. If the folks in a particular
> application community have needs that differ, they need to get organized
> and figure out what's best for them.
>
> _______________________________________________
> Uta mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/uta
>