Re: [ietf-dkim] Re: Issue #1512: Re: making SSP useless in one short step

[Arvel Hathcock]

+1

Me, three.  Alert... everyone else.


OMG, +1

I could easily get on-board for this.  What's unacceptable is if the 
existence of any valid signature what-so-ever is sufficient to bypass SSP.


Arvel

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

Re: [ietf-dkim] Draft summary of SSP functionality

[Arvel Hathcock]

Ok, took the bait, couldn't resist, sorry :)

> You don't think that a status label of "suspicious" implies a focus on
> misbehaviors?.

I know you didn't ask me this, but (sorry), if we decide to change 
"Suspicious" to something else then we might as well go fully P.C. and 
change it to "a message of interest."  We've all seen the police on the 
news before:  "Yes, the suspect was detained for questioning... Uh, 
, I meant, the person of 
interest was detained..."  If anyone thinks what I've just said is silly 
then perhaps you can see why much of this dancing back and forth on 
egg-shells is just getting a bit boring.  I've got a dictionary. 
Suspicious is the right word.  I'm inclined to leave it.  But if we 
change it, please don't use "a message of interest."  I think they'll 
kill me for that in Texas.


> Do [you] envision a reasonable scenario where a receiver has
> adopted SSP and conforms to it, but does not have the
> stated sender enforcement request override the reputation
> assessment for a signer?  Note that this either implies
> or explicitly violates the request of the SSP domain owner.

I know you didn't ask me this question either (sorry) but what I can 
easily imagine is a scenario in which a receiver has adopted SSP and 
conforms to it, but decides to set it aside in the presence of a valid 
signature from an entity that it trusts.


> Could you provide some examples of such scenarios?

You didn't ask me, but yes, I can.

(a) My software has a global white list feature.  That white list 
contains any number of identities from which validly signed messages are 
trusted.  When encountered, no SSP.


(b) My software allows individual users to maintain their own address 
books.  The domain of any entry therein can be configured as a trusted 
identity.  When validly signed messages arrive from such identities 
bound for said users, no SSP.


(c) My software includes call outs to a certification service.  Use of 
the service is predicated upon trust in the certifier.  When validly 
signed messages arrive from identities which the certification service 
says it's in love with, no SSP.


(d) Although this isn't completely fleshed out yet I hope my software 
will someday have a transparent framework for using any domain-based 
reputation service.  Use of such services are predicated upon trust in 
the service provider.  When validly signed messages arrive, etc. etc.


Compared to many on this list, I'm a relative idiot in the software 
business.  Imagine what somebody with a real brain might be able to come 
up with.


Arvel


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

Re: [ietf-dkim] Re: Issue #1512: Re: making SSP useless in one short step

[Dave Crocker]

John Levine wrote:

Which is a long winded version of that third party signatures are
completely orthogonal to SSP. "All" should just mean "I sign all of
my mail". No more, no less.


+1

R's,
John

PS: Mike and I agree on something! Alert the media!


+1

Me, three.  Alert... everyone else.

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] Draft summary of SSP functionality

[Arvel Hathcock]

If what you say is true then we should shore up the Introduction. 
Failing that, I propose that we focus working group time on working 
group deliverables.  This isn't one of them.


Arvel


Dave Crocker wrote:

Folks,

If non-participants are to be asked about the potential use of SSP, it 
helps to have a description of it that is concise, complete and for 
which there is reasonable consensus about the content.  Simply handing 
non-participants a point to the specification is useless for all but the 
most technical and dedicated.


To that end, I've pulled some text from my review, as a candidate.  It's 
intent is not to judge SSP but to describe its salient basis and 
functions. In other words, what is it, rather than is it good, bad or 
broken?


Obviously I have no expectation that my writing is entirely without 
judgment, so I would like to get some working group review of the text, 
to see if we can agree on text that is factual and useful:


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

Re: [ietf-dkim] Tracing SSP's paradigm change

[Arvel Hathcock]

Note that  
refers to unsigned messages and not signed messages that do not match 
the From field.


Well, I wonder what this might mean: "There is also the issue of (c) the 
use of SSP to determine the types of DKIM identities that are acceptable."


I'm done with this debate now.  What matters is the issue tracker and 
I'm sure the chairs would rather see input there.


Arvel

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

Re: [ietf-dkim] ISSUE 1519: SSP-01 Unnecessary constraint on i= when asserting "strict"

[Douglas Otis]

On Dec 5, 2007, at 3:41 PM, Jim Fenton wrote:


There seems to be quite a bit here I don't understand.

Douglas Otis wrote:
A domain wishing to protect their transactional mail may decide to  
publish "strict" to limit the acceptance of "non-compliant" messages.


Compliance now requires the i= to not include a localpart, or for  
the localpart to match with the From header.


"Compliance" must be equivalent to "being not Suspicious".


Funny you should ask. : )

The word "suspicious" used in the SSP draft has different meanings.   
"Non-compliance" was meant to mean "not complying with the definition  
of a valid Originator Signature".  The "suspicious" term offers a  
negative connotation to define a state, and such connotation seems  
unnecessary for a specification.  The word "suspicious" is also found  
in three other places within the draft to imply different states.  The  
draft seems to presume these states are to be combined.  The  
specifications should not attempt this optimization without some  
experience indicating whether combining these states would be the  
right choice.


Having a valid "Originator Signature" was one way "suspicious" was  
defined, so technically no, I do not mean "suspicious" per the current  
definition of "Originating Signature".  I apologize for not adopting  
the "suspicious" convention.  Ironically, I was attempting to avoid  
confusion.


This unnecessary requirement may produce "false positive"  
detections of bad acts when signing domain uses i= as intended in  
the base draft, which is to indicate on who's behalf the message  
was signed.


I need an example to understand what would constitute a false  
positive.


Example 1:

A domain is signing all their email per DKIM base and are very careful  
about where all their email originates.  They go to great lengths to  
ensure the i= parameter indicates which header identity submitted the  
message (on who's behalf the message was signed).  Everything is  
running fine, and then the IT staff decides to publish an SSP policy  
of "strict" to curtail reports of spoofing because they were advised  
to do so in this situation.  Now they find messages from the office  
administrator of the CEO are being blocked at the MTA used by their  
accounting agency.  The signature accurately indicates the message was  
introduced by the office administrator.  After all, the office  
administrator is the only authenticated entity submitting the message,  
and the i= parameter accurately reflects this.  Clearly, the domain  
has done the "right thing" per DKIM base.


Per the definition of Originator Signature, only a signature "on  
behalf of" the From header can qualify as being valid.  Or more  
technically, a message submitted by the office administrator for the  
CEO will not be compliant with this definition of Originator  
Signature.  In essence, a verifier is expected to know better than the  
signing domain which headers are to be referenced by the i=  
parameter.  With this restriction placed upon the i= parameter,  a  
policy of "strict" will then make such messages as non-compliant with  
the definition of Originator Signature.  A valid Originator Signature  
is required to be compliant with "strict".  The IT staff might ask  
themselves whether they should have waited for SSP to have been  
finished before deploying DKIM.


Example 2:

A domain is running web based commerce and mailing-list on the same  
domain.  They feel using the same domain improves their branding,  
makes it easier for their customers to remember, and better protects  
their users from phishing.  This mailing list signs the RFC2921 List- 
id headers and does not use (or overwrite) Sender headers.  While  
allowing anyone to subscribe, this domain ensures only specific role  
accounts within their domain are able to post to the mailing list.  As  
with example 1, the domain is very careful about where all their email  
originates, and they also wish to protect their transactional  
messages.  After publishing a "strict" policy, they then receive  
complaints many subscribers are no longer able to receive list  
messages from their role accounts.


Example 3:

A large well-known domain issues transactional messages, where some  
messages serve as an introduction service.  These messages facilitate  
an introduction by placing a first-party email-address within the From  
header.  At times, the introduction address is that of "complimentary"  
or account on the domain when some customers want to remain  
anonymous.  Each message is signed with an opaque-id which internally  
defines the transaction, and has nothing to do with the identity found  
within any header.  This domain also wishes to protect their  
transactions, but find when they publish "strict", their  
"complimentary" email is blocked, even at their own MTA.



Options to mitigate "false positives" would be to:

1- Exclude the i= parameter
2- Add another signature specifically signin

Re: [ietf-dkim] Re: making SSP useless in one short step

[Arvel Hathcock]

Hi all, me again, sorry.  Seems I'm missing all the fun in Vancouver. 
You don't know how much I wish I could be there.


On day one, for all intents and purposes, no recipient server on the 
Internet is going to make the query for this, and hence the mechanism is 
"defeated".


That line of thinking must be rejected because it is historically true 
for all protocols in widespread use today, promotes inertia, and 
celebrates a pessimistic futility.  We must be careful not to think in 
these terms.


At very best, it will be quite a few years (5-10 years seems typical, 
for popular enhancements to email) before a large number of receiving 
servers make the query, and there will remain a substantial percentage 
of receivers failing to query essentially forever.


Best to get the 5-10 year timer started now then!  This sounds like a 
good argument for getting SSP out yesterday.  Regardless, it may not be 
an accurate assessment of time frames in this case as recent industry 
activity suggests.


So the strict requirements of the strict mode have to be considered in 
the face of massive non-adoption, pretty much forever.


Folks, "massive non-adoption, pretty much forever" is one individual's 
assessment.  That does not necessarily mean it is accurate.  But, assume 
for a moment that it is accurate.  Do we deny useful capability to all 
simply because some (or even most) decide they don't need it or want it? 
 No, of course not.  So, no matter how you look at this argument, it is 
easily rejected.


Contrast this with the view that this feature is quite useful among a 
small, cooperative collection of services that have agreed to use it.


While this is not Internet scale -- by which I mean broad adoption with 
massive breadth of use and no prior arrangement among the users -- it is 
a perfectly credible capability, albeit one that needs to be treated as 
a specialized facility, rather than a general one.


I hope that I have completely misunderstood.

The notion that we should embrace a plurality of closed, specialized, 
and proprietary approaches to what should be an open industry standard 
freely available to all is antithetical to the IETF purpose (as I 
understand that purpose) and is specifically contrary to what we, as a 
working group, are chartered to achieve.  Therefore, it is out of step 
both with the spirit and the scope of our chartered work and should 
simply be discarded upon that basis.


Also, I can not stress this point enough: "specialized facilities" (as 
opposed to general ones) have a way of becoming entrenched and remaining 
specialized.  This is not healthy for the larger community.


Now, I am ready (and eager) to be corrected.

Arvel





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

Re: [ietf-dkim] making SSP useless in one short step

[Arvel Hathcock]

Question:  Is DKIM for transit validation or is it for content
authentication?


DKIM-Base is for transit validation.  DKIM-SSP is for detecting a 
certain type of unauthorized domain use.  Nothing is for content 
authentication.


Arvel


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

Re: [ietf-dkim] Re: making SSP useless in one short step

[Arvel Hathcock]

It rather depends on my opinion of hacker.com.  I agree that
signatures from unknown domains are uninteresting, something that's
the same with or without SSP.  But if I have reason to trust
hacker.com, I'm done, I'm not going to check anything else.


Correct, correct, correct!  In this cause we set SSP aside and embrace 
that realm which SSP so enthusiastically celebrates:  receiver freedom 
to do what-so-ever receiver freedom might dictate.  There is absolutely 
no problem here.


Arvel


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

Re: [ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01)

[Arvel Hathcock]

Folk on this list are confusing what the protocol states MUST be done in 
order to be implemented with what the protocol's algorithm states MUST 
be done to a message.  Any protocol has to have language with respect to 
the former.  This protocol has NO language with respect to the latter.


Sorry, "MUST be done to a message" in the sense of dictating ultimate 
disposition thereof.


Arvel


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

Re: [ietf-dkim] Tracing SSP's paradigm change

[Dave Crocker]

Arvel Hathcock wrote:

 > Well, I reviewed the archives for the period during which i= was added
 > and could not find discussion of it.  So I'm glad to hear you've done
 > a more thorough review.  This means that you can point me to the
 > archives of the working group consideration of the issue?

I wouldn't waste any more time chasing this.  Even if no such archive 
exists, what is that but evidence that this issue is idiosyncratic or 
has been deemed utterly unremarkable?


A lack of working group discussion is evidence of a lack of working group 
awareness and most certainly a lack of explicit working group consensus.


The use of SSP for signed messages creates a series of functional interactions 
that SSP's use on unsigned messages does not.


For a security protocol to skip analysis of interaction effects -- heck, for 
any protocol function to do this -- seems a tad unusual, particularly when it 
seeks to modify an existing critical infrastructure service.



The notion that "DKIM-Base is for signed mail while DKIM-SSP is for 
unsigned (only)" has never been thinking in accord with any draft of SSP 
which I remember reading or implementing.  And it's clearly out of step 
with where we are today.


Note that  refers 
to unsigned messages and not signed messages that do not match the From field.


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] Re: Issue #1512: Re: making SSP useless in one short step

