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
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
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
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
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.
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
'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
'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
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
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
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
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
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
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
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
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
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
, 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
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
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
/
---
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
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
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
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
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
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
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
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
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
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
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
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
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
1201 - 1246 of 1246 matches
Mail list logo