Subject: Re: [dns-privacy] review of draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC validation requirement

From: Antoine Germanos <[email-masked]>
Date: Mon, 30 Oct 2017 16:13:26 +0000

Antoine Germanos™
________________________________
From: dns-privacy <[email-masked]> on behalf of [email-masked] <[email-masked]>
Sent: Monday, October 30, 2017 6:10:54 PM
To: [email-masked]
Subject: dns-privacy Digest, Vol 44, Issue 13

Send dns-privacy mailing list submissions to
        [email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.ietf.org/mailman/listinfo/dns-privacy
or, via email, send a message with subject or body 'help' to
        [email-masked]

You can reach the person managing the list at
        [email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of dns-privacy digest..."

Today's Topics:

   1. Re: review of draft-ietf-dprive-dtls-and-tls-profiles-11: we
      should revert DNSSEC validation requirement (Stephane Bortzmeyer)
   2. Re: review of draft-ietf-dprive-dtls-and-tls-profiles-11: we
      should revert DNSSEC validation requirement (Paul Hoffman)
   3. Re: review of draft-ietf-dprive-dtls-and-tls-profiles-11: we
      should revert DNSSEC validation requirement (Daniel Kahn Gillmor)
   4. Re: Why is draft-ietf-dprive-dtls-and-tls-profiles still
      blocked? (Daniel Kahn Gillmor)
   5. Re: review of draft-ietf-dprive-dtls-and-tls-profiles-11: we
      should revert DNSSEC validation requirement (Paul Hoffman)
   6. Re: review of draft-ietf-dprive-dtls-and-tls-profiles-11: we
      should revert DNSSEC validation requirement (Stephen Farrell)

----------------------------------------------------------------------

Message: 1
Date: Mon, 30 Oct 2017 14:34:03 +0100
From: Stephane Bortzmeyer <[email-masked]>
To: Daniel Kahn Gillmor <[email-masked]>
Cc: [email-masked]
Subject: Re: [dns-privacy] review of
        draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC
        validation requirement
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=us-ascii

On Fri, Oct 27, 2017 at 11:40:15PM -0400,
 Daniel Kahn Gillmor <[email-masked]> wrote
 a message of 219 lines which said:

> I do not believe that DNSSEC validation is warranted as a mitigation
> against an active attacker in the context of an opportunistic
> metaquery,

I see the point but it seems to me a small detail in a 29-pages
document. So, IMHO, it should not cause yet another long delay for a
draft that already lingered too much.

> But i think the other changes between draft-10 and draft-11 are
> unwarranted and should be reverted.

There are very few changes and, except the DNSSEC *requirment*, they
seem good to me. I agree with Sara "I really do think a description
there of the trade-offs of DNSSEC validation are warranted".

------------------------------

Message: 2
Date: Mon, 30 Oct 2017 07:46:43 -0700
From: "Paul Hoffman" <[email-masked]>
To: "Sara Dickinson" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dns-privacy] review of
        draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC
        validation requirement
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=utf-8; format=flowed

On 30 Oct 2017, at 6:11, Sara Dickinson wrote:

> I?d disagree that connecting to a server for which the meta-query
> response failed DNSSEC validation results in _just_ a loss of privacy
> for Opportunistic in this case. If the answer was BOGUS then it seems
> reasonable to assume the server is not legitimate and so connecting
> also results in the clients' entire DNS service being controlled by
> the attacker.

There are many ways to get a BOGUS response that have nothing to do with
the information being "not legitimate". Typically today, BOGUS comes
from misconfigured servers such as expired keys, some nameservers out of
sync, and so on.

You cannot infer from a BOGUS response about why it is bogus.

> Take the case where the DNS server from DHCP really is legitimate. The
> fact that the meta-query answer _could_ be spoofed provides a vector
> for an opportunistic client to be directed to an attackers' DNS
> server. Note that this attack is not possible on a ?normal? client
> that directly uses the DHCP provided server, the attacker has to
> attack each individual query. My concern here is that without DNSSEC
> validation of the re-direct Opportunistic clients have an additional
> risk of this kind of attack than ?normal? ones.

Spoofing in normal DHCP and spoofing without DNSSEC seem equivalent to
me.

> Also this is only a guaranteed DoS for the case where there is only a
> single server configured. If there are multiple servers then the
> attacker must spoof the meta-query answers for _all_ the servers to
> achieve DoS. If it only spoofs one then the client can still get
> service.

...unless the attacker can spoof the (typically) two servers that the
client has addresses to.

> So one way to look at the trade-off seems to be is it worse that an
> attacker can block your DNS service or gets an extra chance to control
> all your DNS answers? I think you are arguing that for opportunistic
> the latter is preferable because a principle of Opportunistic is that
> it shouldn?t fail? If the WG decided that to be the case then it
> needs to be clear in the document this choice comes with an additional
> risk (and yet still not guarantee of privacy).

It is only an "additional risk" for a very limited attacker who can only
attack one of a set of addresses.

If the WG wants to go down the path of making Opportunistic encryption
even more difficult in order to feel that we offered the best security,
requiring DNSSEC on the client is a good way to do that. I would still
prefer more ubiquitous encryption.

--Paul Hoffman

------------------------------

Message: 3
Date: Mon, 30 Oct 2017 16:08:35 +0100
From: Daniel Kahn Gillmor <[email-masked]>
To: Sara Dickinson <[email-masked]>
Cc: [email-masked]
Subject: Re: [dns-privacy] review of
        draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC
        validation requirement
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="utf-8"

On Mon 2017-10-30 13:11:41 +0000, Sara Dickinson wrote:
> I really do think a description there of the trade-offs of DNSSEC
> validation are warranted

I agree that a discussion of the tradeoffs involved in DNSSEC validation
of the opportunistic meta-query is warranted.  I just come to a
different conclusion than the requirements in draft-11.

> if it ends up just being a MAY (although I would like to see SHOULD as
> a minimum for opportunistic).

SHOULD validate, but with what failure mode?  are we really saying that
opportunistic SHOULD deliver a DoS instead of a loss of privacy?  I
discuss a few optional responses for failures in opportunistic mode
below.

> I can also recognise the implementation overhead, however this is
> required for only one of the 3 cases of how the client may be
> provisioned:
>
> * IP address only (no meta-query required)
>
> * IP address and ADN (no meta-query required)
>
> * ADN only (meta-query required)
>
> So it is for the case where a client was directly and securely
> configured with just the ADN of a server it expects to provide
> privacy. If a client doesn?t want to implement DNSSEC then it can
> always restrict the opportunistic profile to requiring one of the
> first 2 configurations.

The cheapest and simplest implementation in terms of user experience to
get to verifiable opportunistic profile (that is, a profile that can at
least report that DNS privacy has been achieved, even if it won't be
enforced) seems to be:

  * allow the local administrator to provide a name for the preferred
    DNS resolver

Since it's opportunistic, it can even be enabled by default.

But this is the "ADN only" use case.  Saying it's not usable with the
opportunistic profile without DNSSEC validation would be a shame.

>> Choice 0 is the same outcome as the non-DNSSEC-validating scenario for
>> strict clients (no mitigation),
>
> Agreed - DNSSEC validation just provides earlier detection for Strict clients

or, converts success to failure in the case of DNSSEC misconfiguration
(because the connection would otherwise have succeeded) :(

> I?d disagree that connecting to a server for which the meta-query
> response failed DNSSEC validation results in _just_ a loss of privacy
> for Opportunistic in this case. If the answer was BOGUS then it seems
> reasonable to assume the server is not legitimate and so connecting
> also results in the clients' entire DNS service being controlled by
> the attacker.

sure, but this is the case for non-private DNS as well, right?  So the
mitigation in this case is with respect to the features that "private
DNS" is supposed to offer.  Whatever those features are, they are absent
given an attacker-controlled DNS resolver.  So if the DNS-over-TLS
server is intended to also provide integrity protection, yes, that would
also be lost.  I think we're agreeing here, right?  I apologize if "loss
of privacy" is a misleading shorthand.

> Take the case where the DNS server from DHCP really is legitimate. The
> fact that the meta-query answer _could_ be spoofed provides a vector
> for an opportunistic client to be directed to an attackers' DNS
> server. Note that this attack is not possible on a ?normal? client
> that directly uses the DHCP provided server, the attacker has to
> attack each individual query. My concern here is that without DNSSEC
> validation of the re-direct Opportunistic clients have an additional
> risk of this kind of attack than ?normal? ones.

ok, i think i understand.  The concern is that a non-network-controlling
attacker who can spoof DNS responses but can't spoof DHCP responses can
now take over full DNS resolution of opportunistic clients just by
racing (and winning) the legitimate metaquery response.

This is true, but the threat model we're worrying now include all of the
following characteristics:

 * attacker does not control the client's network (otherwise, they could
   redirect the port 853 queries anyway)

 * attacker cannot (or has failed to) race the client's DHCP connection
   (otherwise, they'd point to a different DNS server anyway)

 * attacker *can* race the legitimate response to the client's
   opportunistic metaquery.

 * client is in opportunistic mode.

So the question is, in this particular corner case, what is the right
mitigation to the scenario where "if DNSSEC validation of the
opportunistic metaquery fails?" ?

if the answer is "?proceed as though it had not failed (trying to
connect to the preferred server's proposed address), but continue
listening for another response to the metaquery; prefer subsequent
metaquery responses that do have DNSSEC validation over those responses
that are not DNSSEC validated." Then i'd be ok with it, but it's not
specified in the draft.

If the answer is "?hard-fail and deny DNS service", then i think that's
incorrect given the goals of opportunistic mode.

If the answer is "?stop trying to use opportunistic DNS privacy
entirely, but fall back to using the DHCP-provided resolver for all
queries" then i think that's a mistake -- we've already demonstrated
that we're in a scenario where the attacker can race the DHCP-provided
resolver and win.  So what do we gain by making this the failure mode?

> Also this is only a guaranteed DoS for the case where there is only a
> single server configured. If there are multiple servers then the
> attacker must spoof the meta-query answers for _all_ the servers to
> achieve DoS. If it only spoofs one then the client can still get
> service.

I think this equivalent to my responses-to-failed-validation #2 --
retrying the opportunistic metaquery.  (also, equivalent to "?but
continue listening?" in the paragraphs above.) I agree that's an
interesting case, but i think it's an additional complexity as yet
unspecified in the draft.  :(

> So one way to look at the trade-off seems to be is it worse that an
> attacker can block your DNS service or gets an extra chance to control
> all your DNS answers? I think you are arguing that for opportunistic
> the latter is preferable because a principle of Opportunistic is that
> it shouldn?t fail? If the WG decided that to be the case then it needs
> to be clear in the document this choice comes with an additional risk
> (and yet still not guarantee of privacy).

it is "an extra chance only" in the scenario where points outlined above
hold.  An attacker who can also race and beat the DHCP server has the
exact same chance already, right?

> Technically his DISCUSS was on a different topic (SPKI handling) as
> Stephane pointed out, this was an issue that came out of a separate
> comment he made.

Hm, sorry, i'll try to follow up on that in the other sub-thread.

Thanks for the discussion.

    --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://mailarchive.ietf.org/arch/browse/dns-privacy/attachments/20171030/671db67b/attachment.asc>

------------------------------

Message: 4
Date: Mon, 30 Oct 2017 16:27:16 +0100
From: Daniel Kahn Gillmor <[email-masked]>
To: Stephane Bortzmeyer <[email-masked]>, [email-masked]
Subject: Re: [dns-privacy] Why is
        draft-ietf-dprive-dtls-and-tls-profiles still blocked?
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="us-ascii"

On Fri 2017-10-27 15:55:10 +0200, Stephane Bortzmeyer wrote:
> The datatracker tells us that draft-ietf-dprive-dtls-and-tls-profiles
> has a DISCUSS "This needs to be updated to indicate that the client
> MUST NOT offer 7250 unless it has a preconfigured SPKI, otherwise
> you're going to have interop problems."

I agree that this DISCUSS should be cleared, since draft-10 and draft-11
both state:

    A client MUST only indicate support for raw public keys if it has an
    SPKI pinset pre-configured (for interoperability reasons).

Regards,

    --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://mailarchive.ietf.org/arch/browse/dns-privacy/attachments/20171030/639c412b/attachment.asc>

------------------------------

Message: 5
Date: Mon, 30 Oct 2017 08:42:18 -0700
From: "Paul Hoffman" <[email-masked]>
To: "Daniel Kahn Gillmor" <[email-masked]>
Cc: [email-masked]
Subject: Re: [dns-privacy] review of
        draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC
        validation requirement
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=utf-8; format=flowed

On 30 Oct 2017, at 8:08, Daniel Kahn Gillmor wrote:

> On Mon 2017-10-30 13:11:41 +0000, Sara Dickinson wrote:
>> if it ends up just being a MAY (although I would like to see SHOULD
>> as
>> a minimum for opportunistic).
>
> SHOULD validate, but with what failure mode?

+1 to the question: we're talking about Opportunistic mode here.

> are we really saying that
> opportunistic SHOULD deliver a DoS instead of a loss of privacy?

Some of us are most emphatically not saying that.

. . .

> sure, but this is the case for non-private DNS as well, right?  So the
> mitigation in this case is with respect to the features that "private
> DNS" is supposed to offer.  Whatever those features are, they are
> absent
> given an attacker-controlled DNS resolver.  So if the DNS-over-TLS
> server is intended to also provide integrity protection, yes, that
> would
> also be lost.  I think we're agreeing here, right?  I apologize if
> "loss
> of privacy" is a misleading shorthand.
>
>> Take the case where the DNS server from DHCP really is legitimate.
>> The
>> fact that the meta-query answer _could_ be spoofed provides a vector
>> for an opportunistic client to be directed to an attackers' DNS
>> server. Note that this attack is not possible on a ?normal?
>> client
>> that directly uses the DHCP provided server, the attacker has to
>> attack each individual query. My concern here is that without DNSSEC
>> validation of the re-direct Opportunistic clients have an additional
>> risk of this kind of attack than ?normal? ones.
>
> ok, i think i understand.  The concern is that a
> non-network-controlling
> attacker who can spoof DNS responses but can't spoof DHCP responses
> can
> now take over full DNS resolution of opportunistic clients just by
> racing (and winning) the legitimate metaquery response.
>
> This is true, but the threat model we're worrying now include all of
> the
> following characteristics:
>
>  * attacker does not control the client's network (otherwise, they
> could
>    redirect the port 853 queries anyway)
>
>  * attacker cannot (or has failed to) race the client's DHCP
> connection
>    (otherwise, they'd point to a different DNS server anyway)
>
>  * attacker *can* race the legitimate response to the client's
>    opportunistic metaquery.
>
>  * client is in opportunistic mode.
>
> So the question is, in this particular corner case, what is the right
> mitigation to the scenario where "if DNSSEC validation of the
> opportunistic metaquery fails?" ?
>
> if the answer is "?proceed as though it had not failed (trying to
> connect to the preferred server's proposed address), but continue
> listening for another response to the metaquery; prefer subsequent
> metaquery responses that do have DNSSEC validation over those
> responses
> that are not DNSSEC validated." Then i'd be ok with it, but it's not
> specified in the draft.
>
> If the answer is "?hard-fail and deny DNS service", then i think
> that's
> incorrect given the goals of opportunistic mode.

Agree. And fully agree that an attacker who can do the third bullet *but
not the second* is a very obscure corner case.

Having this document say, in essence, "you don't get opportunistic
encryption unless you add a DNSSEC validation stack" feels like a
regression to the original goals of this WG.

--Paul Hoffman

------------------------------

Message: 6
Date: Mon, 30 Oct 2017 15:59:21 +0000
From: Stephen Farrell <[email-masked]>
To: Paul Hoffman <[email-masked]>, Daniel Kahn Gillmor
        <[email-masked]>
Cc: [email-masked]
Subject: Re: [dns-privacy] review of
        draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC
        validation requirement
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="utf-8"

Hiya,

On 30/10/17 15:42, Paul Hoffman wrote:
> Having this document say, in essence, "you don't get opportunistic
> encryption unless you add a DNSSEC validation stack" feels like a
> regression to the original goals of this WG.

I'm not sure that having a stack is such a barrier in reality.
Requiring that some DNSSEC signatures validate in order to win
the opportunistic game is the problem I think.

I'd personally be fine with a "MUST try DNSSEC" statement, though
that could be argued to be OTT, given the probability of success,
but as DKG and you (and I) agree, it's the failure mode that needs
fixing in the draft.

S.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: <https://mailarchive.ietf.org/arch/browse/dns-privacy/attachments/20171030/00fb8f85/attachment.asc>

------------------------------

Subject: Digest Footer

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

------------------------------

End of dns-privacy Digest, Vol 44, Issue 13
*******************************************