Subject: Re: [jose] [COSE] 🔔 WGLC of draft-ietf-cose-webauthn-algorithms

From: Mike Jones <[email-masked]>
Date: Tue, 22 Oct 2019 16:17:15 +0000

Thanks again for the review, Neil.  My replies are inline, prefixed by “Mike>”.

                                                       -- Mike

From: COSE <[email-masked]> On Behalf Of Neil Madden
Sent: Friday, September 20, 2019 8:09 AM
To: Jim Schaad <[email-masked]>
Cc: [email-masked]; [email-masked]; ivaylo petrov <[email-masked]>
Subject: Re: [COSE] [jose] 🔔 WGLC of draft-ietf-cose-webauthn-algorithms

Thanks for the reply, comments in-line marked with [NEM]:

On 20 Sep 2019, at 15:31, Jim Schaad <[email-masked]<mailto:[email-masked]>> wrote:

From: jose <[email-masked]<mailto:[email-masked]>> On Behalf Of Neil Madden
Sent: Friday, September 20, 2019 2:35 AM
To: ivaylo petrov <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [jose] 🔔 WGLC of draft-ietf-cose-webauthn-algorithms

Thanks, I wasn't aware of this draft. It looks ok, just a few comments from me:

secp256k1 is mentioned in the context of signatures and the new ES256K JWS algorithm, but when it is registered in the JOSE Elliptic Curve registry it will also be usable for ECDH-ES encryption. The current draft mentions JOSE but only links to RFC 7515 (JWS). Is the intention that the curve be only used for signatures, or is it also intended for encryption?

[JLS] That is an interesting question.  Right now I would say that it is only for signatures, but it could be expanded to key agreement quite easily.  Is there any need for it or are you just speculating?  The big use I know of is bit coin which is only signatures and WebAuthn which is only signatures.

[NEM] As soon as it is registered as a JOSE elliptic curve it can be used for ECDH-ES, so the draft should make a statement one way or another as to whether this is intended rather than standardizing that usage by side-effect IMO.

Mike> Having thought about this some more, given that no one on the thread has presented an argument why secp256k1 should or should not be used with ECDH-ES, I now plan to make an explicit statement that whether it can or cannot be used is explicitly out of scope of this specification, and the topic could be covered by a future specification.  The question doesn’t have to be decided to achieve the goals of the current specification.

I'm glad RS1 is not being registered for JOSE, although I'm still a bit surprised that it is being registered (even as deprecated) for a standard as new as COSE. I can't find any justification in the linked WebAuthn or CTAP specs for why this algorithm needs to exist at all. Section 5.3 says that it needs to be registered because some WebAuthn TPM attestations use it, but the very same section says that the algorithm MUST NOT be used by COSE implementations (is a WebAuthn implementation not a COSE implementation?). If the normative language in the spec is obeyed then the algorithm will never be used and so the registered identifier isn't needed.

[JLS] For better or for worse, RS1 is already registered for JOSE, so that is the reason it is not registered here.

Ouch, I hadn't seen this. The WebCrypto group really did a number on the registry. Thankfully most of them (including RS1) are only registered for JWK usage and marked as Prohibited. (What does it even mean for things like "A128CBC" to be registered as a JWK "alg" value?)

My main point still stands that section 5.3 of the draft is self-contradictory as it says that the reason for registry is because some TPMs are using the algorithm but then also says that those implementations MUST NOT use the algorithm, negating the reason for registering it in the first place.

Mike> I will include the explanation arrived at in the discussion on the JOSE mailing list.

-- Neil

---

From: Mike Jones <[email-masked]>
Date: Thu, 24 Oct 2019 23:13:43 +0000

These issue resolutions have been incorporated in https://tools.ietf.org/html/draft-ietf-cose-webauthn-algorithms-02.  Thanks again for your useful review!

                                                                -- Mike

From: Mike Jones
Sent: Tuesday, October 22, 2019 9:17 AM
To: Neil Madden <[email-masked]>; Jim Schaad <[email-masked]>
Cc: [email-masked]; [email-masked]; ivaylo petrov <[email-masked]>
Subject: RE: [COSE] [jose] 🔔 WGLC of draft-ietf-cose-webauthn-algorithms

                                                       -- Mike

