Subject: Re: [ietf-dkim] I-D Action:draft-ietf-dkim-ssp-00.txt

From: Jim Fenton <[email-masked]>
Date: Thu, 05 Jul 2007 14:25:39 -0700

Thanks, Stephen.  I had a good vacation, and I'm back.

I have seen a few comments on the list, in particular Phillip's comment
about the downgrade attack that we need to discuss more.  If any of you
are holding onto comments, please go ahead.

I'm particularly interested in reactions to the algorithm given in
section 4.4.  This is another attempt to strike the right balance
between security (the SHOULD for subdomain coverage in SSP requirements
section 5.1 #4), ease of deployment (trying to avoid doubling the size
of zones with extra SSP records), and avoiding creation of unacceptable
loads on DNS, and root and TLD name servers in particular.  Speak up if
there are any uncovered holes in this algorithm, or where I haven't
achieved these goals.

-Jim

Stephen Farrell wrote:
>
> Couple of quick notes on that:
>
> 1. Thanks to Jim for getting it out before his vacation.
>
> 2. Since he's on vacation we might have to wait if we've
> "why'd you do that..." questions, though other authors
> are about.
>
> 3. Remember that this is a -00 I-D so don't treat it as
> if its written in store. OTOH, concrete alternatives are
> much better than just criticising - we have after all
> been chatting about this for ages already.
>
> S.
>
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: Douglas Otis <[email-masked]>
Date: Fri, 6 Jul 2007 10:20:19 -0700

On Jul 5, 2007, at 2:25 PM, Jim Fenton wrote:

> I have seen a few comments on the list, in particular Phillip's  
> comment about the downgrade attack that we need to discuss more.   
> If any of you are holding onto comments, please go ahead.

While Phillip is correct about the downgrade issue, the key record  
would need to be modified instead of an SSP record.  The SSP record  
is only checked when the message is not signed by a domain that is at  
or above the email address domain.

> section 4.4.

The only way to provide full coverage without dramatically increasing  
the zone size would be to ensure an SSP record coincides with every  
SMTP discovery record (MX and A).  Deprecation of the A for discovery  
now should exclude use of AAAA records from becoming a problem.  Over  
time, A record discovery could be obsoleted where SSP records would  
only need to coincide with MX records.  The A record discovery aspect  
of SMTP would become obsolete once a MX record for an email-address  
domain becomes a requisite for message acceptance at public SMTP  
servers.  A record discovery could continue to function with the  
sending of messages well after A record discovery becomes deemed  
obsolete to support a acceptance requirement.  This would mean a  
email-address domain lacking an MX record might have trouble sending  
their messages, where some are already finding this to be the current  
state.

> This is another attempt to strike the right balance between  
> security (the SHOULD for subdomain coverage in SSP requirements  
> section 5.1 #4), ease of deployment (trying to avoid doubling the  
> size of zones with extra SSP records), and avoiding creation of  
> unacceptable loads on DNS, and root and TLD name servers in  
> particular.  Speak up if there are any uncovered holes in this  
> algorithm, or where I haven't achieved these goals.

Little is achieved by using wildcards.  Wildcard synthesis blocking  
within the DNS protocol necessitates placement of both a wildcard and  
non-wildcard RRs at every DNS node.  As an alternative, establishing  
tighter conventions upon discovery records actually reduces the  
amount of data published within DNS.  Limited discovery also requires  
fewer DNS transactions, and can be a broadly applied strategy for  
other protocols.  It would also mean that the current strategy of  
prefixed TXT records can be utilized.

Deploying a new wildcard XPTR scheme will necessitate increasing the  
zone size.  The XPTR scheme requires additional transactions which  
will likely to return NXDOMAIN for many years.  Those that fear a new  
RR might not be supported will also need to support an alternative  
method as well.  Unless this alternative depends upon a limited  
discovery record, such as MX or SRV records, the size of the zone  
could grow exponentially larger as other protocols attempt the same  
strategy.  Limiting discovery records is really the only reasonable  
solution for any protocol attempting to establish policy records.

