Re: [ietf-dkim] What third-party ISP problem?

Mark Delany wrote: > The point seems to be that there is a potential mis-match. Reputation > of content author != reputation of outsourced-sender, aka ISP. > > One imagines that most small businesses fall into this category where > they have an impeccable record, yet their ISP is, by necessity,

[ietf-dkim] What third-party ISP problem?

On Wed, Aug 02, 2006 at 08:02:54PM -0700, Dave Crocker allegedly wrote: [Starting a new thread to focus on a one aspect] > Outsourcing for mail sending is already common, so it seems likely that > delegating signing would be, too. > > But my question is why it is better to have a "delegation of

RE: [ietf-dkim] A more fundamental SSP axiom

All, Maybe I am confused on how email works. Sending, A. I want to send a message. My MTA looks up the MX record of the receiving party and initiates a bind and a conversation on port 25 with the receiver's MTA. As part of that conversation headers are exchanged one of which is DKIM. I then pass th

Re: [ietf-dkim] A more fundamental SSP axiom

> Man, you made me laugh spit on my screen!! Perhaps a tissue? > I wish to remind you of what you said nearly 1 year ago, that really > strikes at the core: Thanks, but you're not paying attention. I've said as much since. I think your issue must be that you confuse an argument for the exis

Re: [ietf-dkim] A more fundamental SSP axiom

John L wrote: > The third is " signs all my mail", if it turns out that there > actually exist foo's that reliable enough to delegate's one's signing, > and that it's easier to do that than to sign in the MUA or to provide > signing keys so that foo can put on the sender's signature. Outsourcing

Re: [ietf-dkim] A more fundamental SSP axiom

Please don't shoot the messanger: I'm just asking. I hadn't intended to shoot, sorry if it came across that way. You're right, people find all sorts of other uses for successful protocols, but those uses tend to be "pull", repurpose info already used for something else rather than "push", st

Re: [ietf-dkim] A more fundamental SSP axiom

John L wrote: I think a more fundamental question is who the consumers of SSP information are. I think that everybody agrees that DKIM receivers are an important constituent, but are they the only ones? It doesn't seem very hard to envision other consumers. Usage scenarios would be very he

Re: [ietf-dkim] How MALLET PERFORMS a DOWNGRADE ATTACK

Oh come on. We're done on that issue. Let's at least try make progress please. You suggested it. The WG chose not to do that. That's all. S. Douglas Otis wrote: On Aug 2, 2006, at 3:12 PM, Hallam-Baker, Phillip wrote: NO MALLET PERFORMS A SUCCESSFUL DOWNGRADE ATTACK. As far as Bob is conc

Re: [ietf-dkim] How MALLET PERFORMS a DOWNGRADE ATTACK

> The selector mechanism is a simple fix.I tend to agree with John, the selector mechanism seems overly complex.  Perhaps a convention of right-hand labels within theselector, or adoption of the r= mechanism could simplify thissomewhat.  The r= mechanism also has the advantage of not impactingkey

Re: [ietf-dkim] How MALLET PERFORMS a DOWNGRADE ATTACK

On Aug 2, 2006, at 3:12 PM, Hallam-Baker, Phillip wrote: NO MALLET PERFORMS A SUCCESSFUL DOWNGRADE ATTACK. As far as Bob is concerned the email is in compliance with policy so he has to accept the message as being compliant with the signature policy even though it is not. On this I ten

Re: [ietf-dkim] Re: How MALLET PERFORMS a DOWNGRADE ATTACK

Dave Crocker wrote: Stephen Farrell wrote: Hallam-Baker, Phillip wrote: NO MALLET PERFORMS A SUCCESSFUL DOWNGRADE ATTACK. I could quibble. That's not a downgrade attack since Alice parallel-signed with both. I was under the impression that the working group had said that it was not conc

Re: [ietf-dkim] Re: How MALLET PERFORMS a DOWNGRADE ATTACK

Stephen Farrell wrote: > > > Hallam-Baker, Phillip wrote: >> NO MALLET PERFORMS A SUCCESSFUL DOWNGRADE ATTACK. > > I could quibble. That's not a downgrade attack since Alice > parallel-signed with both. I was under the impression that the working group had said that it was not concerned abo

[ietf-dkim] Re: How MALLET PERFORMS a DOWNGRADE ATTACK

Hallam-Baker, Phillip wrote: NO MALLET PERFORMS A SUCCESSFUL DOWNGRADE ATTACK. I could quibble. That's not a downgrade attack since Alice parallel-signed with both. This is different from bidding down with spnego/gssapi or SSL where there may be an "export" option, but I don't want to end up

Re: [ietf-dkim] A few SSP axioms

On Aug 2, 2006, at 1:59 PM, Hector Santos wrote: DKIM was attractive because it offered a way to resolve the IP forwarding problem and also offer strong, exclusive policies. So since day one, I repeated the same mantra here, with no reason to believe history will not repeat itself:

[ietf-dkim] How MALLET PERFORMS a DOWNGRADE ATTACK

> From: Stephen Farrell [mailto:[EMAIL PROTECTED] > Hallam-Baker, Phillip wrote: > >> From: Stephen Farrell [mailto:[EMAIL PROTECTED] > > > >> Why? Surely all that can happen is stripping of the > stronger sig and > >> we already decided that that wasn't a bother for base, so > why is it a >

RE: [ietf-dkim] A more fundamental SSP axiom

At 2:37 PM -0500 8/2/06, Arvel Hathcock wrote: > We need more than that: we need a statement of how the receivers are expected by the senders to use it. If this is just "I wanted to tell you what I want" with no expectation of how that information will be used, it's just bluster. Paul, I

Re: [ietf-dkim] A more fundamental SSP axiom

Ok.    Here is a scenario:    I send a signed message somewhere.   To me, it's that simple.   IMHO this-Works: (some of which flies in the face of the scope- I know - don't care) -One signature per message. -Authentication happens in the SMTP process or a process that knows everything about the mes

Re: [ietf-dkim] A few SSP axioms

- Original Message - From: "Stephen Farrell" <[EMAIL PROTECTED]> Sent: Wednesday, August 02, 2006 2:47 PM Subject: Re: [ietf-dkim] A few SSP axioms >> Hmm, unknown router and transient issues wasn't obvious? > > It wasn't obvious that that was your concern. And if it is > your concer

Re: [ietf-dkim] A more fundamental SSP axiom

I think a more fundamental question is who the consumers of SSP information are. I think that everybody agrees that DKIM receivers are an important constituent, but are they the only ones? It doesn't seem very hard to envision other consumers. Usage scenarios would be very helpful. As Dave no

Re: [ietf-dkim] A more fundamental SSP axiom

- Original Message - From: "Arvel Hathcock" <[EMAIL PROTECTED]> To: Sent: Wednesday, August 02, 2006 3:23 PM Subject: RE: [ietf-dkim] A more fundamental SSP axiom > So, focus narrowly on what receivers would find of immediate benefit > for an initial round of SSP work which will entice

Re: [ietf-dkim] A few SSP axioms

Damon wrote: On 8/2/06, *Stephen Farrell* <[EMAIL PROTECTED] > wrote: Damon wrote: > As the sender whom signed the message, I want to tell the receiver to > trust mine and ignore (or dislike) the rest. I don't want anyone else to > sign in my

Re: [ietf-dkim] A few SSP axioms

Damon wrote: As the sender whom signed the message, I want to tell the receiver to trust mine and ignore (or dislike) the rest. I don't want anyone else to sign in my place if I am the one signing. Right? That's exactly where we started:-) Some people (incl. me) don't see any benefit in dis

Re: [ietf-dkim] A few SSP axioms

On 8/2/06, Stephen Farrell <[EMAIL PROTECTED]> wrote: Damon wrote:> As the sender whom signed the message, I want to tell the receiver to> trust mine and ignore (or dislike) the rest. I don't want anyone else to > sign in my place if I am the one signing.> Right?That's exactly where we started:-) S

Re: [ietf-dkim] SSP additional tag?

William,    I see adding this to the Signature as fixing a lot of issues. Why was it dropped? Can it be re-visited since at this point it is valuable again?   Regards, Damon Sauer  On 8/2/06, william(at)elan.net <[EMAIL PROTECTED]> wrote: On Wed, 2 Aug 2006, Damon wrote:> Are you saying the the re

RE: [ietf-dkim] A more fundamental SSP axiom

> We need more than that: we need a statement of how the receivers are > expected by the senders to use it. If this is just "I wanted to tell > you what I want" with no expectation of how that information will be > used, it's just bluster. Paul, I may be misunderstanding but does communicatin

Re: [ietf-dkim] A few SSP axioms

On 8/2/06, Stephen Farrell <[EMAIL PROTECTED]> wrote: Damon wrote:> Does the DKIM verifier give a hoot about the other Recieved headers?No (Assuming they're not signed, and the signer didn't prevent their addition using the existing scheme in base.)But so far verifiers don't care about whether ther

Re: [ietf-dkim] SSP additional tag?

