[153185] in North American Network Operators' Group
Re: Wacky Weekend: The '.secure' gTLD
daemon@ATHENA.MIT.EDU (Fred Baker)
Thu May 31 21:17:53 2012
From: Fred Baker <fred@cisco.com>
In-Reply-To: <CAPiURgUWZLJ8f7gS3HpR=0KE_TZ5OmmYBJ5VhPd729wvNpC_yQ@mail.gmail.com>
Date: Thu, 31 May 2012 18:16:21 -0700
To: Grant Ridder <shortdudey123@gmail.com>
Cc: Nanog <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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
>=20
> 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...
>>=20
>> 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.
>>=20
>> 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?
>>=20
>> 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.
>=20
> Well, show this to your buddies.
>=20
> 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.
>=20
> Also in the envelope, you may find a datum that looks like:
>=20
>> DKIM-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/simple;
>> d=3Dcisco.com; i=3Dtli@cisco.com; l=3D319; q=3Ddns/txt;
>> s=3Diport; t=3D1336587580; x=3D1337797180;
>> h=3Dsubject:mime-version:from:in-reply-to:date:cc:
>> content-transfer-encoding:message-id:references:to;
>> bh=3DcXlHIR7jgb7lDsoGWEAx6MS6AJ7zJwnnwkO+N7lsBqs=3D;
>> b=3Dgks8REH7Yho0kcjPt/+H8FJMmi0qF/tZ/mpARWFevTiObT64ZaXog3+k
>> tDKdaPOAYQYJ8OoJfT/ynOGdtOnN87adlM0lUoDgY5s7bg6juBnaSESG0
>> UMo18OTQiwuXzV94LNzNSl3lsH++1tfzbsNJe1p+TzjGtBljFoQgMZu4l
>> c=3D;
>=20
> 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.
>=20
> I'll bet you find a similar thing in this very note.
>=20
> "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:
>=20
>> DKIM-Signature: v=3D1; a=3Drsa-sha256; c=3Drelaxed/relaxed;
>> d=3Dgmail.com; s=3D20120113;
>> h=3Dmime-version:date:message-id:subject:from:to:content-type;
>> bh=3D+PAULPy6MwBt3TU1am4I5yRRvfudEeK0k2nzWGCD6kY=3D;
>> =
b=3DaKMwdM9q/Jh72pJ51i3Kyumy6wIMk6osgAfCyukFh2ATgiy3yWuu5oam4/DgRvo81+
>> =
OD0xeYqSyTx2Z2qjUxHtz9kl5nxCkNWlePbOjefog0gfPH1nKN/Kw/562k7OFvl3WeXd
>> =
hOIfpNOZb+W5wBIavFg9HKLvr8oDCcNNNkAx0c4WlynMNodcpQVkFchsYDFfV0x5jNme
>> =
st/+XLCNmjE1h73/WGmRn3AVJ7WaHKWWdW8PDKw2p1HLnrN8l1FCDeWDX6dMHtABSLuH
>> =
C5ScenHkhgPDcAyDdjSmVqEPmuaUB4GU7BaNRqwsUMjcvJZxYuOETux05pBYY2HpRYTC
>> D6yQ=3D=3D
>=20
> 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=20=
>=20
> - "I don't think that domain <> implements DKIM, so I'll just accept =
the message", or=20
> - "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=20
> - "I think it does, and this email has one, but the signature is =
bogus; I'll drop it", or=20
> - "I think it does, and this email has one that checks out, so I'll =
deliver it to Lt Baker".
>=20
> 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.
>=20
> Policy.
>=20
> What if nobody implements the policy? We all put signatures on our =
mail, but nobody checks them?
>=20
> Phishing. That's what happens.
>=20
> 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.
>=20
> 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.
>=20
> 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.=20
>=20
> 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.
