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

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 7 Jun 2021 08:51:30 -0400

Raising this in SAAG because this raises a policy issue and CFRG because
that is where the policy should be enforced. It is also relevant to LAMPS
but trying to avoid cross posting as everyone on the LAMPS list is likely
on SAAG.

rfc7253 specifies OCB mode. But there is no OID specified to use OCB with
CMS, nor are there identifiers for use with JOSE.

This is problematic to say the least. If an algorithm is worth publishing
as an RFC, there should be definitive identifiers for general purpose
packaging formats specified in that RFC.

I would like to propose that in future assignment of relevant OIDs and JOSE
identifiers be considered a requirement for similar work. If a spec for a
symmetric mode isn't sufficiently specified to enable interoperable
implementation in CMS and JOSE, it is not sufficiently specified to be an
RFC.

This would not cover TLS, IPSEC etc. since they have rather different
considerations. Algorithms are curated and selected as suites for TLS for a
start.

I am not a fan of having multiple registries for specifying identifiers for
algorithms. In fact if I had my way, there would be a single IANA text
registry because while we could write a spec for a cryptographic algorithm
and call it SMTP, that would be silly.

It seems to me that one registry for the ASN.1 identifiers and one for text
based identifiers is sufficient for all reasonable purposes. To the extent
that XML signature and encryption are still a thing, well why don't we just
specify a generic URN scheme for IANA registries and have done.

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 7 Jun 2021 13:44:49 +0000

*   rfc7253 specifies OCB mode. But there is no OID specified to use OCB with CMS, nor are there identifiers for use with JOSE.

For this particular case, a request to the IANA expert will get an OID.  (He’s a co-chair of LAMPS :)

  *   I would like to propose that in future assignment of relevant OIDs and JOSE identifiers be considered a requirement for similar work. If a spec for a symmetric mode isn't sufficiently specified to enable interoperable implementation in CMS and JOSE, it is not sufficiently specified to be an RFC.

That’s a reasonable thing to ask for, and something that could be caught by SECDIR or AD review.

---

From: Roman Danyliw <[email-masked]>
Date: Mon, 7 Jun 2021 13:53:10 +0000

Hi!

From: saag <[email-masked]> On Behalf Of Salz, Rich
Sent: Monday, June 7, 2021 9:45 AM
To: Phillip Hallam-Baker <[email-masked]>; IETF SAAG <[email-masked]>; IRTF CFRG <[email-masked]>
Subject: Re: [saag] [CFRG] OCB does not have an OID specified, that is a general problem

[Roman] Agreed in the general case for the IETF stream.  For RFC7253, this review would have been during IESG conflict review because that document was IRTF stream (which doesn’t have an SECDIR review, AD review or even an IESG ballot).

Roman

---

From: Neil Madden <[email-masked]>
Date: Mon, 7 Jun 2021 15:02:14 +0100

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).

— Neil

> On 7 Jun 2021, at 13:51, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> Raising this in SAAG because this raises a policy issue and CFRG because that is where the policy should be enforced. It is also relevant to LAMPS but trying to avoid cross posting as everyone on the LAMPS list is likely on SAAG.
> 
> 
> rfc7253 specifies OCB mode. But there is no OID specified to use OCB with CMS, nor are there identifiers for use with JOSE.
> 
> This is problematic to say the least. If an algorithm is worth publishing as an RFC, there should be definitive identifiers for general purpose packaging formats specified in that RFC.
> 
> I would like to propose that in future assignment of relevant OIDs and JOSE identifiers be considered a requirement for similar work. If a spec for a symmetric mode isn't sufficiently specified to enable interoperable implementation in CMS and JOSE, it is not sufficiently specified to be an RFC.
> 
> This would not cover TLS, IPSEC etc. since they have rather different considerations. Algorithms are curated and selected as suites for TLS for a start. 
> 
> I am not a fan of having multiple registries for specifying identifiers for algorithms. In fact if I had my way, there would be a single IANA text registry because while we could write a spec for a cryptographic algorithm and call it SMTP, that would be silly. 
> 
> It seems to me that one registry for the ASN.1 identifiers and one for text based identifiers is sufficient for all reasonable purposes. To the extent that XML signature and encryption are still a thing, well why don't we just specify a generic URN scheme for IANA registries and have done.
> _______________________________________________
> CFRG mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/cfrg

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 7 Jun 2021 16:15:15 +0200

