Re: [Doh] WG Review: DNS Over HTTPS (doh)

[Phillip Hallam-Baker <[e-mail]>]

Replying to many threads.

1) I am glad to hear that it is agreed that any WG in this area will 'be a
marathon'. This is an important problem and it needs to be done right. And
that means discussing the set of use cases to be addressed, developing
requirements and only then looking at solutions. Do it right or not at all.

2) WS-* did too achieve its principal goal of making work for consultants.
It looked promising at first and then...

3) We might well want to delay a decision on this issue until after the IAB
ename workshop which might well lead to a game changer.

4) I agree with Mark Nottingham that this is an API thing and that IETF
does not own the specs where the key APIs are defined. That is WebAPIs for
JS (W3C) and POSIX.


But here is the thing, if IETF says a DNS interface should look like X then
by golly, I bet W3C and POSIX etc. will be only too happy to follow the
lead. And the strange thing is that IETF has already got a DNS Interface
which is really, really good and not the ones I proposed:

https://tools.ietf.org/html/rfc6763

It has Apple's name on the spec so there is one major platform on board.
And it is 2013 and supported by quite a bit of running code. The only real
problem with the spec is that it is presented as 'one option' on how to do
service discovery.

Please, do not give me six ways to do a thing, give me one. And do not let
application developers choose either. Pick one method that serves all the
requirements and tell people to stick to it unless there is reason not to.
Standards are all about taking away choices that don't matter. Have six
ways to implement service discovery and I have to implement whichever one
is picked for a protocol myself. Pick just one as the default and it will
be there for me in a library.

Yes, we can grandfather legacy protocols like HTTP and SMTP. But lets not
force everyone to implement everything.


The only problem I have with RFC6763 is that the power of the idea had to
be hidden to get through process. This draft takes the ideas in RFC6763 and
takes them to their logical conclusion:

http://prismproof.org/Documents/draft-hallambaker-json-web-service.html


In short, what I think the Javascript, C, C# API for service discovery
should look like is:

Connection = Interface.GetService (<address>, <protocol>)

for example:

Connection = Interface.GetService ("example.com", "_http._tcp")

That is it. I want all the extraneous stuff to go away or be hidden as
options. It should be possible for the DNS records to force use of a
security enhancement (e.g. a specific version of TLS with specific trust
anchor)


That API could be implemented using existing DNS protocol at the client
certainly. The incentive to change the client-resolver protocol would be
motivated by latency, not by functionality. The big problem with DNS is
that the protocol is only reliable for one request and one response and
even if you could do multiple requests in one packet, the discovery
mechanisms are more complex and inherently require multiple round trips.