Hacker News Reader

Comment by tptacek | Hacker News Reader

Successful deployment of STS would bring to zero the number of real-world use cases for DNSSEC/DANE, which would be a very good thing.

View on HN

Read the draft dude. STS is designed to interoperate with DANE.

Also, if you deploy your STS info via DNS you'll need DNSSEC validation to to ensure that what you read in DNS is actually what the zone holder put there. Without DNSSEC how does a sending SMTP daemon trust the STS policy of the recipient zone. STS policies are stored in DNS TXT records, or their own new RR.

Pleaee don't be rude. STS doesn't preclude DANE, but it doesn't require it either. Meanwhile, this use case was the last remaining one motivating DANE at all.

The draft is very clear about DANE being preferred from both a security and deployment perspective (does't need to get certificates for all hosted domains).

Sure, if DNSSEC fail, then SMTP-STS is better than nothing.

I'm pretty sure that the big providers could have had deployed DNSSEC relatively easily, if they just wanted to.

I think other DNS-based email security features such as DKIM and DMARC motivates DNSSEC as well.

Why? They solve different problems. DNSSEC/DANE moves the TLS CA into the hands of the DNS hierarchy from various corporations. STS just says to use TLS (with this cert, but you can only know the cert is OK to begin with because of a CA, or DANE).

DNSSEC however has its own problems. I have been thinking of a DNSSEC2 proposal for a while now that for example would use online signing only.

Having no support for offline signing in and of itself isn't a selling point. What else does your approach have to offer?

It is a selling point in that it simplifies the protocol, making it easier to implement. Obviously it would not be the only difference.

> It is a selling point in that it simplifies the protocol, making it easier to implement.

In the current protocol the only difference between offline and online signing is in how authoritative servers are implemented. There the differences aren't all that significant (relative to building an authoritative server as a whole) -- the same data needs signing, etc -- so please explain how your protocol makes implementation simpler.

> Obviously it would not be the only difference.

Can you please expand on that? You've said you've been thinking of a DNSSEC2 proposal for a while so you must have more to say.

I forgot to mention that one of the known problems of DNSSEC is the DNS zone information disclosure problem. Online signing would allow the problem to be eliminated and reduce complexity by the protocol no longer having to be designed for enumerating DNS records. Of course, DNSSEC2 would probably only allow ECC signing too (I suggest both NIST curves and Curve25519 as options).

Online signing and white lies are already in DNSSEC. What you've described so far doesn't seem to be different to the status quo. Even deprecation of older cryptographic signatures is being worked through at the moment.

I know about this. That is why I mentioned the complexity that comes from the original protocol design being designed for offline signing.

You have said you have been thinking of a DNSSEC2 proposal for a while, that your protocol differs in multiple ways and that it is easier to implement. Given this you should be able to concretely articulate how your protocol differs and where its advantages are gained. Thus far you have not shown the ability to do this.

It is just a bunch of ideas at this point and not even a complete list of them.

The DNS root servers need offline signing. Many servers are in untrusted areas (think intervention from local government).

I think DNSSEC already deals with this by offline signing another key that actually signs the DNS root zone.

Because the only remaining reason to deploy DNSSEC is to exploit DANE to allow SMTP MTAs to force TLS. All the other uses of DNSSEC are already DOA.

It's a little tricky to explain why this is the case without getting into a lot of gritty detail. A shorthand answer is that browser vendors have, pretty much as a group, decided not to adopt DANE (the DNSSEC-based alternative to the X.509 CA system), and DANE is the only reason anyone cares about DNS security on an Internet where everything is going to be encrypted (usually with TLS) by default.

Is SSHFP not a legitimate use case for DNSSEC? (Genuinely curious.)

It absolutely is a legitimate use case, and would IMO improve security for the type of developers who do use SSH, but don't know what a fingerprint is. It would also make it easier to create secure connections for non-developers, e.g. a SFTP/SCP based file sync app.

No, SSHFP is pretty silly as a motivating use case for DNSSEC. There's nothing it does that you can't do (better!) with some other system. It makes sense if you already have a secure DNS. But that begs the question of why you would need a secure DNS.

You don't need a secure DNS for the web.

You don't, with STS deployed, need a secure DNS for email.

Is publishing SSH key fingerprints so important that we should do a forklift upgrade of the DNS? No, of course not.

STS information is stored in DNS records. Why would you not want to secure those?

Also, I think you're underestimating the growth of DNSSEC deployments. I've been watching DNSSEC growth for about 2 years and it is steadily moving up and to the right.

It has taken two decades to get to this point. The protocol has been substantially revised four times, and, after each of those four revisions, DNSSEC proponents said "now, we've got it right, and it's ready for universal deployment".

It is nowhere near ready for universal deployment today, and, indeed, virtually nobody relies on it, unlike TLS.

DNSSEC ain't pretty. I'll agree with you there, but that doesn't mean it isn't the best thing going for us in terms of securing the DNS. Like it or not it's important to be able to trust DNS responses.

I guess I don't have some expectation that deployment should take place quickly. Or that the first go at a protocol is going to always get it right. Just because a journey is difficult doesn't mean the journey isn't worth taking.

DNSSEC and TLS are unrelated. They're trying to solve different problems.

There is no point to securing the DNS. There are only downsides.

*using DNSSEC

I don't think there's any point to securing the DNS at all.

DNSSEC adoption is actually doing pretty well. And there are reasons beyond DANE to deploy it.

Please share.

I don't have good numbers for signing of zones. Although we do know that these numbers are increasing. Cloudflare recently turned on DNSSEC for all of their clients.

Geoff Huston at APNIC does some good work at measuring validation. Check out slide 2 and 24 of this preso. https://meetings.icann.org/en/marrakech55/schedule/wed-dnsse...

Again, I'm not arguing that DNSSEC adoption has been easy and fast. But it's being adopted steadily.

No, I'm asking about the reasons to deploy it.

Both these ideas are terrible ideas.

Give me a solid anchor and a lever that is long enough and I can move the earth.

The problem of all modern crypto technos is 1) CPU burnt for crypto is a nice lever for DOS (and not all our mails require crypto, seriously 60% is spam) 2) they do not solve the 2 general problem

Yes 2 auth/Channels factors seems nice. The problem they stay on the same plane. It is 2 inbound channels.

You know when USA engineers last thought it was smart, kiddies learnt to use a 1$ cpt crunch whistle to phone for free all around the world.

Actually I don't mind, I am broke and totally will love free whatever the stuff that this kind of engineering will offer me.

Reply on news.ycombinator.com