Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

2011-05-10 Thread Barry Leiba
 We've had a bit of discussion in this thread (and elsewhere) about
 this, but I need to get a clear view of consensus.  Doug agrees with
 Hector's note, below, and Dave and Murray do not.  I'd like to hear
 from others within the next few days, about whether you think we
 should make the change Hector requests or not.  I need to get a sense
 of whether there's significant support for it.  Again, please keep
 arguments to a minimum, so it's clearer to me what the consensus is --
 we've had the arguments going for a while now.

I have the writeup almost ready for the IESG, and this issue has had
enough responses for me to get a clear sense:
We do not have consensus to make this change.  I'm closing issue #25
as wontfix.  Thanks, Hector, for laying the issue out clearly, and
to others for reviewing and commenting.

Barry, as chair

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


Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

2011-05-08 Thread Barry Leiba
Participant input:

 I proposes the following:

 3.x  Originating Domain Identity (ODID)

     The ODID is the domain part of the From: address.  This identity
     MAY be considered as an output communicated to an advanced
     Identity Assessor module.

I don't like making up a new name for what we already have.  I'd
rather just call it the domain part of the 'From' address.

There's also the issue, in defining this, that there may be multiple
From addresses with different domain parts.  In a case like this:

   From: Paul Simon p...@example.com,
 Art Garfunkel g...@example.net

...which domain do we use?

 3.9.  Output Requirements

     For each signature that verifies successfully or produces a TEMPFAIL
     result, the output of a DKIM verifier module MUST include the set of:

     o  The domain name, taken from the d= signature tag; and

     o  The result of the verification attempt for that signature.

 |  Optional output are:
 |
 |  o  The Agent or User Identity (AUID) taken from i=, if any.
 |
 |  o  The Originating Domain Identity (ODID). Verifier output
 |     MAY consider ODID when no signatures or invalid signatures
 |     are found.

     The output MAY include other signature properties or result meta-
     data, including PERMFAILed or otherwise ignored signatures, for use
     by modules that consume those results.

I find this Mostly Harmless[1], but unnecessary.  As others have said,
it's clear that identity assessors can use any information they like,
and the contents of the RFC5322 From are included in that.  I don't
object to pointing out items that we think might be particularly
useful, but I don't think we should be calling it output of the
signature verifier.  And, really, advice about the identity assessor
should mostly be in the deployment document, not in the protocol
document.

In other words, as a participant, I prefer not to add this, but I
wouldn't fight strongly against it.

Barry, as participant

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


Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

2011-05-08 Thread Hector Santos
Barry Leiba wrote:
 Participant input:
 
 I don't like making up a new name for what we already have.  I'd
 rather just call it the domain part of the 'From' address.

We already have an identity for it in section 2.3 - Author's 
Organization
and that is to mean a domain.We labeled all others with acronyms 
for easier modeling, why not ODID.

 
 There's also the issue, in defining this, that there may be multiple
 From addresses with different domain parts.  In a case like this:
 
From: Paul Simon p...@example.com,
  Art Garfunkel g...@example.net
 
 which domain do we use?

