> On Mar 9, 2016, at 6:19 AM, Stephen Farrell <[email protected]> wrote:
>
>
Starting with the easy ones...
>
> - abstract: rfc-ed prefers s/[RFC7258]/(RFC7258)/ in abstracts
Okay, fixed.
>
> - abstract: would RFC7626 be a better thing to point at from here
> instead of RFC7258?
Yes I think thats a good change.
>
> - intro: maybe "recently adopted" is no longer true, consider
> rephrasing?
s/recently/also/
>
> - intro: Might be better to refer to RFC7525 as BCP195, so that you
> don't need to say "or its successors." Same thing in 3.2.
Ack, done.
>
> - 3.1: "purely for encrypted communications" is good - but do we
> need to say anything about NULL ciphersuites? RFC7525 says you MUST
> NOT negotiate those, so it's probably ok, unless you want to
> re-enforce that here.
My opinion is that we're covered by RFC7525/BCP195, which is referenced
in the next section under Handshake and Authentication. If we specifically
mention NULL encryption, then wouldn't we also need to mention RC4, "not
less than 112 bits" and any other requirements from RFC7525?
>
> - 3.2: "make use of trusted a SPKI Fingerprint pinset" needs to be
> rephrased.
Do you say that because SPKI is not spelled out at this point, or
something else? We've since expanded SPKI here.
>
> - 3.4, 2nd last para: this recommends using tickets (RFC5077), which
> is fine. RFC7525 (section 3.4) suggests changing tickets at least
> weekly. Is that suggestion also good here or would it be better to
> recommend (or suggest) some other ticket lifetime? I'd guess
> it's fine but maybe you know better?
Ticket lifetime hasn't come up before, so I would assume the RFC7525
recommendation is fine.
>
> - 4.1, RFC 7435 is about "opportunistic security" and not about
> "opportunistic encryption." That followed a long terminology debate,
> so you might want to s/encryption/security/ there. (But I don't care
> personally:-)
I've changed it to opportunistic encryption.
>
> - 4.1, last para: OS never provides "guaranteed" privacy. I think
> what you mean is that while you're always vulnerable to an on-path
> attacker, if there is no such attacker then you do get privacy (to
> the recursive) albeit with no guarantee. I think that's subtly
> different from what's stated.
Okay if we just change "provides guaranteed privacy" to "provides privacy" ?
>
> - 4.2, "The user MUST be alerted" needs a qualification - what if
> it's my calendar running in the background? I'd prepend a "Where
> possible,... " at least.
Agreed. I've inserted "whenever possible"
>
> - Section 7: I'm not clear from the note if you do or don't want
> this text in the RFC. I'd suggest keeping it. (Except the note.)
Agreed. I've removed "prior to publication" from the note.
>
> - Section 9, point 4: I think it'd be fair to note that naive
> padding schemes may not work as well as planned against traffic
> analysis, and to say that implementations that allow for flexibility
> there might be good so that we can experiment with ways of
> mitigating traffic analysis.
How does this look to you?
Since
padding of DNS messages is new, implementations might need to
support multiple types of padding or other mitigation techniques
in response to traffic analysis threats.
>
> - Section 10: This contradicts the front page which has 6 names
> listed.
>
contradiction removed.
DW
_______________________________________________
dns-privacy mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dns-privacy
