Re: draft-ietf-dkim-ssp-06 in last call?

Douglas Otis <dotis@xxxxxxxxxxxxxx> · Wed, 8 Oct 2008 19:11:09 -0700

On Oct 8, 2008, at 2:28 PM, Stephen Farrell wrote:

Doug,

Firstly, this draft is not yet in IETF LC, so you've jumped the gun  
a bit.

In any case, I believe you had, and took, a number of opportunities  
to present your concerns at f2f meetings, on the list and in I-Ds  
like the one cited below. However, you did not garner support for  
your suggested changes. (Frankly, you didn't succeed in fully  
explaining your concerns, at least I still don't quite get what  
worries you.)

A praiseworthy goal of SSP, when widely adopted, would be as a  
mechanism to help limit the use of a domain in the From header field  
for email by requiring a signature by that domain.  Unfortunately SSP  
extends this goal to an area beyond their charter.  Who should cry foul?

For a signature to be compliant with even the lesser of the two ADSP  
restrictive assertions, the signature's "on-behalf-of"  or its default  
must match against the From header field, the message's author.  Why  
is that?

This contrived requirement prevents a proper use of the "on-behalf-of"  
field as a means to indicate what had been authenticated.  This  
authentication information is needed to better deal with replay abuse  
without collaterally blocking the entire domain.  The overhead of  
verifying two DKIM signatures will then be needed to accommodate an  
"on-behalf-of" not matching against the From header field.   Also as a  
result, the signature associated with the From header field is likely  
to be a blank "on-behalf-of".  Two signatures where one informative  
signature could have been employed is not being practical.  Requiring  
a domain's message to include a signatures that is "on-behalf-of" of  
the From header field is a bad practice.  This practice is wasteful.   
This practice is bad for the environment.  There is nothing gained by  
a blank "on-behalf-of" value, except as a requirement to implement  
this very bad practice.  As a rhetorical question, why would large  
domains not wish to give recipients any option other than all-or- 
nothing?  Clearly the "on-behalf-of" the From header field compliance  
requirement gives larger domains a distinct and unfair advantage in  
this respect.

Some large providers manage to control outbound traffic to where only  
5% of their traffic is likely the result of Bot-Net or bad-actor  
related abuse.  When considered within the context of a signature  
lacking meaningful replay abuse prevention, a blank "on-behalf-of"   
offers nothing to improve the situation.  There is also a real danger  
where message annotations that are based upon the existence of ADSP  
record and a DKIM signature might be seen by recipients as an  
assurance the From header field has been validated.  With the DKIM WG  
being within the Security Area, this should have been a concern, since  
ADSP compliance provides no other option than to have the DKIM  
signature be "on-behalf-of" the From header field.

But hopefully we'll get the benefit of IETF wide review in the near  
future so maybe someone else will be able to see what the DKIM list  
didn't.

My hope as well.  I hope to see DKIM to offer a practical means for  
ushering in IPv6 email.  IPv6 is soon too massive and soon too tangled  
to be properly handled by black-hole lists.

Lastly, by "voting process," I guess you must mean the question I  
asked after the end of WGLC, (thread at [1]). That wasn't a voting  
process, it was me checking that relatively few WGLC comments didn't  
reflect a lack of consensus, that the changes to handle the few WGLC  
comments that were posted had been processed ok, and that there was  
in fact no one at all on the list to speak up and agree with your  
concerns. So, I checked, and we got a bunch of "+1" messages to the  
effect that the draft was ready to send to the IESG and, so far,  
zero messages agreeing with your position.

IMHO, the damaging decisions were not the result of mailing list  
discussions.  When attempting to discern what lead to the decisions,  
little can be discerned from a long series of empty votes.  The  
reference to voting was not about whether to go to last call.  Of  
course, this too was rather typical.  How is it that a statement of a  
factual error in the draft not find thoughtful discussion on the  
mailing list,  other than a vote on some suggested fixes?  The lack of  
reasoning goes to heart of the concern.  When asked for how or why a  
critical decision was made, an ensuing discussion offer an assurance  
that the reasoning was principled.  "You can always add two  
signatures" sounds too much like "Let them eat cake" from my  
perspective.

