ietf
[Top] [All Lists]

Re: Secdir review of draft-ietf-jose-json-web-signature-31

2014-09-12 16:52:07
On Fri, Sep 5, 2014 at 8:56 PM, Mike Jones 
<Michael(_dot_)Jones(_at_)microsoft(_dot_)com>
wrote:

 Thanks for the useful review, Tero.  I’ve cc’ed the working group to
make them aware of the contents of your review.  Also, Richard Barnes,
please see a request for a reply from you on one issue below.  Replies are
inline below…



-----Original Message-----
From: Tero Kivinen [mailto:kivinen(_at_)iki(_dot_)fi]
Sent: Thursday, September 04, 2014 5:03 AM
To: iesg(_at_)ietf(_dot_)org; secdir(_at_)ietf(_dot_)org; 
ietf(_at_)ietf(_dot_)org;
draft-ietf-jose-json-web-signature(_dot_)all(_at_)tools(_dot_)ietf(_dot_)org
Subject: Secdir review of draft-ietf-jose-json-web-signature-31



I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the IESG.
These comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.



Summary: This document has issues.



This document is part of the jose-json document set, and describres the
JSON Web Signatures.



The security considerations section includes text which says:



   The entire list of security considerations is beyond the scope of

   this document, but some significant considerations are listed here.





but also lists quite a lot of security considerations. I think the
security considerations covering this document should be in scope with the
document. Of course there are generic security considerations which might
be outside the scope of this document, but I do not think we need to
explictly mention those.



Several reviewers have objected to this sentence.  Its removal is planned.



Also, additional security considerations will be described in the process
of resolving Russ Housley’s gen-art review comments.



I have following issues about the draft:



   1) "alg" and Protected Header



   2) Hash inside "alg" and inside the signature



   3) There is no explict warning about the "alg" "none".



   4) Thumbprint formats



There is also following nit:



   5) Terminology ordering.



----------------------------------------------------------------------



1) "alg" and Protected Header



Question: Shouldn't the "alg" header parameter be protected by the
signature, i.e. wouldn't it make sense to say MUST be in the "Protected
Header"?



If it is part of the "Unprotected Header" and is not protected by the
signature, that would allow all kind of attacks, i.e. changing the "alg" to
be "none" or changing the hash algorithm of the signature.



If it should be part of the "Protected Header" then that would mean that
"Proteced Header" cannot be empty, as "alg" is mandatory header parameter,
and MUST be present.



There are several cases where the text indicates that "Protected Header"
could be empty, which would mean that "alg" could be part of the
"Unprotected Header". (Section 5.1, 4. bullet; section 7.2, "protected"
element and other places in same section). In all examples the "alg" is
always in the "Proteced Header".



I think the draft needs text saying something about the situation where
"alg" is not in "Protected Header" in the security sections section. I.e.
either say, that it has been analyzed that there is no problem even when
the "alg" is not protected, and reference to such analysis, or otherwise
add text/warning that it MUST/SHOULD be in the "Protected Header". I do not
know enough about the proposed signature algorithms to know which one is
true, especially as there might be new algorithms in the future.



Richard Barnes, do you want to answer this one?  You were the primary
advocate for allowing the algorithm to be unprotected in the JSON
Serialization.



As I recall, the motivation had to do with the fact that, by default, CMS
does not protect the algorithm (although it was later extended to enable it
to be protected).  Some others in the working group thought that having
unprotected algorithms was a bad idea, in line with your comment above.

The only need for protection of the "alg" value is to prevent algorithm
substitution attacks, as discussed in RFC 6211.
https://tools.ietf.org/html/rfc6211

These attacks are fairly limited in their applicability, since they require
that:
 * The attacker is able to compute an input that is valid for the signature
using a different, weaker algorithm
 * The attacker's input is valid according to whatever application rules
are being applied
 * A relying party will accept the weaker algorithm

Given all those criteria, it seems reasonable that some signers might
regard algorithm substitution attacks as an acceptable risk.  For example,
in an application that set explicit minimum algorithm requirements (e.g.,
SHA-3 only!), there may be no risk of a relying party accepting the weaker
algorithm.  Or the application payload might have low enough entropy that
it's impossible to find a valid forged input.

And if an application is concerned about algorithm substitution attacks, it
can protect itself by including the algorithm in the payload, as X.509 does.

I would be happy to have some advisory text in the security considerations,
but I don't think this rises to the level of SHOULD/MUST.

--Richard





--



2) Hash inside "alg" and inside the signature



Also in some cases the signature itself has the hash function stored
internally, i.e. RSASSA-PKCS1-V1_5 contains the hash function oid inside
the signature, so what should the implementation do if the "alg" parameter
outside the signature does not match the oid inside the signature? I.e the
signature using "alg" of "RS256", but inside the signature the oid is using
the "SHA1". Most crypto libraries will just take the oid from the
signature, and use that to verify the message. Adding some description what
to do in such situation would be needed.



I think there’s some confusion here, since the JWS spec does not use any
OIDs or ASN.1 for signatures.  Rather, the cryptographic operations to be
performed are fully specified by the “alg” value and the signatures are
represented as base64url encoded octet sequences representing the signature
values produced by the signature algorithms.



--



3) There is no explict warning about the "alg" "none".



In the section 5.2 it says that "at least one signature ... MUST
successfully validate", but that does not limit alg "none" out from it.
I.e. if the application policy is to "one signature needs to validate", and
it gets JWS that has "none" as one of the algorithms, then it will accept
it.



I think there should be warning here or in the security considerations
section about the "none" algorithm, especially as the algorithm itself is
defined in the different draft (perhaps just reference to the section 8.5
of the [JWA] draft).



This warning is present in the spec where the algorithm is defined –
specifically
http://tools.ietf.org/html/draft-ietf-jose-json-web-algorithms-31#section-8.5.
(Note that the working group decided to define algorithms in a separate
spec than the ones in which they are used.)



Also note that it is up to applications which algorithms are acceptable in
a given context – not just “none” but also other algorithms that might be
deprecated or inappropriate for some other reason.  Unless the signature
algorithm used is acceptable to the application, it should not accept the
JWT.



--



4) Thumbprint formats



Section 4.1.7 and 4.1.8 defines a x5t and x5t#S256 thumbprints, but those
are over the whole certificate.



With the thumbprints, it has been noted lately, that quite often it is
more useful to use the hash of the SubjectPublicKeyInfo object of the

X.509 certificate, than the full X.509 certificate. This method has been
used in the raw public key methods (draft-ietf-tls-oob-pubkey,
draft-kivinen-ipsecme-oob-pubkey), and also in the DANE (it has two options
one for the full certificate and another for the SubjectPublicKeyInfo
object of the certificate).



Using hash of the SubjectPublicKeyInfo object allows changing the
certificate without invalidiating the certificates, i.e. when changing CAs,
or switching from SHA1 to SHA2 in certificates, or just renewing the
certificate. It also allows using raw public keys which do not have defined
X.509 certificate format, but which can be converted to the
SubjectPublicKeyInfo object when calculating the thumbprints. This is very
important in the Internet of Things type of things, which might not be
using the full X.509 certificates.



This thumbprint definition matches existing practice in commonly used
software packages.  For instance, both openssl and Windows use certificate
thumbprints of this kind.



That being said, there’s nothing preventing another specification from
defining a different thumbprint calculation over the SPKI information and a
header parameter used to represent it.  The header parameters are
extensible via a registry.



--



5) Terminology ordering.



Terminology is not in any order. It would be useful to have it either in
logical order (i.e. define terms before they are used), or in alphabetical
order.



Now for example the "JWS Protected Header" is used before it is defined in
the "JWS Signature", and "Header Paramater" is between "JWS Signature" and
"JWS Protected Header", also "JWS Signature" uses both "JWS Payload" and
"JWS Protected Header", and one of those is defined before and one after
the "JWS Signature".



The terms are listed in top-down order, with related terms grouped
together.  Thus “JSON Web Signature” is first, the members that make up a
JWS object are listed together in the order that they appear in a JWS,
etc.  That being said, I’ll plan to review the orderings and make sure that
they consistently follow those ordering rules.



--

kivinen(_at_)iki(_dot_)fi



                                                                Thanks
again,

                                                                -- Mike