[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: One Party Consent Model
On Wed, 14 Jul 2004, Markus Hofmann wrote:
> jfcm wrote:
> > 1. the mailing list the information is sent to is part of the
> > information. That information cannot be modified without the agreement
> > of the whole mailing list. If I send a mail to this list saying that you
> > do not understand this point and I make an OPES to remove you from the list
> > - I agree so it is OK by your criteria
> > - you will not respond, so everyone will believe you do not object
> > - I send another mail agreeing but I make an OPES changing the from
> > jfc in from markus (I can do it since I am one end). Everyone will
> > understand that you have agreed not understanding this point
> > ... and you will know nothing of this.
> > 2. Again I am A, you are B and someone is C. An OPES changes B in
> > C. C will be the receiving end. He has agreed to the change. Is
> > that enough? May be if B gave authority to C, maybe not if B has
> > not.
> See your point, but the example you outline above violates the OPES
> tracing requirement, which says that Markus (or B in the generic
> example) must be able to trace the OPES service. I.e. I would be
> aware of the OPES service that removed me.
Tracing does not work for one side if the message is killed or
short-circuited by another side. If I send an HTTP request to a porn
site, my corporate proxy blocks the request, then the porn site will
not know I sent the request. This is a corner case of a message not
reaching the other side at the consent of the originating side.
IMHO, jfc's example is broken (for the lack of a better word) because
when jfc talks about changing distribution lists or From headers, he
assumes both that the mailing list has no reliable authentication
_and_ that unauthenticated changes may have negative affect on
subscribers. Both things are true for most IETF mailing lists!
However, since subscribers know the environment is not secure, but
still subscribe, they accept the risks. In other words, they
technically authorize the adaptations jfc is talking about. They
consent to receive forged e-mails and to being silently removed from
the distribution lists. Both things did happen many times in IETF. I
was even lucky enough to be the subject of the latter.
Thus, we are talking about a two-party consent case. Nothing "bad" is
happening in jfc examples from consent point of view.
In a "good" mailing list environment, jfc would either not be able to
change/forge headers OR doing so would not have an impact on the