-Doug

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 10 Jul 2007 14:15:28 -0700

From: [email-masked] on behalf of Douglas Otis

		

I would like to discuss the downgrade attack certainly. We have to address the attack either by solving it or by explaining it in the security considerations.

Doug's statement above is not correct though. A recipient ONLY looks at the policy record if it does not find an acceptable signature record. That means:

A) The message has no signature at all

B) The message has a signature header but it fails to verify

C) The message has a signature that references a signature key for an algorithm that is not acceptably secure

D) The message has a signature that references a signature key for an algorithm that the recipient is unable to verify.

The outcome from signature verification is binary: either a valid signature was found, or it was not. A client that implements BASE alone is not allowed to distinguish between the four cases above. This limits the field of application to whitelisting good mail.

With policy we have three outcomes, the outcome 'not found' is expanded to 'compliant with policy' or 'not compliant with policy'.

The point about the upgrade/downgrade attack is that a DKIM policy is determined by both the key records and the policy records. A key record is an implicit statement that the signer MAY use the specified key to sign a message. 

We want to be able to ensure that a recipient is able to correctly determine whether a message signature is or is not compliant with policy in cases C and D. Without the ability to code the policy 'every message is signed with an RSA key and a EC-DSA key' we are unable to publish an EC-DSA key without allowing the attacker to negate our policy.

The information about the algorithms is kept in the key records, what we need in the policy section is a restriction on the key selectors.

What I propose here is to eliminate the 'partial signature' policy statements that Jim has defined and replace them with the ability to specify restrictions on the signing keys. This is neutral from a complexity point of view. We eliminate a useless option and replace it with an option we very much need.

---

From: Douglas Otis <[email-masked]>
Date: Tue, 10 Jul 2007 16:37:57 -0700

On Jul 10, 2007, at 2:15 PM, Hallam-Baker, Phillip wrote:

> I would like to discuss the downgrade attack certainly. We have to  
> address the attack either by solving it or by explaining it in the  
> security considerations.
>
> Doug's statement above is not correct though. A recipient ONLY  
> looks at the policy record if it does not find an acceptable  
> signature record. That means:
>
> C) The message has a signature that references a signature key for  
> an algorithm that is not acceptably secure
>
> D) The message has a signature that references a signature key for  
> an algorithm that the recipient is unable to verify.

Don't forget.

E) The message has a signature by a Third-Party domain.

You are describing a policy conformance issue caused when an  
algorithm is upgraded, but not yet supported by the recipient.  IMO,  
this is not a downgrade attack, although this could affect policy  
compliance.

When the key is obtained, it should be possible to determine whether  
the key's algorithm is supported.  Unfortunately, a key's notation  
will not cover all aspects of the signing and verification process.   
A downgrade attack might occur when two signatures are added to  
ensure compliance during an upgrade transition.

There might be an attack made possible when a stronger algorithm is  
trivially defeated.  This might happen when a weaker algorithm is  
accepted, although both algorithms are supported.  Exploitation of a  
weaker algorithm could be considered a downgrade attack when a  
stronger algorithm is supported.

The other situation might be removal of the weaker algorithm, where  
evidence a different algorithm is supported by the signing domain may  
offer some level of acceptance.  Removal of the weaker algorithm and  
spoofing a stronger algorithm might be considers an a spoofed upgrade  
attack.

Having a stronger signature algorithm signed by a weaker algorithm  
might be an expensive and perhaps fragile solution to a downgrade  
attack.  However, this approach presupposes the nature of the weaker  
algorithm's exploit.  Although a weaker algorithm may become  
problematic, abandoning a weaker algorithm may be untenable as this  
may invite conditions leading to a spoofed upgrade attack.

Preventing a downgrade attack, without presupposing what the weakness  
might be, could be handled by defining a flag within the key  
indicating that it had been deprecated and what key pairs should be  
present.  The purpose of the deprecated flag is to indicate that the  
key MUST BE accompanied by a stronger signature.  Identifying the  
stronger and weaker algorithms should also be done within the keys to  
minimize overhead and preclude either a downgrade or spoofed upgrade  
attack.

