Firstly you are insane to recommend dropping PTB’s.  That will break lots of 
things
including TCP.

Secondly we could just use a well known TSIG key and have the authoritative 
servers add
it to their configuration today, especially the root and TLDs servers.  The 
recursive
servers could also add the key for root and TLD servers they know have 
installed the
the well known key.  This is easy to test with tools like dig.

e.g.

key "." {
        algorithm hmac-sha256;
        secret "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=";
};

server <address> { key “.”; };

Auto configuring the key can come in the next revision of the software and 
would handle
FORMERR/NOTIMP (STD-13 errors) and NOTAUTH/BADKEY (expected error from TSIG 
implementations)
by falling back to non-TSIG queries when talking to a server using the well 
known key without
it being explicitly configured.  If using the well known key with a server is 
explicitly
configured fallback to non-TSIG messages would not occur.

Yes, some implementations may need to add TSIG support.  The majority already 
support
TSIG, it is just a matter of configuring the key.

https://ednscomp.isc.org/compliance/alexa1m-tsig-wkk.txt

Below are typical error responses as well as a one from a server with the key 
configured.

% dig soa . @b.root-servers.net -y 
hmac-sha256:.:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
;; Couldn't verify signature: tsig indicates error

; <<>> DiG 9.13.1 <<>> soa . @b.root-servers.net -y 
hmac-sha256:.:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOTAUTH, id: 42384
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 2
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: af1f5afe5008ef28ac57d36f5bdf617e3364284dfc68df28 (good)
;; QUESTION SECTION:
;.                              IN      SOA

;; TSIG PSEUDOSECTION:
.                       0       ANY     TSIG    hmac-sha256. 1541366142 300 0  
42384 BADKEY 0 

;; Query time: 178 msec
;; SERVER: 199.9.14.201#53(199.9.14.201)
;; WHEN: Mon Nov 05 08:15:42 AEDT 2018
;; MSG SIZE  rcvd: 96
;; WARNING -- Some TSIG could not be validated

% 

% dig soa . @a.root-servers.net -y hmac-sha256:.: 
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
;; Couldn't verify signature: expected a TSIG or SIG(0)

; <<>> DiG 9.13.1 <<>> soa . @a.root-servers.net -y 
hmac-sha256:.:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: FORMERR, id: 38857
;; flags: qr rd; QUERY: 0, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; WARNING: EDNS query returned status FORMERR - retry with '+noedns'

;; Query time: 279 msec
;; SERVER: 198.41.0.4#53(198.41.0.4)
;; WHEN: Mon Nov 05 08:14:45 AEDT 2018
;; MSG SIZE  rcvd: 12
;; WARNING -- Some TSIG could not be validated

% 

% dig soa . @127.0.0.1 -y 
hmac-sha256:.:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= 
;; BADCOOKIE, retrying.

; <<>> DiG 9.13.1 <<>> soa . @127.0.0.1 -y 
hmac-sha256:.:AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 63699
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: a2986dd7ec4014f14a25b1d85bdf6805e53cda0537bd7b68 (good)
;; QUESTION SECTION:
;.                              IN      SOA

;; ANSWER SECTION:
.                       86400   IN      SOA     a.root-servers.net. 
nstld.verisign-grs.com. 2018110401 1800 900 604800 86400

;; TSIG PSEUDOSECTION:
.                       0       ANY     TSIG    hmac-sha256. 1541367813 300 32 
NJNkcTXIjQ4PWVc6o9RNqXIzjofXDMpTlrXCEKJ1EQ4= 63699 NOERROR 0 

;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Nov 05 08:43:33 AEDT 2018
;; MSG SIZE  rcvd: 203

% 

Mark

> On 5 Nov 2018, at 3:36 am, fujiw...@jprs.co.jp wrote:
> 
> It is time to drop fragmentation (and pMTU discovery) in DNS.
> 
> A research paper showed that there are many authoritative servers that
> accept any ICMP destination unreachable / fragmentation needed and DF
> set (pMTU response packets) and reduce packet size up to 296 bytes.
> Path MTU discovery is controlled by any attacker.  Then the authors
> sent trigger queries and did second fragmentation attack to CA's
> resolvers.
> 
>  https://dl.acm.org/citation.cfm?id=3243790
>  Domain Validation++ For MitM-Resilient PKI
>  Markus Brandt, Tianxiang Dai, Amit Klein, Haya Shulman, Michael Waidner
>  Fraunhofer SIT, TU Darmstadt
> 
> Proposed solution is not good. DNS with TCP transport is enough, I think.
> 
> I would like to propose to drop fragmentation and pMTU discovery in DNS.
> 
> Authoritative servers should drop ICMP fragmentation needed,
> set static EDNS buffsize 1220, and set DF bit in responses.
> 
> On resolver machines, I would like to drop fragmented response packets.
> We can write IP filter that drop fragmented packet to resolvers,
> but it is not beautiful.
> 
> --
> Kazunori Fujiwara, JPRS <fujiw...@jprs.co.jp>
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: ma...@isc.org

_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to