[John Levine]

> Which is a long winded version of that third party signatures are
> completely orthogonal to SSP. "All" should just mean "I sign all of
> my mail". No more, no less.

+1

R's,
John

PS: Mike and I agree on something! Alert the media!


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

Re: [ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01)

[Arvel Hathcock]

Somehow, we need to tell verifiers what they need to do in order to
implement this specification.  Nobody is saying that verifiers MUST
implement SSP at all, but rather that if they want to implement SSP,
this is how they MUST do it.  Of course, verifiers are free to implement
some other SSP-like thing, even one that acts on SSP records, but I feel
we need to provide some precision in the thing we're calling SSP.


Exactly right!  Please, Jim, keep it up.

Folk on this list are confusing what the protocol states MUST be done in 
order to be implemented with what the protocol's algorithm states MUST 
be done to a message.  Any protocol has to have language with respect to 
the former.  This protocol has NO language with respect to the latter.


There is nothing that needs to be done here.

Arvel


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

Re: [ietf-dkim] Draft summary of SSP functionality

[Dave Crocker]

The SSP mechanism has a potential signer -- that is, the owner of a 
domain name -- publish an SSP-specific DNS TXT record, in an SSP-specific

branch under the domain name.  On the receive-side, the domain name under
which the DNS query is made is taken from the rfc2822.From 
portion of an address, in a received message.


It's not really an SSP-specific branch, but an SSP-specific label under the
DKIM key management branch.


What does it mean to have an SSP-specific label that is not an SSP-specific
branch?


By contrast, SSP seeks to detect misbehaviors, specifically related to 
unauthorized use of a domain in an RFC2822.From field . SSP
does not seek to deal with other identity fraud, such as in the 
RFC2822.From , the Subject field, or in the message body,

or any use of "cousin" domains that can be confused with a target domain.



That's one way to look at it.  I would describe it, instead of "detect 
misbehaviors, ..." as "provide guidance to DKIM verifiers regarding 
messages lacking a valid DKIM signature on behalf of the message's author."



The current SSP draft provides for two basic modes of use:


You don't think that a status label of "suspicious" implies a focus on
misbehaviors?

-base is careful to say that there is no semantic to be taken from the absence
of a valid signature.  -ssp is explicitly for the purpose of creating
semantics about the absence of any signature or an acceptable signature.

As for "detecting" versus "providing guidance" these focus on very different
levels, which I guess I think are are complementary. The former is higher
level, IMO, while the latter is more about the mechanism.  The text discusses
things in terms of their basic thrust.  There is a conceptual difference
between the nature of the use of DKIM signing versus SSP.



1. Unsigned message.  When a receiver gets a message that is not signed,
they can query the DNS for an SSP record, associated with the domain name
in the (first) rfc2822.From field header address.  If that record states
that all mail with that domain name in the From field is signed, then the
recipient can assume that the message is problematic.

2. Signed message.  When a receiver gets a message that is signed, but
which has the signature's "i=" that is different from the domain name in
the (first) From field address, perform the SSP query, described in step
1. The result of this evaluation is expected to override the reputation
assessment of the actual signer.


s/different from the domain name/different from the/  if you want to


If I did the specified edit properly, that produces:

When a receiver gets a message that is signed, but
which has the signature's "i=" that is different from the
in the (first) From field address...

I assume the point of the edit is to include full addresses.

On reading the result, I'm inclined to suggest "...signature's i= value that
is different..."



match the current SSP draft.  Where did you get the second sentence? The
term "reputation" occurs exactly once in the draft and it isn't saying
this.


Do envision a reasonable scenario where a receiver has adopted SSP and
conforms to it, but does not have the stated sender enforcement request
override the reputation assessment for a signer?  Note that this either
implies or explicitly violates the request of the SSP domain owner.

Could you provide some examples of such scenarios?


SSP is motivated by a desire on the part of message senders, to inform 
message recipients about constraints on the senders' practices.  The 
premise is that receivers with this additional information will be able

to reject a class of mail that is not legitimate. The mechanism is
approximate, in that a legitimate message might begin with a legitimate
signature, but then have the signature get broken during transit.  When
SSP is used, such messages will be treated by the recipient as suspect.


Rejecting messages is just one possible result.  Placing that first 
emphasizes it, in my opinion inappropriately.  What you fail to mention


The section 2.9 text "a Verifier may decide the message should be accepted on
the basis of other information beyond the scope of this document" at first
seems to support your view, but I think a bit of reflection changes that.

While the text explicit notes that rejection is not the only action that can
be taken, the language actually assumes that it will be typical and that an
outcome other than rejection is, frankly, exceptional.

Some of this depends on just how pragmatic and honest we want to be in stating
what the goals of SSP publishers actually are and what the likely practices of
receivers who adopt SSP will be.

If the summary is to achieve the goal of meaningfully help others to
understand the "nature" off SSP then the text needs to have more than
mathematical purity of diplomatically and formally careful specification
language.  It needs to broach issues of motives and expected uses.


is that there are domains who would l

Re: [ietf-dkim] Tracing SSP's paradigm change

[Arvel Hathcock]

> Well, I reviewed the archives for the period during which i= was added
> and could not find discussion of it.  So I'm glad to hear you've done
> a more thorough review.  This means that you can point me to the
> archives of the working group consideration of the issue?

I wouldn't waste any more time chasing this.  Even if no such archive 
exists, what is that but evidence that this issue is idiosyncratic or 
has been deemed utterly unremarkable?


Also, let us reject the title of this thread and thereby strip away it's 
illegitimate claim of "paradigm change".  The burden of proof is on 
those who assert that such a change has occurred.  It certainly has not.


The notion that "DKIM-Base is for signed mail while DKIM-SSP is for 
unsigned (only)" has never been thinking in accord with any draft of SSP 
which I remember reading or implementing.  And it's clearly out of step 
with where we are today.


Arvel


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

[ietf-dkim] Re: Issue #1512: Re: making SSP useless in one short step

[Michael Thomas]

Jim Fenton wrote:

[Adding issue number to the subject so we know what we're talking about.]

Michael Thomas wrote:
  

mtcc.com SSP: p=strict;

From: [EMAIL PROTECTED]
DKIM-Signature: [EMAIL PROTECTED];
Subject: phish is yummy

If you're going to say that this signature qualifies as acceptable for
the above SSP record, then you have created a security hole that renders
SSP utterly useless.




With p=strict and no other Originator Signature present, the message is
indeed Suspicious.  If the verifier is following the spec, it is always
Suspicious.

You may have intended to present the example with p=all.  In this case,
the message may or may not be Suspicious, at the discretion of the
verifier.  This is what is meant by "Verifier acceptable".  If the
verifier knows something good about the signer (maybe it's ietf.org
instead of hacker.com), it might decide that the message is not
Suspicious.  It's up to the verifier.
  


I actually meant it the way I wrote it because that's what Dave seems
to be saying an acceptable state of affairs for either strict or all. My
point is that it not acceptable for SSP qua SSP, though a receiver can 
decide

to trust hacker.com's signature in *both* cases and there's nothing that
we can or should do about that.

Which is a long winded version of that third party signatures are completely
orthogonal to SSP. "All" should just mean "I sign all of my mail". No
more, no less.

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

Re: [ietf-dkim] Draft summary of SSP functionality

[Jim Fenton]

Perhaps we need a better introduction in the specification, then.  The
text below isn't worded from the standpoint of a document introduction,
but it might help fill the vacuum created when the normative text in the
introduction gets moved elsewhere.

Comments below...

Dave Crocker wrote:
> Folks,
>
> If non-participants are to be asked about the potential use of SSP, it
> helps to have a description of it that is concise, complete and for
> which there is reasonable consensus about the content.  Simply handing
> non-participants a point to the specification is useless for all but
> the most technical and dedicated.
>
> To that end, I've pulled some text from my review, as a candidate. 
> It's intent is not to judge SSP but to describe its salient basis and
> functions. In other words, what is it, rather than is it good, bad or
> broken?
>
> Obviously I have no expectation that my writing is entirely without
> judgment, so I would like to get some working group review of the
> text, to see if we can agree on text that is factual and useful:
>
>
>
>
> The IETF's DKIM working group has followed its specification of a base
> method for associating a responsible identity to an email, via
> cryptographic signing, with a draft, titled DKIM Sender Signing
> Practices (SSP).  The SSP specification describes itself as defining a
> mechanism "senders may use to advertise how they sign their outgoing
> mail, and how verifiers should access and interpret those results."
> That is, SSP permits potential DKIM signers to publish statements
> about how they use DKIM, and also to publish directions for DKIM
> validators (receivers) on how they are to handle a class of received
> messages.
>
> The SSP mechanism has a potential signer -- that is, the owner of a
> domain name -- publish an SSP-specific DNS TXT record, in an
> SSP-specific branch under the domain name.  On the receive-side, the
> domain name under which the DNS query is made is taken from the
> rfc2822.From  portion of an address, in a received message.

It's not really an SSP-specific branch, but an SSP-specific label under
the DKIM key management branch.

>
> By associating an organization's verifiable identity to a message, the
> reputation of that organization can then be used by a message receiving
> engine, for determining message handling, such as whether to deliver
> the message to the designated recipient.  This is what DKIM Base permits.
>
> By contrast, SSP seeks to detect misbehaviors, specifically related to
> unauthorized use of a domain in an RFC2822.From field . 
> SSP does not seek to deal with other identity fraud, such as in the
> RFC2822.From , the Subject field, or in the message
> body, or any use of "cousin" domains that can be confused with a
> target domain.

That's one way to look at it.  I would describe it, instead of "detect
misbehaviors, ..." as "provide guidance to DKIM verifiers regarding
messages lacking a valid DKIM signature on behalf of the message's author."
>
> The current SSP draft provides for two basic modes of use:
>
>1. Unsigned message.  When a receiver gets a message that is not
> signed, they can query the DNS for an SSP record, associated with the
> domain name in the (first) rfc2822.From field header address.  If that
> record states that all mail with that domain name in the From field is
> signed, then the recipient can assume that the message is problematic.
>
>2. Signed message.  When a receiver gets a message that is signed,
> but which has the signature's "i=" that is different from the domain
> name in the (first) From field address, perform the SSP query,
> described in step 1. The result of this evaluation is expected to
> override the reputation assessment of the actual signer.

s/different from the domain name/different from the/  if you want to
match the current SSP draft.  Where did you get the second sentence? 
The term "reputation" occurs exactly once in the draft and it isn't
saying this.

>
> SSP is motivated by a desire on the part of message senders, to inform
> message recipients about constraints on the senders' practices.  The
> premise is that receivers with this additional information will be
> able to reject a class of mail that is not legitimate. The mechanism
> is approximate, in that a legitimate message might begin with a
> legitimate signature, but then have the signature get broken during
> transit.  When SSP is used, such messages will be treated by the
> recipient as suspect.

Rejecting messages is just one possible result.  Placing that first
emphasizes it, in my opinion inappropriately.  What you fail to mention
is that there are domains who would like precisely this to happen:  if
their message gets broken, even inadvertently in transit, they want it
rejected.
>
> Given that adoption of a new mechanism, like DKIM's base signing,
> takes many years, it should be assumed that use of SSP will almost
> always result in a failed DNS query, for every message with a new
> (un

Re: [ietf-dkim] ISSUE 1519: SSP-01 Unnecessary constraint on i= when asserting "strict"// edits

[Jim Fenton]

Douglas Otis wrote:
> dkim-ssp-01 edits to avoid unnecessary constraint on i=
>
> 
> Was:
> 1. Introduction
> ...
>In the absence of a valid DKIM signature on behalf of the "From"
>address [RFC2822],..
>
> Change to:
>   In the absence of a valid DKIM signature on behalf of the "From"
>   address [RFC2822] domain,..

It has been pointed out that the Introduction is not the place for
normative language, but wherever this sentence ends up, it would tell
the verifier to skip the SSP check on the basis of a domain match
alone.  This means that someone signing with a key that has a g=
constraint could tell the verifier to bypass the SSP check for any
message in the domain, not just the From address[es] that the signer is
authorized to sign for.  This would create a new security vulnerability.

>
> 
>
> Was:
> 2.8. Originator Signature
>
>An "Originator Signature" is any Valid Signature where the signing
>address (listed in the "i=" tag if present, otherwise its default
>value, consisting of the null address, representing an unknown user,
>followed by "@", followed by the value of the "d=" tag) matches the
>Originator Address.  If the signing address does not include a local-
>part, then only the domains must match; otherwise, the two addresses
>must be identical.
>
> Change to:
> 2.8. Originator Signature
>
>An "Originator Signature" is any Valid Signature where the d= tag
>matches or is within the Originator Domain (the domain of the first
>From email-address).  In addition, when a key is restricted by its
>g= tag, the signature MUST BE valid for the Originator Address (the
>first From email-address).

As far as I can tell, the only difference between these statements
occurs when the signer has an unrestricted key and decides to apply a
local-part to the i= tag even though it is not required.  I don't think
this is an important case to consider; they could easily apply the From
address's local-part if they want.

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

[ietf-dkim] Issue #1512: Re: making SSP useless in one short step

[Jim Fenton]

[Adding issue number to the subject so we know what we're talking about.]

Michael Thomas wrote:
>
> mtcc.com SSP: p=strict;
>
> From: [EMAIL PROTECTED]
> DKIM-Signature: [EMAIL PROTECTED];
> Subject: phish is yummy
>
> If you're going to say that this signature qualifies as acceptable for
> the above SSP record, then you have created a security hole that renders
> SSP utterly useless.
>
>
With p=strict and no other Originator Signature present, the message is
indeed Suspicious.  If the verifier is following the spec, it is always
Suspicious.

You may have intended to present the example with p=all.  In this case,
the message may or may not be Suspicious, at the discretion of the
verifier.  This is what is meant by "Verifier acceptable".  If the
verifier knows something good about the signer (maybe it's ietf.org
instead of hacker.com), it might decide that the message is not
Suspicious.  It's up to the verifier.

So there are three cases:

p=unknown => message is not Suspicious
p=all => message is not Suspicious if an Originator Signature is present
or another signature is present that is acceptable to the verifier
p=strict => message is Suspicious unless an Originator Signature is present

It might be argued that we should allow the verifier to make a decision
based on other criteria in the p=all case.  I see SSP as an adjunct to
DKIM, and not other mechanisms, and the [not] Suspicious result as an
input to later stages of filtering, but I'd be interested in the group's
opinion on that.

-Jim


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

Re: [ietf-dkim] ISSUE 1519: SSP-01 Unnecessary constraint on i= when asserting "strict"

[Jim Fenton]

There seems to be quite a bit here I don't understand.

Douglas Otis wrote:
> A domain wishing to protect their transactional mail may decide to
> publish "strict" to limit the acceptance of "non-compliant" messages.
>
> Compliance now requires the i= to not include a localpart, or for the
> localpart to match with the From header.

"Compliance" must be equivalent to "being not Suspicious".

>
> This unnecessary requirement may produce "false positive" detections
> of bad acts when signing domain uses i= as intended in the base draft,
> which is to indicate on who's behalf the message was signed.

I need an example to understand what would constitute a false positive.

>
> Options to mitigate "false positives" would be to:
>
>  1- Exclude the i= parameter
>  2- Add another signature specifically signing the From as well
>
> Option 1 eliminates _any_ significance the i= parameter could have and
> makes signature ambiguous.
>
> Option 2 reduces significance of the i= parameters when the From
> header is signed "because it was there".

All DKIM signatures MUST sign the From header field (RFC 4871, section 5.4).
>
>
> A requirement to have verifiers enforce which headers a domain should
> be signing seems over-reaching.  However, in the case of the g=
> restricted keys, there is already an expectation that verifiers will
> qualify valid localparts.

There is an expectation in the sense that the local-part of the signing
address MUST match the g= value.
>
> Solution:
>
> When the "strict" policy is asserted, limit "restricted" keys to being
> compliant only when signing the From header.

Again confused.  The From header field is always signed.

If you can describe the proposal in more precise terms, I'd be in a
better position to respond.

-Jim

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

[ietf-dkim] [psg.com #1519] [Comment] SSP-01 Unnecessary constraint on i= when asserting "strict" // correction

[Douglas Otis]

Parent/Child error:
"within" should be "a parent of".

Edit correction:
2.8. Originator Signature

 An "Originator Signature" is any Valid Signature where the d= tag
 matches or is [a parent of] the Originator Domain (the domain of the
 first From email-address).  In addition, when a key is restricted by
 its g= tag, the signature MUST BE valid for the Originator Address
 (the first From email-address).
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Re: making SSP useless in one short step

[Michael Thomas]

John Levine wrote:

From: [EMAIL PROTECTED]
DKIM-Signature: [EMAIL PROTECTED];
Subject: phish is yummy

If you're going to say that this signature qualifies as acceptable for
the above SSP record, then you have created a security hole that renders
SSP utterly useless.


It rather depends on my opinion of hacker.com.  I agree that
signatures from unknown domains are uninteresting, something that's
the same with or without SSP.  But if I have reason to trust
hacker.com, I'm done, I'm not going to check anything else.


  Yes, but that should be outside of the scope of SSP. I think
  we are agreeing though even if it pains both of us :)

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

Re: [ietf-dkim] making SSP useless in one short step

[Scott Kitterman]

On Wednesday 05 December 2007 13:46, Michael Thomas wrote:
> [Who is apps-review, and why are they rejecting messages? If this is
>   intended as an apps area review where only Dave gets to post, that's
>   a problem.]
>
> Dave Crocker wrote:
> >>o  A "Verifier" is the agent that verifies a message by checking the
> >>   actual signature against the message itself and the public key
> >>   published by the Alleged Signer.  The Verifier also looks up the
> >>   Sender Signing Practices published by the domain of the Originator
> >>   Address if the message is not correctly signed by the Alleged
> >>   Originator.
> >
> > Again:  SSP is now not restricted to unsigned messages.  It applies also
> > to a
> > potentially very large class of signed messages.  In effect, SSP now
> > appears
> > to attempting to emulate  SPF strictures of correlation among identity
> > fields.
>
>If SSP is going to have any utility whatsoever, it cannot be defeated
>by the mere act of signing a message from any random domain. Period.
>That would be completely and utterly useless, and a complete joke to
>create such a specification. When a domain says that it signs all of
>its mail, it means just that. It doesn't mean that maybe on every
>third thursday that some other domain might sign the mail. It means
>that the domain in question signs its own mail with its own
>signatures. That means that you have to know which domain a piece of
>mail is purporting to be from. The address chosen in the requirements
>in RFC5016 is the rfc2822.From address. This was not controversial.
>Why we're rehash that non-argument now is beyond me.

+1.  It's pretty obvious that it has to be this way.

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

Re: [ietf-dkim] Re: making SSP useless in one short step

[Scott Kitterman]

On Wednesday 05 December 2007 15:54, Dave Crocker wrote:
> Michael Thomas wrote:
> >> There is quite a lot implied by saying "defeated".
> >
> > Defeated. Utterly. Trivially. It would be the equivalent to the
> > IETF trying to standardize an 8 bit encryption scheme.
>
> Unfortunately, SSP is defeated out of the box, even with all of its
> specified features intact.
>
> I publish a strict record.  I therefore want receivers to take note of all
> mail that has my domain in the From field but is not signed by that domain.
>
> On day one, for all intents and purposes, no recipient server on the
> Internet is going to make the query for this, and hence the mechanism is
> "defeated".
>
So all protocols that involve any kind of network exchange to work are 
defeated and useless and the IETF should stop writing them?  That's the 
logical conclusion one can draw from this perspective.  It's equally true of 
all protocols the day they are minted.

It's been clear you've had your mind made up about the utility of SSP since 
before the working group started.  It'd be nice if you tried to be 
constructive.

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

Re: [ietf-dkim] ISSUE: SSP-01 Unnecessary constraint on i= when asserting "strict"

[Scott Kitterman]

On Wednesday 05 December 2007 13:36, Douglas Otis wrote:
> A domain wishing to protect their transactional mail may decide to
> publish "strict" to limit the acceptance of "non-compliant" messages.
>
> Compliance now requires the i= to not include a localpart, or for the
> localpart to match with the From header.
>
> This unnecessary requirement may produce "false positive" detections
> of bad acts when signing domain uses i= as intended in the base draft,
> which is to indicate on who's behalf the message was signed.
>
> Options to mitigate "false positives" would be to:
>
>   1- Exclude the i= parameter
>   2- Add another signature specifically signing the From as well

Since the signer is controlled by the same entity, option 3 would be don't 
send messages where i= doesn't match what's in From.  

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

Re: [ietf-dkim] Draft summary of SSP functionality

[Scott Kitterman]

On Wednesday 05 December 2007 13:09, Dave Crocker wrote:
> Folks,
>
> If non-participants are to be asked about the potential use of SSP, it
> helps to have a description of it that is concise, complete and for which
> there is reasonable consensus about the content.  Simply handing
> non-participants a point to the specification is useless for all but the
> most technical and dedicated.
>
Since you've already stated you think SSP is useless, please don't muddy the 
waters with writing more stuff for us to review that serves no purpose other 
than disctraction.

Let's focus on getting the spec done and sweat the marketing later.

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

Re: [ietf-dkim] Mailing lists as 2822-Sender (was: Responsibility vs. Validity)

[Hector Santos]

Dave Crocker wrote:



Tony Finch wrote:

 "The "Sender:" field specifies the
   mailbox of the agent responsible for the actual transmission of the
   message."


Popular MTA implementations (Sendmail, Postfix) do not implement the
Sender: header the way 822 and 2822 suggest,


How would you describe what they do do?


Well, if SendMail/PostFix is operating like the rest of the world... If 
missing, a SMTP receiver MIGHT do:


   Sender: <-- x821.MailFrom

in the same vain many SMTP receivers will fill in the missing 822 
required fields.


   FROM:  <<-- x821.MailFrom
   To:<<-- x821.RcptTo

and they MUST do this if they want to SUPPORT the presentation layers.

But sender is not a given because it is not a 822 required field. In 
fact, I seem to recall, it was only in recent years that we even 
bothered with Sender in our mailers.


Only a few sites will reject such empty headers in the DATA block. Off 
hand, I know of one, HOTMAIL.COM and they only started to reject mail 
without the headers when SENDER-ID support was added to HOTMAIL.COM.


--
Sincerely

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] Re: making SSP useless in one short step

[John Levine]

>From: [EMAIL PROTECTED]
>DKIM-Signature: [EMAIL PROTECTED];
>Subject: phish is yummy
>
>If you're going to say that this signature qualifies as acceptable for
>the above SSP record, then you have created a security hole that renders
>SSP utterly useless.

It rather depends on my opinion of hacker.com.  I agree that
signatures from unknown domains are uninteresting, something that's
the same with or without SSP.  But if I have reason to trust
hacker.com, I'm done, I'm not going to check anything else.

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

Re: [ietf-dkim] Mailing lists as 2822-Sender (was: Responsibility vs. Validity)

[Hector Santos]

Ha! Yammer-To-Author! Hilarious!

Thanks for making my day. :-)

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

Steve Dorner wrote:


At 9:14 AM -0800 12/5/07, Dave Crocker wrote:
Frankly I think [Resent-] should be deprecated, because it causes so 
much trouble.


Along with From, Sender, and Reply-To.  :-)

