third parties (was RE: simplicity, focus and adoption; what probl em are

I agree that a mailing list is a third party. I also believe that is it
possible, and valuable, for someone to make an authorization decision based
on the fact that a message came from that third party. In some authorization
models, I might not even care who originated a message provided that it was
reflected by a particular mailing list. In others, I might care about both
who originated the message and who reflected it, or only who originated it.

That's why I think assertions made by third parties is a separable question,
and therefore admits of a separate solution. We can design a mechanism that
provides an assurance of the identity of the originator (the first party),
and then provide a separate mechanism that allows third-parties like
reflectors to provide their own complementary assurance. The types of
assertions generated are likely to be different enough (in their constraints
and construction, anyway) that they warrant separate design efforts.

Of course, if third parties invalidate the original first-party assertion by
munging the message in some way, that might throw us for a loop - but we
need to come to terms with the fact that this will probably be possible no
matter how we design the first-party assertion. If third parties can
legitimately alter messages in such ways, though, this implies that the
messaging system has a trust model in which recipients already trust those
third-parties to some degree. It is therefore highly appropriate that a
verifier rely on an assertion from the third party to make authorization
decisions in this instance - you already need to trust that third party to
alter content responsibly, and so on. Furthermore, reflectors could in this
case add some sort of verification assertion stating that the reflector
verified the first-party assertion, and again, if recipients already need to
trust these third-parties for other reasons, trusting their verification
assertion doesn't seem problematic. Realistically, something like this has
to be about as well as we can do when first-party assertions are invalidated
by intrusive third parties.

My core point is, if the above seems reasonable, we can come up with a
system for first-party assertions as a first step, and then address the
third-party assertions case with a separate mechanism. I doubt we're going
to make much progress contending with these two separate problems as a
conflated lump. We've stuffed so much food in our mouths here that we can't
chew. We need to slice up the meal a bit first.

Is there any good reason not to just decouple these two properties, and
agree to start with the first-party problem?

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Jim Fenton [mailto:fenton(_at_)cisco(_dot_)com]
> Sent: Thursday, October 28, 2004 10:09 PM
> To: Dave Crocker
> Cc: IETF MAILSIG WG
> Subject: Re: simplicity, focus and adoption; what problem are 
> we trying
> to solve?
>
>
>
> At the risk of repeating some points that have already been 
> made by others...
>
> At 07:37 AM 10/28/2004 -0700, Dave Crocker wrote:
> > For the current discussion, we need adoption by sending sites and 
> > receiving sites (and, here, the different between adoption 
> by mtas vs. 
> > muas is irrelevant).  Mailing Lists are just one more example of 
> > adoption.  
>
> I see mailing lists as being different because they're in 
> series between the (original) sender and an eventual 
> recipient.  So now there are three parties that have to 
> implement message signing and verification in order for 
> message signing to work for a particular message.  That has 
> got to be slower on the average than when only two parties 
> were required to deploy.
>
>
> > Treating mailing lists as a special concern introduces significant 
> > additional complexity to the specification, makes end-to-end 
> > performance significantly more problematic -- by defining the 
> > end-points as crossing an intermediate UA -- and is just as 
> likely to 
> > frustrate user expectations as it is to aid them.
>
> I don't think the architectural model of a mailing list 
> (back-to-back UA, or multi-pronged forwarder, to name two) 
> matters a whole lot here.  The question is whether we should 
> make some effort -- and not a large one -- to try to help 
> messages pass validation if they have been modified in 
> transit, whether it's by a mailing list, or by an MTA that 
> adds a legal disclaimer or advertising statement to a message.
>
> Some/most of the signing proposals include options for 
> canonicalizing the signed content.  Do you also disagree with this?
>
>
>
>
> > > We should make some attempt to get
> > >  message signing to work with at least some mailing lists to make
> > >  it more effective before the lists upgrade.  
> >
> > We should also make some attempt to get message signing to work with 
> > at least some personal Forwarding or Resending.  
> >
> > Or maybe we shouldn't.
> >
> > Maybe survivial of the signature across re-postings is not a goal.
>
> Or maybe it is.  That's the question.
>
>
> > Maybe we should define a simple, clean service, that has a 
> constrained 
> > goal and constrained specification.  That way it will be easier to 
> > understand and implement and it will work predictably.  This 
> will make 
> > adoption and use far easier.
>
> Simple and clean are relative terms.  I would argue that IIM, 
> with body length counts and header copying, is still simple, 
> clean, and constrained.
>
>
> > I am trying to imagine designing any other Internet protocol 
> that has 
> > special features to hack around transient adoption concerns.  
>
> Any protocol that negotiates options for, say, an obsolete 
> authentication technique or encryption algorithm has a 
> special hack around a transient adoption concern.  I'm sure 
> there are others on the list that can supply specific examples.
>
>
>
> > >  I agree, but this is a different issue entirely.  In the absence
> > >  of mailing lists that re-sign, the original sender signature will
> > >  be the only one available.
> >
> > The problem is that, in a very real sense, it will not be 
> valid and it 
> > should not be!
>
> Are you saying that this mechanism, as you envision it, is 
> broken when a mailing list does not modify the message nor 
> remove the signature?  Because the signature will be present 
> and will verify successfully in some cases.
>
>
> > Let's step back and ask what the purpose of this signature is.
> >
> > The purpose of the mailsig mechanism is:
> >
> >                Provide an assertion of message transit origination 
> >                accountability that can be validated.  
>
> Please remind me where this is from.  I'm trying to parse the 
> phrase "message transit origination accountability".  This 
> isn't clean and simple!
>
>
> >                The use of this accountability is during 
> message reception, 
> >                to assess likely acceptability.
> >
> > We are not trying to replicate pgp or s/mime.  We are trying 
> to serve 
> > an entirely different purpose.  We are trying to say who is 
> > responsible for injecting this message into the message transfer 
> > service.
> >
> > The mailing list  processor is responsible for injecting the message 
> > into the transfer service.  Therefore the only signature 
> that is valid 
> > for mail coming from it is the mailing list signature.  The original 
> > authors are not accountable for the potentially arbitrary 
> behavior of 
> > mailing list processors.  
> >
> > Let's not design a specification that pretends otherwise.
>
> We aren't pretending otherwise.  It is clear exactly what the 
> original author signed, and the recipient can decide whether 
> to accept the "arbitrary behavior" or not.
>
>
>
> > >  I consider a valid signature that is based on the 2822 From
> > >  address to be more valuable than another one applied later because
> > >  it signs the address that I will be looking at in my MUA; 
> >
> > There is no automatic requirement that the recipient user 
> see anything 
> > about the signature.  
> >
> > Really.
>
> You can't require that the recipient user see anything.  But 
> most MUAs I have seen display From and not Sender, and I want 
> to encourage display of the address that was signed.  If 
> there is a valid signature corresponding to the From address, 
> that requirement is satisfied (except maybe for Outlook).
>
> -Jim