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 <smyslov.i...@gmail.com> Date: Friday, 8 December 2023 at 13:24 To: John Mattsson <john.matts...@ericsson.com>, 'Sean Turner' <s...@sn3rd.com>, 'Salz, Rich' <rs...@akamai.com> Cc: 'TLS List' <tls@ietf.org> 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:john.matts...@ericsson.com] 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 <smyslov.i...@gmail.com> Date: Wednesday, 6 December 2023 at 19:04 To: John Mattsson <john.matts...@ericsson.com>, 'Sean Turner' <s...@sn3rd.com>, 'Salz, Rich' <rs...@akamai.com> Cc: 'TLS List' <tls@ietf.org> 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 <s...@sn3rd.com> Date: Wednesday, 6 December 2023 at 14:55 To: Salz, Rich <rs...@akamai.com>, John Mattsson <john.matts...@ericsson.com> Cc: TLS List <tls@ietf.org> Subject: Re: [TLS] "Notes" column in draft-ietf-tls-rfc8447bis? > On Dec 6, 2023, at 08:02, Salz, Rich <rsalz=40akamai....@dmarc.ietf.org> > 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
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