From: COSE <[email-masked]<mailto:[email-masked]>> On Behalf Of Neil Madden
Sent: Friday, September 20, 2019 8:09 AM
To: Jim Schaad <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; ivaylo petrov <[email-masked]<mailto:[email-masked]>>
Subject: Re: [COSE] [jose] 🔔 WGLC of draft-ietf-cose-webauthn-algorithms

-- Neil

---

From: Mike Jones <[email-masked]>
Date: Thu, 24 Oct 2019 23:16:02 +0000

These issue resolutions have been incorporated in https://tools.ietf.org/html/draft-ietf-cose-webauthn-algorithms-02.  Thanks again for your useful reviews!

				-- Mike

-----Original Message-----
From: Benjamin Kaduk <[email-masked]> 
Sent: Monday, September 23, 2019 10:37 AM
To: Neil Madden <[email-masked]>
Cc: Mike Jones <[email-masked]>; Jim Schaad <[email-masked]>; [email-masked]; [email-masked]; ivaylo petrov <[email-masked]>
Subject: Re: [jose] 🔔 WGLC of draft-ietf-cose-webauthn-algorithms

On Sat, Sep 21, 2019 at 11:47:53AM +0100, Neil Madden wrote:
> On 21 Sep 2019, at 01:44, Mike Jones <Michael.Jones=[email-masked]> wrote:
> > 
> > RSA SHA-1 is used by TPMs, which produce attestations used by W3C WebCrypto.  That can’t be changed.  That’s why an algorithm identifier is needed for it.  It’s use is prohibited for new applications but TPMs are an existing application.  I can work to make this clearer when resolving the WGLC comments.
> 
> I think clarifying the text along those lines would help a lot. It is worrying that these TPMs have to continue to use a known weak signature method and they apparently cannot be changed, but at least with the MUST NOT you give people a clue that this is something they want to run away from pretty quickly.
> 
> >  
> > As for secp256k1, the “ES256K” algorithm is registered, whose definition is “ECDSA using secp256k1 curve and SHA-256”.  That’s only for signing.  The draft is currently silent on whether the registered curve can also be used for other things.  I think that’s how it should be, unless there are security reasons to the contrary.
> 
> Well section 4.4 registers secp256k1 as a JWK Elliptic Curve so it will be usable with the existing ECDH-ES family of algorithms without any additional registrations. There *are* some security concerns about using secp256k1 outside of signatures - see e.g. [1] which lists the theoretical problems with the curve. In particular, fast implementations of scalar multiplication (used in ECDH) for secp256k1 are not constant time making it a riskier choice for ECDH than for ECDSA. As far as I'm aware though, that just puts it in the same category as the other NIST/SECG standard curves that are already registered for JOSE. So I'm not against it being available for both JWS and JWE usage, I'd just like that to be an explicit documented decision rather than an accident.

I'm also inclined to agree that making an explicit statement is preferred; I have less-strong feelings about whether that statement is to allow or disallow the usage.

-Ben

> [1]: 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcryp
> to.stackexchange.com%2Fa%2F68286%2F26028&amp;data=02%7C01%7CMichael.Jo
> nes%40microsoft.com%7Cfa969966b9eb45afa24808d7404cbdca%7C72f988bf86f14
> 1af91ab2d7cd011db47%7C1%7C0%7C637048570666413397&amp;sdata=HWxwbJIZZfN
> gHhyX1GIJ8%2FahQC8FsrMH0SnLxrrX%2BDo%3D&amp;reserved=0 
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcry
> pto.stackexchange.com%2Fa%2F68286%2F26028&amp;data=02%7C01%7CMichael.J
> ones%40microsoft.com%7Cfa969966b9eb45afa24808d7404cbdca%7C72f988bf86f1
> 41af91ab2d7cd011db47%7C1%7C0%7C637048570666413397&amp;sdata=HWxwbJIZZf
> NgHhyX1GIJ8%2FahQC8FsrMH0SnLxrrX%2BDo%3D&amp;reserved=0>
> 
> -- Neil

> _______________________________________________
> jose mailing list
> [email-masked]
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fjose&amp;data=02%7C01%7CMichael.Jones%
> 40microsoft.com%7Cfa969966b9eb45afa24808d7404cbdca%7C72f988bf86f141af9
> 1ab2d7cd011db47%7C1%7C0%7C637048570666413397&amp;sdata=Q6DuWQduwTgUYcx
> OnZ7znz0bwfMSGYdCeSSb1PZiRjs%3D&amp;reserved=0