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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf