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

[Daniel Migault <[e-mail]>]

Hi,

Thanks. It looks to me we are ready to go with this version.

Yours,
Daniel

On Sun, Apr 9, 2017 at 3:05 AM, denis bider <[e-mail]>
wrote:

> 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
>>>>
>>>>
>>>
>>
>
> _______________________________________________
> Curdle mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/curdle
>
>