subject:"\[TLS\] RFC8447bis"

[TLS] I-D Action: draft-ietf-tls-rfc8447bis-09.txt

2024-04-30 Thread internet-drafts

Internet-Draft draft-ietf-tls-rfc8447bis-09.txt is now available. It is a work
item of the Transport Layer Security (TLS) WG of the IETF.

   Title:   IANA Registry Updates for TLS and DTLS
   Authors: Joe Salowey
Sean Turner
   Name:draft-ietf-tls-rfc8447bis-09.txt
   Pages:   18
   Dates:   2024-04-30

Abstract:

   This document updates the changes to TLS and DTLS IANA registries
   made in RFC 8447.  It adds a new value "D" for discouraged to the
   recommended column of the selected TLS registries.

   This document updates the following RFCs: 3749, 5077, 4680, 5246,
   5705, 5878, 6520, 7301, and 8447.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-rfc8447bis-09.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-rfc8447bis-09

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] -rfc8447bis: s15 ambiguity

2024-04-10 Thread Salz, Rich

> Hi! I submitted the following PR to address the point Rich and ekr discussed 
> about an ambiguity in s15 of -rfc8447bis:
> https://github.com/tlswg/rfc8447bis/pull/56


Looks good to me, thanks.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] -rfc8447bis: s15 ambiguity

2024-04-10 Thread Sean Turner

Hi! I submitted the following PR to address the point Rich and ekr discussed 
about an ambiguity in s15 of -rfc8447bis:
https://github.com/tlswg/rfc8447bis/pull/56

Cheers,
spt
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-08.txt

2024-01-30 Thread Salz, Rich

> Requests to experts for published documents tends to come from IANA directly. 
> But I think that your remedy is fine.

By my memory, about 80-90 percent come from IANA; some come directly to the TLS 
experts and we have to remember to CC them into the thread.  And requiring IANA 
to forward the request with knowing whether or not someone is a WG/RG chair 
seems a little burdensome on them.

If the WG/RG has consensus to ask for a codepoint, then it is reasonable to 
allow the codepoint to be assigned. So maybe add "Experts can approve 
registrations if the working or research group reaches consensus about the need 
for code point assignment and the chairs of a group request assignment."



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-08.txt

2024-01-30 Thread Martin Thomson

On Wed, Jan 31, 2024, at 07:16, Salz, Rich wrote:
>> This version incorporates all known issues. The authors believe this version 
>> is ready for WGLC.
>
> Yes, pretty much.  Two nits than can be fixed during AUTH48
>
> This sentence in Sec 15 confuses me:
>   For this reason, designated experts should decline code point 
> registrations for documents which have already been adopted or are 
> being proposed for adoption by IETF working groups or IRTF research 
> groups.
>
> Presumably, you want the RG/WG chair to make the request?   Or do you 
> mean "other than the TLS WG" ?

Requests to experts for published documents tends to come from IANA directly.  
But I think that your remedy is fine.

If the WG/RG has consensus to ask for a codepoint, then it is reasonable to 
allow the codepoint to be assigned.  So maybe add "Experts can approve 
registrations if the working or research group reaches consensus about the need 
for code point assignment and the chairs of a group request assignment."

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-08.txt

2024-01-30 Thread Salz, Rich

> This version incorporates all known issues. The authors believe this version 
> is ready for WGLC.

Yes, pretty much.  Two nits than can be fixed during AUTH48

This sentence in Sec 15 confuses me:
For this reason, designated experts should decline code point 
registrations for documents which have already been adopted or are being 
proposed for adoption by IETF working groups or IRTF research groups.

Presumably, you want the RG/WG chair to make the request?   Or do you mean 
"other than the TLS WG" ?

Also, a nit, sometimes the tense is not consistent. For example, Sec 5 says:
Ciphersuites marked as EXPORT use weak ciphers and were deprecated in 
TLS 1.1 [RFC4346].
Cipher suites marked as anon do not provide any authentication and are 
vulnerable to man-in-the-middle attacks and are deprecated in TLS 1.1 [RFC4346].
RC4 is a weak cipher and is deprecated in [RFC7465].

A mix of "were" "are" and "is" in three consecutive sentences :)



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-08.txt

2024-01-23 Thread Sean Turner

Hi! With author hat on,

This version incorporates all known issues.  The authors believe this version 
is ready for WGLC.

spt

> On Jan 23, 2024, at 13:43, internet-dra...@ietf.org wrote:
> 
> Internet-Draft draft-ietf-tls-rfc8447bis-08.txt is now available. It is a work
> item of the Transport Layer Security (TLS) WG of the IETF.
> 
>   Title:   IANA Registry Updates for TLS and DTLS
>   Authors: Joe Salowey
>Sean Turner
>   Name:    draft-ietf-tls-rfc8447bis-08.txt
>   Pages:   18
>   Dates:   2024-01-23
> 
> Abstract:
> 
>   This document updates the changes to TLS and DTLS IANA registries
>   made in RFC 8447.  It adds a new value "D" for discouraged to the
>   recommended column of the selected TLS registries.
> 
>   This document updates the following RFCs: 3749, 5077, 4680, 5246,
>   5705, 5878, 6520, 7301, and 8447.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-tls-rfc8447bis-08.html
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-rfc8447bis-08
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] I-D Action: draft-ietf-tls-rfc8447bis-08.txt

2024-01-23 Thread internet-drafts

Internet-Draft draft-ietf-tls-rfc8447bis-08.txt is now available. It is a work
item of the Transport Layer Security (TLS) WG of the IETF.

   Title:   IANA Registry Updates for TLS and DTLS
   Authors: Joe Salowey
Sean Turner
   Name:draft-ietf-tls-rfc8447bis-08.txt
   Pages:   18
   Dates:   2024-01-23

Abstract:

   This document updates the changes to TLS and DTLS IANA registries
   made in RFC 8447.  It adds a new value "D" for discouraged to the
   recommended column of the selected TLS registries.

   This document updates the following RFCs: 3749, 5077, 4680, 5246,
   5705, 5878, 6520, 7301, and 8447.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-rfc8447bis-08.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-rfc8447bis-08

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2023-12-08 Thread Valery Smyslov

>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 didnt 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 didnt 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 
Date: Friday, 8 December 2023 at 13:24
To: John Mattsson , 'Sean Turner' , 
'Salz, Rich' 
Cc: 'TLS List' 
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 didnt 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 Ilaris 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,0xB

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

2023-12-08 Thread John Mattsson

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 
Date: Friday, 8 December 2023 at 13:24
To: John Mattsson , 'Sean Turner' , 
'Salz, Rich' 
Cc: 'TLS List' 
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_KUZN

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

2023-12-08 Thread Valery Smyslov

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 didnt 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 Ilaris 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 
Date: Wednesday, 6 December 2023 at 19:04
To: John Mattsson , 'Sean Turner' , 
'Salz, Rich' 
Cc: 'TLS List' 
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).

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

2023-12-08 Thread John Mattsson

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 
Date: Wednesday, 6 December 2023 at 19:04
To: John Mattsson , 'Sean Turner' , 
'Salz, Rich' 
Cc: 'TLS List' 
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 
Date: Wednesday, 6 December 2023 at 14:55
To: Salz, Rich , John Mattsson 
Cc: TLS List 
Subject: Re: [TLS] "Notes" column in draft-ietf-tls-rfc8447bis?

> On Dec 6, 2023, at 08:02, Salz, Rich  
> 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-45444731-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

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

2023-12-06 Thread Valery Smyslov

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 
Date: Wednesday, 6 December 2023 at 14:55
To: Salz, Rich , John Mattsson 
Cc: TLS List 
Subject: Re: [TLS] "Notes" column in draft-ietf-tls-rfc8447bis?


> On Dec 6, 2023, at 08:02, Salz, Rich  
> 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-45444731-cc6bdfdfb39824c6
 
<https://protect2.fireeye.com/v1/url?k=31323334-501d5122-313273af-45444731-cc6bdfdfb39824c6&q=1&e=9148a29f-ecfe-46e0-869e-33ffd8475127&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

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2023-12-06 Thread Ilari Liusvaara

On Wed, Dec 06, 2023 at 03:46:32PM +, John Mattsson wrote:
> That sounds great.
> 
> Who is doing the work of adding “for TLS 1.3 and later”?
> 
> My understanding is that the currently registered TLS 1.3 cipher suites are:
> 
> Value Description
> 0x13,0x01 TLS_AES_128_GCM_SHA256
> 0x13,0x02 TLS_AES_256_GCM_SHA384
> 0x13,0x03 TLS_CHACHA20_POLY1305_SHA256
> 0x13,0x04 TLS_AES_128_CCM_SHA256
> 0x13,0x05 TLS_AES_128_CCM_8_SHA256
> 0x13,0x06 TLS_AEGIS_256_SHA512
> 0x13,0x07 TLS_AEGIS_128L_SHA256
> 0xC0,0xB0 TLS_ECCPWD_WITH_AES_128_GCM_SHA256
> 0xC0,0xB1 TLS_ECCPWD_WITH_AES_256_GCM_SHA384
> 0xC0,0xB2 TLS_ECCPWD_WITH_AES_128_CCM_SHA256
> 0xC0,0xB3 TLS_ECCPWD_WITH_AES_256_CCM_SHA384
> 0xC0,0xB4 TLS_SHA256_SHA256
> 0xC0,0xB5 TLS_SHA384_SHA384
> 0xC1,0x03 TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L
> 0xC1,0x04 TLS_GOSTR341112_256_WITH_MAGMA_MGM_L
> 0xC1,0x05 TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S
> 0xC1,0x06 TLS_GOSTR341112_256_WITH_MAGMA_MGM_S

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).

> Note that “for TLS 1.3 and later” and “DTLS-OK” is not enough as some
> cipher suites (the _ECCPWD_ ones) seem to be valid for TLS 1.2,
> TLS 1.3, DTLS 1.2 but not DTLS 1.3….

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.

> Do we need some guidance/requirements on naming and use of TLS 1.3
> cipher suites? The _ECCPWD_ ones seem to include authentication in
> the TLS 1.3. 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.

Well, _ECCPWD_ is just special snowflake as it modifies the key
exchange (I haven't checked if what it does actually works). The GOST
ciphers do not seem to do anything special with key exchange (unlike
other things like seemingly rekeying for every record), so those
presumably should just be TLS_KUZNYECHIK_* and TLS_MAGMA_*.

The rekey-every-record the GOST ciphers do could pose a problem for
defining a mapping to DTLS or QUIC... Unless doing it like AES-GCM
was added to SECSH (a.k.a. SSH).

-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2023-12-06 Thread Salz, Rich

I am not aware of any particular work to say which ciphers can be used where.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2023-12-06 Thread John Mattsson

That sounds great.

Who is doing the work of adding “for TLS 1.3 and later”?

My understanding is that the currently registered TLS 1.3 cipher suites are:

Value
Description
DTLS 1.3
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
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
N
N
0xC0,0xB1
TLS_ECCPWD_WITH_AES_256_GCM_SHA384
N
N
0xC0,0xB2
TLS_ECCPWD_WITH_AES_128_CCM_SHA256
N
N
0xC0,0xB3
TLS_ECCPWD_WITH_AES_256_CCM_SHA384
N
N
0xC0,0xB4
TLS_SHA256_SHA256
N
N
0xC0,0xB5
TLS_SHA384_SHA384
N
N
0xC1,0x03
TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_L
N
N
0xC1,0x04
TLS_GOSTR341112_256_WITH_MAGMA_MGM_L
N
N
0xC1,0x05
TLS_GOSTR341112_256_WITH_KUZNYECHIK_MGM_S
N
N
0xC1,0x06
TLS_GOSTR341112_256_WITH_MAGMA_MGM_S
N
N

(The DTLS 1.3 and QUIC information is my understanding. It is currently not in 
the IANA registry).

Note that “for TLS 1.3 and later” and “DTLS-OK” is not enough as some cipher 
suites (the _ECCPWD_ ones) seem to be valid for TLS 1.2, TLS 1.3, DTLS 1.2 but 
not DTLS 1.3….

I think the notes column should contain info on DTLS 1.3 and QUIC as well.

Do we need some guidance/requirements on naming and use of TLS 1.3 cipher 
suites?
The _ECCPWD_ ones seem to include authentication in the TLS 1.3. 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.

Cheers,
John Preuß Mattsson

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

> On Dec 6, 2023, at 08:02, Salz, Rich  
> 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-45444731-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

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

2023-12-06 Thread Sean Turner


> On Dec 6, 2023, at 08:02, Salz, Rich  
> 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://github.com/tlswg/rfc8447bis/pull/48

spt

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2023-12-06 Thread Salz, Rich

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. :)
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2023-12-05 Thread John Mattsson

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.

(It is very hard for someone to find out which cipher suites are usable for TLS 
1.3, DTLS 1.3, and QUIC)

Cheers,
John

From: TLS  on behalf of Salz, Rich 

Date: Thursday, 20 April 2023 at 21:17
To: tls@ietf.org 
Subject: [TLS] "Notes" column in draft-ietf-tls-rfc8447bis?
I’m starting to write the draft about TLS 1.2 being frozen.

It occurred to me that every TLS registry might need a “notes” column.  If 
someone defines a new crypto algorithm, sat AEGIS being considered in CFRG, we 
want to assign it a number but have a note saying “only for TLS 1.3 and later”
We could make it be a simple yes/no column, like “Pre-1.3?” but I think that’s 
needlessly terse.

Does that make sense?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-07.txt

2023-11-27 Thread Watson Ladd

On Mon, Nov 27, 2023 at 10:14 AM Sean Turner  wrote:
>
> Hi! -06 and -07 incorporate the “Comment” column that we discussed at IETF 
> 118.  Joe and I are planning to ask for WGLC on this version.

Minor quibble with the IANA instructions for instruction type. It
reads " Setting a value to "Y" or "D" in the "Recommended" column
requires IETF Standards Action [RFC8126].  Any state transition to or
from a "Y" or "D" value requires IESG Approval."  To me this is a bit
unclear: standards action is required to move a value to Y or D, but
then does IESG Approval kick in as well? Conversely is IESG approval
the only way to make something N? I think the answer to this as
written is yes, while the first one is genuinely unclear.

Sincerely,
Watson Ladd

-- 
Astra mortemque praestare gradatim

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-07.txt

2023-11-27 Thread Salz, Rich

> Hi! -06 and -07 incorporate the “Comment” column that we discussed at IETF 
> 118. Joe and I are planning to ask for WGLC on this version.


Looks good to me, thanks!

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-07.txt

2023-11-27 Thread Sean Turner

Hi! -06 and -07 incorporate the “Comment” column that we discussed at IETF 118. 
 Joe and I are planning to ask for WGLC on this version.

spt

> On Nov 27, 2023, at 10:11, internet-dra...@ietf.org wrote:
> 
> Internet-Draft draft-ietf-tls-rfc8447bis-07.txt is now available. It is a work
> item of the Transport Layer Security (TLS) WG of the IETF.
> 
>   Title:   IANA Registry Updates for TLS and DTLS
>   Authors: Joe Salowey
>Sean Turner
>   Name:    draft-ietf-tls-rfc8447bis-07.txt
>   Pages:   18
>   Dates:   2023-11-27
> 
> Abstract:
> 
>   This document updates the changes to TLS and DTLS IANA registries
>   made in RFC 8447.  It adds a new value "D" for discouraged to the
>   recommended column of the selected TLS registries.
> 
>   This document updates the following RFCs: 3749, 5077, 4680, 5246,
>   5705, 5878, 6520, 7301, and 8447.
> 
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/
> 
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-tls-rfc8447bis-07.html
> 
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-rfc8447bis-07
> 
> Internet-Drafts are also available by rsync at:
> rsync.ietf.org::internet-drafts
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] I-D Action: draft-ietf-tls-rfc8447bis-07.txt

2023-11-27 Thread internet-drafts

Internet-Draft draft-ietf-tls-rfc8447bis-07.txt is now available. It is a work
item of the Transport Layer Security (TLS) WG of the IETF.

   Title:   IANA Registry Updates for TLS and DTLS
   Authors: Joe Salowey
Sean Turner
   Name:draft-ietf-tls-rfc8447bis-07.txt
   Pages:   18
   Dates:   2023-11-27

Abstract:

   This document updates the changes to TLS and DTLS IANA registries
   made in RFC 8447.  It adds a new value "D" for discouraged to the
   recommended column of the selected TLS registries.

   This document updates the following RFCs: 3749, 5077, 4680, 5246,
   5705, 5878, 6520, 7301, and 8447.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-rfc8447bis-07.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-rfc8447bis-07

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] I-D Action: draft-ietf-tls-rfc8447bis-06.txt

