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

From: "Stephen Farrell" <[email-masked]>
Date: Wed, 09 Mar 2016 06:19:23 -0800

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.

---

From: "Wessels, Duane" <[email-masked]>
Date: Wed, 9 Mar 2016 18:43:49 +0000

> On Mar 9, 2016, at 6:19 AM, Stephen Farrell <[email-masked]> 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

Yes I think thats a good change.

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

s/recently/also/

> don't need to say "or its successors." Same thing in 3.2.

Ack, done.

> NOT negotiate those, so it's probably ok, unless you want to

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

Do you say that because SPKI is not spelled out at this point, or
something else?  We've since expanded SPKI here.

> it's fine but maybe you know better?

Ticket lifetime hasn't come up before, so I would assume the RFC7525
recommendation is fine.

> so you might want to s/encryption/security/ there. (But I don't care

I've changed it to opportunistic encryption.

> different from what's stated.

Okay if we just change "provides guaranteed privacy" to "provides privacy" ?

> it's my calendar running in the background? I'd prepend a "Where

Agreed.  I've inserted "whenever possible"

> this text in the RFC. I'd suggest keeping it. (Except the note.)

Agreed.  I've removed "prior to publication" from the note.

> 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

contradiction removed.

DW

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 9 Mar 2016 21:17:13 +0000

> Starting with the easy ones...

Sure they're all easy:-)

All of the stuff below is fine except as noted...

> something else?  We've since expanded SPKI here.

No "trusted a SPKI" seems like Yoda-speak is all:-)

> I've changed it to opportunistic encryption.

It was that before, though. Maybe you did s/encryption/security/
which'd be fine.

>        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

Heh - nicely ambiguous:-)

Cheers again,
S.

> 
> DW
> 
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

---

From: "Wessels, Duane" <[email-masked]>
Date: Wed, 9 Mar 2016 21:39:47 +0000

> On Mar 9, 2016, at 1:17 PM, Stephen Farrell <[email-masked]> wrote:
> 
> 
>> 
>>> 

Okay, wow... I must've read that at least five times today and not noticed.

> It was that before, though. Maybe you did s/encryption/security/

Yes, sorry!

       <section title="Opportunistic Privacy Profile">
         <t>
           For opportunistic privacy, analogous to SMTP opportunistic
-          encryption <xref target="RFC7435"/> one does not require privacy,
+          security <xref target="RFC7435"/>, one does not require privacy,
          but one desires privacy when
           possible.
         </t>

> mitigations to be deployed in future."

Excellent, thank you.

DW

---

From: "Wessels, Duane" <[email-masked]>
Date: Wed, 9 Mar 2016 22:24:07 +0000

Hi Stephen,

> the DER encoded SPKI?)

I don't think that was intentional.  Happy to add it as a requirement.

   Implementations of this privacy profile MUST support the calculation
   and representation of a fingerprint as the SHA-256 [RFC6234] hash of
   the DER-encoded ASN.1 representation of the Subject Public Key Info
   (SPKI) of an X.509 certificate.  Additional fingerprint types MAY
   also be supported.

> and why is the "don't pin to a CA" rule in
> appendix A not a MUST in the body of the document?

The appendix essentially says "service-specific private CA: good. public CA: bad"

I don't think we can make it a MUST because (a) how do you enforce that and
(b) we don't expect the DNS client to differentiate between private/public CAs.

> Wouldn't it be
> better to do both of those?

Sorry, I'm not sure what you mean by "do both of those"?

> (Or to say why you're not doing them,

I agree that it might be better to move the sentence below from the appendix
to the main body.

   Operators of a DNS-over-TLS service in this profile are
   expected to provide pins that are specific to the service being
   pinned (i.e., public keys belonging directly to the end-entity or to
   a service-specific private CA) and not to public key(s) of a generic
   public CA.

> "Do RFC7525 and you're good."

I don't know.  I need to defer to TLS experts on this one.

This may be a case where the risks (of getting it wrong) outweigh the benefits
(of sometimes lower latency) so maybe it should be removed?

DW

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Mar 2016 08:41:15 +0000

Hiya,

>    (SPKI) of an X.509 certificate.  Additional fingerprint types MAY

That's great thanks. You maybe want to mention the base64 encoding
too if you want that to end up exactly as per Appendix A.

> (b) we don't expect the DNS client to differentiate between private/public CAs.

Ok, fair point.

> Sorry, I'm not sure what you mean by "do both of those"?

Never mind - bad phraseology from me;-)

>    a service-specific private CA) and not to public key(s) of a generic

Fair enough.

> (of sometimes lower latency) so maybe it should be removed?

Some people will prefer the latency gain though as we know.

I think in this case all you need to do is highlight that false
start has requirements over and above 7525, e.g. by saying:

"Implementations supporting TLS false start need to be aware
that imposes additional constraints on how one uses TLS,
over and above those stated in BCP195. It is unsafe to use
false start if your implementation and deployment doesn't
adhere to these specific requirements. See [false-start]
for details of those additional constraints."

Cheers,
S.

PS: If the above changes are acceptable then my DISCUSS will
be sorted.

---

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 10 Mar 2016 18:00:56 +0000

> On Mar 10, 2016, at 12:41 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 

Okay, it says this now:

   Implementations of this privacy profile MUST support the calculation
   of a fingerprint as the SHA-256 [RFC6234] hash of the DER-encoded
   ASN.1 representation of the Subject Public Key Info (SPKI) of an
   X.509 certificate.  Implementations MUST support the representation
   of a SHA-256 fingerprint as a base 64 encoded character string
   [RFC4648].  Additional fingerprint types MAY also be supported.

>>   a service-specific private CA) and not to public key(s) of a generic

That sentence has now been moved to the opening paragraph of 4.2.

> for details of those additional constraints."

I've added this with just minor edits, thanks.

> PS: If the above changes are acceptable then my DISCUSS will

The link below will take you to an rfcdiff of all the changes since starting IESG evaluation

http://goo.gl/Wwsr7M

DW

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 10 Mar 2016 18:37:52 +0000

> The link below will take you to an rfcdiff of all the changes since starting IESG evaluation

Great thanks. I'll change my ballot to yes shortly

Ta,
S.