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

[Daniel Migault <[e-mail]>]

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