On Thu, Apr 24, 2014 at 9:52 AM, Ralf Weber <[email protected]> wrote:
> Moin!
>
>
> On 24.04.2014, at 15:28, "Tirumaleswar Reddy (tireddy)" <[email protected]> 
> wrote:
>
>>> -----Original Message-----
>>> From: dns-privacy [mailto:[email protected]] On Behalf Of 
>>> Nicholas
>>> Weaver
>>> Sent: Thursday, April 24, 2014 1:58 AM
>>> To: Paul Wouters
>>> Cc: dnsop; Nicholas Weaver; [email protected]
>>> Subject: Re: [dns-privacy] [DNSOP] DNS over DTLS (DNSoD)
>>>
>>>
>>>> On Apr 23, 2014, at 1:00 PM, Paul Wouters <[email protected]> wrote:
>>>> No, I fully disagree with this. Port 53 TCP has a much better chance
>>>> at working these days than a random other newly assigned port.
>>
>> On the contrary, Firewalls are configured today to permit UDP port 53 and 
>> block TCP port 53. Why should firewalls change their configuration ?
> I know lots of firewalls that also allow TCP/53, but the real problem with 
> all these middle boxes that make changing DNS hard is that they believe to 
> understand the full protocol and only pass what they think is right. So 
> everything new we come up will be dropped (Been there, done that). We have to 
> be very careful with changes to the DNS protocol if we want them to be 
> deployed

+1

If you want to use TLS with DNS then use port 443. One of the effects
of firewalls is that we now only have three ports for all protocols:

Port 80/UDP: Non SSL traffic
Port 443/TCP: SSL traffic
Port 53/UDP: DNS

Which is why the HTTP/2.0 crowd have adopted 'always TLS', not for
encryption, they want to bypass firewalls. And the reason some of us
are pushing back on that is that some of them propose weakening TLS to
make this practical.

Now this approach is of course reprehensible. People are deploying
firewalls for legitimate reasons. And there are some circumstances in
which your traffic not getting out is exactly what should happen.

There are also circumstances where censorship bypass is important and
legitimate.


If you want to run DNS over TCP then I suggest that you simply build a
mechanism to advise on the port to use into whatever upgrade mechanism
you attempt. Then you can use 443, 8443, whatever works.

But the result is rather Rube-Goldberg. My version of digg exploded
from a few hundred kb to 2Mb because it now has the whole of OpenSSL
embedded. (Although the same might well happen if I implemented
DNSSEC)

I don't like that approach. TLS is optimized for a particular purpose
and DNS is a very different problem. We end up using only a fraction
of the features. And as heartbleed shows, an unused feature can still
cause failure. In fact its always been the underused parts of TLS
where problems have emerged - client auth, renegotiation, heartbeat.


I would prefer to separate out the key negotiation from the DNS
protocol. The complex part is the key negotiation. Applying crypo to
messages is pretty easy (albeit not foolproof as heartbeat shows).

One of the features you will note in both CBOR and JSON-B is that we
both use byte length markers to specify the length of binary and text
fields but we don't use them to denote lists or structures.

There is a good reason for that, using byte counts to measure
structures is inherently ambiguous if the inner lengths are larger
than the outer.


Just finishing up a draft. Got to get over this cold first.

-- 
Website: http://hallambaker.com/

_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to