Re: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-algorithms-33: (with DISCUSS and COMMENT)

Richard Barnes <rlb@ipv.sx> Fri, 10 October 2014 21:58 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: jose@ietfa.amsl.com
Delivered-To: jose@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF861AD418 for <jose@ietfa.amsl.com>; Fri, 10 Oct 2014 14:58:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ks04EmM7KX7g for <jose@ietfa.amsl.com>; Fri, 10 Oct 2014 14:58:09 -0700 (PDT)
Received: from mail-vc0-f177.google.com (mail-vc0-f177.google.com [209.85.220.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80F8D1A8855 for <jose@ietf.org>; Fri, 10 Oct 2014 14:58:09 -0700 (PDT)
Received: by mail-vc0-f177.google.com with SMTP id hq11so3328350vcb.8 for <jose@ietf.org>; Fri, 10 Oct 2014 14:58:08 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Rtbtw8IjBIZvsPuBsxUTWWZS9u5WICxMcyIdYMT+DtY=; b=IHNsdlz9ixCt0Uxn0KGG/P+hXr8iUsCms0WiVTC/8erCF82+HgkG1D1/k7FGaf7uFI nYCRbPgoITFkOjV7C4wvG8DnFqG5oYGrGSHHM4Ior+MLNuIcJHwYPXgr0RgeEve9+B7t ZxyRAeeWI52zZNCVDpguwaaiO1k1Oz+4KGX9xctTEPrudZtqihJwxvE9DuAm33G7Il0M ZKD4kIjJpWiIZD/5oBHV++NqnY1w64Tvk4XePHR7FI3lWPqVz2pWeJljeZqfFxi3e41m 19uuf1uUx/142ie4yxa650PmFO4q2BwJDS4qT5E/uyR9QhEJgVLek0szsJJio6/iaCor XxLg==
X-Gm-Message-State: ALoCoQkMaEVpfTwILTUi2n4Fjk4KNyP4hREk7SU/qNHYZdE8p5GzHzgsA9Todl8n3PRmx6P8rvcO
MIME-Version: 1.0
X-Received: by 10.220.213.199 with SMTP id gx7mr8199656vcb.20.1412978288591; Fri, 10 Oct 2014 14:58:08 -0700 (PDT)
Received: by 10.31.134.17 with HTTP; Fri, 10 Oct 2014 14:58:08 -0700 (PDT)
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BAF0C49@TK5EX14MBXC286.redmond.corp.microsoft.com>
References: <20141002023617.18602.69709.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAF0C49@TK5EX14MBXC286.redmond.corp.microsoft.com>
Date: Fri, 10 Oct 2014 17:58:08 -0400
Message-ID: <CAL02cgR6zHZpDHFwdZHvNd7+wHMwraqCtFz-u=Y3Ogfm9M6n3A@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Mike Jones <Michael.Jones@microsoft.com>
Content-Type: multipart/alternative; boundary="089e0112c12af79eba050518a403"
Archived-At: http://mailarchive.ietf.org/arch/msg/jose/siVlyEg1MGM9ikVL8zBZKp3_6QE
Cc: "jose-chairs@tools.ietf.org" <jose-chairs@tools.ietf.org>, "jose@ietf.org" <jose@ietf.org>, The IESG <iesg@ietf.org>, "draft-ietf-jose-json-web-algorithms@tools.ietf.org" <draft-ietf-jose-json-web-algorithms@tools.ietf.org>
Subject: Re: [jose] Richard Barnes' Discuss on draft-ietf-jose-json-web-algorithms-33: (with DISCUSS and COMMENT)
X-BeenThere: jose@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Javascript Object Signing and Encryption <jose.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jose>, <mailto:jose-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/jose/>
List-Post: <mailto:jose@ietf.org>
List-Help: <mailto:jose-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jose>, <mailto:jose-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Oct 2014 21:58:13 -0000

On Mon, Oct 6, 2014 at 3:54 AM, Mike Jones <Michael.Jones@microsoft.com>
wrote:

> Thanks for your review, Richard.  Replies are inline below...
>
> > -----Original Message-----
> > From: jose [mailto:jose-bounces@ietf.org] On Behalf Of Richard Barnes
> > Sent: Wednesday, October 01, 2014 7:36 PM
> > To: The IESG
> > Cc: jose-chairs@tools.ietf.org; draft-ietf-jose-json-web-
> > algorithms@tools.ietf.org; jose@ietf.org
> > Subject: [jose] Richard Barnes' Discuss on
> draft-ietf-jose-json-web-algorithms-
> > 33: (with DISCUSS and COMMENT)
> >
> > Richard Barnes has entered the following ballot position for
> > draft-ietf-jose-json-web-algorithms-33: Discuss
> >
> > When responding, please keep the subject line intact and reply to all
> email
> > addresses included in the To and CC lines. (Feel free to cut this
> introductory
> > paragraph, however.)
> >
> >
> > Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
> > for more information about IESG DISCUSS and COMMENT positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > http://datatracker.ietf.org/doc/draft-ietf-jose-json-web-algorithms/
> >
> >
> >
> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > Section 3.2.
> > "This computed HMAC value is then compared to the result of base64url
> > decoding the received encoded JWS Signature value."
> > Need to add:
> > "In order to avoid timing attacks, the comparison of the computed HMAC
> value
> > to the JWS Signature value MUST be done in a constant-time manner."
>
> OK
>
> > Section 3.6.
> > I'm not going to object to "none", even though I think it's a very
> dangerous
> > feature because of the risk of confusion between Secured and Unsecured
> JWS.
> > But there needs to be stronger guidance:
> > 1. An implementation SHOULD NOT support "none" unless the implementor
> > knows that it will be used in application context s that require it.
> > 2. If an implementation does support "none", then it MUST NOT accept it
> as part
> > of generic JWS validation.  Instead, it should require the application
> to explicitly
> > signal that an Unsecured JWS is expected for a given validation
> operation.
>
> As discussed in the working group, your concern about applications
> inappropriately allowing the use of "none" actually is an instance of a
> more general concern that applications not allow *any* algorithms to be
> used that are not appropriate in their application contexts.  This concern
> is already addressed in the specification at the end of Section 5.2 as
> follows:
>
> "Finally, note that it is an application decision which algorithms are
> acceptable in a given context. Even if a JWS can be successfully validated,
> unless the algorithm(s) used in the JWS are acceptable to the application,
> it SHOULD reject the JWS."
>
> Since your specific concern is already handled in a more general way, I
> would like to request that you withdraw this DISCUSS on that basis.  Also,
> you were one of the contributing authors to the security considerations on
> this topic in Section 8.5 of JWA (Unsecured JWS Security Considerations),
> so it's not clear that there's any cause for you to come back with
> additional wording change requests on this topic at this point.
>

Thanks for reminding me about Section 8.5.  I think I would be satisfied
here if the contents of Section 8.5 were just moved up to this section.
That way all of the requirements for implementing "none" will be together.



> > Section 4.2.
> > Systems that support RSAES-PKCS1-V1_5 key unwrap are commonly vulnerable
> > to oracle attacks based on whether they accept the wrapped key or not.
> > See, e.g.,
> > https://www.w3.org/Bugs/Public/show_bug.cgi?id=25431
> > http://cryptosense.com/choice-of-algorithms-in-the-w3c-crypto-api/
> > In light of that, it seems irresponsible to include this algorithm
> without extensive
> > security precautions, and especially irresponsible for it to be
> REQUIRED.  It's
> > been dropped from WebCrypto, and is being dropped from TLS in v1.3.
>
> The reasons for its inclusion and security considerations about it are
> already covered in Section 8.3 of JWA (RSAES-PKCS1-v1_5 Security
> Considerations).  If you'd like to beef up the text there, specific
> additional proposed wording would be welcomed.  It's required because it's
> the one asymmetric key encryption algorithm that appeared to be
> ubiquitously deployed across development platforms.  Otherwise, there would
> be no practical basis for interoperability for this functionality.
>

Thanks for the pointer to 8.3.  I had missed that.  That helps, but doesn't
resolve the issue.

My concern here is that by having RSAES-PKCS1-v1_5 as a REQUIRED algorithm,
we will encourage the creation of more vulnerable stacks, and extend the
life of those that already exist.  (Note that this is independent of the
guidance in RFC 3447.)  Could we compromise on moving the requirement level
for this algorithm to OPTIONAL, and promoting OAEP to REQUIRED?




> > Section 6.3.1.
> > The descriptions of these parameters are really vague, especially when
> it comes
> > to the "oth" parameters.  Please cite a reference that provides more
> detail, e.g.,
> > RFC 3447.
>
> I agree that an RFC 3447 reference would be appropriate.
>
> > Section 6.3.2.6.
> > This section defines the wrong parameter.
>
> Thanks!
>

Cool.  I'll clear these points when the updated draft is posted.



> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Section 1.1.
> > The pointer for BASE64URL should be to JWS.  One level of indirection,
> please :)
>
> Agreed
>
> > Section 3.1, 4.1, and 5.1.
> > As I said in the working group, the implementation requirements in these
> > registries should be removed.  They are unnecessary for
> interoperability, and
> > highly likely to be ignored by implementors, both because (1) many
> > implementations are for specific applications that do not require all of
> the
> > REQUIRED algorithms, and (2) many implementations use cryptographic
> libraries
> > that do not support some REQUIRED algorithms.  I have personally written
> more
> > than one JWS/JWE implementation that ignored these requirements, for
> exactly
> > these reasons.  (This would be a DISCUSS for me, if not for my having
> made this
> > argument already in the WG.)
>
> For what it's worth, apparently Stephen Farrell disagrees with you (as do
> many in the working group).
> > Section 3.2.
> > "A key of the same size as the hash output (for instance, 256 bits for
> > "HS256") or larger MUST be used with this algorithm."
> > A pointer to Section 3 of RFC 2104 here would be helpful.  I was
> surprised at this
> > requirement, given that FIPS 198 says "The size of the key, K, shall be
> equal to or
> > greater than L/2, where L is the size of the hash function output."
>
> The thread with Jim Schaad on this topic concluded as follows:
>
> [JLS] This does not seem to be the statement in sp800-107 rev1 (section
> 5.3.4) which updated FIPS 198.   It says that the security = min (length of
> K, 2*C) where C is the internal barrel length.
>
> Ah, OK.  Thanks for the updated reference.  I stand corrected.
> --Richard
>
> > Section 3.4.
> > It might be worth noting that though this format seems ad-hoc, it is the
> same
> > used by WebCrypto.
>
> I'll think about if there's a non-intrusive way to add this.  Are there
> other places also using this representation?  I'd thought that there were.
>

I was going to say that this is how some libraries do it, but
unfortunately, that doesn't appear to be true of either of the libraries I
checked, NSS and OpenSSL.  NSS uses a DER form, and OpenSSL uses a struct
with two integers.



> > Section 4.7.1.1.
> > Shouldn't you require that this field MUST encode a 16-octet / 128-bit
> value?
>
> Actually, 4.7 already states "Use of an Initialization Vector of size 96
> bits is REQUIRED with this algorithm."  (See the GCM spec for why.)  But I
> could add "96 bit" to the description.
>

Good catch.  Seems like the extra mention wouldn't hurt.

--Richard



> > _______________________________________________
> > jose mailing list
> > jose@ietf.org
> > https://www.ietf.org/mailman/listinfo/jose
>
>                                 Thanks again,
>                                 -- Mike
>
>