Re: [TLS] [Editorial Errata Reported] RFC8996 (7739)

[Rebecca VanRheenen]

Greetings,

FYI - this report has been deleted as junk (identical text is listed in 
Original Text, Corrected Text, and Notes, and this text does not even appear in 
this RFC).

Thank you.

RFC Editor/rv


> On Dec 21, 2023, at 7:02 PM, RFC Errata System  
> wrote:
> 
> The following errata report has been submitted for RFC8996,
> "Deprecating TLS 1.0 and TLS 1.1".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid7739
> 
> --
> Type: Editorial
> Reported by: mohamed abdurahman hassan 
> 
> 96
> 
> Original Text
> -
> 
>   application.  The authorization server should take special care when
>   enabling this grant type and only allow it when other flows are not
>   viable.
> 
>   This grant type is suitable for clients capable of obtaining the
>   resource owner's credentials (username and password, typically using
>   an interactive form).  It is also used to migrate existing clients
>   using direct authentication schemes such as HTTP Basic or Digest
>   authentication to OAuth by converting the stored credentials to an
>   access token.
> 
> 
> Corrected Text
> --
> 
>   application.  The authorization server should take special care when
>   enabling this grant type and only allow it when other flows are not
>   viable.
> 
>   This grant type is suitable for clients capable of obtaining the
>   resource owner's credentials (username and password, typically using
>   an interactive form).  It is also used to migrate existing clients
>   using direct authentication schemes such as HTTP Basic or Digest
>   authentication to OAuth by converting the stored credentials to an
>   access token.
> 
> 
> Notes
> -
> application.  The authorization server should take special care when
>   enabling this grant type and only allow it when other flows are not
>   viable.
> 
>   This grant type is suitable for clients capable of obtaining the
>   resource owner's credentials (username and password, typically using
>   an interactive form).  It is also used to migrate existing clients
>   using direct authentication schemes such as HTTP Basic or Digest
>   authentication to OAuth by converting the stored credentials to an
>   access token.
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". (If it is spam, it 
> will be removed shortly by the RFC Production Center.) Please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> will log in to change the status and edit the report, if necessary.
> 
> --
> RFC8996 (draft-ietf-tls-oldversions-deprecate-12)
> --
> Title   : Deprecating TLS 1.0 and TLS 1.1
> Publication Date: March 2021
> Author(s)   : K. Moriarty, S. Farrell
> Category: BEST CURRENT PRACTICE
> Source  : Transport Layer Security
> Area: Security
> Stream  : IETF
> Verifying Party : IESG

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

[TLS] [Editorial Errata Reported] RFC8996 (7739)

[RFC Errata System]

The following errata report has been submitted for RFC8996,
"Deprecating TLS 1.0 and TLS 1.1".

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid7739

--
Type: Editorial
Reported by: mohamed abdurahman hassan 

96

Original Text
-

   application.  The authorization server should take special care when
   enabling this grant type and only allow it when other flows are not
   viable.

   This grant type is suitable for clients capable of obtaining the
   resource owner's credentials (username and password, typically using
   an interactive form).  It is also used to migrate existing clients
   using direct authentication schemes such as HTTP Basic or Digest
   authentication to OAuth by converting the stored credentials to an
   access token.


Corrected Text
--

   application.  The authorization server should take special care when
   enabling this grant type and only allow it when other flows are not
   viable.

   This grant type is suitable for clients capable of obtaining the
   resource owner's credentials (username and password, typically using
   an interactive form).  It is also used to migrate existing clients
   using direct authentication schemes such as HTTP Basic or Digest
   authentication to OAuth by converting the stored credentials to an
   access token.


Notes
-
application.  The authorization server should take special care when
   enabling this grant type and only allow it when other flows are not
   viable.

   This grant type is suitable for clients capable of obtaining the
   resource owner's credentials (username and password, typically using
   an interactive form).  It is also used to migrate existing clients
   using direct authentication schemes such as HTTP Basic or Digest
   authentication to OAuth by converting the stored credentials to an
   access token.

