Re: [TLS] "Notes" column in draft-ietf-tls-rfc8447bis?

[John Mattsson <[e-mail]>]

Hi Valery,

>First, the rekeying is not per-packet, but per n packets,
>where n depends on the suite and varies from 1 to 8192
>(as per table 1, Section 4.1, RFC 9367, constant C_3).

Thanks for the clarification. So, if I understand correctly, the rekeying frequency is 2^64 – C_3 and is fixed per cipher suite.

>And second, the packet protection key
>depends only on the corresponding application traffic secret
>and on the packet number, it can always be calculated
>if the packet number is known. Both DTLS and QUIC
>bear sequence numbers in packets, so
>there seem to be no major obstacles for using GOST suites in them
>(I didn’t evaluate their use myself, but similar construction
>is used for GOST ciphers in ESP, RFC 9227, and it works).


I think the ESP approach would work for GOST suites in DTLS 1.2. The difference is that sequence numbers are always encrypted in DTLS 1.3 and QUIC. With rekeying every 8192 records (TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L) I think you could update the epoch every time and things would work. With rekeying every record (TLS_GOSTR341112_256_WITH_MAGMA_MGM_S) you would not be able to rely on epoch for out of order records and I think the receiver might need to try several keys before finding the correct one.



Cheers,

John Preuß Mattsson

From: Valery Smyslov <[e-mail]>
Date: Friday, 8 December 2023 at 13:24
To: John Mattsson <[e-mail]>, 'Sean Turner' <[e-mail]>, 'Salz, Rich' <[e-mail]>
Cc: 'TLS List' <[e-mail]>
Subject: RE: [TLS] "Notes" column in draft-ietf-tls-rfc8447bis?
Hi John,

two more clarifications regarding GOST suites.

First, the rekeying is not per-packet, but per n packets,
where n depends on the suite and varies from 1 to 8192
(as per table 1, Section 4.1, RFC 9367, constant C_3).

And second, the packet protection key
depends only on the corresponding application traffic secret
and on the packet number, it can always be calculated
if the packet number is known. Both DTLS and QUIC
bear sequence numbers in packets, so
there seem to be no major obstacles for using GOST suites in them
(I didn’t evaluate their use myself, but similar construction
is used for GOST ciphers in ESP, RFC 9227, and it works).

Regards,
Valery.



From: John Mattsson [mailto:[e-mail]]
Sent: Friday, December 08, 2023 12:31 PM
To: Valery Smyslov; 'Sean Turner'; 'Salz, Rich'
Cc: 'TLS List'
Subject: Re: [TLS] "Notes" column in draft-ietf-tls-rfc8447bis?

Hi,

Valery Smyslov wrote:
>No, they include only hash (GOSTR341112) and AEAD cipher (MAGMA_MGM or KUZNYECHIK_MGM).
>Their order in the names is unusual (hash first, cipher second).

Yes, my misunderstanding based on the weird naming order. So nothing weird technically.


Ilari Liusvaara wrote:
>Also,
>
>0x00,0xC6 TLS_SM4_GCM_SM3
>0x00,0xC7 TLS_SM4_CCM_SM3
>
>Both are explicitly flagged as not OK for DTLS. However, using GCM/CCM
>in usual way, so not difficult to define how those would work in DTLS
>or QUIC (just copy what AES-128 does there).

Yes, I agree that would be straightforward. But it has not been done yet.

Ilari Liusvaara wrote:
>If the _ECCPWD_ ones work for TLS 1.3, why wouldn't those work for DTLS
>1.3 or QUIC? Those ciphersuites use AES in standard way, and DTLS/QUIC
>do serialize the flights.

Yes, you are correct that they should work. DTLS 1.3 and QUIC defined header protection for all cipher suites that use AES.

