Re: [lisp] Stephen Farrell's Discuss on draft-ietf-lisp-ddt-08: (with DISCUSS and COMMENT)

[Stephen Farrell <[e-mail]>]

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?
>>>>
>>>>
>