[ietf-dkim] Tracing SSP's paradigm change

[Steve Atkins]

On Dec 6, 2007, at 11:40 AM, Michael Thomas wrote:

> Steve Atkins wrote:
>> On Dec 6, 2007, at 9:29 AM, Michael Thomas wrote:
>>> Steve Atkins wrote:
>>>> On Dec 6, 2007, at 8:57 AM, Michael Thomas wrote:
>>>>> Dave Crocker wrote:
>>>>>> Michael Thomas wrote:
>>>>>>> And as far as I can tell, you alone seem to be carrying this  
>>>>>>> torch
>>>>>>> here. Changing what we agreed on with rfc5016 should require  
>>>>>>> a very
>>>>>>> high barrier. I see little if any support, let alone broad  
>>>>>>> consensus
>>>>>>> that we got it wrong.
>>>>>
>>>>>   You still didn't respond: did you read 5016 before it was  
>>>>> issued?
>>>>>   In fact I know that you did because you gave a lot of very  
>>>>> detailed
>>>>>   feedback. And this was not one of the thing you commented on  
>>>>> at the
>>>>>   time, so charges of "paradigm change" ring rather hollow.
>>>>>
>>>>>> So, you missed the postings by Levine and Atkins?  (Perhaps  
>>>>>> some others were on "my" side of this topic, but these two  
>>>>>> were at least quite explicit.
>>>>>
>>>>>   I didn't read them as supporting your reading. Let them speak  
>>>>> for
>>>>>   themselves. There are a lot of things being discussed, after  
>>>>> all.
>>>> I broadly agree with most of Dave's concerns...
>>>
>>> Believe it or not, I agree with some of Dave's too. But that isn't
>>> the issue at hand. The specific issue is whether *any* DKIM  
>>> signature
>>> from *any* domain should be sufficient to qualify for "strict" or  
>>> "all".
>>> Do you agree with that or not?
>> In a well-designed protocol based on DKIM, yes I'd agree that a
>> validly DKIM signed message should not provoke an SSP query.

(Michael removes the relevant comment here, let me re-add it).

>> But that's not the protocol we have.

I agree, in principle, with Dave's view that a valid DKIM
signature should not provoke additional DNS queries
for self-published policies.

However I do not believe that SSP does not require
that, from my reading of the current drafts.


>
>   This is rather astonishing, and then you go on to say:
>
>> I think RFC 5016 shows a lack of understanding of DKIM (or is  
>> choosing
>> not to consider some important features of DKIM), and is
>> part of the push to try and build a next generation SPF on
>> an inappropriate base authentication technology.
>
>   Gee thanks, I am new on this block I guess.
>
>   In any case, the problem that I'm having with a lot of the nay- 
> sayers
>   is that it is purely destructive rather than constructive feedback.
>   The feedback is always of the nature of this is wrong, not what will
>   correct the problem. When I raise issues, I suggest a change to make
>   the spec better. If you don't suggest concrete changes to the draft,
>   it's really sort of hard to take you or anybody else seriously.
>   Frankly if you think this is just a piece of junk, I really don't
>   understand why you or Dave or John waste your time.

RFC 5016 isn't based on a clear articulation of what threat
SSP is supposed to defend against. It's also based on the
misconception that if a sender DKIM signs a mail then it
will still be signed on receipt (I understand that you know
that that isn't the case, but a lot of the document appears to
be based on simply ignoring that fact). It's a good solid
description of what a protocol should look like, and many
of the points it does bring up are good ones - but it's
based on false assumptions.

Given that, any suggested changes aren't going to be
wordsmithing, they're going to be wholesale rewrites
which will both be rejected by the document owner and
cause yet more aggravation, noise and personal attacks
here (the level of discourse is so coarse that everyone,
myself included, is letting their frustration leak through
into the discussion). What's the point? My goal is not
to annoy people, it's to improve the quality of the global
email infrastructure.

If you want to work on an analysis of SSP, based on an
honest evaluation of the weaknesses of DKIM on which
it's based, a clear articulation of the threat it intends to
thwart and a real analysis of the actual threat model and
the ways in which SSP can alleviate it, and the harmful
side effects that doing so may have on email in general
then that would be a useful document for the group to
put together and a good use of time.

Minor wordsmithing of an existing document based on
invalid lemmas may improve that documents clarity, but
doesn't seem like the most useful use of time.

Cheers,
   Steve