Re: [ietf-dkim] the actual problem DKIM addresses, was Review of draft-fenton-dkim-threats-01

2005-11-01 Thread Dave Crocker
at all to do with the handling service, per se. d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ ietf-dkim mailing list http://dkim.org

[ietf-dkim] ebay / eboy

2005-10-31 Thread Dave Crocker
as a possible threat in the analysis? SSP deals with matching the From to the DKIM identity. Did you have any other matching in mind? d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ ietf-dkim mailing list http://dkim.org

Re: [ietf-dkim] Review of draft-fenton-dkim-threats-01

2005-10-30 Thread Dave Crocker
No. Sigh. It's actually a good idea to do it. And your level of detail certainly makes the issues coherent, tangible and addressable. My quibble is over the timing and the newness of them. Not that such quibbles ever count for anything. I think it is considerably more than a quibble. It

Re: [ietf-dkim] is this a problem or not?

2005-10-29 Thread Dave Crocker
The usual approach is by using different domains. Disregarding the courtesy forwarding swamp, it makes sense for a bank to say that its transactional notices, e.g., you're overdrawn, shouldn't be coming from any place but the bank, and shouldn't be appearing on mailing lists. On the other

Re: [ietf-dkim] web page now includes paris audio and jabber archive pointers

2005-10-27 Thread Dave Crocker
Folks, The DKIM web page, at http://mipassoc.org/dkim/ now has pointers to the audio recording and the jabber log, of the Paris Jabber pointer was to last year's session, which interestingly was held one day from exactly one year earlier than this year's bof. Anyhow, it's been fixed.

Re: [ietf-dkim] DKIM BOF agenda

2005-10-26 Thread Dave Crocker
You don't have to convince yourselves. You have to convince the people in the room (whoever that might be) to the tune of rough consensus. That's the audience you're playing to. I believe this captures the problem nicely and concisely. It means that a substantial constituency from

Re: [ietf-dkim] DKIM BOF agenda

2005-10-26 Thread Dave Crocker
A very reasonable point, though there are also counter arguments. But that's a discussion that's not for this list which for better or worse has to work with the current IETF custom practice. Stephen, Ok. This is a pretty serious disconnect. I described a process and you have said that it

Re: [ietf-dkim] Should DKIM drop SSP?

2005-10-26 Thread Dave Crocker
Doug, Can you acknowledge the trade-off and defend this choice? Can you demonstrate any support on the list for your proposal? ___ ietf-dkim mailing list http://dkim.org

[ietf-dkim] web page now includes paris audio and jabber archive pointers

2005-10-26 Thread Dave Crocker
Should have added this months ago. The DKIM web page, at http://mipassoc.org/dkim/ now has pointers to the audio recording and the jabber log, of the Paris BOF. /d ___ ietf-dkim mailing list http://dkim.org

[ietf-dkim] Revised charter and documents uploaded to web site

2005-10-25 Thread Dave Crocker
Folks, New versions of the draft charter, base and ssp specifications and threats analysis have been placed on the DKIM web site, at: http://mipassoc.org/dkim d/ ___ ietf-dkim mailing list http://dkim.org

Re: [ietf-dkim] DKIM BOF agenda

2005-10-24 Thread Dave Crocker
Folks, 1. Agenda introduction (10) 2. Walk through proposed charter (15) 3. Discussion of proposed charter -- open (20) 4. Walk through threat analysis -- Fenton (15) 5. Walk through base spec -- Allman (10) 6. Walk through policy spec -- Allman (10) 7. Introduce other deliverables (10)

Re: [ietf-dkim] over-the-wire (in)compatibility between pre-IETF DKIM and (eventual) IETF DKIM

2005-10-21 Thread Dave Crocker
I understand there is a desire not to introduce many more things or drive the spec in new directions, and I agree with that. Having said that, it is better to make any changes now while adoption is low than wait until adoption is much higher. On the other hand, doing more work takes more

Re: [ietf-dkim] over-the-wire (in)compatibility between pre-IETF DKIM and (eventual) IETF DKIM

2005-10-21 Thread Dave Crocker
Andrew, If you are characterizing any change as more work, then you are arguing for a rubber stamp. Oh? You mean that doing more work does NOT take more time? What I am arguing for is careful attention to the question of urgency. Some folks see an urgent need for this standard. Some do

Re: [ietf-dkim] over-the-wire (in)compatibility between pre-IETF DKIM and (eventual) IETF DKIM

2005-10-21 Thread Dave Crocker
Discussing things like kludges, infinite improvements, rubber stamp etc is just not productive for either supposed side. right. d/ ___ ietf-dkim mailing list http://dkim.org

Re: [ietf-dkim] over-the-wire (in)compatibility between pre-IETF DKIM and (eventual) IETF DKIM