> 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 Encryptio…

... and for COSE, I don’t think there is such a constraint, so algorithm registration should be handled together with any OID checking.

Grüße, Carsten

---

From: Richard Outerbridge <[email-masked]>
Date: Mon, 7 Jun 2021 10:34:19 -0400

Hmm …
__outer

> On 2021-06-07 (158), at 09:53:10, Roman Danyliw <[email-masked]> wrote:
> 
> Hi!
>  
> From: saag <[email-masked] <mailto:[email-masked]>> On Behalf Of Salz, Rich
> To: Phillip Hallam-Baker <[email-masked] <mailto:[email-masked]>>; IETF SAAG <[email-masked] <mailto:[email-masked]>>; IRTF CFRG <[email-masked] <mailto:[email-masked]>>

[ … ]

> [email-masked] <mailto:[email-masked]>
> https://www.irtf.org/mailman/listinfo/cfrg <https://www.irtf.org/mailman/listinfo/cfrg>

---

From: Russ Housley <[email-masked]>
Date: Mon, 7 Jun 2021 11:00:51 -0400

It would be very easy to write a document like RFC 5084 for AES-OCB.  If you want to do that, I'm sure that LAMPS could adopt and review it.

Russ

> On Jun 7, 2021, at 8:51 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> saag mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/saag

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 7 Jun 2021 20:58:12 -0400

On Mon, Jun 7, 2021 at 10:02 AM Neil Madden <[email-masked]> 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.

JWK is a protocol built on top of JOSE, so it makes sense for that protocol
to specify recommended algorithms. 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. 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.

---

From: Neil Madden <[email-masked]>
Date: Tue, 8 Jun 2021 08:53:26 +0100

On 8 Jun 2021, at 01:58, Phillip Hallam-Baker <[email-masked]> wrote:
> 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. 

> 
> 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). 

> 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. 

> 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. 

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.  

(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). 

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. 

— Neil

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 8 Jun 2021 12:36:14 -0400

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

>> (This is in contrast to key agreement algorithms - “alg” - as these can
>> be advertised in the JSON Web Key metadata).
>>
>
> 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.
>
> 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.

---

From: Michael StJohns <[email-masked]>
Date: Tue, 8 Jun 2021 12:37:10 -0400

On 6/7/2021 9:53 AM, Roman Danyliw wrote:
>
>   * I would like to propose that in future assignment of relevant OIDs
>     and JOSE identifiers be considered a requirement for similar work.
>     If a spec for a symmetric mode isn't sufficiently specified to
>     enable interoperable implementation in CMS and JOSE, it is not
>     sufficiently specified to be an RFC.
>
> [Roman] Agreed in the general case for the IETF stream.  For RFC7253, 
> this review would have been during IESG conflict review because that 
> document was IRTF stream (which doesn’t have an SECDIR review, AD 
> review or even an IESG ballot).
>
> Roman
>
This seems to be yet another reason why the CFRG should be a WG and not 
an RG.

I know this is not a popular opinion, but I think by keeping the CFRG in 
the IRTF, we're actually hurting the IRTF.   In the deep murky history 
of the IRTF, the organization was originally (post Kobe) meant to be a 
place for exploration of a lot of different points of view.  The concept 
of a RG "adopting a draft" was pretty much anathema - the idea was for 
lots of competing ideas to make it through the publication filters after 
some peer review and thence on to the broader community for 
consideration within the protocol development community.   It was not to 
come to a "consensus" on the one true way.  It should be possible to go 
into a RG with an idea that meets the general theme and is at least 
plausible, without having to "win" a race of competing proposals, and 
come out of it with an RFC in much less than 2 years - even as an 
individual contributor.  I'm not sure that's still possible.

