Subject: RE: [ietf-dkim] Delegated signatures in real life

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 29 Aug 2006 16:41:30 -0700

Orbitz might not care about the security issues raised by allowing doubleclick to sign messages on behalf of their CEO and other executives. Many others will.

This is a security area spec, least privilege must apply wherever possible.

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of John L
> Sent: Tuesday, August 29, 2006 6:18 PM
> To: DKIM List
> Subject: [ietf-dkim] Delegated signatures in real life
> 
> Here's the headers from a message that Doubleclick just sent 
> to my Yahoo account on behalf of Orbitz.  Note that the From: 
> address and DK signature are in email.orbitz.com, even though 
> it was sent by Doubleclick from a Doubleclick IP.  Yahoo 
> thoughfully displayed a little now saying that the DK 
> signature was good when I looked at the message.  I also 
> include the key record, retrieved from Doubleclick's name servers.
> 
> Senders already use NS delegation to let third parties put on 
> first party DK signatures.  It works.  It's popular.  There 
> is no need to invent another way to solve this solved problem.
> 
> Regards,
> John Levine, [email-masked], Primary Perpetrator of "The 
> Internet for Dummies", Information Superhighwayman wanna-be, 
> http://www.johnlevine.com, Mayor "More Wiener schnitzel, 
> please", said Tom, revealingly.
> 
> 
> X-Apparently-To: [email-masked] via 206.190.38.154; Tue, 
> 29 Aug 2006 07:42:48 -0700
> X-Originating-IP: [198.31.62.19]
> Authentication-Results: mta162.mail.mud.yahoo.com
>    from=email.orbitz.com; domainkeys=pass (ok)
> Received: from 198.31.62.19  (EHLO mta.email.orbitz.com) 
> (198.31.62.19)
>    by mta162.mail.mud.yahoo.com with SMTP; Tue, 29 Aug 2006 
> 07:40:52 -0700
> DomainKey-Signature: s=dk; d=email.orbitz.com; c=nofws; 
> q=dns; 
> b=nUvGhBPdC8bKVo8E/nLbHWcPJE7mFu83ePkSkmcE91EYdNUb7Wl4emekvK3t
> kHzRCu1u94C7oWy5xX/HOjRBOkudiRdnWaTMkZmHypYllnuyUX71y7WhkeojckSbInn6;
> Date: Tue, 29 Aug 2006 10:40:32 -0400 (EDT)
> From: "Orbitz"<[email-masked]>
> To: [email-masked]
> Subject: Joe, Sale Ending & Rochester Flights from $142 r/t
> MIME-Version: 1.0
> Content-Type: text/html; charset="us-ascii"
> Content-Transfer-Encoding: 7bit
> Content-Length: 6278
> 
> (look for the key record)
> 
> $ dig dk._domainkey.email.orbitz.com txt
> 
> ; <<>> DiG 9.3.1 <<>> dk._domainkey.email.orbitz.com txt ;; 
> global options:  printcmd ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23293 ;; 
> flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;dk._domainkey.email.orbitz.com.        IN      TXT
> 
> ;; ANSWER SECTION:
> dk._domainkey.email.orbitz.com. 21600 IN TXT    
> "p=MHwwDQYJKoZIhvcNAQEBBQADawAwaAJhALdLXrYpY2RRUPHr6ph9jVnrFAY
> vyNjEgGVRmxjiu2EUBEyQDKFOSiDzS00xN/HaIt5IknLJumgu/YdaHhHAgsnnO
> RUV1JwDcOZ3Xo3Iz9cT3ojg4us6SpQhl01dVGS6dwIDAQAB\;"
> 
> 
> _______________________________________________
> NOTE WELL: This list operates according to 
> http://mipassoc.org/dkim/ietf-list-rules.html
> 
> 

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 30 Aug 2006 00:56:48 +0100

> This is a security area spec, least privilege must apply wherever possible.

I'm not entirely convinced by the least privilege argument here.
(Of course, we're currently giving maximal privileges to the DNS
admins, so it may also be too late.)

Anyhow, while its a good principle, it can lead to over engineering.
And the premature involvment of legalistic stuff was, IMO, highly
detrimental to the development of PKI, so I'd personally be happy
were the WG to try to engineer dkim signatures to be as legally
insignificant as possible.

S.

PS: Chair hat off in the above of course.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Hector Santos" <[email-masked]>
Date: Tue, 29 Aug 2006 19:56:33 -0400

In addition, we completely ignore DomainKey junk like where nearly most of
the time it fails anyway.  It is a prime example of the JUNK we are trying
to eliminate.

===
HLS

----- Original Message -----
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "John L" <[email-masked]>; "DKIM List" <[email-masked]>
Sent: Tuesday, August 29, 2006 7:41 PM
Subject: RE: [ietf-dkim] Delegated signatures in real life

