Re: the curse of the S(imple) protocols, was: Re: e2e

[Dave Crocker <dcrocker at bbiw.net>]

John C Klensin wrote:
> If was precisely SPF and Sender-ID, and some similar approaches, to which I
> was referring.    And I agree with the skepticism and, based on my personal
> biases, could have said something a lot stronger that "appear to be":  I
> was trying to be as neutral

(every now and again, i too experiment with being politic.)


> as possible in that comment.   One may, of course, be able to substitute
> "one hop in trust relationships" for "one hop in transport", but it is not
> clear how much that changes things.

Probably requires both constraints, to work, given the physical act of
registering source addresses.


> To avoid more of the confusion that comes from not giving examples, while I
> believe that DKIM eliminates some of the problems associated with SPF and
> Sender-ID, I don't see it as eliminating all, or even most, of them _if it
> is used in the

Reasoned discussion about tradeoffs and benefits is always helpful. This space
has not had much of that...

In any event, reasoned proponents of DKIM are clear that it has narrow intent
and narrow benefit.  While some of the constraints are already known, I
suspect most reasoned proponents would expect to discover additional ones.


> But I don't think I understand how/why you believe it constrains 
> anything... it was just an observation that those techniques do have
> skeptics, that there is some evidence that they don't work

Interesting.  You were using "appear to" as a means of raising questions and I
was interpreting it to note the lack of sufficient experience to be able to
say "known to".  So we had pretty much opposite views of the term.  Sorry for
the misunderstanding.

By way of clarifying the point I was trying to make about path-registration
administrative overhead: It is easy to create the first record. By that
measure, the barrier to adoption for a 'sender' can be extremely low.  No new
software and maybe one or a few DNS records.  This is goodness.

But it misses the considerable long-term overhead, having to constantly
anticipate changes to the records, including registering all intermediaries,
such as outsourced sending engines and individual forwarders (such as
acm.org.).  In other words, the path-registration scheme requires upper-level
application work to be cognizant of email topology and to keep accurate
registration for it.

(The irony of this is that the lower network levels are pressing hard to
*de-couple* identification information from location information, and here we
have an email security scheme trying to marry them more closely.


> In other words, too many of the proposals that keep kicking around assume
> that there is a live, direct, online, path, using stable and public IP
> addresses, between the set of systems under close control of the receiver
> and those under close control of the sender and that there are no gateways
> involved.

Yup.


> > Right.  Or perhaps consider alternate techniques that do not impose this
> > limitation?
>
> Sure.   You have any suggestions that don't require any of:
>
> * fundamental changes to how the mail system works, especially changes that
> would make things more difficult for legitimate users with slow,
> intermittent, or very expensive connectivity?  * a PKI or equivalent with
> fairly strong assumptions about user ability to manage keys?  * central
> control of the mail system, or control by a relatively small collection of
> collectively-selected, or regulator-selected or certified, providers?
>
> * treating a new correspondent address as inherently suspicious even if the
> correspondent is well-known and trusted?

Sure.

d/

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net

_______________________________________________
Ietf mailing list
Ietf at ietf.org
https://www1.ietf.org/mailman/listinfo/ietf