Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread domainkeys-feedbackbase02
--- Scott Kitterman <[EMAIL PROTECTED]> wrote: > I guess that depends on exactly what we are talking about. Some > messages are pretty well inherently abusive while others it depends on > the context. > > If it's a message that has some inherent characteristic that makes it > abusive (it's fr

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread domainkeys-feedbackbase02
--- Scott Kitterman <[EMAIL PROTECTED]> wrote: > Frankly all this discussion about let's go get the guy that signed the > message makes me really wonder why I would ever want to sign a message. > Back to my hobby horse of the week for a moment, unless you offer a > benifit to the sender, the

Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?

2005-08-23 Thread Douglas Otis
On Aug 23, 2005, at 8:09 PM, Earl Hood wrote: On August 23, 2005 at 16:13, Douglas Otis wrote: Let's take a real-world example. CPAN provides a permanent email address for all CPAN account holders. CPAN account holders specify where to forward all messages address to their CPAN addresses. Th

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Jim Fenton
Earl Hood wrote: On August 23, 2005 at 13:53, Jim Fenton wrote: This goes to what we have been very generically calling first-party and third-party signatures. The original submission of a message would normally result in a first-party signature from the supposed author's domain. A mail

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Scott Kitterman
[EMAIL PROTECTED] wrote: --- Scott Kitterman <[EMAIL PROTECTED]> wrote: So in your view, what is the accountability entity for a message sent to you, the MUA/MSA/MTA that signed the message or the MTA that sent you the message if they aren't the same? One definition of accountability might

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread domainkeys-feedbackbase02
--- Earl Hood <[EMAIL PROTECTED]> wrote: > Any "accountability" should be explicitly defined. In the negative sense, let me suggest that an accountable entity is one who can best stop the traffic if you don't want it. If we take a leap of faith that what you don't want is the content, then maybe

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread domainkeys-feedbackbase02
--- Scott Kitterman <[EMAIL PROTECTED]> wrote: > So in your view, what is the accountability entity for a message sent to > you, the MUA/MSA/MTA that signed the message or the MTA that sent you > the message if they aren't the same? One definition of accountability might be; which party is best

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Earl Hood
On August 23, 2005 at 20:06, Dave Crocker wrote: > > > Should a forwarder (e.g. college alumni permanent address service) have > > > > > > the same level of accountability as the originating domain (the domain > > > that received the initial submission of a message)? > > > > > I don't see why

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Scott Kitterman
Dave Crocker wrote: Let's remember that the primary role for this signature is as input to a delivery filtering process. So the nature of the 'accountability' is inherently narrow. That's one view. I view that role as entirely secondary to the potential for DKIM to restrict certainly class

[ietf-dkim] Is accountability binary?

2005-08-23 Thread domainkeys-feedbackbase02
--- John R Levine <[EMAIL PROTECTED]> wrote: > > Should a forwarder (e.g. college alumni permanent address service) have > > the same level of accountability as the originating domain (the domain > > that received the initial submission of a message)? > > I don't see why not. If they're sending

Re: [ietf-dkim] proposed threat analysis outline

2005-08-23 Thread Arvel Hathcock
Yes, yes, yes. I agree completely here. -- Arvel - Original Message - From: "Jim Fenton" <[EMAIL PROTECTED]> To: "Tony Finch" <[EMAIL PROTECTED]> Cc: Sent: Monday, August 22, 2005 11:29 PM Subject: Re: [ietf-dkim] proposed threat analysis outline Tony, While I like your outline

Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?

