ietf-dkim
[Top] [All Lists]

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

2009-06-16 16:43:49
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.  

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.

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.

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 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'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. :-)

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.

--

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

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