On Wed, 2 Aug 2006, Damon wrote: Are you saying the the receiving MTA is not going to know what IP it received the message from? More precisely the system doing DKIM checking is not going to know it or even more precisely we should not assume that it would have any knowledge about it (at leas

Re: [ietf-dkim] A more fundamental SSP axiom

On Aug 2, 2006, at 11:55 AM, <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> wrote: Dave, As a receiver I would like to know who sent the message, who signed the message and any further information that might allow me to assign a spam score accurately for further edge processing. Who signed th

Re: [ietf-dkim] A few SSP axioms

Damon wrote: Does the DKIM verifier give a hoot about the other Recieved headers? No (Assuming they're not signed, and the signer didn't prevent their addition using the existing scheme in base.) But so far verifiers don't care about whether there're one or two or however many signatures eith

Re: [ietf-dkim] SSP additional tag?

On 8/2/06, william(at)elan.net <[EMAIL PROTECTED]> wrote: On Wed, 2 Aug 2006, Damon wrote:> It does not matter which server adds the tag, only which server is the > sending MTA.DKIM is protocol that does not have much to do with SMTP session.As I said - to add this feature in you need to have DKIM

Re: [ietf-dkim] A few SSP axioms

On 8/2/06, Stephen Farrell <[EMAIL PROTECTED]> wrote: Hector Santos wrote:> - Original Message -> From: "Stephen Farrell" < [EMAIL PROTECTED] Hector Santos wrote:>>>...and>>>want to make sure that only emails directly from their system are >>>accepted as valid by recipient.

RE: [ietf-dkim] A more fundamental SSP axiom

> As soon as we have a basis for believing that Receive side folk with actually > USE information provided by senders, then the senders are much more likely to > provide it. After all, providing it improves deliverability. Ah, I see. Thanks for helping me understand better. > If we only focus o

Re: [ietf-dkim] A more fundamental SSP axiom

[EMAIL PROTECTED] wrote: > Dave, > As a receiver I would like to know who sent the message, who signed the > message These two statements are relatively precise and well understood. > ...and any further information that might allow me to assign a spam > score accurately for further edge proce

Re: [ietf-dkim] A more fundamental SSP axiom

At 11:40 AM -0700 8/2/06, Dave Crocker wrote: As soon as we have a basis for believing that Receive side folk with actually USE information provided by senders, then the senders are much more likely to provide it. We need more than that: we need a statement of how the receivers are expected by

RE: [ietf-dkim] A more fundamental SSP axiom

Dave, As a receiver I would like to know who sent the message, who signed the message and any further information that might allow me to assign a spam score accurately for further edge processing. Thanks, Bill Oxley Messaging Engineer Cox Communications, Inc. Alpharetta GA 404-847-6397 [EMAIL

Re: [ietf-dkim] A few SSP axioms

Hector Santos wrote: - Original Message - From: "Stephen Farrell" <[EMAIL PROTECTED]> Hector Santos wrote: ...and want to make sure that only emails directly from their system are accepted as valid by recipient. Aha! Possible sound of penny dropping... Is it a mail routing

Re: [ietf-dkim] A more fundamental SSP axiom

Arvel Hathcock wrote: >> SSP exists so that receivers can make better decisions about >> handling their incoming mail. > > There is a lot of truth in that statement. I would say it like this though: > SSP exists so that senders can provide input in the hopes that receivers will > make "bet

Re: [ietf-dkim] A few SSP axioms

- Original Message - From: "Stephen Farrell" <[EMAIL PROTECTED]> > Hector Santos wrote: >>...and >>want to make sure that only emails directly from their system are >>accepted as valid by recipient. > > Aha! Possible sound of penny dropping... > > Is it a mail routing policy y

Re: [ietf-dkim] SSP additional tag?

Some people unfortunetly never introduced tag (present for example in IIM) specifying which server actually adds DKIM signature. This makes it impossible to extend in the way you proposed as receiver would not know server/network responsible for adding particular signature when email is actuall

Re: [ietf-dkim] SSP additional tag?

If I have a domain that my ISP is my MTA then my ISP is my SPF. In this case, if the message is signed, it is truly specific to me.   And I disagree with the breaking of forwarding...   User A sends a message from the home office in Walla Walla. It is signed by the home office's MTA and also by the

Re: [ietf-dkim] A few SSP axioms

- Original Message - From: "John L" <[EMAIL PROTECTED]> To: "Hector Santos" <[EMAIL PROTECTED]> >> John wants to know how a 2nd signature could invalid an already valid >> message. This is really based on a "Good Citizen" model where >> everything is done correctly. > > Actually, it's b

Re: [ietf-dkim] Are verifiers expected to query SSP on a successfulverify?

Hallam-Baker, Phillip wrote: From: Stephen Farrell [mailto:[EMAIL PROTECTED] Why? Surely all that can happen is stripping of the stronger sig and we already decided that that wasn't a bother for base, so why is it a problem now? (Maybe I mis-remember but I think we decided it was a non-pro

RE: [ietf-dkim] Are verifiers expected to query SSP on a successfulverify?

> From: Stephen Farrell [mailto:[EMAIL PROTECTED] > Why? Surely all that can happen is stripping of the stronger > sig and we already decided that that wasn't a bother for > base, so why is it a problem now? (Maybe I mis-remember but I > think we decided it was a non-problem, not that it was a

RE: [ietf-dkim] A more fundamental SSP axiom

> SSP exists so that receivers can make better decisions about > handling their incoming mail. There is a lot of truth in that statement. I would say it like this though: SSP exists so that senders can provide input in the hopes that receivers will make "better" decisions about handling thei

Re: [ietf-dkim] Are verifiers expected to query SSP on a successfulverify?

Hallam-Baker, Phillip wrote: From: Stephen Farrell [mailto:[EMAIL PROTECTED] Phill, Hallam-Baker, Phillip wrote: > That does not allow for algorithm agility which I believe is either > an explicit security area requirement now or soon will be after the > SHA-1 issue is addressed. Don

RE: [ietf-dkim] Are verifiers expected to query SSP on a successfulverify?

> From: Stephen Farrell [mailto:[EMAIL PROTECTED] > Phill, > > Hallam-Baker, Phillip wrote: > > That does not allow for algorithm agility which I believe > is either > an explicit security area requirement now or > soon will be after the > SHA-1 issue is addressed. > > Don't we already ha

Re: [ietf-dkim] A more fundamental SSP axiom

John L wrote: How about this one: SSP exists so that receivers can make better decisions about handling their incoming mail. Corollary: Information not useful to receivers doesn't belong in SSP. These seem obvious to me, but based on some other correspondence, they're not obvious to e

Re: [ietf-dkim] Are verifiers expected to query SSP on a successfulverify?

Phill, Hallam-Baker, Phillip wrote: > That does not allow for algorithm agility which I believe is either > an explicit security area requirement now or soon will be after the > SHA-1 issue is addressed. Don't we already have alg. agility between signers and verifiers, via the h= and k= fields

Re: [ietf-dkim] Are verifiers expected to query SSP on a successful verify?

On Aug 2, 2006, at 4:35 AM, Stephen Farrell wrote: Can you explain why they are, without recourse to any acronyms and in a sentence or two each? For the most part, Problem 1 together with Solution A is currently being discussed, but this should not be seen as a forgone conclusion. Solut

RE: [ietf-dkim] Are verifiers expected to query SSP on a successfulverify?

The verifier should check the SSP record in cases where the message is insufficiently authenticated according to its local authorization policy. This could be because: * There is no signature * The signature is present does not validate * The signature uses an algorithm that is deprecated by

Re: [ietf-dkim] A more fundamental SSP axiom

Scott Kitterman wrote: > On Wed, 02 Aug 2006 08:28:20 -0500 wayne <[EMAIL PROTECTED]> wrote: >> In <[EMAIL PROTECTED]> Dave Crocker <[EMAIL PROTECTED]> writes: >>> For this initial round of SSP, the wording of the Corollary probably > needs to be: >>> Information that is not widely viewed by

Re: [ietf-dkim] WG and individual submissions...

Once nice thing about the IETF Tools WG page http://tools.ietf.org/wg/dkim/ is that it lists both Official working group and "Related active" documents. To be included in the latter list, you just need to include "-dkim-" somewhere in the I-D name. Tony Hansen [EMAIL PROTECTED] St

Re: [ietf-dkim] A few SSP axioms

Hector, I don't plan to engage in verbal jousting about what's a claim vs. what's a demonstration. I've seen use-cases that satisfy me about the utility of e.g. the "I always sign everything" statement, (and some variants) but I've not seen anything I find at all convincing for the "I want my st

[ietf-dkim] WG and individual submissions...

Hector Santos wrote: > PS: Maybe it would be a good idea for the WG to officially announce the > availability of the DSAP I-D draft. Sure. But since of course its not an official WG document I'm only informally announcing it here:-) Hector's written up an individual submission with his ideas o

Re: [ietf-dkim] A more fundamental SSP axiom

On Wed, 02 Aug 2006 08:28:20 -0500 wayne <[EMAIL PROTECTED]> wrote: >In <[EMAIL PROTECTED]> Dave Crocker <[EMAIL PROTECTED]> writes: > >> John L wrote: >>> SSP exists so that receivers can make better decisions about >>> handling their incoming mail. >>> Corollary: >>> Information not useful

Re: [ietf-dkim] SSP additional tag?

In <[EMAIL PROTECTED]> Damon <[EMAIL PROTECTED]> writes: > Such as "I always sign mail from servers on my SPF record or CIDR(s)" For me, one of the big advantages of DKIM/DK is that it doesn't break (as often) on forwarding, which complements SPF which doesn't break (as often) on mailing lists.

[ietf-dkim] SSP additional tag?

I know that I am writing this a great risk of being flamed but the more I think about it the better it sounds to me. I believe that it will help with the "I sign some mail" and "I sign no mail" issues.   What about using an additional tag to specify where I always sign mail from.   Such as "I alway

Re: [ietf-dkim] New Requirements: SSP must offer Highest Protection Possible

Stephen Farrell wrote: How would this Exclusive (I am the only one to sign) SSP policy DoS work and if so, why would not there be a defense? Right now, I'd mostly be concerned about the accidental DoS where some intermediary also signs. However, I guess if someone could control mail routing

Re: [ietf-dkim] A few SSP axioms

John wants to know how a 2nd signature could invalid an already valid message. This is really based on a "Good Citizen" model where everything is done correctly. Actually, it's based on the model in draft-ietf-dkim-base-04.txt. As always, concrete scenarios would be a great help to understand

Re: [ietf-dkim] A few SSP axioms

- Original Message - From: "Stephen Farrell" <[EMAIL PROTECTED]> To: "Hector Santos" <[EMAIL PROTECTED]> > Hector, > > Yet another claim of utility with no demonstration! Are we referring to a "useful scenario?" Does it matter if is past or preesent? As far as I am concern until all t

Re: [ietf-dkim] A more fundamental SSP axiom

In <[EMAIL PROTECTED]> Dave Crocker <[EMAIL PROTECTED]> writes: > John L wrote: >> SSP exists so that receivers can make better decisions about >> handling their incoming mail. >> Corollary: >> Information not useful to receivers doesn't belong in SSP. I agree, but it is also important to r

Re: [ietf-dkim] A few SSP axioms

Hector, Yet another claim of utility with no demonstration! I do agree that we have to cater for an imperfect world, but you have yet to demonstrate a case where that makes it bad to add signatures to a signed message (from a bank or whatever). Why don't you(*) just show me the benefit? If its

Re: [ietf-dkim] A few SSP axioms

- Original Message - From: "Stephen Farrell" <[EMAIL PROTECTED]> To: "John Levine" <[EMAIL PROTECTED]> > > John Levine wrote: >> If you disagree, you really have to provide a concrete scenario where >> an added signature turns a valid message into an invalid one, keeping >> in mind that

Re: [ietf-dkim] Are verifiers expected to query SSP on a successful verify?

Doug, I don't see how your problems, other than 1, are in scope for SSP. Can you explain why they are, without recourse to any acronyms and in a sentence or two each? S. Douglas Otis wrote: This explores a range of possible policy and auxiliary records and label scenarios as a general exercis

Re: [ietf-dkim] A few SSP axioms

John Levine wrote: If you disagree, you really have to provide a concrete scenario where an added signature turns a valid message into an invalid one, keeping in mind that the existing message headers and the messge body did not change at all, since the original signature is still good. Sorry

Re: [ietf-dkim] New Requirements: SSP must offer Highest Protection Possible

Hector Santos wrote: From: "Stephen Farrell" <[EMAIL PROTECTED]> To: "Hector Santos" <[EMAIL PROTECTED]> Now that sounds *very* complicated, or else, very marginal (in terms of places it could be used). A bank? Maybe with the growing "e-Medical" market, a doctor? or in general any high-val

Re: [ietf-dkim] Crypto Algorithm policy/practice

Michael Thomas wrote: I know that we've gotten a barrage in the last few days but is there support for having policy for what algorithms a domain uses? I assume this is to deal with bid-down attacks. I know where we stand wrt this with -base, but don't remember whether we were given any guid

[ietf-dkim] Back to basics with requirements

I've read the last few hundred messages on SSP and have concluded this is a very hard problem! Despite seeing a lot of interesting ideas, I'm not personally converging on understanding the SSP requirements or the right SSP solution for a wide range of customer uses. DKIM base was a reasonably wel