Subject: [OAUTH-WG] Adam Roach's Discuss on draft-ietf-oauth-jwt-bcp-06: (with DISCUSS and COMMENT)

From: Adam Roach via Datatracker <[email-masked]>
Date: Mon, 24 Jun 2019 22:04:47 -0700

Adam Roach has entered the following ballot position for
draft-ietf-oauth-jwt-bcp-06: 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 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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for everyone who worked to get this document out the door. I found it to
be well-organized and easy to read.

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

This is a process discuss for Roman to handle, and I plan to clear it
during the IESG formal telechat.

This document is intended for BCP status. It has a normative reference to RFC
8017, which is an informational document. Checking the last call text
(https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-bcp/edit/lastcalltext/),
there is no mention of RFC 8017, nor does RFC 8017 appear in the downref
registry (https://datatracker.ietf.org/doc/downref/).

Thanks to RFC 8067, we are not required to run this document through IETF LC
again (and, given that RFC 8017's predecessor, RFC 3447, is in the registry,
we probably don't want to). However, we'll need to minute that the point was
raised and addressed. There is also at least one additional requirement
imposed by section 2 of RFC 8067 that needs to be satisfied (see the last
sentence in that section).

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

§3.2:

>  That said, if a JWT is cryptographically protected by a transport
>  layer, such as TLS using cryptographically current algorithms, there
>  may be no need to apply another layer of cryptographic protections to
>  the JWT.

It may be helpful to distinguish between end-to-end TLS encryption (such as that
seen in HTTPS, even in the presence of proxies) and hop-by-hop TLS encryption
(such as that seen in SIPS when proxies are present). In the latter case,
intermediaries may perform attacks that would otherwise only be possible to
mount by the endpoints.

My concrete suggestion is to modify the above text to read "...protected
end-to-end by a transport layer, such as..."

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

§3.2:

>  -  Avoid all RSA-PKCS1 v1.5 [RFC2313] encryption algorithms,
>     preferring RSA-OAEP ([RFC8017], Sec. 7.1).

It's not clear to me what this recommendation intends to say regarding the
algorithms in RFC 2437 and RFC 3447. One might infer that they're deprecated
as well. If this is the intention, please be explicit.

---

From: Roman Danyliw <[email-masked]>
Date: Tue, 25 Jun 2019 13:38:54 +0000

> -----Original Message-----
> From: iesg [mailto:[email-masked]] On Behalf Of Adam Roach via
> Datatracker
> Sent: Tuesday, June 25, 2019 1:05 AM
> To: The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; oauth-
> [email-masked]; [email-masked]
> Subject: Adam Roach's Discuss on draft-ietf-oauth-jwt-bcp-06: (with DISCUSS
> and COMMENT)
> 
> 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.)
> 
> 
> Thanks for everyone who worked to get this document out the door. I found
> it to be well-organized and easy to read.
> 
> This is a process discuss for Roman to handle, and I plan to clear it during the
> IESG formal telechat.
> 
> This document is intended for BCP status. It has a normative reference to
> RFC 8017, which is an informational document. Checking the last call text
> Thanks to RFC 8067, we are not required to run this document through IETF
> LC again (and, given that RFC 8017's predecessor, RFC 3447, is in the registry,
> we probably don't want to). However, we'll need to minute that the point
> was raised and addressed. There is also at least one additional requirement

Good catch.  This is my fault.  The caution of the downref was in the shepherd write-up (thanks Hannes).

I share your view that since RFC8017 (not in downref registry but referenced here) obsoletes RFC3447 (in the downref registry), we don't need to re-run the LC (per Section 2 of RFC8067).  Is there concern with this course of action?

Roman

> It may be helpful to distinguish between end-to-end TLS encryption (such as
> that seen in HTTPS, even in the presence of proxies) and hop-by-hop TLS
> encryption (such as that seen in SIPS when proxies are present). In the latter
> case, intermediaries may perform attacks that would otherwise only be
> possible to mount by the endpoints.
>