This was already discussed over the years and many felt the first one 
(see next paragraph, but ADSP leaves it open, see ADSP Section 2.3 and 
3.0.   This is no different than having multiple 3rd party 
DKIM-Signatures with different responsible SDID signers.

Keep in mind the rarity of it too. The originating author is already a 
vetted input process at legitimate hosting systems, i.e. No 
*legitimate* System in the world allows a free FROM input field for 
users to freely enter not only just one unknown address but multiples 
as well.  The only ones are those catering to such anonymity have 
already long been the part and the source of the problem.

-- 
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


Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

2011-05-08 Thread SM
At 11:52 06-05-2011, Barry Leiba wrote:
We've had a bit of discussion in this thread (and elsewhere) about
this, but I need to get a clear view of consensus.  Doug agrees with
Hector's note, below, and Dave and Murray do not.  I'd like to hear
from others within the next few days, about whether you think we
should make the change Hector requests or not.  I need to get a sense
of whether there's significant support for it.  Again, please keep

As I could not find any description of an interoperability issue in 
the arguments that have been made, I cannot support any change.

Regards,
-sm 

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


Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

2011-05-08 Thread Hector Santos
SM wrote:
 At 11:52 06-05-2011, Barry Leiba wrote:
 We've had a bit of discussion in this thread (and elsewhere) about
 this, but I need to get a clear view of consensus.  Doug agrees with
 Hector's note, below, and Dave and Murray do not.  I'd like to hear
from others within the next few days, about whether you think we
 should make the change Hector requests or not.  I need to get a sense
 of whether there's significant support for it.  Again, please keep
 
 As I could not find any description of an interoperability issue in 
 the arguments that have been made, I cannot support any change.

Section 1.1 says

Readers are advised to be familiar with the material in [RFC4686],
[RFC5585] and [RFC5863], which respectively provide the background
for the development of DKIM, an overview of the service, and
deployment and operations guidance and advice.

What do you think will happen when they read the DKIM Service 
Architecture, Security and Deployment Consensus Built Documents, all 
peppered with Signing Practices concepts?

Do you think they will wonder why 3.9 doesn't bother to mention 
anything regarding that large chunk in that pretty Software Engineer 
Process Model illustration?

Oh well.

-- 
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


Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

2011-05-08 Thread Dave CROCKER

On 5/8/2011 7:03 AM, Barry Leiba wrote:
 Participant input:

 I proposes the following:

 3.x  Originating Domain Identity (ODID)

  The ODID is the domain part of the From: address.  This identity
  MAY be considered as an output communicated to an advanced
  Identity Assessor module.

 I don't like making up a new name for what we already have.  I'd
 rather just call it the domain part of the 'From' address.

We might want to consider the benefits of consistency with existing 
documentation.

Email Arch (RFC 5598):

Section 2.1.1:  Author - responsible for creating the message

Section 2.2.1:  Originator - ensures that a message is valid for posting and
then submits it to a Relay

Section 4.1.4:  From:Author
Sender:  Originator

So what, exactly, are the semantics intended by this new term.



 I find this Mostly Harmless[1], but unnecessary.

Going to Draft is supposed to restrict changes to what is necessary, rather 
than 
what is whimiscally appealing to some folk.

There is already a problem with people's believing that DKIM protects or 
validates the From: field contents and that a DKIM signature implies 
assurances about that field, more than the actual data integrity from signing 
to 
verifying.

Adding a new term to refer to a portion of the From: field implies that there 
is 
an important need for the DKIM Signing specification to make that reference.

This feeds the confusion about the role of a DKIM signature.  That's not 
benignly unnecessary.  That's actively counter-productive.

d/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

2011-05-08 Thread Hector Santos
Dave CROCKER wrote:
 On 5/8/2011 7:03 AM, Barry Leiba wrote:
 I proposes the following:

 3.x  Originating Domain Identity (ODID)

  The ODID is the domain part of the From: address.  This identity
  MAY be considered as an output communicated to an advanced
  Identity Assessor module.

 I don't like making up a new name for what we already have.  I'd
 rather just call it the domain part of the 'From' address.
 
 We might want to consider the benefits of consistency with 
 existing documentation.
 
 Email Arch (RFC 5598):
 
 Section 2.1.1:  Author - responsible for creating the message
 
 Section 2.2.1:  Originator - ensures that a message is valid for 
 posting and then submits it to a Relay
 
 Section 4.1.4:  From:Author
 Sender:  Originator
 
 So what, exactly, are the semantics intended by this new term.

See RFC5585, RFC4686 and RFC5863. Which by the way has nothing to do 
with the author but the author domain (ODID).

We have long established the only single anchor we have in RFC5322 and 
one we must protect is the RFC5322.FROM and that is why is it the 
single only DKIM requirement for burning it into the signature.

Since the DKIM has nothing to say regarding missing signers, the 
security is lost and is thus an unsecured protocol design to now allow 
the ODID to be checked per RFC5016, RFC5617, RFC5585, RFC4686 and RFC5863.

 Adding a new term to refer to a portion of the From: field implies 
 that there is an important need for the DKIM Signing specification 
 to make that reference.

And it does in section 1.1 with the advisement for readers to be familiar:

1.1.  DKIM Architecture Documents

Readers are advised to be familiar with the material in [RFC4686],
[RFC5585] and [RFC5863], which respectively provide the background
for the development of DKIM, an overview of the service, and
deployment and operations guidance and advice.

 This feeds the confusion about the role of a DKIM signature.  

Too late. The existing confusion is to create (1) functional 
specifications and requirements and then ignore it in your (2) 
technical specifications, thus confusing (3) implementors, making (4) 
testing payoffs much harder to achieve  and (5) maintenance even worst 
to contain - your five phases of Software Engineering.

 That's not benignly unnecessary.  That's actively 
 counter-productive.

See above.

-- 
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


Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

2011-05-07 Thread Alessandro Vesely
On 06/May/11 21:09, John R. Levine wrote:
 this, but I need to get a clear view of consensus.  Doug agrees with
 Hector's note, below, and Dave and Murray do not.  I'd like to hear
 from others within the next few days, about whether you think we
 should make the change Hector requests or not.
 
 Dave and Murray are right, Hector is not.

+1, since we don't know precisely what output is actually used.
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

2011-05-07 Thread Hector Santos
Alessandro Vesely wrote:
 On 06/May/11 21:09, John R. Levine wrote:
 this, but I need to get a clear view of consensus.  Doug agrees with
 Hector's note, below, and Dave and Murray do not.  I'd like to hear
 from others within the next few days, about whether you think we
 should make the change Hector requests or not.
 Dave and Murray are right, Hector is not.
 
 +1, since we don't know precisely what output is actually used.

Therefore, since we don't know, we discourage usage, exploration.  On 
the other hand, we encourage a single output for a MUST Trust Assessor 
Identity where by far, the majority of the receivers don't have.  I 
will venture using pareto, over 80% and most likely more 95-99%.

Wonderful.

I suggest we do know how what output is being used or would be used if 
enabled  or is a technical requirement:

1) Empirical Fact!

We know SDID is showing a very low payoff and very useless utility 
with a majority of DKIM mail coming from unknown signers and spammers

2) Current Implementations API Fact!

We know ODID is used for ADSP lookups, optionally or not.

3) Technical Fact!

We don't know if AUID is part of anything outside of it being adding 
as another signing bit, but it is WRITTEN in the technical 
specification as a MAY for Output.

I believe I am more RIGHT here than David and Murray and you.

-- 
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


Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

2011-05-07 Thread Steve Atkins

On May 6, 2011, at 12:09 PM, John R. Levine wrote:

 this, but I need to get a clear view of consensus.  Doug agrees with
 Hector's note, below, and Dave and Murray do not.  I'd like to hear
 from others within the next few days, about whether you think we
 should make the change Hector requests or not.
 
 Dave and Murray are right, Hector is not.

+1.

Cheers,
  Steve

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


Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

2011-05-07 Thread Hector Santos
Barry Leiba wrote:
 We've had a bit of discussion in this thread (and elsewhere) about
 this, but I need to get a clear view of consensus.  Doug agrees with
 Hector's note, below, and Dave and Murray do not.  I'd like to hear
 from others within the next few days, about whether you think we
 should make the change Hector requests or not.  I need to get a sense
 of whether there's significant support for it.  Again, please keep
 arguments to a minimum, so it's clearer to me what the consensus is --
 we've had the arguments going for a while now.
 
 Barry, as chair

BTW Barry,  the proposal I made was this:

http://mipassoc.org/pipermail/ietf-dkim/2011q2/016282.html

Repeated here for those without editor URL launching support or disabled.

  --
 Murray wrote:
 You want AUID and RFC5322.From added to the Output Requirements 
 section explicitly.  

BTW, while RFC5322.From will satisfy requirements, I am proposing a
new ODID identity (RFC5322.From.domain) since that is whats already
extracted by APIs in order to do the current ADSP support.

I proposes the following:

3.x  Originating Domain Identity (ODID)

 The ODID is the domain part of the From: address.  This identity
 MAY be considered as an output communicated to an advanced
 Identity Assessor module.

INFORMATIVE IMPLEMENTATION NOTE:

The ODID and SDID are inputs for the optional
Checking Signing Practices component as described
in the DKIM Service Architecture [RFC5585]

3.9.  Output Requirements

 For each signature that verifies successfully or produces a TEMPFAIL
 result, the output of a DKIM verifier module MUST include the set of:

 o  The domain name, taken from the d= signature tag; and

 o  The result of the verification attempt for that signature.

|  Optional output are:
|
|  o  The Agent or User Identity (AUID) taken from i=, if any.
|
|  o  The Originating Domain Identity (ODID). Verifier output
| MAY consider ODID when no signatures or invalid signatures
| are found.

 The output MAY include other signature properties or result meta-
 data, including PERMFAILed or otherwise ignored signatures, for use
 by modules that consume those results.

 See Section 6.1 for discussion of signature validation result codes.

You might be able to figure out better text.
   -

-- 
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


Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

2011-05-06 Thread Murray S. Kucherawy
 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Hector Santos
 Sent: Thursday, May 05, 2011 9:41 PM
 To: dcroc...@bbiw.net
 Cc: ietf-dkim@mipassoc.org
 Subject: Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!
 
 This approach you have is an implementation conclusion.  It is not
 part of the protocol. The protocol clearly says in 3.11:
 
 Upon successfully verifying the signature, a receive-side DKIM
 verifier MUST communicate the Signing Domain Identifier (d=) to a
 consuming Identity Assessor module and MAY communicate the Agent or
 User Identifier (i=) if present.
 
 Therefore with no subjective consideration, no assertions, no
 philosophies, the protocol defines a process model of:
 
 trust = TrustIdentityAssessor(SDID [,AUID])
 
 There is NO opinion about this! That is your DKIM Trust Protocol Model
 with a Mandatory SDID input and an optional AUID input.

Actually, using your notation, it's:

trust = TrustIdentityAssessor(SDID[, AUID[, s=[, t=[, l=[, x=[, ...]])

How far do we really need to go here?

 In order for this to work, your 3.9 Output Requirement MUST expose
 those two parameters at the very least.

By saying MAY ... other, I maintain that it already does.

 To be consistent you have three protocol design tech writing choices:
 
1) Remove the second clause in that 3.11 3rd paragraph - problem fixed.
 
2) Add AUID to 3.9 as an optional output
 
3) Remove section 3.9

...or the solution I'm beginning to like:

4) Alter 3.11 to match 3.9.

 This is what happens when you add something in the last minute without
 any consensus.  It was just added - no consensus.

