Subject: [secdir] Security review of draft-ietf-dprive-dtls-and-tls-profiles-09

From: Ben Laurie <[email-masked]>
Date: Thu, 4 May 2017 12:11:59 +0100

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Status: not ready.

I am a little puzzled by this I-D. The title is "Authentication and
(D)TLS Profile for DNS-over-(D)TLS" and the intro says it specifies
profiles which "which define the security properties a user should
expect when using that profile to connect to the available DNS
servers", however, as far as I can see, no properties other than
server authentication are defined.

The document also appears to claim that a connection that is
authenticated and encrypted is "private" - that seems to stretch the
meaning of "private" quite considerably.

Other considerations surely exist, such as resistance against traffic
analysis, key sizes, algorithm choice.

As a result, claims like "Strict Privacy provides the strongest
privacy guarantees" are just plain wrong.

Given these large holes in scope, I have not attempted a more detailed analysis.

---

From: Sara Dickinson <[email-masked]>
Date: Mon, 8 May 2017 08:44:46 +0100

> On 4 May 2017, at 12:11, Ben Laurie <[email-masked]> wrote:
> 

Hi Ben, 

Thanks for the review. 

> server authentication are defined.

Section 5 is really the part of the draft intended to address this by outlining in detail the security properties a user should expect when using either a Strict or Opportunistic Profile to connect to the available DNS servers. So by security properties we really mean mitigation against passive attack (via encryption alone) or active attack (by using encryption in combination with authentication).

In developing the draft we found widespread uncertainly among the DNS community as to precisely what Opportunistic Security was and how it differed from Strict. For example it became apparent that many DNS folks didn’t realise that Opportunistic could include falling back to clear text thus providing no security guarentees.  That is why the table in Section 5 is provided to (hopefully) clarify these concepts and expectations. It might seem overkill to those with a strong security background but we had enough iterations on this during working group review that it really did seem necessary.

Would re-wording the introduction text to say something like 

“This document specifies two Usage Profiles (Strict and Opportunistic) for DTLS [RFC6347] and TLS [RFC5246] which provide different levels of attack mitigation over using only clear text DNS.”

be a start in addressing this?

> meaning of "private" quite considerably.

It wasn’t the intent to claim complete privacy via these Profiles. I _thought_ we had been quite careful in always using a phrase such as “This profile provides strong privacy guarantees to the client.” rather than saying ’This provides a private connection” but perhaps I missed something? This seems to go back to the same issue of wording and so I wonder that if we had used a phrase like ‘attack mitigation’ throughout instead of 'privacy guarantees’ it would read more clearly?

> analysis, key sizes, algorithm choice.

We do attempt to address these issues separately in later sections, specifically:
-  Section 11 ‘Counter measures to DNS Traffic Analysis’ recommending padding SHOULD be done by both client and server and 
 - Section 9 '(D)TLS Protocol Profile' where rather than making specific recommendations for DNS we state that client and servers MUST adhere to RFC7275 and MUST use TLS 1.2 or later, etc. 

> privacy guarantees" are just plain wrong.

Better written as “Strict Privacy provides the strongest privacy guarantees of the two Profiles described here”? Again, the intention isn’t to portray Strict Privacy as some sort of ‘perfect privacy’ just as the ‘best privacy available’.

I’m hoping this is a general problem generated by the use of a handful of phrases in the document that I now realise could be read with a different context. If you also think this is the fundamental issue then I would suggest the authors take a pass over the document to try to address this by either changing this wording or carefully defining what these terms mean in the context of this document. 

Regards

Sara.

---

From: Ben Laurie <[email-masked]>
Date: Fri, 12 May 2017 20:42:47 +0100

> Section 5 is really the part of the draft intended to address this by outlining in detail the security properties a user should expect when using either a Strict or Opportunistic Profile to connect…

OK, so what you're really aiming at is mitigation of trivial MitM
attacks on the underlying crypto.

So how about making the title (and summary) be "Avoiding Trivial MitM
Attacks on DNS-over-(D)TLS"?

> be a start in addressing this?

A start, but it leaves entirely vague what attack you might be mitigating.

I guess the core problem is I don't see a clear articulation of the
threat model.

I'd hazard a guess from the above that it's essentially: "there should
be no man in the middle who can trivially get plaintext". If the claim
is you mitigate that threat with "Strict" then I would then only have
to argue about how authentication occurs, rather than how all
"security properties" occur.

> It wasn’t the intent to claim complete privacy via these Profiles. I _thought_ we had been quite careful in always using a phrase such as “This profile provides strong privacy guarantees to the client.” rather than saying ’This provides a private connection” but perhaps I missed something?

I think that most users have no idea what the difference is between
those two statements.

> This seems to go back to the same issue of wording and so I wonder that if we had used a phrase like ‘attack mitigation’ throughout instead of 'privacy guarantees’ it would read more clearly?

Yes. And you need to say what attack you mitigate. :-)

> Better written as “Strict Privacy provides the strongest privacy guarantees of the two Profiles described here”?

Technically, I think you can only claim it is at least as strong.
Unless you have a magic authentication story. :-)

> Again, the intention isn’t to portray Strict Privacy as some sort of ‘perfect privacy’ just as the ‘best privacy available’.
>