Hacker News Reader

Comment by mehrdadn | Hacker News Reader

Taking a step back here... shouldn't proving ownership of a domain involve the domain registrar some way, rather than involving whoever happens to host your DNS? They know who you are, so maybe they can provide an interface to let you prove to others that you own the domain. Like I dunno, maybe just let the owner of the domain generate a unique one-time key valid for 30 minutes, and provide an API to allow anybody to check ownership if given that key, e.g. at a standard URL like

  yourregistrar.com/domainowner?domain=example.com&ownerkey=8719425131715293085

View on HN

DNS security is a red herring. This is a BGP attack; the attackers control IPs. They can intercept traffic --- including DV cert checks --- without touching nameservers.

> They can intercept traffic --- including DV cert checks --- without touching nameservers.

Huh? I'm talking about certificate issuance and domain ownership here. If a CA can't verify the domain with the registrar then they fail to issue a certificate, it's as simple as that. It's not like they can get a forged response over HTTPS...

An attacker who controls arbitrary IP addresses can get a DV cert issued without control of the DNS.

> An attacker who controls arbitrary IP addresses can get a DV cert issued without control of the DNS.

What? How? Did you read my comment at all? I was saying the CA needs to have a way to verify ownership with the domain registrar. Over HTTPS, obviously. An attacker can't forget a response, so the worst case is the cert doesn't get issued, which it very much shouldn't be if ownership cannot be verified.

I can't tell whether you're talking about how you think things should work or making claims about how they actually do work. If the latter: no. DV certificate checks don't use HTTPS to validate ownership. The point of DV certificate checks is to provision HTTPS in the first place.

If you control BGP, you can thwart DV checks and get a certificate issued. You can do that without touching the DNS at all.

> I can't tell whether you're talking about how you think things should work or making claims about how they actually do work.

How can you not tell? I was extremely explicit that this was the former in the very first sentence of my initial comment:

>>>>>> Taking a step back here... ___shouldn't___ proving ownership of a domain involve the domain registrar some way, rather than involving whoever happens to host your DNS?

The only reason we have DV certs is because people find normal certs painful to apply for. They're a convenience. Similarly: LetsEncrypt does HTTP challenges, relying on the DNS as a side effect, because lots of people who need certificates do not control their DNS records, even if they "own" the domain.

Much easier — allow people to put a public key into the WHOIS database.

How does either solve this if the bad actor is able to inject routes at will? Just redirect whois.iana.org to their servers. Then they can prevent you from accurately determining who the registrar is in the first place.

Whois database results can be signed and are signed for some TLDs.

Where is that information on whether or not you should expect a TLD to be signed stored? Is it on the client side? If a client receives an unsigned whois response, what does it do?

This isn't something I was aware of, and I'm not having much luck in finding out the implementation details.

> Where is that information on whether or not you should expect a TLD to be signed stored? Is it on the client side? If a client receives an unsigned whois response, what does it do?

I can imagine a zillion different approaches... most obvious (not necessarily the best) one being to ask an IANA server over a normal TLS connection whether it should expect a TLD's records to be signed. And you can obviously cache that response for a while.

Remember the point here is to validate domain ownership, which everybody already understands to be a big deal. If you can't get any trustable response from anybody, then I would expect it is your duty to refrain from issuing a certificate for that domain.

My question is about the existing implementation of signed WHOIS records, which kuschku seems to be stating exist for some TLD already.

There are some drafts, and some NICs that have custom WHOIS solutions over custom authenticated protocols that don’t integrate with the normal WHOIS functionality.

But the larger issue is that there is no global integrated WHOIS system – e.g. to view a WHOIS record for a .de currently you need to solve a captcha and provide a valid reason (and can’t do it automated).

Or, you know, use DNSSEC.

Crypto maximalists don't like additive security mechanisms that reduce the risk and potential scope of attacks, but may not address every possible attack vector. Often the effect of crypto maximalism is reduced security. In the real world it takes multiple mitigating technologies to address a problem, and perfection is not always achievable. See RFC7435.

Except WHOIS is (likely) going away next month (at least in RIPE) due to GDPR.

It is not going away, it never was, never will.

DENIC has been compliant with the GDPR for months already, and its WHOIS database is still running – you just can’t expose all fields of the WHOIS to any unauthenticated viewer.

I don't think it makes sense to force every domain owner on the planet who wants HTTPS to understand how to generate, store, use, and maintain (more) public/private keys, especially in a secure manner. Having to deal with SSL certificates is enough of a pain already, and for this one you'd have to use another program to sign requests, so there's an added layer of pain. In fact, I don't think it makes sense to add to the burden of domain owners so much at all, even if they could all do this.

Not to mention that, more practically there's no need (and potentially possible harm) to tie the ownership records to a particular cipher. Really, it's the registrar's job to deal with domain ownership; ideally it shouldn't involve you at all. And as a near-corollary, they could probably deal with long-term key security better than the average domain owner.

I think it does make sense. If they can't do it themselves then let them hire someone who'll do this for them.

> I think it does make sense. If they can't do it themselves then let them hire someone who'll do this for them.

Really? In your mental model is (or should be) every domain owner overflowing with money?

In my mental model the requirements of the modern web are way above what was in the 1990s.

A single static landing page would be expected to have at least traffic tracking, at least for the sake of load-balancing.

Even if the page is that - just a static page, the chance it's hosted by the content owner themselves is becoming smaller every day.

So frankly - yes. I believe today is the right time to start adding/replacing layers in the stack. After all - we've gone a long way in terms of software deployment tools so it's way more interchangeable.

Ok, then we need to stop using DNS. Your record server being compromised shouldn't be able to imply ownership.

Or we should require DNSSEC for DV certificates.

You're right that something should be used, but DNSSEC is a weak solution from a security point of view.

I... agree? In fact that's quite literally what I was saying?

Reply on news.ycombinator.com