I see no straightening out of the tangle we are in regarding all these 
fields.  We keep trying to tweak the rules, tweak compliance, etc, so 
that we get a system where everybody can conveniently do what they want, 
and I don't think it's possible.


Frankly, I think we either just give it up and live with it, or define 
entirely new fields with narrow, specific meanings that enable agents to 
put together the operations we like.


Eg, deprecate (softly and over time) Sender, and replace with:

Original-Injector:
List-Injector:
Translated-Injector:
Fuelled-Injector:
...

Deprecate Reply-To:, and replace with:

Yammer-To-Author:
Yammer-To-List:
Yammer-To-Mother-In-Law-of-Cousin-Of-Mailing-List-Owner:
...

We have to get very specific about labelling who did what to whom if we 
hope to have a situation that is satisfying to our sense of the right 
progression of the universe.


Some of these fields probably would need to be multiple, and even 
order-maintained.  They might need syntax above and beyond what is 
currently allowed for recipient fields.  There would probably be a fair 
number of them.


But there's so much useless junk flying around in email now, several 
dozen more addressing fields would hardly be noticed.  :-)


My guess is that "living with it" is going to win.







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

Re: [ietf-dkim] Mailing lists as 2822-Sender (was: Responsibility vs. Validity)

[Dave Crocker]

