Re: [Curdle] comments on draft-ietf-curdle-rsa-sha2-03.txt

[denis bider <[e-mail]>]

I have:

- Applied these nits to the rsa-sha2 document, and submitted a new version.

- Applied a few nits that appeared to be relevant also to the ext-info
document, and submitted a new version.

With regard to this:

> -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-4'

I have not made changes because a normative reference is appropriate here
for SHA-2, and there does not appear to be an RFC that could serve as an
alternative reference. Other past RFCs that address the use of SHA-2 also
use the FIPS standard as a normative reference.

denis


On Fri, Apr 7, 2017 at 1:49 PM, Daniel Migault <[e-mail]>
wrote:

> In addition, I have also been requested by the IESG to add as an
> informative reference the link of the IANA page. In our case the link is
> the following one:
> https://www.iana.org/assignments/ssh-parameters/ssh-parameters.xhtml#ssh-
> parameters-19
>
> Yours,
> Daniel
>
> On Fri, Apr 7, 2017 at 2:43 PM, Daniel Migault <
> [e-mail]> wrote:
>
>> Hi,
>>
>> In the chicago meeting [1], the consensus seems that even though pss
>> would be defined, there is no plane to implement nor to use it. I am
>> confirming this consensus on the mailing list. If you desagree with that,
>> please raise your opinion. If not we will move the draft forward.
>>
>> The nits tool on the current version provides teh following output:
>>
>> [1] https://www.ietf.org/proceedings/98/minutes/minutes-98-curdle-00.txt
>>
>>
>>   Checking nits according to http://www.ietf.org/id-info/checklist :
>>   ----------------------------------------------------------------------------
>>
>>   -- The draft header indicates that this document updates RFC4252, but the
>>      abstract doesn't seem to mention this, which it should.
>>
>>   -- The draft header indicates that this document updates RFC4253, but the
>>      abstract doesn't seem to mention this, which it should.
>>
>>   -- The document seems to lack a disclaimer for pre-RFC5378 work, but may
>>      have content which was first submitted before 10 November 2008.  If you
>>      have contacted all the original authors and they are all willing to grant
>>      the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
>>      this comment.  If not, you may need to add the pre-RFC5378 disclaimer.
>>      (See the Legal Provisions document at
>>      http://trustee.ietf.org/license-info for more information.)
>>
>>
>>   Checking references for intended status: Proposed Standard
>>   ----------------------------------------------------------------------------
>>
>>      (See RFCs 3967 and 4897 for information about using normative references
>>      to lower-maturity documents in RFCs)
>>
>>   == Missing Reference: 'RFC3629' is mentioned on line 100, but not defined
>>
>>   == Unused Reference: 'RFC4250' is defined on line 298, but no explicit
>>      reference was found in the text
>>
>>   -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-180-4'
>>
>>   ** Obsolete normative reference: RFC 3447
>>
>> yours,
>>
>> Daniel
>>
>>
>> On Mon, Mar 27, 2017 at 4:51 PM, denis bider <[e-mail]>
>> wrote:
>>
>>> That is a welcome assurance. If PSS is added, it sounds like something
>>> to mention in Security Considerations as a further argument against small
>>> keys.
>>>
>>> On Mon, Mar 27, 2017 at 1:24 AM, Ilari Liusvaara <
>>> [e-mail]> wrote:
>>>
>>>> On Sun, Mar 26, 2017 at 10:50:02PM -0500, Daniel Migault wrote:
>>>> > Whether pss variant have to be added is up to the WG to decide. That I
>>>> > would be in favor is only one opinion ;-) [1] lists some advantages
>>>> of PSS
>>>> > vs PKCS1v1.5. Note that enabling a given key may be used by two
>>>> variants
>>>> > needs also some thoughts. I will raise the question during the
>>>> meeting, but
>>>> > discussion will be made on the mailing list.
>>>>
>>>> This thing came up in context of TLS 1.3.
>>>>
>>>> The probability PKCS#1v1.5 and PSS signature overlaps depends on key
>>>> size and salt size. Where overlap is defined as encoded message that
>>>> is valid in both PKCS#1v1.5 and PSS. These depend on hashing algorithm
>>>> and number of bits in n, but not precise value of n.
>>>>
>>>> TLS restricts salt length to be the same as hash length. Which makes
>>>> overlaps highly unlikely with key sizes >=2048 bits and hash sizes
>>>> <=512 bits. The problem being to control ~1000 bits using 512 bits.
>>>>
>>>> As key size decreases or salt size increases, the overlap probability
>>>> increases, and eventually overlaps become almost certain, and further
>>>> one gets multiple overlaps.
>>>>
>>>> >
>>>> > [1]
>>>> > https://www.emc.com/emc-plus/rsa-labs/historical/raising-sta
>>>> ndard-rsa-signatures-rsa-pss.htm
>>>>
>>>>
>>>> -Ilari
>>>>
>>>
>>>
>>> _______________________________________________
>>> Curdle mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/curdle
>>>
>>>
>>
>