2023-11-27 Thread internet-drafts

Internet-Draft draft-ietf-tls-rfc8447bis-06.txt is now available. It is a work
item of the Transport Layer Security (TLS) WG of the IETF.

   Title:   IANA Registry Updates for TLS and DTLS
   Authors: Joe Salowey
Sean Turner
   Name:draft-ietf-tls-rfc8447bis-06.txt
   Pages:   18
   Dates:   2023-11-27

Abstract:

   This document updates the changes to TLS and DTLS IANA registries
   made in RFC 8447.  It adds a new value "D" for discouraged to the
   recommended column of the selected TLS registries.

   This document updates the following RFCs: 3749, 5077, 4680, 5246,
   5705, 5878, 6520, 7301, and 8447.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-rfc8447bis-06.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-rfc8447bis-06

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] I-D Action: draft-ietf-tls-rfc8447bis-05.txt

2023-10-19 Thread internet-drafts

Internet-Draft draft-ietf-tls-rfc8447bis-05.txt is now available. It is a work
item of the Transport Layer Security (TLS) WG of the IETF.

   Title:   IANA Registry Updates for TLS and DTLS
   Authors: Joe Salowey
Sean Turner
   Name:draft-ietf-tls-rfc8447bis-05.txt
   Pages:   17
   Dates:   2023-10-19

Abstract:

   This document updates the changes to TLS and DTLS IANA registries
   made in RFC 8447.  It adds a new value "D" for discouraged to the
   recommended column of the selected TLS registries.

   This document updates the following RFCs: 3749, 5077, 4680, 5246,
   5705, 5878, 6520, 7301, and 8447.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-rfc8447bis-05.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-rfc8447bis-05

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

2023-06-15 Thread Rob Sayre

On Thu, Jun 15, 2023 at 13:37 Christopher Wood  wrote:

> Sorry for the delay. This slipped through the cracks. Given that we went
> through this process with the text as-is, I think we can live without this
> change.
>

Hi,

There were a bunch of boring suggestions in my message*. I hope Ekr
considers all of them. But, even if he disagrees on most, I made PRs for
the ones that were obvious or there seemed to be some agreement that things
could be improved:
https://github.com/tlswg/tls13-spec/pull/1316
https://github.com/tlswg/tls13-spec/pull/1317
https://github.com/tlswg/tls13-spec/pull/1318

On the subject of this consensus call, which I do not dispute, I made an
effort:
https://github.com/tlswg/tls13-spec/pull/1319

Aside from those, I'm a little worried that not enough WG members have read
the whole thing. That's just what I found, but that's only one reading.

thanks,
Rob

* https://mailarchive.ietf.org/arch/msg/tls/_8G7LKEPGdNSIjdaBo5tpWSNwj0/
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

2023-06-15 Thread Christopher Wood

On May 22, 2023, at 6:49 PM, Eric Rescorla  wrote:On Mon, May 22, 2023 at 1:09 PM Rob Sayre  wrote:On Mon, May 22, 2023 at 12:59 PM Christopher Wood  wrote:We trust the editors will faithfully enact all editorial changes they agree with as the document moves forward in the process. If there were non-editorial comments that we overlooked, could you please resurface them?Hi,I made these comments about 1.5 months ago, so I hope it doesn't seem like I'm requesting a particularly quick turnaround.Yes, this is my mistake. I just went through the Github issues and forgot to dealwith this e-mail. I will create a PR for these.There were a couple obvious corrections EKR agreed with, but aren't done. These should be fixed before IETF Last Call.The one real problem (imho) with the document is nested MUST requirements:https://mailarchive.ietf.org/arch/msg/tls/6x0uEVIUCBwMOIaV3UBzqeRt6Ys/EKR called this "guidance", but RFC 2119 says MUST is "an absolute requirement". The document needs to use the 2119 requirements language correctly. I understand the goal, which is to preserve wire-format compatibility in older TLS versions, even though they have security flaws.As you indicate, the context here is that RFC 8996 forbids TLS < 1.2, butwe know people might ignore that and thus this text is intended to providerequirements for people who do so. It's an inherently contradictory situation,but also the one we find ourselves in.With that in mind, you seem to be making three points:>   Note that [RFC8996] and Appendix E.5 forbid the negotation of TLS
>   versions below 1.2; implementations which do not follow that guidance
>   MUST behave as described above.Your complaint seems to boil down to the word "guidance", but the word used there doesn't have normative force, so I think this is an editorial issue.I agree we should also cite E.5, and I can cite that in my PR.Appendix E.5:
> >   The security of SSL 2.0 [SSL2], SSL 3.0 [RFC6101], TLS 1.0 [RFC2246],
> >   and TLS 1.1 [RFC4346] are considered insufficient for the reasons
> >   enumerated in [RFC6176], [RFC7568], and [RFC8996] and they MUST NOT
> >  be negotiated for any reason.

> Here, I would end with "...for any reason in applications that require a
> secure channel."I don't think that this is a good change. 8996 just flat out prohibits them and so we should match that.>> >   Implementations MUST NOT send an SSL version 2.0 compatible CLIENT-
> > HELLO.  Implementations MUST NOT negotiate TLS 1.3 or later using an
> > SSL version 2.0 compatible CLIENT-HELLO.  Implementations are NOT
> >  RECOMMENDED to accept an SSL version 2.0 compatible CLIENT-HELLO in
> >  order to negotiate older versions of TLS.
>
> Without the little trailing text I added above, this seems a little
> contradictory. The thinking here is the document says this is NOT
> RECOMMENDED, but it's something they MUST NOT do, unless you only mean TLS
> 1.2 here.
I don't see the problem here. You MUST NOT negotiate TLS < 1.2 and you are NOT RECOMMENDED to use  the SSLv2 CH to negotiate TLS 1.2.Perhaps your objection is to the use of the plural "older versions" but again, we know that some people will ignore the E.5 requirement and the point here is that even if they do so, they should still not do this.With all that said, if there is WG consensus to make these changes, I'll of course do so. Deferring to the chairs on how to proceed.Sorry for the delay. This slipped through the cracks. Given that we went through this process with the text as-is, I think we can live without this change. Best,Chris, for the chairs ___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

2023-06-03 Thread tom.ripe


On 22/05/2023 20:59, Christopher Wood wrote:

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls



Chris

Many, although not all, of your messages to the TLS list display the 
above and no more.  This is indeed what the message header says, with 
multipart/alternative but with only a text/html for anything more than 
the footing.


Please fix.

Tom Petch

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

2023-05-22 Thread Rob Sayre

On Mon, May 22, 2023 at 3:49 PM Eric Rescorla  wrote:

> On Mon, May 22, 2023 at 1:09 PM Rob Sayre  wrote:
>
>> The one real problem (imho) with the document is nested MUST requirements:
>> https://mailarchive.ietf.org/arch/msg/tls/6x0uEVIUCBwMOIaV3UBzqeRt6Ys/
>>
>> EKR called this "guidance", but RFC 2119 says MUST is "an absolute
>> requirement". The document needs to use the 2119 requirements language
>> correctly. I understand the goal, which is to preserve wire-format
>> compatibility in older TLS versions, even though they have security flaws.
>>
>
> As you indicate, the context here is that RFC 8996 forbids TLS < 1.2, but
> we know people might ignore that and thus this text is intended to provide
> requirements for people who do so. It's an inherently contradictory
> situation,
> but also the one we find ourselves in.
>

It doesn't seem like this text should be difficult to fix. The introduction
says "The primary goal of TLS is to provide a secure channel between two
communicating peers...".

Couldn't the document say that the <1.2 versions no longer meet this goal,
but nevertheless have compatibility requirements? That's a bit different
from calling a MUST "guidance". I think words matter here.

thanks,
Rob
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

2023-05-22 Thread Eric Rescorla

On Mon, May 22, 2023 at 1:09 PM Rob Sayre  wrote:

> On Mon, May 22, 2023 at 12:59 PM Christopher Wood 
> wrote:
>
>> We trust the editors will faithfully enact all editorial changes they
>> agree with as the document moves forward in the process. If there were
>> non-editorial comments that we overlooked, could you please resurface them?
>>
>
> Hi,
>
> I made these comments about 1.5 months ago, so I hope it doesn't seem like
> I'm requesting a particularly quick turnaround.
>

Yes, this is my mistake. I just went through the Github issues and forgot
to deal
with this e-mail. I will create a PR for these.

> There were a couple obvious corrections EKR agreed with, but aren't done.
> These should be fixed before IETF Last Call.
>
> The one real problem (imho) with the document is nested MUST requirements:
> https://mailarchive.ietf.org/arch/msg/tls/6x0uEVIUCBwMOIaV3UBzqeRt6Ys/
>
> EKR called this "guidance", but RFC 2119 says MUST is "an absolute
> requirement". The document needs to use the 2119 requirements language
> correctly. I understand the goal, which is to preserve wire-format
> compatibility in older TLS versions, even though they have security flaws.
>

As you indicate, the context here is that RFC 8996 forbids TLS < 1.2, but
we know people might ignore that and thus this text is intended to provide
requirements for people who do so. It's an inherently contradictory
situation,
but also the one we find ourselves in.

With that in mind, you seem to be making three points:

>   Note that [RFC8996] and Appendix E.5 forbid the negotation of TLS
>   versions below 1.2; implementations which do not follow that guidance
>   MUST behave as described above.

Your complaint seems to boil down to the word "guidance", but the word
used there doesn't have normative force, so I think this is an
editorial issue.

I agree we should also cite E.5, and I can cite that in my PR.

Appendix E.5:
> >   The security of SSL 2.0 [SSL2], SSL 3.0 [RFC6101], TLS 1.0 [RFC2246],
> >   and TLS 1.1 [RFC4346] are considered insufficient for the reasons
> >   enumerated in [RFC6176], [RFC7568], and [RFC8996] and they MUST NOT
> >  be negotiated for any reason.

> Here, I would end with "...for any reason in applications that require a
> secure channel."

I don't think that this is a good change. 8996 just flat out prohibits
them and so we should match that.

>
> >   Implementations MUST NOT send an SSL version 2.0 compatible CLIENT-
> > HELLO.  Implementations MUST NOT negotiate TLS 1.3 or later using an
> > SSL version 2.0 compatible CLIENT-HELLO.  Implementations are NOT
> >  RECOMMENDED to accept an SSL version 2.0 compatible CLIENT-HELLO in
> >  order to negotiate older versions of TLS.
>
> Without the little trailing text I added above, this seems a little
> contradictory. The thinking here is the document says this is NOT
> RECOMMENDED, but it's something they MUST NOT do, unless you only mean TLS
> 1.2 here.

I don't see the problem here. You MUST NOT negotiate TLS < 1.2 and you
are NOT RECOMMENDED to use  the SSLv2 CH to negotiate TLS 1.2.

Perhaps your objection is to the use of the plural "older versions"
but again, we know that some people will ignore the E.5 requirement
and the point here is that even if they do so, they should still not
do this.

With all that said, if there is WG consensus to make these changes,
I'll of course do so. Deferring to the chairs on how to proceed.

-Ekr

-Ekr

___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

2023-05-22 Thread Rob Sayre

On Mon, May 22, 2023 at 12:59 PM Christopher Wood 
wrote:

> We trust the editors will faithfully enact all editorial changes they
> agree with as the document moves forward in the process. If there were
> non-editorial comments that we overlooked, could you please resurface them?
>

Hi,

I made these comments about 1.5 months ago, so I hope it doesn't seem like
I'm requesting a particularly quick turnaround.

There were a couple obvious corrections EKR agreed with, but aren't done.
These should be fixed before IETF Last Call.

The one real problem (imho) with the document is nested MUST requirements:
https://mailarchive.ietf.org/arch/msg/tls/6x0uEVIUCBwMOIaV3UBzqeRt6Ys/

EKR called this "guidance", but RFC 2119 says MUST is "an absolute
requirement". The document needs to use the 2119 requirements language
correctly. I understand the goal, which is to preserve wire-format
compatibility in older TLS versions, even though they have security flaws.

The rest of my comments are at the editor's discretion, I agree.

thanks,
Rob
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

2023-05-22 Thread Christopher Wood

We trust the editors will faithfully enact all editorial changes they agree with as the document moves forward in the process. If there were non-editorial comments that we overlooked, could you please resurface them?Best,Chris On May 21, 2023, at 7:44 PM, Rob Sayre  wrote:On Fri, May 19, 2023 at 5:03 AM Christopher Wood  wrote:Thanks to everyone who provided reviews and feedback for these documents! I believe we have consensus to move both forward with changes that have been incorporated during the review cycle. We’ll start preparing the shepherd writeups and then move these on in the process.Hi,The comments I left are not addressed, even the fairly pedestrian corrections. EKR answered, although he certainly did not agree with all of them. For example, the label "resumption_master_secret" still appears, although that should have been changed in all instances.thanks,Rob 
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

2023-05-21 Thread Rob Sayre

On Fri, May 19, 2023 at 5:03 AM Christopher Wood 
wrote:

> Thanks to everyone who provided reviews and feedback for these documents!
> I believe we have consensus to move both forward with changes that have
> been incorporated during the review cycle. We’ll start preparing the
> shepherd writeups and then move these on in the process.
>

Hi,

The comments I left are not addressed, even the fairly pedestrian
corrections. EKR answered, although he certainly did not agree with all of
them. For example, the label "resumption_master_secret"
still appears, although that should have been changed in all instances.

thanks,
Rob
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

2023-05-19 Thread Christopher Wood

Thanks to everyone who provided reviews and feedback for these documents! I 
believe we have consensus to move both forward with changes that have been 
incorporated during the review cycle. We’ll start preparing the shepherd 
writeups and then move these on in the process.

Best,
Chris

> On Mar 28, 2023, at 9:00 PM, Christopher Wood  wrote:
> 
> As mentioned during yesterday's meeting, this email starts the working group 
> last call for "The Transport Layer Security (TLS) Protocol Version 1.3" and 
> "IANA Registry Updates for TLS and DTLS” I-Ds, located here:
> 
> - https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis
> - https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis
> 
> The WG Last Call will end on April 18, 2023.
> 
> Please review the documents and submit issues or pull requests via the GitHub 
> repositories, which can be found at:
> 
> - https://github.com/tlswg/tls13-spec
> - https://github.com/tlswg/rfc8447bis
> 
> Alternatively, you can also send your comments to tls@ietf.org.
> 
> Thanks,
> Chris
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

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

2023-05-11 Thread Salz, Rich

Ping.

From: "Salz, Rich" 
Date: Thursday, April 20, 2023 at 3:17 PM
To: "tls@ietf.org" 
Subject: [TLS] "Notes" column in draft-ietf-tls-rfc8447bis?

I’m starting to write the draft about TLS 1.2 being frozen.

It occurred to me that every TLS registry might need a “notes” column.  If 
someone defines a new crypto algorithm, sat AEGIS being considered in CFRG, we 
want to assign it a number but have a note saying “only for TLS 1.3 and later”
We could make it be a simple yes/no column, like “Pre-1.3?” but I think that’s 
needlessly terse.

Does that make sense?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

2023-05-01 Thread Salz, Rich

Thanks for the info.

>This tweak was introduced as a result of discussions in Philly (IETF115) to 
>address David Schinazi’s comment at the mic. If I remember correctly, the 
>discussion was that there’s not really a concern about exhausting the registry 
>space because it’s a “string" registry, but we still wanted the DEs to make 
>sure the structure is followed, i.e., "EXPORTER:” is included. So … in some 
>respects I think of it as a SHOULD, but then that does clash with s13.

> I guess the question is as DE, is the guidance going to lead to problems?

No, seems okay to me.

The PR's are also okay, and if #38 missed something, I'm sure the RPC will find 
it :)

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

2023-05-01 Thread Sean Turner



> On Apr 11, 2023, at 12:50, Salz, Rich  wrote:
> 
> I am commenting on 8447bis. This document is just about ready to move 
> forward, but two fixes are needed.
> 
> Why there are Notes still in the doc (e.g., near end of section 6 it says 
> about weaker elliptic curves) and think those should be resolved, one way or 
> another, before advancing out of the WG.

There were still notes in s5 and s6 to draw attention to cipher suite listing 
in light of I-D.ietf-tls-deprecate-obsolete-kex and I guess now John’s I-D too. 
 Joe and I will circle with those authors to make sure we have the appropriate 
coverage.

> Sec 7 adds a note that says the experts "will highly encourage registrants to 
> provide a link" while Sec 13 says experts "ensure the specification is 
> publicly available."  So is that SHOULD or MUST?  (And s/highly/strongly/ IMO)

