[jose] Re: WGLC for draft-ietf-jose-fully-specified-algorithms

[Neil Madden]

Hi Mike, Thanks for the reply, but I don’t think the new draft addresses any of my concerns. I also don’t think there is consensus for the ECDH-ES identifier changes being proposed. I do strongly believe the draft should be re-written with a much reduced scope to just specify Ed25519 and Ed448 identifiers and drop the rest. — Neil On 9 Jul 2024, at 21:43, Michael Jones <michael_b_jo...@hotmail.com> wrote:  Thanks for your detailed WGLC feedback, Neil.  I believe that the specification now consistently describes the approaches taken to address the problems posed by the existing polymorphic algorithm registrations.  In particular, it now clearly describes which of them have replacements registered for them, which do not, and why.  And in the cases where replacements are not being registered, it describes how future specifications can do so.   I understand that you would solve these problems differently and am thankful that you nonetheless chose to provide detailed and useful feedback on the approach taken.  The authors attempted to incorporate as much of your feedback as possible, which greatly clarified the text and its intent in numerous places.                                                                   Sincerely,                                                                 -- Mike   From: Neil Madden <neil.e.mad...@gmail.com> Sent: Monday, May 6, 2024 11:58 AM To: Michael Jones <michael_b_jo...@hotmail.com> Cc: Karen ODonoghue <kodo...@gmail.com>; JOSE WG <jose@ietf.org> Subject: Re: [jose] WGLC for draft-ietf-jose-fully-specified-algorithms   Hi Mike,   Thanks for the response, but none of this addresses or is even relevant to any of the points I raised. It just confirms that the mistake is wide-spread.   Taking OIDC as an example, why is it a perfectly fine solution for OIDC discovery to define both      id_token_encryption_alg_values_supported     id_token_encryption_enc_values_supported allowing these two independent parameters to be independently specified, but it is not an option to define a similar     id_token_encryption_crv_values_supported ?   Incidentally, given that you've put WebAuthn in the list, what's the plan there for when you deprecate the algorithm identifiers used by already deployed hardware? Given that WebAuthn is basically a monoculture around ES256 at this point, you will be directly deprecating the algorithm used by nearly 100% of existing hardware.   (I tried to find out *why* WebAuthn makes this restriction instead of just specifying the key size/curve directly, but I got lost in a maze of twisty little hyperlinks, all alike).   -- Neil   On 6 May 2024, at 18:11, Michael Jones <michael_b_jo...@hotmail.com> wrote:   The draft is solving a real problem that’s not hypothetical.  Multiple specifications by multiple working groups across both JOSE and COSE have had to create workarounds for the problems that polymorphic algorithm identifiers are causing.  While previously discussed on-list and in the draft, as a reminder, these specifications implemented or need mitigations for polymorphic algorithm identifiers:   WebAuthn contains this de-facto algorithm definition to work around this problem:   -8 (EdDSA), where crv is 6 (Ed25519)  FAPI 2 contains this similar workaround: Note: As of the time of writing there isn't a registered fully-specified algorithm describing "EdDSA using the Ed25519 variant". If such algorithm is registered in the future, it is also allowed to be used for this profile.   OAuth 2.0 Authorization Server Metadata, which defines this metadata property (and others similar to it):    token_endpoint_auth_signing_alg_values_supported       OPTIONAL.  JSON array containing a list of the JWS signing       algorithms ("alg" values) supported by the token endpoint for the       signature on the JWT [JWT] used to authenticate the client at the       token endpoint for the "private_key_jwt" and "client_secret_jwt"       authentication methods.   OpenID Connect Discovery 1.0, which defines this metadata property (and others similar to it): id_token_signing_alg_values_supported REQUIRED. JSON array containing a list of the JWS signing algorithms (alg values) supported by the OP for the ID Token to encode the Claims in a JWT [JWT].   Neil, you’re right that the spec needs editorial work to accurately reflect which parts of the problem space the working group decided to tackle and not tackle at this time.  We didn’t update the spec before WGLC to reflect the outcome of the on-list working group discussion “[jose] Fully-specified ECDH algorithms”.  This will happen once the working group last call feedback is in.  That said, solving the acute parts of the problem now won’t preclude additional specifications solving more of the pain points in the future.   As for you disagreeing with deprecating “EdDSA” for JOSE, the polymorphic EdDSA definition is the root cause of the need for the workarounds above.  Fixing the problem requires replacing it.   Summarizing my position, this specification will be ready for publication after applying the (mostly editorial) updates described above.                                                                   -- Mike   From: jose <jose-boun...@ietf.org> On Behalf Of Neil Madden Sent: Monday, May 6, 2024 6:41 AM To: Karen ODonoghue <kodo...@gmail.com> Cc: jose@ietf.org Subject: Re: [jose] WGLC for draft-ietf-jose-fully-specified-algorithms   Unsurprisingly, I still don’t think this is a very good idea, and I think the draft still needs a lot of work. The abstract and rest of the draft still mentions making *all* JOSE algorithm identifiers “fully-specified”, but the draft does no such thing: just changing EdDSA now (for JOSE). As this WGLC says, there was no support for “fully-specifying” ECDH algorithm identifiers, because it’s clearly a bad idea.    So the draft needs to be substantially rewritten to reflect what it is actually now proposing. It also, ironically, needs to flesh out what “fully-specified” means, because that description is very vague. (eg it seems key sizes do not need to be specified, but curves do, and it refers to KDFs and other things that are not in scope).  Perhaps rewrite it as a more focused draft saying that *elliptic curve signature* algorithms should specify the curve specifically.    I strongly disagree with deprecating “EdDSA” for JOSE, so IMO section 3.1.2 should be deleted.    The entirety of section 3.3 should also be removed, or else substantially rewritten to reflect that the advice doesn’t apply to encryption algorithms. I would delete it.    Section 6.1 is wrong, as has been pointed out already in this WG: numerous HSM restrict RSA key sizes they support. (Saying it’s not a problem in the wild because everything uses the same key sizes begs the question as to why the same reasoning doesn’t apply to EdDSA).    Section 6.2 says it is not sure what to do, suggesting the draft isn’t ready for WGLC.    The security considerations in section 7 are nonsense. How does an attacker get to “choose algorithms” with current EdDSA?   Overall, this draft is still deeply confused and not anywhere near ready for publication.    Regards,   Neil On 6 May 2024, at 06:31, Karen ODonoghue <kodo...@gmail.com> wrote: JOSE working group members, This email initiates a three week working group last call on the following document:  https://datatracker.ietf.org/doc/draft-ietf-jose-fully-specified-algorithms/ All open issues have been resolved. Additionally there does not appear to be general support for including fully-specified ECDH algorithms. https://mailarchive.ietf.org/arch/msg/jose/ZHDlXENvTwjlWxTVQQ2hkNBX4dw/    Please review the document and post any final comments along with your recommendation on whether or not it is ready to proceed by the Monday 27 May.    Thank you,  JOSE chairs   _______________________________________________ jose mailing list jose@ietf.org https://www.ietf.org/mailman/listinfo/jose

_______________________________________________
jose mailing list -- jose@ietf.org
To unsubscribe send an email to jose-le...@ietf.org