|
[ietf-dkim] Re: Forgery complexities
2005-08-29 15:32:12
On Aug 29, 2005, at 1:18 PM, Dave Crocker wrote:
Lead-in problem statement:
,---
| Forgery of headers that indicate message origin is a problem
for users of
| Internet mail.
'---
DKIM is an authentication technique. It authenticate an identity.
While that is a true statement, this new identity is independent of
headers normally considered to be related to forgery. Falsifying the
originator (author) of the message has nothing to do with the
validity of a DKIM signature.
Authentication is not needed, unless one is worried about invalid
uses of identities. I think that it is reasonable to call that
"forgery".
Adding an unseen identity within a message, and being able to verify
this unseen identity, does not directly deal with the current forgery
problem. Forgery deals with identities people associate with having
originated the message. Not using overloaded terms like forgery
would provide a less misleading and confusing description of the
specific goals.
DKIM allows the inclusion of a signature. The validity of the
signature makes no statement beyond having accepted and subsequently
transmitted the message. DKIM may offer no assurances related to any
message content beyond the signature.
I would also hope there could be clearly defined goals that describes
what DKIM provides. This should be kept separate from goals related
to what is considered to be a product of the SSP mechanism.
So the opening statement is factually correct. And it is describes
a concern that is the foundation for pursuing DKIM.
I see the forgery problem as a foundation for pursuing S/MIME or
OpenPGP.
The goal of DKIM.
,---
| The DKIM working group will produce standards-track
specifications that
| permit authentication of message headers during transit, using
public-key
| signatures and based on domain name identifiers.
'---
While one could describe signature verification as authenticating
the signature header, this is not addressing the problem statement.
Ensuring that the received headers are the headers that were sent
does not address the problem of forgery?
The signature simply indicates this was the message sent. It makes
no claims regarding any other content. Perhaps some signers confirm
content in some manner, but this does not provide the recipient any
means for concluding headers indicating the originator are valid.
DKIM does not directly address the forgery problem.
The fact that DKIM provides a digital signature based on a hash of
the message headers means that, in fact, it is ensuring that any
modification to the headers, after the message is sent, will be
detected. Hence, they are authenticated... With respect to the
identity doing the signing.
A used car salesman explaining their warranty may define the drive-
train warranty as only applying to the wheel-lugs, that are part of
the drive-train. While indeed the signature may encompass headers
and body content, this makes no assurance any content is valid, or
that any content is being assured by the signing domain. While
indeed without the signature the wheels fall off, but this does not
mean the signature has authenticated the validity of the signed
content. The signature simply indicates _this_ message was signed by
_this_ domain.
The headers which could possibly relate to forgery are _not_
being authenticated. I find these two statements misleading and
not representative of the DKIM mechanism as currently devised.
I think you are confusing the benefit of closing SOME holes with
the desire/need to close ALL holes. The fact that some forms of
forgery are dealt with by DKIM does not mean it attempts to deal
with all forms.
The term forgery is confusing what protections are being provided.
If the goal is to prevent forgery, then S/MIME or OpenPGP are
appropriate solutions, where DKIM is not. DKIM does not directly
address the problem of forgery as it is generally understood. Don't
call wheel-lugs the drive-train and expect anyone to understand what
is being protected.
General goals:
...
- Establish accountable domain-specific opaque identifier.
what does domain-specific "opaque" identifier mean? Opaque to who?
Compared to what?
The only practical solution I see for addressing replay-abuse issues
and to support effective techniques that detect forgery would be for
the signing domain to add their own opaque identifier with the
signature that is either sequential or related to the access
account. Unlike a mailbox-address, this opaque identifier could be
assumed unique for the the signing domain. The term opaque means
that the interpretation of this identifier is only understood by the
signing domain.
The opaque identifier should provide the requisite anonymity (as
opposed to the i=). An opaque identifier would still permit a high
granularity well beyond a mailbox-domain. It should be obvious
mailbox-domain authorization is limited to the granularity of the
mailbox-domain. If this domain is dereferenced, or open to third-
party signatures, then multiple domain granularity includes a much
larger to infinite set of potential miscreants. With the zombie
problem being rather prevalent, mailbox-domain(s) granularity is
problematic. Third-party restrictions are also problematic, as this
will impact normal behaviors. Opaque identifiers offer a practical
solution.
-Doug
_______________________________________________
ietf-dkim mailing list
http://dkim.org
|
|