I can get behind s/highly/strongly:
https://github.com/tlswg/rfc8447bis/pull/39

This tweak was introduced as a result of discussions in Philly (IETF115) to 
address David Schinazi’s comment at the mic. If I remember correctly, the 
discussion was that there’s not really a concern about exhausting the registry 
space because it’s a “string" registry, but we still wanted the DEs to make 
sure the structure is followed, i.e., "EXPORTER:” is included. So … in some 
respects I think of it as a SHOULD, but then that does clash with s13.

I guess the question is as DE, is the guidance going to lead to problems?

> A nit, this line appears multiple times:
>   Setting a "Recommended" column value to Y or D requires Standards
> There should probably be quotes around the letters Y and D, for consistency 
> with other text.

I hope I got ‘em all here:
https://github.com/tlswg/rfc8447bis/pull/38

Cheers,

> A post IETF 116 bump to make sure folks get their reviews in. If you look at 
> the diffs from RFC 8446 you can see not that much has changed. We will also 
> take “I read it and it looks good” response. 
> 
> 
> Cheers,
> spt
> 
> 
>> On Mar 28, 2023, at 21:00, Christopher Wood > > wrote:
>> 
>> As mentioned during yesterday's meeting, this email starts the working group 
>> last call for "The Transport Layer Security (TLS) Protocol Version 1.3" and 
>> "IANA Registry Updates for TLS and DTLS” I-Ds, located here:
>> 
>> - 
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis__;!!GjvTz_vk!Ulz2iHrqiHDTnXaSY0-d3Vo3dX-wtwR6OtahB_aLeEKhAfPj4rRfFY4jViJ3R9YUrgSyiMh7$
>>  
>> 
>>  
>> - 
>> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis__;!!GjvTz_vk!Ulz2iHrqiHDTnXaSY0-d3Vo3dX-wtwR6OtahB_aLeEKhAfPj4rRfFY4jViJ3R9YUrjrMdAm2$
>>  
>> 
>>  
>> 
>> The WG Last Call will end on April 18, 2023.
>> 
>> Please review the documents and submit issues or pull requests via the 
>> GitHub repositories, which can be found at:
>> 
>> - 
>> https://urldefense.com/v3/__https://github.com/tlswg/tls13-spec__;!!GjvTz_vk!Ulz2iHrqiHDTnXaSY0-d3Vo3dX-wtwR6OtahB_aLeEKhAfPj4rRfFY4jViJ3R9YUrj6Gs5p8$
>>  
>> 
>>  
>> - 
>> https://urldefense.com/v3/__https://github.com/tlswg/rfc8447bis__;!!GjvTz_vk!Ulz2iHrqiHDTnXaSY0-d3Vo3dX-wtwR6OtahB_aLeEKhAfPj4rRfFY4jViJ3R9YUrpamqVl6$
>>  
>> 
>>  
>> 
>> Alternatively, you can also send your comments to tls@ietf.org 
>> .
>> 
>> Thanks,
>> Chris
>> ___
>> TLS mailing list
>> TLS@ietf.org 
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!Ulz2iHrqiHDTnXaSY0-d3Vo3dX-wtwR6OtahB_aLeEKhAfPj4rRfFY4jViJ3R9YUrjkidxUX$
>>  
>> 
>>  
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!Ulz2iHrqiHDTnXaSY0-d3Vo3dX-wtwR6OtahB_aLeEKhAfPj4rRfFY4jViJ3R9YUrjkidxUX$
>  
> 
>  
> 
> 
> 

___
TLS mailing list
TLS@ietf.org
https://ww

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

2023-04-20 Thread Salz, Rich

I’m starting to write the draft about TLS 1.2 being frozen.

It occurred to me that every TLS registry might need a “notes” column.  If 
someone defines a new crypto algorithm, sat AEGIS being considered in CFRG, we 
want to assign it a number but have a note saying “only for TLS 1.3 and later”
We could make it be a simple yes/no column, like “Pre-1.3?” but I think that’s 
needlessly terse.

Does that make sense?
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Fwd: WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

2023-04-19 Thread John Mattsson

Hi,

I think RFC8447bis need to say something about at least DTLS 1.3 Record Number 
Encryption

The two AEGIS algorithms recently got code points and DTLS-OK = Y even if there 
was no specification on how to do DTLS 1.3 Record Number Encryption
https://datatracker.ietf.org/doc/draft-irtf-cfrg-aegis-aead/
https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml

Both DTLS 1.3 Record Number Encryption and QUIC Header Protection will be added 
in the next version of the AEGIS draft. It is already merged to main.
https://github.com/jedisct1/draft-aegis-aead

Given that TLS WG is discussing deprecating (D)TLS 1.2 I don’t think you should 
get DTLS-OK = Y unless you specify how to do DTLS 1.3 Record Number Encryption.

At a minimum I think people should be reminded to specify QUIC and DTLS 1.3 
Header Protection. I also think it need to be clear that you don’t get DTLS-OK 
= Y unless you specify how to do DTLS 1.3 Record Number Encryption.

My preference would be a new column “Protocols” specifying which protocols the 
cipher suite can be used in. After the update the value for the AEGIS 
algorithms in that column would be “TLS 1.3, DTLS 1.3, QUIC”

Cheers,
John
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

2023-04-12 Thread Loganaden Velvindron

On Wed, 5 Apr 2023 at 06:32, Stephen Farrell  wrote:
>
>
> Hiya,
>
> On 05/04/2023 02:47, Sean Turner wrote:
> > A post IETF 116 bump to make sure folks get their reviews in. If you
> > look at the diffs from RFC 8446 you can see not that much has
> > changed. We will also take “I read it and it looks good” response.
>
> I looked at the diff between 8446bis-07 and 8446 and it seems
> fine to me. My only comment is that C.4 says one "SHOULD NOT
> reuse a key share" - I'd be happier if that was a "MUST NOT"
> but understand if we stick with SHOULD NOT. If there were a
> good reference showing that it's quite feasible to never
> deliberately re-use a key share, even at scale, that'd be a fine
> addition. (I don't have such a reference to offer,
> sorry;-)
>

Agreed. Overall, the document looks good.

> Cheers,
> S.
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

2023-04-12 Thread Eric Rescorla

On Wed, Apr 12, 2023 at 12:15 AM Ilari Liusvaara 
wrote:

> On Wed, Apr 12, 2023 at 01:18:17AM +, Peter Gutmann wrote:
> > On the subject of clarification, the update also needs to explain why
> PSK is
> > split across two separate extensions, psk_key_exchange_modes and
> > pre_shared_key, with complex and awkward reconciliation rules between
> then,
> > and why the PSK has to be the last extension in the client hello.  I
> can't see
> > any reason for either of those two, which in particular for the latter
> one
> > means why would an implementation follow that apparently pointless
> > requirement?  Is this codifying someone's implementation bug?  Do demons
> fly
> > out of your nose if it's not the last extension?
>
> For the first, I actually asked that very question during TLS 1.3
> development. Psk_key_exchange_modes can appear without pre_shared_key.
>

Yes. This is what happens in a non-resumption handshake, so that the client
can
advertise what it supports.


As for the second, the present method of computing binders (message
> truncation) requires pre_shared_key to be the last extension. While
> it would be possible to design ways of computing binders without such
> requirement, those methods would seem to be much more complicated.
>

Correct. The idea is that the binder is computed on a prefix of the CH, as
indicated
in S 4.2.11.2.

-Ekr


>
>
>
> -Ilari
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

2023-04-12 Thread Ilari Liusvaara

On Wed, Apr 12, 2023 at 01:18:17AM +, Peter Gutmann wrote:
> On the subject of clarification, the update also needs to explain why PSK is
> split across two separate extensions, psk_key_exchange_modes and
> pre_shared_key, with complex and awkward reconciliation rules between then,
> and why the PSK has to be the last extension in the client hello.  I can't see
> any reason for either of those two, which in particular for the latter one
> means why would an implementation follow that apparently pointless
> requirement?  Is this codifying someone's implementation bug?  Do demons fly
> out of your nose if it's not the last extension?

For the first, I actually asked that very question during TLS 1.3
development. Psk_key_exchange_modes can appear without pre_shared_key.

As for the second, the present method of computing binders (message
truncation) requires pre_shared_key to be the last extension. While
it would be possible to design ways of computing binders without such
requirement, those methods would seem to be much more complicated.

-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

2023-04-11 Thread Peter Gutmann

Ben Smyth  writes:

>Because pre_shared_key appears in ClientHello and ServerHello, whilst
>psk_key_exchange_modes only appears in the former?

That's a circular argument, pre_shared_key already has two different forms
that depend on whether it's the ClientHello or ServerHello it so this is
saying "psk_key_exchange_modes has to be in a different extension because
psk_key_exchange_modes is in a different extension".

Making it { modes + info if required } in one extension where the mode is
right next to the info it applies to rather than splitting it across two
extensions would be the obvious way to do it.

Peter.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

2023-04-11 Thread Ben Smyth

On Wed, 12 Apr 2023, 03:18 Peter Gutmann,  wrote:

> On the subject of clarification, the update also needs to explain why PSK
> is
> split across two separate extensions, psk_key_exchange_modes and
> pre_shared_key


Because pre_shared_key appears in ClientHello and ServerHello, whilst
psk_key_exchange_modes only appears in the former?

>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

2023-04-11 Thread Peter Gutmann

On the subject of clarification, the update also needs to explain why PSK is
split across two separate extensions, psk_key_exchange_modes and
pre_shared_key, with complex and awkward reconciliation rules between then,
and why the PSK has to be the last extension in the client hello.  I can't see
any reason for either of those two, which in particular for the latter one
means why would an implementation follow that apparently pointless
requirement?  Is this codifying someone's implementation bug?  Do demons fly
out of your nose if it's not the last extension?

Peter.


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

2023-04-11 Thread Salz, Rich

I am commenting on 8446bis.

I re-read the draft, it is almost ready to move forward.  All but one of the 
open issues are basically editorial. I think John Mattsson's issue [1] on PSK 
identity guidance is worth including; I do not recall much WG discussion of 
this.

[1] https://github.com/tlswg/tls13-spec/issues/1308

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

2023-04-11 Thread Salz, Rich

I am commenting on 8447bis. This document is just about ready to move forward, 
but two fixes are needed.

Why there are Notes still in the doc (e.g., near end of section 6 it says about 
weaker elliptic curves) and think those should be resolved, one way or another, 
before advancing out of the WG.

Sec 7 adds a note that says the experts "will highly encourage registrants to 
provide a link" while Sec 13 says experts "ensure the specification is publicly 
available."  So is that SHOULD or MUST?  (And s/highly/strongly/ IMO)

A nit, this line appears multiple times:
   Setting a "Recommended" column value to Y or D requires Standards
There should probably be quotes around the letters Y and D, for consistency 
with other text.

A post IETF 116 bump to make sure folks get their reviews in. If you look at 
the diffs from RFC 8446 you can see not that much has changed. We will also 
take “I read it and it looks good” response. 

Cheers,
spt

> On Mar 28, 2023, at 21:00, Christopher Wood  > wrote:
> 
> As mentioned during yesterday's meeting, this email starts the working group 
> last call for "The Transport Layer Security (TLS) Protocol Version 1.3" and 
> "IANA Registry Updates for TLS and DTLS” I-Ds, located here:
> 
> - 
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis__;!!GjvTz_vk!Ulz2iHrqiHDTnXaSY0-d3Vo3dX-wtwR6OtahB_aLeEKhAfPj4rRfFY4jViJ3R9YUrgSyiMh7$
>  
> 
>  
> - 
> https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis__;!!GjvTz_vk!Ulz2iHrqiHDTnXaSY0-d3Vo3dX-wtwR6OtahB_aLeEKhAfPj4rRfFY4jViJ3R9YUrjrMdAm2$
>  
> 
>  
> 
> The WG Last Call will end on April 18, 2023.
> 
> Please review the documents and submit issues or pull requests via the GitHub 
> repositories, which can be found at:
> 
> - 
> https://urldefense.com/v3/__https://github.com/tlswg/tls13-spec__;!!GjvTz_vk!Ulz2iHrqiHDTnXaSY0-d3Vo3dX-wtwR6OtahB_aLeEKhAfPj4rRfFY4jViJ3R9YUrj6Gs5p8$
>  
> 
>  
> - 
> https://urldefense.com/v3/__https://github.com/tlswg/rfc8447bis__;!!GjvTz_vk!Ulz2iHrqiHDTnXaSY0-d3Vo3dX-wtwR6OtahB_aLeEKhAfPj4rRfFY4jViJ3R9YUrpamqVl6$
>  
> 
>  
> 
> Alternatively, you can also send your comments to tls@ietf.org 
> .
> 
> Thanks,
> Chris
> ___
> TLS mailing list
> TLS@ietf.org 
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!Ulz2iHrqiHDTnXaSY0-d3Vo3dX-wtwR6OtahB_aLeEKhAfPj4rRfFY4jViJ3R9YUrjkidxUX$
>  
> 
>  

___
TLS mailing list
TLS@ietf.org 
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!Ulz2iHrqiHDTnXaSY0-d3Vo3dX-wtwR6OtahB_aLeEKhAfPj4rRfFY4jViJ3R9YUrjkidxUX$

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

2023-04-06 Thread Rob Sayre

On Wed, Apr 5, 2023 at 1:05 PM Rob Sayre  wrote:

>
>
> On Wed, Apr 5, 2023 at 12:53 PM Eric Rescorla  wrote:
>
>>
>>
>> On Wed, Apr 5, 2023 at 12:50 PM Rob Sayre  wrote:
>>
>>> On Wed, Apr 5, 2023 at 12:26 PM Eric Rescorla  wrote:
>>>
 Thanks for your feedback. Most of these are editorial comments and
 so I think they're my decision as editor about which ones to take
 absent some instruction from the chairs.

>>>
>>> I agree concerning most of them. One just finds nitpicks if you read the
>>> whole thing carefully.
>>>
>>> The one thing I think is really substantive is the deprecation of TLS
>>> 1.0 / 1.1, since you have a strange nesting of MUSTs.
>>>
>>> I think a descriptive "NOT RECOMMENDED" approach would be better here.
>>> Then, describe that servers might choose to accept 1.0/1.1 if they don't
>>> actually care whether the traffic is secure. This is a very common pattern.
>>> I found a survey that showed popular public sites were likely to accept
>>> almost anything (SSL3, unencrypted traffic, etc).*
>>>
>>
>> I don't see how we can use NOT RECOMMENDED here, because we already have
>> an RFC which prohibits the use of TLS 1.0 and TLS 1.1 and we're not
>> contradicting
>> that. The purpose of the text you highlight is to address people who are
>> nonconformant
>> with that RFC.
>>
>
> I see your point. RFC8996 does say "MUST NOT", but that's not deprecation.
> It's prohibition, as you say. So, the title of the document is confusing.
>
> I still think what it's in this document is confusing, because it says "if
> you don't follow this MUST, you have to follow this MUST...".
>
> But I can see this situation is kind of messy, so I think it's editorial.
>

Hi, sorry to be a pest here, but maybe this isn't editorial.

First, one nit: "negotation" here:

4.1.3 Server Hello:
>   Note that [RFC8996] and Appendix E.5 forbid the negotation of TLS
>   versions below 1.2; implementations which do not follow that guidance
>   MUST behave as described above.

Here's my effort, just to make it more than a complaint. I'm not attached
to the exact wording:

"In order to preserve the security properties enumerated in the
Introduction, [RFC8996] and Appendix E.5 forbid the negotiation of TLS
versions below 1.2. Implementations willing to accept obsolete TLS versions
MUST behave as described above."

Appendix E.5:
>   The security of SSL 2.0 [SSL2], SSL 3.0 [RFC6101], TLS 1.0 [RFC2246],
>   and TLS 1.1 [RFC4346] are considered insufficient for the reasons
>   enumerated in [RFC6176], [RFC7568], and [RFC8996] and they MUST NOT
>   be negotiated for any reason.

Here, I would end with "...for any reason in applications that require a
secure channel."

>   Implementations MUST NOT send an SSL version 2.0 compatible CLIENT-
>   HELLO.  Implementations MUST NOT negotiate TLS 1.3 or later using an
>   SSL version 2.0 compatible CLIENT-HELLO.  Implementations are NOT
>   RECOMMENDED to accept an SSL version 2.0 compatible CLIENT-HELLO in
>   order to negotiate older versions of TLS.

Without the little trailing text I added above, this seems a little
contradictory. The thinking here is the document says this is NOT
RECOMMENDED, but it's something they MUST NOT do, unless you only mean TLS
1.2 here.

