[secdir] secdir review of draft-ietf-jose-jws-signing-input-options-06

Benjamin Kaduk <kaduk@MIT.EDU> Fri, 11 December 2015 18:04 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id CAFA71A6F1D; Fri, 11 Dec 2015 10:04:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id kAsWJI5EQPbO; Fri, 11 Dec 2015 10:04:54 -0800 (PST)
Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C50121A9007; Fri, 11 Dec 2015 10:04:53 -0800 (PST)
X-AuditID: 1209190d-f79306d000006b70-72-566b104440c8
Received: from mailhub-auth-4.mit.edu ( []) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id FF.BF.27504.4401B665; Fri, 11 Dec 2015 13:04:52 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu []) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id tBBI4pYb030218; Fri, 11 Dec 2015 13:04:51 -0500
Received: from multics.mit.edu (system-low-sipb.mit.edu []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id tBBI4mQY014884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 11 Dec 2015 13:04:51 -0500
Received: (from kaduk@localhost) by multics.mit.edu ( id tBBI4l8o026655; Fri, 11 Dec 2015 13:04:47 -0500 (EST)
Date: Fri, 11 Dec 2015 13:04:47 -0500 (EST)
From: Benjamin Kaduk <kaduk@MIT.EDU>
To: iesg@ietf.org, secdir@ietf.org, draft-ietf-jose-jws-signing-input-options.all@ietf.org
Message-ID: <alpine.GSO.1.10.1512111248420.26829@multics.mit.edu>
User-Agent: Alpine 1.10 (GSO 962 2008-03-14)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJIsWRmVeSWpSXmKPExsUixG6nrusikB1m0PVSymJ6620Wixl/JjJb fFj4kMWB2WPJkp9MAYxRXDYpqTmZZalF+nYJXBl9U24yFmwRq1iyYzVbA+MkoS5GTg4JAROJ ljmvWCBsMYkL99azgdhCAouZJI5d9e9i5AKyNzJKnJi0kwXCOcQk8WNSAxOE08Ao8fvAc2aQ FhYBbYl5D38xgdhsAioSM99sBBslIpAs8ebfJXYQW1jATWLmq1eMIDavgKPE6yVrWEFsUQEd idX7p7BAxAUlTs58AmYzC2hJLJ++jWUCI98sJKlZSFILGJlWMcqm5Fbp5iZm5hSnJusWJyfm 5aUW6Rrp5WaW6KWmlG5iBIUYpyTvDsZ3B5UOMQpwMCrx8C7gyAoTYk0sK67MPcQoycGkJMrr w5cdJsSXlJ9SmZFYnBFfVJqTWnyIUYKDWUmEt+Q5UDlvSmJlVWpRPkxKmoNFSZx37hffMCGB 9MSS1OzU1ILUIpisDAeHkgTvApChgkWp6akVaZk5JQhpJg5OkOE8QMOtQWp4iwsSc4sz0yHy pxgVpcR5t4MkBEASGaV5cL3gFLCbSfUVozjQK8K8a0CqeIDpA677FdBgJqDBX66kgwwuSURI STUwZuqvKl31KfDU9cAW+wyWnz8+5s7mcTl75if7fa85jAf3lusxOOz84RJukSXXcnvl/IbL Erk3L1/kjj5ovtTpRBPL0U9XSlxrU/s0npr0pE1PKCyoNJBy0ntUZLzFoFjWYPGmT7E/zQqr jzsHv0llNvzU++9S65eNrLOTYv/4rPvlFRW1ev9eJZbijERDLeai4kQA+lhAzdwCAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/_FyqAJ5XD2x5JzDeGqsa4Pj6rOA>
Subject: [secdir] secdir review of draft-ietf-jose-jws-signing-input-options-06
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Dec 2015 18:04:56 -0000

Hi all,

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.

This document is Ready.

The main JWS spec (RFC 7515) required that the signed payload was
base64url-encoded prior to signing.  This results in a noticeable size
expansion; in some circumstances it is desirable to avoid this expansion
and reencoding.  I did not follow the JWS document closely at the time,
but I believe this issue was raised at the time and consensus reached on
the published version because it is always safe for applications to use.
This document provides an opt-in mechanism for application (protocol)s to
avoid the extra encoding and expansion, leaving the burden on the
application to determine whether it is safe to do so and perform the
relevant input checking/sanitization.  The security considerations
correctly describe the implications of the loss of encoding and the
restrictions on the signed content when detached payloads are not used,
interoperability concerns for applications not supporting the b64 header
parameter, and proposes appropriate countermeasures.

Interestingly, this document does not need to update the JWS spec, since
it is just adding to an IANA registry and not modifying the core spec, but
it does update the JWT spec (RFC 7519) to prohibit the use of b64=false in
JWTs.  No justification is made for this restriction in the text of the
document, but it seems reasonable to "play it safe" in this sense, to me.

I do have a few nits unrelated to the security review:

The abstract mentions the "Updates: 7519", but the introduction does not;
I am sometimes told that both locations should mention the update, but I
assume that the RFC Editor will notice if anything needs to change.

It is a bit amusing that the example with payload "$.02" is actually
longer with the unencoded payload, due to the overhead of the header
field, but I do not suggest modifying the example at this time.

Section 5.3 makes reference to Section 8.3 of RFC 7159 for JSON
string-escape processing, but I think perhaps section 7 of that RFC would
be a better reference.

Relatedly, I needed to reread the text in Section 5.3 a few times in order
to convince myself that I correctly understood the procedure for
generating the payload to be signed, but I believe that all the steps
given are necessary and correct, and do not have proposed text that would
be better.  String-escape processing is just inherently fiddly.

I did not attempt to verify the examples' encoding and consistency.

Thanks for this well-written document.