Re: [Curdle] AD Review: draft-ietf-curdle-rsa-sha2-07.txt

[Eric Rescorla <[e-mail]>]

On Mon, Aug 21, 2017 at 10:36 AM, denis bider <[e-mail]>
wrote:

> Hey!
>
> Apologies, I am currently in the middle of moving to another country again
> (for the third, and hopefully final time!). I can still make changes as
> necessary to this draft, though.
>
> With respect to the below issue, I'm still not sure how to best phrase it
> differently. Maybe we could just remove the paragraph about why we're not
> doing DSA? At the time I wrote it, I thought it was a good idea to justify
> the removal, but maybe we don't even really need to explain anything there.
> Especially if the justification is simply "we don't wanna". :)
>

This seems like a fine resolution.

-Ekr


>
> denis
>
>
>
> On Sat, Aug 19, 2017 at 11:27 AM, Eric Rescorla <[e-mail]> wrote:
>
>> Ping?
>>
>> -Ekr
>>
>>
>> On Tue, Jun 20, 2017 at 3:55 PM, Eric Rescorla <[e-mail]> wrote:
>>
>>> Usually, I would say "we're getting rid of finite field" :)
>>>
>>> -Ekr
>>>
>>>
>>> On Tue, Jun 20, 2017 at 7:14 AM, denis bider <[e-mail]>
>>> wrote:
>>>
>>>> I agree, but there has to be a reason it's on its way out. :) This is
>>>> the one reason I know how to phrase. If there's something else I can do
>>>> instead, let me know.
>>>>
>>>> On Mon, Jun 19, 2017 at 11:11 AM, Eric Rescorla <[e-mail]> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Mon, Jun 19, 2017 at 8:28 AM, denis bider <
>>>>> [e-mail]> wrote:
>>>>>
>>>>>> > Either you are using PKCS#1 v1.5 or you are using PSS.
>>>>>> > In the former case, there is no mask function and salt.
>>>>>>
>>>>>> Yikes, thanks. :) This was left over from an early version that
>>>>>> specified PSS. This was before PKCS#1 v1.5 was requested. (The change took
>>>>>> place before any implementation was released, so all deployed
>>>>>> implementations use PKCS#1 v1.5.)
>>>>>>
>>>>>>
>>>>>> > You say in the intro that RSA was defined as 1024 bit
>>>>>> > keys. Are these keys of arbitrary length? Is there an
>>>>>> > upper or lower limit?
>>>>>>
>>>>>> I believe this may refer to the following sentence:
>>>>>>
>>>>>> "In [RFC4253], SSH originally defined the public key algorithms
>>>>>> "ssh-rsa" for server and client authentication using RSA with SHA-1, and
>>>>>> "ssh-dss" using 1024-bit DSA and SHA-1."
>>>>>>
>>>>>> Here, 1024-bit refers to DSA. RFC 4253 imposes no limits on RSA key
>>>>>> sizes.
>>>>>>
>>>>>>
>>>>>> > > Implementations SHOULD apply PKCS#1 v1.5 padding to the expected
>>>>>> > > hash, THEN compare the encoded bytes with the output of [...]
>>>>>>
>>>>>> > Why "SHOULD?
>>>>>>
>>>>>> Fair point. Changed as follows:
>>>>>>
>>>>>> "Verifiers MUST instead apply PKCS#1 v1.5 padding to the expected
>>>>>> hash, then compare the encoded bytes with the output of the RSA operation."
>>>>>>
>>>>>>
>>>>>> > This is an odd argument given that ECDSA is often also
>>>>>> > implemented with random k.
>>>>>>
>>>>>> I agree, but that is the main argument that was given by multiple
>>>>>> people as the main reason to remove DSA from the original draft (which
>>>>>> covered DSA in addition).
>>>>>>
>>>>>
>>>>> How about just "DSA is on its way out" :)
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> denis
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Jun 17, 2017 at 1:30 PM, Eric Rescorla <[e-mail]> wrote:
>>>>>>
>>>>>>> TECHNICAL
>>>>>>> S 3.
>>>>>>>   Signing and verifying using these algorithms is performed
>>>>>>> according to
>>>>>>>   the RSASSA-PKCS1-v1_5 scheme in [RFC8017] using SHA-2 [SHS] as
>>>>>>> hash;
>>>>>>>   MGF1 as mask function; and salt length equal to hash size.
>>>>>>>
>>>>>>> This seems incorrect. Either you are using PKCS#1 v1.5 or you are
>>>>>>> using PSS. In the former case, there is no mask function and salt.
>>>>>>> Appendix 5.3 suggests that you are not using PSS. In any case,
>>>>>>> you need to fix the inconsistency.
>>>>>>>
>>>>>>> You say in the intro that RSA was defined as 1024 bit keys. Are
>>>>>>> these keys of arbitrary length? Is there an upper or lower limit?
>>>>>>>
>>>>>>>
>>>>>>> S 5.3.
>>>>>>>   Implementations SHOULD apply PKCS#1 v1.5 padding to the expected
>>>>>>> hash,
>>>>>>>   THEN compare the encoded bytes with the output of the RSA
>>>>>>> operation.
>>>>>>>
>>>>>>> Why "SHOULD?
>>>>>>>
>>>>>>>
>>>>>>> S 6.
>>>>>>>   A draft version of this memo also defined an algorithm name for
>>>>>>> use of
>>>>>>>   2048-bit and 3072-bit DSA keys with a 256-bit subgroup and SHA-2
>>>>>>> 256
>>>>>>>   hashing. It is possible to implement DSA securely by generating "k"
>>>>>>>   deterministically as per [RFC6979]. However, a plurality of
>>>>>>> reviewers
>>>>>>>   were concerned that implementers would continue to use libraries
>>>>>>> that
>>>>>>>   generate "k" randomly. This is vulnerable to biased "k" generation,
>>>>>>>   and extremely vulnerable to "k" reuse. This document therefore
>>>>>>>   disrecommends DSA, in favor of RSA and elliptic curve cryptography.
>>>>>>>
>>>>>>> This is an odd argument given that ECDSA is often also implemented
>>>>>>> with random k. Not that I am in favor of adding DSA here.
>>>>>>>
>>>>>>> -Ekr
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Curdle mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/curdle
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>