> The outcome from signature verification is binary: either a valid  
> signature was found, or it was not. A client that implements BASE  
> alone is not allowed to distinguish between the four cases above.  
> This limits the field of application to whitelisting good mail.

Agreed.

> With policy we have three outcomes, the outcome 'not found' is  
> expanded to 'compliant with policy' or 'not compliant with policy'.

It would seem two signatures would be the only reasonable method for  
transitioning with a strict policy.  As such, there should not be  
policy exceptions made based upon what only appears to be supported.   
The domain should be allowed to explicitly indicate what has been  
deprecated, and indicate what should be accompanied by each other  
signature within the keys.

> The point about the upgrade/downgrade attack is that a DKIM policy  
> is determined by both the key records and the policy records. A key  
> record is an implicit statement that the signer MAY use the  
> specified key to sign a message.
>
> We want to be able to ensure that a recipient is able to correctly  
> determine whether a message signature is or is not compliant with  
> policy in cases C and D. Without the ability to code the policy  
> 'every message is signed with an RSA key and a EC-DSA key' we are  
> unable to publish an EC-DSA key without allowing the attacker to  
> negate our policy.

It would seem any unsupported algorithm clearly falls into a 'not  
signed' category.  When policy is strict, this would be within the  
'not compliant with policy' category.

> The information about the algorithms is kept in the key records,  
> what we need in the policy section is a restriction on the key  
> selectors.

This is difficult to follow.  How can a global policy differentiate  
whether it is okay to use selector A or B.  One might presume both  
selectors are used or they would not be published.  If one were to  
sign an email-address within a sub-domain, it could also utilize  
different keys within both higher and lower domains.  The stronger  
signatures could be valid only for a sub-domain email-address whereas  
the weaker signature could be used for either domain without possible  
conflict.

Authorization of signatures within sub-domains could be used.   
Restrictions of such authorizations could occur within a TPA-SSP  
without inducing additional overhead.   : )

> What I propose here is to eliminate the 'partial signature' policy  
> statements that Jim has defined and replace them with the ability  
> to specify restrictions on the signing keys. This is neutral from a  
> complexity point of view. We eliminate a useless option and replace  
> it with an option we very much need.

It is not clear what mechanism is being proposed.  The TPA-SSP could  
be extended to include a  '*+<policy-limitation>' local-part matching  
component as an added restriction.

-Doug

---

From: "Charles Lindsey" <[email-masked]>
Date: Wed, 11 Jul 2007 11:17:54 +0100

On Wed, 11 Jul 2007 00:37:57 +0100, Douglas Otis <[email-masked]>  
wrote:

>> Doug's statement above is not correct though. A recipient ONLY looks at  
>> the policy record if it does not find an acceptable signature record.  
>> That means:

Eh? A recipient can look at a policy record whenever he sees fit to do so,  
and for whatever reason.

> E) The message has a signature by a Third-Party domain.

And

F) The signer seemed to be unrelated to the From/Sender/Whatever headers;

G) The signature covered an "unusual" selection  of headers;

H) There were several signatures, of which some passed and some failed;

I) Umpteen other reasons why it looked suspicious.

A Policy Record might well clear up some (probably not all) of such cases.  
Moreover, experience will throw up new scams that the Bad Guys will  
invent, and so it may become necessary to add new kinds of information to  
Policy records that we have not even thought of yet. So, to that extent,  
their notation needs to be extensible.

-- 
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131                       
   Web: http://www.cs.man.ac.uk/~chl
Email: [email-masked]      Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9      Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Thu, 12 Jul 2007 07:34:34 -0700

> [mailto:[email-masked]] On Behalf Of Charles Lindsey
> Sent: Wednesday, July 11, 2007 6:18 AM

> >> Doug's statement above is not correct though. A recipient 
> ONLY looks 
> >> at the policy record if it does not find an acceptable 
> signature record.
> >> That means:
> 
> Eh? A recipient can look at a policy record whenever he sees 
> fit to do so, and for whatever reason.