Tony Finch wrote:

 "The "Sender:" field specifies the
   mailbox of the agent responsible for the actual transmission of the
   message."


Popular MTA implementations (Sendmail, Postfix) do not implement the
Sender: header the way 822 and 2822 suggest,


How would you describe what they do do?

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] Re: making SSP useless in one short step

[Dave Crocker]

Michael Thomas wrote:

There is quite a lot implied by saying "defeated".


Defeated. Utterly. Trivially. It would be the equivalent to the
IETF trying to standardize an 8 bit encryption scheme.



Unfortunately, SSP is defeated out of the box, even with all of its specified 
features intact.


I publish a strict record.  I therefore want receivers to take note of all 
mail that has my domain in the From field but is not signed by that domain.


On day one, for all intents and purposes, no recipient server on the Internet 
is going to make the query for this, and hence the mechanism is "defeated".


At very best, it will be quite a few years (5-10 years seems typical, for 
popular enhancements to email) before a large number of receiving servers make 
the query, and there will remain a substantial percentage of receivers failing 
to query essentially forever.


So the strict requirements of the strict mode have to be considered in the 
face of massive non-adoption, pretty much forever.


Contrast this with the view that this feature is quite useful among a small, 
cooperative collection of services that have agreed to use it.


While this is not Internet scale -- by which I mean broad adoption with 
massive breadth of use and no prior arrangement among the users -- it is a 
perfectly credible capability, albeit one that needs to be treated as a 
specialized facility, rather than a general one.


d/
--

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

[ietf-dkim] OT: apps-review (was: making SSP useless in one short step)

[Frank Ellermann]

Michael Thomas wrote:

> Who is apps-review, and why are they rejecting messages?



Like GenArt, only apps.  

> If this is intended as an apps area review where only 
> Dave gets to post, that's a problem.

Sometimes I read the GenArt list (it's on GMane) but I
think I've no business to post there.  A tool for the
general area director.  And apps-review is a tool for
one or both apps ADs.  

 Frank

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

Re: [ietf-dkim] Re: making SSP useless in one short step

[Hector Santos]

Michael Thomas wrote:

>> Dave Crocker wrote:
>> Because the mechanism is problematic and the choice of From is
>> problematic.
>
> Problematic? It's central, and well documented in RFC5016.

It unfortunate the people you acknowledged in RFC 5016 as providing 
substantial review, never really did agreed or never really thoroughly 
understand it.


So much time wasted.

Nearly 2+ years ago the original SSP-01, by far, the clearer functional 
specification, even a 6 year old can understand, biggest hole was the 
3rd party issue. Today, the same thing.


IMV, I should probably just focus on making DKIM/SSP a 1st party 
signature system as this is the only common ground nearly everyone, if 
not all, agrees with. And if some one wishes to propose a 3rd party 
signature after the 1st party system in in practice, it can then be 
revisited.


We need to provide the highest benefit possible for DKIM/SSP so that the 
market can gain the confidence in implementing and adopting it, relying 
on it - confidently with no ambiguity.  That can only be done with a 1st 
party signature system in place - first.  The 3rd party stuff is far too 
complicated. Too many loop holes, too many security threats, too much 
trouble that will bring down DKIM/SSP with it.


Of course, my opinion.

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

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

Re: [ietf-dkim] Mailing lists as 2822-Sender (was: Responsibility vs. Validity)

[Steve Dorner]

At 9:14 AM -0800 12/5/07, Dave Crocker wrote:
Frankly I think [Resent-] should be deprecated, because it causes so 
much trouble.


Along with From, Sender, and Reply-To.  :-)

I see no straightening out of the tangle we are in regarding all 
these fields.  We keep trying to tweak the rules, tweak compliance, 
etc, so that we get a system where everybody can conveniently do what 
they want, and I don't think it's possible.


Frankly, I think we either just give it up and live with it, or 
define entirely new fields with narrow, specific meanings that enable 
agents to put together the operations we like.


Eg, deprecate (softly and over time) Sender, and replace with:

Original-Injector:
List-Injector:
Translated-Injector:
Fuelled-Injector:
...

Deprecate Reply-To:, and replace with:

Yammer-To-Author:
Yammer-To-List:
Yammer-To-Mother-In-Law-of-Cousin-Of-Mailing-List-Owner:
...

We have to get very specific about labelling who did what to whom if 
we hope to have a situation that is satisfying to our sense of the 
right progression of the universe.


Some of these fields probably would need to be multiple, and even 
order-maintained.  They might need syntax above and beyond what is 
currently allowed for recipient fields.  There would probably be a 
fair number of them.


But there's so much useless junk flying around in email now, several 
dozen more addressing fields would hardly be noticed.  :-)


My guess is that "living with it" is going to win.

[ietf-dkim] ISSUE: SSP-01 Unnecessary constraint on i= when asserting "strict"// edits

[Douglas Otis]

dkim-ssp-01 edits to avoid unnecessary constraint on i=


Was:
1. Introduction
...
   In the absence of a valid DKIM signature on behalf of the "From"
   address [RFC2822],..

Change to:
  In the absence of a valid DKIM signature on behalf of the "From"
  address [RFC2822] domain,..



Was:
2.8. Originator Signature

   An "Originator Signature" is any Valid Signature where the signing
   address (listed in the "i=" tag if present, otherwise its default
   value, consisting of the null address, representing an unknown user,
   followed by "@", followed by the value of the "d=" tag) matches the
   Originator Address.  If the signing address does not include a  
local-

   part, then only the domains must match; otherwise, the two addresses
   must be identical.

Change to:
2.8. Originator Signature

   An "Originator Signature" is any Valid Signature where the d= tag
   matches or is within the Originator Domain (the domain of the first
   From email-address).  In addition, when a key is restricted by its
   g= tag, the signature MUST BE valid for the Originator Address (the
   first From email-address).


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

Re: [ietf-dkim] Mailing lists as 2822-Sender (was: Responsibility vs. Validity)

[Tony Finch]

On Tue, 4 Dec 2007, [EMAIL PROTECTED] wrote:
>
> I don't recall anyone considering using Resent- fields for this until
> just now, but I could easily have missed it

I think it's a cute idea, but Resent- fields are an interop nightmare
because the 822 specification is too weak to work in general (e.g. a
sequence of multiple resendings) and the 2822 specification is not
entirely compatible and not widely implemented.

Tony.
-- 
f.a.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
SOUTHEAST ICELAND: CYCLONIC 5 TO 7, OCCASIONALLY GALE 8 AT FIRST IN SOUTH.
ROUGH OR VERY ROUGH. SQUALLY SHOWERS. MODERATE OR GOOD.

Re: [ietf-dkim] Mailing lists as 2822-Sender (was: Responsibility vs. Validity)

[Tony Finch]

On Wed, 5 Dec 2007, Dave Crocker wrote:
>
> Well, let's get back to first princples.  RFC 2822 3.6.2:
>
>  "The "Sender:" field specifies the
>mailbox of the agent responsible for the actual transmission of the
>message."

Popular MTA implementations (Sendmail, Postfix) do not implement the
Sender: header the way 822 and 2822 suggest, so even before you consider
mailing list managers you need to be very careful about RFC lawyering.

Microsoft MUAs present message headers in a way that works best if normal
messages do not have a Sender: field and mailing list messages do have one.

Tony.
-- 
f.a.n.finch  <[EMAIL PROTECTED]>  http://dotat.at/
LUNDY FASTNET IRISH SEA SHANNON: WEST OR SOUTHWEST 6 TO GALE 8, PERHAPS SEVERE
GALE 9 LATER. HIGH OR VERY HIGH IN FASTNET AND SHANNON, ROUGH OR VERY ROUGH IN
LUNDY AND IRISH SEA. RAIN OR SQUALLY SHOWERS. MODERATE OR GOOD, OCCASIONALLY
POOR.
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Tracing SSP's paradigm change

[Dave Crocker]

Michael Thomas wrote:

Scott Kitterman wrote:

I seem to have missed the discussion where anyone but you is suprised by
this.  If one is going to distinguish between originator signatures and
others, then this requirement pretty obviously follows.


+1, and I had the dubious distinction of having to go through the thousands
of mail messages. I can't imagine that there is anything new under the sun
on this topic.



Well, I reviewed the archives for the period during which i= was added and 
could not find discussion of it.  So I'm glad to hear you've done a more 
thorough review.  This means that you can point me to the archives of the 
working group consideration of the issue?


d/


--

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

[ietf-dkim] Re: making SSP useless in one short step

[Michael Thomas]

Dave Crocker wrote:
Again:  SSP is now not restricted to unsigned messages.  It applies 
also to a potentially very large class of signed messages.  In 
effect, SSP now
 appears to attempting to emulate  SPF strictures of correlation 
among identity fields.


If SSP is going to have any utility whatsoever, it cannot be defeated 
by the mere act of signing a message from any random domain.


There is quite a lot implied by saying "defeated".


Defeated. Utterly. Trivially. It would be the equivalent to the
IETF trying to standardize an 8 bit encryption scheme.

Perhaps you could explain the operational, threat and protection models 
that

substantiates your assessment.  I am pretty sure it has not been clearly
documented.  It seems pretty clear to me that the models require a 
homogeneous

and reliable end-to-end service, with considerable cooperation among all
senders and receivers, with no signature breakage.


mtcc.com SSP: p=strict;

From: [EMAIL PROTECTED]
DKIM-Signature: [EMAIL PROTECTED];
Subject: phish is yummy

If you're going to say that this signature qualifies as acceptable for
the above SSP record, then you have created a security hole that renders
SSP utterly useless.