Instructions:
-
This erratum is currently posted as "Reported". (If it is spam, it 
will be removed shortly by the RFC Production Center.) Please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
will log in to change the status and edit the report, if necessary.

--
RFC8996 (draft-ietf-tls-oldversions-deprecate-12)
--
Title   : Deprecating TLS 1.0 and TLS 1.1
Publication Date: March 2021
Author(s)   : K. Moriarty, S. Farrell
Category: BEST CURRENT PRACTICE
Source  : Transport Layer Security
Area: Security
Stream  : IETF
Verifying Party : IESG

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

Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'

[Salz, Rich]

You can tell the reader whatever you want. The fact remains that if the only 
way to add QR to the currently deployed TLS-1.2-based “stuff” is modifying 
TLS-1.2, then that’s what will be done in that particular case.

Of course.  We’re not the protocol police and nobody from the IETF will come 
and arrest anyone who uses Kyber-based key exchange in TLS 1.2 But with this 
document, they will not be able to register such an algorithm for 1.2

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

Re: [TLS] [EXT] Re: Adoption call for 'TLS 1.2 Feature Freeze'

[Blumenthal, Uri - 0553 - MITLL]

-1 to Tim. 

 

You can tell the reader whatever you want. The fact remains that if the only 
way to add QR to the currently deployed TLS-1.2-based “stuff” is modifying 
TLS-1.2, then that’s what will be done in that particular case.  

 

I hope that the majority of the installed base would be able to migrate to PQ 
and TLS-1.3+ in a normal way. But in all likelihood, “special cases” will 
exist. 

--

V/R,

Uri

 

There are two ways to design a system. One is to make it so simple there are 
obviously no deficiencies.

The other is to make it so complex there are no obvious deficiencies.


 -  C. A. R. Hoare

 

 

From: TLS  on behalf of Ira McDonald 

Date: Thursday, December 21, 2023 at 13:39
To: Tim Hollebeek , Ira McDonald 

Cc: Hannes Tschofenig , Bas 
Westerbaan , "Salz, Rich" 
, "TLS@ietf.org" 
Subject: [EXT] Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

 

+1 to Tim - tell the reader explicitly that they will only ever get PQC w/ TLS 
1. 3 or higher. Cheers, - Ira On Thu, Dec 21, 2023, 12: 34 PM Tim Hollebeek 
 wrote: I personally think 
this point 

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender 
This message came from outside the Laboratory. 
ZjQcmQRYFpfptBannerEnd

+1 to Tim - tell the reader explicitly that they will only ever get PQC w/ TLS 
1.3 or higher.

 

Cheers,

- Ira

On Thu, Dec 21, 2023, 12:34 PM Tim Hollebeek 
 wrote:

I personally think this point is important enough to be made explicitly instead 
of implicitly.

 

If we want to communicate loudly and clearly that post-quantum cryptography is 
NEVER coming to TLS 1.2, we need to explicitly say that.

 

Otherwise people will say “I know you said TLS 1.2 was frozen, but post-quantum 
cryptography isn’t a feature, it’s a critical security vulnerability that needs 
to be patched regardless of any freezes.”

 

The answer will be and needs to be: “No, we told you clearly and explicitly 
that post-quantum cryptography would require moving to TLS 1.3 or later”.

 

-Tim

 

From: TLS  On Behalf Of Hannes Tschofenig
Sent: Monday, December 11, 2023 12:06 PM
To: Salz, Rich ; Hannes Tschofenig 
; Bas Westerbaan 
; Deirdre Connolly 

Cc: TLS@ietf.org
Subject: Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

 

Hi Rich,

 

that is implied by a "feature freeze". No reason to highlight PQC (even though 
it is a hype topic right now).

 

Ciao

Hannes

 

Am 11.12.2023 um 17:18 schrieb Salz, Rich:

