Hiya, On 04/11/16 16:12, Anton Smirnov wrote: > Hi Stephen, > > will it be OK if we mark in the document security algorithm 1 as > reserved without even elaborating that it is/was RSA-SHA1 and the only > security algorithm specified in the RFC will be 2 == RSA-SHA256 ? > > This will ensure that whoever is using algorithm 1 will not run into > compatibility issues but RSA-SHA1 will be clearly non-RFC-compliant.
How about defining alg=1 as rsa-sha1 and marking that as deprecated with alg=2 as rsa-sha256 as the MUST implement? (I don't care myself if you have an IANA registry for those yet or not, doing it in text is fine.) S > > Anton > > On Tuesday 01 November 2016 22:09, Stephen Farrell wrote: >> Hiya, >> >> On 01/11/16 18:51, Anton Smirnov wrote: >>> Hello Stephen, >>> >>> thanks for your comment. >>> >>> Existing DDT implementations are already using RSA-SHA1, so we cannot >>> simply replace it with RSA-SHA256. But we should be able to add the >>> latter as another signing algorithm. >> Really? The sha-1 weaknesses for use in signatures were >> found and documented in an RFC in 2005. [1] We published >> an RFC attempting to tidy up remaining loose ends related >> to sha1 for signatures in 2011. [2] Asking for rsa-sha1 now >> is really very far behind the state of the art. >> >> But are you talking implementations or deployments here? >> If mostly the former then I think you ought remove rsa-sha1 >> entirely and replace with rsa-sha256. That is a trivial >> code change and I can see no justification for not making >> that change. >> >> If you are talking about existing deployments please >> provide the argument as to why those are such that we >> should publish an RFC that calls for use of an obsolete >> signature algorithm 11 years after the initial crypto >> weaknesses were documented in the IETF. If there are good >> arguments for that a) I'll be surprised, and b) my plan >> would be to ask for advice from the security area - I >> don't think we've hit this case before where an experimental >> RFC wants to use such a thoroughly obsolete signature >> algorithm, one that would never be ok in a standards >> track RFC and one where it's really easy to do the right >> thing instead. >> >> Cheers, >> S. >> >> [1] https://tools.ietf.org/html/rfc4270 >> [2] https://tools.ietf.org/html/rfc6194 >> >> >>> Authors will take in your comments in the next revision of the >>> draft. >>> >>> Anton >>> >>> On Thursday 27 October 2016 14:44, Stephen Farrell wrote: >>>> Stephen Farrell has entered the following ballot position for >>>> draft-ietf-lisp-ddt-08: Discuss >>>> >>>> When responding, please keep the subject line intact and reply to all >>>> email addresses included in the To and CC lines. (Feel free to cut this >>>> introductory paragraph, however.) >>>> >>>> >>>> Please refer to >>>> https://www.ietf.org/iesg/statement/discuss-criteria.html >>>> for more information about IESG DISCUSS and COMMENT positions. >>>> >>>> >>>> The document, along with other ballot positions, can be found here: >>>> https://datatracker.ietf.org/doc/draft-ietf-lisp-ddt/ >>>> >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> DISCUSS: >>>> ---------------------------------------------------------------------- >>>> >>>> >>>> 6.4.1: RSA-SHA1 is not the right choice today, shouldn't >>>> this be RSA-SHA256? >>>> >>>> >>>> ---------------------------------------------------------------------- >>>> COMMENT: >>>> ---------------------------------------------------------------------- >>>> >>>> >>>> - 6.4.1: Can you clarify what bits are signed? I'm not >>>> quite sure from the description given - you can have >>>> more than one signature but you say the the "entire >>>> record" is covered. >>>> >>>> - Section 8: Where's signature validation in the >>>> pseudo-code? >>>> >>>> >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ lisp mailing list [email protected] https://www.ietf.org/mailman/listinfo/lisp
