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

[Sara Dickinson <[e-mail]>]

> On 4 May 2017, at 12:11, Ben Laurie <[e-mail]> wrote:
> 
> 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.
> 

Hi Ben, 

Thanks for the review. 

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

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?

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

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?

> 
> Other considerations surely exist, such as resistance against traffic
> 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. 

> 
> As a result, claims like "Strict Privacy provides the strongest
> 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.