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

[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

[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

[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

[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

[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

[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

[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

[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

[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] WGLC for draft-ietf-tls-rfc8446bis and draft-ietf-tls-rfc8447bis

[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

[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

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

[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

[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

[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

[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

[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

[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

[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

[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

[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 

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

[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

[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 

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

[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 

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

[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

[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 

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

[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_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

[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_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

[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
> 

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

[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

[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

[Martin Thomson]

https://author-tools.ietf.org/diff?doc_1=rfc8446_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

[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