In any event, it is worth commenting on the reasons that the reputation 
of the

random domain that does sign are rendered irrelevant.  (I asked this before
but have not seen a response.)


Useless to whom? The SSP protocol? Yes, it's completely useless as
that signature doesn't emanate from that domain. If you're talking
about a receiver in general, that is completely out of scope of SSP;
the receiver is entitled to attach as much (ir)relevance to that
signature as it sees fit.


Period. That
would be completely and utterly useless, and a complete joke to create 
such

 a specification. When a domain says that it signs all of its mail, it
means just that. It doesn't mean that maybe on every third thursday that
some other domain might sign the mail. It means that the domain in 
question
 signs its own mail with its own signatures. That means that you have 
to know which domain a piece of mail is purporting to be from. The 
address chosen in the requirements in RFC5016 is the rfc2822.From 
address. This was

 not controversial. Why we're rehash that non-argument now is beyond me.


Because the mechanism is problematic and the choice of From is problematic.


Problematic? It's central, and well documented in RFC5016.

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

Re: [ietf-dkim] making SSP useless in one short step

[Michael Thomas]

John Levine wrote:

  If SSP is going to have any utility whatsoever, it cannot be defeated
  by the mere act of signing a message from any random domain. Period.


Well, OK.  That sounds like a request to remove the language about
Verifier Acceptable Third-Party Signatures, since the sender has no
idea what signing domains the verifier would consider acceptable.
I'll be happy to send in an issue request referring to the specific
sections in the draft.


  Absolutely. That is, in fact, what issue 1512 is about. Any text
  trying to say what receivers do with non-first party signatures
  should be removed as out of scope, IMO.

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

Re: [ietf-dkim] making SSP useless in one short step

[John Levine]

>   If SSP is going to have any utility whatsoever, it cannot be defeated
>   by the mere act of signing a message from any random domain. Period.

Well, OK.  That sounds like a request to remove the language about
Verifier Acceptable Third-Party Signatures, since the sender has no
idea what signing domains the verifier would consider acceptable.
I'll be happy to send in an issue request referring to the specific
sections in the draft.

R's,
John

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

Re: [ietf-dkim] ISSUE: SSP-01 Unnecessary constraint on i= when asserting "strict"

[Eliot Lear]

Doug,

Thank you.

Now Issue 1519.

Eliot

Douglas Otis wrote:
> A domain wishing to protect their transactional mail may decide to
> publish "strict" to limit the acceptance of "non-compliant" messages.
>
> Compliance now requires the i= to not include a localpart, or for the
> localpart to match with the From header.
>
> This unnecessary requirement may produce "false positive" detections
> of bad acts when signing domain uses i= as intended in the base draft,
> which is to indicate on who's behalf the message was signed.
>
> Options to mitigate "false positives" would be to:
>
>  1- Exclude the i= parameter
>  2- Add another signature specifically signing the From as well
>
> Option 1 eliminates _any_ significance the i= parameter could have and
> makes signature ambiguous.
>
> Option 2 reduces significance of the i= parameters when the From
> header is signed "because it was there".
>
>
> A requirement to have verifiers enforce which headers a domain should
> be signing seems over-reaching.  However, in the case of the g=
> restricted keys, there is already an expectation that verifiers will
> qualify valid localparts.
>
> Solution:
>
> When the "strict" policy is asserted, limit "restricted" keys to being
> compliant only when signing the From header.
>
> This would not change restrictions already imposed on "restricted"
> keys, but would allow the i= parameter to be used as intended by the
> base draft, or in _any_ manner desired by the signer.
>
> This minor modification would allow strict polices to:
>
>  a- protect transactional messages
>
>  b- allow the domain to run a mailing list, for example
>
>  c- allow unambiguous signing of the domain's messages
>
>  d- allow the identity expressed in the i= parameter to be opaque when
> desired
>
> -Doug
>
> ___
> NOTE WELL: This list operates according
> tohttp://mipassoc.org/dkim/ietf-list-rules.html
>
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

[ietf-dkim] Re: making SSP useless in one short step

[Dave Crocker]

Mike,

Michael Thomas wrote:
[Who is apps-review, and why are they rejecting messages? If this is 
intended as an apps area review where only Dave gets to post, that's a 
problem.]


Apps review is an existing mechanism.  I participate in it.  Others
participate in it.  I used it exactly the same way I have used it for previous
reviews I have done, except cc'ing the wg rather than the authors.  I didn't
create the mechanism.  I used it specifically because it is an established
capability.

That said, I think the list I posted to is used to record the review, rather
than for on-going discussion, so I have removed it from the cc list.

If you dislike the mechanism, feel free to direct comments about it to the
Apps area directors.


Again:  SSP is now not restricted to unsigned messages.  It applies also 
to a potentially very large class of signed messages.  In effect, SSP now
 appears to attempting to emulate  SPF strictures of correlation among 
identity fields.


If SSP is going to have any utility whatsoever, it cannot be defeated by 
the mere act of signing a message from any random domain.


There is quite a lot implied by saying "defeated".

Perhaps you could explain the operational, threat and protection models that
substantiates your assessment.  I am pretty sure it has not been clearly
documented.  It seems pretty clear to me that the models require a homogeneous
and reliable end-to-end service, with considerable cooperation among all
senders and receivers, with no signature breakage.

In any event, it is worth commenting on the reasons that the reputation of the
random domain that does sign are rendered irrelevant.  (I asked this before
but have not seen a response.)



Period. That

would be completely and utterly useless, and a complete joke to create such
 a specification. When a domain says that it signs all of its mail, it
means just that. It doesn't mean that maybe on every third thursday that
some other domain might sign the mail. It means that the domain in question
 signs its own mail with its own signatures. That means that you have to 
know which domain a piece of mail is purporting to be from. The address 
chosen in the requirements in RFC5016 is the rfc2822.From address. This was

 not controversial. Why we're rehash that non-argument now is beyond me.


Because the mechanism is problematic and the choice of From is problematic.


Question:  Is DKIM for transit validation or is it for content 
authentication?


This is a false dilemma.


No it is not. In fact it is basic and salient.

Perhaps the difference between the two is not clear to you?

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] Draft summary of SSP functionality

[Steve Atkins]

On Dec 5, 2007, at 10:46 AM, Dave Crocker wrote:

Probably worth distinguishing between the specific assertions that  
the draft current supports, versus the scope of additional  
assertions that could be added to the repertoire.


I don't think the latter - potential extensions - need be mentioned  
at all, as any extensions will be either private use only or will  
require additional standards work.


But there are, I think, twelve assertions that the current SSP draft  
can make. Listing which of those assertions are valid, and what  
message they are intended to communicate to the receiver, and what  
action the receiver might be expected to take on receiving them would  
be useful plain english[1] to create. If the meanings of those  
assertions change in different query scenarios (valid dkim signature  
vs no valid dkim signature, say) then those need to be enumerated too.


That's a useful thing to do in any case, to clarify what everyone  
believes the current draft means, but once it's done I suspect it can  
be converted to the short summary needed for this document.


Cheers,
  Steve

[1] Excluding meaningless or ill-defined terms such as "Suspicious"

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

[ietf-dkim] making SSP useless in one short step

[Michael Thomas]

[Who is apps-review, and why are they rejecting messages? If this is
 intended as an apps area review where only Dave gets to post, that's
 a problem.]

Dave Crocker wrote:

   o  A "Verifier" is the agent that verifies a message by checking the
  actual signature against the message itself and the public key
  published by the Alleged Signer.  The Verifier also looks up the
  Sender Signing Practices published by the domain of the Originator
  Address if the message is not correctly signed by the Alleged
  Originator.


Again:  SSP is now not restricted to unsigned messages.  It applies also 
to a
potentially very large class of signed messages.  In effect, SSP now 
appears
to attempting to emulate  SPF strictures of correlation among identity 
fields.





  If SSP is going to have any utility whatsoever, it cannot be defeated
  by the mere act of signing a message from any random domain. Period.
  That would be completely and utterly useless, and a complete joke to
  create such a specification. When a domain says that it signs all of
  its mail, it means just that. It doesn't mean that maybe on every
  third thursday that some other domain might sign the mail. It means
  that the domain in question signs its own mail with its own
  signatures. That means that you have to know which domain a piece of
  mail is purporting to be from. The address chosen in the requirements
  in RFC5016 is the rfc2822.From address. This was not controversial.
  Why we're rehash that non-argument now is beyond me.

> Question:  Is DKIM for transit validation or is it for content
> authentication?

  This is a false dilemma.

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

[ietf-dkim] ISSUE: SSP-01 Unnecessary constraint on i= when asserting "strict"

[Douglas Otis]

A domain wishing to protect their transactional mail may decide to  
publish "strict" to limit the acceptance of "non-compliant" messages.


Compliance now requires the i= to not include a localpart, or for the  
localpart to match with the From header.


This unnecessary requirement may produce "false positive" detections  
of bad acts when signing domain uses i= as intended in the base draft,  
which is to indicate on who's behalf the message was signed.


Options to mitigate "false positives" would be to:

 1- Exclude the i= parameter
 2- Add another signature specifically signing the From as well

Option 1 eliminates _any_ significance the i= parameter could have and  
makes signature ambiguous.


Option 2 reduces significance of the i= parameters when the From  
header is signed "because it was there".



A requirement to have verifiers enforce which headers a domain should  
be signing seems over-reaching.  However, in the case of the g=  
restricted keys, there is already an expectation that verifiers will  
qualify valid localparts.