2005-08-23 Thread Earl Hood
On August 23, 2005 at 16:13, Douglas Otis wrote: > > DKIM should provide the mechanism to facilitate accountability in > > an acceptably reliable fashion. > > > > Therefore, you are implying that domains may practice policies that > > selectively sign messages based on what they want to account fo

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Dave Crocker
On 23 Aug 2005 22:42:50 -0400, John R Levine wrote: > > Should a forwarder (e.g. college alumni permanent address service) have > > > > the same level of accountability as the originating domain (the domain > > that received the initial submission of a message)? > > > I don't see why not. If t

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread John R Levine
> If the DKIM specification explicit states that it provides an > accountable identity for a message without mentioning what is > involved for being accountable, then you may get adoption problems. That hasn't been a problem up to now. I get the impression that most people anticipate doing triage

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Earl Hood
On August 23, 2005 at 13:53, Jim Fenton wrote: > This goes to what we have been very generically calling first-party and > third-party signatures. The original submission of a message would > normally result in a first-party signature from the supposed author's > domain. A mailing list would

Re: [ietf-dkim] Re: SSP and DKIM, was Not exactly not a threat analysis

2005-08-23 Thread John Levine
>(and today ain't over yet). Since July 26 when I first released it there >have been 65,392 downloads of it. Well, that's encouraging. >The problem I have is that I can't populate DNS with the required entries >for my customers automagically and they are mostly all incapable of doing >this on

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Earl Hood
On August 23, 2005 at 10:09, Ned Freed wrote: > It seems to me that the underlying disagreement here has to do with the > term "signature". In DKIM signatures are nothing but a means to an end: > They provide the means of attaching an accountably identity to a specific > message. I am uncertain a

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread John Levine
>I don't think DKIM should preclude MUA signing of authored content. It doesn't. If the MUA wants to apply an S/MIME or PGP signature, it can do so, same as always. Since we already have those two signature systems, it's not obvious to me what the benefit would be of adding their function into D

Re: [ietf-dkim] Re: SSP and DKIM, was Not exactly not a threat analysis

2005-08-23 Thread Arvel Hathcock
I think we're in violent agreement. I don't see anything particularly wrong with SSP, but as far as I know it's still just a paper design which makes it a poor candidate for standardization at this point. I can shed some light on that point. I've got thousands of domains using DKIM (that mean

RE: [ietf-dkim] DKIM vs. S/MIME and OpenPGP

2005-08-23 Thread Hallam-Baker, Phillip
> [mailto:[EMAIL PROTECTED] On Behalf Of Keith Moore > Now maybe we could get businesses to sign their messages with > S/MIME or > OpenPGP and solve the phishing problem that way, but somehow I don't > think they'll go for it. And for any of this to work we need > widespread > buyin. If th

Re: [ietf-dkim] updated threat analysis outline

2005-08-23 Thread Douglas Otis
On Aug 23, 2005, at 12:24 PM, Tony Finch wrote: http://www.cus.cam.ac.uk/~fanf2/hermes/doc/antiforgery/draft-fanf- dkim-rationale.txt 4.1. Hostname (RFC 2821 EHLO) I agree HELO is currently is not properly configured in many cases, and RFC 2821 allows this situation. HELO verificati

[ietf-dkim] Re: SSP and DKIM, was Not exactly not a threat analysis

2005-08-23 Thread John Levine
>> Same starting line for both, not necessarily the same finish line. > >That's been my expectation all along. That was reflected >in the proposed charter. I think we're in violent agreement. I don't see anything particularly wrong with SSP, but as far as I know it's still just a paper design whi

RE: [ietf-dkim] BCC Recipients

2005-08-23 Thread Hallam-Baker, Phillip
So only include that token on the BCC copy. > -Original Message- > From: Michael Thomas [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 23, 2005 5:11 PM > To: Hallam-Baker, Phillip > Cc: Tony Finch; Keith Moore; ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] BCC Recipients > > > Ha

Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?

2005-08-23 Thread Douglas Otis
On Aug 23, 2005, at 12:49 PM, Earl Hood wrote: On August 20, 2005 at 18:21, Douglas Otis wrote: DKIM should provide the mechanism to facilitate accountability in an acceptably reliable fashion. Therefore, you are implying that domains may practice policies that selectively sign messages based

[ietf-dkim] DKIM vs. S/MIME and OpenPGP

2005-08-23 Thread Keith Moore
I thought you said that DKIM is the transmission signature and that S/MIME and OpenPGP offer the authoring signature. Did I misunderstand you? Clearly S/MIME and OpenPGP try to provide an authoring signature. They don't seem to have been very successful, for reasons that appear to be related

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Jim Fenton
Keith Moore wrote: Part of the idea that DKIM seems to propose is that more than one party can potentially sign a message. For instance, an author might sign a message, or a list might sign the same message. But different parties mean different things when they sign the message. If the author

[ietf-dkim] Some real world DKIM feedback

2005-08-23 Thread Arvel Hathcock
For those who don't know, I've implemented and deployed the full DKIM (base+SSP) some weeks ago in a new version of my MTA. My customers are reporting that they are receiving DKIM signed messages from "s=2005; d=replies.em.bankofamerica.com". These message successfully interoperate. I have o

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Keith Moore
no, it "just" means that the MTA has to transmit multiple copies of the same message to the same SMTP server, differing only in their signature and bcc header field. And this breaks existing email functionality (the multiple recipient optimization) which contradicts one of our goals. Only for

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Keith Moore
no, it "just" means that the MTA has to transmit multiple copies of the same message to the same SMTP server, differing only in their signature and bcc header field. My understanding is that BCC should not be seen in SMTP transmission, except first hop when SMTP is used in place of SUBMIT.

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Keith Moore
Part of the idea that DKIM seems to propose is that more than one party can potentially sign a message. For instance, an author might sign a message, or a list might sign the same message. But different parties mean different things when they sign the message. If the author signs a message, it m

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Michael Thomas
Keith Moore wrote: >>I think that authors that want to protect their reputations can arrange for their messages to have DKIM authorship signatures, and also advertise (say via DNS) that their messages will have such signatures. Whether this is done via an MUA, or via a special submission ser

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Michael Thomas
Scott Kitterman wrote: Ned Freed wrote: It appears to me that there are those who do not want SSP for reasons that aren't clear to me. I'd rather get SSP in scope once and for all and not have to have the scope arguement again after base is published. Same starting line for both, not necessa

Re: [ietf-dkim] BCC Recipients

2005-08-23 Thread Michael Thomas
Hallam-Baker, Phillip wrote: Or something of that nature. That means that the BCC recipient can verify it was sent to them while preventing any To: or CC: recipient knowing anything more than that there is a BCC. That in and of itself seems like a breach of BCC semantics. I'd be very alarmed j

RE: [ietf-dkim] BCC Recipients

2005-08-23 Thread Hallam-Baker, Phillip
> -Original Message- > From: william(at)elan.net [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 23, 2005 3:33 PM > To: Hallam-Baker, Phillip > Cc: ietf-dkim@mipassoc.org > Subject: Re: [ietf-dkim] BCC Recipients > > > > On Tue, 23 Aug 2005, Hallam-Baker, Phillip wrote: > > >> This

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Jim Fenton
Going back a lot of messages, but only a few hours (apologies if I'm beating a dead horse): Keith Moore wrote: Part of the idea that DKIM seems to propose is that more than one party can potentially sign a message. For instance, an author might sign a message, or a list might sign the same m

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Tony Finch
On Tue, 23 Aug 2005, william(at)elan.net wrote: > > Therefore I do not understand how can MTA possibly transmit multiple > copies "differing in their signature and BCC heaader field". You should re-read the discussion in RFC 2822 section 3.6.3 about the three ways in which BCC can be used, in part

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Arvel Hathcock
OTOH, right now SSP is nowhere near as well thought out as DKIM is. You mean "right now DKIM-SSP is nowhere near as well though out as DKIM-base". I tend to think the approach of DKIM first, SSP next is best. You mean "I tend to think the approach of DKIM-base first, DKIM-SSP next is best

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Arvel Hathcock
Exactly! Well said Scott! -- Arvel - Original Message - From: "Scott Kitterman" <[EMAIL PROTECTED]> To: Sent: Tuesday, August 23, 2005 2:08 PM Subject: Re: [ietf-dkim] Not exactly not a threat analysis Ned Freed wrote: DKIM without SSP is useful, but SSP adds significant value.

Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?

2005-08-23 Thread Earl Hood
On August 20, 2005 at 18:21, Douglas Otis wrote: > > It appears your discussion of accountability is really something that > > sits on top of DKIM, since trying to standardize "accountability" > > seems impractical. > > I do not understand what you mean by standardized accountability. > Either th

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread william(at)elan.net
On Tue, 23 Aug 2005, Keith Moore wrote: no, it "just" means that the MTA has to transmit multiple copies of the same message to the same SMTP server, differing only in their signature and bcc header field. My understanding is that BCC should not be seen in SMTP transmission, except first hop

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread domainkeys-feedbackbase02
--- Ned Freed <[EMAIL PROTECTED]> wrote: > THe term I prefer is "accountable". "Responsible" goes a bit too far in this > context since it carries with it some connotation of authorship. ... > DKIM isn't supposed to provide a general content signing service, or a general > nonrepudiation service

Re: [ietf-dkim] BCC Recipients

2005-08-23 Thread william(at)elan.net
On Tue, 23 Aug 2005, Hallam-Baker, Phillip wrote: This doesn't help for BCC recipients at the same domain. The only way to sign BCC in my view is to provide a per user signature constructed by means of an HMAC. For example message is "Hello World", Sending it to [EMAIL PROTECTED] So I const

Re: [ietf-dkim] More of a marketting plan really

2005-08-23 Thread Tony Finch
On Tue, 23 Aug 2005, Hallam-Baker, Phillip wrote: > > * The cost of running spam filtering systems is very high for the > largest ISPs and for providers of spam filtering services. This cost > could be significantly reduced if there was a better way to identify the > good incoming mail. Signing

[ietf-dkim] updated threat analysis outline

2005-08-23 Thread Tony Finch
On Tue, 23 Aug 2005, Ned Freed wrote: > > The real question is how this affects the threat analysis. I think SSP > needs to be part of the analysis, but we need to be clear when we're > talking about base DKIM and when we're talking about SSP. That way we > know which benefits (and risks) accrue fr

Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?

2005-08-23 Thread Earl Hood
On August 20, 2005 at 17:14, Douglas Otis wrote: > > You can't stop forgery without stopping forgery. Some things that are > > perhaps technically forgery are considered desireable. Other things > > that aren't forgery might be affected by forgery prevention protocols. > > Stopping forgery re

[ietf-dkim] BCC Recipients

2005-08-23 Thread Hallam-Baker, Phillip
> This doesn't help for BCC recipients at the same domain. The only way to sign BCC in my view is to provide a per user signature constructed by means of an HMAC. For example message is "Hello World", Sending it to [EMAIL PROTECTED] So I construct a BCC identifier HMAC ("[EMAIL PROTECTED]", SHA1

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Tony Finch
On Tue, 23 Aug 2005, Keith Moore wrote: > > no, it "just" means that the MTA has to transmit multiple copies of the same > message to the same SMTP server, differing only in their signature and bcc > header field. And this breaks existing email functionality (the multiple recipient optimization) w

[ietf-dkim] More of a marketting plan really

2005-08-23 Thread Hallam-Baker, Phillip
Title: Message My threat analysis has a rather different starting place. My objective is not so much to solve a particular problem as to identify a 'killer application' where there is: A clearly understood pain point. A core constituency that is directly affected by the pain point

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Scott Kitterman
Ned Freed wrote: DKIM without SSP is useful, but SSP adds significant value. OTOH, right now SSP is nowhere near as well thought out as DKIM is. So, in the interests of getting things done, I tend to think the approach of DKIM first, SSP next is best. Divide and conquer has often proved to be

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Keith Moore
However the submission server cannot trivially include the list of recipients in the message signature and remain compatible with BCC (which is one of our requirements). Sure it can. Any recipient in the envelope but not in the message header gets a separate signature. Easiest thing to do is t

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Earl Hood
On August 19, 2005 at 23:23, Keith Moore wrote: > The point is that, for a variety of reasons, From really has no implied > relationship with who sent the message, and has only a tenuous > relationship with who wrote the message. People have stood on their > heads trying to reconcile this wit

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Keith Moore
>>I think that authors that want to protect their reputations can arrange for their messages to have DKIM authorship signatures, and also advertise (say via DNS) that their messages will have such signatures. Whether this is done via an MUA, or via a special submission server, or whatever, is up

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Ned Freed
Ned Freed wrote: > Now, if at some point in the future, after this group is done and has "walked > into absence", it makes sense to reuse some or alll of DKIM to provide some of > these other services in lieu of using S/MIME, PGP or whatever, that's fine. > Incremental development is A Good Thi

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Tony Finch
On Tue, 23 Aug 2005, Keith Moore wrote: > > I don't think DKIM should preclude MUA signing of authored content. Agreed. > > However the submission server cannot trivially include the list of > > recipients in the message signature and remain compatible with BCC (which > > is one of our requiremen

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Keith Moore
>>I think that authors that want to protect their reputations can arrange for their messages to have DKIM authorship signatures, and also advertise (say via DNS) that their messages will have such signatures. Whether this is done via an MUA, or via a special submission server, or whatever, is up

RE: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Hallam-Baker, Phillip
> [mailto:[EMAIL PROTECTED] On Behalf Of Russ Housley > Keith: > > I thought you said that DKIM is the transmission signature > and that S/MIME > and OpenPGP offer the authoring signature. Did I misunderstand you? > > If there is consensus on this point, then this helps set the > scope for t

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Scott Kitterman
Ned Freed wrote: Now, if at some point in the future, after this group is done and has "walked into absence", it makes sense to reuse some or alll of DKIM to provide some of these other services in lieu of using S/MIME, PGP or whatever, that's fine. Incremental development is A Good Thing. But w

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Tony Finch
On Tue, 23 Aug 2005, Keith Moore wrote: > > I think that authors that want to protect their reputations can arrange for > their messages to have DKIM authorship signatures, and also advertise (say via > DNS) that their messages will have such signatures. Whether this is done via > an MUA, or via a

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Ned Freed
>> no, you keep claiming that I'm wrong, while misrepresenting what I'm >> proposing. I don't think you're convincing anyone. > > > Keith, I don't mean to be rude, but I think you have this backwards. I > think you have been wrong from the outset and nothing you have said has > convinced me oth

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Ned Freed
> Now, Keith will no doubt argue that DKIM is of marginal value at best unless we > extend it into these areas. Simply put, I disagree. For example, even in the > absence of SSP DKIM at a minimum provides a service that can make > whitelisting/blacklisting far more reliable. I strongly disagre

Re: [ietf-dkim] what DKIM is --- a personal perspective

2005-08-23 Thread Earl Hood
On August 19, 2005 at 13:18, Eric Allman wrote: > First, by itself, DKIM is not an anti-phishing tool and is definitely > not an anti-spam tool. Then the DKIM specification should be careful when refering to such things. Since the current draft states that DKIM could assist in dealing with phis

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Douglas Otis
On Aug 23, 2005, at 10:55 AM, Keith Moore wrote: Some blacklists are more responsible than others, but I haven't yet seen one that, if trusted to block mail, doesn't block a significant amount of legitimate mail. One advantages of DKIM in this regard, is that when reputation can fully mo

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Keith Moore
A submission server might be in a good position to sign a message on behalf of the submitter, but it seems awkward at best to expect a submission server to distinguish between original messages and re-sent messages. Which implies that you think that it's impossible to implement your tag in a no

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Douglas Otis
On Aug 23, 2005, at 8:47 AM, Keith Moore wrote: Concluding there is significance for a mailbox address assumes mailbox- addresses are normally constrained by the signing domains, or that DKIM establishes an appendage of mailbox-address authorizations. It also seems you want this to include

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Tony Finch
On Tue, 23 Aug 2005, Keith Moore wrote: > > A submission server might be in a good position to sign a message on behalf of > the submitter, but it seems awkward at best to expect a submission server to > distinguish between original messages and re-sent messages. Which implies that you think that

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Russ Housley
Keith: I thought you said that DKIM is the transmission signature and that S/MIME and OpenPGP offer the authoring signature. Did I misunderstand you? If there is consensus on this point, then this helps set the scope for the DKIM threat analysis and charter. Russ At 11:47 AM 8/23/2005, Ke

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Keith Moore
no, you keep claiming that I'm wrong, while misrepresenting what I'm proposing. I don't think you're convincing anyone. Keith, I don't mean to be rude, but I think you have this backwards. I think you have been wrong from the outset and nothing you have said has convinced me otherwise. O

Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP recorddoesnot exist?

2005-08-23 Thread Arvel Hathcock
If you can show that publishing base will in no way cripple or weaken SSP then I for one will get behind your plan. If you can't, I and others won't. That is the debate here. This was not fair of me to say because it is not possible to prove a negative. My apologies Dave, and everyone. Wh

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Keith Moore
Now, Keith will no doubt argue that DKIM is of marginal value at best unless we extend it into these areas. Simply put, I disagree. For example, even in the absence of SSP DKIM at a minimum provides a service that can make whitelisting/blacklisting far more reliable. I strongly disagree. If DKI

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Keith Moore
The primary deployment scenario for DKIM is to do the signing on the submission server, so the signature doesn't necessarily identify the message's author. I'd say the tag you want has at least three settings: author / submission server / re-sender A submission server might be in a good position

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Ned Freed
> > But different parties mean different things when they sign the > > message. If the author signs a message, it means "I wrote this". > > If a list signs a message, it means "I sent this". > Ah, why didn't you just say so two weeks ago? I think you will find > that you are reading a whole lot

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Tony Finch
On Tue, 23 Aug 2005, Keith Moore wrote: > > If you mean that trusting someone else to decide, on behalf of a large and > diverse set of users, what is good for all of those users, is a poorly chosen > policy - then I emphatically agree. I think that's the only reasonably scalable way to implement

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Ned Freed
John R Levine wrote: >>>Right. The context is who signed it. >> >>That's not sufficient unless signers who (re)transmit messages are >>clearly distinguishable from signers who author content. > > > You keep saying that, I keep pointing out that you're wrong. I guess > we're done. no, you keep

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Tony Finch
Keith Moore wrote: > > That's not sufficient unless signers who (re)transmit messages are clearly > distinguishable from signers who author content. That would be a workable > solution, though I don't think it's desirable to overload addresses in this > way. The primary deployment scenario for DK

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Keith Moore
John R Levine wrote: Right. The context is who signed it. That's not sufficient unless signers who (re)transmit messages are clearly distinguishable from signers who author content. You keep saying that, I keep pointing out that you're wrong. I guess we're done. no, you keep claiming tha

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Tony Finch
On Tue, 23 Aug 2005, Keith Moore wrote: > Tony Finch wrote: > > On Tue, 23 Aug 2005, Keith Moore wrote: > > > > > And because "abuse" is subjective (one recipient's spam is another > > > recipient's useful ad), you end up both legitimizing some amount of > > > abuse and marginalizing useful and val

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread John R Levine
> > Right. The context is who signed it. > > That's not sufficient unless signers who (re)transmit messages are > clearly distinguishable from signers who author content. You keep saying that, I keep pointing out that you're wrong. I guess we're done. R's, John PS: > That's a bit like saying

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Keith Moore
And because "abuse" is subjective (one recipient's spam is another recipient's useful ad), you end up both legitimizing some amount of abuse and marginalizing useful and valid behavior. I don't see any clear signs of the convergence to mediocrity that you are concerned about, Well, to me the a

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Keith Moore
John R Levine wrote: I concur with Tony's model that a signature only means "I will accept the blame for this message". I don't think that flies, or at least, I think that makes DKIM of fairly marginal value. A message itself is rarely blameworthy; what matters is the context. Right. The c

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread John R Levine
> > I concur with Tony's model that a signature only means "I will accept > > the blame for this message". > > I don't think that flies, or at least, I think that makes DKIM of fairly > marginal value. A message itself is rarely blameworthy; what matters is > the context. Right. The context is

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Keith Moore
Tony Finch wrote: On Tue, 23 Aug 2005, Keith Moore wrote: If you put signing domains in the position of accepting responsibility for any type of abuse, you do several things. One is that you make it more difficult for domains to justify signing messages. And because "abuse" is subjective (one

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Tony Finch
On Tue, 23 Aug 2005, Keith Moore wrote: > > If you put signing domains in the position of accepting responsibility for any > type of abuse, you do several things. One is that you make it more difficult > for domains to justify signing messages. And because "abuse" is subjective > (one recipient's

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Keith Moore
Concluding there is significance for a mailbox address assumes mailbox- addresses are normally constrained by the signing domains, or that DKIM establishes an appendage of mailbox-address authorizations. It also seems you want this to include some type of path registrations to regulate forwarding

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Douglas Otis
On Tue, 2005-08-23 at 07:58 -0400, Keith Moore wrote: > John Levine wrote: > > I concur with Tony's model that a signature only means "I will accept > > the blame for this message". > > I don't think that flies, or at least, I think that makes DKIM of fairly > marginal value. A message itself i

Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?

2005-08-23 Thread Scott Kitterman
Douglas Otis wrote: On Mon, 2005-08-22 at 21:32 -0400, Scott Kitterman wrote: Once it gets to the MUA, it's too late. I want to reject the message during SMTP (after DATA, but before OK). Your notion seems to consider mailbox address authorization will be the principle mechanism used to re

Re: [ietf-dkim] Not exactly not a threat analysis

2005-08-23 Thread Keith Moore
John Levine wrote: But different parties mean different things when they sign the message. If the author signs a message, it means "I wrote this". If a list signs a message, it means "I sent this". Ah, why didn't you just say so two weeks ago? I think I have said more or less the same thin

Re: [ietf-dkim] proposed threat analysis outline

2005-08-23 Thread Tony Finch
On Mon, 22 Aug 2005, Jim Fenton wrote: > > While I like your outline quite a bit, my inclination is to stick closer to > the specific questions that Russ posed (Who are the bad guys and what are they > capable of? Where are they in the system? What do they want to do?). The > more that we expand

Re: [ietf-dkim] Re: Not exactly not a threat analysis

2005-08-23 Thread Tony Finch
On Tue, 23 Aug 2005, Frank Ellermann wrote: > Tony Finch wrote: > > > Isn't the i= tag the new identity that Keith is asking for? > > Checking the draft, i= is optional, must be below d=, it's not > required to match anything selected by h=, and it's a "verifier > policy issue" [XREF TBD] with the

[ietf-dkim] Re: Not exactly not a threat analysis

2005-08-23 Thread Frank Ellermann
Tony Finch wrote: > Isn't the i= tag the new identity that Keith is asking for? Checking the draft, i= is optional, must be below d=, it's not required to match anything selected by h=, and it's a "verifier policy issue" [XREF TBD] with the fine print. I'm not sure, but for Keith's idea the "

Re: [ietf-dkim] DKIM SSP: Security vulnerability when SSP record does not exist?

2005-08-23 Thread Douglas Otis
On Mon, 2005-08-22 at 21:32 -0400, Scott Kitterman wrote: > Douglas Otis wrote: > > > You wish to include an anti-forgery mechanism directly within DKIM. I > > fear serious issues will likely derail DKIM deployment when "anti- > > forgery" mechanisms interfere with normal email, while at the sa