Last Call Review of draft-ietf-jose-jws-signing-input-options-06

Request Review of draft-ietf-jose-jws-signing-input-options
Requested rev. no specific revision (document currently at 09)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-12-15
Requested 2015-11-29
Authors Michael Jones
Draft last updated 2015-12-22
Completed reviews Genart Last Call review of -06 by Robert Sparks (diff)
Genart Last Call review of -06 by Robert Sparks (diff)
Secdir Last Call review of -06 by Benjamin Kaduk (diff)
Opsdir Last Call review of -06 by Stefan Winter (diff)
Assignment Reviewer Stefan Winter
State Completed
Review review-ietf-jose-jws-signing-input-options-06-opsdir-lc-winter-2015-12-22
Reviewed rev. 06 (document currently at 09)
Review result Has Issues
Review completed: 2015-12-22



I have reviewed this document as part of the Operational directorate's
ongoing effort to review all IETF documents being processed by the IESG.
 These comments were written with the intent of improving the
operational aspects of the IETF drafts. Comments that are not addressed
in last call may be included in AD reviews during the IESG review.
Document editors and WG chairs should treat these comments just like any
other last call comments.

Summary: Ready with issues

Major issues:


Minor issues:

There are coexistence issues between implementations which understand
the notion of the "b64" parameter (i.e. implementing this RFC) and those
who do not (i.e. all existing JWS implementations).
The issues are discussed in Security Considerations (second para up
until the end). The issues with it are:

* the conclusions are not as satisfactory as they could be.
Interoperability is either

 - left as an out-of-band and undescribed mechanism ("make sure that
only supporting implementations talk to each other")
 - by explicitly marking support for b64 as critical (IMO the only good
 - modifying the payload so that it contains unparseable characters
(which may or may not be possible for the sender depending on the
payload characteristics)

* this is placed in Security Considerations while it has actual
operational impact on every transmitted message: in essence it states:
"Sometimes, sender and recipient may misunderstand each other without
noticing". Example given in the draft where the actual message is "NDA1"
while the recipient thinks it was told "405", without a way to notice.
Even if the misunderstanding is not related to security, it can/will
have significant implications for the application.

I believe this can not be left as-is. Luckily, there seems to be an easy
way out:

"Whenever the 'b64' header exists and is set to false, the 'crit' header
MUST also be present and contain 'b64'."

This, maybe in conjunction with

"When the content is intended to be base64 encoded, the 'b64' header
SHOULD NOT be present."

This would make sure that implementations who know nothing of b64 are
left alone (there is no unknown extension, there is no criticality in
any such extension, and the sender did not intend to make use of the
feature => all good). While at the same time for unencoded payloads
making deterministically clear that unencoded transmission is happening,
and is required to be understood.

This would at the same time make a complex piece of Sec Con go away.


Stefan Winter

Ingenieur de Recherche
Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et
de la Recherche
2, avenue de l'Université
L-4365 Esch-sur-Alzette

Tel: +352 424409 1
Fax: +352 422473

PGP key updated to 4096 Bit RSA - I will encrypt all mails if the
recipient's key is known to me








 OpenPGP digital signature