Solution:

When the "strict" policy is asserted, limit "restricted" keys to being  
compliant only when signing the From header.


This would not change restrictions already imposed on "restricted"  
keys, but would allow the i= parameter to be used as intended by the  
base draft, or in _any_ manner desired by the signer.


This minor modification would allow strict polices to:

 a- protect transactional messages

 b- allow the domain to run a mailing list, for example

 c- allow unambiguous signing of the domain's messages

 d- allow the identity expressed in the i= parameter to be opaque  
when desired


-Doug

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

Re: [ietf-dkim] Draft summary of SSP functionality

[Dave Crocker]

Michael Thomas wrote:

Override? No. That is the receiver's decision, and SSP is silent on
that. 


So, you are comfortable with the rest of the text?

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] Draft summary of SSP functionality

[Dave Crocker]

Probably worth distinguishing between the specific assertions that the draft 
current supports, versus the scope of additional assertions that could be 
added to the repertoire.


d/


Steve Atkins wrote:


This covers the mechanics of when and how an SSP record may
be queried. I think it also needs mention of what sort of assertions
an SSP record may make, in clear english

For example:



--

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

Re: [ietf-dkim] Mailing lists as 2822-Sender (was: Responsibility vs. Validity)

[Mark Martinec]

> Well, let's get back to first princples.  RFC 2822 3.6.2:
> "The "Sender:" field specifies the mailbox of the agent
> responsible for the actual transmission of the message."

Heretically rejecting the RFC 2822 restriction to one Sender header
field appears to put things back in order and opens up new grounds.

There could be one Sender for the secretary (mailing on behalf of...),
one by a googlemail.com remailer, one by a final mailing list
(each one prepended to a header), and each hop may sign whatever
fields it desires, ragardless of what might next hops be.

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

Re: [ietf-dkim] Draft summary of SSP functionality

[Michael Thomas]

Dave Crocker wrote:
   2. Signed message.  When a receiver gets a message that is signed, 
but which has the signature's "i=" that is different from the domain 
name in the (first) From field address, perform the SSP query, described 
in step 1. The result of this evaluation is expected to override the 
reputation assessment of the actual signer.


Override? No. That is the receiver's decision, and SSP is silent on
that. Some receivers may choose to do that, some may use it as data
in some filtering calculus, others may ignore it altogether. I'm
firmly in the "data" camp which makes it hard for me to understand
why this is such a difficult concept.

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

Re: [ietf-dkim] Draft summary of SSP functionality

[Steve Atkins]

On Dec 5, 2007, at 10:09 AM, Dave Crocker wrote:


Folks,

If non-participants are to be asked about the potential use of SSP,  
it helps to have a description of it that is concise, complete and  
for which there is reasonable consensus about the content.  Simply  
handing non-participants a point to the specification is useless  
for all but the most technical and dedicated.


To that end, I've pulled some text from my review, as a candidate.   
It's intent is not to judge SSP but to describe its salient basis  
and functions. In other words, what is it, rather than is it good,  
bad or broken?


Obviously I have no expectation that my writing is entirely without  
judgment, so I would like to get some working group review of the  
text, to see if we can agree on text that is factual and useful:


This covers the mechanics of when and how an SSP record may
be queried. I think it also needs mention of what sort of assertions
an SSP record may make, in clear english

For example:

"This sender signs all mail with DKIM"

"This sender DKIM signs every third mail they send, except on  
Tuesdays (local time)".


"This sender requires that recipients discard any mail apparently  
from them that does not have a valid DKIM signature"


"This sender signs some mail with DKIM"

That sort of thing.

Cheers,
  Steve






The IETF's DKIM working group has followed its specification of a  
base method for associating a responsible identity to an email, via  
cryptographic signing,
with a draft, titled DKIM Sender Signing Practices (SSP).  The SSP  
specification describes itself as defining a mechanism "senders may  
use to
advertise how they sign their outgoing mail, and how verifiers  
should access
and interpret those results." That is, SSP permits potential DKIM  
signers to
publish statements about how they use DKIM, and also to publish  
directions for
DKIM validators (receivers) on how they are to handle a class of  
received

messages.

The SSP mechanism has a potential signer -- that is, the owner of a  
domain name -- publish an SSP-specific DNS TXT record, in an SSP- 
specific branch under the domain name.  On the receive-side, the  
domain name under which the DNS query is made is taken from the  
rfc2822.From  portion of an address, in a received message.


By associating an organization's verifiable identity to a message, the
reputation of that organization can then be used by a message  
receiving
engine, for determining message handling, such as whether to  
deliver the

message to the designated recipient.  This is what DKIM Base permits.

By contrast, SSP seeks to detect misbehaviors, specifically related to
unauthorized use of a domain in an RFC2822.From field .   
SSP does
not seek to deal with other identity fraud, such as in the  
RFC2822.From
, the Subject field, or in the message body, or any  
use of "cousin" domains that can be confused with a target domain.


The current SSP draft provides for two basic modes of use:

   1. Unsigned message.  When a receiver gets a message that is not  
signed, they can query the DNS for an SSP record, associated with  
the domain name in the (first) rfc2822.From field header address.   
If that record states that all mail with that domain name in the  
From field is signed, then the recipient can assume that the  
message is problematic.


   2. Signed message.  When a receiver gets a message that is  
signed, but which has the signature's "i=" that is different from  
the domain name in the (first) From field address, perform the SSP  
query, described in step 1. The result of this evaluation is  
expected to override the reputation assessment of the actual signer.


SSP is motivated by a desire on the part of message senders, to  
inform message recipients about constraints on the senders'  
practices.  The premise is that receivers with this additional  
information will be able to reject a class of mail that is not  
legitimate. The mechanism is approximate, in that a legitimate  
message might begin with a legitimate signature, but then have the  
signature get broken during transit.  When SSP is used, such  
messages will be treated by the recipient as suspect.


Given that adoption of a new mechanism, like DKIM's base signing,  
takes many years, it should be assumed that use of SSP will almost  
always result in a failed DNS query, for every message with a new  
(un-cached) domain name in the From field.



d/
--

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


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

[ietf-dkim] Draft summary of SSP functionality

[Dave Crocker]

Folks,

If non-participants are to be asked about the potential use of SSP, it helps 
to have a description of it that is concise, complete and for which there is 
reasonable consensus about the content.  Simply handing non-participants a 
point to the specification is useless for all but the most technical and 
dedicated.


To that end, I've pulled some text from my review, as a candidate.  It's 
intent is not to judge SSP but to describe its salient basis and functions. 
In other words, what is it, rather than is it good, bad or broken?


Obviously I have no expectation that my writing is entirely without judgment, 
so I would like to get some working group review of the text, to see if we can 
agree on text that is factual and useful:





The IETF's DKIM working group has followed its specification of a base method 
for associating a responsible identity to an email, via cryptographic signing,
with a draft, titled DKIM Sender Signing Practices (SSP).  The SSP 
specification describes itself as defining a mechanism "senders may use to

advertise how they sign their outgoing mail, and how verifiers should access
and interpret those results." That is, SSP permits potential DKIM signers to
publish statements about how they use DKIM, and also to publish directions for
DKIM validators (receivers) on how they are to handle a class of received
messages.

The SSP mechanism has a potential signer -- that is, the owner of a domain 
name -- publish an SSP-specific DNS TXT record, in an SSP-specific branch 
under the domain name.  On the receive-side, the domain name under which the 
DNS query is made is taken from the rfc2822.From  portion of an 
address, in a received message.


By associating an organization's verifiable identity to a message, the
reputation of that organization can then be used by a message receiving
engine, for determining message handling, such as whether to deliver the
message to the designated recipient.  This is what DKIM Base permits.

By contrast, SSP seeks to detect misbehaviors, specifically related to
unauthorized use of a domain in an RFC2822.From field .  SSP does
not seek to deal with other identity fraud, such as in the RFC2822.From
, the Subject field, or in the message body, or any use of 
"cousin" domains that can be confused with a target domain.


The current SSP draft provides for two basic modes of use:

   1. Unsigned message.  When a receiver gets a message that is not signed, 
they can query the DNS for an SSP record, associated with the domain name in 
the (first) rfc2822.From field header address.  If that record states that all 
mail with that domain name in the From field is signed, then the recipient can 
assume that the message is problematic.


   2. Signed message.  When a receiver gets a message that is signed, but 
which has the signature's "i=" that is different from the domain name in the 
(first) From field address, perform the SSP query, described in step 1. The 
result of this evaluation is expected to override the reputation assessment of 
the actual signer.


SSP is motivated by a desire on the part of message senders, to inform message 
recipients about constraints on the senders' practices.  The premise is that 
receivers with this additional information will be able to reject a class of 
mail that is not legitimate. The mechanism is approximate, in that a 
legitimate message might begin with a legitimate signature, but then have the 
signature get broken during transit.  When SSP is used, such messages will be 
treated by the recipient as suspect.


Given that adoption of a new mechanism, like DKIM's base signing, takes many 
years, it should be assumed that use of SSP will almost always result in a 
failed DNS query, for every message with a new (un-cached) domain name in the 
From field.



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] Mailing lists as 2822-Sender (was: Responsibility vs. Validity)

[Dave Crocker]

Pete Resnick wrote:

On 12/1/07 at 3:30 PM +, John Levine wrote:
RFC 2822 section 3.6.2 describes originator fields.  By my reading it 
is pretty clear that a list should add a Sender: field with the list's 
name since it's the list that's sending the mail.