At this point, the IRTF is looking more and more like a more closed 
version of the IETF with many procedures mostly indistinguishable from 
the IETF.  A number of RGs even have IANA actions for their documents 
and that suggests standards creation is bleeding into the IRTF in a way 
that will diminish the worth of the IRTF as a place for ideas rather 
than finished designs.

In the instant discussion, OID assignment should be done using IETF 
procedures.  And discussions on changes to IETF procedures are (or 
should be?) probably out of scope for an RG.

Later, Mike

---

From: Colin Perkins <[email-masked]>
Date: Wed, 9 Jun 2021 15:15:35 +0100

> On 8 Jun 2021, at 17:37, Michael StJohns <[email-masked]> wrote:
IRTF stream drafts do get IRSG review before publication, but equally one of the reasons we have IESG conflict review is to catch this sort of thing if it's missed.
> This seems to be yet another reason why the CFRG should be a WG and not an RG. 
> 
You’ve repeatedly raised this point. The IRSG considered it, and the CFRG chairs and IAB discussed it in the last IAB review of CFRG. Each time, we concluded that the CFRG is best placed be able to bridge the cryptographic research community and the IETF as an IRTF RG.
> I know this is not a popular opinion, but I think by keeping the CFRG in the IRTF, we're actually hurting the IRTF.   In the deep murky history of the IRTF, the organization was originally (post Kobe) meant to be a place for exploration of a lot of different points of view.  The concept of a RG "adopting a draft" was pretty much anathema - the idea was for lots of competing ideas to make it through the publication filters after some peer review and thence on to the broader community for consideration within the protocol development community.
> 
Kobe was a long time ago. Organisations and processes evolve. 
> It was not to come to a "consensus" on the one true way.  It should be possible to go into a RG with an idea that meets the general theme and is at least plausible, without having to "win" a race of competing proposals, and come out of it with an RFC in much less than 2 years - even as an individual contributor.  I'm not sure that's still possible.
> 
I note that draft-oran-icnrg-qosarch-06 is currently in the RFC Editor queue as a non-consensus document on the IRTF stream. The initial draft was submitted in August 2019. CFRG works in a particular way. Other RGs can, and do, work in different ways.
> At this point, the IRTF is looking more and more like a more closed version of the IETF with many procedures mostly indistinguishable from the IETF.  A number of RGs even have IANA actions for their documents and that suggests standards creation is bleeding into the IRTF in a way that will diminish the worth of the IRTF as a place for ideas rather than finished designs.
> 
One of the roles of IRTF is to publish experimental protocols, to document ideas that are being prototyped to see if they’re usable at Internet scale, and to help the research community conduct deployment experiments. Sometimes those experimental protocols need parameter registries, so other experiments can build on top of them without conflicts. This can be abused, like everything, but I don’t see the concept of IANA registries in IRTF RFCs as inherently problematic.
> In the instant discussion, OID assignment should be done using IETF procedures.  And discussions on changes to IETF procedures are (or should be?) probably out of scope for an RG.  

Changes to the IETF procedures can only be made by the IETF, certainly, but the participants an IRTF RG can discuss whether they think those procedures ought to change, and whether they want to propose such a change to IETF, same as participants in any other venue can have such a discussion. 

-- 
Colin Perkins
https://csperkins.org/

---

From: Neil Madden <[email-masked]>
Date: Fri, 11 Jun 2021 11:00:31 +0100

On 8 Jun 2021, at 17:36, Phillip Hallam-Baker <[email-masked]> wrote:
> […]
> 
> On Tue, Jun 8, 2021 at 3:53 AM Neil Madden <[email-masked] <mailto:[email-masked]>> wrote:
> On 8 Jun 2021, at 01:58, Phillip Hallam-Baker <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> 
>> On Mon, Jun 7, 2021 at 10:02 AM Neil Madden <[email-masked] <mailto:[email-masked]>> wrote:
> 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.

And yet that is exactly what is recorded in the IANA JOSE registry. I appreciate that you’d like things to be different, but that’s not the reality today. A WG established the IANA registry and set up the procedures by which alterations to it are made, as described in RFC 7518 that established the registry (p34):

   The implementation requirements of an algorithm may be changed over
   time as the cryptographic landscape evolves, for instance, to change
   the status of an algorithm to Deprecated or to change the status of
   an algorithm from Optional to Recommended+ or Required.

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

OAuth2 doesn’t have any dependency on JOSE. I think you mean OIDC?

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

Sorry, what? JOSE defines *two* serialization formats: https://datatracker.ietf.org/doc/html/rfc7515#section-7 <https://datatracker.ietf.org/doc/html/rfc7515#section-7> 

> Well it does actually - see the “JOSE Implementation Requirements” field: https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms <https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms>
> 
> And merely assigning a code point does not change the recommendations for implementing algorithms in a 'JOSE Library'.

It absolutely does in this case.

> 
> 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.

If you didn’t implement the Required algorithms, then you didn’t implement a standards-compliant JOSE library. Otherwise what do you think “JOSE Implementation Requirements: Required” means on an IANA JOSE algorithm registration?

> 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.
> 
>  
> 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.

I’m not conflating anything. Unlike yourself, I am the primary maintainer of a JOSE library that is in use in some of the largest organisations in the world handling many millions of operations every day. You keep making statements that are directly in contradiction with the JOSE RFCs.

> OATH2 allows use of 128 bit AES and 256 bit SHA-2.

Again, I assume you mean OpenID Connect, as OAuth2 itself makes no recommendations about cryptography at all (other than requiring TLS). OIDC itself defers to JOSE for algorithms. So here you can see that the choice of algorithms in the IANA JOSE algorithms registry directly and immediately impacts a widely used protocol.

> 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.
>  
> 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.
> 

By your own admission the Mesh is doing something entirely non-standard with JOSE anyway, so you are also free to also adopt OCB as a non-standard algorithm. 

As somebody who is responsible for maintaining a JOSE library (and an OIDC implementation), I’d rather we were somewhat conservative in adopting new JOSE algorithms. I strongly disagree that there should be a presumption that any algorithm published by CFRG should immediately be considered for adoption by default in JOSE. There are cases where I think adoption would be sensible - e.g. I hope to see post-quantum algorithms for JOSE at some point - but OCB doesn’t reach the bar in my opinion. 

— Neil

---

From: Michael StJohns <[email-masked]>
Date: Fri, 11 Jun 2021 17:00:34 -0400

Hi Colin - thanks for the note.

On 6/9/2021 10:15 AM, Colin Perkins wrote:
>> On 8 Jun 2021, at 17:37, Michael StJohns <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>>   * I would like to propose that in future assignment of relevant
>>>     OIDs and JOSE identifiers be considered a requirement for
>>>     similar work. If a spec for a symmetric mode isn't sufficiently
>>>     specified to enable interoperable implementation in CMS and
>>>     JOSE, it is not sufficiently specified to be an RFC.
>>>
>>> [Roman] Agreed in the general case for the IETF stream.  For 
>>> RFC7253, this review would have been during IESG conflict review 
>>> because that document was IRTF stream (which doesn’t have an SECDIR 
>>> review, AD review or even an IESG ballot).
>>>
> IRTF stream drafts do get IRSG review before publication, but equally 
> one of the reasons we have IESG conflict review is to catch this sort 
> of thing if it's missed.

Personally, I think that's a bug, not a feature.  If something shows up 
at the IRTF that might conflict with the IETF, it should be pretty 
obvious at the beginning and ideally moved over to the IETF by the RG 
chair or the IRTF chair at that point rather than waiting to the point 
of publication.  More below.

> You’ve repeatedly raised this point. The IRSG considered it, and the 
> CFRG chairs and IAB discussed it in the last IAB review of CFRG. Each 
> time, we concluded that the CFRG is best placed be able to bridge the 
> cryptographic research community and the IETF as an IRTF RG.