After a short scan of the tracker item (#22) and the discussion thread, I found 
three people worked on the specific text and at least five (including those 
three) said they liked the result, versus one or two that disagreed.  That 
sounded like rough consensus to me and we were still within the WGLC deadline, 
so I incorporated the change.

Again, the Chair has the final say.


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


Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

2011-05-06 Thread Hector Santos
Murray S. Kucherawy wrote:
 -Original Message-

 Therefore with no subjective consideration, no assertions, no
 philosophies, the protocol defines a process model of:

 trust = TrustIdentityAssessor(SDID [,AUID])

 There is NO opinion about this! That is your DKIM Trust Protocol Model
 with a Mandatory SDID input and an optional AUID input.
 
 Actually, using your notation, it's:
 
   trust = TrustIdentityAssessor(SDID[, AUID[, s=[, t=[, l=[, x=[, ...]])
 
 How far do we really need to go here?

As far are the protocol technical specification says it is. However, 
isn't these additional parameters not part of a Trust Assessor 
functionality and are part of the validation functionality?  In 
principle, the RFC4871 process model prototyping using a dyadic FP 
(Functional Programming) methodology would be overall:

   MAIL.PAYLOAD= MAIL_FEED()
   VERIFY.OUTPUT   = DKIM_VERIFY(MAIL.PAYLOAD)
   ACCESSOR.OUTPUT = DKIM_ACCESSORS(VERIFY.OUTPUT, MAIL.PAYLOAD)

In this summary prototype, MAIL.PAYLOAD provides all the inputs 
(RFC5322 message) for both verification and for any inputs required 
for any assessors in the process. The only new data would be included 
within the VERIFY.OUTPUT and ASSESSOR.OUTPUT namespaces.

With 3.9, VERIFY.OUTPUT is defined to be:

   VERIFY.OUTPUT.RESULT
   VERIFY.OUTPUT.SDID

Without 3.9, the technical reading extraction would be:

   VERIFY.OUTPUT.RESULT
   VERIFY.OUTPUT.SDID
   VERIFY.OUTPUT.AUID

and IMO, per RFCs 4686, 5016, 5617, 5585, 5863 it would be:

   VERIFY.OUTPUT.RESULT
   VERIFY.OUTPUT.SDID
   VERIFY.OUTPUT.AUID
   VERIFY.OUTPUT.ODID

To exclude AUID and/or ODID, it would be a subjective conclusion for a 
specific implementation mandate.

 To be consistent you have three protocol design tech writing choices:

1) Remove the second clause in that 3.11 3rd paragraph - problem fixed.
2) Add AUID to 3.9 as an optional output
3) Remove section 3.9
 
 or the solution I'm beginning to like:
 
 4) Alter 3.11 to match 3.9.

or take out 3.11 and like it was done for RFC5322.From, you can modify
the two references to the unfortunate technically incorrect sentence
in the abstract and section 1.2:

DKIM separates the question of the identity of the signer of
the message from the purported author of the message.

What question are we separating?  The association?  It would be 
technically incorrect given the binding requirement.

In lieu of ADSP, it may be a policy-based association separation but 
still an
DKIM-based association of authenticity.  As long as Purported Author 
is a fundamental requirement to be bound to the signature, it will 
always be an inherent association between the signer and author that 
can not be separated.

Maybe it can be change to a more functionally correct description:

DKIM provides a mechanism which allows for the separation of
the authorized association|relationship of the identity of
the message signer from any other agent or user identity,
including the originating author domain.

Anyway

-- 
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


Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

2011-05-06 Thread Douglas Otis
On 5/5/11 9:40 PM, Hector Santos wrote:
 Dave CROCKER wrote:

 I don't think this is correct. The signer creates and signs the i= value,
 so it's not garbage,
 
 By garbage, I mean not guaranteed to have any useful meaning.
 
 So, I believe, it's essentially meaningless as far as the protocol can
 stipulate.  Assertions of its semantics thus fall outside of the base DKIM
 spec.
 It's worth noting that Murray said 'could be'.

 But Murray's final paragraph has the essential points: within the scope of 
 the
 DKIM Signing specification, the receive-side has no way to determine what the
 semantics of i= are, as we discussed at great length when formulating the 
 Update
 RFC.

 But, then, folks on the list already know that.
 We have here is a failure to communicate. - Cool Hand Luke

 Dave,

 This approach you have is an implementation conclusion.  It is not
 part of the protocol. The protocol clearly says in 3.11:

  Upon successfully verifying the signature, a receive-side DKIM
  verifier MUST communicate the Signing Domain Identifier (d=) to a
  consuming Identity Assessor module and MAY communicate the Agent or
  User Identifier (i=) if present.

 Therefore with no subjective consideration, no assertions, no
 philosophies, the protocol defines a process model of:

  trust = TrustIdentityAssessor(SDID [,AUID])

 There is NO opinion about this! That is your DKIM Trust Protocol Model
 with a Mandatory SDID input and an optional AUID input.

 In order for this to work, your 3.9 Output Requirement MUST expose
 those two parameters at the very least.  There is no assertions or
 opinions - thats the protocol you defined.

 Now, when you begin to exclude it, then you mixing up implementation
 desires with subjective conclusion that really is not part of the
 protocol defined.  There is some subjective information notes about
 the value, but that has nothing to do with the protocol you defined.

 To be consistent you have three protocol design tech writing choices:

 1) Remove the second clause in that 3.11 3rd paragraph - problem fixed.

 2) Add AUID to 3.9 as an optional output

 3) Remove section 3.9

 This is what happens when you add something in the last minute without
 any consensus.  It was just added - no consensus.
I must agree with Hector on this point.  It seems the motivation to 
simplify DKIM has wrongly included removal of output information 
intended to be bound with the signature.  It would be like SMTP later 
deciding not to include trace information intended to be bound with the 
message.

While the i= may contain the email address of the author or the 
postmaster of the domain or simply an opaque tag, the meaning is NOT 
undefined.  Its meaning IS defined by the signing domain.  The whole 
point of DKIM was to establish a context for such information, 
especially information intended to be closely bound with the signature.  
Deprecating that aspect of DKIM overlooks many security aspects, and the 
valid and intended use of this information.  What this parameter had 
been defined should ensure against any interoperability issues, but 
perhaps deserves a warning that it NOT be used by third parties who are 
unaware of the signing domains definition of this field.  It would still 
be extremely useful within enterprise applications, for example.

