ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] draft-allman-dkim-{base,ssp}-01.txt

2005-10-26 01:09:00

Doug,

Thanks for taking the time to make it easier to see the diffs.

Douglas Otis wrote:

On Oct 25, 2005, at 1:47 AM, Stephen Farrell wrote:
http://www.sonic.net/~dougotis/id/draft-otis-dkim-threats-01.html
http://www.sonic.net/~dougotis/id/draft-otis-dkim-threats-01.txt

I find it confusing and not entirely helpful that we now
have two partially overlapping threat analyses. Can you
try to excise the overlap so that your document only
contains the delta? I (and I'm sure others) won't be able
to properly consider your concerns if I can't see where
the differences lie.

Just to be clear though - our current charter specifies
that we work on *one* threats document and that the starting
point there is Jim's document.

Of course there should only be one document. I found it easier to sweep through what stood out as desired changes by editing Jim's excellent document. I was troubled by how the threat review did not treat the SSP mechanism separately. As it is now, extracting the SSP mechanism will create a number of changes to this review. I also have concerns that the SSP mechanism may only be appropriate for a few special cases where these domain's policies should also be easier to obtain than allowed with the SSP mechanism.

Easier for you - it made it harder for me to see what you mean.
But the stuff below helps somewhat.

So at some point the we can do an exercise to compare each bit of
your draft against the then-current threats document. I don't think
we want to do that just now though since we'd get bogged down in
detail.

For now, wouldn't it be better to discuss your main issues, in a
one-per-thread way?

DKIM can provide significant benefit without any policies being published, but instead by simply including binding information within the message and using an opportunistic strategy.

That I think is a fair enough point and worth discussing. (As might
be whether or not to allow an option for public keys to be included
with signatures.) OTOH it seems that there should be a benefit to
using DNS to move the keys and policy data if its done well, since
it does provide a somewhat out-of-band channel (generally good in
security) as well as potential ways to choke back on misbehaviour
(which can be both good and dangerous).

Separately you seem to be criticising the policy assertions which
can be made by ssp - that seems to be independent of how those
assertions are distributed and should therefore be a separate
thread. I'm sure there's plenty of room for different opinions
on the right set of policy assertions to allow - there always is!

I think those are your main points, but if I've missed something
else at that level, let me know.

If they are, then separate threads for each would be a good idea.

> There is not going  to
be a flag day.
>
So far, I have only managed to provide the comparison documents. Explaining problems with SSP will take longer than the time I have today.
>
> Saying it in fewer words is a challenge I am not well suited  to
handle. : )

I suffer the same way a lot of the time:-)

Here is a link to a series of pdf files that provides a section by section breakdown of the changes.

http://www.sonic.net/~dougotis/dkim/

Thanks for taking the time to do this,
Stephen.

_______________________________________________
ietf-dkim mailing list
http://dkim.org