Rolf E. Sonneveld wrote:
> On 5/4/11 1:25 AM, Murray S. Kucherawy wrote:
>> The assertion you're making is that the consumer of an API shouldn't
>> need to maintain any context; the API will give you back all the bits
>> of context you need to continue as well as the answer you need.
>>
>> ..
>>
>> So it is with DKIM: If you get back an indication from a verifier
>> function that a signature verified, then the signature covered the
>> lowest From: field that you presented to it. You know that because
>> that's how the interface you're using was defined.
>
> For a scenario where a caller is calling a DKIM milter which in turn
> calls an API, this is all true. But DKIM will be/is deployed in many
> more scenario's. Consider scenario's like:
>
> * there can be one or more hops between verifier and consumer
> * between verifier and consumer MTA's can re-order From headers,
> * or remove From headers if there is more than one of them present.
> * What if Postini and MessageLabs are going to use DKIM for inbound
> traffic for their customers and want to communicate the DKIM
> verification results to the consumers within the mail infra of
> their customers?
>
>> An implementation certainly could give you back that From: field's
>> contents (and OpenDKIM does, if you ask for it), but still I don't see
>> any reason to make it mandatory.
>>
>> I might even go so far as to say returning that From: field is
>> dangerous since it is not confirmed by anything, so DKIM (which is an
>> authentication protocol) returning data that can't be validated, even
>> if it was signed, is quite possibly asking for trouble.
>
> But then DKIM is only authenticating the d= and we should no longer
> position DKIM as being 'effective in defending against the fraudulent
> use of origin addresses'.
+1 well said.
Let me show examples of the DKIM mail integration dilemmas. My apology
for the length of this, but I am trying to extract all the key design
issues we are facing or will be facing with DKIM:
A fundamental flaw is to believe all backends have a RFC5322 Mail
Store. The protocol has to provide for discovery for the software
engineering interface points to engineer the integration and
transformations needs.
RFC4871bis is saying there is an mandatory interfacing point for a
trust transformation and believing that leaving the door open with
stating the possibility of other outputs is universally obvious.
For a DKIM software engineering minimal, DKIM-BASE needs to expose the
interface points such the ODID (or From) and the AUID which is
explicitly stated as a MAY therefore it should also be part of the
Outputs. Reasonable engineers to exptract from RFC5585, RFC4686 the
interface points for the "black box" transformed outputs.
There are only four minimal elements that can be extracted based on
all the different considerations since RFC4871 with all the related
consensus built documents:
verification status
SDID signer domain
AUID agent/user identity
ODID author domain
Everyone will need those parameters to satisfy the DKIM Service
Architecture which includes security, policy and trust considerations.
When one actually begins to employ DKIM in a total mail systems that
includes:
- internet hosting with SMTP, POP3, NNTP, MLM, IMAP, etc,
- how mail is stored and/or transformed, and
- online/offline MUA considerations
it become more clear of what inputs/utputs are needed for DKIM
purposes and also the complexity of where the "trust" increases and
decreases.
Example:
Remote UserA sends dkim signed mail to Local UserB and Local UserC at
the same local mail host.
UserB likes to use the Online Mail Access (Web site, but it can be any
other online connection device). UserC was an online person, but he
slowly migrated over the years to an offline RFC-based Mail
Reader/Writer (Outlook, Eudora, Thunderbird and many others).
UserB - online user.
It should be fairly obvious that the centralized backend has rendering
control for UserB and has all the power to provide the security,
policy and overall trust outcomes the UserB. During the import
process from remote userA, depending on the backend storage method,
the information was generated necessary for the backend to display the
information to the UserB. To assume the backend will do the
verification dynamically with each message reader, while possible,
probably not very efficient. So the odds are good the verification
was be done once and all the outputs will need to be stored. Whether
one is using a raw RFC54322 storage method or it is protocol assumed
that is expected is not the point because in cases, the output must be
common. What is important to consider is that it is backend that is
telling UserB and all online access users is that what they see
"should be" trusted (at least in the header display)
UserC - Online User.
Let uses POP3. Backends don't have control of what is display or how
it will be displayed at the header level. We have historical BCP
across all mail systems and in all mail networks, that at the very
least it will have, in no particular order:
Date:
From:
To:
Subject:
Since there is a time-shifted mail application, you might also see a
received or reception date because its not generally the same as the
originating date.
What it is important though that it is RFC5322 based and whatever DKIM
related information the backend wishes to provide to the UserC will
be included in the headers. This is important as I described in the
second part of this UserC offline mail consideration.
What is also important is an "inherent" trust factor for the UserC
using the backend mail host. Its not an blind consideration for the
user to pick or use a particular mail host. So even if it was not
possible for the backend to display that security, policy, trust
information that was certifiably verified once already at the backend
to the user, UserC does have some, possibly faulty, level of trust
already.
So the question of whether the offline MUA duplicating this
recalculation become more relevant - for UserC sake.
What I think about what can be displayed to the DKIM-aware or perhaps
just a simpler DKIM-Report-Aware MUA so that he doesn't have to redo
the calculation DKIM overhead in a trusted manner.
Can an Authentication-Results header from the same Backend Mail Host
only (1 degree of separation) be used for the DKIM-Report-Aware MUA?
Remember, the offline MUA may independently decide not take user
considerations into account for a trusted backend and just do what it
thinks is best or a more advanced DKIM ready MUA may provide the DKIM
related user options along with the other common MUA mail pick up
options already existing for an account setup:
[_] Enable DKIM support
(o) Use A-R DKIM results from the same mail host
(_) Calculate the DKIM verification.
So things are possible.
There is also other methods a backend can do and this is based on 25+
years of offline product design experience. Overall the product goal was:
Providing the same (or equal) reading experiences and
security requirements necessary for online access in
a time-shifted offline manner.
For those who were in this market, it is fairly obvious. But this
highlights two things:
- Backend transformation (i.e. POP3 transformation to RFC5322)
- New ideas to support legacy MUA using forced display header changes
You have to accept the idea for the long history of many backends with
real motivations to transform RFC5322 into proprietary backend store
formats (i.e. one may be to limit/lower PCI related security concerns
regarding HTML/Javascript exploits, another are mail streams where
multi-media is not important, there are many reasons including
reducing storage space requirements). But for the user who has
migrated to offline access, the idea of giving them original content
perfection became more relevant and a tougher local policy decision.
But still have growing needs to address the market of legacy or better
the BCP MUA design where essentially there is no standard protocol to
control what headers are displayed. There are two ways to approach this:
1) Wait for the Offline MUA to die off
We have a new recycling towards centralization, and we can just wait
out the departing generation of Offline MUA users and focus designs
towards Online MUA access. You can see this in high-value email
notifications with secured content design that is based on the idea is
reading it online. You can also see this with the recent Microsoft
move to remove and no longer supporting the 20+ years of
microsoft.public.* newsgroups and shifting it to online mail forums.
2) Proxies
You can design proxies or design backend forced changes in the header
display to reveal more information. For microsoft, their migration
solution included a backend API Proxy for NNTP client/servers to
assist the market of RFC-based News Readers. Since their proxy was
limited, had Input/Output transformation bugs, others wrote better
proxies. I wrote one as well called "Wildca! Live Exchange"
(http://opensite.winserver.com/wclex).
The goal again was to give the Microsoft Online Reading experience
which now included all the new outputs to display, in an offline
manner. Using a few of the output examples, online you see stuff like.
From: Whoever
Status: MVP
Stars: 1 to 5
Member Since:
Number of Posts:
Those are all "Trust" ideas in the area of what users can believe or
accept or not in solutions value.
So with WcLEX, some of the outputs where used in setting the
RFC5322.From, so the news reader using the wcLEX proxy:
From: Whoever [MVP, Stars: 4, Post: 243] <whoever@msforums>
and wcLEX also haves options to write this and more backend details in
the content using mixed html/text MIME parts.
In summary, if RFC4871bis focuses on just exposing what is a single
mandatory output and not what is DKIM Output Complete, certainly life
doesn't end, but it does certainly makes it harder to extract and
derive necessary mail integration solutions.
DKIM-BASE certainly makes it clear what is mandatory and if we just
focus on that and totally forget about ADSP and other things related
to it, then its easy to see what is only needed to convert to UserB
and UserC.
Signing by:
Trusted Signing by:
and the problem is that the default design is to lock that in.
DKIM-BASE should allow for all the minimal extracts that can be obtained:
Signing by:
Trusted signing by:
Authorized signing by:
Authorized and Trusted signing by:
I am not saying that just because I am strong advocate for policy, but
it is all part of the total mail integration picture based on what
what encompasses the current DKIM mindset and considerations.
Future implementators will be at an disadvantage and fortunately, we
were able to get the new section 1.1 which the additional "clues" for
engineers to find out all that is needed. But it would be so much
simpler if the new Output Requirements section was a better summary of
the DKIM Output Complete values to consider.
I know one thing, DKIM is a complex beast and the last thing we need
is more protocol relaxation and incomplete exposure of information in
indirect and ambiguous ways we know offer utility.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
