Subject: [OAUTH-WG] Barry Leiba's Yes on draft-ietf-oauth-jwt-bcp-06: (with COMMENT)

From: Barry Leiba via Datatracker <[email-masked]>
Date: Mon, 24 Jun 2019 01:50:17 -0700

Barry Leiba has entered the following ballot position for
draft-ietf-oauth-jwt-bcp-06: Yes

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 https://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:
https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Nice work on this; thanks.

-- Section 1 --

   Readers are advised to seek out any errata or updates that apply to this
   document.

Excellent.  I note that this is a really nice opportunity to include, here, a
URI to a page in the working group wiki or github that you can now create and
that will be used to post updates (that might not qualify as errata) before
they're incorporated into published updates.

Other than that,  I just have some editorial comments:

-- Section 1.1 --

   -  Implementers of JWT libraries (and the JWS and JWE libraries used
      by them),

Nit: Does "them" refer to the implementers or the libraries?  Please re-phrase
to clarify.

-- Section 2.4 --

Nit: "and thus, the ciphertext, depends" should be "and, thus, the ciphertext
depend" (note moved comma and plural verb).

-- Section 2.6 --

Nit: "However older implementations" needs a comma: "However, older
implementations"

-- Section 2.7 --
I find the paragraph to be somewhat awkward, and suggest a slight rewording,
thus:

NEW
There are attacks in which one recipient will be given a JWT that was intended
for it, and will attempt to use it at a different recipient for which that JWT
was not intended.  For instance, if an OAuth 2.0 [RFC6749] access token is
legitimately presented to an OAuth 2.0 protected resource which it is intended,
that protected resource might then present that same access token to different
protected resource for which the access token is not intended, in an attempt to
gain access.  If such situations are not caught, this can result in the
attacker gaining access to resources that it is not entitled to access. END

As to the title of this section, this doesn't seem to be a "substitution".  I'm
not sure what to call it (maybe it's a form of replay attack, but maybe not
really), but "substitution" doesn't seem right.

-- Section 2.9 --

Nit: In "operations, e.g. database and LDAP searches," you need a comma after
"e.g."  Or, better still, just change "e.g." to "such as", and avoid the Latin.

-- Section 3.4 --

Nit: "(see e.g.  [Valenta], Sec. 7.1)" needs commas: "(see, e.g.,  [Valenta],
Sec. 7.1)"  And in the next sentence, because of the "or both!" at the end I
would remove the "Either" at the beginning.

-- Section 3.6 --

   It is RECOMMENDED to avoid any compression of data before encryption
   since such compression often reveals information about the plaintext.

The passive voice doesn't work in this construct; "it is recommended to avoid"
doesn't seem like proper English.  Also, it's not the compression that reveals
information, but the resultant compressed data, right?  How about this?:

NEW
   Compression of data SHOULD NOT be done before encryption, because
   such compressed data often reveals information about the plaintext.
END

-- Section 3.11 --

   Confusion of one kind of JWT for another can be prevented by having
   all the kinds of JWTs that could otherwise potentially be confused
   include an explicit JWT type value and include checking the type
   value in their validation rules.

I find the sentence awkward, and suggest a slight rewrite:

NEW
   Sometimes, one kind of JWT can be confused for another.  If a particular
   kind of JWT is subject to such confusion, that JWP can include an explicit
   JWT type value, and the validation rules can specify checking the type.
   This mechanism can prevent such confusion.
END