Ilari Liusvaara wrote:
>Well, _ECCPWD_ is just special snowflake as it modifies the key
>exchange (I haven't checked if what it does actually works).

Feels to me like it would have been good if _ECCPWD_ TLS 1.3 cipher suites had never been registered. What should have been done is to register TLS_AES_256_CCM_SHA384 together with some new key exchange or extentions....

Below is an updated table of TLS 1.3 cipher suites based on Ilari’s comments. One day I hope most of this info will be easy to extract from the IANA registry.
Value
Description
DTLS 1.3
QUIC
Comment
0x00,0xC6
TLS_SM4_GCM_SM3
N
N
Would be straightforward to specify use in DTLS 1.3 and QUIC
0x00,0xC7
TLS_SM4_CCM_SM3
N
N
Would be straightforward to specify use in DTLS 1.3 and QUIC
0x13,0x01
TLS_AES_128_GCM_SHA256
Y
Y
0x13,0x02
TLS_AES_256_GCM_SHA384
Y
Y
0x13,0x03
TLS_CHACHA20_POLY1305_SHA256
Y
Y
0x13,0x04
TLS_AES_128_CCM_SHA256
Y
Y
0x13,0x05
TLS_AES_128_CCM_8_SHA256
Y
N
QUIC RFC states MUST NOT use
0x13,0x06
TLS_AEGIS_256_SHA512
Y
Y
0x13,0x07
TLS_AEGIS_128L_SHA256
Y
Y
0xC0,0xB0
TLS_ECCPWD_WITH_AES_128_GCM_SHA256
Y
Y
0xC0,0xB1
TLS_ECCPWD_WITH_AES_256_GCM_SHA384
Y
Y
0xC0,0xB2
TLS_ECCPWD_WITH_AES_128_CCM_SHA256
Y
Y
0xC0,0xB3
TLS_ECCPWD_WITH_AES_256_CCM_SHA384
Y
Y
0xC0,0xB4
TLS_SHA256_SHA256
N
N
Impossible to use in DTLS 1.3 and QUIC as NULL encryption is used.
0xC0,0xB5
TLS_SHA384_SHA384
N
N
Impossible to use in DTLS 1.3 and QUIC as NULL encryption is used.
0xC1,0x03
TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L
N
N
Not straightforward to specify use in DTLS 1.3 and QUIC due to per-packet rekeying
0xC1,0x04
TLS_GOSTR341112_256_WITH_MAGMA_MGM_L
N
N
Not straightforward to specify use in DTLS 1.3 and QUIC due to per-packet rekeying
0xC1,0x05
TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S
N
N
Not straightforward to specify use in DTLS 1.3 and QUIC due to per-packet rekeying
0xC1,0x06
TLS_GOSTR341112_256_WITH_MAGMA_MGM_S
N
N
Not straightforward to specify use in DTLS 1.3 and QUIC due to per-packet rekeying

Cheers,
John

From: Valery Smyslov <[e-mail]>
Date: Wednesday, 6 December 2023 at 19:04
To: John Mattsson <[e-mail]>, 'Sean Turner' <[e-mail]>, 'Salz, Rich' <[e-mail]>
Cc: 'TLS List' <[e-mail]>
Subject: RE: [TLS] "Notes" column in draft-ietf-tls-rfc8447bis?
Hi John,

just a clarification:


The _GOSTR341112_ seems to include authentication and key exchange…. I did not think this was how TLS 1.3 cipher suites were supposed to be used.

            No, they include only hash (GOSTR341112) and AEAD cipher (MAGMA_MGM or KUZNYECHIK_MGM).
            Their order in the names is unusual (hash first, cipher second).

            Regards,
            Valery.

Cheers,
John Preuß Mattsson

From: Sean Turner <[e-mail]>
Date: Wednesday, 6 December 2023 at 14:55
To: Salz, Rich <[e-mail]>, John Mattsson <[e-mail]>
Cc: TLS List <[e-mail]>
Subject: Re: [TLS] "Notes" column in draft-ietf-tls-rfc8447bis?

> On Dec 6, 2023, at 08:02, Salz, Rich <rsalz=[e-mail]> wrote:
>
> Yes, I think information regarding if a cipher suite is for TLS 1.3 is very needed to have.  I already asked for that in
> https://mailarchive.ietf.org/arch/msg/tls/0gDKfXJvAemFDm7MWcS1DTDVIe8/
>
> In addition, I would also like to information if the cipher suite can be used in QUIC.
>
> The 8447bis draft added a notes column to every TLS registry. The “1.2 is frozen” draft says to use it to indicate things like “for TLS 1.3 and later”. It’s a free-form text field, so we can direct IANA to put anything we want. :)

Yep we added it via:
https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-cc6bdfdfb39824c6&q=1&e=9148a29f-ecfe-46e0-869e-33ffd8475127&u=https%3A%2F%2Fgithub.com%2Ftlswg%2Frfc8447bis%2Fpull%2F48

spt