> Orbitz might not care about the security issues raised by allowing
> doubleclick to sign messages on behalf of their CEO and other
> executives. Many others will.
>

---

From: Steve Atkins <[email-masked]>
Date: Tue, 29 Aug 2006 17:13:54 -0700

> executives. Many others will.

Why is that a security issue?

As I understand it, email sent by [email-masked] where he
wants to assert that he is the author will use S/MIME or similar.

Domainkeys and friends specify who has taken responsibility for
an email, not the identity of the author. Anyone prepared to take
responsibility either directly or indirectly (by sharing their private
key or delegating control over some subset of their key publication)
can take do that.

So... the idea that DomainKeys would be used to "sign" email, in
an S/MIME or PGP sort of sense, on behalf of an individual seems
somewhere between meaningless and nonsensical.

What am I missing here?

Cheers,
   Steve

---

From: John L <[email-masked]>
Date: Tue, 29 Aug 2006 20:34:24 -0400 (EDT)

> executives. Many others will.

Actually, Doubleclick signs for email.orbitz.com, which is not the domain 
where the execs have their addresses.  If there is some security problem 
here, you'll have to explain more clearly what it is.

> This is a security area spec, least privilege must apply wherever possible.

Sure, but don't forget that the D in DKIM stands for Domain.  The 
granularity is domains, not mailboxes.  If you want per-mailbox 
signatures, DKIM isn't what you're looking for.

Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Information Superhighwayman wanna-be, http://johnlevine.com, Mayor
"I dropped the toothpaste", said Tom, crestfallenly.
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "william(at)elan.net" <[email-masked]>
Date: Tue, 29 Aug 2006 18:45:30 -0700 (PDT)

> What am I missing here?

Taking responsibility for email is not the same as protecting "From" 
address from unauthorized use. I may want to have "someremailer.com"
take responsibility for remailing the message that passes through them
where as when I send message directly I take responsibility for that.

At the same time I do know that some of my email (i.e. with "From"
email address) will endup  going through them and they will sign
those emails. So including them in list of 3rd party senders allows
to conclude the policy with sign-all and then nobody else can
send email on my behalf without it being violation of this policy.

The major difference really is that it is necessary for remailer to
know about you having delegated addition of signature on your behalf
with NS delegation (or some other selector location mechanism).
For policy record when verifying your "From" address no special 
action/reconfig is necessary for remailer if message with your
"From" start passing through them - only action from your side
is necessary. Operationally 2nd one is a lot easier to setup for
users and most "3rd party" mailing services i.e. compare to SPF
when you want to include list of ip address of your ISP and no
special action from your ISP is necessary, where as with NS
delegation of selectors it would be required.

-- 
William Leibzon
Elan Networks
[email-masked]

---

From: Douglas Otis <[email-masked]>
Date: Tue, 29 Aug 2006 18:35:06 -0700

On Aug 29, 2006, at 5:34 PM, John L wrote:

> Actually, Doubleclick signs for email.orbitz.com, which is not the  
> domain where the execs have their addresses.  If there is some  
> security problem here, you'll have to explain more clearly what it is.
>

Signatures can assure the integrity of assertions, where domains can  
also clarify what had been validated prior to signing.  While this  
may not allow a recipient to repeat validations for themselves, this  
information is still valuable when the recipient has cause to trust  
the signing domain.  Perhaps this trust is due to a simple  
association established with the originator via policy.  For example,  
an MSA could accept outbound messages from a mailing-list, and  
messages from authenticated accounts.  The MSA can have prior  
knowledge through various methods to assert whether the originator's  
address had been validated.  The signing domain conveying this  
information within the signature allows meaningful annotations to be  
applied at the receiver for the recipient.

When the receiver annotates the signing domain's assertions of non- 
validated and validated addresses, those message marked as validated  
can be captured for future reference by the MUA.  The actual identity  
of the originator requires out-band methods.  This out-of-band method  
could be something as simple as a pass-phrase conveyed over a phone  
call or secure web page.  The granularity is one bit, validated/not- 
validated.  The recipient has an equally simple choice based on  
captured references, to trust a claim of validation or not.

DKIM offers a means for domains to convey valuable information and to  
retain trust in their integrity and that of their individual users  
separately.  The identity of the originator must be determined  
through other means, but that is a good thing.  It would be wholly  
impractical to expect all users within an entire domain to be equally  
trustworthy.  Without a means of differentiating users by whatever  
means, DKIM becomes significantly devalued.

-Doug

---

From: "J.D. Falk" <[email-masked]>
Date: Wed, 30 Aug 2006 14:49:34 -0700

> executives. Many others will.

Then they won't delegate the record they use to sign mail from their CEO 
and other executives.  No problem.

-- 
J.D. Falk, Anti-Spam Product Manager
Yahoo! Communications Platform Team
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html