Wacky Weekend: The '.secure' gTLD

Mailman List Mirror (Read Only)
1

"The proposal comes from Alex Stamos of research firm iSec Partners, and
would appoint Artemis Internet as the gatekeeper of .secure. Artemis would
require registered domains to encrypt all web and email traffic (except for
HTTP redirects funneling connections towards the appropriate TLS-encrypted
site), use DNSSEC, and deploy DomainKeys Identified Mail (DKIM) for spam
prevention. In addition, Artemis would employ a rigorous screening process to
verify registrants' identities (including reviewing articles of incorporation
and human interviews), and routinely conduct security scans of registered
sites. The venture has $9.6 million (US) in funding provided by Artemis'
parent company NCC Group, a UK-based IT security firm."

  https://lwn.net/Articles/497254/

Discuss. Debate. Digress.

Cheers,
-- jra

2

I see that LWN has already spotted this; smb will no doubt be pleased to
know that the very first reply suggests that RFC 3514 solves the problem
much more easily.

Cheers,
-- jra

3

In the domain business we don't need a new RFC to know that everything
that is evil will end in .evil, and everything else is not evil. No
need to define a new bitmask field.

Rubens

4

I think this is an interesting concept, but i don't know how well it will
hold up in the long run. All the initial verification and continuous
scanning will no doubtingly give the .secure TLD a high cost relative to
other TLD's.

-Grant

5

Countries would never all agree on what the definition of "secure"
was, so clearly we'll have to have

secure.ly
secure.it
secure.us
secure.no
...

Mike

6

I think this is an interesting concept, but i don't know how well it will
hold up in the long run. All the initial verification and continuous
scanning will no doubtingly give the .secure TLD a high cost relative to
other TLD's.

not necessarily. It can be done with a laptop that does "dig" and sends email to the place.

What will drive the price up is the lawsuits that come out of the woodwork when they start trying to enforce their provisions. "What? I have already printed my letterhead! What do you mean my busted DKIM service is a problem?"

BTW, getting DKIM on stuff isn't the issue. I'm already getting spam with DKIM headers in it. It's getting the policy in place that if a domain is known to be using DKIM, to drop traffic from it that isn't signed or for which the signature fails.

You may find the following exchange with my military son, whose buddies apparently call me "skynet", amusing...

7

not necessarily. It can be done with a laptop that does "dig" and sends email to the place.

What will drive the price up is the lawsuits that come out of the woodwork when they start trying to enforce their provisions. "What? I have already printed my letterhead! What do you mean my busted DKIM service is a problem?"

BTW, getting DKIM on stuff isn't the issue. I'm already getting spam with DKIM headers in it. It's getting the policy in place that if a domain is known to be using DKIM, to drop traffic from it that isn't signed or for which the signature fails.

Wow, I wouldn't have expected such a deep dive on DKIM here, but...

Last I heard, where we're at is sort of bilateral agreements between the
paypals of the world telling the gmails of the world to drop broken/missing
DKIM signatures. And that is between pretty specialized situations -- it
doesn't apply to corpro-paypal denizens, just their transactional mail.
The good news is that even though it's specialized, it's both high volume
and high value.

The big problem with a larger scope -- as we found out when I was still
at Cisco -- is that it's very difficult for $MEGACORP to hunt down
all of the sources of legitimate email that is sent in the name of
$MEGACORP. Some of these mail producers are ages old, unowned,
unmaintained, and still needed. It's very difficult to find them all,
let alone remediate them. So posting some policy like "DROP IF
NOT SIGNED" will send false positives to an unacceptable level
for $MEGACORP. So the vast majority of Cisco's email is signed, but
not all of it. After 4 years away, I would be very surprised to hear that
has changed because IT really doesn't have much motivation to hunt
it all down even if it ultimately lead to being able to make a stronger
statement.

One other thing:

That particular one is from an email sent to me by a colleague named Tony Li<tli@cisco.com>, who is a Cisco employee. It gives you proof that the message originated from Cisco, and in this case, that Cisco believes that it was originated by Tony Li.

In reality, Cisco doesn't know that's it really coming from Tony Li. We
never required authentication to submission servers. And even if we
did, it wouldn't be conclusive, of course.

A valid DKIM signature really says: "we Cisco take responsibility for this
email". If it's spam, if it's spoofed from a bot, if it's somebody having
dubious fun spoofing Tony Li... you get no guarantee as the receiving
MTA that it isn't one of those, but you can reasonable complain to
Cisco if you're getting them because it's going through their
infrastructure. I think that's an incremental improvement because it
was far too easy for the $ISP's of the world to blow off complaints of
massive botnets on their networks because they could just say that
it must have been spoofed. If they sign their mail, it's now their
responsibility.

Mike

8

What will drive the price up is the lawsuits that come out of the
woodwork when they start trying to enforce their provisions. "What? I
have already printed my letterhead! What do you mean my busted DKIM
service is a problem?"

History suggests that the problem will be the opposite. They will
find that the number of registrations is an order of magnitude less
than their worst case estimate (a problem that every domain added in
the past decade has had), and they will make the rules ever looser to
try to gather more registrations and appease their financial backers
until it's yet another meaningless generic TLD.

For concrete examples, see what happened to .AERO, .TRAVEL, .PRO, and
of course the race to the bottom of first regular SSL certificates,
and now green bar certificates.

What might be useful would be .BANK, with both security rules and
limited registrations to actual banks. Identifying banks is
relatively* easy, since you can use the lists of entities that
national bank regulators regulate.

R's,
John

* - I said relatively, not absolutely.

9

routinely conduct security scans of registered sites.

This can only play out one of 2 ways:

1) They launch an nmap scan on the 13th of every month from a known fixed address
which everybody just drops traffic, and it's pointless.

2) The worst rules-of-engagement mess the industry has ever seen.

sites. The venture has $9.6 million (US) in funding provided by Artemis'
parent company NCC Group, a UK-based IT security firm."

And only have to pay $185K to ICANN for the TLD. Hmm....

A bunch of lawyers are gonna get filthy stinking rich. I think I need to make some popcorn. :slight_smile:

10

What will drive the price up is the lawsuits that come out of the
>woodwork when they start trying to enforce their provisions. "What? I
>have already printed my letterhead! What do you mean my busted DKIM
>service is a problem?"

History suggests that the problem will be the opposite. They will
find that the number of registrations is an order of magnitude less
than their worst case estimate (a problem that every domain added in
the past decade has had), and they will make the rules ever looser to
try to gather more registrations and appease their financial backers
until it's yet another meaningless generic TLD.

agree.

For concrete examples, see what happened to .AERO, .TRAVEL, .PRO, and

start with .biz as its re-purposing occurred first.

of course the race to the bottom of first regular SSL certificates,
and now green bar certificates.

What might be useful would be .BANK, with both security rules and
limited registrations to actual banks. Identifying banks is
relatively* easy, since you can use the lists of entities that
national bank regulators regulate.

agree. proposed by core. opposed by aba.

R's,
John

* - I said relatively, not absolutely.

even within the financial services industry, useful taxonomies exist,
e.g., ethical banks, islamic banks, depositor owned cooperative banks,
... again, proposed by core. opposed by aba. and you _were_ on the
high security generic top-level domain working group where you pushed
for anti-spamdom and i for forms of "more secure banking".

-e

11

HTTP redirects funneling connections towards the appropriate TLS-encrypted
site), use DNSSEC, and deploy DomainKeys Identified Mail (DKIM) for spam

The "Except for HTTP redirects" part is a gigantonormous hole. A
MITM attacker on a LAN can intercept traffic to the non-HTTPS redirect
site and proxy this traffic. The ".SECURE" in the TLD looks like a
user interface declaration, the user will believe that the appearance
of .SECURE means their connection is encrypted, even when it is not.