-Doug




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


Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

2011-05-06 Thread Barry Leiba
We've had a bit of discussion in this thread (and elsewhere) about
this, but I need to get a clear view of consensus.  Doug agrees with
Hector's note, below, and Dave and Murray do not.  I'd like to hear
from others within the next few days, about whether you think we
should make the change Hector requests or not.  I need to get a sense
of whether there's significant support for it.  Again, please keep
arguments to a minimum, so it's clearer to me what the consensus is --
we've had the arguments going for a while now.

Barry, as chair

On Wed, May 4, 2011 at 6:11 PM, Hector Santos hsan...@isdg.net wrote:
 Ah come on guys!  We all know what the problems are, we know the sides
 and what colors we wear.  Is it possible to come up with a compromise
 to solve this conflicts once and for all?

 Dave, don't you want receivers to follow RFC5585 design?  If so, then
 what can't we get the Outputs described for that design to work?  From
 what I can see, there are four variables:

    status  REQUIRED
    SDID    REQUIRED, MANDATORY for Trust Identity Assessor (see 2.7)
    AUID    OPTIONAL, see 3.11
    ODID    OPTIONAL for Checking Signing Process (see RFC5585)

 We have the REQUIRED/MANDATORY identity you want.  But you have the
 others too.

 What is technically wrong with this?

 --
 Sincerely

 Hector Santos
 http://www.santronics.com

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


Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

2011-05-06 Thread John R. Levine
 this, but I need to get a clear view of consensus.  Doug agrees with
 Hector's note, below, and Dave and Murray do not.  I'd like to hear
 from others within the next few days, about whether you think we
 should make the change Hector requests or not.

Dave and Murray are right, Hector is not.

R's,
John
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

2011-05-05 Thread Hector Santos
Murray, your technical *subjective* reasoning is not convincing.

First, as for procedural issues, I have come to understand for bis 
work, how Hansen, Klensin and SM describes it. You do not seem to 
reflect the same advice and quite often in contradiction.

In regards to AUID, the only technical *non-subjective protocol 
recommendation to consider is the one in section 3.11:

Upon successfully verifying the signature, a receive-side DKIM
verifier MUST communicate the Signing Domain Identifier (d=) to a
consuming Identity Assessor module and MAY communicate the Agent or
User Identifier (i=) if present.

It provides the non-subjective protocol technical justifications for 
both outputs to be part of the output requirements.  Nothing else need 
to be said. Its called Software Engineering. Choosing not to include 
it is a subjective implementation reason.

In regards to ODID, its a fundamental message header. Its technical 
history and importance should not be something to be explained. In 
DKIM, that fundamental messaging entity is reflected as the only 
single header requirement for signature binding and per RFC5585, 
RFC4686, RFC5017 and RFC5617 an essential part for security.

Most important of all:

DKIM can not mandate which is now a highly questionable protocol with 
highly subjective information in it with an highly isolated mandate 
for a mandatory single output with a MUST have requirement for a Trust 
Identity Assessor without *explicitly exposing* all the minimal 
outputs, especially when the default design excludes security protocol 
design considerations.

Protocol implementation is whats it all about and for RFC4871bis, it 
is for specific implementation design only.

If we want to exclude specific implementations, the Output 
Requirements needs to be more open with DKIM Complete information 
for receivers to better consider.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Murray S. Kucherawy wrote:
 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Hector Santos
 Sent: Wednesday, May 04, 2011 4:22 PM
 To: ietf-dkim@mipassoc.org
 Subject: Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

 You want AUID and RFC5322.From added to the Output Requirements
 section explicitly.  At least two other participants disagree on
 either technical or procedural grounds.
 1) I have not seen any no arguments based on technical merits, or one
 that didn't have an substantial proof.  Purely procedural and even SM
 showed your opinion on procedural (for BIS work) was not quite IETF
 correct.
 
 You're not reading our replies then.  So here we go again, once more for the 
 record, one of each:
 
 Technical: The AUID is an unvetted value.  The local-part and the subdomain 
 could be garbage.  It's inappropriate for a security protocol to return a 
 possibly false value in the context of saying something was cryptographically 
 validated.  Moreover, the suggestion conflates protocol and implementation; 
 you can already pass the AUID, the From: field, or any other value you want 
 to an adjacent layer or module without requiring a change to the current 
 wording of 3.9.  The fact that some adjacent modules want or need it is not 
 proscribed by the current wording either, so the proposed change is actually 
 unnecessary.
 
 Procedural: Working group consensus to date has been to list only SDID as the 
 required output, along with a status (see RFC5672, and RFC4871bis WGLC 
 traffic).  Adding a value to the list of outputs is in contradiction to the 
 Draft Standards advancement process (see BCP9, Section 4.1.2).  Only removing 
 things is allowed.  SM didn't correct my interpretation of BCP9, but rather 
 highlighted another aspect of it.  What he said and what I said are both 
 correct.
 
 2) There are at least four others (including myself) who agree with
 the ODID proposal of both variable or one of them.
 
 I've only seen one other that supports the RFC5322.From as being a mandatory 
 output.  So let's tackle that now too, for the record:
 
 Technical: The RFC5322.From is an unvetted value.  The entire field could be 
 garbage.  It's inappropriate; see above, same reasons.
 
 Procedural: Adding a value, see above, same reasons.
 
 So what's the compromise?
 Your ball.  You are the editor of the documents. Its up to you to
 reduce the conflicts with proposed compromising text.  Murray, I am
 not your problem as much you believe, insist it is.
 
 I encourage you to read The Tao of IETF, http://www.ietf.org/tao.html, 
 especially Section 5.3 which explains the role of the document editor.  
 Contrary to what you seem to believe, it is not our job to find a way to slip 
 your suggestion in to the document just because it is repeated often.  
 Rather, a change to a standards track document, which RFC4871 and RFC5672 
 are, requires working group consensus and then similarly consensus

Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