1.   I consider Section 3 "Implications for post-quantum cryptography" 
misplaced. I suggest to delete the section

2.   The motivation for the draft is unrelated to developments with PQC.

The point is to explain to people that we are going to need PQ crypto, and it 
*will not be a 1.2 enhancement*

 

 
___
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



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

[Ira McDonald]

+1 to Tim - tell the reader explicitly that they will only ever get PQC w/
TLS 1.3 or higher.

Cheers,
- Ira

On Thu, Dec 21, 2023, 12:34 PM Tim Hollebeek  wrote:

> I personally think this point is important enough to be made explicitly
> instead of implicitly.
>
>
>
> If we want to communicate loudly and clearly that post-quantum
> cryptography is NEVER coming to TLS 1.2, we need to explicitly say that.
>
>
>
> Otherwise people will say “I know you said TLS 1.2 was frozen, but
> post-quantum cryptography isn’t a feature, it’s a critical security
> vulnerability that needs to be patched regardless of any freezes.”
>
>
>
> The answer will be and needs to be: “No, we told you clearly and
> explicitly that post-quantum cryptography would require moving to TLS 1.3
> or later”.
>
>
>
> -Tim
>
>
>
> *From:* TLS  *On Behalf Of *Hannes Tschofenig
> *Sent:* Monday, December 11, 2023 12:06 PM
> *To:* Salz, Rich ; Hannes Tschofenig
> ; Bas Westerbaan  40cloudflare@dmarc.ietf.org>; Deirdre Connolly <
> durumcrustu...@gmail.com>
> *Cc:* TLS@ietf.org
> *Subject:* Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'
>
>
>
> Hi Rich,
>
>
>
> that is implied by a "feature freeze". No reason to highlight PQC (even
> though it is a hype topic right now).
>
>
>
> Ciao
>
> Hannes
>
>
>
> Am 11.12.2023 um 17:18 schrieb Salz, Rich:
>
> 1.   I consider Section 3 "Implications for post-quantum
> cryptography" misplaced. I suggest to delete the section
>
> 2.   The motivation for the draft is unrelated to developments with
> PQC.
>
> The point is to explain to people that we are going to need PQ crypto, and
> it **will not be a 1.2 enhancement**
>
>
>
>
>
> ___
>
> 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 'TLS 1.2 Feature Freeze'

[Tim Hollebeek]

I personally think this point is important enough to be made explicitly instead 
of implicitly.

 

If we want to communicate loudly and clearly that post-quantum cryptography is 
NEVER coming to TLS 1.2, we need to explicitly say that.

 

Otherwise people will say “I know you said TLS 1.2 was frozen, but post-quantum 
cryptography isn’t a feature, it’s a critical security vulnerability that needs 
to be patched regardless of any freezes.”

 

The answer will be and needs to be: “No, we told you clearly and explicitly 
that post-quantum cryptography would require moving to TLS 1.3 or later”.

 

-Tim

 

From: TLS  On Behalf Of Hannes Tschofenig
Sent: Monday, December 11, 2023 12:06 PM
To: Salz, Rich ; Hannes Tschofenig 
; Bas Westerbaan 
; Deirdre Connolly 

Cc: TLS@ietf.org
Subject: Re: [TLS] Adoption call for 'TLS 1.2 Feature Freeze'

 

Hi Rich,

 

that is implied by a "feature freeze". No reason to highlight PQC (even though 
it is a hype topic right now).

 

Ciao

Hannes

 

Am 11.12.2023 um 17:18 schrieb Salz, Rich:

1.   I consider Section 3 "Implications for post-quantum cryptography" 
misplaced. I suggest to delete the section

2.   The motivation for the draft is unrelated to developments with PQC.

The point is to explain to people that we are going to need PQ crypto, and it 
*will not be a 1.2 enhancement*

 





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



smime.p7s
Description: S/MIME cryptographic signature
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls