Thanks for your comments, Neil. See the updates to the specification in
https://www.ietf.org/archive/id/draft-ietf-jose-fully-specified-algorithms-06.html.
My replies are inline below, prefixed by "Mike>".
-- Mike
From: Neil Madden <[email protected]>
Sent: Wednesday, September 4, 2024 2:59 AM
To: Karen ODonoghue <[email protected]>
Cc: JOSE WG <[email protected]>
Subject: [jose] Re: 2nd WGLC for draft-ietf-jose-fully-specified-algorithms
(Fully Specified Algorithms)
It might be helpful if the authors could describe how they have addressed the
feedback received?
Mike> See below
>From my point of view, there are still many problems with this document.
>AFAICT, almost none of the points I've raised previously have been addressed.
>Although the document no longer deprecates encryption algorithms, it still
>contains problematic statements about them, and clauses like this one in
>section 3.1:
"Each of these multiple algorithms must be independently fully specified. The
operations performed by each of them MUST NOT vary when used alongside other
algorithms. So for instance, for JOSE, alg values and enc values MUST each be
fully specified, and their behaviors MUST NOT depend upon one another."
These requirements would make ECDH-ES with direct key agreement unusable,
because it includes the "enc" value in the KDF context info, so very directly
depends on the specific content encryption algorithm. (And this kind of context
inclusion absolutely *should* be done for security). IMO most of section 3 is
wrong or misleading and should be removed entirely.
Mike> We removed the incorrect text. Thanks for catching this. As for
removing all the text about encryption, other reviewers explicitly thanked us
for our treatment of encryption and consider it to be in scope. That said, we
have significantly tightened the exposition but left the encryption section in
the specification.
Section 5 should say how implementations that want to support old and new
algorithms for a transition period should handle this: publish the same key
twice with different "alg" values, remove the "alg" field entirely (not a good
idea), etc.
Mike> We've added text on continuing to use deprecated algorithms, per your and
Göran's comments. We also added security considerations text on including
"alg" values in JWKs and COSE Keys.
Section 6.1 on RSA states:
"This is not a problem in practice, because RSA libraries accommodate keys of
different sizes without having to use different code. Therefore, for example,
there are not known cases in the wild where it would be useful to have
different algorithm identifiers for RSASSA-PKCS1-v1_5 with SHA-256 and 2048-bit
keys versus 4096-bit keys or 8192-bit keys. Therefore, the RSA signature
algorithms are not replaced by this specification."
But, as I've pointed out multiple times now, this is not the case. Many
FIPS-compliant HSMs limit RSA key sizes, e.g.:
https://thalesdocs.com/gphsm/ptk/5.9/docs/Content/PTK-C_Admin/Sec_Policies_User_Roles/Typ_Sec_Policies/FIPS.htm
"RSA: must be 2048, 3072, or 4096 bits"
I'm not pointing this out because I think we need to specify RSA key sizes in
algorithm identifiers, but to again point out that the definition of
"fully-specified" that this draft proposed is arbitrary and inconsistent. As
I've said many times before, I would have far less concern about a document
that simply registers Ed25519/Ed448 and marks EdDSA as discouraged.
Mike> Thanks for the FIPS reference. We've incorporated a FIPS 140-3 citation
and updated the RSA text accordingly.
The first paragraph of the security considerations section 7 is outright wrong
and should be removed. There is no additional attack surface before these
changes. If anything, this spec introduces more attack surface!
Mike> We've removed this paragraph.
Appendix A is entirely opinion and should be removed - there is no consensus
about which combinations of ECDH-ES algorithms should be considered and this
document shouldn't make any statement about it.
Mike> Appendix A reflects the state of the working group discussions on ECDH.
Others wanting to create fully-specified ECDH algorithms in the future will
have an easier job with this as a starting point. And again, there was
explicit support in the working group for continuing to discuss fully-specified
encryption algorithms.
- Neil
On 21 Aug 2024, at 15:10, Karen ODonoghue
<[email protected]<mailto:[email protected]>> wrote:
JOSE working group members,
This email initiates a second working group last call for the Fully
Specified Algorithms document:
https://datatracker.ietf.org/doc/draft-ietf-jose-fully-specified-algorithms/
The authors have updated the draft based on WGLC comments and
discussions at IETF 120, and the chairs have polled the working group
about the readiness for WGLC. Seeing no opposition, we've decided to
proceed with a second WGLC.
Please review the document in detail and reply to this message
(keeping the subject line intact) with your opinion on the readiness
of this document for publication and any additional comments that you
have.
This will be a three week WGLC. Please submit your responses by 13
September 2024.
Thank you,
Karen (for the JOSE WG chairs)
_______________________________________________
jose mailing list -- [email protected]<mailto:[email protected]>
To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]
