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 On Thu, May 31, 2012 at 7:29 PM, Rubens Kuhl <rubensk@gmail.com> wrote:

On Thu, May 31, 2012 at 9:19 PM, Jay Ashworth <jra@baylink.com> wrote:

...

----- Original Message -----

...

From: "Jay Ashworth" <jra@baylink.com>

...

Subject: Wacky Weekend: The '.secure' gTLD

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.

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

On May 31, 2012, at 5:43 PM, Grant Ridder wrote:

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... Begin forwarded message:

From: Fred Baker <fred@cisco.com> Date: May 9, 2012 12:55:40 PM PDT To: Colin Baker <...> Subject: Re: skynet

On May 9, 2012, at 2:14 PM, Colin Baker wrote:

...

so my friends and i have taken to calling you 'Skynet' since you invented the internet and have full access to all technological secrets...

A question came up last night regarding phishing attempts. When we call our banks or other companies, we have to identify as the customer by giving specific info such as mother's maiden name, password, last 4, etc. That is so the company knows that this is us and not an identify thief.

Why dont companies have to do the same thing with us? I could get a random call from someone claiming to be Wells Fargo, but they dont have to do anything like 'the wells fargo secret code is 117 and the authentication for me to call about your account is 7G.' would it make sense to have that sort of two-way authentication?

We thought you might know, since your hands are in every realm of current business practices, technology, and you read the encyclopedia as a kid.

Well, show this to your buddies.

If you're using Apple Mail, right now, go to the "View" bar, go down to "Message", and from there to "Raw Source". An email message contains two parts - one that is the email itself, and one (called the "envelope") that contains information used in sending the message around. There will be several lines that start with "Received:"; they tell you that the message was received by a specific Mail Transfer Agent (an application running on a computer) at a certain time; if there are several of them, you can infer that the MTA that received it sent it to the next, and if you're looking for delays in mail transfer, a large difference in time is a smoking weapon saying where that delay was.

Also in the envelope, you may find a datum that looks like:

...

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=tli@cisco.com; l=319; q=dns/txt; s=iport; t=1336587580; x=1337797180; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=cXlHIR7jgb7lDsoGWEAx6MS6AJ7zJwnnwkO+N7lsBqs=; b=gks8REH7Yho0kcjPt/+H8FJMmi0qF/tZ/mpARWFevTiObT64ZaXog3+k tDKdaPOAYQYJ8OoJfT/ynOGdtOnN87adlM0lUoDgY5s7bg6juBnaSESG0 UMo18OTQiwuXzV94LNzNSl3lsH++1tfzbsNJe1p+TzjGtBljFoQgMZu4l c=;

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.

I'll bet you find a similar thing in this very note.

"DKIM" stands for "Domain Keys Identified Mail", and is used by Google, Yahoo, and Cisco among others. Here's the DKIM Information Element from the email you sent me:

...

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=+PAULPy6MwBt3TU1am4I5yRRvfudEeK0k2nzWGCD6kY=; b=aKMwdM9q/Jh72pJ51i3Kyumy6wIMk6osgAfCyukFh2ATgiy3yWuu5oam4/DgRvo81+ OD0xeYqSyTx2Z2qjUxHtz9kl5nxCkNWlePbOjefog0gfPH1nKN/Kw/562k7OFvl3WeXd hOIfpNOZb+W5wBIavFg9HKLvr8oDCcNNNkAx0c4WlynMNodcpQVkFchsYDFfV0x5jNme st/+XLCNmjE1h73/WGmRn3AVJ7WaHKWWdW8PDKw2p1HLnrN8l1FCDeWDX6dMHtABSLuH C5ScenHkhgPDcAyDdjSmVqEPmuaUB4GU7BaNRqwsUMjcvJZxYuOETux05pBYY2HpRYTC D6yQ==

The theory is that if someone (your MTA, not your computer) receives such an information element, it can apply a policy. The policy might say

- "I don't think that domain <> implements DKIM, so I'll just accept the message", or - "I think it does, but this email doesn't have one, so obviously this isn't from that domain and therefore is bogus; I'll drop it", or - "I think it does, and this email has one, but the signature is bogus; I'll drop it", or - "I think it does, and this email has one that checks out, so I'll deliver it to Lt Baker".

There is another approach, called Secure MIME or S/MIME. Your military mail system uses it. It puts a signature on every email that you send, so we can definitively say that you personally sent it, and if we get an email from a military address that either has no signature or the signature is invalid, we can drop it. S/MIME has an additional capability - it can encrypt the mail, and it can even encrypt it in a way that only the person you sent it to can read it.

Policy.

What if nobody implements the policy? We all put signatures on our mail, but nobody checks them?

Phishing. That's what happens.

We're trying to make the network self-aware. We need to make the humans self-aware before we can do that.

Oh, I should have also said something else.

In addition, we are capable of authenticating a user that sends an email. Again assuming that you're using Apple Mail, go to the "Mail" header on the upper bar, to "Preferences", to "Accounts", to your outgoing mail server (SMTP), to "Edit SMTP Server List", to "Advanced". You'll see there that you can select a different port for mail, and that you have the option of using the Secure Sockets Layer (SSL) between you and your first MTA - your SMTP mail server. If that is configured, the server can say it knows for sure that the mail originated with you, and can therefore apply the DKIM signature.

I mentioned that I'm getting spam from Austin's YAHOO account; I wonder if you are. YAHOO uses DKIM as well, but whoever is really sending it is tricking YAHOO into believing the email is from Austin, which I suspect means that either YAHOO isn't using SSL or someone got Austin's credentials.

There are two weak links. People using the tools, and network administrators using the tools. If they are actually used, as far as we know they work. They are often not or only partially used.

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.

Note that you've misquoted; that was a reply to my post, possibly 2 levels deep. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Jimmy Hess <mysidia@gmail.com> wrote: On 5/31/12, Jay Ashworth <jra@baylink.com> wrote:

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. -- -JH

On 6/4/12 12:30 AM, Keith Medcalf wrote:

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

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.

On 6/4/12 3:28 PM, Andrew Sullivan wrote:

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

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