Re: [dns-privacy] dns-privacy Digest, Vol 44, Issue 15

[Antoine Germanos <[e-mail]>]

Dear all,

As for the scenario, let’s talk about Starbucks eg ;

good one by the way, I love Starbucks .
Let’s say I am meeting with someone that touched base with me saying he is a family relative.

He touched base with me saying I as relative to his late aunt , supposedly my mother’s grandmother, his aunt in the same time, thus I should sign some papers becoz I do inherit a small part of the assets .

Opportunistic or. Not, who would just ignore such a proposal, at least from what I know, I heard my mom talking once about the late gone and that they were really close relatives.

Supposedly in this scenario, where , if so, we are all family , why not to touch base with him , already the papers he gave me me about the inheritance, were already notarized, and mentioned the family tree , very clear in the header.as proofs being. RelativeS ( the notary had mentioned the name of my mom and accordingly her sister , who passed away yesterday, unfortunate coincidence indeed.

When we talked, as relatives , nothing new was brought to discussion, I , as always curious to discover and DiGG more in the family tree , relatives, or , Not.
When a while ago,
I was invited to lunch in my ex-wife family palace, my mom, so attached to maintain our family, very strong roots concerning just gathering the family members on occasions, very strict concerning the code and the conduct, she is the daughter of a Lord, and etiquette matters a lot for her,
When i took my kids on thanksgiving to my ex-wife family palace, ( they have been a lot of weddings and divorces between my family and my ex- wife family )

By then , my mom boycotted me for a while and thought I would leave the kids custody to my ex-wife, so much attached and strict about keeping the family together. She later knew that my boys have our family roots in their DNA, (? A very well anchored ancestry) - nothing on earth can break this link . And honestly I am fed up with my mom concerns after 30 years of being in a situation where I should prove to her that “indeed, for sure, no matter what, even if they will take my soul” I would never change my family name or my boys family name. An issue my ex - wife lawyer used just to blackmail my family , knowing how much we are attached each one to the other.

And concerning poisoning my drink; just take a minute and think seriously of it; he is the owner of Starbucks!!! He can, would, could, will maybe poison everyone. So, thinking of it, calculating the risk i% he could have poisoned my drink is the same % anybody of us could fave every morning when grabbing his coffee.

If each of us will keep on suspecting each other’s , than the rule is gonna be the exception, and the exception rule!! Our beliefs, principles , own convictions, and same vision is what put us together ; true, we have to keep the circle ⭕️ a [ circle ] , and stay awaken and aware, but if it’s gonna be an all-time trust issues bouncing in a tennis playground; it will literally become just a “game” of hide and seek, instead of the Common Community Commitment, a Perpetual Pitching Probabilities; then ....let’s go PPP P-P ( phonetics) .

This is my opinion, i for myself want with pleasure dedicating my time to a common belief, and better be “opportunistic” than being “Skeptical”; and better than those 2 is to behave like we should, one community, not labeling and doubting each others.

You could say whatever u want, kick me off, but honestly, I am in for my strong believe in a common vision. And how to develop it , rather than “envelop” it.

Greetings,
Antoine


Antoine Germanos™
________________________________
From: dns-privacy <[e-mail]> on behalf of [e-mail] <[e-mail]>
Sent: Tuesday, October 31, 2017 9:00:16 PM
To: [e-mail]
Subject: dns-privacy Digest, Vol 44, Issue 15

Send dns-privacy mailing list submissions to
        [e-mail]

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
        [e-mail]

You can reach the person managing the list at
        [e-mail]

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 (Paul Wouters)
   2. Re: review of draft-ietf-dprive-dtls-and-tls-profiles-11: we
      should revert DNSSEC validation requirement (Sara Dickinson)
   3. Re: review of draft-ietf-dprive-dtls-and-tls-profiles-11: we
      should revert DNSSEC validation requirement (Paul Hoffman)
   4. 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 16:04:51 -0400 (EDT)
From: Paul Wouters <[e-mail]>
To: Daniel Kahn Gillmor <[e-mail]>
Cc: Sara Dickinson <[e-mail]>, [e-mail]
Subject: Re: [dns-privacy] review of
        draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC
        validation requirement
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=utf-8; format=flowed

On Mon, 30 Oct 2017, Daniel Kahn Gillmor wrote:

> Date: Mon, 30 Oct 2017 11:08:35
> From: Daniel Kahn Gillmor <[e-mail]>
> Cc: [e-mail]
> To: Sara Dickinson <[e-mail]>
> Subject: Re: [dns-privacy] review of
>     draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC
>     validation requirement
>
> 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 a client allows multiple type of profiles, then DNSSEC might not be
needed to reach a pre-configured Strict profile with a trust anchor.
Then the decision to be made is, if that Strict profile is unavailable,
does that make the current network hostile enough to not use it? And if
no strict profile is configured, well then anyting is better then
nothing.

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

If talking about the meta query, see above. If talking about DNSESC
validation for the actual content queries, I think it should be
considered that anything not properly supporting DNSSEC is an active
attack against the user, and I would be okay with a hard fail.

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

I thought "opportunistic" meant "do not report to the user" so as to
guarantee that the user is still thinking they are in the realm of "not
private" even if there is encryption happening, because without a trust
anchor, the user cannot know if this opportunistic party is privacy
preserving?

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

A dnssec failure is no different then a certificate failure, and
browsers are now doing something really close to hard fail on those now.

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

I guess I see two different opportunistic cases. One where you find
a DNS server, get to an IP and/or public key, use DNSSEC to confirm the
key/name in the public real DNS (via that server) and protected with
DNSSEC. For instance, a coffeeshop chain could do so, and if it links to
say publicdns.starbucks.com then you have some confidence then the local
instance of the coffeeshop cannot see your traffic. And then there is
the opportunistic case where you simply will never find out the
identity, and where you just assume the provider could be the attaker.

I feel those two user cases are different. The first one, I could decide
not to use my local starbucks when it starts to fail using the chain's
configured DNS server. The second case I know I'm giving my privacy to
someone who could be malicious, but I still prefer that over not using
their DNS. (although in practise, my guess is as soon as google DNS
supports TLS, everyone will have at least one Strict profile with their
key and never use an opportunistic profile.

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

I think that's really rare now. Most "shared wifi" solutions constrain the
clients and prevent them from talking to each other. In the coffeeshop
the customers cannot see my laptop, but the coffeeshop owner can.

Paul



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

Message: 2
Date: Tue, 31 Oct 2017 15:06:16 +0000
From: Sara Dickinson <[e-mail]>
To: Paul Wouters <[e-mail]>
Cc: Daniel Kahn Gillmor <[e-mail]>, [e-mail]
Subject: Re: [dns-privacy] review of
        draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC
        validation requirement
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=utf-8

So here is an example of how Stubby works today. It has separate settings for Transports(UDP/TCP/TLS), Usage profile and DNSSEC. The relevant DNSSEC options are:

- dnssec_return_status  - blocks BOGUS answers, returns all others with status information (secure vs insecure vs indeterminate)
- dnssec_return_only_secure   - does what is says on the tin

where ?dnssec_return_status? is obviously what we recommend if you want DNSSEC.

If I have stubby configured like that then connecting to a DNS server with a BOGUS A record just because I?m in opportunistic privacy mode seems questionable.

So maybe ?A DNSSEC validating client SHOULD apply the same validation policy to the A/AAAA meta-query lookup as it does to other queries.??

Sara.

> On 30 Oct 2017, at 20:04, Paul Wouters <[e-mail]> wrote:
>
> On Mon, 30 Oct 2017, Daniel Kahn Gillmor wrote:
>
>> Date: Mon, 30 Oct 2017 11:08:35
>> From: Daniel Kahn Gillmor <[e-mail]>
>> Cc: [e-mail]
>> To: Sara Dickinson <[e-mail]>
>> Subject: Re: [dns-privacy] review of
>>    draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC
>>    validation requirement
>> 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 a client allows multiple type of profiles, then DNSSEC might not be
> needed to reach a pre-configured Strict profile with a trust anchor.
> Then the decision to be made is, if that Strict profile is unavailable,
> does that make the current network hostile enough to not use it? And if
> no strict profile is configured, well then anyting is better then
> nothing.
>
>>> 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.
>
> If talking about the meta query, see above. If talking about DNSESC
> validation for the actual content queries, I think it should be
> considered that anything not properly supporting DNSSEC is an active
> attack against the user, and I would be okay with a hard fail.
>
>> 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:
>
> I thought "opportunistic" meant "do not report to the user" so as to
> guarantee that the user is still thinking they are in the realm of "not
> private" even if there is encryption happening, because without a trust
> anchor, the user cannot know if this opportunistic party is privacy
> preserving?
>
>> or, converts success to failure in the case of DNSSEC misconfiguration
>> (because the connection would otherwise have succeeded) :(
>
> A dnssec failure is no different then a certificate failure, and
> browsers are now doing something really close to hard fail on those now.
>
>>> 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.
>
> I guess I see two different opportunistic cases. One where you find
> a DNS server, get to an IP and/or public key, use DNSSEC to confirm the
> key/name in the public real DNS (via that server) and protected with
> DNSSEC. For instance, a coffeeshop chain could do so, and if it links to
> say publicdns.starbucks.com then you have some confidence then the local
> instance of the coffeeshop cannot see your traffic. And then there is
> the opportunistic case where you simply will never find out the
> identity, and where you just assume the provider could be the attaker.
>
> I feel those two user cases are different. The first one, I could decide
> not to use my local starbucks when it starts to fail using the chain's
> configured DNS server. The second case I know I'm giving my privacy to
> someone who could be malicious, but I still prefer that over not using
> their DNS. (although in practise, my guess is as soon as google DNS
> supports TLS, everyone will have at least one Strict profile with their
> key and never use an opportunistic profile.
>
>>> 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.
>
> I think that's really rare now. Most "shared wifi" solutions constrain the
> clients and prevent them from talking to each other. In the coffeeshop
> the customers cannot see my laptop, but the coffeeshop owner can.
>
> Paul
>
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy



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

Message: 3
Date: Tue, 31 Oct 2017 08:12:45 -0700
From: "Paul Hoffman" <[e-mail]>
To: "Sara Dickinson" <[e-mail]>
Cc: [e-mail]
Subject: Re: [dns-privacy] review of
        draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC
        validation requirement
Message-ID: <[e-mail]>
Content-Type: text/plain; charset=utf-8; format=flowed

On 31 Oct 2017, at 8:06, Sara Dickinson wrote:

> So maybe ?A DNSSEC validating client SHOULD apply the same
> validation policy to the A/AAAA meta-query lookup as it does to other
> queries.??

That could be misinterpreted to indicate that there has to be some
positive validation policy. How about:
    A DNSSEC validating client SHOULD apply the same validation policy
    to the A/AAAA meta-query lookup as it does to other queries.
    A client that does not validate DNSSEC SHOULD apply any policy it
    has to the A/AAAA meta-query lookup.

--Paul Hoffman



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

Message: 4
Date: Tue, 31 Oct 2017 18:39:03 +0000
From: Stephen Farrell <[e-mail]>
To: Paul Hoffman <[e-mail]>, Sara Dickinson
        <[e-mail]>
Cc: [e-mail]
Subject: Re: [dns-privacy] review of
        draft-ietf-dprive-dtls-and-tls-profiles-11: we should revert DNSSEC
        validation requirement
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="utf-8"


Hiya,

On 31/10/17 15:12, Paul Hoffman wrote:
> On 31 Oct 2017, at 8:06, Sara Dickinson wrote:
>
>> So maybe ?A DNSSEC validating client SHOULD apply the same validation
>> policy to the A/AAAA meta-query lookup as it does to other queries.??
>
> That could be misinterpreted to indicate that there has to be some
> positive validation policy. How about:
> ?? A DNSSEC validating client SHOULD apply the same validation policy
> ?? to the A/AAAA meta-query lookup as it does to other queries.
> ?? A client that does not validate DNSSEC SHOULD apply any policy it
> ?? has to the A/AAAA meta-query lookup.

So I think either of the above could be ok.

The main thing for me is that we do not insist that a server
has to get DNSSEC setup before they can do opportunistic DNS
security. I think the above is ok in that respect.

Just checking: I think that means that with the opportunistic
profile, only servers that have DNSSEC setup and where the
client validates and gets a badly signed response would be
affected, all other cases would still get DNS privacy of some
sort. If that's right, I can live with it.

Cheers,
S.

>
> --Paul Hoffman
>
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy

-------------- 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/20171031/4a2c1866/attachment.asc>

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

Subject: Digest Footer

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


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

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