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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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?

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.

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.

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?

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.

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.

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




_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]