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

[denis bider <[e-mail]>]

Done and submitted. :-)


On Tue, Aug 22, 2017 at 2:04 PM, Eric Rescorla <[e-mail]> wrote:

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