Hi Ben, We recommend using “Rejected” with a verifier note to capture the necessary information. That way a reader knows that the “error” has been considered and a conclusion reached versus leaving in “Reported”.
Thank you. RFC Editor/mf On Oct 19, 2018, at 7:59 AM, Benjamin Kaduk <ka...@mit.edu> wrote: > 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
