Subject: Re: [DNSOP] draft-zhang-dnsop-weak-trust-anchor.txt

From: "张海阔" <[email-masked]>
Date: Sat, 31 May 2014 17:55:58 +0800

The TCP is an optional protocal for DNS query at the auth name server side, and is not mandatory, 
so not every DNS service will support TCP.
so I think we should provide a method to get rid of it by UDP protocal.

thanks for your feedback.

haikuo 

------------------ origin email ------------------
>From: Paul Wouters <[email-masked]>
>Reply-To: 
>To: "[email-masked]" <[email-masked]>
>Cc: dnsop <[email-masked]>
>Subject: Re: [DNSOP]  draft-zhang-dnsop-weak-trust-anchor.txt
>Date: Fri, 30 May 2014 14:11:45 -0400 (EDT)
>

On Fri, 30 May 2014, [email-masked] wrote:

> Name: draft-zhang-dnsop-weak-trust-anchor

> URL:http://www.ietf.org/internet-drafts/draft-zhang-dnsop-weak-trust-anchor-00.txt
> Status:https://datatracker.ietf.org/doc/draft-zhang-dnsop-weak-trust-anchor/
> Htmlized:http://tools.ietf.org/html/draft-zhang-dnsop-weak-trust-anchor-00
> 
> 
> Abstract:
>  DNS Security Extensions (DNSSEC) is an effective method to provide
>  security protection for resolvers and end users in the DNS protocols.
>  But the DNSSEC is too aggressive for the DNS service in the poor
>  network infrastructure, because the domain name will be invisible
>  when large DNSSEC messages were dropped by some other network
>  equipments, like the routers which have MTU problem or the old
>  firewalls which do not support ENDS0. This document defines a new
>  concept weak trust anchor which can be used on a security-aware
>  resolver to get rid of the above problem.
> 
> 
> I am looking for feedback for this draft, feel free to comment.

A very skeptical person would describe this draft as a protocol backdoor
to disable DNSSEC to faciliate DNS spoofing to unwitting victims.

The draft claims to address two problems:

1 MTU issues with DNSSEC by misconfigured firewalls dropping
   large (and/or fragmented?) UDP.

2 old firewalls dropping EDNS0 packets by not recognising these as valid
  DNS packets.

The first issue is not a problem, the DNS software could request smaller
UDP packets using EDNS0, or it could fall back to TCP. No protocol
modifications are required for this to work.

The second issue is about broken software for a standard released in
August 1999 (RFC 2671), and assumes that the end hosts will actually
timely update by implementing this new 2014 document???

And to accomodate such broken software, it would requires the client to
completely disable DNSSEC when the network filters out expected DNSSEC
responses to queries it sent, without being able to tell this packet
drop was due to "old firewalls" or a MITM attack.

If this document is really meant to assist newer endnodes from operating
in old broken networks, you should find a way to accomplish this that
does not require disabling DNSSEC and does not require any DNS protocol
change.

Note also that for this problem, there is already a commonly deployed
solution at the application level that addresses this situation, such
as https://www.nlnetlabs.nl/projects/dnssec-trigger/ which will inform
the user the network is severely broken or the user is under attack,
and gives the user the option to disable DNSSEC and go "insecure".
Contrary to the proposed draft, the user is informed and consent is
requested before disabling a security control the user has activated
for good reasons on their system.

I do not believe your stated problem is one that needs addressing.

I do not believe the Security Considerations section of your draft
even remotely begins to address the problems of completely disabling
DNSSEC transparently without user consent.

Paul

---

From: Mark Andrews <[email-masked]>
Date: Sat, 31 May 2014 20:35:27 +1000

In message <[email-masked]>, "=?gb2312?B?1cW
> thanks for your feedback.

TCP has never been optional.  Optional is MAY.  TCP was part of the
base spec. RFC 103[45].  RFC 1123 said SHOULD. i.e. you need to
have a very good reason to not implement it.  TCP has since been
made a MUST RFC 5966.  As for DNSSEC you would be insane to disable
TCP if you are serving a signed zone.

Mark
 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]