Re: [saag] [CFRG] OCB does not have an OID specified, that is a general problem

[Phillip Hallam-Baker <[e-mail]>]

My view of the way IETF/IRTF should consider cryptographic algorithms might
be described as a 'fat waist model'

First of all we have general discussion of the canon of prefered
cryptographic algorithms for use in IETF protocols in SAAG and CFRG. There
is a lot of overlap between the groups of course but CFRG is the primary
gatekeeper that algorithms must pass to be added to the canon and SAAG is
the primary grim reaper taking them away.

Once we decide an algorithm is no longer fit for purpose, we want to remove
it from the recommendations for every current standard. Merely adding an
algorithm to the canon does not mean that every current standard must allow
it. All that it means is that it is available for those standards which
might use it.

This canon represents the base of the pyramid.


At the very top of the pyramid we have protocol standards. Here we
typically look to limit the choices both for interoperability and for
security. The algorithm choices are taken from the canon but they are in
most cases going to be a subset of the canon. As a general rule we would
normally want to limit ourselves to one primary and one backup for each
cryptographic function. This is because the security of the system is
generally the security of the weakest algorithm, Adding stronger algorithms
to a protocol suite does not make the protocol any stronger, only removing
the obsolete weaker algorithms does that.

Since removing algorithms is typically a costly and painful process, most
new protocol proposals should adopt the strongest algorithm choices that
are appropriate at the time it is introduced. The choices I would have made
in 2014 have no bearing on the choices I would make in 2021. One of the
simplifications I have made in the Mesh is to require 448 bit ECDH, 256 bit
AES and 512 bit SHA-2 or SHA-3. Those are entirely defensible choices in
2021, I don't think I could have gotten away with those in 2014 and people
would have been looking at me funny if I proposed them in 2005.


And then in the middle of the pyramid we have standards which aren't
actually protocols in their own right but are components used in protocols.
In the security area these are our cryptographic format specs such as
PKCS#7/CMS, XML Signature, XML Encryption, JOSE, DARE, etc. etc.

I was one of the people who spent many hours debating the inclusion or
exclusion of various algorithms from most of those formats and it is only
now that I have realized that the entire discussion was a waste of time
because cryptographic format specs do not raise interoperability issues,
protocols do.

Since these are not protocols in their own right, the interoperability
issues are very different to those of a protocol. They might apply to
someone who is going to write a standalone library for a format. But even
that seems like the wrong approach to me. My reference code for the Mesh
contains a JOSE and a DARE library. Neither of which actually contains any
algorithm code. The algorithms are implemented in .NET Core which in turn
uses OpenSSL or Windows crypto or in the case of algorithms .NET does not
support, in my own code.

[My implementation has 2197 lines of executable code that provide packaging
of cryptographic algorithms so they can be applied in a consistent manner
and only 1439 lines that implement algorithms]

Does the fact that JOSE supports RSA require the Mesh to support RSA? - No.
Does the fact that JOSE requires HMAC-SHA2 256 bit require the Mesh to use
it? - No.
Does the fact that JOSE does not define an identifier for AES-OCB prevent
the Mesh using it? - No.
Should the Mesh define its own set of algorithm identifiers to compete with
those used by JOSE? - Oh please no.

Of course, the Mesh is really built on DARE which is based on JOSE but has
quite a bit added and even more taken away. The Mesh approach to crypto is
that there should be exactly one way to do a given thing. So where JOSE has
to allow six different key wrapping approaches, the Mesh has one, where
JOSE supports three cipher suite strengths, the Mesh has one, etc. etc.

It is this cryptographic format that I consider the 'fat waist'. Basically
any cryptographic algorithm that is a part of the canon can be
specified here and in some cases we are going to have algorithms that are
not specified. We can write text that says that an S/MIME application MUST
NOT sign using MD5 or encrypt using DES but both have to be in any real
world application and that can never change because Alice has to be able to
read the message Bob sent in 1995 in 2021 and possibly in 2050.

The one area in which cryptographic formats do raise interop issues is when
they are used as a file format. And only some formats are used as file
formats.


rfc7518 (ietf.org) <https://datatracker.ietf.org/doc/html/rfc7518>

   Registering the algorithms and identifiers here, rather than in the
   JWS, JWE, and JWK specifications, is intended to allow them to remain
   unchanged in the face of changes in the set of Required, Recommended,
   Optional, and Deprecated algorithms over time.  This also allows
   changes to the JWS, JWE, and JWK specifications without changing this
   document.


On Tue, Jun 8, 2021 at 3:53 AM Neil Madden <[e-mail]> wrote:

> On 8 Jun 2021, at 01:58, Phillip Hallam-Baker <[e-mail]>
> wrote:
>
>
> 
> On Mon, Jun 7, 2021 at 10:02 AM Neil Madden <[e-mail]>
> wrote:
>
>> Unless there is a compelling reason to do so, I’d prefer that registering
>> algorithm identifiers for JOSE be a manual (and rare) step. JOSE provides
>> no way for consumers to advertise which Encryption Methods they support
>> (“enc” - which is what OCB would be), so adding new options here can only
>> harm interoperability.
>>
>> (This is in contrast to key agreement algorithms - “alg” - as these can
>> be advertised in the JSON Web Key metadata).
>>
>
> I don't agree. JOSE has no algorithm negotiation mechanism because it is a
> format, not a protocol. After we went through the whole
> recommended/required algorithm thing on JOSE, it suddenly occurred to me
> that this was precisely none of JOSE's business. It is for the protocols
> and services built using XML Signature, JOSE, CMS etc. to decide what
> algorithms to require and/or recommend.
>
>
> Doesn’t this contradict your desire to have a single IANA algorithm
> registry? If individual application protocols are to state which algorithms
> to use then they need a registry each to state this.
>

