On 09/03/16 18:43, Wessels, Duane wrote: > >> On Mar 9, 2016, at 6:19 AM, Stephen Farrell <[email protected]> >> wrote: >> >> > > Starting with the easy ones...
Sure they're all easy:-) All of the stuff below is fine except as noted... >> >> - 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. No "trusted a SPKI" seems like Yoda-speak is all:-) > >> >> - 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. It was that before, though. Maybe you did s/encryption/security/ which'd be fine. > >> >> - 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. I'd suggest instead: "Since traffic analysis can be based on many kinds of pattern and many kinds of classifier, simple padding schemes may not by themselves be sufficient to mitigate the attack. Padding will however form a part of more complex mitigations for the traffic analysis attack that are likely to be developed over time. Implementers who can offer flexibility in terms of how padding can be used may be in a better position to enable such mitigations to be deployed in future." >> - Section 10: This contradicts the front page which has 6 names >> listed. >> > > contradiction removed. Heh - nicely ambiguous:-) Cheers again, S. > > DW > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy >
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