This is true, in particular the verifier might well find it more efficient to pull a policy record before checking the signature.

But an authenticated signature always dominates policy according to the specification.

> > E) The message has a signature by a Third-Party domain.

If all you are doing is spam control a signature from an accountable third party is sufficient and you would not need to check policy. If bank of america sends a message to the list where it gets munged and resigned that is going to be acceptable at some level.

If we want the ability to insist on being able to distinguish this case we will need to do a lot more. I would much prefer to wait till a recharter. In particular I think it will be much easier to do that type of policy after the email infrastructure has made accomodation to DKIM.

> G) The signature covered an "unusual" selection  of headers;

That would be another example of not sufficient.

> H) There were several signatures, of which some passed and 

Failed signatures are ignored.

> Moreover, experience will throw up new scams that the Bad 
> Guys will invent, and so it may become necessary to add new 
> kinds of information to Policy records that we have not even 
> thought of yet. So, to that extent, their notation needs to 
> be extensible.

Some of which will be something DKIM needs to deal with, some will not.

Phill

---

From: Douglas Otis <[email-masked]>
Date: Thu, 12 Jul 2007 12:22:27 -0700

On Jul 12, 2007, at 7:34 AM, Hallam-Baker, Phillip wrote:

> If all you are doing is spam control a signature from an  
> accountable third party is sufficient and you would not need to  
> check policy. If bank of america sends a message to the list where  
> it gets munged and resigned that is going to be acceptable at some  
> level.

Not exactly.  A Third-Party signature coincident with the SMTP client  
excludes replay abuse, which is likely problematic with respect to spam.

> If we want the ability to insist on being able to distinguish this  
> case we will need to do a lot more. I would much prefer to wait  
> till a recharter. In particular I think it will be much easier to  
> do that type of policy after the email infrastructure has made  
> accomodation to DKIM.

Third-Party authorization should not be delayed, nor is there a  
reason to wait.

There are three fairly important issues dramatically affected by the  
methods DKIM allows to authorize Third-Party domains.

1) Replay Abuse

2) Key Security

3) DSN handling

This is detailed in an extension to SSP, which slightly modifies the  
current SSP proposal:

http://www.ietf.org/internet-drafts/draft-otis-dkim-tpa-ssp-01.txt

Third-Party authorizations by-name safely scales.  This authorization  
strategy permits a signing domain to readily coincide with that of  
the SMTP client.  When the authorized signing domain is coincident  
with an SMTP client within the same domain, replay abuse is precluded  
as a risk.  The ensures adequate resources are available to handle  
exceptions where there would be risk of replay abuse.

By using an authorization by-name scheme, rather than exchanging keys  
for this purpose, the impact of a compromised key is limited to just  
that domain.  Reports of a compromise would not list every selector/ 
domain of where a public half of this service provider's keys had  
been published.  Without an authorization by-name SSP record, every  
customer of the service provider wishing to authorize the service  
might need to be included within such a report.  This type of report  
would be devastating news for DKIM.  DKIM keys will be distributed to  
several servers connecting to the Internet, and are fairly vulnerable  
as a result.

The use of transparent authorization techniques must be discouraged,  
as this will represent a significant problem when dealing with  
security breaches or even establishing best practices.

When a record is signed by a Third-Party domain, versus not being  
signed, this is a natural place to first query for a TPA-SSP record,  
rather than just an SSP record.  The use of a wildcard at this  
location eliminates any subsequent SSP record query.  This  
authorization by-name technique safely scales, unlike any IP address  
path registration scheme.  This authorization by-name helps curtail  
possible replay abuse as well.  Authorization by-name also greatly  
simplifies the process an email-address domain administrator  
confronts when they desire to authorize a service provider.  This  
also greatly limits the email-address domains exposure to possible  
security breaches as well.

As a bonus, by including a signed header contained the MAILFROM  
address,  authorization by-name can also ensure that DSNs of  
differing domains are safe to submit.

-Doug