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

Richard Barnes <rlb@ipv.sx> Sat, 18 October 2014 18:18 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 7B65F1A8A50 for <jose@ietfa.amsl.com>; Sat, 18 Oct 2014 11:18:30 -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=ham
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 a_-ajy4qS5nF for <jose@ietfa.amsl.com>; Sat, 18 Oct 2014 11:18:26 -0700 (PDT)
Received: from mail-vc0-f181.google.com (mail-vc0-f181.google.com [209.85.220.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07FE81A8A4A for <jose@ietf.org>; Sat, 18 Oct 2014 11:18:25 -0700 (PDT)
Received: by mail-vc0-f181.google.com with SMTP id le20so1957567vcb.12 for <jose@ietf.org>; Sat, 18 Oct 2014 11:18:25 -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=YOStF996VMpvU9M2r1DaPh+9ZwOZQDQM9NH8/uXmyAk=; b=lNGzW+OTW9apvSmUotB+lX2el1a0lHY8h/a4hj7RKSbO4YPjRXSEij8E/OGEJcR49q 71Vlc/NiAkiWDD6QBe+qx7atAJqfmRs3GX+cABCqVQbahNZ83ZpMPd/gT3Lc8O1dr8Bj ZImp962OMo+4kfh1etvDQxfsfcS1m9IKTJVH5y6Qq9LZn84t/cOiYMpgQuIGVHcBEjN9 8EyENM86qcL6hXZkBcm6DVzCpzj1+R0HLaLbtn7Jxy+5BtCgAHTN4wVj+UOe4eEG7EC8 j/vwfou8XKz7IUR0k6se6FoG3fQR8UiqRgmUqyQyqjm8+qlC97rc7ge0mPKHZguzHt0h QdeA==
X-Gm-Message-State: ALoCoQlSdY7SfutVn9bU10/xM19cKfAo2P6X4N78kzP0JjA8Rrk5rV9SBNvL0ZAz3JHvulwWpa1z
MIME-Version: 1.0
X-Received: by 10.220.179.135 with SMTP id bq7mr13944094vcb.15.1413656305050; Sat, 18 Oct 2014 11:18:25 -0700 (PDT)
Received: by 10.31.149.205 with HTTP; Sat, 18 Oct 2014 11:18:24 -0700 (PDT)
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439BAFACA8@TK5EX14MBXC286.redmond.corp.microsoft.com>
References: <20141002023617.18602.69709.idtracker@ietfa.amsl.com> <4E1F6AAD24975D4BA5B16804296739439BAF0C49@TK5EX14MBXC286.redmond.corp.microsoft.com> <CAL02cgR6zHZpDHFwdZHvNd7+wHMwraqCtFz-u=Y3Ogfm9M6n3A@mail.gmail.com> <4E1F6AAD24975D4BA5B16804296739439BAFACA8@TK5EX14MBXC286.redmond.corp.microsoft.com>
Date: Sat, 18 Oct 2014 11:18:24 -0700
Message-ID: <CAL02cgQD2X_ig_JOjW=MZ+jqeditrzm1kb2p+-U8HoiXUGtNoQ@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Mike Jones <Michael.Jones@microsoft.com>
Content-Type: multipart/alternative; boundary=089e013a0834e5bdde0505b68151
Archived-At: http://mailarchive.ietf.org/arch/msg/jose/4VT96BQ5yaOG_dkYVf4oI2kYJlU
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: Sat, 18 Oct 2014 18:18:30 -0000

On Sat, Oct 11, 2014 at 1:23 PM, Mike Jones <Michael.Jones@microsoft.com>
wrote:

> > From: Richard Barnes [mailto:rlb@ipv.sx]
> > Sent: Friday, October 10, 2014 2:58 PM
> > To: Mike Jones
> > Cc: The IESG; jose-chairs@tools.ietf.org;
> draft-ietf-jose-json-web-algorithms@tools.ietf.org; jose@ietf.org
> > Subject: Re: [jose] Richard Barnes' Discuss on
> draft-ietf-jose-json-web-algorithms-33: (with DISCUSS and COMMENT)
> >
> > 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 implementer
> > > 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 3.6 does end with the sentence "See Section 8.5 for security
> considerations associated with using this algorithm" so implementers are
> reminded to also pay attention to the security considerations.  If we were
> to do what you requested, this would be the only algorithm for which the
> security considerations were included in the algorithm description, rather
> than in the security considerations section, which would be fairly weird
> and non-parallel, editorially.
>

Actually, "none" is the only algorithm for which there are additional
normative requirements in the Security Considerations.  So it actually
seems more sensible to move those requirements up.

I'm really just asking for a copy/paste here, shouldn't be invasive.  But I
do think the level of indirection creates security risk.



> Again, given that you were an author of 8.5 and seemed fine with the
> resolution after the extensive discussion then, I'd ask you to clear the
> DISCUSS on that basis and not request that it be reworked again.
>
> > > 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?
>
> Rather than Optional, I'd counter-propose to change it to Recommended- and
> changing OAEP to Recommended+.  It's not clear that OAEP is widely enough
> deployed yet to make it REQUIRED.  What do others in the working group
> think?
>

I can live with this.

--Richard




>
> > > 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 implementers, 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.
>
> OK - then it's not clear that there's anything else definitive to say,
> unless we want to add a note that this is the same representation used by
> WebCrypto.  Do you think that's worth adding?
>
> > > 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
>
>                                 -- Mike
>
>