Re: [TLS] [Errata Held for Document Update] RFC8446 (5682)
On Thu, Jan 18, 2024 at 5:25 PM Rob Sayre wrote: > On Thu, Jan 18, 2024 at 1:26 PM David Benjamin > wrote: > >> >> I think sometimes we spend a little more energy than is actually useful >> in figuring out these implied lower bounds. :-) In practice, the only >> decision we actually care about is whether 0 is allowed, and even then it's >> often irrelevant (like here). >> > > FWIW, I find these really confusing in TLS notation. > > I usually end up checking what NSS or OpenSSL does to get the answer. So, > I don't think there's an operational problem, but it could be better. > I just mentally replace all non-zero minimums to 1 when reading. I can't think of any structure where a non-zero minimum value was not just some attempt to figure out the minimum possible byte count of a single object. David ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Errata Held for Document Update] RFC8446 (5682)
On Thu, Jan 18, 2024 at 1:26 PM David Benjamin wrote: > > I think sometimes we spend a little more energy than is actually useful in > figuring out these implied lower bounds. :-) In practice, the only decision > we actually care about is whether 0 is allowed, and even then it's often > irrelevant (like here). > FWIW, I find these really confusing in TLS notation. I usually end up checking what NSS or OpenSSL does to get the answer. So, I don't think there's an operational problem, but it could be better. thanks, Rob ___ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
Re: [TLS] [Errata Held for Document Update] RFC8446 (5682)
The extension list cannot actually be empty because we also say:
> The "signature_algorithms" extension
> MUST be specified, and other extensions may optionally be included
> if defined for this message.
That said, enforcing this by rejecting the empty list doesn't do much
because the receiver will need to look for specifically the sigalgs
extension anyway. So I'm on board with making this say either 0 or 4.
Honestly, 2 is fine too... if you check for 2 instead of 4, you'll still
have the exact same behavior. In fact I think the sigalgs rule implies the
true minimum is 8. But let's not put 8 because it will confuse everyone.
I think sometimes we spend a little more energy than is actually useful in
figuring out these implied lower bounds. :-) In practice, the only decision
we actually care about is whether 0 is allowed, and even then it's often
irrelevant (like here).
On Thu, Jan 18, 2024 at 3:47 PM Benjamin Kaduk wrote:
> I think if the errata report is moved back into the "reported" state by
> the RFC Editor staff, the AD should be able to edit the report to reflect
> the intent as opposed to having the diff appear.
>
> -Ben
>
> On Tue, Jan 16, 2024 at 07:07:19PM -0800, RFC Errata System wrote:
> > The following errata report has been held for document update
> > for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3".
> >
> > --
> > You may review the report below and at:
> >
> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid5682__;!!GjvTz_vk!T2x_YvOjybcaxb8hARC3CW6xdOhGeq2BD-cjxoPyutXUwQp_f3O3PfnITevFE1EaDkGlyknuPtDLnj4boiBQ1w$
> >
> > --
> > Status: Held for Document Update
> > Type: Technical
> >
> > Reported by: Richard Barnes
> > Date Reported: 2019-04-01
> > Held by: Paul Wouters (IESG)
> >
> > Section: 4.3.2, B.3.2
> >
> > Original Text
> > -
> > --- rfc8446.txt 2018-08-10 20:12:08.0 -0400
> > +++ rfc8446.erratum.txt 2019-04-01 15:44:54.0 -0400
> > @@ -3341,7 +3341,7 @@
> >
> >struct {
> >opaque certificate_request_context<0..2^8-1>;
> > - Extension extensions<2..2^16-1>;
> > + Extension extensions<0..2^16-1>;
> >} CertificateRequest;
> >
> >
> > @@ -7309,7 +7309,7 @@
> >
> >struct {
> >opaque certificate_request_context<0..2^8-1>;
> > - Extension extensions<2..2^16-1>;
> > + Extension extensions<0..2^16-1>;
> >} CertificateRequest;
> >
> >
> >
> >
> > Corrected Text
> > --
> > --- rfc8446.txt 2018-08-10 20:12:08.0 -0400
> > +++ rfc8446.erratum.txt 2019-04-01 15:44:54.0 -0400
> > @@ -3341,7 +3341,7 @@
> >
> >struct {
> >opaque certificate_request_context<0..2^8-1>;
> > - Extension extensions<2..2^16-1>;
> > + Extension extensions<0..2^16-1>;
> >} CertificateRequest;
> >
> >
> > @@ -7309,7 +7309,7 @@
> >
> >struct {
> >opaque certificate_request_context<0..2^8-1>;
> > - Extension extensions<2..2^16-1>;
> > + Extension extensions<0..2^16-1>;
> >} CertificateRequest;
> >
> >
> >
> >
> > Notes
> > -
> > The length of this vector can never 2. It is either 0, if the vector is
> empty, or >=4, if the vector has at least one extension. Nothing elsewhere
> in the spec requires a non-zero number of extensions here, so this syntax
> should allow a zero-length vector.
> >
> > Paul Wouters (AD): Richard meant the diff to be the fix, not the
> original/corrected text. The diff is not in the RFC itself. There are two
> places in the mentioned sections that need this one liner fix.
> >
> > --
> > RFC8446 (draft-ietf-tls-tls13-28)
> > --
> > Title : The Transport Layer Security (TLS) Protocol
> Version 1.3
> > Publication Date: August 2018
> > Author(s) : E. Rescorla
> > Category: PROPOSED STANDARD
> > Source : Transport Layer Security
> > Area: Security
> > Stream : IETF
> > Verifying Party : IESG
> >
> > ___
> > TLS mailing list
> > TLS@ietf.org
> >
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!T2x_YvOjybcaxb8hARC3CW6xdOhGeq2BD-cjxoPyutXUwQp_f3O3PfnITevFE1EaDkGlyknuPtDLnj70kj7-uw$
>
> ___
> 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] [Errata Held for Document Update] RFC8446 (5682)
I think if the errata report is moved back into the "reported" state by the RFC
Editor staff, the AD should be able to edit the report to reflect the intent as
opposed to having the diff appear.
-Ben
On Tue, Jan 16, 2024 at 07:07:19PM -0800, RFC Errata System wrote:
> The following errata report has been held for document update
> for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3".
>
> --
> You may review the report below and at:
> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid5682__;!!GjvTz_vk!T2x_YvOjybcaxb8hARC3CW6xdOhGeq2BD-cjxoPyutXUwQp_f3O3PfnITevFE1EaDkGlyknuPtDLnj4boiBQ1w$
>
>
> --
> Status: Held for Document Update
> Type: Technical
>
> Reported by: Richard Barnes
> Date Reported: 2019-04-01
> Held by: Paul Wouters (IESG)
>
> Section: 4.3.2, B.3.2
>
> Original Text
> -
> --- rfc8446.txt 2018-08-10 20:12:08.0 -0400
> +++ rfc8446.erratum.txt 2019-04-01 15:44:54.0 -0400
> @@ -3341,7 +3341,7 @@
>
>struct {
>opaque certificate_request_context<0..2^8-1>;
> - Extension extensions<2..2^16-1>;
> + Extension extensions<0..2^16-1>;
>} CertificateRequest;
>
>
> @@ -7309,7 +7309,7 @@
>
>struct {
>opaque certificate_request_context<0..2^8-1>;
> - Extension extensions<2..2^16-1>;
> + Extension extensions<0..2^16-1>;
>} CertificateRequest;
>
>
>
>
> Corrected Text
> --
> --- rfc8446.txt 2018-08-10 20:12:08.0 -0400
> +++ rfc8446.erratum.txt 2019-04-01 15:44:54.0 -0400
> @@ -3341,7 +3341,7 @@
>
>struct {
>opaque certificate_request_context<0..2^8-1>;
> - Extension extensions<2..2^16-1>;
> + Extension extensions<0..2^16-1>;
>} CertificateRequest;
>
>
> @@ -7309,7 +7309,7 @@
>
>struct {
>opaque certificate_request_context<0..2^8-1>;
> - Extension extensions<2..2^16-1>;
> + Extension extensions<0..2^16-1>;
>} CertificateRequest;
>
>
>
>
> Notes
> -
> The length of this vector can never 2. It is either 0, if the vector is
> empty, or >=4, if the vector has at least one extension. Nothing elsewhere
> in the spec requires a non-zero number of extensions here, so this syntax
> should allow a zero-length vector.
>
> Paul Wouters (AD): Richard meant the diff to be the fix, not the
> original/corrected text. The diff is not in the RFC itself. There are two
> places in the mentioned sections that need this one liner fix.
>
> --
> RFC8446 (draft-ietf-tls-tls13-28)
> --
> Title : The Transport Layer Security (TLS) Protocol Version 1.3
> Publication Date: August 2018
> Author(s) : E. Rescorla
> Category: PROPOSED STANDARD
> Source : Transport Layer Security
> Area: Security
> Stream : IETF
> Verifying Party : IESG
>
> ___
> TLS mailing list
> TLS@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/tls__;!!GjvTz_vk!T2x_YvOjybcaxb8hARC3CW6xdOhGeq2BD-cjxoPyutXUwQp_f3O3PfnITevFE1EaDkGlyknuPtDLnj70kj7-uw$
>
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
[TLS] [Errata Held for Document Update] RFC8446 (5682)
The following errata report has been held for document update
for RFC8446, "The Transport Layer Security (TLS) Protocol Version 1.3".
--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid5682
--
Status: Held for Document Update
Type: Technical
Reported by: Richard Barnes
Date Reported: 2019-04-01
Held by: Paul Wouters (IESG)
Section: 4.3.2, B.3.2
Original Text
-
--- rfc8446.txt 2018-08-10 20:12:08.0 -0400
+++ rfc8446.erratum.txt 2019-04-01 15:44:54.0 -0400
@@ -3341,7 +3341,7 @@
struct {
opaque certificate_request_context<0..2^8-1>;
- Extension extensions<2..2^16-1>;
+ Extension extensions<0..2^16-1>;
} CertificateRequest;
@@ -7309,7 +7309,7 @@
struct {
opaque certificate_request_context<0..2^8-1>;
- Extension extensions<2..2^16-1>;
+ Extension extensions<0..2^16-1>;
} CertificateRequest;
Corrected Text
--
--- rfc8446.txt 2018-08-10 20:12:08.0 -0400
+++ rfc8446.erratum.txt 2019-04-01 15:44:54.0 -0400
@@ -3341,7 +3341,7 @@
struct {
opaque certificate_request_context<0..2^8-1>;
- Extension extensions<2..2^16-1>;
+ Extension extensions<0..2^16-1>;
} CertificateRequest;
@@ -7309,7 +7309,7 @@
struct {
opaque certificate_request_context<0..2^8-1>;
- Extension extensions<2..2^16-1>;
+ Extension extensions<0..2^16-1>;
} CertificateRequest;
Notes
-
The length of this vector can never 2. It is either 0, if the vector is empty,
or >=4, if the vector has at least one extension. Nothing elsewhere in the
spec requires a non-zero number of extensions here, so this syntax should allow
a zero-length vector.
Paul Wouters (AD): Richard meant the diff to be the fix, not the
original/corrected text. The diff is not in the RFC itself. There are two
places in the mentioned sections that need this one liner fix.
--
RFC8446 (draft-ietf-tls-tls13-28)
--
Title : The Transport Layer Security (TLS) Protocol Version 1.3
Publication Date: August 2018
Author(s) : E. Rescorla
Category: PROPOSED STANDARD
Source : Transport Layer Security
Area: Security
Stream : IETF
Verifying Party : IESG
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
