

HSTS for new TLDs - tomkwok
http://www.imperialviolet.org/2014/07/06/newtlds.html

======
reedloden
This seems like a great idea for the new .trust gTLD [1] (formerly known as
.secure), as they already want sites under it to be "secure".

[1]
[https://www.nccgroupdomainservices.com/](https://www.nccgroupdomainservices.com/)

------
ejr
I wish there was an alternative to the CA system we have now. I'm part of a
private forum with a self-signed cert and while initially there was some
hesitation to it, most members have added it to their browser exceptions.

~~~
psz
There is a proposed solution for this scenario:
[https://en.wikipedia.org/wiki/DNS-
based_Authentication_of_Na...](https://en.wikipedia.org/wiki/DNS-
based_Authentication_of_Named_Entities)

It will allow for pinning certificates (self-signed too) to records in in DNS
with DNSSEC.

~~~
y0ghur7_xxx
DNSSEC still relays on CAs. They were just renamed to "Trust Anchors". The
trust anchor for .com is Verisign.

~~~
kilburn
> DNSSEC still relays on CAs.

No, DNSSEC has nothing to do with CAs. Each DNS authority defines its own keys
used to sign its records.

> They were just renamed to "Trust Anchors".

You are thinking about DANE [1], which is what the a protocol on top of
DNSSEC. Using DANE you authorize X.509 certificates and/or CAs for certain
domains. This allows you to restrict your domain to a specific well-known CA
(such as Verisign), but it also allows you to authorize your own CA or even a
specific certificate directly. It even works per-service, so you do not need
to use the same CA/certificates for all your services.

If you were suggesting that DANE does not solve the traditional CA issue you
are wrong.

[1] [http://tools.ietf.org/html/rfc6698](http://tools.ietf.org/html/rfc6698)

> The trust anchor for .com is Verisign.

Err.. no? I don't even understand what are you trying to say here. The "com"
domain does not seem to have any TLSA records...

~~~
agwa
> No, DNSSEC has nothing to do with CAs

You're interpreting "CA" too literally. DNSSEC doesn't rely on X509
certificate authorities but in effect it relies on an equivalent, in that
Verisign is a central authority certifying ownership of all .com domains.

~~~
ynik
A single trusted root is better than the hundreds of roots in the CA system. I
don't trust Verisign very far, but I certainly trust them more than Verisign
AND Diginotar AND honest achmed's used cars and certificates AND ...

And shouldn't it be possible to implement certificate pinning for whole tlds?
Then we'd only have to trust root for unknown tlds.

~~~
tptacek
First, you don't get "a single trusted root". If DNSSEC/DANE had been deployed
3 years ago, Qhadaffi's Libyan government would have effectively been the CA
for BIT.LY.

Second, and more importantly: the smaller number of trust anchors you end up
with in DNSSEC are controlled by world governments.

It seems absurd to me that the Internet's response to the "global passive
adversary" of NSA would be to hand the entire PKI system over to the USG
_formally_. That's what DNSSEC does.

~~~
dlitz
> ...Qhadaffi's Libyan government would have effectively been the CA for
> BIT.LY.

They already are, in practice. Many reputable CAs will issue certificates to
anyone who can forge an MX record for a domain. With or without DNSSEC, TLD
operators are capable of forging those records.

>It seems absurd to me that the Internet's response to the "global passive
adversary" of NSA would be to hand the entire PKI system over to the USG
formally. That's what DNSSEC does.

No, DNSSEC builds authentication into a system that is and has always been
centrally controlled. And just like with the X.509 CA system, you can use
pinning or Convergence or anything else you want to supplement that.

~~~
tptacek
You shouldn't start a sentence with "no" when it confirms the sentence it's
responding to.

------
dionyziz
I'm surprised no one here is talking about Namecoin [1]. It has become obvious
that the PKI system is failing, and the main issue is centralization.

I don't know if Namecoin itself will be the solution, or some other
blockchain-based method that achieves decentralization such as the more
generic Ethereum [2], but as engineers we should be supportive of such
systems, as they provide better security and true -not just delegated- domain
name ownership.

[1] [http://namecoin.info/](http://namecoin.info/)

[2] [https://www.ethereum.org/](https://www.ethereum.org/)

~~~
M2Ys4U
>It has become obvious that the PKI system is failing, and the main issue is
centralization.

Actually, the problem is exactly the opposite. _Any_ CA can sign a certificate
for _any_ domain.

What compounds the problem with the CA system is that CA trust is sticky. When
a new CA gets added to trust stores, they are effectively trusted for life.
That's not how trust actually works.

What we need is a system that is distributed and that allows for trust to be
granted and - most importantly - revoked at will without causing collateral
damage (i.e. for innocent sites that end up using a bad CA).

Moxie Marlinspike's convergence[0] was a great idea, but it's never really
taken off. TACK[1], also by Marlinspike, looks like nice feature to help
transition away from the CA system when we come up with something better.

[0] [http://convergence.io/](http://convergence.io/) [1]
[http://tack.io/](http://tack.io/)

------
santiagogo
Good idea, especially for some tlds aimed at industries which rely on strong
security like .bank. Will send the link to a couple of ngtld applicants.

------
diafygi
I'm confused on the implementation of something like this. HSTS is an HTTP
header, so it is up to the HTTP server, not the DNS server. How is HSTS
enforced at the domain layer?

~~~
evilpie
Chrome and Firefox both have a preloaded list of sites that should always use
HSTS. [https://blog.mozilla.org/security/2012/11/01/preloading-
hsts...](https://blog.mozilla.org/security/2012/11/01/preloading-hsts/)

~~~
bpatrianakos
Right but site owners need to request inclusion on that list only after
they've enabled HSTS on the server. I've done this myself and I must say I'd
be pretty angry if browsers forced an entire TLD to require HSTS. The result
would be SSL warnings everywhere.

~~~
iancarroll
A preload does not require the header to be set. It would obviously be the
smart thing to do, but it's not required.

HSTS is only a header.

~~~
rgbrenner
_A preload does not require the header to be set._

did you read evilpie's link?

"Only if a host responds with a valid HSTS header with an appropriately large
max-age value (currently greater than or equal to 10886400, which is eighteen
weeks) do we include it in our list. ... We limit the list to hosts that send
a large max-age under the assumption that these sites will not revert to non-
HSTS status."

~~~
iancarroll
but you obviously can't check every domain in the TLD. A preload will still
function, that's the whole point: make sure a MITM can't cut off the HSTS
header.

------
emehrkay
"I can't speak for Firefox and Safari but I think it's safe to assume that
Firefox"

Maybe one of these Firefoxes should say Chrome

~~~
cdh
It is a bit confusing, but I'm not sure that this is actually an error. It
sounds like he may be in a position to directly make that change to Chrome,
but is trying to clarify that his thoughts on Firefox and Safari are his, and
he can't speak on their behalf. When you read it that way, it makes sense.

~~~
schoen
What's more, Firefox previously adopted a related thing that agl invented
(HSTS preloads in general), so he has personal experience of their being
amenable to this sort of thing.

