Going to try this again.
Who DNSSEC[1][2] here? Why do you use it? What do you use it for? Have you considered TLSA (DANE[3]), SSHFP[4], OPENPGPKEY[5] RRs yet? Discuss.
Perhaps you also use DNSCrypt[6] for encryption of your queries? Or maybe you like to encrypt everything and you're running DNSCurve[7]?
Newbies section:
>If you're thinking about registering your own domain, check if they offer DNSSEC. Some registrars automatically sign your zone, which means you most likely can already add your TLSA RRs and such. Other registrars offer to upload your DS RR, or your KSK/ZSK's public key instead. That's also nice if you wish to host your authoritative name server yourself.
There's also an interesting new IETF draft, SMTP STS[8]. Would be interesting to secure your MTA more.
[1] https://tools.ietf.org/html/rfc4033
[2] http://www.dnssec.net/
[3] https://tools.ietf.org/html/rfc6698
[4] https://tools.ietf.org/html/rfc4255
[5] https://tools.ietf.org/html/draft-ietf-dane-openpgpkey-08
[6] https://www.dnscrypt.org/
[7] https://dnscurve.org/
[8] https://tools.ietf.org/html/draft-margolis-smtp-sts-00
I'm running Unbound with DNSSEC validation from the IANA root.
If I had a domain, I'd definitely implement TLSA records.
I'd like ask you a question, OP.
How did you come to learn so much about DNS? Do you work with it? Do you have any resources that you can share? I just want to learn more, is all. Thanks.
>>53750764.
>I'd like ask you a question, OP.
>How did you come to learn so much about DNS? Do you work with it? Do you have any resources that you can share? I just want to learn more, is all. Thanks.
Well, I'm doing a masters in CS but I became very interested in DNS, and especially DNSSEC (I like cryptography in general). I have a good professor and he suggested me to start reading the RFCs, registering my own domain and just play with it. I did as he suggested and we sometimes discuss certain DNS aspects we both find interesting. I'm still learning a lot, but he still knows *way* more than I do.
I guess I can advice everyone the same who is interested in DNS. Start with the theory (RFCs and the DNS concepts in general) and then apply your new knowledge in practice. By learning the theory and then applying it your own domain it makes a lot of sense and you'll learn plenty.
i thought you dead, faggot
>>53750700
Recently installed this addon:
https://addons.mozilla.org/en-US/firefox/addon/dnssec-validator/?src=search
Need to actually sit down and read about it though.
Does it show green https address if i add it to my dns settings?
>>53751565
It's a good add-on to verify DNSSEC+DANE, but the web browser still warns when an X.509 certificate isn't signed by a trusted CA in its trust store, even when you created a TLSA RR with Certificate usage 3 (Domain-issued certificate), which doesn't rely on PKIX path validation.
So, yes, it does verify a domain's DNSSEC+DANE setup, but I'd like to see this functionality natively built-in to web browser itself. I.e., it should show a green lock in your URL bar when a domain entity successfully DANE validates, regardless of whether it PKIX path validates (unless specifically configured with the TLSA RR to do so).
The add-on its current state is a good debugging tool at this moment.
>>53751743
Very good question, because at this moment it still doesn't (yet), hence why many domains haven't incorporated TLSA RRs into their domains yet. See >>53751764 for a more detailed overview.
This is just a matter of time, but sadly the big bad CAs (Thawte and such) don't really like DANE, because DANE no longer requires you to have your certificate signed by them, which means they lose money, in a sense. You can just sign them yourself, like you could with Let's Encrypt, but now you are your own trusted CA, and you no longer depend on others.
>>53750700
>Going to try this again.
DNSSEC was shit the last time you asked and it's still shit now.
>>53752047
Want to expound on why it's shit? That accusation seems baseless.
>>53752391
>Based on archaic cryptosystems from decades ago
>Forced zone enumeration
>Gives a backdoor into your crypto infrastructure to the government that owns your .TLD
>Makes DNS amplification attacks even worse
>Doesn't add any relevant security to any relevant protocols
>>53752686
>>>53752391
>>Based on archaic cryptosystems from decades ago
These have been superceded by ECC[1] algorithms[2], which are more efficient and less computational intensive. I'd like to see Edwards-curve[3] being standardised, though. Here's the IETF draft: https://tools.ietf.org/html/draft-ietf-curdle-dnskey-ed25519-01
>>Forced zone enumeration
Try NSEC3[4], which mitigates enumeration. It's been around for years now.
>>Gives a backdoor into your crypto infrastructure to the government that owns your .TLD
You do understand public key cryptography, and the delegation of domains, right? If you do, then you would know that you generate your own keys. You could argue backdoors in the NIST standardised ECC cryptography, but that's why I'm waiting for Edwards-curve to be implemented.
>>Makes DNS amplification attacks even worse
You can mitigate this with proving NX with NSEC(3), setting a large TTL, and reject continuous bogus queries.
>>Doesn't add any relevant security to any relevant protocols
It does, especially with DANE. Integrity is literally part of the InfoSec CIA[5] triad.
[1] https://en.wikipedia.org/wiki/Elliptic_curve_cryptography
[2] https://www.iana.org/assignments/dns-sec-alg-numbers/dns-sec-alg-numbers.xhtml
[3] https://ed25519.cr.yp.to/
[4] https://tools.ietf.org/html/rfc5155
[5] https://en.wikipedia.org/wiki/Information_security#Key_concepts
I wish the dnscrypt autoinstall script by some dude on github wasn't broken
>>53752938
>You do understand public key cryptography, and the delegation of domains, right? If you do, then you would know that you generate your own keys.
You do understand what a chain of trust is, right?
Whoever owns the root keys can fake the entire chain of trust leading up to an arbitrary domain. Guess who owns the root keys for .ly, .com etc.?
>It does, especially with DANE. Integrity is literally part of the InfoSec CIA[5] triad.
Sure, DANE is probably the best example you could have given since X.509 root CAs are actually an example of a flawed cryptographic trust system - but I don't see any reason why I should trust the DNS root any more.
I already rely on e.g. HPKP to provide some degree of TOFU guarantees, since it's the next best thing to a proper trust system we have.
If you really want to replace the DNS system by something more secure, try something like NameCoin or other p2p systems that actually give you some degree of trust other than “come on goy, just trust me you dumb fuck”
>>53753213
>You do understand what a chain of trust is, right?
I do, but a web of trust like PGP relies on doesn't scale for every domain. A blockchain might, but ill get back to that later.
>Whoever owns the root keys can fake the entire chain of trust leading up to an arbitrary domain.
The TCRs[1] are very transparent in their procedure. Sure the US government is involved, but so is ICANN (IANA), RIPE NCC, ISC, et cetera.
>Guess who owns the root keys for .ly, .com etc.?
All TLDs have been delegated by IANA to whichever has a technical or.public interest. You can find more on this here (for ccTLDs): https://www.iana.org/help/cctld-delegation
>>It does, especially with DANE. Integrity is literally part of the InfoSec CIA[5] triad.
>Sure, DANE is probably the best example you could have given since X.509 root CAs are actually an example of a flawed cryptographic trust system - but I don't see any reason why I should trust the DNS root any more.
For the very reason you're understandably skeptical about the current PKIX CA system. DigiNotar messed up bad, and who's to say other CAs aren't messing up as well? I trust DNSSEC much more because it's transparent.
>I already rely on e.g. HPKP to provide some degree of TOFU guarantees, since it's the next best thing to a proper trust system we have.
Well, HPKP demands at least two valid X.509 certificates and pertains to web servers (only?). With DANE you also still demand PKIX path validation by CAs of your own choosing.
>If you really want to replace the DNS system by something more secure, try something like NameCoin or other p2p systems that actually give you some degree of trust other than “come on goy, just trust me you dumb fuck”
This I support, a blockchain makes the trust system completely distributed. I'm not sure how they would solve the inevitable growth of the blockchain itself, though, but it's very interesting.
[1] https://www.iana.org/dnssec/tcrs
>>53750700
I use OpenDNS.
How fucked am I?
>>53753576
Meh, in conjunction with DNSCrypt you at least prevent your ISP snooping on you. I don't know much about OpenDNS' policy itself though.
>>53753601
Well this hasn't happened to me yet
https://www.youtube.com/watch?v=gnKuATDRsBs
So I assume the policy is alright
>>53753562
>I do, but a web of trust like PGP relies on doesn't scale for every domain.
Never mind that PGP doesn't even work at all. Not enough people use it, and most people who do use it incorrectly.
>The TCRs[1] are very transparent in their procedure.
Are they transparent about possible NSA involvement and/or gag orders? How do we know the NSA haven't compromised their servers?
>All TLDs have been delegated by IANA to whichever has a technical or.public interest.
I'm sure the lybian government has a technical or public interest in MITMing .ly domains.
>I trust DNSSEC much more because it's transparent.
Where is their infrastructure documentation? Where is their warrant canary? Where can I find out about how well secured their trust anchors are?
>>53753716
>Never mind that PGP doesn't even work at all. Not enough people use it, and most people who do use it incorrectly.
How does one use PGP incorrectly?
>>53753738
>How does one use PGP incorrectly?
By trust identifies without sufficient level of trust.
PGP is designed around the idea of a web of trust, but no such web has manifested itself to the degree necessary for PGP to serve as a reliable means of establishing cryptographic identities.
Never mind all the other problems with PGP/GPG
http://grimoire.ca/gpg/terrible
http://www.thoughtcrime.org/blog/gpg-and-me/
https://lists.torproject.org/pipermail/tor-talk/2013-September/030235.html
>>53753716
>>>53753562 (You)
>>I do, but a web of trust like PGP relies on doesn't scale for every domain.
>Never mind that PGP doesn't even work at all. Not enough people use it, and most people who do use it incorrectly.
Sad truth, but that's arguing PEBKAC over its inherent security.
>>The TCRs[1] are very transparent in their procedure.
>Are they transparent about possible NSA involvement and/or gag orders? How do we know the NSA haven't compromised their servers?
Well, a blockchain demands that no party should be in charge of over 50% of its computational power. Who's to say a TLA hasn't backdoored the 'miners' everybody use?
>>All TLDs have been delegated by IANA to whichever has a technical or.public interest.
>I'm sure the lybian government has a technical or public interest in MITMing .ly domains.
Lol.
>>I trust DNSSEC much more because it's transparent.
>Where is their infrastructure documentation? Where is their warrant canary? Where can I find out about how well secured their trust anchors are?
Well, for starters here's the FAQ: https://www.iana.org/help/tcr-answers and here's the initial KSK ceremony video that explains a lot in a very brief way: https://m.youtube.com/watch?v=b9j-sfP9GUU beyond this there are numerous links on IANA and ICANN's websites which you can lookup. I do not know every single detail about this procedure by heart, of course, but mind you this isn't all hush-hush as I fear you might have implied.
>>53753903
>Well, a blockchain demands that no party should be in charge of over 50% of its computational power. Who's to say a TLA hasn't backdoored the 'miners' everybody use?
Everybody is in charge of the software they run. The blockchain implementations I'm aware of are based on free and open source software.
If I can set up a miner and convince myself of its authenticity - plus convince myself that the same software is being used on significant enough portions of the rest of the mining community, I can get a high degree of transparency.
The alternative is requiring a reliance on a third party cryptographic black box, which is what root trust anchors are.
>>53753903
>https://m.youtube.com/watch?v=b9j-sfP9GUU
>So, what we have is a collaboration between three entities - who were all together involved in making the root zone the DNS - which is VeriSign, the U.S. department of commerce and ICANN; and what we did is we formed a design team to try and build a solution that we thought /preserved/ that structure with those three organizations, but added the security aspects in.
Am I reading this correctly as “VeriSign and the U.S. department of commerce will still have their ability to MITM and spy on end users, don't worry NSA”?
I wanna register a domain but not let my real information (including my real name) be available through WHOIS. I see several services that offer it and a few warnings as well about the domain not really being "yours" once you opt in for WHOIS protection. I wanna hide my real name without paying a company and effectively giving them ownership of the domain, but also without paying a lot of money.
Help me, DNS guy!
>>53754087
No, not necessarily. Don't forget that all DNS traffic is unencrypted by default. Everyone can freely spy on each other, provided they receive queries from you.
>>53754153
I mean in the sense of being able to present forged DNS certificates that present wrong TLS keys, so they can MITM your HTTPS traffic.
>>53754087
>Persons considered affiliated with ICANN, VeriSign or the U.S. Department of Commerce may not become a Trusted Community Representatives.
Seems like it's the exact opposite, actually
>>53754211
The selected TCRs aren't.
SO should i use it or not.
No one ever says shit other then circlejerking
>MFW this thread
I have a lot of reading to do.
>>53753903
>Well, for starters here's the FAQ: https://www.iana.org/help/tcr-answers
I'm struggling to find the answers I want from this document.
It seems that security is placed in three communities here:
1. The recovery key shareholders (RKSHs). I know that a minimum of 5 of them are needed to perform some form of recovery task, but what exactly is that task? What power do they hold?
2. The trusted community representatives (TCRs). I know that they're present for the processes involving keys, but what exactly does that mean? What power do they hold?
3. The people in charge of maintaining the actual facilities where these meetings take place and these devices and keys are physically stored. How do I know they can't just turn off the alarm, open up the safe with their backup keys and do bad things this way?
I don't see an adequate description of *who* can do *what*. I don't see a threat model. What if 5 malicious RKSHs got together? What if N malicious TCRs got together? What can they and can't they do?
I don't see the transparency in documentation that I was hoping for. Is there something more in depth?
Managed DNS Portal:
https://mdns.verisign.com/mdns-web/certLogon.jsp
Howdy, Stranger!
https://publicdnsforum.verisign.com/
The status can't be seen unless you have their certificate:
https://www.cloudharmony.com/status-of-dns-for-verisign
I get a 'problem loading page' text
>>53754291
Also, what do these people actually sign?
Are they just securely “handing off” trust from the root key to some TLD-specific company that's in charge of all, say, .xyz domains?
Or when I register for a domain (example.com), does my key go directly into these meetings? Do I have to fly there and attend personally in order to get my domain signed, or do I delegate it to some “trusted” third party? How do I know I can trust this third party?
>>53754323
Yeah, IANA itself!
>We want to build a framework that you, the end user, can trust!
>So we decided to make it as overly and ridiculously complicated as possible so that you, the end user, have no hope of ever understanding what exactly is going on
I refuse to place any faith in a system I don't even remotely understand. If they want me to use it, they can start by making it friendly for the end user.
>Cisco to Acquire OpenDNS for $635 Million
Cisco to Acquire OpenDNS for $635 Million
Oy Vey
it's '"Open'"
Goym
As an Engineer who supports sysadmins to integrate shit like this there are far too many Idiots out there who can not even implement fucking SPF records without fucking everything up.
DNSSEC and everything is nice but seeing how many problems stem from shitty DNS implementation I see dark times of bullshit when this is coming.
As we are @4chan I suggest to get the closest DNS to your animestaion PC and just cache all the sites you fap to.
>>53754398
Good point, and this already happening today. The traditional LAMP stack since the last decade or two is still being rolled out to every customer, absent DNSSEC, DKIM, SPF, DMARC, whatever. Some do, but a lot of these providers still don't.
Companies should invest more in smart *people*, not 'smart' automated solutions which never get maintained again, because 'it just werks™'.
>>53754179
Only of their domains, e.g. your parent domain. You remain in charge of your own domain, your own zone signing and your own keys you generate. So unless you're arguing backdoors in NIST standards (for example), you have autonomous control of your own crypto your servers run, validated by your own DANE RRs (for example).
DNSSEC + DNSCrypt is what I do, makes me feel good
And I'm even a windows user~
>>53754765
>You remain in charge of your own domain, your own zone signing and your own keys you generate.
I'm operating on the assumption that my DNS traffic is going through an untrusted server that can inspect and modify the packets as they go along.
In this threat model, what security benefits does DNSSEC provide? I still see nothing solid.
>>53754833
>>53753971
>>>53753903 (You)
>>Well, a blockchain demands that no party should be in charge of over 50% of its computational power. Who's to say a TLA hasn't backdoored the 'miners' everybody use?
>Everybody is in charge of the software they run. The blockchain implementations I'm aware of are based on free and open source software.
>If I can set up a miner and convince myself of its authenticity - plus convince myself that the same software is being used on significant enough portions of the rest of the mining community, I can get a high degree of transparency.
That's true, and I trust they're inspected for shady stuff by their maintainers, as well as independent auditors. Let's just hope this trust isn't misplaced.
>The alternative is requiring a reliance on a third party cryptographic black box, which is what root trust anchors are.
Well, you can inspect what cryptographic algorithms were used to secure your parent domains, all the way up to the root. It's not so much a blackbox, right? I mean, I'd be worried if they used proprietary algorithms, but that's not the case.
If you can trust your TLD, it's cool. If you don't, you can consider a different TLD, but if you don't trust the root itself, well, then you have a problem, yes. That's why IANA and ICANN are (but also need to be) so transparent to 'bootstrap' this trust we place in them. If you don't trust them, that's fine. So, let's hope NameCoin or something similar catches on.
>>53754858
Oh, you meant your queries. I thought you meant the authoritative name servers.
Right, well mind you that DNSSEC offers no confidentiality (encryption), only integrity (here public key signing). DNSSEC guarantees that your answers you receive from authoritative name servers haven't been tampered with. However, if you *also* don't want intermediary parties to see which domains you want to visit, try DNSCrypt or DNSCurve in conjunction with DNSSEC.
>>53754372
Then start by canceling your SSN, credit cards, bank accounts, loans, mortgage, you name it.
>>53754966
>Well, you can inspect what cryptographic algorithms were used to secure your parent domains, all the way up to the root. It's not so much a blackbox, right?
I'm not talking about the cryptographic primitives, but about the system as a whole.
I don't really know *who* has how much power over my domain. I can't inspect the innards of my registrar's web server (you know, the one I'm actually uploading my signature to). How can I have any faith that they're not going to modify the data I give them?
>>53755632
>implying I use any of them
The only legally required cryptographic system I'm using is the one for my personal ID, which done a fair amount of study on. (Enough to determine what exact NSA-weakened elliptic curves they use internally)
Consequently, I've decided that this system is almost wholly insecure and basically should not be trusted at all. So in that sense, I've analyzed it enough to be comfortable using it - because I know I cannot trust it, I cannot do anything wrong.
>>53755901
>How can I have any faith that they're not going to modify the data I give them?
So, let's think like an attacker. How would you tamper with the system? 1) You could argue the presence of a backdoor in certain used cryptographic algorithms in general, or 2) you could argue the owners of the TLDs deliberately tamper with their child domains records to redirect queries to compromised name servers that still DNSSEC validate, but with their own KSK/ZSKs. These would imply state level attacks, which in all fairness is not out of the question, but unlikely nonetheless. There may be more theoretical attacks, but I'll just stick to these two which I thought of just now. Fell free to suggest your own attacks.
The first attack (backdoor) we don't know, but it has been suggested by mathematicians that the current NIST ECC standards could theoretically contain a backdoor. A heterogeneous pool of available algorithms aims to tackle this by making everything about a cryptographic system open (think Kerckhoffs' Principle). For example, you could trust djb's or Bruce Schneier's cryptography over the US government approved standards. Edwards-curve is currently an IETF draft btw.
The second attack (hijacking domains) would mean instant downtime for the owners of their domains because all traffic they would receive is now being redirected to compromised servers. Companies that constantly monitor their traffic would notice this instantly.
So I'm not saying it's impossible, and the system isn't perfect, but it's highly unlikely attacks like these would take place. I will say that the we still need a more heterogeneous availability of cryptographic algorithms for DNSSEC for viable mitigation of the first theoretical attack, as well as that small companies and individuals that don't monitor their traffic may still be susceptible to the second theoretical attack.
I know, trust is very hard to come by these days, isn't it?
>>53756397
>2) you could argue the owners of the TLDs deliberately tamper with the child domains records [...]
To clarify, for the second attack I strictly meant just the records that parent is authoritative for (glue and such). I did not mean the records residing in the child domain itself, as these would have been signed by the child domain itself, of course.
>>53754953
Source?
>>53756397
>The second attack (hijacking domains) would mean instant downtime for the owners of their domains because all traffic they would receive is now being redirected to compromised servers. Companies that constantly monitor their traffic would notice this instantly.
You're not thinking like an attacker yet.
Suppose alice resolves ‘google.com’ using DNS server bob.
Mallory sits in the line between alice and bob and has the freedom to inspect, modify, insert or remove any packets that get sent in either direction.
Alice -> Bob: Hi what is the address of google.com?
Mallory lets this packet go through.
Bob -> Alice: The address is X.Y.Z.W, btw here is an attached cryptographic signature of this answer
Mallory intercepts this packet and changes the cryptographic signature that was returned, to a signature of her own key.
Neither Alice nor Bob know something suspicious is going on, unless Alice repeats this experiment with a client that has a trusted connection to Bob and compares the signature received. But that would imply trusting Bob, and having a secure connection to Bob to begin with (which defeats the whole purpose of DNSSEC)
Mallory can then later intercept Alice's packets to X.Y.Z.W and MITM using her own key, so again neither Alice nor X.Y.Z.W realize something suspicious is going on.
>>53750700
Good thread OP. Thanks
Bump, more people need to know about dnscrypt
>>53757499
>499 ▶
>Bump, more people need to know about dnscrypt
agreed, it's easier to setup than ever these days as well
DNSSEC or DNSCurve ?
>>53757391
I understand, but that's when the RRSIGs come in!
For every query, an authoritative name resolver with DNSSEC sends back an answer together with the corresponding RRSIG of the record. The RRSIG is a digest of the record, and gets matched to the public key which the zone has been signed with (DNSKEY RR), which will be matched with the DS RR in the parent. This process repeats itself all the way up to the root. Or the other way around, from the root down to the record. Top down, or bottom up depends on the implementation you use to verify a record's integrity.
If Mallory were to forge her own answers back to Alice, the RRSIG wouldn't match Bob's DNSKEY RR, because Mallory would need Bob's private key for that. That, or she found a hash collision, which is extremely unlikely with the current strong algorithm strengths. So make sure you use a strong algorithm (of course).
>>53750700
I work for a big Swiss ISP and I'll lead the implementation of DNSSEC starting in June this year.
Can't wait. Last time I was so hyped we started distributing IPv6.
>>53757766
Awesome, good to luck to you. I'm still in university, but I could see myself working for an ISP or registrar one day.
Thanks for the discussion everybody, but I need to get some shuteye. Yes, I'm a 'eurofag'.
If this thread is dead tomorrow I'll start a new thread later this week.
>>53757669
>If Mallory were to forge her own answers back to Alice, the RRSIG wouldn't match Bob's DNSKEY RR, because Mallory would need Bob's private key for that. That, or she found a hash collision, which is extremely unlikely with the current strong algorithm strengths. So make sure you use a strong algorithm (of course).
And where does Alice get Bob's DNSKEY RR from? Oh right, from Mallory.
What part of MITM don't you understand? How is DNSSEC supposed to solve fundamental limitations in information security?
>>53757954
>Oh right, from Mallory.
I don't think so, glue to Bob resides in the parent. Unless Mallory hijacked the IP or the parent's domain, she's not the authoritative name server.
>>53757655
http://security.stackexchange.com/questions/45770/if-dnssec-is-so-questionable-why-is-it-ahead-of-dnscurve-in-adoption
For those uninformed...
>>53752938
>DANE
DNS-based Authentication of Named Entities
relevant: https://datatracker.ietf.org/wg/dane/charter/
>>53753213
>HPKP
HTTP Public Key Pinning; seeking to prevent MITM attacks with forged certs
releevant: https://developer.mozilla.org/en-US/docs/Web/Security/Public_Key_Pinning
>TOFU
trust on first use; like the ssh trusted host prompt
relevant: https://lists.gnupg.org/pipermail/gnupg-users/2015-October/054608.html
i luv u OP, but fuk Generals
>>53757954
The DS RR in the parent wouldn't match Mallory's DNSKEY RR.
>>53750971
sq how do you register a domain and "play" with it?
>>53758302
You register a domain using a registrar.
>>53757357
Ubunchu
>>53758104
If Mallory has access to the parent's key, it easily could. You need some level of access to the parent's key to be able to register domains at all. A system can't work if you cannot use it.
This is just X.509 in disguise. As soon as you give the power to register new certificates to a CA, anybody who infiltrates or controls the CA can use it to forge new certificates.
There's no fundamental way around this limitation. The moment you trust a third party to verify your authenticity, you've given power over your authenticity to said third party.
