Subject: Re: [lamps] [IAB] Conflict between RFC8954 and ISO 14533-4

From: "Mirja Kühlewind (IETF)" <[email-masked]>
Date: Wed, 6 Jan 2021 14:20:46 +0100

Hi Russ,

Thanks for noting this. Do we know if this concern was already raised (informally) with ISO? 

If we don’t have people who are participating also in ISO and can easily start the discussion directly, sending a LS seems to be appropriate that reflects the concept of the lamps group. In this case you/the chairs should get in touch with your AD and maybe some of the key participants for this discussion and draft some text for discussion in the group. The IAB doesn’t necessarily need to be involved to send out the LS but we are happy to help or serve as the official sender if that’s most appropriate in the ISO context.

Mirja

> Am 23.12.2020 um 17:21 schrieb Russ Housley <[email-masked]>:
> 
> 
> Marian Ďurkovič <[email-masked]> brought it to the attention of the LAMPS WG.  That was a message out of the blue from my perspective.
> 
> Russ
> 
> 
> 
>> On Dec 23, 2020, at 11:09 AM, Stephen Farrell <[email-masked]> wrote:
>> 
>> Signed PGP part
>> 
>> Hi Russ,
>> 
>>> On 23/12/2020 15:41, Russ Housley wrote:
>>> Dear  IAB:
>>> The IETF does not have a liaison relationship with the ISO TC that
>>> produced ISO 14533-4:2019.  It would be a good think to tell that
>>> group that we disagree with the approach that was taken.  What does
>>> the IAB suggest?
>> 
>> I've not followed this discussion, nor am I at all familiar
>> with that ISO spec, so I'd have to get up to speed before I'd
>> have an informed opinion.
>> 
>> Does anyone know someone involved with that ISO group/spec?
>> If so, I'd say trying to see if it can be sorted out at that
>> level would be good (if it's not happened already).
>> 
>> If there's no good contact available then yeah I guess the
>> IAB might try find a way to send a message to ISO. First up
>> though might be for lamps to craft the message to be sent
>> (including enough background that IAB and ISO folks will get
>> the point). I'd be happy to bring such a message to the IAB
>> and ask that we figure out how to get it sent to the right
>> place/people.
>> 
>> Cheers,
>> S.
>> 
>> PS: The above is clearly just me speaking, and isn't the
>> consensus of the IAB:-)
>> 
>>> Russ
>>>> On Dec 23, 2020, at 2:40 AM, Tomas Gustavsson
>>>> <[email-masked]> wrote:
>>>> Hi,
>>>> I'd like to give my view on this.
>>>> I support not changing anything in RFC8954.
>>>> I recently started using the term "tweaking standards" for when you
>>>> take an existing field in a standard and use it for other purposes
>>>> than the one stated in the standard, just because it is technically
>>>> possible and not explicitly forbidden in the standard. This has
>>>> been done many times before, and many times it leads to
>>>> interoperability issues, severe spending of time, money and
>>>> resources, and in severe cases even downtime. Tweaking standards is
>>>> a short term short-cut, ignoring long term costs.
>>>> ISO 14533 clearly tweaked RFC6960 section 4.4.1.
>>>> Many internet scale OCSP responders today do not include Nonce in
>>>> the response. Regardless if the client sends it. This is for
>>>> caching reasons, and is for both GET and POST requests.
>>>> Using nonce as MessageImprint is non-interoperable with RFC6960 and
>>>> with the real world.
>>>> I'd like to say it again: ISO 14533 is non-interoperable with how
>>>> OCSP is deployed on the internet today.
>>>> It is a disaster waiting to happen. The reason it hasn't happened
>>>> yet is likely due to ISO 14533 not being widely used. Let's fix it
>>>> before it falls apart. The solution is not to force RFC6960
>>>> compliant OCSP responders into submission to ISO 14533, but to fix
>>>> ISO 14533. ISO 14533 should recognize that the suggested solution
>>>> is non-compliant, causing interoperability issues, and go back and
>>>> create an extension. Yes, it's a little more work, and may result
>>>> in a new RFC, or a replacement of RFC6960 (but the extension can be
>>>> private to ISO 14533 to start with), but it's the right thing to do
>>>> imho.
>>>> There is already an extension, a bit similar to this, specified in
>>>> the German Common PKI. https://de.wikipedia.org/wiki/Common_PKI It's called CertHash and can be copied. The specification isn't available any longer, but I have an off-line copy that I share
>>>> here: https://app.box.com/s/lk1g4a3h75icirnu6xqrqhee8h5kmv54
>>>> It's a SingleResponse extension, section 3.1.2:
>>>> id-commonpki-at-certHash OBJECT IDENTIFIER ::== {1 3 36 8 3 13}
>>>> CertHash ::= SEQUENCE { hashAlgorithm AlgorithmIdentifier, // The
>>>> identifier of the algorithm // that has been used the for hash //value below.
>>>> certificateHash OCTET STRING // A hash over the DER-encoding of
>>>> the // entire PKC or AC (i.e. NOT a hash // over tbsCertificate). }
>>>> There are OCSP responders out there supporting the old CertHash
>>>> extension.
>>>> Not saying to use it "as is", it has another purpose, but very
>>>> very similar. Just put a new OID and rename it to
>>>> MessageImprint...
>>>> Best regards, Tomas
>>>>> On 2020-12-21 17:36, Marian Ďurkovič wrote:
>>>>> *On Sat, 19 Dec 2020 13:12:17 -0800, Mohit Sahni wrote*
>>>>>> From OCSP point of view the MessageImprint is not a random
>>>>>> value but
>>>>> it is a deterministic value generated for a given input by a
>>>>> collision resistant one way hash function.
>>>>> This input, however, consists of multiple parts: some of them
>>>>> being random, some of them being unknown even to document signer
>>>>> (private key). In any case, an attacker is not able to guess this
>>>>> value so it serves against reply attack very well.
>>>>>> One more reason I see for not changing the Nonce extension
>>>>>> length is
>>>>> that the length of MessageImprint is not fixed but varies based
>>>>> on the underlying hash algorithm.  Since RFC3161 does not provide
>>>>> a fixed list of Hash functions, let's say we change the size to
>>>>> Nonce extension to 64 bytes, what if in the future there is a new
>>>>> hash algorithm or some proprietary hash function that requires
>>>>> size to be 128 bytes or 256 bytes or may be 100 GigaBytes, are we
>>>>> going to increase the size of the Nonce extension again?  How can
>>>>> we set an upper limit on Nonce which also serves the regular
>>>>> Nonce use case of just avoiding the replay attacks ?
>>>>> I proposed 2 values: 96 bytes if we want to accomodate 512-bit
>>>>> hashes, or 160 bytes, if we want to accomodate (future) 1024-bit
>>>>> hashes. Any hashing algorithm is designed to yield a relatively
>>>>> small result, so we're certainly not talking about GigaBytes
>>>>> here...
>>>>>> In my opinion, ISO 14533 took advantage of the security
>>>>>> vulnerability
>>>>> that existed in RFC6960 and tried using Nonce extension in a way
>>>>> it was not intended to be used as i.e. using an ASN.1 SEQUENCE
>>>>> where the standard requires use of OCTET STRING.
>>>>> OCTET STRING means arbitrary sequence of bytes, which OCSP
>>>>> responder shouldn't interpret in any way - just echo them back in
>>>>> its response. It's completely irrelevant, what's encoded inside -
>>>>> after all, a random number could also start with 0x30 which
>>>>> corresponds to SEQUENCE.
>>>>>> We should come up with a new extension for associating the
>>>>>> OCSP
>>>>> response with the context where OCSP is being used for long term validation. That is the right thing to do.
>>>>> And what will be the advantage of having yet another extension
>>>>> doing the same thing? Both use cases require nothing else from
>>>>> OCSP responder than to echo back exactly the same bytes it
>>>>> received in request. Do you propose to have 2 extensions, one of
>>>>> them being able to only echo 32 bytes and another being able to
>>>>> echo 96? or 160? or unlimited bytes? Isn't it much more
>>>>> straightforward to have only one "echoing" extension being able
>>>>> to echo as many bytes as needed for both use cases?
>>>>> On the other hand, the disadvantages are significant - I
>>>>> mentioned some of them in my previous email. Also please keep in
>>>>> mind, that RFC 8954 (if applied by OCSP responder or by some
>>>>> firewall doing deep packet inspection) will immediately break
>>>>> digital signing - since it says:
>>>>> A server *MUST* reject any OCSP request that has a nonce in the
>>>>> Nonce extension with a length of either 0 octets or more than 32
>>>>> octets with the malformedRequest OCSPResponseStatus
>>>>> Last but not least, introducing another extension is more complex
>>>>> than you assume - it will require modification of (at least)
>>>>> RFC6960, RFC5019, ISO 14533-4. When will that solution be
>>>>> available and what to do until then?
>>>>> With kind regards, MD
>>>>> _______________________________________________ Spasm mailing
>>>>> list [email-masked] https://www.ietf.org/mailman/listinfo/spasm
>>>> _______________________________________________ Spasm mailing list [email-masked] https://www.ietf.org/mailman/listinfo/spasm
>>> _______________________________________________ Spasm mailing list [email-masked] https://www.ietf.org/mailman/listinfo/spasm
>> <OpenPGP_0x5AB2FAF17B172BEA.asc>
>> 
>> 
>

---

From: Russ Housley <[email-masked]>
Date: Wed, 6 Jan 2021 11:21:18 -0500

Mirja:

We do not know whether the ISO TC has been notified.  I am guessing that a participant in that group rasided the issue with the LAMPS WG, butwe do not know that for sure.

Russ

> On Jan 6, 2021, at 8:20 AM, Mirja Kühlewind (IETF) <[email-masked]> wrote:
> 
> Hi Russ,
> 
>> Marian Ďurkovič <[email-masked] <mailto:[email-masked]>> brought it to the attention of the LAMPS WG.  That was a message out of the blue from my perspective.
>> 
>> Russ
>> 
>> 
>> 
>>> On Dec 23, 2020, at 11:09 AM, Stephen Farrell <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Signed PGP part
>>> 
>>> Hi Russ,
>>> 
>>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>> Hi,
>>>>> the German Common PKI. https://de.wikipedia.org/wiki/Common_PKI <https://de.wikipedia.org/wiki/Common_PKI> It's called CertHash and can be copied. The specification isn't available any longer, but I have an off-line copy that I share
>>>>> here: https://app.box.com/s/lk1g4a3h75icirnu6xqrqhee8h5kmv54 <https://app.box.com/s/lk1g4a3h75icirnu6xqrqhee8h5kmv54>
>>>>>> list [email-masked] <mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/spasm <https://www.ietf.org/mailman/listinfo/spasm>
>>>>> _______________________________________________ Spasm mailing list [email-masked] <mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/spasm <https://www.ietf.org/mailman/listinfo/spasm>
>>>> _______________________________________________ Spasm mailing list [email-masked] <mailto:[email-masked]> https://www.ietf.org/mailman/listinfo/spasm <https://www.ietf.org/mailman/listinfo/spasm>