Just to satisfy my curiosity:  Did the topic of Anti-Trust with respect 
to standards come up in that discussion?   For my own edification, I 
asked Jay Daley whether or not the IETF insurance policies related to 
this covered the IRTF and whether there were any terms and conditions 
that needed to be followed to retain coverage?   I haven't gotten an 
answer to that question yet, but it was a topic he will probably bring 
up with the underwriters when they review coverage.

Some of the byzantine structure of the IETF processes are related to 
providing a structure of institutionalized protections related to 
avoiding anti-trust violations in the standardization process. Those 
include the IPR disclosure requirements, open participation requirements 
and things like the appeal process - none of which necessarily or 
consistently apply to the IRTF.  Even IETF stream Informational 
documents go through that process making the question of whether or not 
they are standards in truth less fraught if we get it wrong.

>> I know this is not a popular opinion, but I think by keeping the CFRG 
>> in the IRTF, we're actually hurting the IRTF.   In the deep murky 
>> history of the IRTF, the organization was originally (post Kobe) 
>> meant to be a place for exploration of a lot of different points of 
>> view.  The concept of a RG "adopting a draft" was pretty much 
>> anathema - the idea was for lots of competing ideas to make it 
>> through the publication filters after some peer review and thence on 
>> to the broader community for consideration within the protocol 
>> development community.
>>

Unfortunately, they sometimes evolve in directions that weren't 
expected, nor were actually best for the community.  See below. In any 
event, your current charter and guidelines were set back in 1996 
(RFC2014) and haven't yet been revised even though Lars submitted a 
draft to do so a few years back.

> The IRTF is a composed of a number of focused, long-term, small
>     Research Groups.  These groups work on topics related to Internet
>     protocols, applications, architecture and technology. Research Groups
>     are expected to have the stable long term membership needed to
>     promote the development of research collaboration and teamwork in
>     exploring research issues.  Participation is by individual
>     contributors, rather than by representatives of organizations.

Note the "focused" and "small" adjectives.  It might be useful to review 
sections 1 and 1.1 of RFC 2014 and figure out if the IRTF is still 
following the spirit of that guidance.  There's also the "stable long 
term membership" which implies an enumeratable group of core members 
actively involved on a long term basis (e.g., not just a member of the 
mailing list...) .  There are multiple statements throughout 2014 that 
refer to a core active membership.

>> It was not to come to a "consensus" on the one true way.  It should 
>> be possible to go into a RG with an idea that meets the general theme 
>> and is at least plausible, without having to "win" a race of 
>> competing proposals, and come out of it with an RFC in much less than 
>> 2 years - even as an individual contributor.  I'm not sure that's 
>> still possible.
>>
> I note that draft-oran-icnrg-qosarch-06 is currently in the RFC Editor 
> queue as a non-consensus document on the IRTF stream. The initial 
> draft was submitted in August 2019. CFRG works in a particular way. 
> Other RGs can, and do, work in different ways.

Thanks for pointing out this document. The datatracker history is pretty 
much an indictment of the IRTF publication process.   As I read this 
document (both reading and reading the diffs), Dave submitted it for 
publication April 2020 (the -04 draft), and - my opinion - that document 
was probably 95%+ ready for publication at that time.   There were a 
number of minor but substantive revisions made after the designated IRTF 
reviewer reviewed the document.  Had it not taken 2.5 months to assign a 
reviewer, the document would have been pretty much ready for publication 
as a thought piece (its intended role) no later than mid to late May 
2020.  The IRSG then tacked on a second review, a conflict review, two 
votes (IESG and IRSG) including a large number of delays (about 4-5 
months total including that 2.5 months mentioned prior) where the 
datatracker shows it in a state waiting for you to dispatch.  There was 
some small amount of explanatory material added after the IRSG review - 
but IMO didn't add anything substantive to the document or for later 
readers.

I was surprised by Mirja's comment that this document was more 
appropriate for the ISE - that suggests there may be a misunderstanding 
of the IRTF model - either on her part or on mine.  As I understand the 
document, it was well within the research area of the ICNRG and 6.2 of 
RFC2014 applies.

It finally got to the RFC editor in late June this year.