-Doug

Stephen.

[1] http://mipassoc.org/pipermail/ietf-dkim/2008q3/010706.html

Douglas Otis wrote:
Here is a draft that outlines a few concerns for draft-ietf-dkim- 
ssp-06:

http://www.ietf.org/internet-drafts/draft-otis-dkim-adsp-sec-issues-03.txt

These concerns were not fully discussed on the DKIM list expect for
voting for an "as is".  Unfortunately a voting process offers little
clarity.

There appears to be a factual error in the draft.  Any restrictive  
ADSP
assertion such as "ALL" or "DISCARDABLE" creates an additional
requirement for what valid DKIM signature remains valid with  
respect to
compliance with ADSP assertions.

See:  draft-ietf-dkim-ssp-06 Section 2.7.  Author Signature

This section defines an Author Signature as a valid signature where  
the
"on-behalf-of" (DKIM signature i=value or its default) matches  
against
the From header field.

Section 3.2 ADSP Usage however says:
.----
|If a message has a Valid Signature from an Author Domain, ADSP
| provides no benefit relative to that domain since the message is
| already known to be compliant with any possible ADSP for that
| domain.
'----

Clearly, these two sections are in conflict.  In addition, the Author
Signature definition is in serious conflict with the working group's
charter.

Since the DKIM key itself can assert a restriction upon the
"on-behalf-of" local-part, there might be some justification to
generally require signatures using local-part restricted keys to also
match against the From header field before being considered valid.   
It
would be dangerous to only impose this requirement based upon the
existence of an ADSP record.  SSP attempts to use DNS "SERVFAIL" to
detect an attempt to block the ADSP records, but this status may  
not be
apparent behind a resolver.  A conditional requirement is ill  
considered
from a security standpoint, and may even invite abuse.

Once the issue of restricted local-part keys is properly handled in  
an
independent fashion, then attempts to require the "on-behalf-of"  
match
against the From header field conflates DKIM and an ADSP record  
into a
poor replacement for either S/MIME or OpenPGP.  After all, the DKIM
signature and it's "on-behalf-of" fields are normally invisible to  
the
recipient, and DKIM in conjunction with an ADSP still does not assure
control over the Display Name being seen.  An MUA can always  
annotate a
message to indicate specifically what portions of the message match
against the DKIM signature's "on-behalf-of" and domain.   The SSP  
draft
is conflating a valid DKIM signature and ADSP record into becoming an
assertion of the identity of the message's Author.  Such conflation
clearly and dangerously exceeds the DKIM charter.

The underlying goal of ADSP was to afford a domain control over the  
use
of their domain within a From header field.  This goal can be fully  
met
without stipulating that the DKIM signature be "on-behalf-of" the
identity within the From header field.  The "on-behalf-of" should  
relate
to what the domain authenticated, even when the "on-behalf-of" is
opaque.   It is common for what is being authenticated by a  
provider to
not be the email-address within the From header field.  Had SSP
permitted an "ALL" assertion and a practice of the "on-behalf-of" to
opaquely or otherwise reflect what the signing domain authenticated,
then DKIM and ADSP would be effective at detecting Bot-Net related
abuse, the current email/Internet plague.  Perhaps some stats will  
soon
be published regarding this concern.  A link will be published when  
ready.

It even seems SSP might be attempting to sabotage DKIM's anti-abuse
utility.  There is no ADSP assertion that a domain is not used to  
send
or sign email, and ADSP "DISCARDABLE" at every node is how a domain
might wish to protect their hierarchy.  Requiring the ADSP record to
also be below the "_domainkey" makes it impossible to also know  
whether
the domain does not publish DKIM public keys as well.  Rather than a
term like DISMISSABLE, DISCARDABLE also implies that DSN can be lost.
SSP fails to even indicate that its assertions pertain to SMTP.  This
lack of protocol specificity might therefore disrupt any message  
where
the From header field domain is not published in DNS as a result of
implied DNS existence.

-Doug

_______________________________________________

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