Skip to main content

Last Call Review of draft-farrell-perpass-attack-03

Request Review of draft-farrell-perpass-attack
Requested revision No specific revision (document currently at 06)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-12-31
Requested 2013-12-05
Authors Stephen Farrell , Hannes Tschofenig
I-D last updated 2014-01-02
Completed reviews Genart Last Call review of -03 by Scott W. Brim (diff)
Genart Last Call review of -04 by Scott W. Brim (diff)
Genart Telechat review of -05 by Scott W. Brim (diff)
Secdir Last Call review of -02 by Adam W. Montville (diff)
Opsdir Last Call review of -03 by Dan Romascanu (diff)
Assignment Reviewer Scott W. Brim
State Completed
Review review-farrell-perpass-attack-03-genart-lc-brim-2014-01-02
Reviewed revision 03 (document currently at 06)
Result Ready with Nits
Completed 2014-01-02
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at


Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-farrell-perpass-attack-03
Reviewer: Scott Brim
Review Date: 2013-12-28
IETF LC End Date: 2013-12-31
IESG Telechat date: 2014-01-23

Summary: Ready for BCP, with one minor issue and some nits

Major issues:

Minor issues:

  We've spent a lot of time on this draft and it looks good. I have one
  remaining minor issue:

  > Participants at that meeting
  > therefore expressed strong agreement that this was an attack that

  This is inconsistent with later text that says some monitoring is not an
  attack. To avoid inconsistency, I suggest adding a few words, e.g.:
  "this can only be treated as an attack", or "this should be treated as
  an attack" instead of just "this was an attack".

Nits/editorial comments:

  > protocol meta-data such as headers

  I've never seen metadata hyphenated before. Please fix.

  > The same techniques can be used
  > regardless of motivation and we cannot defend against the most
  > nefarious actors while allowing monitoring by other actors no matter
  > how benevolent some might consider them to be

  In order to make the justification clear, I suggest

    (1) change "can be used" to "are used" -- they already are, and
    that's significant.

    (2) In the middle, add another justifying clause: "motivation, and
    since we cannot distinguish motive, we cannot defend" ...

  > Protocols that mitigate
  > pervasive monitoring will not prevent the attack

  Add "necessarily": ... not necessarily prevent ...

  > It is nonetheless timely to revisit the security of our standards.

  s/nonetheless/thus/ since you gave the justifications above.
  "Nonetheless" doesn't make sense here.

  > monitoring in the case of Certificate Transparency.  [RFC6962] There

  Reference is in the wrong place.

Thanks for all the work ... Scott