I'm not a member of ICNRG, so maybe this is just the way they like 
things... but Dave's document could have been useful as an RFC as early 
as June or July last year.  I see a pretty bad balance of time 
delay/benefit here.

>> version of the IETF with many procedures mostly indistinguishable 
>> from the IETF.  A number of RGs even have IANA actions for their 
>> documents and that suggests standards creation is bleeding into the 
>> IRTF in a way that will diminish the worth of the IRTF as a place for 
>> ideas rather than finished designs.
>>
> One of the roles of IRTF is to publish experimental protocols, to 
> document ideas that are being prototyped to see if they’re usable at 
> Internet scale, and to help the research community conduct deployment 
> experiments. Sometimes those experimental protocols need parameter 
> registries, so other experiments can build on top of them without 
> conflicts. This can be abused, like everything, but I don’t see the 
> concept of IANA registries in IRTF RFCs as inherently problematic.

That mostly doesn't hold water.    If the experimental protocols are so 
wide spread  that the IRTF documents no longer are sufficient to 
document the research, and/or there are non-IRTF members implementing 
them - it's a standard or well on its way to becoming one.   One answer 
is to draw a bright line at the registry or even at something that looks 
like a usable implementation and transfer the work to the IETF at that 
point. I do note there are cases where you're just adding stuff to 
existing registries (the "ham" URI for example) and that will be useful 
to prevent collisions.

The registries are a symptom, not necessarily the problem.

> Changes to the IETF procedures can only be made by the IETF, 
> certainly, but the participants an IRTF RG can discuss whether they 
> think those procedures ought to change, and whether they want to 
> propose such a change to IETF, same as participants in any other venue 
> can have such a discussion.

Sure, but it's a pointless discussion unless the result reaches over to 
the right set of people.  E.g. SAAG is probably the right set for this 
discussion not CFRG.  That would have been a good point for chair of the 
CFRG or you to make that suggestion.

Later, Mike

>
> -- 
> Colin Perkins
> https://csperkins.org/ <https://csperkins.org/>
>
>
>
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 11 Jun 2021 23:52:41 -0400

On Fri, Jun 11, 2021 at 6:00 AM Neil Madden <[email-masked]> wrote:

> And yet that is exactly what is recorded in the IANA JOSE registry. I
> appreciate that you’d like things to be different, but that’s not the
> reality today. A WG established the IANA registry and set up the procedures
> by which alterations to it are made, as described in RFC 7518 that
> established the registry (p34):
>

Yes, like I said. It was a mistake. There is no need to compound it.

> It absolutely does in this case.

Only because there is a column giving the recommendation status. My point
is that is a mistake.

By your own admission the Mesh is doing something entirely non-standard
> with JOSE anyway, so you are also free to also adopt OCB as a non-standard
> algorithm.
>

It will become the standard if people use it. Which is precisely the point:
Code point registrations are properties of algorithms, not one particular
protocol that might use them. There should never have been a JOSE algorithm
registry in the first place, it should have been a registry of algorithms
that JOSE was merely the first consumer of.

I remember when the IANA Content Type Registry was the MIME Type. If MIME
had made recommendations for supported types, should those have been
binding on the Web?

---

From: Colin Perkins <[email-masked]>
Date: Sat, 12 Jun 2021 13:30:29 +0100

Mike,

