Hi Stephen,
OK, we will do it like this in the next revision of text.
Anton
On Friday 04 November 2016 17:27, Stephen Farrell wrote:
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?
_______________________________________________
lisp mailing list
lisp@ietf.org
https://www.ietf.org/mailman/listinfo/lisp