The TLD should probably not be allowed, because it is confusing, it
looks like a User Interface Declaration, that the site is proven to
be secure, but none of the registry's proposed measures provide a
reliable assurance; it may lead the user to believe that ".SECURE" is
a technical indication that ensures the site is actually secure.

Even HTTPS and EV+SSL do not provide such a strong UI declaration. A
UI declaration should not be able to be made by the registration of a
domain alone, the software displaying the URL should be responsible
for UI declarations.

This may result in mixed signals if a site on a SLD under .SECURE
is actually compromised, which is more harmful than having no UI
declaration.

  Absent a new RFC requirement for browsers to connect to .SECURE TLD
sites using only HTTPS,
their "Non-HTTPS Redirect to HTTPS pages" are just as susceptible
to MITM hijacking as any non-HTTPS site.

prevention. In addition, Artemis would employ a rigorous screening process
to verify registrants' identities (including reviewing articles of incorporation
and human interviews), and routinely conduct security scans of registered
sites. The venture has $9.6 million (US) in funding provided by Artemis'

This is expensive, a good way to keep the TLD out of use except by
large corporations,
and is therefore of very limited value to the community. Required
to meet a generally accepted standard of security with third party
auditing would be more useful.

"Security scans" by one provider aren't really good enough. Automated
scans cannot detect insidious exploitability issues; they typically
detect and flag non-issues to justify their existence, and fail to
detect glaring issues such as session tracking in a manner vulnerable
to CSRF.

More importantly; remote periodic scans cannot detect compromise of
the site or ensure reasonable internal security practices, when the
impact is information leak, intruders don't always insert malware on
the front page for a scanner to pick up.

12

No. Let's go the opposite direction and make DNS a decentralized trust model. :slight_smile:

13

Note that you've misquoted; that was a reply to my post, possibly 2 levels deep.

14

This may result in mixed signals if a site on a SLD under .SECURE
is actually compromised, which is more harmful than having no UI
declaration.

The greatest advantage of .SECURE is that it will help ensure that all the high-value targets are easy to find.

15

one of the rationalizations for imposing a dnssec mandatory to
implement requirement (by icann staff driven by dnssec evangelists) is
that all slds are benefit equally from the semantic.

restated, the value of protecting some bank.tld is indistinguishable
from protecting some junk.tld.

re-restated, no new tlds will offer no economic, or political,
incentives to attack mitigated by dnssec.

i differed from staff-and-dnssec-evangelists, and obviously lost.

see also all possible locations for registries already have native v6,
or can tunnel via avian carrier, another staff driven by ipv6
evangelists, who couldn't defer the v6 mandatory to implement
requirement until availability was no longer hypothetical, or
scheduled, for which difference again availed naught.

as a marketing message, sld use of .secure as a tld may be sufficient
to ensure that a sufficient density of high-value targets are indeed
slds of that tld. staff has not discovered a stability and security
requirement which is contra-indicated by such a common fate / point of
failure.

note also that the requirements for new tlds are significantly greater
than for the existing set, so whatever the .com operator does, it is
not driven by the contract compliance regime which contains either the
dnssec or v6 manditory upon delegation bogies.

-e

p.s. the usual -sec and -6 evangelicals can ... assert their inerrant
correctness as a matter of faith -- faith based policy seems to be the
norm.

16

Well, I note that at least the .secure promoters haven't decided it's
a good idea:

; <<>> DiG 9.7.3-P3 <<>> @NS15.IXWEBHOSTING.COM -t DNSKEY dot-secure.co +dnssec +norec +noall +comment
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27872
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

Best,

A

17

the _known_ .secure-and-all-confusingly-similar-labels promoters.

the reveal is weeks away, followed by the joys of contention set
formation.

there may be more than one .secure application, and who knows, perhaps
a .sec in the bag, or a .cure, or a .seeker, or .sequre, or ...

however, yeah, the requirement bites at contract / delegation time, so
about a year in the future.

-e