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

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 <denisbider.ietf@gmail.com>
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 <ilariliusvaara@welho.com
> > 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
> Curdle@ietf.org
> https://www.ietf.org/mailman/listinfo/curdle
>
>