Uh.not by my reading. Lists add List-* fields (RFC 2369, RFC 2919) 
if they want to indicate something. Fields in the original message 
should be preserved as-is.



Well, let's get back to first princples.  RFC 2822 3.6.2:

 "The "Sender:" field specifies the
   mailbox of the agent responsible for the actual transmission of the
   message."

Is a message fully delivered to a mailing list processor, or is the mailing
list processor merely an odd kind of MTA?  I think there is no controversy
that it is fully delivered, with respect to the mail handling service.  This
means that the mailing list does indeed then "post" the message (back) into
the message stream. In the abstract, then, each posting is for a "new" message.

However...

Perhaps the new posting is really exactly the same as the original message,
except for the addressee list, so that the original Sender field value is
semantically valid?  To me, this has the benefit of being the most relevant
question and the detriment of being pretty subjective.  But then, email
identity strings involve a fair amount of subjectivity already, so it's
probably no major burden to have this one (too.)

Perhaps the mailing list has made significant changes to the message.
Certainly taking multiple messages, to produce a digest, qualifies but I think
other changes do, too.  Where is the limit?  I have no idea.  Since the
mailing list and the original author have a cooperative arrangement, I'm happy
to let them decide.

But the key point is that it means that retaining or replacing the Sender 
value is not a rigid decision.  In other words, it *is* a decision that the 
mailing list operator needs to make explicitly, but the choice entirely 
depends upon the amount of violence that list software does to messages it 
re-posts.


As you (Pete) said in a separate conversation, the underlying question is what 
the Sender address needs to be used for and what will serve that need best.


I don't know that we have much culture around legitimate use of that value, by 
receivers or downstream handlers.



Section 3.6.6 describes resent headers.  One could make a plausible 
argument that a list should add a Resent-Sender: rather than a Sender: 
but it's reasonable to do it either way.


Mailing lists using Resent-* fields gives me the willies. Resent-* 
fields were intended for MUAs resending mail. They weren't intended for 
mailing lists.


Resent was an entirely reasonable idea, but it is one that proved far more
problematic than beneficial.  It works from a simplistic model that seemed 
like a wonderful idea at the time and, IMO, has since shown to merely add 
confusion and complexity rather than benefit.


Frankly I think it should be deprecated, because it causes so much trouble.

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] Mailing lists as 2822-Sender

[Mark Martinec]

Charles Lindsey wrote:
> But if RFC 2822 is followed, then Sender SHOULD NOT be present unles there
> are explicit reasons for doing so. The usual examples given are:
>
> 1. The secretary is sending on behalf of her boss
> 2. There are multiple entries in the From (in which case the Sender MUST
> be included).
>
> Neither of those commonly arises in mailing lists.

It happens with every posting signed by  d=googlemail.com; s=gamma

The From is a home/native address of the author,
the Sender is presumably [EMAIL PROTECTED],
but is replaced by a Sender address of a mailing list.

> Yes, but I would be inclined to modify that by only signing it where it
> was NOT identical to the From (i.e. in the secretary and multiple Froms
> cases above).

The original Sender is not identical to From.

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

Re: [ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01)

[Scott Kitterman]

On Wednesday 05 December 2007 08:53, John Levine wrote:
> >How would doing this work change what verifiers do after the RFC is
> > deployed?
>
> Probably not much, but it will help rein in unwarranted expectations
> by senders that publishing SSP will affect what happens to their mail.
>
It sounds like a lot of work to say the same thing to me.  I don't think 
increasing the quantity and type of ways that the draft says it doesn't 
mandate what receivers will do is a value added use of anyone's time.

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

Re: [ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01)

[John Levine]

>How would doing this work change what verifiers do after the RFC is deployed?

Probably not much, but it will help rein in unwarranted expectations
by senders that publishing SSP will affect what happens to their mail.

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

Re: [ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01)

[Scott Kitterman]

On Wednesday 05 December 2007 08:07, Charles Lindsey wrote:
> On Tue, 04 Dec 2007 18:10:37 -, Jim Fenton <[EMAIL PROTECTED]> wrote:
> > Charles Lindsey wrote:
> >> But it has no business whatsoever making normative statements about
> >> what verifiers are to do, so wording of the form "Verifiers MUST" is
> >> quite out pf place - that is BCP material.
> >
> > Somehow, we need to tell verifiers what they need to do in order to
> > implement this specification.  Nobody is saying that verifiers MUST
> > implement SSP at all, but rather that if they want to implement SSP,
> > this is how they MUST do it.  Of course, verifiers are free to implement
> > some other SSP-like thing, even one that acts on SSP records, but I feel
> > we need to provide some precision in the thing we're calling SSP.
>
> Then do not use "MUST" language when speaking of verifiers. Or,
> alternatively, include wording of the form:
>
> "This document describes processes for what verifiers are expected to do
> in order to achieve what the signers intend.
>
> But these descriptions are not Normative since there is no compulsion on
> verifiers to follow those processes exactly as described, or even at all.
> Therefore, use of the terms "MUST" and "SHOULD" in these descriptions
> merely indicate the steps verifiers need to take if they want to claim
> adherence to the particular set of processes described here."
>
> That essentially modifies the interpretations given in RFC 2119 (and 2119
> already implies that such modifications are appropriate in non-normative
> contexts).
>
> There may be better ways to express all this.

How would doing this work change what verifiers do after the RFC is deployed?

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

Re: [ietf-dkim] Review of DKIM Sender Signing Practices (draft-ietf-dkim-ssp-01)

[Charles Lindsey]

On Tue, 04 Dec 2007 18:10:37 -, Jim Fenton <[EMAIL PROTECTED]> wrote:


Charles Lindsey wrote:

But it has no business whatsoever making normative statements about
what verifiers are to do, so wording of the form "Verifiers MUST" is
quite out pf place - that is BCP material.


Somehow, we need to tell verifiers what they need to do in order to
implement this specification.  Nobody is saying that verifiers MUST
implement SSP at all, but rather that if they want to implement SSP,
this is how they MUST do it.  Of course, verifiers are free to implement
some other SSP-like thing, even one that acts on SSP records, but I feel
we need to provide some precision in the thing we're calling SSP.


Then do not use "MUST" language when speaking of verifiers. Or,  
alternatively, include wording of the form:


"This document describes processes for what verifiers are expected to do  
in order to achieve what the signers intend.


But these descriptions are not Normative since there is no compulsion on  
verifiers to follow those processes exactly as described, or even at all.  
Therefore, use of the terms "MUST" and "SHOULD" in these descriptions  
merely indicate the steps verifiers need to take if they want to claim  
adherence to the particular set of processes described here."


That essentially modifies the interpretations given in RFC 2119 (and 2119  
already implies that such modifications are appropriate in non-normative  
contexts).


There may be better ways to express all this.

--
Charles H. Lindsey -At Home, doing my own thing
Tel: +44 161 436 6131   
   Web: http://www.cs.man.ac.uk/~chl

Email:[EMAIL PROTECTED]: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9  Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Mailing lists as 2822-Sender

[Charles Lindsey]

On Tue, 04 Dec 2007 19:32:26 -, Mark Martinec  
<[EMAIL PROTECTED]> wrote:



I'm observing regular cases of originator signature breakage
by mailing lists which DO NOT modify mail body or header in
intrusive ways. This happens every time the poster included
a Sender header field in its original posting, and then sign it.
A mailing list which replaces the original Sender by its own
causes a signature breakage, quite unnecessarily.


But if RFC 2822 is followed, then Sender SHOULD NOT be present unles there  
are explicit reasons for doing so. The usual examples given are:


1. The secretary is sending on behalf of her boss
2. There are multiple entries in the From (in which case the Sender MUST  
be included).


Neither of those commonly arises in mailing lists.

In the few cases where an already signed Sender arrives at a mailing list,  
then the mailing list should do the same as if it makes any other change  
which invalidates the signature. My preference for that situation is for  
the mailing list to:


1. Check the existing signature (and maybe reject outright if it is  
'suspicious').
2. Record his (hopefully correct) check result in an  
Authentication-Results header.

3. Re-sign the message, including that new Authentication-Results header.


Unfortunately the RFC 4871 wants a Sender signed:

  The following header fields SHOULD be included in the signature,
  if they are present in the message being signed:
o  From (REQUIRED in all signatures)
o  Sender, Reply-To ...


Yes, but I would be inclined to modify that by only signing it where it  
was NOT identical to the From (i.e. in the secretary and multiple Froms  
cases above).


--
Charles H. Lindsey -At Home, doing my own thing
Tel: +44 161 436 6131   
   Web: http://www.cs.man.ac.uk/~chl

Email:[EMAIL PROTECTED]: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9  Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

Re: [ietf-dkim] Review of DKIM Sender Signing Practices(draft-ietf-dkim-ssp-01)

[Charles Lindsey]

On Tue, 04 Dec 2007 16:22:16 -, J D Falk <[EMAIL PROTECTED]> wrote:


Charles Lindsey suggested:



And I am still happy to see BCP material which then, essentially,
describes ways in which verifiers are "expected"
to apply the "advice".


A fine idea -- except, how do we list Best Current Practices when there
are no current practices yet?


The particular practices I have in mind are those already in the draft,  
but currently confusingly described by the use of 2119-like MUSTard.


--
Charles H. Lindsey -At Home, doing my own thing
Tel: +44 161 436 6131   
   Web: http://www.cs.man.ac.uk/~chl

Email:[EMAIL PROTECTED]: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9  Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
___
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html