Not at all. My point is that the purpose of a registry is limited to
assigning a signifier to one or more signified. It is not for IANA to
specify that RSA is required or not, that is a WG decision.


> JWK is a protocol built on top of JOSE, so it makes sense for that
> protocol to specify recommended algorithms.
>
>
> This is rather backwards: JWK is part of JOSE and indeed JOSE depends on
> JWK (see for example the “jwk” and “epk” headers).
>

Well yes and no, JWK also pops up in other contexts. OAUTH2 would have been
a better example.

JOSE doesn't even specify the serialization format, it is a component of a
protocol, not a protocol.


> But the recommendations made in the JOSE spec have absolutely no bearing
> on the Mesh which uses parts of JOSE because being written six years later,
> the state of the art has moved on. The Mesh does not support RSA at all and
> the elliptic curve algs are X448 and Ed448. The curve 25519 versions are
> not supported for profile signing, etc. etc.
>
> I would expect the same to apply in the COSE world. Merely defining a code
> point for JOSE or CMS does not make a statement about the algorithm
> recommendation status.
>
>
> Well it does actually - see the “JOSE Implementation Requirements” field:
> https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms
>
> And the reason for this is because the algorithms are implemented by JOSE
> libraries. Indeed, this is the whole point of JOSE, that applications don’t
> need to implement their own algorithms but can just use a preexisting
> library.
>

And merely assigning a code point does not change the recommendations for
implementing algorithms in a 'JOSE Library'.

Since I wrote my own JOSE library in less than a week, I have a hard time
believing that it is the JOSE part that is critical. And since I used the
.NET crypto as base, the recommendations in the JOSE specs were not
remotely relevant.


All it does is specify the one canonical identifier every application will
> use. It is not at all important what that identifier is (provided it is not
> an absurd length) it is critical that everyone use the same identifier
> though.
>
>
> If different applications are going to specify different algorithms then
> this somewhat argues against your point: they _don’t_ need to use the same
> algorithm identifiers as other applications in that case.
>

There is no reason why the algorithm suite for the Mesh should be the same
as that for SIP and plenty of reasons why it needs to be different. The
Mesh uses threshold cryptography which only works with DH and ECDH
algorithms for a start. Even if RSA was still viable from a security point
of view, I couldn't use it. OCB was patent encumbered when JOSE was
written, it is not today. The advantages of OCB over GSM are significant
but not something that is worth losing backwards compatibility over.



> But I think we’re rather getting off the track here because as I mentioned
> in my first email, OCB would be standardised as an Encryption Method (“enc”
> header value). This introduces more complications. JOSE supports encrypting
> a message to multiple recipients, each of which can use a different key
> management algorithm (“alg”). But the content of the message has to be
> encrypted using a common symmetric Encryption Method that all the
> recipients understand. This is why introducing new Encryption Methods is
> problematic because as the number of options goes up, the chances of
> finding an algorithm that all recipients agree on reduces.
>

Since I have 0 users and 1 implementation, my scope for deciding algorithm
choices is radically different from that of others.

You keep conflating the concerns that apply to existing JOSE applications
to the concerns that properly apply to JOSE.



> (The alternative is that we register as many new “enc” values as we like
> but they are all effectively ignored because everyone uses “A128CBC-HS256”
> as the only thing guaranteed to work everywhere. This is not the case
> currently because there are only a few “enc” options and so most libraries
> implement all of them).
>

OATH2 allows use of 128 bit AES and 256 bit SHA-2. The Mesh requires 256
bit AES and 512 bit SHA-2 or SHA-3. And that is exactly what you would
expect. OAUTH2 is an attempt to define an authorization scheme that is
conflated into an authentication mechanism that manages to squeeze itself
into the legacy deployed base of Web Browsers. The Mesh is a Threshold PKI
whose primary function is management of private keys. My problems have
absolutely nothing in common with those of OAUTH2 which is why their
algorithm choices have no bearing on mine any more than TLS is beholden to
CMS or CMS to OpenPGP.


> In 2021, I think OCB has very few advantages over JOSE’s existing GCM
> Encryption Methods, so I think it is much more trouble than it’s worth to
> specify it for use there. If we’re going to expand the “enc” registry I’d
> rather it was for an algorithm with significant advantages over the
> existing alternatives, such as misuse resistance or better performance on
> low-end hardware.
>

This was discussed at some length on the cryptography list and the
overwhelming feeling there was to go for OCB. That was not a decision taken
lightly as it required me to write the implementation. GCM is a stream
cipher and the uses in the Mesh clearly require a block cipher which means
CBC and OCB are the only acceptable choices.