Re: [sidr] I-D Action: draft-ietf-sidr-rfc6485bis-02.txt

Richard Hansen <rhansen@bbn.com> Wed, 15 July 2015 23:44 UTC

Return-Path: <rhansen@bbn.com>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7039C1B34A6 for <sidr@ietfa.amsl.com>; Wed, 15 Jul 2015 16:44:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XlkRoShRzQAp for <sidr@ietfa.amsl.com>; Wed, 15 Jul 2015 16:44:14 -0700 (PDT)
Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AD541B2F36 for <sidr@ietf.org>; Wed, 15 Jul 2015 16:44:14 -0700 (PDT)
Received: from socket.bbn.com ([192.1.120.102]:37645) by smtp.bbn.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.77 (FreeBSD)) (envelope-from <rhansen@bbn.com>) id 1ZFWLS-00072q-QU; Wed, 15 Jul 2015 19:44:10 -0400
X-Submitted: to socket.bbn.com (Postfix) with ESMTPSA id 9C3C23FFD7
Message-ID: <55A6F046.1090109@bbn.com>
Date: Wed, 15 Jul 2015 19:44:06 -0400
From: Richard Hansen <rhansen@bbn.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Sandra Murphy <sandy@tislabs.com>
References: <20150515192215.5707.56279.idtracker@ietfa.amsl.com> <555CE890.1090802@bbn.com> <462B3352-DAA9-476C-AA33-C517C515B7F0@tislabs.com> <555E5E4A.5080303@bbn.com> <FEE30510-E4B2-43A1-9CE9-0EC9EE1E4333@tislabs.com>
In-Reply-To: <FEE30510-E4B2-43A1-9CE9-0EC9EE1E4333@tislabs.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="SS1t4JrM2Qe0LMRPNjswTrd81iHsNjxRW"
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/AFU9wr3tjlxU95og-_4XmZSD7nM>
Cc: sidr@ietf.org
Subject: Re: [sidr] I-D Action: draft-ietf-sidr-rfc6485bis-02.txt
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jul 2015 23:44:17 -0000

On 2015-07-03 06:39, Sandra Murphy wrote:
> Speaking as regular ol' member
> On May 21, 2015, at 6:38 PM, Richard Hansen <rhansen@bbn.com> wrote:
> 
>> On 2015-05-21 17:08, Sandra Murphy wrote:
>>> On May 20, 2015, at 4:03 PM, Richard Hansen <rhansen@bbn.com> wrote:
>>>> * section 8 is incorrect -- sha256WithRSAEncryption does not
>>>>   violate the CMS RFCs (implementations just choose to use
>>>>   rsaEncryption instead, which has the same meaning in this
>>>>   context)
>>>
>> [...]
>>>
>>> Perhaps you are concerned mostly about the terms being used?  But the
>>> rfc6485bis document does not say "violate" and I believe that what it
>>> says agrees with the message above.  If you don't think so, you
>>> should say why.
>>
>> This draft's Section 8 says:
>>
>>   [...]                                    A closer reading of
>>   [RFC4055] and [RFC5754] has identified that the CMS SignerInfo field
>>   must support use of the rsaEncryption OID for full conformance with
>>   the CMS specifications, and the normative references in [RFC6485]
>>   inherited this requirement.
>>
>> The phrase "the CMS SignerInfo field must support use of the
>> rsaEncryption OID" doesn't make much sense to me -- how can an OID field
>> not support an OID?  I'm not 100% sure what is meant here, but the next
>> paragraph provides a hint:
>>
>>   [...]                                          By conforming to the
>>   CMS specifications as per [RFC4055] and [RFC5754], RPKI CMS objects
>>   are less likely to be rejected as non-conformant with the CMS
>>   standards.
>>
>> To me, this sentence and the one above are claiming that the CMS RFCs
>> say that the SignerInfo signatureAlgorithm field MUST contain
>> rsaEncryption, and that we are non-conformant (violating the spec) by
>> using sha256WithRSAEncryption.  Neither is true.
> 
> You and I disagree here.
> 
> To be clear: our disagreement is whether the description of the
> motivation for the change to RFC6485 is ambiguous or not.

I feel that Section 8 is incorrect, not just unclear.  (If I'm
interpreting it in a way that is not intended by the authors, and I
don't think I am, then this disagreement *is* just about clarity, not
correctness.)

> 
> Personally, I do not consider that an important matter.  The
> description of the motivation does not change the specification, it
> does not change implementation, and it does not confuse implementors
> about implementation.

I agree that Section 8 as worded does not impact implementations of
*this* standard.

My concern is that the current wording adds to the existing confusion
surrounding the CMS signed object spec, and that people trying to
understand the CMS standard will see this section and reach an incorrect
conclusion.

> 
> To recap:
> RFC6485 chose to mandate an algorithm id.
> That choice is compliant with the CMS RFCs.
> The CMS RFCs make a choice of a mandatory to implement algorithm ID.
> RFC6485's choice is not the CMS mandatory to implement choice.
> Unfortunately, common CMS implementations chose to support only the
>   CMS mandatory to implement algorithm ID.
> So common CMS implementations can not be compliant with RFC6485.
> By aligning our choice of mandatory algorithm ID with the mandatory
>   algorithm in the CMS RFCs, we make it possible for common CMS
>   implementations to be compliant with RFC6485.
> By aligning our choice of mandatory algorithm ID with the mandatory
>   algorithm in the CMS RFCs, we eliminate the problem that a compliant
>   RPKI signed object would be rejected by the common CMS
>   implementations.

Yes, I agree with this recap.