> On 11 Jun 2021, at 22:00, Michael StJohns <[email-masked]> wrote:
> 
>>> On 8 Jun 2021, at 17:37, Michael StJohns <[email-masked] <mailto:[email-masked]>> wrote:
> Personally, I think that's a bug, not a feature.  If something shows up at the IRTF that might conflict with the IETF, it should be pretty obvious at the beginning and ideally moved over to the IETF by the RG chair or the IRTF chair at that point rather than waiting to the point of publication.  More below.
> 
I believe it’s sensible that the IESG has procedures in place to catch any conflicts that might be missed by the other publication streams.
> Just to satisfy my curiosity:  Did the topic of Anti-Trust with respect to standards come up in that discussion? 
> 
No.
>   For my own edification, I asked Jay Daley whether or not the IETF insurance policies related to this covered the IRTF and whether there were any terms and conditions that needed to be followed to retain coverage?   I haven't gotten an answer to that question yet, but it was a topic he will probably bring up with the underwriters when they review coverage.
> 
> Some of the byzantine structure of the IETF processes are related to providing a structure of institutionalized protections related to avoiding anti-trust violations in the standardization process.  Those include the IPR disclosure requirements, open participation requirements and things like the appeal process - none of which necessarily or consistently apply to the IRTF.  Even IETF stream Informational documents go through that process making the question of whether or not they are standards in truth less fraught if we get it wrong.
> 
As I’m sure you’re aware, the IRTF has IPR disclosure requirements in place. While RFC 2014 allows for IRTF research groups with closed membership, all the current research groups have open membership (and that has been the case for many years now). Decisions made by the IRTF Chair can be appealed to the IAB, and concerns about research group operations may be raised with the IRTF Chair.
> Unfortunately, they sometimes evolve in directions that weren't expected, nor were actually best for the community.  See below.  In any event, your current charter and guidelines were set back in 1996 (RFC2014) and haven't yet been revised even though Lars submitted a draft to do so a few years back.
> 
> Note the "focused" and "small" adjectives.  It might be useful to review sections 1 and 1.1 of RFC 2014 and figure out if the IRTF is still following the spirit of that guidance.  There's also the "stable long term membership" which implies an enumeratable group of core members actively involved on a long term basis (e.g., not just a member of the mailing list...) .  There are multiple statements throughout 2014 that refer to a core active membership.
> 
I’m familiar with RFC 2014. It’s not clear what point you are trying to make here.
> Thanks for pointing out this document. The datatracker history is pretty much an indictment of the IRTF publication process.   As I read this document (both reading and reading the diffs), Dave submitted it for publication April 2020 (the -04 draft), and - my opinion - that document was probably 95%+ ready for publication at that time.   There were a number of minor but substantive revisions made after the designated IRTF reviewer reviewed the document.  Had it not taken 2.5 months to assign a reviewer, the document would have been pretty much ready for publication as a thought piece (its intended role) no later than mid to late May 2020.  The IRSG then tacked on a second review, a conflict review, two votes (IESG and IRSG) including a large number of delays (about 4-5 months total including that 2.5 months mentioned prior) where the datatracker shows it in a state waiting for you to       dispatch.  There was some small amount of explanatory material added after the IRSG review - but IMO didn't add anything substantive to the document or for later readers.
> 
> I was surprised by Mirja's comment that this document was more appropriate for the ISE - that suggests there may be a misunderstanding of the IRTF model - either on her part or on mine.  As I understand the document, it was well within the research area of the ICNRG and 6.2 of RFC2014 applies.
> 

If an IRSG member has a question about the suitability of a document for publication on the IRTF stream, then they should raise it for discussion. Mirja did this, the IRSG discussed the issue and agreed publication on the IRTF stream was appropriate.
> I'm not a member of ICNRG, so maybe this is just the way they like things... but Dave's document could have been useful as an RFC as early as June or July last year.  I see a pretty bad balance of time delay/benefit here.
> 
As you note, you’re not a participant in ICNRG and hence are not familiar with all the discussion and context around this draft. 

I also remind you that there's an ongoing pandemic that's caused significant delay and disruption for many activities over the past year or so.
> That mostly doesn't hold water.  If the experimental protocols are so wide spread  that the IRTF documents no longer are sufficient to document the research, and/or there are non-IRTF members implementing them - it's a standard or well on its way to becoming one.   One answer is to draw a bright line at the registry or even at something that looks like a usable implementation and transfer the work to the IETF at that point.   I do note there are cases where you're just adding stuff to existing registries (the "ham" URI for example) and that will be useful to prevent collisions.
> 
The Internet research community has long made use of research testbeds and deployment experiments, sometimes at large scale, to validate ideas. As part of this, the community sometimes needs experimental protocols and parameter registries to be documented to help coordination between researchers. It's appropriate that IRTF supports such research.

-- 
Colin Perkins
https://csperkins.org/