2005-10-20 Thread Dave Crocker
Stephen, The point is that changes to the signing process are always imcompatible - the best you can do for backwards compatbility is sign twice or else allow an option to produce a backwards compatible signature format. But I believe we're likely to end up with the MUST-implement being the

Re: [ietf-dkim] over-the-wire (in)compatibility between pre-IETF DKIM and (eventual) IETF DKIM

2005-10-20 Thread Dave Crocker
I would be surprised though if the result for the signature construct (which may be a bit of a special case here) didn't have the best security option as the MUST-implement, even if it has the legacy signature construct as a MAY-emit. But we'll see when we get there... Just to be obsessively

Re: [ietf-dkim] comments on the threats draft

2005-10-19 Thread Dave Crocker
Stephen, 2. There should be a complete analysis, including threats caused by/to the DKIM protocol. There is in fact some text along these lines (see the nits below), but we should include as much as we can here. I have been a strong supporter of doing the threat analysis and doing it before

Re: [ietf-dkim] over-the-wire (in)compatibility between pre-IETF DKIM and (eventual) IETF DKIM

2005-10-19 Thread Dave Crocker
Oh drat! I just posted a half-written response and did not mean to. Please just ignore it. I want to talk with Stephen offline before burdening the list with more of this exchange. A thousand apollogies. d/ Dave Crocker wrote: Is it ok with folks to be required to replace essentially

Re: [ietf-dkim] Re: DKIM BOF -- draft charter and agenda

2005-10-17 Thread Dave Crocker
Several people pointed out the problem in that, and we changed it to the current * Additional key management protocols or infrastructure. I think it's fine as it currently is, yes? I don't think it needs If I am understanding the issue correctly, then yes, 'additional' should be

Re: [ietf-dkim] Re: dkim service

2005-10-14 Thread Dave Crocker
'making this up as I go' is really exactly the problem. multiple signatures moves from one entity taking responsibility to some unknown combination of responsibilities, ensuring substantially greater complexity in the overall system. What are the relationships among the signers? How much

Re: [ietf-dkim] Re: dkim service

2005-10-14 Thread Dave Crocker
'making this up as I go' is really exactly the problem. multiple signatures moves from one entity taking responsibility to some unknown combination of responsibilities, ensuring substantially greater complexity in the overall system. What are the relationships among the signers? How much

Re: [ietf-dkim] Re: dkim service

2005-10-14 Thread Dave Crocker
Could have sworn we were talking about formal standards and what works for them, rather than what kinds of informal heuristics people use. Please cite a standard that has that specifies the kind of trust ambiguity you are promoting. RFC 2822, section 3.6.7. Given that Received fields are

Re: [ietf-dkim] Re: dkim service

2005-10-13 Thread Dave Crocker
Right. The idea, as I put it once, was that If you break it, you bought it. Put less colloquially, if a mailing list that knows it's going to mangle the message receives a DKIM-signed message, it should this was/is a particularly important view, since it relieves the signing effort of

Re: [ietf-dkim] Charter bashing...

2005-10-12 Thread Dave Crocker
Folks, Frankly, I think this is a huge step backwards. You're changing the charter from discussing the goals of the service we're trying to define to discussing the details of the mechanisms we use to build the service. IMO this is going down a path that is likely to cause far more problems

Re: [ietf-dkim] Charter bashing...

2005-10-12 Thread Dave Crocker
The other part of this that I admit to being confused by is in what capacity Stephen is speaking -- bof chair, or just a contributor like any of the rest of us. The charter Barry sent out was discussed at length on the list and didn't seem especially contentious either on the list or at the

Re: [ietf-dkim] Charter bashing...

2005-10-12 Thread Dave Crocker
There was a great deal of contention regarding what DKIM was attempting to achieve at the Paris BOF. there was? there was a great deal of contention about how to run the meeting, but serious debate about the 'purpose' of debate -- enough debate to justify your assessment -- was entirely

Re: [ietf-dkim] Charter bashing...

2005-10-12 Thread Dave Crocker
IETF is currently a three round deal. In the near future it may be reduced to two rounds. I think we can add the additional ciphers in at the DRAFT standard stage without introducing delay. Most WGs (S/MIME, PKIX, TLS) seem to do this via additional RFCs. Not sure why but it does seem to be

Re: [ietf-dkim] draft-fenton-dkim-threats-00

2005-10-07 Thread Dave Crocker
Douglas Otis wrote: The only thing DKIM prevents is detecting invalid uses of a domain name for a signature. DKIM, as described, does not prevent or detect invalid uses. Oh. You mean that your sending a message using my domain, without my permission, won't be possible to detect? Not in the

Re: [ietf-dkim] New DKIM threat analysis draft