2011-05-05 Thread Hector Santos
Murray, your technical *subjective* reasoning is not convincing.

First, as for procedural issues, I have come to understand for bis
work, how Hansen, Klensin and SM describes it. You do not seem to
reflect the same advice and quite often in contradiction.

In regards to AUID, the only technical *non-subjective protocol
recommendation to consider is the one in section 3.11:

Upon successfully verifying the signature, a receive-side DKIM
verifier MUST communicate the Signing Domain Identifier (d=) to a
consuming Identity Assessor module and MAY communicate the Agent or
User Identifier (i=) if present.

It provides the non-subjective protocol technical justifications for
both outputs to be part of the output requirements.  Nothing else need
to be said. Its called Software Engineering. Choosing not to include
it is a subjective implementation reason.

In regards to ODID, its a fundamental message header. Its technical
history and importance should not be something to be explained. In
DKIM, that fundamental messaging entity is reflected as the only
single header requirement for signature binding and per RFC5585,
RFC4686, RFC5017 and RFC5617 an essential part for security.

Most important of all:

DKIM can not mandate which is now a highly questionable protocol with
highly subjective information in it with an highly isolated mandate
for a mandatory single output with a MUST have requirement for a Trust
Identity Assessor without *explicitly exposing* all the minimal
outputs, especially when the default design excludes security protocol
design considerations.

Protocol implementation is whats it all about and for RFC4871bis, it
is for specific implementation design only.

If we want to exclude specific implementations, the Output
Requirements needs to be more open with DKIM Complete information
for receivers to better consider.

-- 
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com

Murray S. Kucherawy wrote:
 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Hector Santos
 Sent: Wednesday, May 04, 2011 4:22 PM
 To: ietf-dkim@mipassoc.org
 Subject: Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

 You want AUID and RFC5322.From added to the Output Requirements
 section explicitly.  At least two other participants disagree on
 either technical or procedural grounds.
 1) I have not seen any no arguments based on technical merits, or one
 that didn't have an substantial proof.  Purely procedural and even SM
 showed your opinion on procedural (for BIS work) was not quite IETF
 correct.
 
 You're not reading our replies then.  So here we go again, once more for the 
 record, one of each:
 
 Technical: The AUID is an unvetted value.  The local-part and the subdomain 
 could be garbage.  It's inappropriate for a security protocol to return a 
 possibly false value in the context of saying something was cryptographically 
 validated.  Moreover, the suggestion conflates protocol and implementation; 
 you can already pass the AUID, the From: field, or any other value you want 
 to an adjacent layer or module without requiring a change to the current 
 wording of 3.9.  The fact that some adjacent modules want or need it is not 
 proscribed by the current wording either, so the proposed change is actually 
 unnecessary.
 
 Procedural: Working group consensus to date has been to list only SDID as the 
 required output, along with a status (see RFC5672, and RFC4871bis WGLC 
 traffic).  Adding a value to the list of outputs is in contradiction to the 
 Draft Standards advancement process (see BCP9, Section 4.1.2).  Only removing 
 things is allowed.  SM didn't correct my interpretation of BCP9, but rather 
 highlighted another aspect of it.  What he said and what I said are both 
 correct.
 
 2) There are at least four others (including myself) who agree with
 the ODID proposal of both variable or one of them.
 
 I've only seen one other that supports the RFC5322.From as being a mandatory 
 output.  So let's tackle that now too, for the record:
 
 Technical: The RFC5322.From is an unvetted value.  The entire field could be 
 garbage.  It's inappropriate; see above, same reasons.
 
 Procedural: Adding a value, see above, same reasons.
 
 So what's the compromise?
 Your ball.  You are the editor of the documents. Its up to you to
 reduce the conflicts with proposed compromising text.  Murray, I am
 not your problem as much you believe, insist it is.
 
 I encourage you to read The Tao of IETF, http://www.ietf.org/tao.html, 
 especially Section 5.3 which explains the role of the document editor.  
 Contrary to what you seem to believe, it is not our job to find a way to slip 
 your suggestion in to the document just because it is repeated often.  
 Rather, a change to a standards track document, which RFC4871 and RFC5672 
 are, requires working group consensus and then similarly consensus up the 
 chain

Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

2011-05-05 Thread Michael Thomas
On 05/04/2011 08:34 PM, Murray S. Kucherawy wrote:
 Technical: The AUID is an unvetted value.  The local-part and the subdomain 
 could be garbage.  It's inappropriate for a security protocol to return a 
 possibly false value in the context of saying something was cryptographically 
 validated.