thanks,
Rob







>
>
>>
>>> I think this approach is more accurate, but also more critical in terms
>>> of security than what you have now.
>>>
>>> thanks,
>>> Rob
>>>
>>> *
>>> "In fact, the top 100 sites were more likely to still support SSL 3, TLS
>>> 1.0, and TLS 1.1 than servers with much less traffic."
>>> <
>>> https://www.f5.com/labs/articles/threat-intelligence/the-2021-tls-telemetry-report
>>> >
>>>
>>>
>>>
 On Tue, Apr 4, 2023 at 10:43 PM Rob Sayre  wrote:

> Hi,
>
> I'm still not sure about the list/vector rename. Aside from that,
> here's what I found:
>
> > It tightens some requirements and contains
> > updated text in areas which were found to be unclear as well as
> other
> > editorial improvements.
>
> "It contains clarifications and tightened requirements." [let's assume
> some things were unclear and that editorial improvements are 
> clarifications]
>

 Not all editorial improvements are clarifications.


>
> > Forbid negotiating TLS 1.0 and 1.1 as they are now deprecated by
> [RFC8996].
>
> I know what's meant here, but deprecated does not mean forbidden. I
> think you want to say "NOT RECOMMENDED" in RFC 2119 words, and give a 
> brief
> reason for that. [but keep reading]
>

 This isn't normative text. However 8996 is entitled "Deprecating TLS
 1.0 and TLS 1.1" so I think this
 is fine.



> > The protocol does not provide any forward secrecy guarantees for
> this data.
> > The server's behavior determines what forward secrecy
> > guarantees, if any, apply (see Section 8.1). This behavior is
> > not communicated to the client as

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

2023-04-05 Thread Rob Sayre

On Wed, Apr 5, 2023 at 12:53 PM Eric Rescorla  wrote:

>
>
> On Wed, Apr 5, 2023 at 12:50 PM Rob Sayre  wrote:
>
>> On Wed, Apr 5, 2023 at 12:26 PM Eric Rescorla  wrote:
>>
>>> Thanks for your feedback. Most of these are editorial comments and
>>> so I think they're my decision as editor about which ones to take
>>> absent some instruction from the chairs.
>>>
>>
>> I agree concerning most of them. One just finds nitpicks if you read the
>> whole thing carefully.
>>
>> The one thing I think is really substantive is the deprecation of TLS 1.0
>> / 1.1, since you have a strange nesting of MUSTs.
>>
>> I think a descriptive "NOT RECOMMENDED" approach would be better here.
>> Then, describe that servers might choose to accept 1.0/1.1 if they don't
>> actually care whether the traffic is secure. This is a very common pattern.
>> I found a survey that showed popular public sites were likely to accept
>> almost anything (SSL3, unencrypted traffic, etc).*
>>
>
> I don't see how we can use NOT RECOMMENDED here, because we already have
> an RFC which prohibits the use of TLS 1.0 and TLS 1.1 and we're not
> contradicting
> that. The purpose of the text you highlight is to address people who are
> nonconformant
> with that RFC.
>

I see your point. RFC8996 does say "MUST NOT", but that's not deprecation.
It's prohibition, as you say. So, the title of the document is confusing.

I still think what it's in this document is confusing, because it says "if
you don't follow this MUST, you have to follow this MUST...".

But I can see this situation is kind of messy, so I think it's editorial.

thanks,
Rob



>
>> I think this approach is more accurate, but also more critical in terms
>> of security than what you have now.
>>
>> thanks,
>> Rob
>>
>> *
>> "In fact, the top 100 sites were more likely to still support SSL 3, TLS
>> 1.0, and TLS 1.1 than servers with much less traffic."
>> <
>> https://www.f5.com/labs/articles/threat-intelligence/the-2021-tls-telemetry-report
>> >
>>
>>
>>
>>> On Tue, Apr 4, 2023 at 10:43 PM Rob Sayre  wrote:
>>>
 Hi,

 I'm still not sure about the list/vector rename. Aside from that,
 here's what I found:

 > It tightens some requirements and contains
 > updated text in areas which were found to be unclear as well as other
 > editorial improvements.

 "It contains clarifications and tightened requirements." [let's assume
 some things were unclear and that editorial improvements are 
 clarifications]

>>>
>>> Not all editorial improvements are clarifications.
>>>
>>>

 > Forbid negotiating TLS 1.0 and 1.1 as they are now deprecated by
 [RFC8996].

 I know what's meant here, but deprecated does not mean forbidden. I
 think you want to say "NOT RECOMMENDED" in RFC 2119 words, and give a brief
 reason for that. [but keep reading]

>>>
>>> This isn't normative text. However 8996 is entitled "Deprecating TLS 1.0
>>> and TLS 1.1" so I think this
>>> is fine.
>>>
>>>
>>>
 > The protocol does not provide any forward secrecy guarantees for this
 data.
 > The server's behavior determines what forward secrecy
 > guarantees, if any, apply (see Section 8.1). This behavior is
 > not communicated to the client as part of the protocol.
 > Therefore, absent out-of-band knowledge of the server's behavior,
 > the client should assume that this data is not forward secret.

 Here, you use the term "out-of-band", but the PSK text replaced
 "out-of-band" with "external[ly]". I can't tell whether this usage is
 intentional.

>>>
>>> It is. The PSKs here are resumption PSKs. They're not external. The out
>>> of band in
>>> question is knowledge about the server behavior.
>>>
>>>
>>>

 > Because TLS 1.3 forbids renegotiation, if a server has negotiated TLS
 > 1.3 and receives a ClientHello at any other time, it MUST terminate

 "TLS 1.3 forbids renegotiation. If a server has negotiated TLS 1.3 and
 receives a ClientHello at any other time, it MUST terminate..."

 [No starting sentences with "Because"]

>>>
>>> I believe this is editor discretion.
>>>
>>>

 > Note that [RFC8996] and Appendix E.5 forbid the negotation of TLS
 > versions below 1.2; implementations which do not follow that guidance
 > MUST behave as described above.

 I think this makes my "NOT RECOMMENDED" suggestion above correct. A
 forbidden "MUST NOT" wouldn't need this text.

>>>
>>> I don't understand this argument. The point of this text is that people
>>> are forbidden
>>> to do previous versions by 8996, but we know some people won't so this
>>> is
>>> backup guidance. I think this is fine.
>>>
>>>
>>>
>>>

 > Unless otherwise specified, trailing data is forbidden.
 > That is, senders MUST NOT include data after the structure in the
 > "extension_data" field.

 This doesn't seem like "MUST NOT", since it could be "otherwise

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

2023-04-05 Thread Eric Rescorla

On Wed, Apr 5, 2023 at 12:50 PM Rob Sayre  wrote:

> On Wed, Apr 5, 2023 at 12:26 PM Eric Rescorla  wrote:
>
>> Thanks for your feedback. Most of these are editorial comments and
>> so I think they're my decision as editor about which ones to take
>> absent some instruction from the chairs.
>>
>
> I agree concerning most of them. One just finds nitpicks if you read the
> whole thing carefully.
>
> The one thing I think is really substantive is the deprecation of TLS 1.0
> / 1.1, since you have a strange nesting of MUSTs.
>
> I think a descriptive "NOT RECOMMENDED" approach would be better here.
> Then, describe that servers might choose to accept 1.0/1.1 if they don't
> actually care whether the traffic is secure. This is a very common pattern.
> I found a survey that showed popular public sites were likely to accept
> almost anything (SSL3, unencrypted traffic, etc).*
>

I don't see how we can use NOT RECOMMENDED here, because we already have
an RFC which prohibits the use of TLS 1.0 and TLS 1.1 and we're not
contradicting
that. The purpose of the text you highlight is to address people who are
nonconformant
with that RFC.

-Ekr




>
> I think this approach is more accurate, but also more critical in terms of
> security than what you have now.
>
> thanks,
> Rob
>
> *
> "In fact, the top 100 sites were more likely to still support SSL 3, TLS
> 1.0, and TLS 1.1 than servers with much less traffic."
> <
> https://www.f5.com/labs/articles/threat-intelligence/the-2021-tls-telemetry-report
> >
>
>
>
>> On Tue, Apr 4, 2023 at 10:43 PM Rob Sayre  wrote:
>>
>>> Hi,
>>>
>>> I'm still not sure about the list/vector rename. Aside from that, here's
>>> what I found:
>>>
>>> > It tightens some requirements and contains
>>> > updated text in areas which were found to be unclear as well as other
>>> > editorial improvements.
>>>
>>> "It contains clarifications and tightened requirements." [let's assume
>>> some things were unclear and that editorial improvements are clarifications]
>>>
>>
>> Not all editorial improvements are clarifications.
>>
>>
>>>
>>> > Forbid negotiating TLS 1.0 and 1.1 as they are now deprecated by
>>> [RFC8996].
>>>
>>> I know what's meant here, but deprecated does not mean forbidden. I
>>> think you want to say "NOT RECOMMENDED" in RFC 2119 words, and give a brief
>>> reason for that. [but keep reading]
>>>
>>
>> This isn't normative text. However 8996 is entitled "Deprecating TLS 1.0
>> and TLS 1.1" so I think this
>> is fine.
>>
>>
>>
>>> > The protocol does not provide any forward secrecy guarantees for this
>>> data.
>>> > The server's behavior determines what forward secrecy
>>> > guarantees, if any, apply (see Section 8.1). This behavior is
>>> > not communicated to the client as part of the protocol.
>>> > Therefore, absent out-of-band knowledge of the server's behavior,
>>> > the client should assume that this data is not forward secret.
>>>
>>> Here, you use the term "out-of-band", but the PSK text replaced
>>> "out-of-band" with "external[ly]". I can't tell whether this usage is
>>> intentional.
>>>
>>
>> It is. The PSKs here are resumption PSKs. They're not external. The out
>> of band in
>> question is knowledge about the server behavior.
>>
>>
>>
>>>
>>> > Because TLS 1.3 forbids renegotiation, if a server has negotiated TLS
>>> > 1.3 and receives a ClientHello at any other time, it MUST terminate
>>>
>>> "TLS 1.3 forbids renegotiation. If a server has negotiated TLS 1.3 and
>>> receives a ClientHello at any other time, it MUST terminate..."
>>>
>>> [No starting sentences with "Because"]
>>>
>>
>> I believe this is editor discretion.
>>
>>
>>>
>>> > Note that [RFC8996] and Appendix E.5 forbid the negotation of TLS
>>> > versions below 1.2; implementations which do not follow that guidance
>>> > MUST behave as described above.
>>>
>>> I think this makes my "NOT RECOMMENDED" suggestion above correct. A
>>> forbidden "MUST NOT" wouldn't need this text.
>>>
>>
>> I don't understand this argument. The point of this text is that people
>> are forbidden
>> to do previous versions by 8996, but we know some people won't so this is
>> backup guidance. I think this is fine.
>>
>>
>>
>>
>>>
>>> > Unless otherwise specified, trailing data is forbidden.
>>> > That is, senders MUST NOT include data after the structure in the
>>> > "extension_data" field.
>>>
>>> This doesn't seem like "MUST NOT", since it could be "otherwise
>>> specified". I think there needs to be a harsher choice made here, or just
>>> leave it out.
>>>
>>
>> This is actually fairly standard language.
>>
>>
>>
>>> > When processing an extension, receivers MUST
>>> > abort the handshake with a "decode_error" alert if there is data left
>>> > over after parsing the structure. This does not apply if the
>>> > receiver does not implement or is configured to ignore an extension.
>>>
>>> Again, doesn't seem like a "MUST". But the following text says "This
>>> does not apply", without clarifying what "this" is.
>>>
>>
>> I don't follo

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

2023-04-05 Thread Rob Sayre

On Wed, Apr 5, 2023 at 12:26 PM Eric Rescorla  wrote:

> Thanks for your feedback. Most of these are editorial comments and
> so I think they're my decision as editor about which ones to take
> absent some instruction from the chairs.
>

I agree concerning most of them. One just finds nitpicks if you read the
whole thing carefully.

The one thing I think is really substantive is the deprecation of TLS 1.0 /
1.1, since you have a strange nesting of MUSTs.

I think a descriptive "NOT RECOMMENDED" approach would be better here.
Then, describe that servers might choose to accept 1.0/1.1 if they don't
actually care whether the traffic is secure. This is a very common pattern.
I found a survey that showed popular public sites were likely to accept
almost anything (SSL3, unencrypted traffic, etc).*

I think this approach is more accurate, but also more critical in terms of
security than what you have now.

thanks,
Rob

*
"In fact, the top 100 sites were more likely to still support SSL 3, TLS
1.0, and TLS 1.1 than servers with much less traffic."
<
https://www.f5.com/labs/articles/threat-intelligence/the-2021-tls-telemetry-report
>



> On Tue, Apr 4, 2023 at 10:43 PM Rob Sayre  wrote:
>
>> Hi,
>>
>> I'm still not sure about the list/vector rename. Aside from that, here's
>> what I found:
>>
>> > It tightens some requirements and contains
>> > updated text in areas which were found to be unclear as well as other
>> > editorial improvements.
>>
>> "It contains clarifications and tightened requirements." [let's assume
>> some things were unclear and that editorial improvements are clarifications]
>>
>
> Not all editorial improvements are clarifications.
>
>
>>
>> > Forbid negotiating TLS 1.0 and 1.1 as they are now deprecated by
>> [RFC8996].
>>
>> I know what's meant here, but deprecated does not mean forbidden. I think
>> you want to say "NOT RECOMMENDED" in RFC 2119 words, and give a brief
>> reason for that. [but keep reading]
>>
>
> This isn't normative text. However 8996 is entitled "Deprecating TLS 1.0
> and TLS 1.1" so I think this
> is fine.
>
>
>
>> > The protocol does not provide any forward secrecy guarantees for this
>> data.
>> > The server's behavior determines what forward secrecy
>> > guarantees, if any, apply (see Section 8.1). This behavior is
>> > not communicated to the client as part of the protocol.
>> > Therefore, absent out-of-band knowledge of the server's behavior,
>> > the client should assume that this data is not forward secret.
>>
>> Here, you use the term "out-of-band", but the PSK text replaced
>> "out-of-band" with "external[ly]". I can't tell whether this usage is
>> intentional.
>>
>
> It is. The PSKs here are resumption PSKs. They're not external. The out of
> band in
> question is knowledge about the server behavior.
>
>
>
>>
>> > Because TLS 1.3 forbids renegotiation, if a server has negotiated TLS
>> > 1.3 and receives a ClientHello at any other time, it MUST terminate
>>
>> "TLS 1.3 forbids renegotiation. If a server has negotiated TLS 1.3 and
>> receives a ClientHello at any other time, it MUST terminate..."
>>
>> [No starting sentences with "Because"]
>>
>
> I believe this is editor discretion.
>
>
>>
>> > Note that [RFC8996] and Appendix E.5 forbid the negotation of TLS
>> > versions below 1.2; implementations which do not follow that guidance
>> > MUST behave as described above.
>>
>> I think this makes my "NOT RECOMMENDED" suggestion above correct. A
>> forbidden "MUST NOT" wouldn't need this text.
>>
>
> I don't understand this argument. The point of this text is that people
> are forbidden
> to do previous versions by 8996, but we know some people won't so this is
> backup guidance. I think this is fine.
>
>
>
>
>>
>> > Unless otherwise specified, trailing data is forbidden.
>> > That is, senders MUST NOT include data after the structure in the
>> > "extension_data" field.
>>
>> This doesn't seem like "MUST NOT", since it could be "otherwise
>> specified". I think there needs to be a harsher choice made here, or just
>> leave it out.
>>
>
> This is actually fairly standard language.
>
>
>
>> > When processing an extension, receivers MUST
>> > abort the handshake with a "decode_error" alert if there is data left
>> > over after parsing the structure. This does not apply if the
>> > receiver does not implement or is configured to ignore an extension.
>>
>> Again, doesn't seem like a "MUST". But the following text says "This does
>> not apply", without clarifying what "this" is.
>>
>
> I don't follow your argument here either. It's a MUST for any extension
> you understand.
> Obviously, if you don't understand it, you can't comply with this. I'll
> attempt to clarify.
>
>
>> > After checking ServerHello.random to determine if the server
>> > handshake message is a ServerHello or HelloRetryRequest, clients MUST
>> > check for this extension prior to processing the rest of the
>> > ServerHello.  This will require clients to parse the ServerHello in ...
>>
>> Another "this"

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

2023-04-05 Thread Eric Rescorla

