Re: [DNSOP] order of records in DNAME responses
* Evan Hunt [2017-02-24 00:24]: > I'd like to start a discussion of that now. Does anyone have a problem > with the idea of clarifying the protocol here, saying that the order of > records in the answer section of a chaining response is significant, and in > particular, that a DNAME MUST precede the corresponding synthesized CNAME? Do you mean clarifying as in "how it always was meant to be but stated in unclear words" or as in "change to protocol"? In the latter case, you'd still need code to parse responses from implementations that don't make assumptions about the order of records. Regards, Matt smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Stupid thought: why not an additional DNSKEY record flag: NSEC* only...
Paul Hoffman wrote on 2017-01-05 20:44: >> A pre-computed chain does not provide the same benefit. It increases the >> enumeration cost in terms of network queries (CPU time is of less >> importance here because the collection process is network-bound except >> for the very last few NSEC3 records). Enumeration remains feasible with >> pre-computed chains unless you re-salt and re-sign the zone in an >> interval, which is shorter than the duration needed to send one query >> for each NSEC3 record in a zone. > > Doesn't that last sentence assume that the attacker has a complete > dictionary of possible values in the zone? To collect an NSEC3 record it suffices to find a random non-existing name, whose hash value cuts the NSEC3 record. This does not require a lot of hashing attempts and a dictionary is not required. By keeping track of which NSEC3 records you have already seen, you only need to send network queries for hash ranges not yet discovered. This gives you the whole NSEC3 chain, though not the cleartext names yet. The cost for recovering cleartext names depends on the iteration count and the number of candidate names you try (i.e. size of dictionary), but not (or maybe little) on the size of the chain. Regards, Matt smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Stupid thought: why not an additional DNSKEY record flag: NSEC* only...
* Paul Hoffman [2017-01-05 18:05]: >> NSEC3 lies work today, but people worry that NSEC3 might have server >> compromise compromise the ZSK. > > NSEC3 lies can also be created with pre-computing, but at a cost of > greatly increasing the size of the zone. NSEC/NSEC3 lies prevent enumeration effectively when they're minimally covering because it's infeasible to ever collect such a chain. A pre-computed chain does not provide the same benefit. It increases the enumeration cost in terms of network queries (CPU time is of less importance here because the collection process is network-bound except for the very last few NSEC3 records). Enumeration remains feasible with pre-computed chains unless you re-salt and re-sign the zone in an interval, which is shorter than the duration needed to send one query for each NSEC3 record in a zone. Regards, Matt smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Stupid thought: why not an additional DNSKEY record flag: NSEC* only...
* Mukund Sivaraman [2017-01-04 19:24]: > Assume an attacker is able to spoof answers, which is where DNSSEC > validation helps. If a ZSK is leaked, it becomes a problem only when an > attacker is able to spoof answers (i.e., perform the attack). > > What you're saying is that with a special NSEC3-only DNSKEY compromise, > "attacker can only fake an NXDOMAIN". If an attacker can fake NXDOMAINs > and get the resolver to accept them, that's as bad. The attacker can > deny all answers in the zone by presenting valid negative answers. This > is why we have proof of non-existence that needs to be securely > validated. A special NSEC3-only-DNSKEY's compromise isn't a better > situation than a ZSK compromise. You're right if you're only considering denial of service. If you take phishing or email hijacking into account, an NSEC3-only compromise is a better situation than a ZSK compromise (or at least a different attack class, whether or not better). With DANE, however, it's not just denial of service anymore: NXDOMAIN spoofing cancels the protection provided by DANE. So we have the cost of a protocol change vs. the benefit of protecting from bogus records (but not from DoS or DANE downgrade)... Regards, Matt smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DNSSEC in draft-ietf-dnsop-resolver-priming
Paul Hoffman wrote on 2016-01-23 21:47:
> On 22 Jan 2016, at 14:44, Wessels, Duane wrote:
>
>> I think I'm okay with "resolvers SHOULD send DO when priming." Seems
>> like BIND and Unbound already do this.
>
> Noted. Waiting to hear from a bunch more people on this.
No objection.
>> Do we also need to say that the resolver SHOULD/MUST retry with DO=0
>> if there is no response to the first priming query?
>
> Personal opinion: yes for SHOULD, but we need to integrate it with the
> earlier text about going to a different server if you don't get a
> response within 2 seconds.
This is only useful if validation is disabled and should be stated
accordingly.
>> The more important question may be: what shall the resolver do if
>> validation of the priming response fails? I'm skeptical that we, as a
>> group, will be willing to say that the resolver should refuse to
>> forward any queries to a root unless validation succeeds.
>
> Personal opinion: agree. We can say that it is local policy. One
> possible policy is to keep trying other hints until one response validates.
Yep, this matches the standard implementation behavior of handling bogus
responses: discard response and try again. If it keeps failing, give up
and don't update the root hints. There's no need to stop communicating
with root.
There's another issue: once root-servers.net is signed, the priming
response will contain RRSIG in the ADDITIONAL section.
1) What if there's not enough space for all RRSIG and the server omits
some of them? (which seems to be allowed according to RFC 4035 Sec. 3.1.1)
2) What if the ANSWER section validates (i.e. response is not bogus) but
some of the addresses in the ADDITIONAL section fail to validate?
I suggest that validators use the following approach:
- If root-servers.net is signed, validate the ANSWER section as usual.
- Attempt to validate all address records. If any of them is bogus or
incomplete (A, or RRSIG missing), query directly for the server
name and validate the response, e.g. A/a.root-servers.net.
This behavior is consistent with Sec. 4.2 in the current draft ("...
issue direct queries for A and RRSets for the remaining names.")
Regards,
Matt
smime.p7s
Description: S/MIME Cryptographic Signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Comments regarding the NSEC5
* Paul Hoffman [2015-03-24 13:57]: On Mar 23, 2015, at 6:23 PM, Jan Včelák jan.vce...@nic.cz wrote: - The statement about NSEC3 offline dictionary attacks are still possible and have been demonstrated doesn't take into account trivial changes that an operator can choose to take if they are really concerned about offline dictionary enumeration (with the trade-off being zone size). Please, can you clarify which trivial solution in particular do you mean? Sure. When signing the zone, instead of creating one NSEC3 record for a gap, you create 10 or 100 with random intervals between the two hashes. That way an attacker is more likely to get results that will not match dictionary entries. This slows down the online hash collection but not the offline dictionary enumeration. The attacker will have to send 10 or 100 times as many queries (which of course the server administrator pays by having to send 10 or 100 times as many negative responses). In the offline attack, the performance is dominated by the effort for hashing the input dictionary. Whether you're matching the output against 1000 or 10 hash values has little influence on the total performance. Regards, Matt smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] various approaches to dns channel secrecy
* Paul Vixie [2014-07-06 19:29]: Matthäus Wander wrote: * Paul Vixie [7/5/2014 7:47 PM]: Matthäus Wander wrote: DTLS works on top of UDP (among others) and thus can pass CPE devices. no, it cannot. DTLS does not look something that the CPE was programmed to accept; thus in many cases it is silently dropped. DTLS can be used on top of UDP. CPE devices allow outgoing UDP sessions to arbitrary ports. If they didn't, many online games and VoIP applications would not work. it's possible to find single counter examples to almost any assertion. My point is that for a significant portion of Internet users, e.g. residential, HTTPS tunneling is not necessary. HTTPS tunneling should not be mandatory if it comes with disadvantages to a large user base who don't need it. The extra HTTPS layer suggests negative performance implications compared to a tailored protocol (maybe negligible, maybe not). Requiring TCP/443 is a dealbreaker when the port is already occupied by a small business web server or by an administration interface on a plastic device. however, consider RFC 2671 (EDNS), published fifteen years ago. because it changes the format of a UDP/53 datagram, there is silent loss across most CPE boundaries. [...] that fix is not going into the O(10^9) CPE devices now in place, ever. if we can't get this right for EDNS in 15 years, my bet is that another 15 (or 150) years of trying won't produce better results. in fact, by jim gettys and dave taht i've been made to understand that the world's CPE problem is much worse than i knew. we might be able to fix it for the next billion devices some day, but the devices shipping today are still crippled. Agreed. incentives are such that a CPE provider hopes to sell web access, not internet access. your counter-example of DNS gaming does not change the treatment now accorded UDP/53 at the internet edge. if you seriously think that a DTLS solution can be universally deployed, including in hotel rooms, home CPE environments, coffee shops, and mobile, then you and i are having a same planet, different worlds experience, and i wish you well on your walk. I didn't mean to imply that a DTLS solution can be universally deployed. I'm just not convinced that mandatory HTTPS tunneling built into a new DNS protocol is the appropriate solution here. My experience is that HTTPS tunneling is unnecessary in most (not all) networks. If I want to use SSH or VoIP in one of those crippled networks, I need a generic tunneling solution anyway. Admittedly, if I only need the web in a crippled network then encrypted DNS over HTTPS is a plus. That use case seems very narrow. Regards, Matt smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] various approaches to dns channel secrecy
* Paul Vixie [7/5/2014 7:47 PM]: Matthäus Wander wrote: DTLS works on top of UDP (among others) and thus can pass CPE devices. no, it cannot. DTLS does not look something that the CPE was programmed to accept; thus in many cases it is silently dropped. DTLS can be used on top of UDP. CPE devices allow outgoing UDP sessions to arbitrary ports. If they didn't, many online games and VoIP applications would not work. Here's an example DTLS session passing my DSL router at home: https://www.cloudshark.org/captures/7d2ae4cfe155 Source code found here: http://marc.info/?l=openssl-usersm=113009464321966w=3 Regards, Matt smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-zhang-dnsop-weak-trust-anchor.txt
Hi, Section 4: If the resolver was configured with a weak trust anchor and got nothing after sending a request with DO bit set, then it should clear DO bit in the EDNS0 in the query message and query again to the authoritative name server. So it could receive a normal DNS message (with no DNSSEC information, if the previous packet loss was caused by large size) and continue its DNS query process, then return the result as an insecure message. The concept is vulnerable to downgrade attacks: - An on-path MITM attacker can drop DNSSEC messages to force insecure DNS and then spoof bogus DNS responses. - An off-path attacker can saturate links to delay/drop DNSSEC messages to force insecure DNS and then spoof bogus DNS responses. The interoperability problems can be solved without degrading security, e.g. fall back to TCP. Regards, Matt -- Universität Duisburg-Essen Verteilte Systeme Bismarckstr. 90 / BC 316 47057 Duisburg smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Bill Woodcock [2014-03-27 23:54]: On Mar 27, 2014, at 10:14 AM, Matthäus Wander matthaeus.wan...@uni-due.de wrote: Here's a small statistic about RSA key lengths of 741,552 signed second-level domains (collected on 2014-01-27, counting KSK and ZSKs): 1024 bit: 1298238 2048 bit: 698232 1280 bit: 28441 4096 bit: 25326 512 bit: 8893 1536 bit: 385 Matthäus, do you have an easy way of separating out KSK from ZSK in your statistics? FWIW, we’re currently doing 2048-bit KSK and 1024-bit ZSK, but will shortly be transitioning to 4096-and-2048. Yes, here you go: KSK: 2048 bit: 668634 1024 bit: 49861 4096 bit: 22646 512 bit: 2460 1280 bit:812 1536 bit:314 ZSK: 1024 bit: 1248377 2048 bit: 29598 1280 bit: 27629 512 bit:6433 4096 bit:2680 1032 bit: 310 Regards, Matt - -- Universität Duisburg-Essen Verteilte Systeme Bismarckstr. 90 / BC 316 47057 Duisburg -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTNZ9WAAoJEFaVlPYoUriue2oH/1ObggrmrVD/xhLkGJgrmJtT lVmiKufrAr4ega+xfdnpAGl3auYDmVzjBbjXUrmFRTb7vc0uuSIpBLpNWCHeFqN+ a3cQfltBquLGJ42vqo4t3PEbNspp+D/eP7ctqFj0qC3QALLgzrYLzBroH/TpErT6 050hqBkbwZghfVgZ37j+3hSfnRkr9gbpQSEstv95WVXQ3PKInz8JclE76fu8iG52 L0yRv2Iv23DF+2Zha0j3v7xP99mEVvnoifMk2KLKjFt+/VpTgKuzDxg/s/sMTRJp KIuneTmaaDqBwPB2d/9/ieuwjIm+O39Hu37qkWBwlmZGwv2D1bvRXBJCaoC7kvE= =FuVG -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Whiskey Tango Foxtrot on key lengths...
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Nicholas Weaver [2014-03-27 14:56]: So why are both root and com and org and, well, just about everyone else using 1024b keys for the actual signing? Here's a small statistic about RSA key lengths of 741,552 signed second-level domains (collected on 2014-01-27, counting KSK and ZSKs): 1024 bit: 1298238 2048 bit: 698232 1280 bit: 28441 4096 bit: 25326 512 bit:8893 1536 bit: 385 Plus ~700 odd-sized RSA keys and ~250 DSA/GOST/ECDSA keys. A domain owner of one of the 512-bit keys told me, it was the default config in the signing tool he had used. Regards, Matt - -- Universität Duisburg-Essen Verteilte Systeme Bismarckstr. 90 / BC 316 47057 Duisburg -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTNFx3AAoJEFaVlPYoUriuqfQIAIhyRBYSoqQhjw3KnvmRt0Lm 1vurP5DPFUIpTGyZj5wvVfcj3SQvQ9ULivv+wYZ+XgnOyRf8JSfo62gcC69qED7J Meq8ZPnrG03SfFqaKdv/ArgMBxXBUZxxxixsbHrk80CuHOpdBnqXB0tvbFlRtEyG RHLUNK7vKPDFTnQXRErugtSrfJy1km49hq4SG3bGdTWfOLre3ML6QDDzFw/kb6AD r18sB3yBpFv6uXm98/2lNFDgBzvEBSUyU/abhQQNb/0H9Y8S+ekxXe1JfQEKdpIi F3Gazx6WfaJtHQRqJhEcTeP08eKMTGNMRlp3hzF8v7UmrocowXPW+xDWMsqUWtU= =lCBt -END PGP SIGNATURE- smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-fanf-dnsop-trust-anchor-witnesses-00.txt
* Tony Finch [2014-02-13 21:56]: There was some discussion last month about dispersing trust in the root. http://www.ietf.org/mail-archive/web/dnsop/current/msg10977.html This inspired me to write up a concrete proposal for the quorum-of-witnesses idea that I have vaguely suggested several times over the last few years. The proposed approach disperses the trust into which TA to choose and when to rollover to a new TA. However, it does not disperse the trust that the TA is not misused and not compromised. If I have to fully trust the TA private key holder anyway, my personal assessment would be to trust their TA publication channel as well, e.g. the ones in draft-jabley-dnssec-trust-anchor. The problem I see is the asymmetry of roles between the TA private key holder and the witnesses. The witnesses have no means to assert that the TA holder does not share the key with their government or anybody else. To disperse the trust of a key, you would need a threshold cryptosystem where the TA private key portions are shared among equal peers. Regards, Matt -- Universität Duisburg-Essen Verteilte Systeme Bismarckstr. 90 / BC 316 47057 Duisburg smime.p7s Description: S/MIME Cryptographic Signature ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] draft-hoffine-already-dotless
* Tony Finch [2013-09-30 13:41]: I've just done a rough deliverability test to postmaster@TLD for the TLDs with MX records. This just checks that the RCPT TO command is accepted. The results show that even if your site will let you send mail to these domains, it still mostly won't work. [...] ua mr.kolo.net. BAD [...] You may want to consider greylisting, ua works for me. I didn't test the other ones, though. Regards, Matt -- Universität Duisburg-Essen Verteilte Systeme Bismarckstr. 90 / BC 316 47057 Duisburg smime.p7s Description: S/MIME Kryptografische Unterschrift ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
