Subject: RE: [ietf-dkim] SSP Responsibility Delegation - Security Concerns

From: <[email-masked]>
Date: Wed, 16 Aug 2006 17:52:08 -0400

Jim,
I must be missing something here,
d=isp.net i=[email-masked] the message verifies successfully because the isp.net signed it and the SSP=I sign all at isp.net indicates it does 3rd party signatures?
thanks,
Bill

-----Original Message-----
From: [email-masked] on behalf of Jim Fenton
Sent: Wed 8/16/2006 5:01 PM
To: IETF-DKIM
Subject: [ietf-dkim] SSP Responsibility Delegation - Security Concerns
 
[I have been on vacation the last 2 weeks, and you folks have been
busy!  I can't possibly read everything that was said; excuse me if I
duplicate an issue here and there.  I don't think this is a duplicate
though...]

This concerns the use of SSP to delegate responsibility for signing
messages to a non-related domain without active participation by that
domain: requirement 5 of section 5.3 in ssp-requirements-00.  I think
there's a security problem here, in that it could cause a signature to
be mis-interpreted as a first-party (origination) signature when it's
not.  I'll deviate from the usual use of "example.com" to make the roles
clearer but these are all fictitious domains.

Suppose author.com uses SSP to cause signatures from its service
provider, isp.net, to be interpreted as first-party signatures.  So
[email-masked] sends its outgoing mail to isp.net (hopefully using
authenticated submission), and isp.net applies its own signature.  A
verifier acting on behalf of the recipient sees the signature, looks up
SSP for author.com, and concludes that the message has a first-party
signature.  This is the desired result.

Now suppose that isp.net also hosts some mailing lists.  An attacker
spoofs a message from [email-masked] to some mailing list which will
accept a message from that address.  The mailing-list re-signs its
messages by applying a signature from isp.net.  The verifier will look
at this signature and incorrectly conclude that it's a first-party
signature, while in fact it's a third-party signature on behalf of the list.

This is the problem that the i= tag in the signature is there to solve. 
If instead the mailing list were at author.com, a verifier could
distinguish a signature from the author from a list signature by the
different local-part in i=.  But we can't use i= in this case, because
it has to match (or, perhaps be a subdomain of) the d= domain for the
signature to be valid at all.  In other words, a signature which has
i=[email-masked] and d=isp.net is never valid.

I have a number of other issues with the SSP-based delegation idea as
well, but this is the most clear cut.

-Jim
_______________________________________________
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: Douglas Otis <[email-masked]>
Date: Wed, 16 Aug 2006 15:07:27 -0700

On Aug 16, 2006, at 2:01 PM, Jim Fenton wrote:

> Now suppose that isp.net also hosts some mailing lists.  An  
> attacker spoofs a message from [email-masked] to some mailing list  
> which will accept a message from that address.  The mailing-list re- 
> signs its messages by applying a signature from isp.net.  The  
> verifier will look at this signature and incorrectly conclude that  
> it's a first-party signature, while in fact it's a third-party  
> signature on behalf of the list.

There are many cases where a bad actor could spoof an [email-masked]  
address sent from isp.net.  When isp.net does not use account  
specific authentication, or ensure that email-addresses are permitted  
only after a verification of the account being able to receive at  
that email-address, then these would be other cases where a problem  
could exist.

Here is where an organization like DAC could play an important role  
by certifying which DKIM domains are taking the needed steps to  
protect the From email-address.  Issues related to things like  
mailing list could be resolved by signing these messages using a  
different designated domain.  This would keep the isp.net domain from  
being contaminated by these other uses.  Of course a mailing list  
could also be placed within a different subdomain.  In this case, the  
designated domain should not be listed with a wildcard entry to  
prevent subdomains from being included as being a designated domain.

-Doug

---

From: <[email-masked]>
Date: Wed, 16 Aug 2006 18:12:10 -0400

Im starting to think a 3rd party signature only signing domain with an I only sign mailing lists flag being set may be useful.
thanks,
Bill

-----Original Message-----
From: [email-masked] on behalf of Douglas Otis
Sent: Wed 8/16/2006 6:07 PM
To: Jim Fenton
Cc: IETF-DKIM
Subject: Re: [ietf-dkim] SSP Responsibility Delegation - Security Concerns

-Doug

---

From: Douglas Otis <[email-masked]>
Date: Wed, 16 Aug 2006 15:54:30 -0700

On Aug 16, 2006, at 2:52 PM, <[email-masked]>  
<[email-masked]> wrote:

