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

[Valery Smyslov <[e-mail]>]

>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.
 
              Ah, I see. I didn’t realize that sequence numbers are encrypted.
              Yes, this adds some complexities. Thank you for pointing out.
 
              Regards,
              Valery.
 
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
<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-454445555731-cc6bdfdfb39824c6&q=1&e=9148a29f-ecfe-46e0-869e-33ffd8
475127&u=https%3A%2F%2Fgithub.com%2Ftlswg%2Frfc8447bis%2Fpull%2F48>
&q=1&e=9148a29f-ecfe-46e0-869e-33ffd8475127&u=https%3A%2F%2Fgithub.com%2Ftlswg%2Frfc8447bis%2Fpull%2F48

spt