Subject: Gen-ART review of draft-ietf-jose-json-web-signature-33

From: Russ Housley <[email-masked]>
Date: Sat, 27 Sep 2014 11:31:44 -0400

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-jose-json-web-signature-33
Reviewer: Russ Housley
Review Date: 2014-08-24
IETF LC End Date: 2014-09-03
IESG Telechat date: 2014-10-02

Summary:  Ready.  Some issues could be resolved to improve the document.

Thank you for addressing my comments on -31.

Major Concerns:  

- None.

Minor Concerns:

- Section 10.5 should state that validation of a MAC means provides
  corroboration that the message was generated by one of the parties
  that knows the symmetric MAC key.  This could potentially be many
  parties.

- In Section 4.1.4, should the value match the subject key identifier
  if an X.509 certificate is used?

- In Section 4.1.5, why is TLS required to fetch digitally signed
  X.509 certificates?

---

From: Mike Jones <[email-masked]>
Date: Tue, 30 Sep 2014 18:10:37 +0000

Thanks again for your comments, Russ.  I'm adding the working group to the thread so they're aware of them.  Responses are inline below...

-----Original Message-----
From: ietf [mailto:[email-masked]] On Behalf Of Russ Housley
Sent: Saturday, September 27, 2014 8:32 AM
To: [email-masked]
Cc: IETF Gen-ART; IETF
Subject: Gen-ART review of draft-ietf-jose-json-web-signature-33

I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments you may receive.

Reviewer: Russ Housley

Review Date: 2014-08-24

Major Concerns:

- None.

Minor Concerns:

  parties.

OK

No, it's not expected that these values would match.  For instance, if a JWK contains both bare public key representation of a key and an X.509 representation of the same key, then the "kid" would be expected to match the "kid" in the JWK, which is likely unrelated to the subject key identifier value in the X.509 certificate.  (There's nothing preventing particular applications from using the subject key identifier as the "kid" value, but it's not a requirement, or even necessarily recommended.)

Also note that that certificate thumbprints can be used as identifiers for X.509 certifications, rather than Key ID values - something that's already supported in the spec.

  X.509 certificates?

This question was explicitly discussed by the working group at IETF 87.  The discussion is recorded in the minutes<http://www.ietf.org/proceedings/87/minutes/minutes-87-jose> as follows:

If there is an x5u pointing to a certification issued by a major CA, is TLS required for the HTTP query used to retrieve this certificate?  TLS shouldn't be needed since the certificate is a signed object.  Therefore, the "MUST" use TLS for cert retrieval should be changed to "SHOULD".  This is an application decision.  Mike Jones doesn't want removal of TLS in the case where there's no external means to verify the retrieved key.  Matt Miller: agrees with the jku case, but argues that for x5u, there is a class of applications where it isn't known if the retrieved object is self-protecting (like a certificate) until after it is retrieved.  Even if the object appears to be self-protecting, if the retriever doesn't have a trusted root for that object, it might not be able to verify the protection anyhow.  So it use of TLS might still be preferable instead of having to potentially retrieve an object twice, once over HTTP and then over HTTPS.  Joe Hildebrand wanted to know what the upside of this proposal is.  Richard says it saves on TLS handshakes; Hildebrand envisions a world where TLS is ubiquitous.  Paul Hoffman said that a similar issue in DANE ended up being dropped after a couple of months of discussion.  Richard agreed to drop the TLS MUST to SHOULD proposal.

Russ is certainly right that for certs that chain back to a known root of trust, integrity protection isn't necessary.  It's also the case that this is not true of all certificates that might be used - especially self-signed certificates intended only to carry a key value.  One possibility is to say that TLS MUST be used unless the certificate chains back to a known trust root accepted by the application.  Of course, just requiring TLS is simpler. Do people in the working group want to re-open this issue or are people content with the current requirements?

                                                            -- Mike

---

From: Dave Cridland <[email-masked]>
Date: Tue, 30 Sep 2014 20:08:47 +0100

On 30 September 2014 19:10, Mike Jones <[email-masked]> wrote:

> This question was explicitly discussed by the working group at IETF 87.
> The discussion is recorded in *the minutes
> <http://www.ietf.org/proceedings/87/minutes/minutes-87-jose>* as follows:
>
>
>
> If there is an x5u pointing to a certification issued by a major CA, is
> TLS required for the HTTP query used to retrieve this certificate?  TLS
> shouldn't be needed since the certificate is a signed object.  Therefore,
> the "MUST" use TLS for cert retrieval should be changed to "SHOULD".  This
> is an application decision.  Mike Jones doesn't want removal of TLS in the
> case where there's no external means to verify the retrieved key.  Matt
> Miller: agrees with the jku case, but argues that for x5u, there is a class
> of applications where it isn't known if the retrieved object is
> self-protecting (like a certificate) until after it is retrieved.  Even if
> the object appears to be self-protecting, if the retriever doesn't have a
> trusted root for that object, it might not be able to verify the protection
> anyhow.  So it use of TLS might still be preferable instead of having to
> potentially retrieve an object twice, once over HTTP and then over HTTPS.
> Joe Hildebrand wanted to know what the upside of this proposal is.  Richard
> says it saves on TLS handshakes; Hildebrand envisions a world where TLS is
> ubiquitous.  Paul Hoffman said that a similar issue in DANE ended up being
> dropped after a couple of months of discussion.  Richard agreed to drop the
> TLS MUST to SHOULD proposal.
>
>
>
> Russ is certainly right that for certs that chain back to a known root of
> trust, integrity protection isn’t necessary.  It’s also the case that this
> is not true of all certificates that might be used – especially self-signed
> certificates intended only to carry a key value.  One possibility is to say
> that TLS MUST be used unless the certificate chains back to a known trust
> root accepted by the application.  Of course, just requiring TLS is
> simpler. Do people in the working group want to re-open this issue or are
> people content with the current requirements?
>
>
>
I thought the requirement was confusing as well, however I thought the
rationale might be entirely different:

JOSE exists, in no small part, because of the difficulty in handling X.509
within JavaScript. Therefore even where a certificate [chain] is entirely
valid and properly signed, a JOSE client dereferencing the URI almost
certainly cannot validate the certificate - yet can validate those used in
the TLS handshake because of the difference in the API calls possible.
Indeed, it also cannot validate that the certificate's public key matches
the private key in the JSON object; making use of a trusted source more
important still.

So I do support making the x5u require a dereference over TLS, however I
also think the rationale[s] should be carefully documented in the
specification otherwise the requirement is likely to be ignored.

(More concretely, I think the specification ought to make TLS a SHOULD
here, and explain the rationale, and in particular say that it might be
relaxed only if a consuming application can perform X.509/PKIX path
validation).

Dave.

---

From: Dave Cridland <[email-masked]>
Date: Tue, 30 Sep 2014 20:53:36 +0100

On 30 September 2014 20:37, John Bradley <[email-masked]> wrote:

> I agree, the likelihood of the application correctly walking the path and
> validating the chain is very small.
>
>
I think the likelihood of the application being *able* to is small given
the scope - however if it can, we should assume that it will.

> I strongly prefer leaving it a MUST use TLS and validate the server per
> RFC 6125.
>
> The other thing to note is that the CN of the cert is not in the header.
> If TLS is not used an attacker could simply modify the DNS to retrieve any
> valid certificate and use that to sign.
>
>
Whilst I agree there's a range of attacks possible against non-validating
clients - although "the CN of the cert" sets my teeth on edge - an attacker
cannot do these if the application performs path validation and checks the
key matches.

"SHOULD" and "MUST" are not a stick to beat the unthinking implementer, and
if there exist perfectly reasonable cases where this particular MUST can be
ignored, then by insisting on a MUST here we are simply weakening the
emphasis that all other RFC 2119 language has in this document.

"MUST unless you do X" is a compromise I'd be happy with, although that is
basically what "SHOULD" means.

Certainly this does require the rationale be documented in any case.

Dave.

---

From: Mike Jones <[email-masked]>
Date: Tue, 30 Sep 2014 20:58:48 +0000

John, to move this discussion along on a concrete basis, as an expert in the subject matter, could you write a proposed security considerations subsection that explains the conditions under which an exception to the MUST would be OK?  Then we could evaluate in a concrete way whether we think the specification is better with language like "MUST use TLS unless the conditions described in Section X.Y are met" or better just requiring TLS to keep things simple.

It would be good if you also expanded on the trust model comments you made earlier in the thread and that we discussed on the phone.

                                                                Thanks much,
                                                                -- Mike

From: jose [mailto:[email-masked]] On Behalf Of John Bradley
Sent: Tuesday, September 30, 2014 1:15 PM
To: Dave Cridland
Cc: IETF; IETF Gen-ART; Russ Housley; Mike Jones; [email-masked]; [email-masked]
Subject: Re: [jose] Gen-ART review of draft-ietf-jose-json-web-signature-33

The attack is not possible if the receiver validates the host from the x5u against the certificate CN and validates the path,  otherwise any valid certificate would work, as long as it chains to a valid root.

Yes we could explain that that the client could limit itself to a specific root or bridge and use the CN or DN for the identity of the signer.

So yes it is possible to make an exception to the MUST but explaining how to do that safely is not trivial, and may cause more harm than good.

John B.
On Sep 30, 2014, at 4:53 PM, Dave Cridland <[email-masked]<mailto:[email-masked]>> wrote:

On 30 September 2014 20:37, John Bradley <[email-masked]<mailto:[email-masked]>> wrote:
I agree, the likelihood of the application correctly walking the path and validating the chain is very small.

I think the likelihood of the application being *able* to is small given the scope - however if it can, we should assume that it will.

I strongly prefer leaving it a MUST use TLS and validate the server per RFC 6125.

The other thing to note is that the CN of the cert is not in the header.  If TLS is not used an attacker could simply modify the DNS to retrieve any valid certificate and use that to sign.

Whilst I agree there's a range of attacks possible against non-validating clients - although "the CN of the cert" sets my teeth on edge - an attacker cannot do these if the application performs path validation and checks the key matches.

"SHOULD" and "MUST" are not a stick to beat the unthinking implementer, and if there exist perfectly reasonable cases where this particular MUST can be ignored, then by insisting on a MUST here we are simply weakening the emphasis that all other RFC 2119 language has in this document.

"MUST unless you do X" is a compromise I'd be happy with, although that is basically what "SHOULD" means.

Dave.