Re: DKIM

[Keith Moore <[e-mail]>]

>>Not clear.  As currently envisioned, DKIM doesn't address phishing 
>>because it basically says "I saw this message" rather than "I 
>>wrote this 
>>message".  
> 
> 
> I don't see a problem with that, XML signature does not have any
> signature semantics at all.

Different application, different use cases.

> Signature semantics are a function of the PKI, not the application.

No.  If the protocol doesn't say what is meant by signing a message, or 
even restrict the circumstances in which a message can be signed, then 
very little can be assumed about a signature even if it appears to be 
valid.  PKI can have an effect on semantics, but the semantics don't 
have to be determined entirely by the PKI.

> I see the big problem with blacklists as being their total refusal to
> accept accountability to email senders.

That's partially because either they have no way to be sure of what 
they're asserting, or they have to constrain themselves to making 
assertions which might be verifiable but aren't good indicators of 
anything.  If we want reputation servers to work better, we have to 
provide them with data that are both useful and verifiable.

> Its all about accountability.

I don't see how we can have accountability of reputation servers without 
giving them reliable data which can be audited.  We could penalize them 
for providing false negative indications but that alone would make them 
  ineffective against all but the worst offenders.  Everyone would get 
away with spamming a little bit, and everyone's mailbox would still be 
flooded - just with more sources of spam than we have now, and with spam 
that's harder to filter out with heuristics than at present.

> I think that the problem is the common one of thinking that the way to
> get a group to act quickly is to specify the smallest possible charter,
> even if this means that the job is only half finished.

...and even if that means the problem is not understood.

> I think it would be much better to accept that email authentication is
> going to be a longer job.
> 
> Instead of proposing a twelve month charter with minimal deliverables I
> think that the group should have a longer charter, two or three years
> would be more realistic.

Long charters don't seem to work well.  I'd prefer a charter with the 
first deliverable is that the group should produce a detailed 
description of what it takes to solve the problem and a convincing 
explanation of why it will work.  At the rate IETF moves, that will take 
at least a year.  Once that milestone is completed the group could have 
its charter extended to do the protocol work.  But the protocol work is 
the easy part.


> What I don't think is acceptable is a group saying that they are not
> going to address a part of a problem because 'we do not understand it'

I agree, but it's even worse for a group to try to address a problem 
that it doesn't understand, or for a group to make a part of the problem 
that it doesn't understand a necessary component of a solution.

Keith

_______________________________________________
Ietf mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ietf