Re: Appeal: Publication of draft-lyon-senderid-core-01 in conflict with referenced draft-schlitt-spf-classic-02

On Wed, 14 Dec 2005, Douglas Otis wrote:

> Actually there was case that came close to this limit by an access
> provider, but was rewritten into CIDR notation to reduce the number of
> records, increasing their chances for error.  At the email
> authentication summit in NY, there was a large company that complained
> they could still not fit into this large limit.  DNS is well designed to
> resolve host names and sub-sets of hosts for a domain.  SPF wants this
> to always be a complete set, even for multiple domains.

Nobody said it wants to be complete set and that all possible ip
addresses must be entered in one spf record of 512 bytes as ip ranges
(although clearly this can be achieved with majority of domains). And
there are in fact people at SPF that believe that it should be more
properly layered and it is desirable to list mx and host names and then 
those are resolved to ip address by A lookup (i.e. like CSV) even though 
that causes 2 lookups instead of just one.

>> Funny how you forget to mention that what is called BATV was invented
>> by people working on SPF - at first as advanced version of SRS, which
>> was thereafter released as SES [1] and anybody with technical knowledge
>> will quickly see that BATV basically implements subset of SES (although
>> I agree that is the more useful subset of that proposal).
>
> The idea of tagging the Return-path was not invented by the SPF group.
> Something like VERP could be an example.  It would be incorrect to
> describe the simplicity of BATV as having a genesis from the SPF group.
> RFC2304 could be called the genesis for the idea.  : )

I did not say "tagged" return path - certainly VERP is predecessor to
SRS in that idea. I did say encrypted address, i.e. using private (or 
public) encryption scheme to create custom "tag" for use in return-path - 
this is what SES is about and what BATV afterward used as well.

> BATV would be the correct choice in my view.  SES attempts the same
> everything and the kitchen-sink complexity that could be seen as the
> hallmark of SPF, which also makes SPF with its problems an integral
> component.

The difference is purely semantic in different formats for return-path
tag. Thereafter you have a choice of which schemes to use which BATV
does not describe in the draft at all and SES describes in quite a bit
of detail but in practice if you don't want to use particular scheme,
you dont have to (as far as I know most people who use SES are doing 
similar with HMAC private scheme as what one person using BATV does).

And BTW as I mentioned similar also applies for its use, SES can be
used independent of SPF implemented on the sender site only processing
incoming bounces, 100% same as BATV. But it can also [optionally] be
implemented as external service [again optionally] integrated with SPF. 
These are all extra functionality one does not have to use if he/she 
does not want to.

What is clear to me is that SES people did not publish their spec right 
and should have separated it into several documents - one describing 
MAILFROM tag semantics [doc 100% equivalent to BATV] and then couple
documents describing signature schemes and then document describing 
public dns validation service and another one for special alternative
udp validation. I told them as much and as you know at some point tried 
to advocate that BATV and SES work together because I thought BATV has
done a good job on writing semantics draft already (which could be made
compatible with everything else with just few changes), where as SES
have done fairly good job describing other details for cryptographic 
signature generation, etc. Unfortunately neither group had any serious
interest in working together.

And as far as my opinion using BATV/SES together with SPF makes more
sense - both in reducing computation cryptographic computation when
it does not have to be used and also because by itself BATV/SES are
easily suspectable to a replay attack.

-- 
William Leibzon
Elan Networks
william@elan.net

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