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

[Anton Smirnov <[e-mail]>]

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