> d=isp.net i=[email-masked] the message verifies successfully  
> because the isp.net signed it and the SSP=I sign all at isp.net  
> indicates it does 3rd party signatures?

The ssp would be referenced from 2822.From domain author.com.  Policy  
is not obtained from the signing domain.

This reference would indicate what domains are designated as being  
authoritative for the 2822.From domain.

This designated list might return DSD: isp.net, *.author.com.

It would be illegal per the base draft for the i=[email-masked] to  
be used.  This parameter could be excluded or point to some other  
header that contains an isp.net email-address.

Designating a domain will likely require some knowledge of how the  
domain protects the 2822.From addresses being used.  If there is no  
protection, then anyone could spoof.  Protecting a 2822.From email- 
address could be achieved in a number of ways.  To allow the user  
flexibility, a confirmation similar to that used to subscribe to a  
mailing list could be used per account.  This should be rather simple  
to automate.

All other uses within that domain could then use a separate  
designated domain.  For example signing messages for a list at  
isp.net could have lists.isp.net act as a designated domain for  
isp.net.  This would isolate messages signed by the list from those  
signed on behalf of authenticated accounts.  Conversely, the direct  
accounts could be signed by a designated domain users.isp.net.   
Designated domain lists provide a fair amount of flexibility for  
resolving these types of issues.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Wed, 16 Aug 2006 15:56:33 -0700

Bill,

See dkim-base-04, section 3.5, description of i= tag:  The domain part
of the address MUST be the same as or a subdomain of the value of the
"d=" tag.

This rule is not dependent on SSP.  So if isp.net were to sign for
[email-masked], it would either omit i= entirely, use i=@isp.net, or
create an artificial local-part and use that with i=.  There's some
possibility that one could disambiguate this case with artificial
local-parts, but then we're violating (IMO) the premise of "without
active participation by that domain".  It also overloads the meaning of
the local-part.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Wed, 16 Aug 2006 15:58:27 -0700

Douglas Otis wrote:
>> messages by applying a signature from isp.net.  The verifier will
>> look at this signature and incorrectly conclude that it's a
>> first-party signature, while in fact it's a third-party signature on
>> behalf of the list.
>
> address sent from isp.net.  When isp.net does not use account specific
> authentication, or ensure that email-addresses are permitted only
> after a verification of the account being able to receive at that
> email-address, then these would be other cases where a problem could
> exist.
What you're describing are all things that isp.net could do by using the
right protocols, e.g., authenticated submission.  What I'm describing is
a weakness in the protocol that can't be fixed that way.

-Jim

---

From: Douglas Otis <[email-masked]>
Date: Wed, 16 Aug 2006 16:23:51 -0700

On Aug 16, 2006, at 3:58 PM, Jim Fenton wrote:

> Douglas Otis wrote:
>>
>> There are many cases where a bad actor could spoof an  
>> [email-masked] address sent from isp.net.  When isp.net does not  
>> use account specific authentication, or ensure that email- 
>> addresses are permitted only after a verification of the account  
>> being able to receive at that email-address, then these would be  
>> other cases where a problem could exist.
>
> What you're describing are all things that isp.net could do by  
> using the right protocols, e.g., authenticated submission.  What  
> I'm describing is a weakness in the protocol that can't be fixed  
> that way.

A 2822.From domain designating a different signing domain should  
first understand whether there are steps taken by the signing domain  
that offer adequate protection.  One such step might be to ensure  
that non-authenticated list messages are not signed with the same  
signing domain signature used for authenticated account messages.   
Here designated domains offer a possible solution without the need to  
change the email-addresses into different subdomains.

It seems there would be value obtained by taking these steps.  These  
steps would allow the ISP's customers an ability to use their  
services and have their messages signed while using their email- 
address.  This type of use would require the email-addresses being  
used have been validated or constrained by the provider prior to  
their use.

This seems like a minor change for the better.  What weakness can't  
be fixed by the proper procedures followed by a signing domain?  It  
would seem that first step for designating a signing domain would be  
to check a list of certified DKIM signers that are deemed suitable  
for non-matching domains.  If they are not on the list, don't use  
their service.

-Doug

---

From: Jim Fenton <[email-masked]>
Date: Wed, 16 Aug 2006 16:36:29 -0700

Douglas Otis wrote:
>>> use account specific authentication, or ensure that email-addresses
>>> are permitted only after a verification of the account being able to
>>> receive at that email-address, then these would be other cases where
>>> a problem could exist.
>>
>> What you're describing are all things that isp.net could do by using
>> the right protocols, e.g., authenticated submission.  What I'm
>> describing is a weakness in the protocol that can't be fixed that way.
>
> A 2822.From domain designating a different signing domain should first
> understand whether there are steps taken by the signing domain that
> offer adequate protection.  One such step might be to ensure that
> non-authenticated list messages are not signed with the same signing
> domain signature used for authenticated account messages.  Here
> designated domains offer a possible solution without the need to
> steps would allow the ISP's customers an ability to use their services
> and have their messages signed while using their email-address.  This
> type of use would require the email-addresses being used have been
> validated or constrained by the provider prior to their use.
Sure; regardless of the mode of delegation, whether it's done by SSP, or
by delegating a key or by NS delegation, the domain doing the delegating
should first make sure that they're delegating to a responsible party.
>
> This seems like a minor change for the better.  What weakness can't be
> fixed by the proper procedures followed by a signing domain?
The one I described:  the inability for a verifier to distinguish an
author signature generated by the delegate from a third-party signature
generated by the delegate operating in a different context.

-Jim

---

From: Jim Fenton <[email-masked]>
Date: Wed, 16 Aug 2006 14:01:17 -0700

-Jim

---

From: "Hector Santos" <[email-masked]>
Date: Wed, 16 Aug 2006 20:00:27 -0400

----- Original Message -----
From: "Jim Fenton" <[email-masked]>

 >> This seems like a minor change for the better.  What weakness
>> can't be fixed by the proper procedures followed by a
>> signing domain?

> The one I described:  the inability for a verifier to distinguish
> an author signature generated by the delegate from a
> third-party signature generated by the delegate operating in
> a different context.

This sounds more like a delegate problem.

If the ISP.NET was going to play the rules, then it would avoid such
activity of signing or resigning mailing list mail when in fact it has an
exclusivity contract with the domain author.com to sign in an exclusive
manner in behalf of author.com.  He's breaking his own security as well as
the domain.

This all goes back to the thread we had in MAILSIG:

3rd party Signers - Definition/Usage
http://www.imc.org/ietf-mailsig/mail-archive/msg01933.html

Your scenario is all part of this.

What "contract" does the ISP have with the domain?

Also, by the same token, if the domain "expects" to have to his domain
associated with a mailing list, then it probably should not be using
exclusive contracts with the delegate signer.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com

---

From: <[email-masked]>
Date: Wed, 16 Aug 2006 20:13:46 -0400

Thanks Doug,

-----Original Message-----
From: Douglas Otis [mailto:[email-masked]]
Sent: Wed 8/16/2006 6:54 PM
To: Oxley, Bill (CCI-Atlanta)
Cc: [email-masked]; [email-masked]
Subject: Re: [ietf-dkim] SSP Responsibility Delegation - Security Concerns

-Doug

---

From: Michael Thomas <[email-masked]>
Date: Wed, 16 Aug 2006 17:41:35 -0700

>generated by the delegate operating in a different context.
What would be useful is for people who are neutral about this issue to
look at the attack vector Jim describes. It sure seems real to me, but some
independent verification would be helpful as well. In particular what would
be nice is to place requirement constraints on the protocol such that this
attack must be able to be mitigated by the delegated third party. If that's
possible at all.

       Mike

---

From: Douglas Otis <[email-masked]>
Date: Wed, 16 Aug 2006 18:15:41 -0700

On Aug 16, 2006, at 4:36 PM, Jim Fenton wrote:

>> can't be fixed by the proper procedures followed by a signing domain?
>
> an author signature generated by the delegate from a third-party  
> signature generated by the delegate operating in a different context.

isp.net can encode context using subdomain signatures:

- [email-masked] messages use d=relay.isp.net
- [email-masked] messages use d=lists.isp.net
- [email-masked] messages use d=users.isp.net
- From policy designates users.isp.net as authoritative for isp.net  
(no other flags)
- i= parameter is not included in the signature header

Users with 2822.From domains outside of isp.net are afforded  
isolation by designating users.isp.net to avoid conflicts with  
messages signed from other sources.  None of the mail from these  
other sources would be considered authoritative for the 2822.From  
address which is the desired goal.  Only user.isp.net would be  
considered authoritative for isp.net (or validated outside domains  
designating users.isp.net) emails.  Mail through relays and lists  
would appear to be signed by an outside domain in this example.  As  
the 2822.From has not been validated along these other paths, the  
signing domain should not be represented as being authoritative.   
What is the problem?

-Doug