We reviewed ekr's and Richard's feedback; thanks for the detailed review.
For all (or nearly all) of the non-important issues we believe we can
make appropriate changes or address the concerns adequately. We're not
sending those right now, just to avoid a deluge of words and things to
review on the list.
For the important items:
IMPORTANT: I don't understand what this means from an HTTP perspective...
We believe we can explain this adequately along with the non-important items.
IMPORTANT: Neither of these mechanisms is generally usable, so I
don't think this SHOULD is reasonable...
This is a fair point. We suggest the following changes and hope they
will address this concern
Change from 'A client SHOULD perform proof fetching' to 'A client
SHOULD attempt proof fetching'
Additionally, we would integrate two new points regarding DNS:
1) The UA should first probe and learn if the network supports these DNS queries
2) If the network does not support these DNS queries then periodically
re-probe and if it does eventually support it, you can go through your
backlog.
We'd also mention the Tor option further up as it is a simple solution
from the POV of this draft, although most browsers haven't deployed it
for being a more difficult solution technically.
IMPORTANT: This seems like kind of a dealbreaker...
Yes. We think our wording is incorrect and that leads to your comment.
We would like to suggest how we would change the wording and see if
you have the same assessment.
If SCT Feedback is not deployed by a webserver, malicious logs will
be able to attack all users of the webserver (who do not have a
Trusted Auditor relationship) with impunity.
This is not true. It assumes an auditor cannot recognize a log
partition that is perpetuated by an actively malicious log. In
actuality, an auditor can (and should) be able to recognize that it
has recent STHs that can't be resolved via a consistency proof and
recognize that situation is perpetuating and is bad. If an auditor can
do that, malicious logs _can_ be detected via STH Pollination
(assuming Proof Fetching occurs) - making the document incorrect.
What is true:
If SCT Feedback is not deployed by a webserver, the webserver may
never learn that it was the target of an attack.
The auditors would learn that the log was malicious but not what
domain names it attacked.
We would change the document to reflect the true statement, and update
various mentions and phrases to adequately convey that SCT Feedback is
necessary to learn _who_ is attacked by a malicious log, but not
necessary to learn that a particular log _is_ malicious and has
performed an attack so long as STH Pollination and Proof Fetching
occurs.
IMPORTANT: This algorithm does not terminate...
IMPORTANT: state that rand() has to be a CSPRNG.
You're correct, we can fix these easily enough.
IMPORTANT: This algorithm has terrible performance...
Also correct. We'd be happy to review a suggestion that improves
performance, but I'm nervous about shuffling algorithms. In general,
we can add a note about more carefully considering these cases during
implementation when MAX_XXX_RECORDS_TO_GOSSIP is large.
With regards to Richard's suggestions: we intend to rev the doc to
address all of the minor and major issues as adequately as we can. We
aren't very excited about refactoring the document entirely though. If
the group thinks it's valuable mostly as-is, we'd be happy to see it
published. If the WG thinks it would be better to refactor it, strip
out major components and so on - we think that'd be a valuable effort
and would be happy to comment and provide feedback.
-tom
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