> 
> wrt:
> 
>>
>>   [...]                                          By conforming to the
>>   CMS specifications as per [RFC4055] and [RFC5754], RPKI CMS objects
>>   are less likely to be rejected as non-conformant with the CMS
>>   standards.
> 
> Perhaps you are reading too much into the use of "conforming to"?

There is a chance I am interpreting that sentence in a way not intended
by the authors.  If I am, then something should be done to reduce the
difficulty of interpreting the sentence correctly.  If I am not, then
something should be done to correct the sentence.  Either way, something
should be done.

> Perhaps saying "aligning with" would make it more clear to you?

That's an improvement, but still not sufficient.  I sent a suggested
rewrite of Section 8 to the authors on 2015-05-20 with no response;
here's a more minimal rewrite of just that sentence:

   [...]                                          By requiring RPKI CMS
   signed objects to use an OID that is widely supported by existing
   libraries, implementations are less likely to reject valid RPKI CMS
   signed objects due to incomplete algorithm support.

> 
> I do not know what current CMS implementations would do if they were
> presented with a RFC6485 compliant RPKI signed object.

RPSTIR currently accepts either OID.

Before this OID issue was raised, RPSTIR only accepted CMS signed
objects that used sha256WithRSAEncryption.  CMS signed objects that used
rsaEncryption were rejected due to non-conformance with RFC6485.

> They may indeed report the signed object is "non-conformant with the
> CMS standards".

I suspect the other implementations would have rejected CMS signed
objects that use sha256WithRSAEncryption with "unsupported algorithm",
not "non-conformant with the CMS standard" (but I can't say for sure).

> So I can not say that "rejected as non-conformant with
> the CMS standards" is incorrect.  Error message aside, it is clear
> that any RFC6485 compliant RPKI signed object (if we could find one)

Before this OID issue was raised, RPSTIR's test cases generated valid
CMS signed objects that used sha256WithRSAEncryption.  Those test cases
were changed once everyone agreed to switch to rsaEncryption.

We will add a sha256WithRSAEncryption test case once the rfc6485bis dust
settles (to require RPs to either accept or reject depending on what the
final RFC says).  In the meantime, it would be fairly trivial for us to
manually generate such an object.

> would be rejected by existing implementations.

except RPSTIR

> There might be ways to improve that "rejected as non-conformant"
> phrase of the text, but I don't think it is necessarily wrong.

I do, because I doubt that's an accurate reflection of history.

> 
>> From a CMS RFC conformance perspective it's perfectly OK
>> for RFC6485 to require RPKI CMS object producers to use
>> sha256WithRSAEncryption, but third party crypto libs didn't make it easy
>> for implementations to conform. 
> 
> My reading of the previous discussions is that it is worse than
> "didn't make it easy" -  the crypto libs made it *impossible* for
> implementations to be compliant with RFC6485 - they did not implement
> support for the algorithm RF6485 mandated.

RPSTIR did support RFC6485 as written until this OID issue came up, at
which point we also started accepting rsaEncryption.

(In order to support sha256WithRSAEncryption we had to reinvent much of
the wheel via manual ASN.1 parsing and calls to primitive crypto
functions.  I suspect the other RP implementations call easy-to-use
high-level OpenSSL functions that don't understand sha256WithRSAEncryption.)

> 
>>
>>> It is found in 3370, which 5754 (one of the references) updates and
>>> normatively references.
>>
>> I don't think that is sufficient in this case.  There are multiple RFCs
>> that this document directly and indirectly references that define an
>> algorithm identifier named rsaEncryption.  I believe they all have the
>> same OID value, but some of them give slightly different semantics.
> 
> Really?  I think that would be a very bad thing!  But not our problem, I think.

The multiple meanings for rsaEncryption is not our problem, but not
specifying which meaning we want *is* our problem.

> 
>> Thus, I think it's important to make it clear which definition of
>> rsaEncryption is intended.
>>
>> For example, RFC3370 (for CMS) says that rsaEncryption is either a key
>> type identifier or a signature algorithm identifier, while RFC3279 (for
>> PKIX) says that it's only a key type identifier and thus not suitable
>> for identifying signature algorithms in a PKIX context (you must use
>> xxxWithRSAEncryption instead to specify the digest).
> 
> I think your "and thus not suitable" is a bit of a stretch.

rsaEncryption can't be used to identify a signature algorithm in a PKIX
certificate because it doesn't specify the hash algorithm (PKIX doesn't
have a separate signature hash algorithm OID like CMS does).

It can be (and is) used to identify the PKIX key type, however.

> And it would appear that the existing implementations we are talking
> about did not make this same interpretation - we are in this mess
> because they use rsaEncryption as a signature algorithm identifier.

The story with CMS is different -- and considerably more murky -- than
PKIX because CMS has a separate hash OID for signatures.

I asked the smime mailing list [1] if they could point me to text that
clarifies the relationship between the signatureAlgorithm and
digestAlgorithm fields, and what it means to choose a signatureAlgorithm
OID that also specifies a digest algorithm.  My conclusion is:

  * the CMS RFCs are woefully unclear about this

  * practically speaking, you should never choose a signatureAlgorithm
    OID that conflicts with the digestAlgorithm OID (you're asking for
    trouble if you pick md5WithRSAEncryption and sha-1 for the two OIDs)

  * assuming the digest algorithm is x, then practically speaking it
    shouldn't matter whether the signatureAlgorithm is
    xWithRSAEncryption or just rsaEncryption; implementations will
    probably do the same thing either way (assuming they understand
    both OIDs, which isn't true for sha256WithRSAEncryption)

[1] http://thread.gmane.org/gmane.ietf.smime/7053

-Richard


> 
> Again, speaking as a regular ol' member.
> 
> --Sandy