Subject: [Gen-art] GEN-ART LC review of draft-farrell-perpass-attack-03

From: Scott Brim <[email-masked]>
Date: Sat, 28 Dec 2013 17:01:32 -0500

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

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