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

[Ben Laurie <[e-mail]>]

On 8 May 2017 at 08:44, Sara Dickinson <[e-mail]> wrote:
>
>> 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).

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

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

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.

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

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

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

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