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

[Eric Rescorla <[e-mail]>]

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