Subject: secdir review of draft-ietf-dkim-ssp-requirements-04

From: "David Harrington" <[email-masked]>
Date: Mon, 16 Jul 2007 17:27:41 -0400

Hi,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

Security review:
draft-ietf-dkim-ssp-requirements-04 discusses requirements for the
DKIM signing practices protocol. I felt the discussion of security
issues for DKIM signing was very light. The Security Considerations
section was also too light.  

My advice to the security area directors is that, before publication,
this draft should document stronger security requirements for the DKIM
signing protocol. This document should include an enumeration of the
potential threats, as described in BCP 72 (RFC3552), followed by a
discussion of the requirements that must be met by DKIM signing to
mitigate those threats.

-
a few specific comments related to security issues:
1) section 5.1 discusses discovery requirements. bullet#1 says the
author is the first party sender of a message. After reading this, I
had the question "author of what?" The preceding text only says there
must be a means of obtaining information. It doesn't discuss any
particular approach to getting the information, so I am not sure what
is being authored.

2) section 5.1, bullet #4 says the WG might not be able to reach a
consensus on a solution that completes within a deterministic number
of steps, and if they do not reach consensus, then they MUST document
the relevant security considerations. Even if they DO reach consensus,
they will need to document the security considerations. I'm not sure
how they will document the security considerations of not reaching
consensus. I think there are range of topics mixed into bullet#4, and
they need to be broken out before security for these things can be
considered.

3) section 5.3 bullet #2 calls for a concise linkage between the
identity in the From field and the DKIM i= tag. Isn't the concise
linkage that you need here some type of identity authentication? If
not, how do you know the mapping is actually valid?

4) security requirement#1 - What must SSP do to prevent such DoS
attacks? what must SSP do to prevent being vulnerable to such DoS
attacks? Note that these are two separate questions with potentially
different mitigation strategies.

5) security requirement#2 - what must SSP do to prevent such attacks?
Keeping exchanges small might help, but how about establishing a
secure channel, and using data origin authentication, and message
integrity checking, and replay prevention, to prevent such man in the
middle attacks?

6) there is mention of DNS providing cacheing. I have some concerns
that this may not be appropriate for DNS applicability, and there
could be security concerns introduced if DNS is used to provide
cacheing for this protocol.

-
Other comments:
1) I found the 1st paragraph of section 4 unparseable. I recommend
using multiple sentences here, rather than one long run-on sentence.

2) s/(ie,/(i.e.,/g

3) This document should have **requirements**, and the informative
notes feel wishy-washy. Many requirements are not definitive
requirements, so it will be hard to tell whether the protocol actually
meets the requirements. Some of the informative notes gave a much
better description of what is expected, and I think the
non-informative-note-text would benefit from being described more
fully, and eliminating the informative notes.

4) I think some MUST/SHOULD language is not being used as per RFC2119,
and should be tightened. There is also use of lowercase "must" and
"should"; is this meant to also be consistent with RFC2119 usage? If
not, the "requirements language" section should explain this.

5) section 5.2 bullet#3 says "If the infrastructure doesn't provide
caching (ala DNS), the records retrieved MUST provide initiators the
ability maintain their own cache." I don't understand how retrieved
records can provide this ability to initiators. Either the protocol
needs to provide a caching mechanism (possibly ala DNS), or
implementations do.

6) There are a number of sentences in this document that do not follow
the rules of English grammar. For example, in the 1st paragraph of
section 5.3, there is no subject-verb formualtion, only a couple of
cluases strung together. The grammar makes it hard to read this
document without being forced to go over sentences multiple times to
understand the intent.

7) "intuitive" is in the mind of the beholder. I think it is debatable
whether p=? is less intuitive than p=unknown. What is needed is a
clear and unambiguous syntax about what p=? or p=unknown means.

8) section 5.4 bullet#1 sounds like something to write in the charter,
not the protocol requiremnets document.

9) section 5.4 bullet#2 - are there already existing
discovery/transport/practices to be backwards compatible with? Or is
this saying the future extensions to the future protocol must be
backwards compatible with the future protocol? 

David Harrington
[email-masked]
[email-masked]

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Douglas Otis <[email-masked]>
Date: Mon, 16 Jul 2007 19:55:05 -0700

On Jul 16, 2007, at 2:27 PM, David Harrington wrote:

Don't overlook 5.1 #1:
---
The author is the first-party sender of a message, as specified in  
the [rfc2822].From field.
---

Per RFC2822:
---
3.6.2. Originator fields
... The "From:" field specifies the author(s) of the message, that  
is, the mailbox(es) of the person(s) or system(s) responsible for the  
writing of the message.  The "Sender:" field specifies the mailbox of  
the agent responsible for the actual transmission of the message.
---