I don't think this is correct. The signer creates and signs the i= value,
so it's not garbage, and it can't be false either. I don't even know
what false means in this context. It's just a value which  is guaranteed
to be within the to the d= domain's bailiwick.

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


Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

2011-05-05 Thread Douglas Otis
On 5/5/11 1:34 PM, Michael Thomas wrote:
 On 05/04/2011 08:34 PM, Murray S. Kucherawy wrote:
 Technical: The AUID is an unvetted value.  The local-part and the subdomain 
 could be garbage.  It's inappropriate for a security protocol to return a 
 possibly false value in the context of saying something was 
 cryptographically validated.

 I don't think this is correct. The signer creates and signs the i= value,
 so it's not garbage, and it can't be false either. I don't even know
 what false means in this context. It's just a value which  is guaranteed
 to be within the to the d= domain's bailiwick.
Agreed.

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


Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

2011-05-05 Thread Murray S. Kucherawy
 -Original Message-
 From: Michael Thomas [mailto:m...@mtcc.com]
 Sent: Thursday, May 05, 2011 1:35 PM
 To: Murray S. Kucherawy
 Cc: ietf-dkim@mipassoc.org
 Subject: Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!
 
 On 05/04/2011 08:34 PM, Murray S. Kucherawy wrote:
  Technical: The AUID is an unvetted value.  The local-part and the
  subdomain could be garbage.  It's inappropriate for a security protocol
  to return a possibly false value in the context of saying something was
  cryptographically validated.
 
 I don't think this is correct. The signer creates and signs the i= value,
 so it's not garbage, and it can't be false either. I don't even know
 what false means in this context. It's just a value which  is guaranteed
 to be within the to the d= domain's bailiwick.

By garbage, I mean not guaranteed to have any useful meaning.

Think of how it might be used by someone seeking to avoid accumulating negative 
reputation.  The subdomain might not exist; it could be a string of random 
(though syntactically legal) characters.  The local part might not have 
anything at all to do with an email address or other login ID that's valid on 
the signer or author systems, and may be unique per-message meaning it can't be 
used as input to an assessor in a useful way.

So, I believe, it's essentially meaningless as far as the protocol can 
stipulate.  Assertions of its semantics thus fall outside of the base DKIM spec.


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


Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

2011-05-05 Thread John Levine
I don't think this is correct. The signer creates and signs the i= value,
so it's not garbage, and it can't be false either.

Perhaps the word stable would be more applicable.  The d= value is
tied to the DNS, is relatively stable, and the verifier can check that
there's a key record in the DNS that matches the signature.  The parts
of the i= beyond what's in the d= are just an assertion by the signer
with no semantics, verifiable or otherwise, and are no more useful
than any other unverified assertion.

R's,
John
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

2011-05-05 Thread Hector Santos
Dave CROCKER wrote:

 I don't think this is correct. The signer creates and signs the i= value,
 so it's not garbage,
 
 By garbage, I mean not guaranteed to have any useful meaning.
 
 So, I believe, it's essentially meaningless as far as the protocol can
 stipulate.  Assertions of its semantics thus fall outside of the base DKIM
 spec.

 It's worth noting that Murray said 'could be'.
 
 But Murray's final paragraph has the essential points: within the scope of the
 DKIM Signing specification, the receive-side has no way to determine what the
 semantics of i= are, as we discussed at great length when formulating the 
 Update
 RFC.
 
 But, then, folks on the list already know that.

We have here is a failure to communicate. - Cool Hand Luke

Dave,

This approach you have is an implementation conclusion.  It is not 
part of the protocol. The protocol clearly says in 3.11:

Upon successfully verifying the signature, a receive-side DKIM
verifier MUST communicate the Signing Domain Identifier (d=) to a
consuming Identity Assessor module and MAY communicate the Agent or
User Identifier (i=) if present.

Therefore with no subjective consideration, no assertions, no 
philosophies, the protocol defines a process model of:

trust = TrustIdentityAssessor(SDID [,AUID])

There is NO opinion about this! That is your DKIM Trust Protocol Model 
with a Mandatory SDID input and an optional AUID input.

In order for this to work, your 3.9 Output Requirement MUST expose 
those two parameters at the very least.  There is no assertions or 
opinions - thats the protocol you defined.

Now, when you begin to exclude it, then you mixing up implementation 
desires with subjective conclusion that really is not part of the 
protocol defined.  There is some subjective information notes about 
the value, but that has nothing to do with the protocol you defined.

To be consistent you have three protocol design tech writing choices:

   1) Remove the second clause in that 3.11 3rd paragraph - problem fixed.

   2) Add AUID to 3.9 as an optional output

   3) Remove section 3.9

This is what happens when you add something in the last minute without 
any consensus.  It was just added - no consensus.

-- 
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


Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

2011-05-04 Thread Dave CROCKER


On 5/4/2011 3:11 PM, Hector Santos wrote:
 Dave, don't you want receivers to follow RFC5585 design?  If so, then

RFC 5585 is not a 'design'.  It has a diagram that describes an overall service.

