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

From: Daniel Migault <[email-masked]>
Date: Fri, 7 Apr 2017 14:43:03 -0400

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 <[email-masked]>
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 <[email-masked]
> > 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/curdle
>
>

---

From: Watson Ladd <[email-masked]>
Date: Fri, 7 Apr 2017 11:50:05 -0700

> your opinion. If not we will move the draft forward.

I strongly object. PKCS 1.5 signature verification has a long and
inglorious history of exploitation. PSS does not. Ideally everyone
would have used FDH or equivalently strong signatures, with simple
verification, but that didn't happen.

---

From: Daniel Migault <[email-masked]>
Date: Fri, 7 Apr 2017 15:49:21 -0400

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 <[email-masked]>
wrote:

>> On Mon, Mar 27, 2017 at 1:24 AM, Ilari Liusvaara <
>> [email-masked]> wrote:
>>
>>> > needs also some thoughts. I will raise the question during the
>>> meeting, but

---

From: Daniel Migault <[email-masked]>
Date: Fri, 7 Apr 2017 15:54:25 -0400

Hi,

My understanding was that PSS is proved secured while pkcs1v1.5 is not.
Could you provide reference of such exploitation, that would be helpful.

Yours,
Daniel

---

From: Watson Ladd <[email-masked]>
Date: Fri, 7 Apr 2017 13:52:08 -0700

> Could you provide reference of such exploitation, that would be helpful.

All the exploitation stems Bleichenbacher's on stage demonstration
that improper validation can lead to issues at Crypto '06.

This bug broke Firefox
https://bugzilla.mozilla.org/show_bug.cgi?id=1064636. It broke GnuTLS
https://security.gentoo.org/glsa/200609-15,
It broke OpenSSL
https://www.rapid7.com/db/vulnerabilities/http-openssl-rsa-signature-forgery-vuln.

In many cases bug reporters don't note the origins of this attack,
making it hard to know if additional examples exist. CVE-2016-8021 may
also be an instance of this.

-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 8 Apr 2017 03:42:57 +0000

Watson Ladd <[email-masked]> writes:

>I strongly object. PKCS 1.5 signature verification has a long and inglorious
>history of exploitation. PSS does not. 

That's because nothing uses PSS, so there's no chance to exploit it.  By that
argument we should all be using IYOPS, which not only isn't implemented but
hasn't even been defined yet, making it even more immune to exploitation.

The problem with PKCS #1 was that people implemented it wrong in a variety of
ways, if you follow the spec (encode-then-memcmp) then it's perfectly sound.
Given that most PKCS #1 implementations should by now have been fixed (it's
been what, 20 years) while if we moved to PSS we'd be starting again from
scratch with everyone getting the chance to mess things up in different ways,
PSS is at best no better than PKCS #1, at worst a lot worse.

Peter.

---

From: denis bider <[email-masked]>
Date: Sat, 8 Apr 2017 05:20:49 -0600

I tend to agree. While it is plausible that PSS avoids providing
implementers an easy way to incorrectly verify a signature, I am not in
favor of banning working concepts because they've been implemented
incorrectly.

By that token, the most important proviso we should put in the drafts is:
"Do not, under any circumstances, implement this protocol in a memory
unsafe language, such as C or C++"...

On Fri, Apr 7, 2017 at 9:42 PM, Peter Gutmann <[email-masked]>
wrote:

> inglorious

---

From: denis bider <[email-masked]>
Date: Sun, 9 Apr 2017 01:05:18 -0600

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.

> -- 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 <[email-masked]>
wrote:

> On Fri, Apr 7, 2017 at 2:43 PM, Daniel Migault <
> [email-masked]> 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.
>>
>>> 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.
>>>
>>>> > would be in favor is only one opinion ;-) [1] lists some advantages
>>>> of PSS

---

From: Daniel Migault <[email-masked]>
Date: Sun, 9 Apr 2017 13:56:28 -0400

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 <[email-masked]>
wrote:

> On Fri, Apr 7, 2017 at 1:49 PM, Daniel Migault <

---

From: "Mark D. Baushke" <[email-masked]>
Date: Sun, 9 Apr 2017 21:37:12 -0700

This version, draft-ietf-curdle-rsa-sha2-05.txt
looks good to me.

	-- Mark