This was discussed extensively when 8446 was published and there wasn't
consensus
to make such a change. If the chairs want to re-open this issue, please
weigh in.

-Ekr


On Tue, Apr 4, 2023 at 7:32 PM Stephen Farrell 
wrote:

>
> Hiya,
>
> On 05/04/2023 02:47, Sean Turner wrote:
> > A post IETF 116 bump to make sure folks get their reviews in. If you
> > look at the diffs from RFC 8446 you can see not that much has
> > changed. We will also take “I read it and it looks good” response.
>
> I looked at the diff between 8446bis-07 and 8446 and it seems
> fine to me. My only comment is that C.4 says one "SHOULD NOT
> reuse a key share" - I'd be happier if that was a "MUST NOT"
> but understand if we stick with SHOULD NOT. If there were a
> good reference showing that it's quite feasible to never
> deliberately re-use a key share, even at scale, that'd be a fine
> addition. (I don't have such a reference to offer,
> sorry;-)
>
> Cheers,
> S.
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

2023-04-05 Thread Eric Rescorla

Thanks for your feedback. Most of these are editorial comments and
so I think they're my decision as editor about which ones to take
absent some instruction from the chairs.

On Tue, Apr 4, 2023 at 10:43 PM Rob Sayre  wrote:

> Hi,
>
> I'm still not sure about the list/vector rename. Aside from that, here's
> what I found:
>
> > It tightens some requirements and contains
> > updated text in areas which were found to be unclear as well as other
> > editorial improvements.
>
> "It contains clarifications and tightened requirements." [let's assume
> some things were unclear and that editorial improvements are clarifications]
>

Not all editorial improvements are clarifications.


>
> > Forbid negotiating TLS 1.0 and 1.1 as they are now deprecated by
> [RFC8996].
>
> I know what's meant here, but deprecated does not mean forbidden. I think
> you want to say "NOT RECOMMENDED" in RFC 2119 words, and give a brief
> reason for that. [but keep reading]
>

This isn't normative text. However 8996 is entitled "Deprecating TLS 1.0
and TLS 1.1" so I think this
is fine.



> > The protocol does not provide any forward secrecy guarantees for this
> data.
> > The server's behavior determines what forward secrecy
> > guarantees, if any, apply (see Section 8.1). This behavior is
> > not communicated to the client as part of the protocol.
> > Therefore, absent out-of-band knowledge of the server's behavior,
> > the client should assume that this data is not forward secret.
>
> Here, you use the term "out-of-band", but the PSK text replaced
> "out-of-band" with "external[ly]". I can't tell whether this usage is
> intentional.
>

It is. The PSKs here are resumption PSKs. They're not external. The out of
band in
question is knowledge about the server behavior.



>
> > Because TLS 1.3 forbids renegotiation, if a server has negotiated TLS
> > 1.3 and receives a ClientHello at any other time, it MUST terminate
>
> "TLS 1.3 forbids renegotiation. If a server has negotiated TLS 1.3 and
> receives a ClientHello at any other time, it MUST terminate..."
>
> [No starting sentences with "Because"]
>

I believe this is editor discretion.


>
> > Note that [RFC8996] and Appendix E.5 forbid the negotation of TLS
> > versions below 1.2; implementations which do not follow that guidance
> > MUST behave as described above.
>
> I think this makes my "NOT RECOMMENDED" suggestion above correct. A
> forbidden "MUST NOT" wouldn't need this text.
>

I don't understand this argument. The point of this text is that people are
forbidden
to do previous versions by 8996, but we know some people won't so this is
backup guidance. I think this is fine.




>
> > Unless otherwise specified, trailing data is forbidden.
> > That is, senders MUST NOT include data after the structure in the
> > "extension_data" field.
>
> This doesn't seem like "MUST NOT", since it could be "otherwise
> specified". I think there needs to be a harsher choice made here, or just
> leave it out.
>

This is actually fairly standard language.



> > When processing an extension, receivers MUST
> > abort the handshake with a "decode_error" alert if there is data left
> > over after parsing the structure. This does not apply if the
> > receiver does not implement or is configured to ignore an extension.
>
> Again, doesn't seem like a "MUST". But the following text says "This does
> not apply", without clarifying what "this" is.
>

I don't follow your argument here either. It's a MUST for any extension you
understand.
Obviously, if you don't understand it, you can't comply with this. I'll
attempt to clarify.


> > After checking ServerHello.random to determine if the server
> > handshake message is a ServerHello or HelloRetryRequest, clients MUST
> > check for this extension prior to processing the rest of the
> > ServerHello.  This will require clients to parse the ServerHello in ...
>
> Another "this". Here, I think the text means "This requirement...", but
> usually a rewrite can fix these ambiguities.
>

I don't think this one is unclear.


> > In the absence of some other specification to the
> > contrary, servers which are authenticating with an external PSK MUST
> > NOT send the CertificateRequest message either in the main handshake
> > or request post-handshake authentication.  [RFC8773] provides an
> > extension to permit this, but has not received the level of analysis
> > as this specification.
>
> Another one of these "In the absence of..." paragraphs. Maybe these are
> intentional? They still sound really redundant to me.
>

They're intentional because we know there is actually such an RFC, but you
have to
actually use it.


> > With a 128-bit key as in AES-128, rekeying 2^64 times has a high
> > probability of key reuse within a given connection.  Note that even...
>
> It's almost always possible to drop "Note that..."
>

It is possible, but I prefer to leave it as-is.


> The rest of this paragraph is really heavy on em dashes, and needs to be
> rewritten. Some of them se

[TLS] Fwd: WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

2023-04-05 Thread Achim Kraus


Too fast.
Very sorry, it is already linked to that thread.


 Weitergeleitete Nachricht 
Betreff: Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and
draft-ietf-tls-rfc8447bis
Datum: Wed, 5 Apr 2023 10:47:11 +0200
Von: Achim Kraus 
An: Martin Thomson , tls@ietf.org

Let me try to link this thread to the similar question raised during the
implementation of RPK in openssl.

https://mailarchive.ietf.org/arch/msg/tls/9rXQFjYhAS0z-ZJleMVUgWmvhAA/

My personal "favorite interpretation" of

RFC5246 7.4.6.  Client Certificate

is to stick to that definition there regardless of the certificate type,
which isn't mentioned there.

"If no suitable certificate is available,
 the client MUST send a certificate message containing no
 certificates.  That is, the certificate_list structure has a
 length of zero."

Means: no xYz (e.g. RPK) certificate results in an empty list (3x 0x00).
From the other thread, there seems to be also other certificate types,
which defined this different, but for all, which starts with a 3-bytes
length, the "empty list" will do it.

best regards
Achim


Am 05.04.23 um 08:02 schrieb Martin Thomson:

I mentioned this to Ekr off-list, but I thought I would add one more thing.  
What did we conclude about a client that refuses to provide a raw public key 
when asked by a server?  Are we in a position to change the minimum length from 
1 to 0 in the response?  The thread didn't really end with a solid conclusion, 
other than a note from Ilari indicating that maybe a zero length RPK would be 
OK in some libraries.

See: https://mailarchive.ietf.org/arch/msg/tls/9rXQFjYhAS0z-ZJleMVUgWmvhAA/

On Thu, Mar 30, 2023, at 15:59, Martin Thomson wrote:

https://author-tools.ietf.org/diff?doc_1=rfc8446&doc_2=draft-ietf-tls-rfc8446bis-07
might be helpful to others.

I opened a few issues, but the TLS 1.3 revision is very much ready to
be published.

For the 8447 revision, I found that our decision to remove the
definition of the fields for each registry to be difficult.  The draft
lists changes, so now this document is no longer an easy reference for
how to register TLS extension bits.  Not a big deal and I don't want to
ask the authors to flip flop here, but I wanted to flag it.

On Wed, Mar 29, 2023, at 10:00, Christopher Wood wrote:

As mentioned during yesterday's meeting, this email starts the working
group last call for "The Transport Layer Security (TLS) Protocol
Version 1.3" and "IANA Registry Updates for TLS and DTLS” I-Ds, located
here:

- https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis
- https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis

The WG Last Call will end on April 18, 2023.

Please review the documents and submit issues or pull requests via the
GitHub repositories, which can be found at:

- https://github.com/tlswg/tls13-spec
- https://github.com/tlswg/rfc8447bis

Alternatively, you can also send your comments to tls@ietf.org.

Thanks,
Chris
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

2023-04-05 Thread Achim Kraus


Let me try to link this thread to the similar question raised during the
implementation of RPK in openssl.

https://mailarchive.ietf.org/arch/msg/tls/9rXQFjYhAS0z-ZJleMVUgWmvhAA/

My personal "favorite interpretation" of

RFC5246 7.4.6.  Client Certificate

is to stick to that definition there regardless of the certificate type,
which isn't mentioned there.

"If no suitable certificate is available,
 the client MUST send a certificate message containing no
 certificates.  That is, the certificate_list structure has a
 length of zero."

Means: no xYz (e.g. RPK) certificate results in an empty list (3x 0x00).
From the other thread, there seems to be also other certificate types,
which defined this different, but for all, which starts with a 3-bytes
length, the "empty list" will do it.

best regards
Achim


Am 05.04.23 um 08:02 schrieb Martin Thomson:

I mentioned this to Ekr off-list, but I thought I would add one more thing.  
What did we conclude about a client that refuses to provide a raw public key 
when asked by a server?  Are we in a position to change the minimum length from 
1 to 0 in the response?  The thread didn't really end with a solid conclusion, 
other than a note from Ilari indicating that maybe a zero length RPK would be 
OK in some libraries.

See: https://mailarchive.ietf.org/arch/msg/tls/9rXQFjYhAS0z-ZJleMVUgWmvhAA/

On Thu, Mar 30, 2023, at 15:59, Martin Thomson wrote:

https://author-tools.ietf.org/diff?doc_1=rfc8446&doc_2=draft-ietf-tls-rfc8446bis-07
might be helpful to others.

I opened a few issues, but the TLS 1.3 revision is very much ready to
be published.

For the 8447 revision, I found that our decision to remove the
definition of the fields for each registry to be difficult.  The draft
lists changes, so now this document is no longer an easy reference for
how to register TLS extension bits.  Not a big deal and I don't want to
ask the authors to flip flop here, but I wanted to flag it.

On Wed, Mar 29, 2023, at 10:00, Christopher Wood wrote:

As mentioned during yesterday's meeting, this email starts the working
group last call for "The Transport Layer Security (TLS) Protocol
Version 1.3" and "IANA Registry Updates for TLS and DTLS” I-Ds, located
here:

- https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis
- https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis

The WG Last Call will end on April 18, 2023.

Please review the documents and submit issues or pull requests via the
GitHub repositories, which can be found at:

- https://github.com/tlswg/tls13-spec
- https://github.com/tlswg/rfc8447bis

Alternatively, you can also send your comments to tls@ietf.org.

Thanks,
Chris
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

2023-04-04 Thread Martin Thomson

I mentioned this to Ekr off-list, but I thought I would add one more thing.  
What did we conclude about a client that refuses to provide a raw public key 
when asked by a server?  Are we in a position to change the minimum length from 
1 to 0 in the response?  The thread didn't really end with a solid conclusion, 
other than a note from Ilari indicating that maybe a zero length RPK would be 
OK in some libraries.

See: https://mailarchive.ietf.org/arch/msg/tls/9rXQFjYhAS0z-ZJleMVUgWmvhAA/

On Thu, Mar 30, 2023, at 15:59, Martin Thomson wrote:
> https://author-tools.ietf.org/diff?doc_1=rfc8446&doc_2=draft-ietf-tls-rfc8446bis-07
>  
> might be helpful to others.
>
> I opened a few issues, but the TLS 1.3 revision is very much ready to 
> be published.
>
> For the 8447 revision, I found that our decision to remove the 
> definition of the fields for each registry to be difficult.  The draft 
> lists changes, so now this document is no longer an easy reference for 
> how to register TLS extension bits.  Not a big deal and I don't want to 
> ask the authors to flip flop here, but I wanted to flag it.
>
> On Wed, Mar 29, 2023, at 10:00, Christopher Wood wrote:
>> As mentioned during yesterday's meeting, this email starts the working 
>> group last call for "The Transport Layer Security (TLS) Protocol 
>> Version 1.3" and "IANA Registry Updates for TLS and DTLS” I-Ds, located 
>> here:
>>
>> - https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis
>> - https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis
>>
>> The WG Last Call will end on April 18, 2023.
>>
>> Please review the documents and submit issues or pull requests via the 
>> GitHub repositories, which can be found at:
>>
>> - https://github.com/tlswg/tls13-spec
>> - https://github.com/tlswg/rfc8447bis
>>
>> Alternatively, you can also send your comments to tls@ietf.org.
>>
>> Thanks,
>> Chris
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

2023-04-04 Thread Rob Sayre

Hi,

I'm still not sure about the list/vector rename. Aside from that, here's
what I found:

> It tightens some requirements and contains
> updated text in areas which were found to be unclear as well as other
> editorial improvements.

"It contains clarifications and tightened requirements." [let's assume some
things were unclear and that editorial improvements are clarifications]

> In addition, it removes the use of the term
> "master" as applied to secrets in favor of the term "main" or shorter
> names where no term was necessary.  This document makes the following
> specific technical changes:

"It also removes the use of the term..."

--

> Forbid negotiating TLS 1.0 and 1.1 as they are now deprecated by
[RFC8996].

I know what's meant here, but deprecated does not mean forbidden. I think
you want to say "NOT RECOMMENDED" in RFC 2119 words, and give a brief
reason for that. [but keep reading]

> The protocol does not provide any forward secrecy guarantees for this
data.
> The server's behavior determines what forward secrecy
> guarantees, if any, apply (see Section 8.1). This behavior is
> not communicated to the client as part of the protocol.
> Therefore, absent out-of-band knowledge of the server's behavior,
> the client should assume that this data is not forward secret.

Here, you use the term "out-of-band", but the PSK text replaced
"out-of-band" with "external[ly]". I can't tell whether this usage is
intentional.

> Because TLS 1.3 forbids renegotiation, if a server has negotiated TLS
> 1.3 and receives a ClientHello at any other time, it MUST terminate

"TLS 1.3 forbids renegotiation. If a server has negotiated TLS 1.3 and
receives a ClientHello at any other time, it MUST terminate..."

[No starting sentences with "Because"]

> Note that [RFC8996] and Appendix E.5 forbid the negotation of TLS
> versions below 1.2; implementations which do not follow that guidance
> MUST behave as described above.

I think this makes my "NOT RECOMMENDED" suggestion above correct. A
forbidden "MUST NOT" wouldn't need this text.

> Unless otherwise specified, trailing data is forbidden.
> That is, senders MUST NOT include data after the structure in the
> "extension_data" field.

This doesn't seem like "MUST NOT", since it could be "otherwise specified".
I think there needs to be a harsher choice made here, or just leave it out.

> When processing an extension, receivers MUST
> abort the handshake with a "decode_error" alert if there is data left
> over after parsing the structure. This does not apply if the
> receiver does not implement or is configured to ignore an extension.

Again, doesn't seem like a "MUST". But the following text says "This does
not apply", without clarifying what "this" is.

> After checking ServerHello.random to determine if the server
> handshake message is a ServerHello or HelloRetryRequest, clients MUST
> check for this extension prior to processing the rest of the
> ServerHello.  This will require clients to parse the ServerHello in ...

Another "this". Here, I think the text means "This requirement...", but
usually a rewrite can fix these ambiguities.

> In the absence of some other specification to the
> contrary, servers which are authenticating with an external PSK MUST
> NOT send the CertificateRequest message either in the main handshake
> or request post-handshake authentication.  [RFC8773] provides an
> extension to permit this, but has not received the level of analysis
> as this specification.

Another one of these "In the absence of..." paragraphs. Maybe these are
intentional? They still sound really redundant to me.

> With a 128-bit key as in AES-128, rekeying 2^64 times has a high
> probability of key reuse within a given connection.  Note that even...

It's almost always possible to drop "Note that..."

The rest of this paragraph is really heavy on em dashes, and needs to be
rewritten. Some of them seem to be parentheticals, but I would try to
rewrite it as short sentences.

> Note that it is common practice in some protocols to use the same

Another "Note that"

> Note that purely deterministic ECC signatures such as deterministic ECDSA
and EdDSA ...

...

> If the resumption_master_secret has been
> compromised, a resumption handshake with EC(DHE) gives protection
> against passive attackers and a full handshake with EC(DHE) gives
> protection against active attackers.

Here, you mean "resumption_secret".

> Note: This specification does not currently permit the server to send

The old text was better. No "Note:".

The "currently" part seems like the wrong thing to write in an immutable
document. Maybe "TLS 1.3 does not currently..."?

> In the absence of some other specification to the contrary,
implementations...

I must be missing the conversation on this stuff. How could anyone write a
spec if every requirement was prefaced with "in the absence of some other
specification to the contrary..."

> Amplifying existing information leaks caused by side effects like
> c

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

2023-04-04 Thread Stephen Farrell



Hiya,

On 05/04/2023 02:47, Sean Turner wrote:

A post IETF 116 bump to make sure folks get their reviews in. If you
look at the diffs from RFC 8446 you can see not that much has
changed. We will also take “I read it and it looks good” response.


I looked at the diff between 8446bis-07 and 8446 and it seems
fine to me. My only comment is that C.4 says one "SHOULD NOT
reuse a key share" - I'd be happier if that was a "MUST NOT"
but understand if we stick with SHOULD NOT. If there were a
good reference showing that it's quite feasible to never
deliberately re-use a key share, even at scale, that'd be a fine 
addition. (I don't have such a reference to offer,

sorry;-)

Cheers,
S.


OpenPGP_0xE4D8E9F997A833DD.asc
Description: OpenPGP public key


OpenPGP_signature
Description: OpenPGP digital signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

2023-04-04 Thread Sean Turner

A post IETF 116 bump to make sure folks get their reviews in. If you look at 
the diffs from RFC 8446 you can see not that much has changed. We will also 
take “I read it and it looks good” response. 

Cheers,
spt

> On Mar 28, 2023, at 21:00, Christopher Wood  wrote:
> 
> As mentioned during yesterday's meeting, this email starts the working group 
> last call for "The Transport Layer Security (TLS) Protocol Version 1.3" and 
> "IANA Registry Updates for TLS and DTLS” I-Ds, located here:
> 
> - https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis
> - https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis
> 
> The WG Last Call will end on April 18, 2023.
> 
> Please review the documents and submit issues or pull requests via the GitHub 
> repositories, which can be found at:
> 
> - https://github.com/tlswg/tls13-spec
> - https://github.com/tlswg/rfc8447bis
> 
> Alternatively, you can also send your comments to tls@ietf.org.
> 
> Thanks,
> Chris
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

2023-03-29 Thread Martin Thomson

https://author-tools.ietf.org/diff?doc_1=rfc8446&doc_2=draft-ietf-tls-rfc8446bis-07
 might be helpful to others.

I opened a few issues, but the TLS 1.3 revision is very much ready to be 
published.

For the 8447 revision, I found that our decision to remove the definition of 
the fields for each registry to be difficult.  The draft lists changes, so now 
this document is no longer an easy reference for how to register TLS extension 
bits.  Not a big deal and I don't want to ask the authors to flip flop here, 
but I wanted to flag it.

On Wed, Mar 29, 2023, at 10:00, Christopher Wood wrote:
> As mentioned during yesterday's meeting, this email starts the working 
> group last call for "The Transport Layer Security (TLS) Protocol 
> Version 1.3" and "IANA Registry Updates for TLS and DTLS” I-Ds, located 
> here:
>
> - https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis
> - https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis
>
> The WG Last Call will end on April 18, 2023.
>
> Please review the documents and submit issues or pull requests via the 
> GitHub repositories, which can be found at:
>
> - https://github.com/tlswg/tls13-spec
> - https://github.com/tlswg/rfc8447bis
>
> Alternatively, you can also send your comments to tls@ietf.org.
>
> Thanks,
> Chris
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

2023-03-28 Thread Christopher Wood

As mentioned during yesterday's meeting, this email starts the working group 
last call for "The Transport Layer Security (TLS) Protocol Version 1.3" and 
"IANA Registry Updates for TLS and DTLS” I-Ds, located here:

- https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8446bis
- https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis

The WG Last Call will end on April 18, 2023.

Please review the documents and submit issues or pull requests via the GitHub 
repositories, which can be found at:

- https://github.com/tlswg/tls13-spec
- https://github.com/tlswg/rfc8447bis

Alternatively, you can also send your comments to tls@ietf.org.

Thanks,
Chris
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-04.txt

2023-03-27 Thread Salz, Rich

> FYI: IANA nicely did a review of -rfc8446bis prior to this IETF and suggested 
> a new section be addd to -rfc84446bis that makes it clear what changes are 
> being made as a result of that update. That section can be found here:
https://www.ietf.org/archive/id/draft-ietf-tls-rfc8446bis-07.html#name-changes-for-this-rfc

Yes, it was reading that section that brought the question to my mind.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-04.txt

2023-03-27 Thread Sean Turner

FYI: IANA nicely did a review of -rfc8446bis prior to this IETF and suggested a 
new section be addd to -rfc84446bis that makes it clear what changes are being 
made as a result of that update. That section can be found here:
https://www.ietf.org/archive/id/draft-ietf-tls-rfc8446bis-07.html#name-changes-for-this-rfc

spt

> On Mar 27, 2023, at 19:15, Salz, Rich  
> wrote:
> 
> - 8446 registered new code points
> - 8447 (mostly) changed the policies for issuance of new code points
>  
> I'm suggesting that we maintain that separation for the -bis documents.
>  
> I can live with the current setup then.
>  
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-04.txt

2023-03-27 Thread Salz, Rich

- 8446 registered new code points
- 8447 (mostly) changed the policies for issuance of new code points

I'm suggesting that we maintain that separation for the -bis documents.

I can live with the current setup then.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-04.txt

2023-03-27 Thread Eric Rescorla

On Mon, Mar 27, 2023 at 2:28 AM Salz, Rich  wrote:

>
>
> I would prefer to have any substantive changes in 8446-bis and the policy
> changes in 8447-bis
>
>
>
> Now I’m more confused, since I consider policy changes substantive
> things.  And I’m not sure what policy is.
>

Looking at 8446 and 8447:

- 8446 registered new code points
- 8447 (mostly) changed the policies for issuance of new code points

I'm suggesting that we maintain that separation for the -bis documents.

-Ekr


>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-04.txt

2023-03-27 Thread Salz, Rich


I would prefer to have any substantive changes in 8446-bis and the policy 
changes in 8447-bis

Now I’m more confused, since I consider policy changes substantive things.  And 
I’m not sure what policy is.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-04.txt

2023-03-27 Thread Eric Rescorla

I would prefer to have any substantive changes in 8446-bis and the policy
changes in 8447-bis

-Ekr


On Mon, Mar 27, 2023 at 2:10 AM Salz, Rich  wrote:

>
> > Title : IANA Registry Updates for TLS and DTLS
> > Authors : Joe Salowey
> > Sean Turner
> > Filename : draft-ietf-tls-rfc8447bis-04.txt
> ...
> > This document updates the changes to TLS and DTLS IANA registries
> > made in RFC 8447. It adds a new value "D" for discouraged to the
> > recommended column of the selected TLS registries.
>
> Rfc84460bis makes some changes to the registries. Does it make sense to
> merge those changes into this document so that we have fewer overlapping
> changes?  (The items in Section 11.1 defnitely, and maybe some of the
> changes in Section 11)
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-04.txt

2023-03-27 Thread Salz, Rich



> Title : IANA Registry Updates for TLS and DTLS
> Authors : Joe Salowey
> Sean Turner
> Filename : draft-ietf-tls-rfc8447bis-04.txt
...
> This document updates the changes to TLS and DTLS IANA registries
> made in RFC 8447. It adds a new value "D" for discouraged to the
> recommended column of the selected TLS registries.

Rfc84460bis makes some changes to the registries. Does it make sense to merge 
those changes into this document so that we have fewer overlapping changes?  
(The items in Section 11.1 defnitely, and maybe some of the changes in Section 
11)

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] I-D Action: draft-ietf-tls-rfc8447bis-04.txt

2023-03-27 Thread internet-drafts



A New Internet-Draft is available from the on-line Internet-Drafts
directories. This Internet-Draft is a work item of the Transport Layer
Security (TLS) WG of the IETF.

   Title   : IANA Registry Updates for TLS and DTLS
   Authors : Joe Salowey
 Sean Turner
   Filename: draft-ietf-tls-rfc8447bis-04.txt
   Pages   : 14
   Date: 2023-03-27

Abstract:
   This document updates the changes to TLS and DTLS IANA registries
   made in RFC 8447.  It adds a new value "D" for discouraged to the
   recommended column of the selected TLS registries.

   This document updates the following RFCs: 3749, 5077, 4680, 5246,
   5705, 5878, 6520, 7301, and 8447.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-rfc8447bis-04.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-rfc8447bis-04

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-03.txt

2023-02-01 Thread Joseph Salowey

This update changes the draft to an update of RFC 8447 instead of
obsoleting it, populates the 'D' values for some of the entries in the
registries and changes the exporter registry from specification required to
expert review.

Cheers,

Joe

On Wed, Feb 1, 2023 at 9:15 PM  wrote:

>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Transport Layer Security WG of the IETF.
>
> Title   : IANA Registry Updates for TLS and DTLS
> Authors : Joe Salowey
>   Sean Turner
>   Filename: draft-ietf-tls-rfc8447bis-03.txt
>   Pages   : 14
>   Date: 2023-02-01
>
> Abstract:
>This document updates the changes to TLS and DTLS IANA registries
>made in RFC 8447.  It adds a new value "D" for discouraged to the
>recommended column of the selected TLS registries.
>
>This document updates the following RFCs: 3749, 5077, 4680, 5246,
>5705, 5878, 6520, 7301, and 8447.
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-tls-rfc8447bis-03.html
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-rfc8447bis-03
>
>
> Internet-Drafts are also available by rsync at rsync.ietf.org:
> :internet-drafts
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] I-D Action: draft-ietf-tls-rfc8447bis-03.txt

2023-02-01 Thread internet-drafts



A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

Title   : IANA Registry Updates for TLS and DTLS
Authors : Joe Salowey
  Sean Turner
  Filename: draft-ietf-tls-rfc8447bis-03.txt
  Pages   : 14
  Date: 2023-02-01

Abstract:
   This document updates the changes to TLS and DTLS IANA registries
   made in RFC 8447.  It adds a new value "D" for discouraged to the
   recommended column of the selected TLS registries.

   This document updates the following RFCs: 3749, 5077, 4680, 5246,
   5705, 5878, 6520, 7301, and 8447.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-rfc8447bis-03.html

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-tls-rfc8447bis-03


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt

2023-01-31 Thread Rob Sayre

On Sun, Jan 29, 2023 at 3:24 PM Martin Thomson  wrote:

> On Sun, Jan 29, 2023, at 10:46, Joseph Salowey wrote:
> > I think the current working group consensus for the policy of the
> > recommended column is reflected in the following statement:
> >
> > Setting a value to "Y" or "D" in the "Recommended" column requires IETF
> > Standards Action [RFC8126
> > ].
>
> > Any state transition to or from a "Y" or "D" value requires IESG
> > Approval."
>
> This is my position, so don't change it :)  John wants to mark a ton of
> things with "D".  I think that a good number of the things he asks for
> should be marked "D", but I wouldn't want an expert to be put in that
> position.  "Y" and "D" are both effective statements because they come with
> the "authority" of the IETF (for what that is worth). To require any lesser
> process than consensus would undermine the value of the label.
>

In case there was any doubt, I was also agreeing with Joseph Salowey
further up in the thread. Martin's elaboration here is fine by me, but
Joseph did well to write the literal consensus text.

thanks,
Rob
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt

2023-01-30 Thread John Mattsson

On Sun, Jan 29, 2023, at 10:46, Joseph Salowey wrote:
> I think the current working group consensus for the policy of the
> recommended column is reflected in the following statement:

I can live with that. I definitely don’t want Rich to quit.

Martin Thomson:
>"Y" and "D" are both effective statements because they come with the 
>"authority" of the IETF (for what that
> is worth). To require any lesser process than consensus would undermine the 
> value of the label.

That is a good point.

Cheers,
John

From: TLS  on behalf of Martin Thomson 

