[dns-privacy] Stephen Farrell's Discuss on draft-ietf-dprive-dns-over-tls-07: (with DISCUSS and COMMENT)

["Stephen Farrell" <[e-mail]>]

Stephen Farrell has entered the following ballot position for
draft-ietf-dprive-dns-over-tls-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dprive-dns-over-tls/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------


Many thanks for doing this work. Before I ballot yes on this
one, there are two things I'd like to check (and a bunch of 
non-blocking comments about which I'm also happy to chat):

(1) 4.2: Why didn't you just mandate one way of calculating a
fingerprint as being mandatory to implement? (E.g. a sha256 hash of
the DER encoded SPKI?) and why is the "don't pin to a CA" rule in
appendix A not a MUST in the body of the document? Wouldn't it be
better to do both of those? (Or to say why you're not doing them,
e.g. if current implementations do different things.) Given that
recursives publishing PINs will pick something, having that
something supported by all clients would seem like a fine thing.

(2) Section 5: Is it ok to (almost:-) recommend TLS false start like
that?  Don't you need to at least point out that that has additional
requirements over and above RFC7525? I've not checked those in
detail though, as I'm waiting for the TLS WG to do their publication
request for false start. If you've done that checking, then you
might be just able to say "yeah, that's not a problem" but I'd like
to know since implementers here are likely to read this as saying
"Do RFC7525 and you're good."


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


- abstract: rfc-ed prefers s/[RFC7258]/(RFC7258)/ in abstracts

- abstract: would RFC7626 be a better thing to point at from here
instead of RFC7258?

- intro: maybe "recently adopted" is no longer true, consider
rephrasing?

- 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.

- 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.

- 3.2: "make use of trusted a SPKI Fingerprint pinset" needs to be
rephrased.

- 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?

- 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:-)

- 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.

- 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.

- 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.)

- 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.

- Section 10: This contradicts the front page which has 6 names
listed.