---------- Forwarded message ----------
From: "Scott Brim" <scott.brim@xxxxxxxxx>
Date: Dec 28, 2013 5:01 PM
Subject: GEN-ART LC review of draft-farrell-perpass-attack-03
To: "gen-art" <gen-art@xxxxxxxx>, <draft-farrell-perpass-attack.all@xxxxxxxxxxxxxx>
Cc:
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
From: "Scott Brim" <scott.brim@xxxxxxxxx>
Date: Dec 28, 2013 5:01 PM
Subject: GEN-ART LC review of draft-farrell-perpass-attack-03
To: "gen-art" <gen-art@xxxxxxxx>, <draft-farrell-perpass-attack.all@xxxxxxxxxxxxxx>
Cc:
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