Date: Monday, 30 January 2023 at 00:25
To: tls@ietf.org 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt
On Sun, Jan 29, 2023, at 10:46, Joseph Salowey wrote:
> I think the current working group consensus for the policy of the
> recommended column is reflected in the following statement:
>
> Setting a value to "Y" or "D" in the "Recommended" column requires IETF
> Standards Action [RFC8126
> <https://betaapp.fastmail.com/mail/IETF.tls/compose?u=47c94097#RFC8126>].
> Any state transition to or from a "Y" or "D" value requires IESG
> Approval."

This is my position, so don't change it :)  John wants to mark a ton of things 
with "D".  I think that a good number of the things he asks for should be 
marked "D", but I wouldn't want an expert to be put in that position.  "Y" and 
"D" are both effective statements because they come with the "authority" of the 
IETF (for what that is worth). To require any lesser process than consensus 
would undermine the value of the label.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt

2023-01-29 Thread Martin Thomson

On Sun, Jan 29, 2023, at 10:46, Joseph Salowey wrote:
> I think the current working group consensus for the policy of the 
> recommended column is reflected in the following statement:
>
> Setting a value to "Y" or "D" in the "Recommended" column requires IETF 
> Standards Action [RFC8126 
> ]. 
> Any state transition to or from a "Y" or "D" value requires IESG 
> Approval."

This is my position, so don't change it :)  John wants to mark a ton of things 
with "D".  I think that a good number of the things he asks for should be 
marked "D", but I wouldn't want an expert to be put in that position.  "Y" and 
"D" are both effective statements because they come with the "authority" of the 
IETF (for what that is worth). To require any lesser process than consensus 
would undermine the value of the label.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt

2023-01-28 Thread Rob Sayre

This is right. I don’t think it needs to be more difficult.

thanks,
Rob


On Sat, Jan 28, 2023 at 15:47 Joseph Salowey  wrote:

> I think the current working group consensus for the policy of the
> recommended column is reflected in the following statement:
>
> Setting a value to "Y" or "D" in the "Recommended" column requires IETF
> Standards Action [RFC8126 <#m_962365536413309078_RFC8126>]. Any state
> transition to or from a "Y" or "D" value requires IESG Approval."
>
>
> On Sat, Jan 28, 2023 at 12:49 PM Salz, Rich  40akamai@dmarc.ietf.org> wrote:
>
>> It is not hard to see that e.g., NULL encryption violates the properties.
>>
>>
>>
>> Sure.  And for years we thought MD5 met the properties, until it didn’t.
>> And now, RSA meets the properties, until it doesn’t.
>>
>>
>>
>> The alternative is that someone afterwards need to write a standards
>> track draft and progress that through IETF. As an author of such a draft I
>> would rather not have do that work. I would much rather help evaluating if
>> an item violates the properties before registration.
>>
>>
>>
>> That’s better than trusting security to a handful of people. I mean, if
>> you’re making a judgement that global security needs to move away from an
>> algorithm, having to get a document through standards track seems a very
>> small price to pay.
>>
>>
>>
>> I don’t want that job, and I’d quit if the TLS registries were changed
>> that way. I don’t think it’s likely.
>>
> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt

2023-01-28 Thread Joseph Salowey

I think the current working group consensus for the policy of the
recommended column is reflected in the following statement:

Setting a value to "Y" or "D" in the "Recommended" column requires IETF
Standards Action [RFC8126 <#RFC8126>]. Any state transition to or from a
"Y" or "D" value requires IESG Approval."


On Sat, Jan 28, 2023 at 12:49 PM Salz, Rich  wrote:

> It is not hard to see that e.g., NULL encryption violates the properties.
>
>
>
> Sure.  And for years we thought MD5 met the properties, until it didn’t.
> And now, RSA meets the properties, until it doesn’t.
>
>
>
> The alternative is that someone afterwards need to write a standards track
> draft and progress that through IETF. As an author of such a draft I would
> rather not have do that work. I would much rather help evaluating if an
> item violates the properties before registration.
>
>
>
> That’s better than trusting security to a handful of people. I mean, if
> you’re making a judgement that global security needs to move away from an
> algorithm, having to get a document through standards track seems a very
> small price to pay.
>
>
>
> I don’t want that job, and I’d quit if the TLS registries were changed
> that way. I don’t think it’s likely.
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt

2023-01-28 Thread Salz, Rich

It is not hard to see that e.g., NULL encryption violates the properties.

Sure.  And for years we thought MD5 met the properties, until it didn’t.  And 
now, RSA meets the properties, until it doesn’t.

The alternative is that someone afterwards need to write a standards track 
draft and progress that through IETF. As an author of such a draft I would 
rather not have do that work. I would much rather help evaluating if an item 
violates the properties before registration.

That’s better than trusting security to a handful of people. I mean, if you’re 
making a judgement that global security needs to move away from an algorithm, 
having to get a document through standards track seems a very small price to 
pay.

I don’t want that job, and I’d quit if the TLS registries were changed that 
way. I don’t think it’s likely.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt

2023-01-28 Thread Viktor Dukhovni

On Sat, Jan 28, 2023 at 02:18:01PM -0500, Viktor Dukhovni wrote:
> On Mon, Oct 24, 2022 at 06:25:39PM +, Salz, Rich wrote:
> 
> > This draft looks good.
> > 
> > One nit, omitted "TLS" before SignatureAlgorithm in two places in
> > https://www.ietf.org/archive/id/draft-ietf-tls-rfc8447bis-02.html#section-15-3
> 
> Would it be appropriate to clarify the status of Ed25519 in DTLS?
> 
> https://mta.openssl.org/pipermail/openssl-users/2019-November/011582.html
> 
> and if so, where should such clarification happen?  The registry already
> marks Ed25519 as "DTLS-OK", but unclear on what basis...

See also:


https://mailarchive.ietf.org/arch/browse/tls/?gbt=1&index=7Mjmu7mANU5l5mcJQKd3BAY0_3A

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt

2023-01-28 Thread Viktor Dukhovni

On Mon, Oct 24, 2022 at 06:25:39PM +, Salz, Rich wrote:

> This draft looks good.
> 
> One nit, omitted "TLS" before SignatureAlgorithm in two places in
> https://www.ietf.org/archive/id/draft-ietf-tls-rfc8447bis-02.html#section-15-3

Would it be appropriate to clarify the status of Ed25519 in DTLS?

https://mta.openssl.org/pipermail/openssl-users/2019-November/011582.html

and if so, where should such clarification happen?  The registry already
marks Ed25519 as "DTLS-OK", but unclear on what basis...

-- 
Viktor.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt

2023-01-28 Thread John Mattsson

Hi Rich,

New suggestion for specification required: Items violating the security 
properties shall be marked as D. Otherwise N.

It is not hard to see that e.g., NULL encryption violates the properties.

The alternative is that someone afterwards need to write a standards track 
draft and progress that through IETF. As an author of such a draft I would 
rather not have do that work. I would much rather help evaluating if an item 
violates the properties before registration.

https://datatracker.ietf.org/doc/draft-mattsson-tls-psk-ke-dont-dont-dont/

Cheers,
John

Sent from Outlook for iOS<https://aka.ms/o0ukef>

From: Salz, Rich 
Sent: Saturday, January 28, 2023 6:17 PM
To: John Mattsson ; TLS@ietf.org 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt

As one of the designated experts, I would rather not make that judgement call.  
It’s enough to verify that there is documentation and it is possible to 
implement from that documentation.

From: John Mattsson 
Date: Saturday, January 28, 2023 at 11:57 AM
To: "tls@ietf.org" 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt

Hi,

The current document states that setting the Recommended item to "D" requires 
Standards Action. I think the designated experts should be given the ability to 
mark specification required registrations as “D” Discouraged. In particular, I 
think the designated experts should mark anything that violates the security 
properties described in Appendix F of RFC 8446 as Discouraged, but I think the 
experts should be given the ability to mark anything they think “might result 
in problems if they are used, such as a weak cryptographic algorithm or a 
mechanism that might cause interoperability problems in deployment.” as “D” 
Discouraged.



Cheers,

John

From: TLS  on behalf of John Mattsson 

Date: Thursday, 12 January 2023 at 07:09
To: tls@ietf.org 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt
Hi,

I really like the updates to the Recommended column. Making "Y" normative 
RECOMMENDED and introducing "D" seems like great changes. Good job!


Some high level comments/questions/suggestions
-

- It is very hard to understand from the TLS Cipher Suites registry which 
cipher suites that can be used in TLS 1.3. I think it would be good to 
introduce a TLS 1.3 column.

- Should TLS versions (0x0304, 0x303, ...) and their Recommended status be 
added as a new registry? I think that would be good.

- Maybe rename "DTLS-OK" to "DTLS"? md5 can be e.g. be used in DTLS but is not 
ok to use in DTLS.

- How do one find information on which parameters are QUIC-OK?


Comments on current text:
-

- "undertaken as part of the TLS 1.3 development process."
The abstract should be updated. The part above could be removed.

I think the IANA policies need more work. See some examples below:

- "Setting the Recommended item to "Y" or "D" or changing a item whose
current value is "Y" or "D" requires Standards Action [RFC8126]."
This seems redundant as there is a sentence below it that say the same thing in 
a much better way: “Changing the Recommended status of an item in a Standards 
Track RFC requires Standards Action [RFC8126].”

- "Adding a value Y to the "Recommended" column requires Standards Action 
{{RFC8126}}."
Seems to be different from the general rule above.

- "IESG Approval is REQUIRED for a Y->N transition."
Also Y->D I assume

Cheers,
John

From: TLS  on behalf of internet-dra...@ietf.org 

Date: Monday, 24 October 2022 at 18:32
To: i-d-annou...@ietf.org 
Cc: tls@ietf.org 
Subject: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

Title   : IANA Registry Updates for TLS and DTLS
Authors : Joe Salowey
  Sean Turner
  Filename: draft-ietf-tls-rfc8447bis-02.txt
  Pages   : 22
  Date: 2022-10-23

Abstract:
   This document describes a number of changes to TLS and DTLS IANA
   registries that range from adding notes to the registry all the way
   to changing the registration policy.  These changes were mostly
   motivated by WG review of the TLS- and DTLS-related registries
   undertaken as part of the TLS 1.3 development process.

   This document obsoletes RFC 8447 and updates the following RFCs:
   3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/__;!!GjvTz_vk!QqPr9x6IrhEPWJfLGVqNYz3rfCaztfoH4JpYD5iw106aYZ

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt

2023-01-28 Thread Salz, Rich

As one of the designated experts, I would rather not make that judgement call.  
It’s enough to verify that there is documentation and it is possible to 
implement from that documentation.

From: John Mattsson 
Date: Saturday, January 28, 2023 at 11:57 AM
To: "tls@ietf.org" 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt

Hi,

The current document states that setting the Recommended item to "D" requires 
Standards Action. I think the designated experts should be given the ability to 
mark specification required registrations as “D” Discouraged. In particular, I 
think the designated experts should mark anything that violates the security 
properties described in Appendix F of RFC 8446 as Discouraged, but I think the 
experts should be given the ability to mark anything they think “might result 
in problems if they are used, such as a weak cryptographic algorithm or a 
mechanism that might cause interoperability problems in deployment.” as “D” 
Discouraged.

Cheers,

John

From: TLS  on behalf of John Mattsson 

Date: Thursday, 12 January 2023 at 07:09
To: tls@ietf.org 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt
Hi,

I really like the updates to the Recommended column. Making "Y" normative 
RECOMMENDED and introducing "D" seems like great changes. Good job!

Some high level comments/questions/suggestions
-

- It is very hard to understand from the TLS Cipher Suites registry which 
cipher suites that can be used in TLS 1.3. I think it would be good to 
introduce a TLS 1.3 column.

- Should TLS versions (0x0304, 0x303, ...) and their Recommended status be 
added as a new registry? I think that would be good.

- Maybe rename "DTLS-OK" to "DTLS"? md5 can be e.g. be used in DTLS but is not 
ok to use in DTLS.

- How do one find information on which parameters are QUIC-OK?

Comments on current text:
-

- "undertaken as part of the TLS 1.3 development process."
The abstract should be updated. The part above could be removed.

I think the IANA policies need more work. See some examples below:

- "Setting the Recommended item to "Y" or "D" or changing a item whose
current value is "Y" or "D" requires Standards Action [RFC8126]."
This seems redundant as there is a sentence below it that say the same thing in 
a much better way: “Changing the Recommended status of an item in a Standards 
Track RFC requires Standards Action [RFC8126].”

- "Adding a value Y to the "Recommended" column requires Standards Action 
{{RFC8126}}."
Seems to be different from the general rule above.

- "IESG Approval is REQUIRED for a Y->N transition."
Also Y->D I assume

Cheers,
John

From: TLS  on behalf of internet-dra...@ietf.org 

Date: Monday, 24 October 2022 at 18:32
To: i-d-annou...@ietf.org 
Cc: tls@ietf.org 
Subject: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

Title       : IANA Registry Updates for TLS and DTLS
Authors : Joe Salowey
  Sean Turner
  Filename: draft-ietf-tls-rfc8447bis-02.txt
  Pages   : 22
  Date: 2022-10-23

Abstract:
   This document describes a number of changes to TLS and DTLS IANA
   registries that range from adding notes to the registry all the way
   to changing the registration policy.  These changes were mostly
   motivated by WG review of the TLS- and DTLS-related registries
   undertaken as part of the TLS 1.3 development process.

   This document obsoletes RFC 8447 and updates the following RFCs:
   3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/__;!!GjvTz_vk!QqPr9x6IrhEPWJfLGVqNYz3rfCaztfoH4JpYD5iw106aYZDEdOyxeFLDqaUR1uAyLxotH5hNu3fh11aHm-50pFo4Mpcc$>

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-rfc8447bis-02.html<https://urldefense.com/v3/__https:/www.ietf.org/archive/id/draft-ietf-tls-rfc8447bis-02.html__;!!GjvTz_vk!QqPr9x6IrhEPWJfLGVqNYz3rfCaztfoH4JpYD5iw106aYZDEdOyxeFLDqaUR1uAyLxotH5hNu3fh11aHm-50pDeo0Y4W$>

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-rfc8447bis-02<https://urldefense.com/v3/__https:/www.ietf.org/rfcdiff?url2=draft-ietf-tls-rfc8447bis-02__;!!GjvTz_vk!QqPr9x6IrhEPWJfLGVqNYz3rfCaztfoH4JpYD5iw106aYZDEdOyxeFLDqaUR1uAyLxotH5hNu3fh11aHm-50pFUzvp3C$>

Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts

___

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt

2023-01-28 Thread John Mattsson

Hi,

The current document states that setting the Recommended item to "D" requires 
Standards Action. I think the designated experts should be given the ability to 
mark specification required registrations as “D” Discouraged. In particular, I 
think the designated experts should mark anything that violates the security 
properties described in Appendix F of RFC 8446 as Discouraged, but I think the 
experts should be given the ability to mark anything they think “might result 
in problems if they are used, such as a weak cryptographic algorithm or a 
mechanism that might cause interoperability problems in deployment.” as “D” 
Discouraged.



Cheers,

John

From: TLS  on behalf of John Mattsson 

Date: Thursday, 12 January 2023 at 07:09
To: tls@ietf.org 
Subject: Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt
Hi,

I really like the updates to the Recommended column. Making "Y" normative 
RECOMMENDED and introducing "D" seems like great changes. Good job!


Some high level comments/questions/suggestions
-

- It is very hard to understand from the TLS Cipher Suites registry which 
cipher suites that can be used in TLS 1.3. I think it would be good to 
introduce a TLS 1.3 column.

- Should TLS versions (0x0304, 0x303, ...) and their Recommended status be 
added as a new registry? I think that would be good.

- Maybe rename "DTLS-OK" to "DTLS"? md5 can be e.g. be used in DTLS but is not 
ok to use in DTLS.

- How do one find information on which parameters are QUIC-OK?


Comments on current text:
-

- "undertaken as part of the TLS 1.3 development process."
The abstract should be updated. The part above could be removed.

I think the IANA policies need more work. See some examples below:

- "Setting the Recommended item to "Y" or "D" or changing a item whose
current value is "Y" or "D" requires Standards Action [RFC8126]."
This seems redundant as there is a sentence below it that say the same thing in 
a much better way: “Changing the Recommended status of an item in a Standards 
Track RFC requires Standards Action [RFC8126].”

- "Adding a value Y to the "Recommended" column requires Standards Action 
{{RFC8126}}."
Seems to be different from the general rule above.

- "IESG Approval is REQUIRED for a Y->N transition."
Also Y->D I assume

Cheers,
John

From: TLS  on behalf of internet-dra...@ietf.org 

Date: Monday, 24 October 2022 at 18:32
To: i-d-annou...@ietf.org 
Cc: tls@ietf.org 
Subject: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

Title   : IANA Registry Updates for TLS and DTLS
Authors : Joe Salowey
  Sean Turner
  Filename: draft-ietf-tls-rfc8447bis-02.txt
  Pages   : 22
  Date: 2022-10-23

Abstract:
   This document describes a number of changes to TLS and DTLS IANA
   registries that range from adding notes to the registry all the way
   to changing the registration policy.  These changes were mostly
   motivated by WG review of the TLS- and DTLS-related registries
   undertaken as part of the TLS 1.3 development process.

   This document obsoletes RFC 8447 and updates the following RFCs:
   3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-rfc8447bis-02.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-rfc8447bis-02


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt

2023-01-11 Thread John Mattsson

Hi,

I really like the updates to the Recommended column. Making "Y" normative 
RECOMMENDED and introducing "D" seems like great changes. Good job!


Some high level comments/questions/suggestions
-

- It is very hard to understand from the TLS Cipher Suites registry which 
cipher suites that can be used in TLS 1.3. I think it would be good to 
introduce a TLS 1.3 column.

- Should TLS versions (0x0304, 0x303, ...) and their Recommended status be 
added as a new registry? I think that would be good.

- Maybe rename "DTLS-OK" to "DTLS"? md5 can be e.g. be used in DTLS but is not 
ok to use in DTLS.

- How do one find information on which parameters are QUIC-OK?


Comments on current text:
-

- "undertaken as part of the TLS 1.3 development process."
The abstract should be updated. The part above could be removed.

I think the IANA policies need more work. See some examples below:

- "Setting the Recommended item to "Y" or "D" or changing a item whose
current value is "Y" or "D" requires Standards Action [RFC8126]."
This seems redundant as there is a sentence below it that say the same thing in 
a much better way: “Changing the Recommended status of an item in a Standards 
Track RFC requires Standards Action [RFC8126].”

- "Adding a value Y to the "Recommended" column requires Standards Action 
{{RFC8126}}."
Seems to be different from the general rule above.

- "IESG Approval is REQUIRED for a Y->N transition."
Also Y->D I assume

Cheers,
John

From: TLS  on behalf of internet-dra...@ietf.org 

Date: Monday, 24 October 2022 at 18:32
To: i-d-annou...@ietf.org 
Cc: tls@ietf.org 
Subject: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

Title   : IANA Registry Updates for TLS and DTLS
Authors : Joe Salowey
  Sean Turner
  Filename: draft-ietf-tls-rfc8447bis-02.txt
  Pages   : 22
  Date: 2022-10-23

Abstract:
   This document describes a number of changes to TLS and DTLS IANA
   registries that range from adding notes to the registry all the way
   to changing the registration policy.  These changes were mostly
   motivated by WG review of the TLS- and DTLS-related registries
   undertaken as part of the TLS 1.3 development process.

   This document obsoletes RFC 8447 and updates the following RFCs:
   3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-rfc8447bis-02.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-rfc8447bis-02


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt

2022-10-24 Thread Salz, Rich

This draft looks good.

One nit, omitted "TLS" before SignatureAlgorithm in two places in 
https://www.ietf.org/archive/id/draft-ietf-tls-rfc8447bis-02.html#section-15-3



___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-01.txt

2022-10-24 Thread Joseph Salowey

On Fri, Jul 8, 2022 at 12:06 AM Ilari Liusvaara 
wrote:

> On Thu, Jul 07, 2022 at 09:25:15PM -0700, internet-dra...@ietf.org wrote:
> >
> > A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> > This draft is a work item of the Transport Layer Security WG of the IETF.
> >
> > Title   : IANA Registry Updates for TLS and DTLS
> > Authors : Joe Salowey
> >   Sean Turner
> >   Filename: draft-ietf-tls-rfc8447bis-01.txt
> >   Pages   : 24
> >   Date: 2022-07-07
>
> I find this from section 7 confusing:
>
> >   *  IANA [SHALL update/has updated] this registry to include a "TLS
> >  1.3" column that lists the messages in which the extension may
> >  appear.  This column [SHALL be/has been] initially populated from
> >  the table in Section 4.2 of [I-D.ietf-tls-rfc8446bis] with any
> >  extension not listed there marked as "-" to indicate that it is
> >  not used by TLS 1.3.
>
> The issue here is:
>
> - The [SHALL/has] language means pending change.
> - The TLS 1.3 column in the registry already exists.
> - There are about dozen TLS 1.3 extensions in the extensions registry
>   that are not in the table in RFC8446bis (few are even recommended).
> - The text can be read to clear TLS 1.3 flags on those ~dozen
>   extensions, which I do not think is intended.
>
>
> There's also this:
>
> >   *  IANA [SHALL update/has updated] this registry to include the
> >  "key_share", "pre_shared_key", "psk_key_exchange_modes",
> >  "early_data", "cookie", "supported_versions",
> >  "certificate_authorities", "oid_filters", "post_handshake_auth",
> >  and "signature_algorithms_cert", extensions with the values
> >  defined in [I-D.ietf-tls-rfc8446bis] and the "Recommended" value
> >  of "Y".
>
> As far as I can tell, the values in the registry already match what is
> listed in rfc8446bis (other than maybe references).
>
>
[Joe] Thanks for reviewing this draft.  The current draft is written so it
obsoletes rfc 8447. I think this is the main source of the issues you
list.  I think it would be clearer if this draft just updated RFC8447 so we
don't have to repeat information that has already been acted upon.  I think
this would make it easier to review and easier for IANA to implement.  I
just submitted a new version with section 7 written as if it is an update.

Does this make things clearer?
Is there a reason why we should not take the update approach?



>
> And while going over this, I also found that extension #52
> transparency_info seems to have recommended=Y. The problem is that
> the RFC9162 is Experimental, while recommended=Y requires standard
> action.
>
>
[Joe] RFC9162 did ask for a Y recommendation, however I'm not sure that an
experimental draft is a "standards action" since I'm not sure it has to go
through IESG review.  For this particular instance  the draft did go
through IESG review and I think the Y value is intentional.  Since
experimental drafts do not need to go through IESG review.  I added some
text to the notes in section 7 that might help point this out during the
process, but perhaps we should be explicit about mentioning the
expectations around experimental and informational tracks.


>
>
> -Ilari
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] I-D Action: draft-ietf-tls-rfc8447bis-02.txt

2022-10-24 Thread internet-drafts



A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

Title   : IANA Registry Updates for TLS and DTLS
Authors : Joe Salowey
  Sean Turner
  Filename: draft-ietf-tls-rfc8447bis-02.txt
  Pages   : 22
  Date: 2022-10-23

Abstract:
   This document describes a number of changes to TLS and DTLS IANA
   registries that range from adding notes to the registry all the way
   to changing the registration policy.  These changes were mostly
   motivated by WG review of the TLS- and DTLS-related registries
   undertaken as part of the TLS 1.3 development process.

   This document obsoletes RFC 8447 and updates the following RFCs:
   3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-rfc8447bis-02.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-rfc8447bis-02


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] I-D Action: draft-ietf-tls-rfc8447bis-01.txt

2022-07-08 Thread Ilari Liusvaara

On Thu, Jul 07, 2022 at 09:25:15PM -0700, internet-dra...@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Transport Layer Security WG of the IETF.
> 
> Title   : IANA Registry Updates for TLS and DTLS
> Authors : Joe Salowey
>   Sean Turner
>   Filename: draft-ietf-tls-rfc8447bis-01.txt
>   Pages   : 24
>   Date: 2022-07-07

I find this from section 7 confusing:

>   *  IANA [SHALL update/has updated] this registry to include a "TLS
>  1.3" column that lists the messages in which the extension may
>  appear.  This column [SHALL be/has been] initially populated from
>  the table in Section 4.2 of [I-D.ietf-tls-rfc8446bis] with any
>  extension not listed there marked as "-" to indicate that it is
>  not used by TLS 1.3.

The issue here is:

- The [SHALL/has] language means pending change.
- The TLS 1.3 column in the registry already exists.
- There are about dozen TLS 1.3 extensions in the extensions registry
  that are not in the table in RFC8446bis (few are even recommended).
- The text can be read to clear TLS 1.3 flags on those ~dozen
  extensions, which I do not think is intended.


There's also this:

>   *  IANA [SHALL update/has updated] this registry to include the
>  "key_share", "pre_shared_key", "psk_key_exchange_modes",
>  "early_data", "cookie", "supported_versions",
>  "certificate_authorities", "oid_filters", "post_handshake_auth",
>  and "signature_algorithms_cert", extensions with the values
>  defined in [I-D.ietf-tls-rfc8446bis] and the "Recommended" value
>  of "Y".

As far as I can tell, the values in the registry already match what is
listed in rfc8446bis (other than maybe references).


And while going over this, I also found that extension #52
transparency_info seems to have recommended=Y. The problem is that
the RFC9162 is Experimental, while recommended=Y requires standard
action.



-Ilari

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] I-D Action: draft-ietf-tls-rfc8447bis-01.txt

