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

[denis bider <[e-mail]>]

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". :)

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