Re: Wacky Weekend: The '.secure' gTLD

2012-06-04 Thread Eric Brunner-Williams
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 on

Re: Wacky Weekend: The '.secure' gTLD

2012-06-04 Thread Andrew Sullivan
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: ;

Re: Wacky Weekend: The '.secure' gTLD

2012-06-04 Thread Eric Brunner-Williams
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 a

RE: Wacky Weekend: The '.secure' gTLD

2012-06-03 Thread Keith Medcalf
> 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

Re: Wacky Weekend: The '.secure' gTLD

2012-06-03 Thread Jay Ashworth
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 DN

Re: Wacky Weekend: The '.secure' gTLD

2012-06-03 Thread Charles Morris
No. Let's go the opposite direction and make DNS a decentralized trust model. :) > Digress.

Re: Wacky Weekend: The '.secure' gTLD

2012-06-03 Thread Jimmy Hess
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 t

Re: Wacky Weekend: The '.secure' gTLD

2012-06-01 Thread Eric Brunner-Williams
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 suggest

Re: Wacky Weekend: The '.secure' gTLD

2012-05-31 Thread Hal Murray
> 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 v

Re: Wacky Weekend: The '.secure' gTLD

2012-05-31 Thread valdis . kletnieks
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 w

Re: Wacky Weekend: The '.secure' gTLD

2012-05-31 Thread John Levine
>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

Re: Wacky Weekend: The '.secure' gTLD

2012-05-31 Thread Michael Thomas
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

Re: Wacky Weekend: The '.secure' gTLD

2012-05-31 Thread Fred Baker
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 neces

Re: Wacky Weekend: The '.secure' gTLD

2012-05-31 Thread Michael Thomas
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 neve

Re: Wacky Weekend: The '.secure' gTLD

2012-05-31 Thread Grant Ridder
ote: > 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

Re: Wacky Weekend: The '.secure' gTLD

2012-05-31 Thread Rubens Kuhl
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

Re: Wacky Weekend: The '.secure' gTLD

2012-05-31 Thread Jay Ashworth
- 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.

Wacky Weekend: The '.secure' gTLD

2012-05-31 Thread Jay Ashworth
"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-encrypt