The From: field does not actually refer to who sent the message.   
Here 'sender' is being used in poorly defined fashion.  This field  
refers to originators of the message, and specifically _not_ the  
sender.  Even the Sender: field does not directly indicate who  
administers the SMTP client physically transmitting the message.   
Here the term Author's domain is considered to include any parent  
domain extending all the way up to TLDs.

Don't overlook 5.1 #3 resource record location prohibition.

It is very common for different protocol's RRs to reside at a common  
location.  These records are resolved by different RR types.  Why was  
this statement incorrectly worded?

> consensus on a solution that completes within a deterministic  
> number of steps, and if they do not reach consensus, then they MUST  
> document the relevant security considerations. Even if they DO  
> reach consensus, they will need to document the security  
> considerations. I'm not sure how they will document the security  
> considerations of not reaching consensus. I think there are range  
> of topics mixed into bullet#4, and they need to be broken out  
> before security for these things can be considered.

This requirement is for an uncertain concept that DNS can safely  
establish policy in a hierarchal fashion.  It is uncertain whether  
this can be accomplished within a reasonable number of transactions  
without also creating a potential for DDoS attack.  This uncertainty  
is further exacerbated by there not being any safe existing  
hierarchal email policy structures within DNS.  Absence of policy  
records is normal for existing email.

It would be possible to establish policy in conjunction with SMTP  
discovery RRs required to support the email-address domain in  
question.  This approach precludes a need to extend SSP coverage into  
subdomains, or a need to traverse domains searching for parent  
domain's SSP records.  A strategy that depends upon a policy  
hierarchy is sure create dangerously excessive traffic at second  
level domains, and result in possible DDoS exploits.

> not, how do you know the mapping is actually valid?

This is made worse by a lack of clarity with respect to 5.1 #1 and  
goes to the heart of a major security problem.  It is a normal  
practice to employ email service providers who transmit messages from  
domains independent of the email-address domain signed by a DKIM  
header.  Per-users keys will call into question the caching ability  
of DNS.  Domain centric keys will preclude an architecture where  
messages are normally signed prior to submission.

So how can an email-address authoritatively be signed to convey  
assurances to recipients?

This can be done by:

1) an authorization-by-name RR in DNS at SMTP discovery RRs
   (A concept currently excluded from consideration.)

2) an ad-hoc exchange of keys between domains

3) delegation of key domain to email providers

Both methods 2 & 3 lead to a rather serious difficulty when  
attempting to resolve the messages at risk of having been spoofed  
when a provider's server has been compromised.  Instead of reporting  
the domain of the provider as being compromised, method 2 & 3  
requires a comprehensive list of perhaps thousands of a provider's  
customer's domains will need to be reported instead.  Private keys  
will be distributed to servers directly connected to the Internet,  
where of course there is a high risk keys may become compromised.

> attacks? Note that these are two separate questions with  
> potentially different mitigation strategies.

Not attempting to establish a hierarchal policy within a domain  
should be the first step to assure against DDoS risks.  Instead limit  
policy to SMTP discovery RRs locations instead.  Unfortunately, the  
SSP requirements draft anticipates use of hierarchal policy instead,  
hence what may appear to be double-speak.

> 5) security requirement#2 - what must SSP do to prevent such  
> attacks? Keeping exchanges small might help, but how about  
> establishing a secure channel, and using data origin  
> authentication, and message integrity checking, and replay  
> prevention, to prevent such man in the middle attacks?

A justification for DKIM is that it offers a lightweight method to  
improve the filtering of phishing attacks.  This filtering process is  
_not_ based upon what email-address is within the From: field.  Anti- 
phishing efforts must deal with what the recipient will actually  
_see_.  The email-address is of far lesser concern than that of the  
friendly name and message content.  DKIM and SSP does not even deal  
with either of these elements either.

Why the lack of consideration for authorization-by-name records in  
DNS at SMTP discovery RRs?  This could be based upon an espoused  
ideal of ensuring anonymous access to email.  This goal has  
subsequently used as justification for SMTP clients to avoid  
accountability.  Those actually transmitting spam would rather not  
take responsibility.  Often this accountability is for the  
individuals that utilize the SMTP client.  Here, accountability is  
not seen as being hierarchal, unlike policy records placed within a  
domain.

This view of SMTP client accountability must change for email to  
survive the complex environment ushered in by use of IPv6.  Greater  
dependence upon the domain name also demands an end of "domain  
tasting."   The high churn of domain names thwarts an otherwise  
permissive policy of presuming a domain is responsible.  When  
accountability of SMTP clients is deflected in a sloppy manner to  
often hapless email-address domain owners, individual freedoms and  
equity suffer.

-Doug