Subject: [Add] Functional requirements?

From: Brian Dickson <[email-masked]>
Date: Wed, 10 Apr 2019 18:05:32 -0700

Some of the discussions have shed some light on the underlying issues.

I think it would be helpful to ferret out the actual (functional)
requirements as articulated by various parties, or on behalf of those not
currently in the conversation per se (users, host administrators, network
administrators, security folks).

Getting to the bottom of these, and separating the "what" (goal) from the
"how" (mechanisms, protocols, whatever), can hopefully create enough
flexibility to start finding solutions that meet the functional
requirements, without requiring actual compromise on what those
requirements are.

I'd like to propose specific functional requirement for refinement, and
once refined, to get feedback from folks on how they view those
requirements.

Since there will no doubt be opinions, I suggest ways of making the
assessments of those requirements both concrete, and expressive.

I'm thinking that a numeric score would be useful, where a negative value
means "opposes", a positive value means "supports", a zero means "don't
care", and the size of the positive/negative expresses how strongly the
position is held. There's not much point in having a lot of fine-grained
values; orders of magnitude are called for. I suggest values "1", "100",
"10000", and "100,000,000" (i.e. 1e0, 1e2, 1e4, and 1e8), where the largest
value is basically, "You realize, of course, this means war."

I'll go first, with what I perceive as examples of actual functional
requirements:

   1. "The application needs to know that the DNS query is encrypted to the
   DNS resolver".
   2. "The application need to know the identity of the DNS resolver used."
   3. "The machine administrator needs to provide (i.e. restrict) the
   choice (or choices) of DNS resolver."
   4. "The machine administrator and/or network administrator need to
   provide the choice (or choices) of encrypted transport."
   5. "Each application/user combination, should be free to select the
   choice of DNS resolver and encrypted transport, from among those
   offered/available on the host OS."
   6. "The encryption used should be a minimum of TLS1.3."
   7. "The host OS should be the sole intermediary for establishing DNS
   resolver connections, and the applications should only do DNS resolutions
   by way of such an intermediary."
   8. "The host OS intermediary should not have access to the unencrypted
   DNS queries."
   9. "The host OS intermediary or the application, should validate server
   TLS certificates before using any given TLS connection."
   10. "Policies may be imposed on the host administrator regarding allowed
   options for encrypted transport. The host administrator may enforce those
   policies."

And now I'll provide an example of why it is necessary to tease out the
real functional requirements.

SF has previously stated, "Basically, if the application wants to know that
DNS privacy
is being applied, it has to do it itself."

I hold this to be not technically true. So long as the application does the
TLS key exchange, it can do so cooperatively with some other application
controlling things like the establishing the TCP connection (including
resolving the IP address of the named endpoint), and pre-validating the
offered server TLS certificate.

I'm not intentionally picking on SF here. I am using this one example to
illustrate that there is value in everyone examining their own positions,
and being as precise as possible without over-simplifying or overstating
the actual requirements.

I agree with Ray, that having things continue to operate in a centralized
manner is highly preferable (and I stated so before.) However, I think that
as long as we can all come to agreement on what the real (functional)
requirements are, we can pave the way for multiple implementations of the
central function, rather than restricting it to what the libc maintainers
are willing to agree to.

The end result should be, IMHO, analogous to the UI interaction of, "Foo is
not your default DNS resolver proxy; would you like to change it?", much
like it is/was with the choice of default browser. And the applications who
want DNS privacy should be able to interoperate with any such
implementation, i.e. the specifications should enable interoperability.

Let's start with the requirements, and see how far we can get?

Brian

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 11 Apr 2019 07:47:00 +0100

Hiya,

Not sure about the idea of scoring requirements. Could be
a good one or not - I'll need to ponder it.

Just on this bit...

> offered server TLS certificate.

It would be possible yes to have TLS run via some TCP proxy
Hard to see the point though.

It is not possible for such a TCP proxy to see the TLS server
cert with TLS1.3 unless that TCP proxy is a TLS MitM attacker,
in which case someone has to have configured the application
and the TCP proxy is unnecessary in the first place, for the
enforcement of admin policy.

With TLS1.3 such a TCP proxy can still apply it's policy based
on the SNI in the ClientHello. That may however also go away
with ESNI (it'll not be clear how widely that can be deployed
for maybe a year or so, but I'd hope the answer is "widely";
there'd also be a bootstrap issue to tackle with using ESNI
whilst contacting your fav DNS recursive but that may be
solveable.).

With TLS1.2 sure, such a TCP proxy could check the SNI or the
server certificate. (Earlier TLS versions are in the process
of being deprecated so we don't need to worry about 'em, but
they're the same as TLS1.2 in this respect.)

However, I don't see what'd motivate an application developer
to use such a weird TLS stack, nor do I think it'd be likely
that that weird stack would work everywhere, meaning that the
application developer would also need a normal TLS stack. I'd
guess in such a situation application developers would just
not bother with the weird TLS stack at all.

So I don't think that scenario is likely enough to warrant
much study TBH.

> 
> I'm not intentionally picking on SF here. 

I don't feel picked on at all! You and anyone should feel
entirely free to pick holes in whatever silliness I emit.
(I am however assuming I'm the SF you mean, be embarrassing
if I' wrong there:-)

Cheers,
S.