2022-07-07 Thread internet-drafts



A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

Title   : IANA Registry Updates for TLS and DTLS
Authors : Joe Salowey
  Sean Turner
  Filename: draft-ietf-tls-rfc8447bis-01.txt
  Pages   : 24
  Date: 2022-07-07

Abstract:
   This document describes a number of changes to TLS and DTLS IANA
   registries that range from adding notes to the registry all the way
   to changing the registration policy.  These changes were mostly
   motivated by WG review of the TLS- and DTLS-related registries
   undertaken as part of the TLS 1.3 development process.

   This document obsoletes RFC 8447 and updates the following RFCs:
   3749, 5077, 4680, 5246, 5705, 5878, 6520, and 7301.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-rfc8447bis-01.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tls-rfc8447bis-01


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] I-D Action: draft-ietf-tls-rfc8447bis-00.txt

2022-03-29 Thread internet-drafts



A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Transport Layer Security WG of the IETF.

Title   : IANA Registry Updates for TLS and DTLS
Authors : Joe Salowey
  Sean Turner
Filename: draft-ietf-tls-rfc8447bis-00.txt
Pages   : 20
Date: 2022-03-28

Abstract:
   This document describes a number of changes to TLS and DTLS IANA
   registries that range from adding notes to the registry all the way
   to changing the registration policy.  These changes were mostly
   motivated by WG review of the TLS- and DTLS-related registries
   undertaken as part of the TLS 1.3 development process.

   This document obsoletes RFC8447 and updates the following RFCs: 3749,
   5077, 4680, 5246, 5705, 5878, 6520, 7301.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tls-rfc8447bis/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-tls-rfc8447bis-00.html


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] The TLS WG has placed draft-salowey-tls-rfc8447bis in state "Adopted by a WG"

2022-03-06 Thread IETF Secretariat



The TLS WG has placed draft-salowey-tls-rfc8447bis in state
Adopted by a WG (entered by Christopher Wood)

The document is available at
https://datatracker.ietf.org/doc/draft-salowey-tls-rfc8447bis/


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for draft-salowey-tls-rfc8447bis

2022-03-06 Thread Christopher Wood

Thanks, folks, for chiming in on this thread! Based on discussion that took 
place during IETF 112 and on this thread, I’m declaring consensus to adopt as a 
WG item. 

Authors, please submit draft-ietf-tls-rfc8447bis at your earliest convenience.

Best,
Chris

> On Feb 18, 2022, at 7:32 PM, Christopher Wood  wrote:
> 
> Hi folks,
> 
> Following up on the TLS WG meeting in IETF 112 and draft update in December, 
> this email begins an adoption call for draft-salowey-tls-rfc8447bis, located 
> here:
> 
>   https://datatracker.ietf.org/doc/draft-salowey-tls-rfc8447bis/
> 
> This adoption call will last for two weeks. Please reply to this email by 
> March 4 indicating whether you think this document should be adopted and 
> worked on by the WG.
> 
> Thanks,
> Chris
> 
> 
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for draft-salowey-tls-rfc8447bis

2022-02-23 Thread Martin Thomson

One additional bug I noticed:

Exporter Value  | Recommended |
|-|
client finished | Y |
server finished | Y |
master secret   | Y |
key expansion   | Y |

These should probably be 'D', based on the note in RFC 5705 (which oddly, 
references itself in the equivalent of third person here):

   Note: (1) These entries are reserved and MUST NOT be used for the
   purpose described in RFC 5705, in order to avoid confusion with
   similar, but distinct, use in RFC 5246.

On Thu, Feb 24, 2022, at 08:41, Martin Thomson wrote:
> Adopt.
>
> I found the changes from 8447 hard to find without a diff:
>
> https://www.ietf.org/rfcdiff?url1=rfc8447&url2=draft-salowey-tls-rfc8447bis-01
>
> Some comments on the content:
>
> * Recommended = D requires standards action.  I think that you might 
> want IETF consensus instead.
>
> * A lot of the "changes" here have already been carried out.  Perhaps 
> this document can be a lot shorter.  I still think that the generic 
> text is useful to keep, but there are sections that concentrate only on 
> stuff that has already been done by IANA.  Maybe those sections can go.
>
> * This cites a specific draft version of TLS 1.3 rather than RFC 8446 
> and I can't see why.
>
> On Sat, Feb 19, 2022, at 14:32, Christopher Wood wrote:
>> Hi folks,
>>
>> Following up on the TLS WG meeting in IETF 112 and draft update in 
>> December, this email begins an adoption call for 
>> draft-salowey-tls-rfc8447bis, located here:
>>
>>https://datatracker.ietf.org/doc/draft-salowey-tls-rfc8447bis/
>>   
>> This adoption call will last for two weeks. Please reply to this email 
>> by March 4 indicating whether you think this document should be adopted 
>> and worked on by the WG.
>>
>> Thanks,
>> Chris
>>
>>
>> ___
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for draft-salowey-tls-rfc8447bis

2022-02-23 Thread Martin Thomson

Adopt.

I found the changes from 8447 hard to find without a diff:

https://www.ietf.org/rfcdiff?url1=rfc8447&url2=draft-salowey-tls-rfc8447bis-01

Some comments on the content:

* Recommended = D requires standards action.  I think that you might want IETF 
consensus instead.

* A lot of the "changes" here have already been carried out.  Perhaps this 
document can be a lot shorter.  I still think that the generic text is useful 
to keep, but there are sections that concentrate only on stuff that has already 
been done by IANA.  Maybe those sections can go.

* This cites a specific draft version of TLS 1.3 rather than RFC 8446 and I 
can't see why.

On Sat, Feb 19, 2022, at 14:32, Christopher Wood wrote:
> Hi folks,
>
> Following up on the TLS WG meeting in IETF 112 and draft update in 
> December, this email begins an adoption call for 
> draft-salowey-tls-rfc8447bis, located here:
>
>https://datatracker.ietf.org/doc/draft-salowey-tls-rfc8447bis/
>   
> This adoption call will last for two weeks. Please reply to this email 
> by March 4 indicating whether you think this document should be adopted 
> and worked on by the WG.
>
> Thanks,
> Chris
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for draft-salowey-tls-rfc8447bis

2022-02-23 Thread Eric Rescorla

I support adoption.


On Wed, Feb 23, 2022 at 10:45 AM Salz, Rich  wrote:

> Oops.  Reply over reply-all, not common :)
>
> On 2/23/22, 12:34 PM, "Christopher Wood"  wrote:
>
> Oops — I think you accidentally replied only to me. Would you mind
> replying on the list as well?
>
> > On Feb 19, 2022, at 7:23 AM, Salz, Rich  wrote:
> >
> >>  Following up on the TLS WG meeting in IETF 112 and draft update in
> December, this email begins an adoption call for
> draft-salowey-tls-rfc8447bis, located here:
> >
> > I support adoption and will help read/review/comment on the doc.
> >
>
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for draft-salowey-tls-rfc8447bis

2022-02-23 Thread Salz, Rich

Oops.  Reply over reply-all, not common :)

On 2/23/22, 12:34 PM, "Christopher Wood"  wrote:

Oops — I think you accidentally replied only to me. Would you mind replying 
on the list as well?

> On Feb 19, 2022, at 7:23 AM, Salz, Rich  wrote:
> 
>>  Following up on the TLS WG meeting in IETF 112 and draft update in 
December, this email begins an adoption call for draft-salowey-tls-rfc8447bis, 
located here:
> 
> I support adoption and will help read/review/comment on the doc. 
> 

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

[TLS] Adoption call for draft-salowey-tls-rfc8447bis

2022-02-18 Thread Christopher Wood

Hi folks,

Following up on the TLS WG meeting in IETF 112 and draft update in December, 
this email begins an adoption call for draft-salowey-tls-rfc8447bis, located 
here:

   https://datatracker.ietf.org/doc/draft-salowey-tls-rfc8447bis/
   
This adoption call will last for two weeks. Please reply to this email by March 
4 indicating whether you think this document should be adopted and worked on by 
the WG.

Thanks,
Chris


___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RFC8447bis

2021-11-12 Thread Eric Rescorla

I am fine with this change.

On Thu, Nov 11, 2021 at 11:36 PM John Mattsson  wrote:

> Hi,
>
>
>
> My biggest concern with the "Recommended" column that I raised some year
> ago is that most people I meet in other SDOs as well as developers using
> TLS tend to believe that "Recommended" means "Recommended to use". This
> is unfortunate as there is a huge difference between "recommended to
> support" and "recommended to use". The RFC8447bis authors and TLS chairs
> also made this mistake in their slides this week. It is a very easy mistake
> to make.
>
>
>
> Can we plese rename the column to "Recommended to support". I would also
> suggest to change the text so in RFC8447 as well as the notes in the IANA
> registries to talk about "Recommended to support" instead of just
> "Recommended"
>
>
>
> Cheers,
>
> John
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RFC8447bis

2021-11-11 Thread John Mattsson

Hi,

My biggest concern with the "Recommended" column that I raised some year ago is 
that most people I meet in other SDOs as well as developers using TLS tend to 
believe that "Recommended" means "Recommended to use". This is unfortunate as 
there is a huge difference between "recommended to support" and "recommended to 
use". The RFC8447bis authors and TLS chairs also made this mistake in their 
slides this week. It is a very easy mistake to make.

Can we plese rename the column to "Recommended to support". I would also 
suggest to change the text so in RFC8447 as well as the notes in the IANA 
registries to talk about "Recommended to support" instead of just "Recommended"

Cheers,
John
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RFC8447bis

2021-08-19 Thread David Benjamin

I agree with Martin.

At the end of the day, a collision between IANA and a large-scale
experiment isn't significantly more interesting than a collision between
two large-scale experiments. They will still cause interop problems. There
isn't really any collision benefit to blocking off a range. If anything,
there is a *more* collision risk: the experimental block is much smaller
than the full codepoint space, yet, by their nature, there will be more
experimental allocations than final ones. ECH has gone through so many now.
Indeed, while ECH hasn't been constraining itself to a range, it and a few
other drafts have had a habit of only picking from the upper 256 unused
code points. Yet, by doing that, one of ECH's experimental code points
collided with one of Delegated Credentials' experimental code points.
Thankfully, I don't believe that version of DC was ever shipped large-scale.

The concern that people will special-case the range is also very real, and
would invalidate anything we learn from experiments using that range. We're
already seeing folks special-case GREASE code points. (In hindsight, I
think GREASE should not have been reflected in the table proper.) One of
TLS stacks which inspired GREASE managed to, over the course of fixing its
various bugs, even treat "Unassigned" and "Reserved for Private Use"
differently and briefly only allow unknown Private Use values!

It is true that the TLS space is a little tighter than QUIC, but I think
the same lessons apply.

On Thu, Aug 19, 2021 at 10:18 AM Martin Thomson  wrote:

> On Thu, Aug 19, 2021, at 23:14, Salz, Rich wrote:
> > I understand this concern. I am sympathetic to it. But perhaps
> > large-scale experiments on the whole Internet aren't the scope here?
> > Those kinds of things seem to ask for an early allocation. I am
> > thinking, in particular, of some GOST/TLS identifiers that weren't
> > quite right.
>
> Nothing wrong with due diligence before allocation, or even a little
> reticence.  But I'm also concerned about people putting these ranges in
> their code and doing something special with them.  Like "this is
> experimental, so we will ignore these always" or similarly silly things.
> You don't need to have a reserved space to say that a particular codepoint
> is temporary.
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] RFC8447bis

2021-08-19 Thread Martin Thomson

On Thu, Aug 19, 2021, at 23:14, Salz, Rich wrote:
> I understand this concern. I am sympathetic to it. But perhaps 
> large-scale experiments on the whole Internet aren't the scope here?  
> Those kinds of things seem to ask for an early allocation. I am 
> thinking, in particular, of some GOST/TLS identifiers that weren't 
> quite right.

Nothing wrong with due diligence before allocation, or even a little reticence. 
 But I'm also concerned about people putting these ranges in their code and 
doing something special with them.  Like "this is experimental, so we will 
ignore these always" or similarly silly things.  You don't need to have a 
reserved space to say that a particular codepoint is temporary.

___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

1 2 >

1 - 100 of 108 matches

Mail list logo