Subject: RE: Drive Towards Consensus [was Re: On Extensibility in MARID Re cords]

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 22 Jun 2004 07:56:18 -0700

> The extensions of "accreditation, reputation, and rate limiting" which
> Margaret describe fundamentally involve a 3rd party (since 
> rate limiting
> only looks really useful if audited).  If that is correct, 
> the question
> becomes: are these third party assertions something that need to be
> tied to the individual MARID assertions, are they an independent
> pointer within the record, or are they out of scope?

As a matter of fact, I have made a proposal in this space that does not
require audit, except during the manufacture of trustworthy hardware.

ObDisc: Patent claims on the above are pending, no license is granted, etc.

> Let's assume for now that at least the pointers to them are in scope.
> 
> Imagine for a moment that MARID includes an extension that 
> says:  these
> other people also wish to make assertions about me (with the 
> implication
> that the domain knows about it and is willing to point to it).  Is it
> possible to extend MARID to do that?  Sure.  Give those records a 
> similar syntax
> to MARID and it becomes a set of assertions made by two or 
> more different
> parties about the same domain's infrastructure. Silly states 
> then require
> meta-reputation to resolve, but that may not be a big deal. 

I beleive that you will need meta-reputation here for any interpretation.
But that is quite easy to synthesize, you simply observe your own mail
and complaints from users about spam.

> Is it also possible to do that such that it could be attached to other
> assertions, as a generic mechanism for per-attribute 
> reputation/accreditation/certification? 

I am less worried about the interpretation side as the collection side.

I don't want MARID to help interpret data, but I do need it to tell me 
that data exists.

Any positive accreditation service that requires input from the subject
is going to be incomplete. Unless you assume that one company is going
to have a monopoly here you have to be able to link to the accreditor.

> But the usefulness of either goes back to the issue raised by 
> Roy Badami--what
> does this mean in the context of the extension processing?

Since you cannot be required to provide accreditation data a 
processor can always choose to ignore them.

> The WG discussions so far seem to have gone down two processing paths:
> one in which MARID processing iterates through separate 
> assertions until
> one assertion explicitly allows, disallows or marks unknown the 
> message traffic;
> the other in which all the assertions are taken together to 
> create three sets:
> allowed, disallowed, not known.   In the first approach, new 
> assertions can
> easily be defined to have a null affect. 

I would term these 'authentic', 'forgery' and 'indeterminate'.

I am not so keen on the list approach since it does not allow
the semantic 'all messages come from this set of IP addresses
AND are signed'.

>  An alternate approach there is to 
> specify that
> modifiers of a certain type can be ignored such that the base 
> processing
> of the assertions can proceed if they are not understood.  
> That would mean that
> the syntax of the "external pointer" could be left vague 
> right now, as long
> as it is known to be of that type.

I think this is the best approach.

I view the IP address info as being authentication credentials,
the accreditation data is attributes that MAY be used in the
authentication process at the discretion of the recipient.

> A
> common, practical approach at that point is to limit external 
> assertions
> to ones in which "pretend it wasn't there" processing does no
> harm (

I think that we have no choice on this question. Publishing MARID
rules and processing MARID rules are both optional.

In SAML I used a three basket approach, an assertion consists of 
a set of statements, a set of conditions and a set of advice.
If a condition is not understood then the whole assertion must
be discarded.

But SAML could do that because it was a completely new application and
there was no existing deployed base.

> Without stepping on the toes of the original question asked by the
> chairs, I'd be interested in hearing whether anyone believes MARID
> will need the "set construction" mechanism, or whether it can
> go forward with the iterative processing method.  That may
> tell us something about the extension mechanism choices and
> what our core needs for syntax are.

I think it would be useful to introduce a slightly more expressive 
authentication bucket in the XML syntax, specifically:

At present we have a list [A, B, C]
Which is A.B.C 

I would like a set of lists {[A, B, C], [D, E], [F]}
Which is A.B.C /\ D.E /\ F

Where . is defined as: T.x = T, F.x = F, U.x = x
And T /\ x = T, x /\ T = T, U /\ U = U, U /\ F = U, 
	F /\ U = U, F /\ F = F

In other words the SPF precedence rules apply within each list but
the lists themselves are alternatives and the best alternative wins.

---

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 22 Jun 2004 07:59:05 -0700

> >>>>> "Margaret" == Margaret Olson 
> <[email-masked]> writes:
> 
>     Margaret> The rate limiting needs to occur on the sending side,
>     Margaret> but the receiver needs to know what it is.
> 
> But there's no need for the sender to publish the rate limiting
> information, because there's little reason for you to trust them. 

The trust issue is not relevant.

The sender is publishing a CLAIM. It is for the receiver to validate
the claim and decide whether/how to act on it.

> Obviously the ISP's rate limiting policy would have to specify the IP
> addresses that they're responsible for (they can't rate limit mail you
> send out via another source) but this is all information that should
> be published by the ISP, not the sender.

The sender has to inform the recipient of the existence of the data.

> Though, as I said before, I'd like to see a move towards (return to)
> sites originating (and being responsible for) their own mail rather
> than relaying through their ISP...

The anti-spam zealots have done for that plan. Port25 is mostly blocked.