I think a little search answers my own question. From [Google's cache of][1] I see that it refers to commercial activities.
ยง 6 Identification of providers
Concerning commercial offers, providers shall indicate:
1. their name and address as well as,
2. in case of associations and groups of persons, the
name and address of their authorized representative.
It makes much more sense now, though of course it raises the typical question as to what is a commercial offer. For instance, would a blog with Google ads qualify? But I digress... Never mind!
Are there Bootstrap tutorials that also combine the minimal CSS knowledge required in order to use it? For instance, I have a vague understanding of the box model, and can hand-code very simple pages myself, but I find it unsatisfactory, as the nested divs and knowing what class to use when can drive me a bit nuts. So far the tutorials I've come across don't add much to the official documentation at all.
I'm hoping this lean book [1] will give me a nice, integrated walk through these issues.
Does your decentralized ideal apply to the whole Internet, or just TLD signing and such? In other words, do you believe we'd be better off without a DNS root zone? I know there's Freenet, so I guess another question is whether you think that shift could ever become mainstream.
If so, I'd love a reply.
If not, I'd love a reply. And! And then... this DANE shift would not be such a bad thing, right? You have the hierarchy anyway, so why not have the option of securely publishing [1] your public keys. By the time you have registered your domain and paid all your fees, you might as well!
As for the potentially insecure signing of some TLDs, isn't it partly due to the decentralized nature of the ccTLDs? From a security perspective people may have to learn to trust more .com domains with a green lock than, say, .ly.
[1] I'm purposely using this loaded term, as I'm full of doubt and confusion, hoping to provoke the master and get more thoughts! Refer, for instance, to my TL comment in this thread.
How can DANE ever work if DNS (including DNSSEC) is an unencrypted protocol? Doesn't this mean that the moment you get a response to a DNS query the a malicious network could return orchestrated nonsense?
It looks like something like DNSCurve [1] would be needed, though Paul Vixie stated [2]:
[...] the problems DNSCurve actually does solve are pretty well solved by UDP source port randomization and will be entirely eradicated by DNSSEC [...]
Could security experts give their take on this? There are some strong statements, such as the last sentence: "Because DNSCurve does not do this, and because the problems DNSCurve actually does solve are pretty well solved by UDP source port randomization and will be entirely eradicated by DNSSEC, ISC is not investing in DNSCurve at all."
I have a few questions, in case anybody is interested in any of them:
1) Would full deployment of IPsec render DNSCurve unnecessary?
2) Isn't "full security" impossible until DNS queries are encrypted? I'm reading the ongoing comments about HSTS [+] and can't help to think that, if you assume the network is a malicious medium, then any unencrypted DNS query, including DNSSEC, can receive a compromised response. But then again, Paul Vixie's quoted sentence seems to counter my reasoning/understanding.
I can go on and on about this particular subject, but will refrain from doing so unless there's some demand for yet another DNS & security debate on HN.
I voted the submission up, by the way; thanks for posting it. I hadn't read it.
In [1] you showed us how to authenticate via DNSSEC HTTPS in Chrome. If I understand correctly this involves a lookup of a TYPE257 record. Given that only 5% can resolve TXT records, do you know what % of Chrome users can then resolve TYPE257 records?
Digressing a bit further, wouldn't you say that even if HSTS is enabled and registered in the all the browsers' built-in list, you still have the problem of unencrypted DNS lookups? (Maybe this kind of attack is orders of magnitude harder to implement. I honestly don't know.)
No. The whole idea of HSTS is that you can never trust the DNS; you assume that's the most likely way an attacker is going to MITM her victims. HSTS tells the browser to remember that from that point on, all connections to SERVER.NAME have to happen under a TLS session with a valid cert.
Thanks for your answer! I'm more confused by the moment about DNSSEC et al: isn't the DNSSEC-based validation of HTTPS referred to above supposed to get rid of CAs in the future? That wouldn't make sense even with DNSSEC considering that the information is not encrypted? (Right?) I hope you don't take this as "hijacking", but I'd be most curious about what you and other security experts think about Paul Vixie's "Whither DNSCurve?" [1], which has amazingly not been submitted in HN. I just submitted it [2].
(If I could vote for your time investment, please kindly consider commenting on that article before replying to this comment.)
There is a splinter group of people- who- want- DNSSEC who argue that DNSSEC will obviate the need for CAs. There reasoning, distilled, is that DNSSEC is itself a PKI, with the roots signing TLDs and TLDS signing domains and so on. Since the core architecture purpose of certificates is to "break the tie" between an attacker's public key and the real site's public key, and since DNSSEC zones could serve the same purpose, by housing a DNSSEC-signed public key, blammo, no more Verisign.
There are a bunch of problems with this idea. Most of the ones that spring to my mind are problems with DNSSEC in general: its brittleness, the reliability problems I think it's going to cause, the things it does that actually diminish the security of the DNS... but the big point relevant here is: DNSSEC replaces a market of CAs with a baked- into- the- Internet fiat authority. If DNSSEC had replaced SSL CA's in the mid '00s, Ghaddafi's Libya would have been Bit.ly's CA. This does not seem like a win to me.
I don't think that rent-seeking SSL CAs are as big a problem as many HN users seem to think they are. I think ultimately there's significant expense involved in operating a secure CA, and that relative to their purported value, CA certificates are reasonably priced.
The pressing problem with SSL/TLS is that CAs aren't trustworthy. They are rent-seeking, as expected, but also shoddily operated. The Internet has largely lost faith in the people operating CAs.
Moreover, a decade and a half of browser/CA relationships have left all the major browsers riddled with skeleton-key CA certs run by organization that nobody can really vouch for. As a result, large companies have purchased browser-trusted CA operations, and then used them to do incredibly dubious things. The companies that have been caught doing skanky stuff with their CA keys haven't even been kicked out of the browser CA stores.
As a result, we're left with a situation in which untrustworthy companies can potentially sign certificates for (and thus enable transparent MITM attacks against) critically important sites, like Google Mail. That's an untenable position.
I personally believe (and, yes, hope) that the future of Internet security looks much like today, except with things like Trevor Perrin and Moxie Marlinspike's TACK scheme, to allow security-sensitive sites to overrule bogus CAs, and to allow us to gradually decrease the architectural dependence we have on SSL CAs and start experimenting with more flexible alternatives.
I am not a fan of trying to take the same model that just failed us, but centralizing it and handing it over to the unaccountable groups of people who control the domain name system.
Wow. Thank you very much for educating us, Thomas. Your comments require grabbing some popcorn or equivalent. In particular when you engage in a constructive debate with someone of your caliber. One of my all-time favorite threads in HN (or elsewhere...) is http://news.ycombinator.com/item?id=893659. Thanks again.
Well, now that DANE is nearly an RFC I should change Chrome to use it rather than the TYPE257 records.
But the important point is that DNSSEC stapled certificates don't need the browser to perform any extra DNS lookups. The certificate itself contains the DNSSEC information and signatures. Since DNSSEC is signed the data can come over any channel; it doesn't have to be port 53.
Unencrypted DNS still leaks the hostname that you're visiting - that's true. However, the destination IP address probably leaks the same information and, if not, we sent the hostname in the clear at the beginning of the TLS handshake! (That's SNI, it allows SSL virtual hosting.)
Thanks for answering! What I don't understand is that, given that your starting point is "two computers talking over a malicious network", doesn't the current state of affairs of (unencrypted)DNS mean that it's game over from the outset? That is, if the network is malicious, that MITM could very refer you to an invalid IP address the moment you first try to resolve, say, mail.google.com.
Please don't take this as an argument. I just want to know where I'm wrong! I just can't get over the idea of pushing at the (justifiably) paranoid level for HTTPS while we still have plain-text DNS... even with DNSSEC!
Yes, DNS can be used to direct you to the wrong IP address but that hardly matters: an evil network can give you the correct IP address but then intercept all traffic to it.
The key is that the IP address doesn't matter, indeed it shouldn't matter whether the traffic is going over carrier pigeon. You have a name that you wish to connect to, say example.com, and you have some way to send an receive packets. If the other end can prove that they are example.com by means of a certificate then you have a secure connection. How the data gets there and back is immaterial to transport security.
Hello everyone! I know... I'm still submitting my own articles. On my defense I'll just say it's article #2... I hereby promise I will not do it once I reach #10. I feel it may be of interest to some, in particular the collection of links, and on the other hand my current readership... gives me no choice if I want to share it with the outside world!
Yes! This is a great paper which made surprisingly little noise given how important it is.
The idea is: stipulate that no attacker can ever inject Javascript into a browser. Assume we solve that problem completely. Now, how secure are DOM-based applications? Turns out: not that much more secure. Lots of very clever examples.
[1] http://www.iuscomp.org/gla/statutes/TDG.htm