On Mon, Mar 25, 2019 at 8:52 AM Patrick McManus <mcma...@ducksong.com>
wrote:
> I'm not pushing against DoT per se in this thread, I am pushing against
> the notion that a client has an obligation to the network to provide a
> clear channel for traffic analysis and downgrade triggers.
>
I think it would be better to not combine (and conflate) two or more issues
(which may not be directly related).
Plus, this is approaching a "straw man" argument: the notion of
"obligation".
I might not have been clear enough previously. I am arguing against
obligating client applications to take actions that users have not
explicitly given permission to do.
In this case, the action is: "Use Do{HT} service X".
If X is not on the user's list of Do{HT} providers the user has
selected/configured, then my position is the user MUST be prompted prior to
using X, or absent a user interaction mechanism (UI), then X MUST NOT be
used. This includes the case where X is Do53 (regular DNS), if the user has
selected/configured that Do{HT} is required.
In other words, I am proposing that clients not be built so as to be
susceptible to downgrade attacks (whether by the network operator, or by an
attacker). This is directly analogous to attacks on TLS itself for
downgrading TLS versions or cipher selections. In fact, IMHO, Do{TH} should
take a page from the whole TLS state machine, where the client selects
among the servers' offered parameters, possibly deciding to not complete
the handshake if any of a host of issues are discovered (cert validation,
among others).
>
> One of the notions presented here is that unauthenticated RST injection
> forgery is an acceptable, perhaps in the minds of some even desirable,
> signal for DoT to trigger downgrades and, further, that clients are
> obligated to create a clear signal to the network to enable this approach.
>
This is a separate issue.
Other than blocking all-but-a-few (or all, or a few) DoT servers, I do not
believe anyone has proposed explicit downgrade triggers. Or do you mean,
when a DoT connection is blocked by e.g. a firewall (or other network
enforcement device), that an RST is generated? I believe the RST requires
sequence number validation before it can be processed by the TCP stack,
which means the entity doing the RST generally needs to be in the data
path. Other than "lucky guess" or "high volume attempts", I don't believe
RST to be a serious threat.
> One issue is that you cannot differentiate this signal between a party you
> may want to cooperate with (e.g. your enterprise controller) and an
> attacker - that's the nature of an unauthenticated injection. But there are
> authenticated enterprise configuration methods available for expressing
> policy directly to the client in a trusted way. Indeed my post centered
> around the notion of https interception being a necessary outcome of DoH in
> the enterprise - my point is basically if you can do https interception
> then you are doing enterprise config - consider a config to still do
> secured DNS with a server that implements the enterprise policy rather than
> doing interception.
>
I agree that there is a need for both service discovery (local and
pre-selected Do{TH} providers), and service *policy* discovery, ideally
authenticated and secured (subject to provider implementations adhering to
mechanisms to provide secure authenticity proofs).
>
> And if you do that an enterprise client can, by using its own do{th}
> server, also enjoy the benefits of transport security and be confident that
> the policy server it intends to use is actually the one in use.
>
I agree with this.
I believe there is widespread interest in solving this problem.
However, I believe there is a need for the solution to this problem being
coordinated between the DoH and DoT groups, seeing as the DNS operators
have a significant interest in both DoT and DoH being served on their
servers, and thus a strong interest in any relevant components (discovery,
validation, etc.) being uniformly specified across both protocols.
It might be worth having an AD/WG discussion on where these should be
developed; it might be better to do in DNSOP, rather than DPRIVE or DOH, or
alternatively spinning up a new, very focused WG for this work (I would not
be in favor of the latter).
Brian
> On Mon, Mar 25, 2019 at 6:35 AM Brian Dickson <
> brian.peter.dick...@gmail.com> wrote:
>
>>
>>
>> Sent from my iPhone
>>
>> On Mar 24, 2019, at 10:42 PM, Patrick McManus <mcma...@ducksong.com>
>> wrote:
>>
>>
>> On Sun, Mar 24, 2019 at 10:31 PM Brian Dickson <
>> brian.peter.dick...@gmail.com> wrote:
>>
>>>
>>> This is important for network operators in identifying encrypted DNS
>>> traffic,
>>>
>>
>> not all clients acknowledge a network's right to do such things at all
>> times. And of course it would be useful to tell the difference between
>> policy and a RST injection attack.
>>
>> If the client does acknowledge the network has the right to set policy -
>> then the policy can be set on the client using existing configuration
>> mechanisms that allow the client to differentiate between authorized
>> configuration and perhaps less-authorized folks identifying their DNS
>> traffic. This is well worn ground in the HTTP space.
>>
>>
>> What I find interesting, is that as far as I can tell, everything you
>> wrote applies equally to DoH and DoT, if the transport is the only
>> difference. E.g. Same client browser, same DNS service, accessed via DoH or
>> DoT.
>>
>> Are you suggesting (or claiming) otherwise, and if so, please elaborate?
>>
>> Brian
>>
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
