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

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 <ekr@rtfm.com> wrote:

>
>
> On Mon, Jun 19, 2017 at 8:28 AM, denis bider <denisbider.ietf@gmail.com>
> 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 <ekr@rtfm.com> 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
>>> Curdle@ietf.org
>>> https://www.ietf.org/mailman/listinfo/curdle
>>>
>>>
>>
>