It does feel like an artifact of the times, yes. So I am not sure if there is a better option than "Rejected" (or, I guess, leave in "Reported" indefinitely).
-Ben On Fri, Oct 19, 2018 at 05:34:48PM +1100, Martin Thomson wrote: > An artifact of the times more than an error methinks? The document > does also say: "Currently, DSA [DSS] may only be used with SHA-1." in > the context of talking about use of different hash algorithms for DSA. > > Good thing that we obsoleted that RFC and removed DSA, now we don't > have to worry about it any more... ;) Seriously though, I don't know > the process for dealing with valid criticisms of features that have > been obsoleted. Hold For Document Update seems very wrong, so we can > rule that out at least. > > On Fri, Oct 19, 2018 at 5:25 PM RFC Errata System > <rfc-edi...@rfc-editor.org> wrote: > > > > The following errata report has been submitted for RFC5246, > > "The Transport Layer Security (TLS) Protocol Version 1.2". > > > > -------------------------------------- > > You may review the report below and at: > > http://www.rfc-editor.org/errata/eid5535 > > > > -------------------------------------- > > Type: Technical > > Reported by: Dave Thompson <dave_thompso...@comcast.net> > > > > Section: 4.7 > > > > Original Text > > ------------- > > In DSA, the 20 bytes of the SHA-1 hash are run directly through the > > Digital Signing Algorithm with no additional hashing. ... > > > > Corrected Text > > -------------- > > In DSA, the bytes of the selected hash are run directly through the > > Digital Signing Algorithm with no additional hashing. ... > > > > Notes > > ----- > > In 2246 and 4346 this statement (then using the less-accurate spellings DSS > > and SHA) was correct because only SHA1 was used for DSA (and ECDSA, in > > 4492, versus SHA1+MD5 for RSA), but 5246 changed this to allow specifying > > one of several hashes, with selection constrained by the > > signature_algorithms extension (if present) or CertificateRequest field > > from the peer. > > > > FIPS 186 actually defines the hashing step as part of signature generation > > and verification, so it might be even better to make this something like > > "For DSA, signature generation applies the selected hash [to the contents] > > and then computes two values, r and s." similar to the way the preceding > > paragraph of 5246 "In RSA signing" differs from the 2246 and 4346 versions > > by no longer treating the hashing as separate, but that is a bigger change > > to an obsoleted document, and arguably problematic because the normative > > reference is FIPS 186-2; as indicated in Appendix B on page 80, 186-3 which > > officially allowed DSA to use FIPS 180-3 hashes (not only SHA-1) was > > released in draft before 5246 but not finalized until after (2006-03 to > > 2009-06 versus 2008-08). > > > > Instructions: > > ------------- > > This erratum is currently posted as "Reported". If necessary, please > > use "Reply All" to discuss whether it should be verified or > > rejected. When a decision is reached, the verifying party > > can log in to change the status and edit the report, if necessary. > > > > -------------------------------------- > > RFC5246 (draft-ietf-tls-rfc4346-bis-10) > > -------------------------------------- > > Title : The Transport Layer Security (TLS) Protocol Version > > 1.2 > > Publication Date : August 2008 > > Author(s) : T. Dierks, 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 _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
