Subject: [TLS] Should CCM_8 CSs be Recommended?

From: Sean Turner <[email-masked]>
Date: Tue, 3 Oct 2017 15:53:59 -0700

In the IANA registries draft (https://github.com/tlswg/draft-ietf-tls-iana-registry-updates), we’ve added a recommended column to the Cipher Suites (CSs) registry (and some others).  Right now, the criteria for getting a recommended mark is AEAD ciphers with strong authentication standards track ciphers.  While that’s great generally, the list we’ve got five CSs that gave Joe and I pause:

TLS_DHE_RSA_WITH_AES_128_CCM_8
TLS_DHE_RSA_WITH_AES_256_CCM_8
TLS_PSK_DHE_WITH_AES_128_CCM_8
TLS_PSK_DHE_WITH_AES_256_CCM_8
TLS_ECDHE_PSK_WITH_AES_128_CCM_8_SHA256

The CCM_8 CSs have a significantly truncated authentication tag that represents a security trade-off that may not be appropriate for general environment.  In other words, this might be great for some IoT device but we should not generally be recommending these.

We’re recommending that these five suites be dropped from the recommended list.  Please let us know what you think.

J&S
(editor hats on)

---

From: Jim Schaad <[email-masked]>
Date: Tue, 3 Oct 2017 18:55:28 -0700

How much of a problem with people are we going to get into if the IoT profiles for the IETF go and say "You MUST use this algorithm which the IETF does not recommend?"

I think that this is very likely to get some strong push back from people I that is the case.  Reluctantly I think that we need to keep the recommendation on this algorithms.

> -----Original Message-----
> From: TLS [mailto:[email-masked]] On Behalf Of Sean Turner
> Sent: Tuesday, October 3, 2017 3:54 PM
> To: <[email-masked]> <[email-masked]>
> Subject: [TLS] Should CCM_8 CSs be Recommended?
> 
> In the IANA registries draft (https://github.com/tlswg/draft-ietf-tls-iana-
> registry-updates), we’ve added a recommended column to the Cipher Suites
> (CSs) registry (and some others).  Right now, the criteria for getting a
> recommended mark is AEAD ciphers with strong authentication standards
> track ciphers.  While that’s great generally, the list we’ve got five CSs that
> gave Joe and I pause:
> 
> The CCM_8 CSs have a significantly truncated authentication tag that
> represents a security trade-off that may not be appropriate for general
> environment.  In other words, this might be great for some IoT device but we
> should not generally be recommending these.
> 
> We’re recommending that these five suites be dropped from the
> recommended list.  Please let us know what you think.
> 
> J&S
> (editor hats on)
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 3 Oct 2017 19:54:42 -0700

Generally I tend to agree we should remove these, but as Jim said, there
are reasons where I guess they make sense. Could we add a "Special
Circumstances" marking?

-Ekr

On Tue, Oct 3, 2017 at 3:53 PM, Sean Turner <[email-masked]> wrote:

> In the IANA registries draft (https://github.com/tlswg/
> draft-ietf-tls-iana-registry-updates), we’ve added a recommended column
> to the Cipher Suites (CSs) registry (and some others).  Right now, the
> criteria for getting a recommended mark is AEAD ciphers with strong
> authentication standards track ciphers.  While that’s great generally, the
> list we’ve got five CSs that gave Joe and I pause:
>
> environment.  In other words, this might be great for some IoT device but
> we should not generally be recommending these.
>

---

From: Yoav Nir <[email-masked]>
Date: Wed, 4 Oct 2017 10:30:26 +0300

What we did in IPsec in RFC-tp-be 8221 is the following.  This (including the IoT marker) is also going to appear in the IANA registry:
    +-------------------------+------------+---------+----------------+
    | Name                    | Status     | AEAD    | Comment        |
    +-------------------------+------------+---------+----------------+
    | ENCR_DES_IV64           | MUST NOT   | No      | UNSPECIFIED    |
    | ENCR_DES                | MUST NOT   | No      | [RFC2405]      |
    | ENCR_3DES               | SHOULD NOT | No      | [RFC2451]      |
    | ENCR_BLOWFISH           | MUST NOT   | No      | [RFC2451]      |
    | ENCR_3IDEA              | MUST NOT   | No      | UNSPECIFIED    |
    | ENCR_DES_IV32           | MUST NOT   | No      | UNSPECIFIED    |
    | ENCR_NULL               | MUST       | No      | [RFC2410]      |
    | ENCR_AES_CBC            | MUST       | No      | [RFC3602][1]   |
    | ENCR_AES_CCM_8          | SHOULD     | Yes     | [RFC4309](IoT) |
    | ENCR_AES_GCM_16         | MUST       | Yes     | [RFC4106][1]   |
    | ENCR_CHACHA20_POLY1305  | SHOULD     | Yes     | [RFC7634]      |
    +-------------------------+------------+---------+----------------+

   [1] - This requirement level is for 128-bit and 256-bit keys. 192-bit
   keys remain at the MAY level.

   (IoT) - This requirement is for interoperability with IoT.  Only
   128-bit keys are at the given level.

   IPsec sessions may have very long lifetime and carry multiple
   packets, so there is a need to move to 256-bit keys in the long term.

> On 4 Oct 2017, at 5:54, Eric Rescorla <[email-masked]> wrote:
> 
> Generally I tend to agree we should remove these, but as Jim said, there are reasons where I guess they make sense. Could we add a "Special Circumstances" marking?
> 
> -Ekr
> 
> 
> On Tue, Oct 3, 2017 at 3:53 PM, Sean Turner <[email-masked] <mailto:[email-masked]>> wrote:
> In the IANA registries draft (https://github.com/tlswg/draft-ietf-tls-iana-registry-updates <https://github.com/tlswg/draft-ietf-tls-iana-registry-updates>), we’ve added a recommended column to the Cipher Suites (CSs) registry (and some others).  Right now, the criteria for getting a recommended mark is AEAD ciphers with strong authentication standards track ciphers.  While that’s great generally, the list we’ve got five CSs that gave Joe and I pause:
> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/tls <https://www.ietf.org/mailman/listinfo/tls>
>

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 4 Oct 2017 11:58:23 +0000

➢  We’re recommending that these five suites be dropped from the recommended list.  Please let us know what you think.

Does “recommended” mean for general use, in the public Internet?  Or is it “I know it when I see it” kind of thing?

Either way, I support un-recommending them

---

From: Russ Housley <[email-masked]>
Date: Wed, 4 Oct 2017 09:29:30 -0400

> On Oct 4, 2017, at 3:30 AM, Yoav Nir <[email-masked]> wrote:
> 
If the IoT environment is willing to accept lower integrity protection in order to save a few bits on the wire/ether, I do not see why the specification also forces them from using a larger key size.

Russ

---

From: Yoav Nir <[email-masked]>
Date: Wed, 4 Oct 2017 16:48:59 +0300

> On 4 Oct 2017, at 16:29, Russ Housley <[email-masked]> wrote:
> 
> 
>> On Oct 4, 2017, at 3:30 AM, Yoav Nir <[email-masked] <mailto:[email-masked]>> wrote:
>> 

Maybe to save a few cycles in addition to the few bits?  They claimed that the one AEAD cipher they needed was AES_CCM_8 with a 128-bit key, because that was all that their hardware supports.

What we are saying is that if you want your (in that case IPsec, but it’s no different for TLS) to work with IoT devices, you need that AEAD cipher.

Yoav

---

From: Russ Housley <[email-masked]>
Date: Wed, 4 Oct 2017 09:56:51 -0400

> On Oct 4, 2017, at 9:48 AM, Yoav Nir <[email-masked]> wrote:
> 
> 
>> On 4 Oct 2017, at 16:29, Russ Housley <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 

Right, but is there any reason to restrict CCM_8 to 128-bit keys in the IANA registry entry?  I can't see one.

Russ

---

From: Don Sturek <[email-masked]>
Date: Wed, 04 Oct 2017 07:46:41 -0700

Hi Russ,

At the upcoming IEEE 802.15 meeting in Orlando, we (vendors using IEEE
802.15.4) plan a presentation on support for AES-256 in an upcoming version
of the 802.15.4 standard.

In the Wi-SUN Alliance, we are using TLS-ECDHE-ECDSA-WITH-AES-128-CCM-8 now.
It would be great to at least not prevent support for a longer key version
of that going forward.

Don Sturek

From:  TLS <[email-masked]> on behalf of Russ Housley
<[email-masked]>
Date:  Wednesday, October 4, 2017 at 6:56 AM
To:  Yoav Nir <[email-masked]>
Cc:  IETF TLS <[email-masked]>
Subject:  Re: [TLS] Should CCM_8 CSs be Recommended?

>> If the IoT environment is willing to accept lower integrity protection in
>> order to save a few bits on the wire/ether, I do not see why the
>> specification also forces them from using a larger key size.
> 
> Maybe to save a few cycles in addition to the few bits?  They claimed that the
> one AEAD cipher they needed was AES_CCM_8 with a 128-bit key, because that was
> all that their hardware supports.
> 
> What we are saying is that if you want your (in that case IPsec, but it¹s no
> different for TLS) to work with IoT devices, you need that AEAD cipher.

Right, but is there any reason to restrict CCM_8 to 128-bit keys in the IANA
registry entry?  I can't see one.

Russ

_______________________________________________ TLS mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/tls

---

From: Joseph Salowey <[email-masked]>
Date: Wed, 4 Oct 2017 11:41:49 -0700

The current editor's copy of the draft has the following text about the
recommended column:

The instructions in this document add a recommended column to many of the
TLS registries to indicate parameters that are generally recommended for
implementations to support. Adding a recommended parameter to a registry or
updating a parameter to recommended status requires standards action. Not
all parameters defined in standards track documents need to be marked as
recommended.

If an item is marked as not recommended it does not necessarily mean that
it is flawed, rather, it indicates that either the item has not been
through the IETF consensus process or the item has limited applicability to
specific cases.

On Wed, Oct 4, 2017 at 4:58 AM, Salz, Rich <[email-masked]> wrote:

> ➢  We’re recommending that these five suites be dropped from the

---

From: Andrei Popov <[email-masked]>
Date: Wed, 4 Oct 2017 19:11:08 +0000

It seems that CCM_8 falls in the “limited applicability” bucket. However, there’s nothing wrong with IoT specs requiring these ciphers in their TLS profiles.

Cheers,

Andrei

From: TLS [mailto:[email-masked]] On Behalf Of Joseph Salowey
Sent: Wednesday, October 4, 2017 11:42 AM
To: Salz, Rich <[email-masked]>
Cc: <[email-masked]> <[email-masked]>
Subject: Re: [TLS] Should CCM_8 CSs be Recommended?

The current editor's copy of the draft has the following text about the recommended column:

The instructions in this document add a recommended column to many of the TLS registries to indicate parameters that are generally recommended for implementations to support. Adding a recommended parameter to a registry or updating a parameter to recommended status requires standards action. Not all parameters defined in standards track documents need to be marked as recommended.

If an item is marked as not recommended it does not necessarily mean that it is flawed, rather, it indicates that either the item has not been through the IETF consensus process or the item has limited applicability to specific cases.

On Wed, Oct 4, 2017 at 4:58 AM, Salz, Rich <[email-masked]<mailto:[email-masked]>> wrote:
➢  We’re recommending that these five suites be dropped from the recommended list.  Please let us know what you think.

_______________________________________________
TLS mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tls<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Ftls&data=02%7C01%7CAndrei.Popov%40microsoft.com%7Cd45d59ecd00a42ed5d8c08d50b57a4ce%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636427393411700505&sdata=hHQFFOVxYxpz0uibh1EQjhzOZVlhIE5nW8cX5Uvd3Bo%3D&reserved=0>

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 4 Oct 2017 19:37:07 +0000

*   If an item is marked as not recommended it does not necessarily mean that it is flawed, rather, it indicates that either the item has not been through the IETF consensus process or the item has limited applicability to specific cases.
Perhaps change the list “to” to “intended for” ?

---

From: Sean Turner <[email-masked]>
Date: Thu, 5 Oct 2017 09:43:01 -0700

I put this in a PR:
https://github.com/tlswg/draft-ietf-tls-iana-registry-updates/pull/46/files

spt

> On Oct 4, 2017, at 12:37, Salz, Rich <[email-masked]> wrote:
>

---

From: Sean Turner <[email-masked]>
Date: Thu, 5 Oct 2017 09:45:38 -0700

This is exactly how I think about it.

spt

> On Oct 4, 2017, at 12:11, Andrei Popov <[email-masked]> wrote:
>

---

From: Robert Cragie <[email-masked]>
Date: Thu, 5 Oct 2017 17:57:58 +0100

The original requirement for the truncated (_8) authentication tags was
purely to save bytes. It makes very little difference re. processing as a
16 octet tag is always computed in AES-CCM-128 anyway.

I agree with the assessment that it is "limited applicability" in the grand
scheme of things although it may be more ubiquitous in IoT applications.

Robert

On 5 October 2017 at 17:45, Sean Turner <[email-masked]> wrote:

> > It seems that CCM_8 falls in the “limited applicability” bucket.
> However, there’s nothing wrong with IoT specs requiring these ciphers in
> their TLS profiles.
> >
> > Cheers,
> >
> > Andrei
> >
> > The instructions in this document add a recommended column to many of
> the TLS registries to indicate parameters that are generally recommended
> for implementations to support. Adding a recommended parameter to a
> registry or updating a parameter to recommended status requires standards
> action. Not all parameters defined in standards track documents need to be
> marked as recommended.
> >
> > If an item is marked as not recommended it does not necessarily mean
> that it is flawed, rather, it indicates that either the item has not been
> > Does “recommended” mean for general use, in the public Internet?  Or is
> it “I know it when I see it” kind of thing?
> >

---

From: Sean Turner <[email-masked]>
Date: Mon, 9 Oct 2017 19:05:23 -0400

Anybody else has thoughts on this?

spt

> On Oct 3, 2017, at 18:53, Sean Turner <[email-masked]> wrote:
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 9 Oct 2017 16:10:17 -0700

I think this text is good. I suggest "Not Recommended" with a note, and if
the IoT groups want to publish their own document updating that note, that
would work.

-Ekr

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 13 Oct 2017 11:49:04 +0200

CCM_8 is used in the IoT space because some SDOs believed that they need
to optimize the transmission overhead. Clearly, this is not meant for
general purpose use but rather for IoT only.

Is it a good idea to truncate the authentication tag? I don't have an
opinion about that but that's what the specifications make you use and
that's also what is now in hardware.

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 18 Oct 2017 14:23:19 -0500

I agree with "everyone"; it seems like these fall into what "not
recommended" is intended to encompass.  I don't have a preference for
whether there's an extra annotation about IoT usage.

-Ben