Also, the scope of its description is much larger than what is covered by the 
DKIM Signing specification.


 what can't we get the Outputs described for that design to work?  From
 what I can see, there are four variables:

  status  REQUIRED
  SDIDREQUIRED, MANDATORY for Trust Identity Assessor (see 2.7)
  AUIDOPTIONAL, see 3.11
  ODIDOPTIONAL for Checking Signing Process (see RFC5585)

 We have the REQUIRED/MANDATORY identity you want.  But you have the
 others too.

 What is technically wrong with this?

It goes beyond the Update the working group and the IETF approved.

It also seems to confuse protocol issues with implementation issues.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html


Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

2011-05-04 Thread Murray S. Kucherawy
 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Hector Santos
 Sent: Wednesday, May 04, 2011 3:11 PM
 To: dcroc...@bbiw.net
 Cc: ietf-dkim@mipassoc.org
 Subject: [ietf-dkim] Output summary - Keep your Eye on the Prize!
 
 Ah come on guys!  We all know what the problems are, we know the sides
 and what colors we wear.  Is it possible to come up with a compromise
 to solve this conflicts once and for all?

I'm game.  Let's play.

You want AUID and RFC5322.From added to the Output Requirements section 
explicitly.  At least two other participants disagree on either technical or 
procedural grounds.

So what's the compromise?  So far all you've done is repeat the suggestion 
without any changes, so the others repeat their position without any changes.  
That's not a quest for compromise, it's a circular argument.

Try proposing something else, perhaps.


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


Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

2011-05-04 Thread Hector Santos
Murray S. Kucherawy wrote:
 -Original Message-

 Ah come on guys!  We all know what the problems are, we know the sides
 and what colors we wear.  Is it possible to come up with a compromise
 to solve this conflicts once and for all?
 
 I'm game.  Let's play.

I hope that means play nice.

 
 You want AUID and RFC5322.From added to the Output Requirements 
 section explicitly.  At least two other participants disagree on 
 either technical or procedural grounds.

1) I have not seen any no arguments based on technical merits, or one
that didn't have an substantial proof.  Purely procedural and even SM
showed your opinion on procedural (for BIS work) was not quite IETF
correct.

2) There are at least four others (including myself) who agree with
the ODID proposal of both variable or one of them.

 So what's the compromise?  

Your ball.  You are the editor of the documents. Its up to you to
reduce the conflicts with proposed compromising text.  Murray, I am
not your problem as much you believe, insist it is.

-- 
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


Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!

2011-05-04 Thread Murray S. Kucherawy
 -Original Message-
 From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] 
 On Behalf Of Hector Santos
 Sent: Wednesday, May 04, 2011 4:22 PM
 To: ietf-dkim@mipassoc.org
 Subject: Re: [ietf-dkim] Output summary - Keep your Eye on the Prize!
 
  You want AUID and RFC5322.From added to the Output Requirements
  section explicitly.  At least two other participants disagree on
  either technical or procedural grounds.
 
 1) I have not seen any no arguments based on technical merits, or one
 that didn't have an substantial proof.  Purely procedural and even SM
 showed your opinion on procedural (for BIS work) was not quite IETF
 correct.

You're not reading our replies then.  So here we go again, once more for the 
record, one of each:

Technical: The AUID is an unvetted value.  The local-part and the subdomain 
could be garbage.  It's inappropriate for a security protocol to return a 
possibly false value in the context of saying something was cryptographically 
validated.  Moreover, the suggestion conflates protocol and implementation; you 
can already pass the AUID, the From: field, or any other value you want to an 
adjacent layer or module without requiring a change to the current wording of 
3.9.  The fact that some adjacent modules want or need it is not proscribed by 
the current wording either, so the proposed change is actually unnecessary.

Procedural: Working group consensus to date has been to list only SDID as the 
required output, along with a status (see RFC5672, and RFC4871bis WGLC 
traffic).  Adding a value to the list of outputs is in contradiction to the 
Draft Standards advancement process (see BCP9, Section 4.1.2).  Only removing 
things is allowed.  SM didn't correct my interpretation of BCP9, but rather 
highlighted another aspect of it.  What he said and what I said are both 
correct.

 2) There are at least four others (including myself) who agree with
 the ODID proposal of both variable or one of them.

I've only seen one other that supports the RFC5322.From as being a mandatory 
output.  So let's tackle that now too, for the record:

Technical: The RFC5322.From is an unvetted value.  The entire field could be 
garbage.  It's inappropriate; see above, same reasons.

Procedural: Adding a value, see above, same reasons.

  So what's the compromise?
 
 Your ball.  You are the editor of the documents. Its up to you to
 reduce the conflicts with proposed compromising text.  Murray, I am
 not your problem as much you believe, insist it is.

I encourage you to read The Tao of IETF, http://www.ietf.org/tao.html, 
especially Section 5.3 which explains the role of the document editor.  
Contrary to what you seem to believe, it is not our job to find a way to slip 
your suggestion in to the document just because it is repeated often.  Rather, 
a change to a standards track document, which RFC4871 and RFC5672 are, requires 
working group consensus and then similarly consensus up the chain of approval.  
It is not up to us to encourage consensus or compromise for submitted ideas; 
it's up to the people making the submissions.  That's you here.  If you want 
the change, you do the legwork.

So far I don't see consensus that the RFC5322.From or AUID additions to 3.9 is 
an allowable change procedurally, or a supported one technically.  That's why 
it's not included.  You may of course appeal to the chair if you have different 
information than I do, but that's where it stands.


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