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

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

 




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

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