Subject: Re: [Tls-reg-review] [IANA #1132414] Re: Request to register TLS integrity only cipher suites for TLS 1.3

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 9 Dec 2020 16:44:39 -0800

Digging up this old thread since we may have to revisit the DTLS-OK
value...
My AD review of draft-ietf-tls-dtls13 notes that the mechanism for sequence
number encryption makes some assumptions on the underlying cipher of the
AEAD construction.  One proposal for changing the draft to make different
assumptions that are more future-proof may involve setting DTLS-OK to 'N'
for these ciphers (https://github.com/tlswg/dtls13-spec/pull/166/files).
Regardless, the authors of this draft might do well to provide some
indication of the expected sequence number (non-)protection mechanism.

-Ben

On Thu, Dec 13, 2018 at 03:55:03AM +0000, Salz, Rich wrote:
> DLTS-OK is Y
> 
> On 12/12/18, 6:12 PM, "Sabrina Tanamal via RT" <[email-masked]> wrote:
> 
>     Hi Rich, all, 
>     
>     Sorry we have one more question. Can you let us know how to fill in the "DTLS-OK" column in the TLS Cipher Suites registry?
>     
>     Thanks,
>     
>     Sabrina Tanamal (filling in for Amanda)
>     Senior IANA Services Specialist
>     
>     On Wed Dec 12 16:51:20 2018, [email-masked] wrote:
>     > To avoid creating new holes, how about right after dragonfly:
>     > 0xC0,0xB3       TLS_ECCPWD_WITH_AES_256_CCM_SHA384      Y       N
>     > [RFC-harkins-tls-dragonfly-03]
>     > 0xC0,0xB4-FF    Unassigned
>     > 
>     > On 12/11/18, 8:29 PM, "Amanda Baber via RT" <iana-prot-
>     > [email-masked]> wrote:
>     > 
>     > Hi Rich,
>     > 
>     > Which values should we assign? There are a number of ranges available,
>     > and I haven't been able to find any text in RFC 8447 or RFC 8446 that
>     > identifies which section is for "Not Recommended" assignments:
>     > 
>     > https://www.iana.org/assignments/tls-parameters/tls-
>     > parameters.xhtml#tls-parameters-4
>     > 
>     > Thanks for your patience,
>     > 
>     > Amanda Baber
>     > Lead IANA Services Specialist
>     > 
>     > On Tue Dec 11 20:34:22 2018, [email-masked] wrote:
>     > > We discussed this and approve.  Please assign two numbers in the "not
>     > > recommended" space.
>     > >
>     > > Thanks!
>     > >
>     > > On 12/5/18, 2:54 PM, "Nancy Cam-Winget (ncamwing)"
>     > > <[email-masked]> wrote:
>     > >
>     > > > Contact Name:
>     > > > Nancy Cam-Winget
>     > > >
>     > > > Contact Email:
>     > > > [email-masked]
>     > > >
>     > > > Type of Assignment:
>     > > > "Not Recommended" TLS Cipher suite assignment
>     > > >
>     > > > Registry:
>     > > > TLS 1.3 cipher suite
>     > > >
>     > > > Description:
>     > > > At least two IoT (ODVA and IEC) forums are requesting the need for
>     > > > enabling TLS 1.3 with integrity only protection in the data plane.
>     > > > Under security considerations, we are not recommending this cipher
>     > > > suite to be widely used and note that no privacy is provided when
>     > > > this
>     > > > cipher suite is used and several use cases have been noted where
>     > > > privacy is not required.
>     > > >
>     > > > Additional Info:
>     > > > We have noted the use cases and security (and privacy)
>     > > > considerations
>     > > > in https://tools.ietf.org/html/draft-camwinget-tls-ts13-
>     > > > macciphersuites-01 as well as how the cipher suite would be used
>     > > > with
>     > > > TLS 1.3
>     > >
>     > >
>     > >
>     > > _______________________________________________
>     > > tls-reg-review mailing list
>     > > [email-masked]
>     > > https://www.ietf.org/mailman/listinfo/tls-reg-review
>     > >
>     > >
>     > 
>     > 
>     > 
>     
>     _______________________________________________
>     tls-reg-review mailing list
>     [email-masked]
>     https://www.ietf.org/mailman/listinfo/tls-reg-review
>     
> 
> _______________________________________________
> tls-reg-review mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls-reg-review

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 10 Dec 2020 02:54:07 +0000

Not sure what "these ciphers" means, but in retrospect it was ambiguous to say DTLS-OK because that doesn't have version info and DTLS 1.3 was still a draft.

On 12/9/20, 7:44 PM, "Benjamin Kaduk" <[email-masked]> wrote:

    for these ciphers (https://urldefense.com/v3/__https://github.com/tlswg/dtls13-spec/pull/166/files__;!!GjvTz_vk!Cgmij5Wt0oMzNbDoeK1U8AEo73neLzwjrH9H6QeltjN1eUHWkywBF_-zfT79$ ).

    -Ben

    On Thu, Dec 13, 2018 at 03:55:03AM +0000, Salz, Rich wrote:
    >     > https://urldefense.com/v3/__https://www.iana.org/assignments/tls-parameters/tls-__;!!GjvTz_vk!Cgmij5Wt0oMzNbDoeK1U8AEo73neLzwjrH9H6QeltjN1eUHWkywBF5GSbsmF$ 
    >     > > > in https://urldefense.com/v3/__https://tools.ietf.org/html/draft-camwinget-tls-ts13-__;!!GjvTz_vk!Cgmij5Wt0oMzNbDoeK1U8AEo73neLzwjrH9H6QeltjN1eUHWkywBF7v813C7$ 
    >     > > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls-reg-review__;!!GjvTz_vk!Cgmij5Wt0oMzNbDoeK1U8AEo73neLzwjrH9H6QeltjN1eUHWkywBF_vbCWlv$ 
    >     > >
    >     > >
    >     > 
    >     > 
    >     > 
    >     
    >     https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls-reg-review__;!!GjvTz_vk!Cgmij5Wt0oMzNbDoeK1U8AEo73neLzwjrH9H6QeltjN1eUHWkywBF_vbCWlv$ 
    >     
    > 
    > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls-reg-review__;!!GjvTz_vk!Cgmij5Wt0oMzNbDoeK1U8AEo73neLzwjrH9H6QeltjN1eUHWkywBF_vbCWlv$

---

From: Benjamin Kaduk <[email-masked]>
Date: Wed, 9 Dec 2020 18:56:35 -0800

Sorry, "these ciphers" was intended to mean TLS_SHA256_SHA256 and
TLS_SHA384_SHA384.

-Ben

---

From: Jack Visoky <[email-masked]>
Date: Thu, 10 Dec 2020 22:28:51 +0000

Hi,

This is a good question, thanks for raising it! Of course our intention is to allow for these ciphers to be used with DTLS, as I know of at least two use cases that are planned for these cipher suites with DTLS 1.3. 

For DTLS we'd expect that the sequence numbers would not use encryption. The DTLS 1.3 draft section 4.2.3 (Sequence Number Encryption) starts off with "In DTLS 1.3, when records are encrypted, record sequence numbers are also encrypted". I think we can use the reasoning that the record is not encrypted for these cipher suites so the sequence numbers are also not encrypted.

All that said, we should make this explicit in our RFC draft (https://datatracker.ietf.org/doc/draft-camwinget-tls-ts13-macciphersuites/). The draft already has some text on how to construct the DTLS plaintext, but it makes sense to explicitly state that there is no encryption applied to the sequence number. Does that sound reasonable?

Thanks,

--Jack 

-----Original Message-----
From: Benjamin Kaduk <[email-masked]> 
Sent: Wednesday, December 9, 2020 9:57 PM
To: Salz, Rich <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Jack Visoky <[email-masked]>
Subject: EXTERNAL: Re: [Tls-reg-review] [IANA #1132414] Re: Request to register TLS integrity only cipher suites for TLS 1.3

[Use caution with links & attachments]

Sorry, "these ciphers" was intended to mean TLS_SHA256_SHA256 and TLS_SHA384_SHA384.

-Ben

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 10 Dec 2020 23:01:40 +0000

> I think we can use the reasoning that the record is not encrypted for these cipher suites so the sequence numbers are also not encrypted.

>    All that said, we should make this explicit in our RFC 

Sounds good to me!

---

From: "Amanda Baber via RT" <[email-masked]>
Date: Fri, 11 Dec 2020 19:04:01 +0000

Hi all,

Is there any action for IANA here?

thanks,

Amanda Baber

On Thu Dec 10 23:04:10 2020, [email-masked] wrote:
> > I think we can use the reasoning that the record is not encrypted for
> > these cipher suites so the sequence numbers are also not encrypted.
>

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 11 Dec 2020 19:23:32 +0000

>    Is there any action for IANA here?

Not now.  And depending on how the reviews go, hopefully never.

---

From: Benjamin Kaduk <[email-masked]>
Date: Sun, 13 Dec 2020 18:29:24 -0800

> >    All that said, we should make this explicit in our RFC 

In the interest of clarity, this sounds good to me as well.

Thanks,

Ben