ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] DKIM charter

2005-11-13 18:39:13

----- Original Message -----
From: "Barry Leiba" <leiba(_at_)watson(_dot_)ibm(_dot_)com>
To: "IETF DKIM WG" <ietf-dkim(_at_)mipassoc(_dot_)org>
Sent: Sunday, November 13, 2005 7:57 PM
Subject: Re: [ietf-dkim] DKIM charter


In my view, DKIM is establishing an "implied" trust relationship between
domains by the very nature of making any attempt to support or adopt the
protocol.  It is going to be difficult to keep the concept of "protocol
trust" out of any discussions of SSP.

Hm, interesting approach.  The way I look at it, DKIM is providing
information
that could be used to define a trust relationship, but is not defining any
trust relationship itself.  The recipient decides whether to validate the
signature, and what to do with the results of the validation.  I believe
this
is true with or without SSP, which is why I don't think that SSP is
transferring
responsibility to the recipient: DKIM is giving information, the recipient
domain
is using that information however it chooses, and the DKIM spec does not
tell it
what to do with that.

I see your point. But inevitably, we still need a reason why to even bother
with DKIM overhead. Why do I add it to my package? How will I promote it?
Why should the customer even bother?  What else do I need to make it work?,
etc.

I see the problem today with too much relaxed information that we basically
punt on it, ignore it.  HELO/EHLO is too far gone to really have any trust
in doing any verificaton.  MAIL FROM has some redeeming value simply because
it is still part of the SMTP requirements for system notifications.  But
most contemporary systems don't take action until it is required
(accept-bounce).  If we add value to the payload, we need a good enough
reason (and trust) that whatever we do with has some payback or value.  The
last thing we want down the road is a common attitude that the DKIM
information is "worthless" and reading it could be more problematic than it
is worth.  So I believe that if this happen, we will have a new threat in
DKIM social engineering issues based on this prevaling attitude.  Sender-ID
is practically out of the gate and it is already considered "worthless" by
many.

I'd have to say that updating RFC 2821 is out of scope, and anyone who
participated in DRUMS will understand why.  We want to finish the DKIM
work in
2006, not in 2016.

I play congas, but know nothing about drums. <g> I saw others refer to it
and it seems to be a very old WG archive.  I'm not the type to advocate the
extreme. I know better. But with my system engineering hat on, to support
DKIM requires some level of system wide considerations. I can probably
ignore the issues here but not during implementation.

I'd certainly think it'd be fine to have a non-normative section (or a
section
in a non-normative document, such as the overview) that recommends changes
to
the existing standards or infrastructure.

I also think it's not necessary to list everything that's not in scope, so
I
don't think we need to declare "updating RFC 2821" to be out of scope,
explicitly.

Ok. Good enough.

Thanks for the feedback.

--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com






_______________________________________________
ietf-dkim mailing list
http://dkim.org