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

Usually, I would say "we're getting rid of finite field" :)

-Ekr

On Tue, Jun 20, 2017 at 7:14 AM, denis bider <denisbider.ietf@gmail.com>
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 <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
>>>>
>>>>
>>>
>>
>