2005-10-06 Thread Dave Crocker
Folks, I have only one real reservation. In section 6.3, discussing the message replay attack, esp. in 2nd paragraph... It is presented as if DKIM cannot be applied against replay since replay is indistinguishable from acceptable acts e.g. forwarding. This is not necessarily true. A

Re: [ietf-dkim] draft-fenton-dkim-threats-00

2005-10-06 Thread Dave Crocker
The threat analysis characterizes the bad acts as the spoofing of email addresses. My name is Dave Crocker. The domains involved with my email are dcrocker.net, bbiw.net and songbird.com. The domains in the From and Sender and MailFrom and Helo and Received fields are all valid and I

Re: [ietf-dkim] draft-fenton-dkim-threats-00

2005-10-06 Thread Dave Crocker
, which the threats document does focus on. My point is that this obnoxious Dave Crocker that you do not want to receive mail from qualifies as a Bad Actor, but no spoofing is involved. We do lose sight of some of the benefits when we focus on spoofing, but the threat analysis is focused on what

Re: [ietf-dkim] draft-fenton-dkim-threats-00

2005-10-06 Thread Dave Crocker
With DKIM you still can not prevent an obnoxious sender who is using a domain that also permits various mail-addresses, unless you want to block all of yahoo.com for example. The only thing DKIM prevents is detecting invalid uses of a domain name for a signature. It is well understood that

Re: [ietf-dkim] draft-fenton-dkim-threats-00

2005-10-06 Thread Dave Crocker
nt, I was commenting on the cited statement, which the threats document does focus on. My point is that this obnoxious Dave Crocker that you do not want to receive mail from qualifies as a Bad Actor, but no spoofing is involved. True, but I have been saying that this is a class of Bad

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

2005-08-24 Thread Dave Crocker
/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ ietf-dkim mailing list http://dkim.org

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

2005-08-22 Thread Dave Crocker
on. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ ietf-dkim mailing list http://dkim.org

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

2005-08-22 Thread Dave Crocker
in the semantics, so that it can be reliably and accurately interpreted by a verifying agent? d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ ietf-dkim mailing list http

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

2005-08-22 Thread Dave Crocker
On Mon, 22 Aug 2005 08:12:33 -0700, Dave Crocker wrote: On Fri, 19 Aug 2005 23:33:11 -0400, Keith Moore wrote: It shouldn't be an either-or choice. The author should be able to sign the message indicating that he wrote the content (so that a recipient can verify that yes, it really

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

2005-08-22 Thread Dave Crocker
changes to the threat analysis, charter, and/or specifications are you suggesting? d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ ietf-dkim mailing list http://dkim.org

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

2005-08-21 Thread Dave Crocker
is not whether to provide all of dkim it is whether to require that it all be provided at the same time, or whether to provide the base first. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net

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

2005-08-19 Thread Dave Crocker
mechanism, we do. That's not a small improvement in the world. DKIM will be useful in the short run because we all have quite a lot of knowledge about domains with which we exchange a lot of mail, and that lets us get their mail out of the filtering path. Exactly. d/ --- Dave Crocker

Re: [ietf-dkim] on DKIM as an anti-spam measure

2005-08-17 Thread Dave Crocker
the current focus that is needed. --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ ietf-dkim mailing list http://dkim.org

[ietf-dkim] Focus on: Threat Analysis and Chartering

2005-08-17 Thread Dave Crocker
for the standardization effort. Can we please apply the obvious enthusiasm present on the list to solving our immediate requirement? d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ ietf

[ietf-dkim] a bit of philosophy on working group productivity and scope

2005-08-14 Thread Dave Crocker
of signing a message and validating that signature, we have nothing but fantasy. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ ietf-dkim mailing list ietf-dkim@mipassoc.org

Re: [ietf-dkim] DKIM Threat Analysis v0.06

2005-08-12 Thread Dave Crocker
effects. I think we need to describe lower-level, more-mechanical effects. d/ --- Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net ___ ietf-dkim mailing list ietf-dkim@mipassoc.org http

[ietf-dkim] DKIM Threat Analysis v0.06

2005-08-10 Thread Dave Crocker
On Mon, 1 Aug 2005 12:13:10 +0200, Dave Crocker wrote: * Who are the bad actors? * Where do they fit into the protocol environment (eg, middle of net)? * * What are we trying to prevent them from doing? So far, most of the follow-up on the draft threat analysis thread has been about

Re: [ietf-dkim] DKIM Threat Assessment v0.02 (very rough draft)

2005-08-09 Thread Dave Crocker
origination headers, not just the domain part. Which is why it is, in fact, a primary goal. Since i= is optional, it seems difficult to argue that it demonstrates the tie-in to other identity header fields as primary goal. d/ --- Dave Crocker Brandenburg InternetWorking

<    8   9   10   11   12   13