Re: Wacky Weekend: The '.secure' gTLD
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
Re: Wacky Weekend: The '.secure' gTLD
On Mon, Jun 04, 2012 at 02:49:37PM -0400, Eric Brunner-Williams wrote: > > one of the rationalizations for imposing a dnssec mandatory to > implement requirement (by icann staff driven by dnssec evangelists) is 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 -- Andrew Sullivan Dyn Labs asulli...@dyn.com
Re: Wacky Weekend: The '.secure' gTLD
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.
RE: Wacky Weekend: The '.secure' gTLD
> 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. --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org
Re: Wacky Weekend: The '.secure' gTLD
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 wrote: On 5/31/12, Jay Ashworth 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
Re: Wacky Weekend: The '.secure' gTLD
No. Let's go the opposite direction and make DNS a decentralized trust model. :) > Digress.
Re: Wacky Weekend: The '.secure' gTLD
On 5/31/12, Jay Ashworth 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
Re: Wacky Weekend: The '.secure' gTLD
On 5/31/12 10:52 PM, John Levine wrote: >> 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
Re: Wacky Weekend: The '.secure' gTLD
> 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. Right. But your "high cost" is relative to dime-a-dozen vanity domains and/or domains for small/tiny businesses. That's not their target market. How much would it be worth to a bank if they could keep a few of their customers from being scammed? How much would it be worth to an ISP if they could keep a few of their customers from being phished? For starters, just consider the support costs. Here is a note from a different context that says it only costs $99 for Verisign to certify you to sign secure-boot stuff for Windows 8, so I think that's the right ballpark. http://mjg59.dreamwidth.org/12368.html I'm assuming that the hard part is the initial verification, not the ongoing monitoring that can be automated. YMMV. I might be all wet. ... -- These are my opinions. I hate spam.
Re: Wacky Weekend: The '.secure' gTLD
On Thu, 31 May 2012 20:11:22 -0400, Jay Ashworth said: > 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. :) pgpCGhqyQbTJI.pgp Description: PGP signature
Re: Wacky Weekend: The '.secure' gTLD
>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.
Re: Wacky Weekend: The '.secure' gTLD
On 05/31/2012 06:16 PM, Fred Baker wrote: 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, 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
Re: Wacky Weekend: The '.secure' gTLD
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 > 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=t...@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 > , 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 h
Re: Wacky Weekend: The '.secure' gTLD
On 05/31/2012 05: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. 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
Re: Wacky Weekend: The '.secure' gTLD
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 wrote: > On Thu, May 31, 2012 at 9:19 PM, Jay Ashworth wrote: > > - Original Message - > >> From: "Jay Ashworth" > > > >> 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 > >
Re: Wacky Weekend: The '.secure' gTLD
On Thu, May 31, 2012 at 9:19 PM, Jay Ashworth wrote: > - Original Message - >> From: "Jay Ashworth" > >> 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
Re: Wacky Weekend: The '.secure' gTLD
- Original Message - > From: "Jay Ashworth" > 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. Cheers, -- jra -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
Wacky Weekend: The '.secure' gTLD
"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 -- Jay R. Ashworth Baylink j...@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
