Skip to main content

Last Call Review of draft-levine-herkula-oneclick-04
review-levine-herkula-oneclick-04-secdir-lc-laurie-2016-09-22-00

Request Review of draft-levine-herkula-oneclick
Requested revision No specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2016-10-10
Requested 2016-09-15
Authors John R. Levine , Tobias Herkula
I-D last updated 2016-09-22
Completed reviews Genart Last Call review of -07 by Fernando Gont (diff)
Secdir Last Call review of -04 by Ben Laurie (diff)
Opsdir Last Call review of -06 by Victor Kuarsingh (diff)
Assignment Reviewer Ben Laurie
State Completed
Request Last Call review on draft-levine-herkula-oneclick by Security Area Directorate Assigned
Reviewed revision 04 (document currently at 10)
Result Has issues
Completed 2016-09-22
review-levine-herkula-oneclick-04-secdir-lc-laurie-2016-09-22-00
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.

Status: ready with issues.

Broadly speaking, all seems fine with this draft, except the advice
given for making the header non-forgeable is weak.

"The URI and POST arguments SHOULD include a hard to forge component
such as a hash in addition to or instead of the plain-text names of
the list and the subscriber."

Hashes are not inherently hard to forge, they need to be combined with
a secret of some kind. Also, using a plain hash is error-prone. So
better advice would be something along the lines of

"The URI and POST arguments SHOULD include a hard to forge component
such as an HMAC (RFC 2104) of the other components, using a secret
key, in addition to or instead of the plain-text names of the list and
the subscriber."

Although its kinda obvious, you should probably also say that the
server SHOULD verify this HMAC.

Finally, since the URI argument is the subject of an existing RFC
(2369) that RFC should probably be updated to include this advice.