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.