ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] list expanders (was Re: chained signatures, was l= summary)

2009-06-16 17:12:17
Comments inline.

-----Original Message-----
From: HLS [mailto:sant9442(_at_)gmail(_dot_)com] On Behalf Of hector
Sent: Tuesday, June 16, 2009 4:28 PM
To: MH Michael Hammer (5304)
Cc: DKIM
Subject: Re: [ietf-dkim] list expanders (was Re: chained signatures,
was
l= summary)

Hi Michael,

MH Michael Hammer (5304) wrote:

 > So you are absolutely against 3rd party signatures unless the
 > 3rd party broke a first party signature?

I have an long ethical engineering problem with designing and dealing
with any mail mover software that alters and/or the original intent of
a
message.  The 1986 US EPCA provisions help model the guidelines for
hosting systems.  Keep in mind my view point is purely based on
security
and technical consistency and the expectations of the message
author/owner.  If the intent of the originating author and copy right
holder of the message was mail integrity and not necessarily message
owner authenticity, then I see less of a concern with a 3rd party
(relay
or hop) changing the intent and final status as long as its persistent
and consistent.  The chain of trust applies.


How does a 3rd party signing a message change the intent of the author
of a message? One might argue that breaking the original signature does
that. My response would be to then avoid breaking the original
signature.

One of the arguments put forward supporting the DKIM effort was that
unlike SPF it is not hop dependent. 

But if the intent of the originating author was both mail integrity
and
authenticity, then I see a really high potential for security and
technical problems when there is no  "Helper" involve to assist the
3rd
party and it just blindly alters the mail.


Blindly altering things is generally not a good idea in most
circumstances. I'mnot sure where a "helper" comes into play here.

Assuming the status quo and direction of DKIM-BASE sans policy,  I see
a
less security  problem when the original mail  was signed and valid
and
because of the inherent nature (BCP) of list servers today to alter
the
messaging layer (presentation),  it  keeps the integrity of the
altered
message intent intact  by resigning.   I see problems when the 3rd
party
signs non-signed original mail when policy is still in the mind of
this
project.  If policy was completely out of the picture, then DKIM
becomes:

     A system and core protocol allowing a MTA domain (domain) take
responsibility for the
     transportation of a message to the next  MTA (Hop) .

The model is less focus on the Original Domain expectations for the
authenticity of the transport.  The facebookemail.com post is a prime
example of the situation with blind list server or middle ware
signings.


Daves server signed the message. As I pointed out in my original post,
this implies some level of responsibility for the message. We still
don't know what that means let alone what we should infer in terms of
reputation (for those who want to go there).

My understanding has always been that anyone who handles a message
can
sign and thereby take responsibility (whatever that might mean) for
the
message they are signing.

Although this mindset has prevailed, it was not always like that Mike.
If it was the primary focus (i.e. policy was never a consideration and
out of the picture), then I believe we would long finished this
project
.   In the same vain, if people respected the charter out of scope
guideline for reputation, then possible Policy would of been resolved
and project over long again. :)


I figure that getting senders signing (or signers signing) and receivers
validating will allow the whole reputation issue to be resolved. The
water is great, jump right in.

I have to disagree Hector. For better or for worse, SSP was never
an integral part of DKIM. It is layered on top of DKIM.

It was what sold us to even get involve.  All original marketing and
presentations had SSP as a integral part of the framework.  It was
part
of the charter and and DKIM/SSP original specs was ONE document
(following Yahoo's Domainkeys specifications) before it was split.


I'll admit that SSP has been one of the selling points but as far as I
recollect it has always been represented as something being layered on
top of DKIM and not a core requirement for someone choosing to sign some
(or all) of their messages. Don't get me wrong, I am a strong believer
in the value of SSP/ADSP and believe that once some real implementations
get out in the wild where receivers are validating and respecting ALL or
discardable assertions, life will get interesting.

 > I'm surprised Hector. It really took you a second to decide it
wasn't
legitimate?

Is 1 second good or bad? I did hit 1/2 century mark this year so I am
bit slower. :-)


But wiser?

No honestly, I wondered there for a moment if this was a new WG
participant organizing a wiki/social network DKIM resource.  I just
came
back from a NYC trip visiting daughter and attending Yankees/Mets
game,
and all I heard this weekend was FACEBOOK this, FACEBOOK that. :-)
So I wondered if this was an spambot and if so, why wasn't it trapped
with the list subscription confirmation process.


My hunch is that it was probably an addressbook harvest type scenario.
Various of these social networks offer (insist?/annoy?) users allow them
to harvest email addresses from the users mail so as to allow others the
delight of interacting through the social network. I'm not picking on
Facebook in this respect as it is a fairly common practice.

Mike

_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>