ietf-asrg
[Top] [All Lists]

Re: [Asrg] Re: Washington Post: Earthlink to Deploy a Challenge-Response System for Fightin

2003-05-07 20:44:04
On Wed, 07 May 2003 21:20:22 -0600 
John Fenley <pontifier(_at_)hotmail(_dot_)com> wrote:

Yes a mailing list could give this and that, and it could be checked
this or that way. But a standard method, with standard tools, and a
standard method of accessing it would be usefull to many more people.

As I've previously mentioned I've been noodling on a consent token
protocol.  It here follows:

--<cut>--
I'm sending this now, in its rough'n'ready state as if I don't I likely
won't get to send it at all.  This is a set of loosely structured notes.
If you want EBNFs and protocol FSM diagrams, this isn't going to be it.
If you'd like to help phrase this in more IETF/RFC friendly form, I'd
welcome your assistance.  As I mentioned, this is primarily a set of
workin notes.

Premises:

  No such system is perfect.  This system is in particular very
  imperfect.  The definitions that humans use to define their
  relationships, preferences and value sets are subjective and
  contextual.  This system cannot and does not attempt to reflect
  such concerns.  Instead, this system merely attempts to provide a
  method which allows relationships to be recorded as a set of
  "rights granted", and for subsequent manipulation of those granted
  rights by manipulation of the records of the granted tokens.

This is not Challenge/Response:

  This is not about challenge/response systems, does not require or
  define a challenge response system and in fact has little to do
  with challenge response systems.  That said, a challenge response
  system could trivially be used in close cooperation with this
  system.

  This system describes how consent tokens can be encoded in
  messages, manipulated by messages and MUAs, and otherwise used.
  It does not state the processes required to generate a consent
  token, either on the part of the humans involved, or the software.
  Challenge response systems could be used, but are not required.

This is not PKI or crypto:

  There is no need or requirement in this system for crypto or PKI
  beyond a possible use of one way hashes in constructing consent
  tokens.  There is also no need or use of custom DNS entries at any
  point in the system.

Basic model:

  People can agree, explicitly or tacitly, to accept email from each
  other.  To express this agreement they give each other tokens
  which we'll call, "consent tokens".  Subsequent email from each
  party bears the token the other gave them, thus demonstrating that
  they are someone who has been granted permission/consent by the
  recipient.

    Very loosely the model can be described as, "Here is a special
    key.  When you see me a again, bring this special key with you
    so I can recognise you."

  To a large extent the possession of the token could be considered
  a "what you know" in the standard security model of
  identification.  To prevent replay/spoof attacks, the consent
  tokens may contain (implementation dependent detail) one way
  hashes of key difficult to forge data, like Return-Path and From:
  (both), thus providing an easy method of validating a token in a
  given message against the message.

The following proposal discusses how such tokens may be defined, how
they can move between people's systems, and thusly, how they may be
used.

Purposes:

  The fundamental purpose of the consent token protocol is to allow
  messages to be identified as consensual or not.  By this is meant
  that the recipient of the message can determine if a given message
  he receives is a continuation of a prior relationship which he
  approved of, or is a message from a stranger or unwelcome source.

  Attempts to deduce consent by any other means than, "continuation
  or expansion of prior relationship" is not addressed by this
  protocol.

Requirements:

  Resistant to forgery and obvious attempts to evade, manipulate, or
  compromise.

  Does not require PKI.

  Friends must be able to easily email friends.

  People must be able to establish consensual relationships.

  People must be able to encode tentative consensual relationships
  for things like printed media, business cards, and the like.

  Mailing lists must work, well.

  Replies to a prior post must be able to be recognised as such.

  Email sent to an address provided by means other than SMTP (eg web
  based subscription or response to web-base marketing) by the
  service the address was passed to should not be interfered with.

  The protocol should be friendly to people using software and
  systems which DON'T support the consent token protocol, and should
  fail gracefully for those using non-supporting systems.

  Throw-away addresses should be easy (eg for use in posted small
  ads, conference registrations, etc) and should not require ISP
  involvement.

Consent Token Definition:

  A consent token is a 7-bit clean string which is assumed to be
  opaque to everyone but the author of the token.

  Opacity in this regard simple indicates that meaning can be
  extracted from the consent token string by the creator of the
  token, but that no such meaning is necessarily (reliably)
  derivable by others.  Opacity is not a requirement of a consent
  token, but is easy to achieve and has a number of values when
  present.

  The basic use of a consent token is as a frank on messages sent to
  the originator of the token to show that you are party to the
  shared secret encapsulated in the token.

  What this proposal defines:

    When and how consent tokens are originated.

    When and how they may be requested.

    How consent tokens can be used to facilitate naturally friendly
    human communication.

    How the protocol supports maintenance of consent tokens.'

  The consent token protocol is not intended to define:

    How a consent token is constructed.

    What a consent tokens looks like (beyond being a 7bit clean
    ASCII string suitable for use in email addresses and
    Message-IDs).

    How meaning is encoded into a consent token.

    How meanings are to be encoded into consent tokens.

  Loosely, this is a definition of a means of transport, not what
  the transport may carry.

  Note however that a number of basic "meanings" are suggested for
  consent tokens, and are used to exemplify and illustrate how the
  consent token protocol functions.  These are however
  implementation specific details that are beyond the scope of this
  article, and are used for illustrative purposes only.

Consent token types used in discussion and possible implementations
of types:

  Intellectually this proposal is built on the work of TMDA and its
  use of special strings encoded in plus address to encode various
  forms and levels of consent.  It is strongly suggested that
  readers review TMDA, its capabilities, and in particular the
  various forms of consent TMDA can encode.

  For the purpose of this article the following forms are assumed
  encodable in a consent token.

    - The token is valid for mail from a specific Return-Path
    (called a "sender address token").

    - The token is valid for mail from a specific From: (called a
    from address token).

    - The token is valid for mail for a specific date range from the
    time of origination of the token (called a "dated token")

    - The token has no validity criteria, but does encode a value
    (typically a word or some other human-useful character sequence)
    which can be used to differentiate it from other always valid
    consent tokens (called a "keyword token").

  In addition all the above types may be combined in the various
  permutations, producing such things as a, "dated sender and from
  address token", or a "dated keyword token", and so forth.

  A given token type, embedded in an email address, creates an
  address of that token type.  eg a dated address, a sender address,
  etc.

  A simple way of encoding such data is via an one-way hash of the
  relevant data with a secret.  A received token is first parsed to
  see what sort of data is encoded in it, the relevant data is then
  extracted from the message, and a duplicate token computed using a
  constant secret.  If the two tokens match, then the stated consent
  relationship is validated.

    Note: TMDA has a rather clear implementation of this sort of
    arrangement for almost all of the above token types.

  Please note that these are are not required consent token forms,
  they are merely used as models and examples in showing how the
  consent token protocol works.  Implementations may freely choose
  their own consent token definitions and encodings.  None of the
  above are necessary for the protocol.

Acting on Consent Tokens:

  This proposal does not define how a supporting MUA will act upon
  consent tokens it successfully or unsuccessfully validates.  There
  re many possibilities and this is one of the many areas left as an
  implementation and end-user configuration choice.

  Several possible handlings are envisioned for messages with tokens
  that fail to validate:

      - Message is rejected/bounced.

      - Message is discarded silently.

      - Message is held pending a successful response to a challenge
      response system.

      - Message is filed by the MUA in a location or with an
      annotation that its token is bad (there could be several
      grades of such annotations, for example depending on how far
      expired the dated token was)

      - Message is filed normally.

  As there are many possible types and degrees of consent token
  validation failures, the number and range of possible responses
  could be equally large.  This is a question for end-user
  implementation and configuration, as it doesn't affect or define
  the protocol.

    Note that this ground has already been partially explored by
    TMDA.  Additionally its also very easy to build complex and
    rather arcane systems using consent tokens, as the TMDA
    documentation amply shows.  The intent of this protocol is not
    to require such complex systems, but to build a very simple base
    that people can use and adapt as they need and want.

Consent Token Embedding:

  Consent tokens are encoded in three basic places:

    1) Message-IDs.

    2) Plus addresses (care is taken to make this human-friendly)

    3) A small range of X- headers for specific protocol state
    transforms.

  Note:

    Tokens are encoded in email addresses (or Message-IDs which are
    like email addresses) as plus addresses.  In particular consent
    tokens are not dealt with as discrete items by anything other
    than the system which generated that specific token and bearing
    address.  As far as recipients are concerned, a token can be
    considered inseparable from its bearing email address.  More
    particularly, it is assumed that there is no necessarily
    reliable way for a third party to examine an arbitrary address
    which is carrying a consent token (via plus address) and
    determine which bits are the consent token and which the base
    address.

    No definitions are made about how plus addressing is to be
    accomplished or what plus addressing character is to be used.
    That is an implementation detail that only concerns the
    receiving MTA and MUA in that they have to be able to recognise
    addresses for delivery (MTA) and to extract consent tokens for
    analysis (MUA).  It has no bearing or relation to the rest of
    the world, and is outside of this protocol definition.  That
    said, typical choices for plus address characters are '+' and
    '-'.  The TMDA FAQ contains a useful commentary on the use of
    each and their impact on currently deployed mail systems.

  Use of Message-IDs:

    The use of consent tokens in Message-IDs provides the ground work
    that much of the rest of the system is built on.  A supporting MUA
    will:

      1) Encode a Message-ID which contains a consent token in every
      message it originates.  As Message-IDs have the same structure
      and encoding limits as email addresses, a plus addressing form
      may be used to encode the consent token into the Message-ID
      value.

        The explicit assumption here is that subsequent systems will
        not remove or alter any Message ID so defined.  This is
        already known to be an unreliable assumption.  Specifically
        some list servers on broadcasting a message will generate a
        new Message-ID for the broadcast message.  This is explicitly
        allowed by current standards, but is censured by this
        protocol.

        Note that the meaning encoded into the consent token is an
        end-user configuration, but would likely be either a dated
        token, a keyword token, or a dated keyword token.

      2) Check the Message-IDs in the In-Reply-To and (optionally)
      References: headers, and extract and check any consent tokens
      from the current system.

        The assumption here is that replies to a message generated
        by the local system will have a correct In-Reply-To header,
        and that subsequent messages in the thread will have correct
        References: headers.  These assumptions are known to be
        unreliable.  Some commonly used MUAs don't generate
        In-Reply-To or References headers at all.

      3) Correctly generate In-Reply-To: and References: headers for
      replies.

  In the handling of consent tokens in sending mail to addresses
  which have extant consent relationships there are three choices
  here, none fully elegant.  The local system can rewrite the public
  headers (To:, Cc:, Bcc:) to use a plus-address provided by the
  other end of the consent relationship, an X- header can be used to
  encode the token on a per-address basis, or the SMTP envelope can
  be set by those MUAs which speak SMTP to use the appropriate
  consent tokens.

  Taking them in reverse order:

    Encoding the consent tokens in the envelope runs into the
    problem that there is no standardised way for LDAs and MDAs to
    encode Envelope-To: in a message for MUA processing.  Envelope
    encoding is also fragile across .forwards and aliasesq, and this
    system needs to be robust in those cases.

    Encoding the consent tokens in X- headers is effective, but has
    the slightly displeasing problem of encoding BOTH the flat
    version of the address and the tokenised version of the address
    in the same message, which is an unwelcome information leak fir
    third parties, and acts as a tacit consent for addresses bearing
    consent tokens to be sent to third parties, uninvolved in the
    relationship expressed by the consent token.

      Principle: The only people who should ever see an address
      bearing a consent token are the people involved in the
      relationship expressed by the consent token.

    Rewriting the public headers to encode the consent tokens can be
    offensive if consent data is encoded in headers of a message to
    sent to someone outside of the relationship.  Using the
    consensual forms of an address in public headers to someone
    outside of the relationship creates a utility problem in that it
    makes published a consent address as if it were a base address
    for those people.  Not good.

    Some explanations via example

      For example if a given message is sent to Bubba and CC'ed to
      Boffo:

        From: me(_at_)domain
        To: bubba(_at_)domain
        Cc: boffo(_at_)domain

      The system could rewrite all the headers at once:

        From: me(_at_)domain
        To: bubba+consent-token(_at_)domain
        Cc: boffo-consent-token(_at_)domain

      This presents a problem.  If Bubba wants to privately email
      Boffo, and he didn't previously know him or his address, he's
      going to email boffo-consent-token(_at_)domain which is wrong, as
      Boffo's system will fail to validate the consent token if it
      was unique to me(_at_)domain

      Ergo, the correct behaviour is to send to discrete messages,
      each with separately rewritten headers:

        1) Envelope-To: bubba+consent-token(_at_)domain
           From: me(_at_)domain
           To: bubba+consent-token(_at_)domain
           Cc: boffo(_at_)domain

        2) Envelope-To: boffo-consent-token(_at_)domain
           From: me(_at_)domain
           To: bubba(_at_)domain
           Cc: boffo-consent-token(_at_)domain

      This way each recipient sees the "public" forms of the
      addresses for other people he expects/recognises, and the
      consent-token address for himself that his system recognises.

      Notes:

        This effectively requires that MUAs not deliver mail via
        `sendmail -t`, and instead only use SMTP or `sendmail -bm`.

        This makes some forms of system optimisation more difficult
        (RCPT TO bundling).

    The problem with rewriting the public headers for the current
    recipient is that there are no public headers for the current
    recipient in the case of a BCC (such as in the mailing list
    case).  In the BBC case the consent token has to be encoded
    somewhere else, such as in an X- header.

Use of X- Headers as a Command Layer:

    X- headers are fundamentally useful for negotiations in the
    consent protocol.  A core problem is that the consent token
    protocol needs to usable by end-user systems which don't support
    it, across language barriers, and across human disability
    barriers (eg blind).  The problem then is to encode data into a
    protocol negotiation message which can be reliably machine
    parsed so that a supporting MUA can Do The Right Thing, while
    also encoding human-comprehendable data in the same message so
    that humans using non-supporting systems can process the message
    intelligently and usefully.

    The basic idea here is that the machine parse-able data is
    encoded in canonical forms in defined X- headers, leaving the
    message body free to contain something human friendly, which can
    be adapted to foreign languages, users with disabilities,
    suitably localised, etc.  In this line the message body would
    communicate the meanings of the below X- headers as appropriate.

      Note: By default, messages between consenting parties will
      need no special X-headers to express the consent
      relationships, as that data is encoded in the rewritten public
      headers on each message.

    The basic consent token negotiations (ie the arcs on the finite
    state machine graph) are:

      1) Grant/send a consent token

      2) Request a consent token for the sending address.

        a) Request a consent token for a third party address.

      3) Update/change an already granted consent token

      4) State that a previously granted consent token has been
      revoked.

      5) State that a received message has failed consent validation
      (for whatever reason).

      6) Apply a consent token to a previously received message
      which didn't bear a token (or bore an invalid token).

    The lexicon of consent token protocol X- headers is:

      X-Consent: <address(_at_)domain>

        States the consent-token address which can be used in future
        correspondence.  A receiving MUA should update its internal
        data with this address so that it can automatically
        substitute it in future mail sent to the address in From:.
        User's of not-supporting MUA's can manually enter the
        address into their email aliases/list so that their MUA can
        do the Right Thing at alias expansion time.

      X-Consent-Token: address

        In the case that the recipient of the message is not present
        in the To: or CC: headers (ie a BCC), meaning that no
        there's no direct opportunity for encoding a consent token,
        the consent token address used may be placed in an
        X-Consent-Token: header for the BCC'ed address.  The
        __ONLY__ time an X-Consent-Token: header should be used is
        for BCC's to the receiving address.  Use of this header in
        all other cases is an error.

          Note: In the case where a mailing list sends a message to
          an address which is already present in the public headers
          (eg courtesy copy), an X-Consent-Token: header should be
          used as, as those headers don't apply to this instance of
          the message over this transport.

      X-Consent-Update: <address(_at_)domain>

        Explicitly states that the receiving MUA should discardand
        previously acquired consent token for the address and
        replace it with this header's value.  A receiving MUA should
        update its internal data with this new consent token address
        for future use.  Note that the received message should have
        a validating consent token to update.  Users of
        non-supporting MUAs can manually update their email alias
        lists.

        Typically this header would be used when upgrading someone's
        consent token to a more privileged form (eg extended or
        changed date range, removal of date range etc).  This header
        should only be used on messages which contain no other data
        (ie messages which are dedicated to handling a token update)
        so that receiving systems can be safely configured to handle
        then automatically.

      X-Consent-Request: from(_at_)domain return-path(_at_)domain

        States that the sender wants a consent token address from
        the recipient, and encodes the value of From:/Return-Path:
        that may be used in encoding the consent token (token
        generator's choice as to what data he uses if any).

        Typically a reply to a message bearing this header will
        contain an X-Consent: header.  Depending on implementation
        and end-user configuration, this may happen automatically,
        or after an end-user confirmation or some other process such
        as a challenge/response.

      X-Consent-Request-For: <address(_at_)domain>

        A message bearing this header requests that a message
        containing an X-Consent: token grant be sent to the stated
        address.  Note that received message should bear a
        validating consent token.

        This header should only be used on messages which contain no
        other data so that receiving systems can be safely
        configured to handle such requests automatically.

      X-Consent-Revoked: <address(_at_)domain>

        Tells the recipient MUA that the stated consent token
        address has been revoked and should not be used any more.
        If it is accompanied by an X-Consent: header, this is
        effectively analogous to an X-Consent-Update: header.  Note
        that the received message should have a validating consent
        token.

        This header should only be used on messages which contain no
        other data (ie messages which are dedicated to handling a
        token update) so that receiving systems can be safely
        configured to handle then automatically.  The receiving MUA
        is of course not obliged to honour the request.  This is an
        informational header only.  Enforcement and application of
        token semantics occurs with the MUA that originated the
        token.

      X-Consent-Release: message-id

        Instructs the receiving MUA to consider that a message with
        the stated Message-ID is carrying the consent token that the
        current message is carrying.  Note that message bearing this
        header should have a validating consent token,.

        This header should only be used on messages which contain no
        other data (ie messages which are dedicated to handling a
        token update) so that receiving systems can be safely
        configured to handle then automatically.  Typically this is
        used in automatic (unattended) response to a message with an
        X-Consent-Held: header.  See below for details.

      X-Consent-Held: message-id

        Typically sent to the Return-Path: of the received message,
        optionally with the held message attached as a
        message/rfc822 part (useful if the sender doesn't have a
        consent token for the recipient, unnecessary if he does have
        a consent token for the recipient), this header tells the
        receiving MUA that a message with the stated Message-ID is
        being held or potential-spam-filed etc due to consent token
        failure or absence.

        This header, along with X-Consent-Release: can form (not
        required) the grounds of a basic fully-mechanised consent
        token challenge/response system.  If the received message
        bears a validating consent token, the receiving MUA can
        safely reply with an X-Consent-Release: header.  If the
        received message doesn't have a consent token, then the
        receiving MUA may present the choice to the user or act as
        configured by the user.

        This header should only be used on messages which contain no
        other data (ie messages which are dedicated to handling a
        token update) so that receiving systems can be safely
        configured to handle then automatically.

Deployed MTA requirements:

  Deployed MTAs would require the following configuration aspects:

    1) Support for plus addressing.  Happily all current versions of
    all common MTAs support plus addressing, and have done for
    several years.

    2) Do not replace MUA-generated Message-IDs.

    3) Encode the return path from the message envelope in a
    Return-Path: header in the received message.  Exim and I'm told
    Qmail do this by default.  I've not yet checked other MTAs.


Examples:

  Note that in the folloing examples the string "consent-token" is
  mean to indicate the prsence of some form of consent token.  It
  states nothing about the value of the token, or how it relates to
  other values of "consent-token".



    Bubba emails Boffo (a stranger) requesting help:

      Return-Path: bubba(_at_)domain
      From: bubba(_at_)domain
      To: boffo(_at_)domain
      X-Consent: <bubba+consent-token(_at_)domain>
      Message-ID: <bubba+consent-token+someothergarbage(_at_)domain>
      Subject: Please help me.

    Boffo has is his mail forwarded to weird_address(_at_)domain, and
    further, doesn't use a an MUA which supports the consent token
    protocol.  He replies:

      Return-Path: weird_address(_at_)domain
      From: weird_address(_at_)domain
      To: bubba(_at_)domain
      In-Reply-To: <bubba+consent-token+someothergarbage(_at_)domain>
      Subject: Re: Please help me.

    Bubba's MUA doesn't recognise the weird_address(_at_)domain, but does
    recognise the Message-ID in the In-Reply-To: and successfully
    extracts the consent token from it and handles appropriately.



    Bubba emails Bernie (a stranger) requesting help:

      Return-Path: bubba(_at_)domain
      From: bubba(_at_)domain
      To: bernie(_at_)domain
      X-Consent: <bubba+consent-token(_at_)domain>
      Message-ID: <bubba+consent-token+someothergarbage(_at_)domain>
      Subject: Please help me.

    Bernie has is his mail forwarded to some_guy(_at_)domain, and
    further, uses an MUA which supports the consent token protocol.
    He replies:

      Return-Path: some_guy(_at_)domain
      From: some_guy(_at_)domain
      To: boffo+consent-token(_at_)domain
      In-Reply-To: <bubba+consent-token+someothergarbage(_at_)domain>
      X-Consent: <boffo-consent-token(_at_)domain>
      Subject: Re: Please help me.

    Bubba's MUA doesn't recognise the weird_address(_at_)domain, but does
    recognise the consent token address in the To: field, and
    successfully extracts and handles the consent token.  Further,
    Bubba's MUA notices the X-Consent: header that Bernie's MUA
    added, and sores that address away for future use so that the
    next message Boffo sends Bernie will automagically be sent as
    follows (even tho Bubba enters bernie(_at_)domain):

      Return-Path: bubba(_at_)domain
      From: bubba(_at_)domain
      To:: boffo-consent-token(_at_)domain
      X-Consent: <bubba+consent-token(_at_)domain>
      Subject: About something else...



    Bubba wants to setup a consensual email relationship with Billy
    (a stranger):

      Return-Path: bubba(_at_)domain
      From: bubba(_at_)domain
      To: billy(_at_)domain
      X-Consent: <boffo+consent-token(_at_)domain>
      Message-ID: <boffo+consent-token+othergarbage(_at_)domain>
      X-Consent-Request: bubba(_at_)domain bubba(_at_)domain
      Subject: Let's work together

    Billy's MUA doesn't support consent token negotiations, and so
    he sees (lame attempt at an example human friendly message
    body):

      Return-Path: bubba(_at_)domain
      From: bubba(_at_)domain
      To: billy(_at_)domain
      X-Consent: <boffo+consent-token(_at_)domain>
      Message-ID: <boffo+consent-token+someothergarbage(_at_)domain>
      X-Consent-Request: bubba(_at_)domain bubba(_at_)domain
      Subject: Let's work together

      bubba(_at_)domain would like to exchange email with you in a
      trusting spam-free way.  If you want to send mail to him in
      future, please use the following address:

        boffo+consent-token(_at_)domain

      bubba(_at_)domain's email system will automatically recognise mail
      sent to that address as from you and not forged or spam.

      What address would you like bubba(_at_)domain to use in emailing
      you?  Please reply with the particulars.  If you'd like
      bubba(_at_)domain to continue using the address this message was
      sent to, billy(_at_)domain, you don't have to do anything.

    If Billy used an MUA which supported the protocol, his MUA would
    recognise the X-Consent-Request header and act upon it.  It
    could query Billy for the appropriate action (perhaps by pop-up
    dialog), or if configured to, perhaps even reply automatically
    with a consent token with a short date range validity (say 2
    days).



    Bubba subscribes to a mailing list run by a list manager which
    supports the consent token protocol:

      Return-Path: bubba(_at_)domain
      From: bubba(_at_)domain
      To: list-request(_at_)domain
      X-Consent: <boffo+consent-token(_at_)domain>
      Message-ID: <boffo+consent-token+someothergarbage(_at_)domain>
      Subject: subscribe

      Return-Path: list-admin(_at_)domain
      From: list-admin(_at_)domain
      To: bubba+consent-token(_at_)domain
      In-Reply-To: <bubba+consent-token+someothergarbage(_at_)domain>
      X-Consent: <list-admin-consent-token(_at_)domain>
      Message-ID: <list-consent-token+someothergarbage(_at_)domain>
      X-Consent-Request: list(_at_)domain list(_at_)domain
      Subject: Please confirm your subscription by replying

      Return-Path: bubba(_at_)domain
      From: bubba(_at_)domain
      To: list-admin-consent-token(_at_)domain
      X-Consent: <boffo+consent-token(_at_)domain>
      Message-ID: <boffo+consent-token+someothergarbage(_at_)domain>
      In-Reply-To: <list-consent-token+someothergarbage(_at_)domain>
      Subject: Re: Please confirm your subscription by replying

    Note how the consent tokens are automatically negotiated and
    maintained without the human user's involvement.  The user's MUA
    primes the pump (and thus tells the list manager that he
    supports the consent protocol) by having an X-Consent: header in
    the initial subscribe message.  Similarly, the list server
    primes the pump for the user's MUA by providing the relevant
    details in its X-Consent-Request: header so the MUA can reply
    with a suitably generated consent address, potentially using
    that data.



    Bubba subscribes via web form to a mailing list run by a list
    manager which supports the consent token protocol:

      Your email address: bubba(_at_)domain <SUBMIT>

      Return-Path: list-admin(_at_)domain
      From: list-admin(_at_)domain
      To: bubba(_at_)domain
      X-Consent: <list-admin-consent-token(_at_)domain>
      Message-ID: <list-consent-token+someothergarbage(_at_)domain>
      X-Consent-Request: list(_at_)domain list(_at_)domain
      Subject: Please confirm your subscription by replying

      Return-Path: bubba(_at_)domain
      From: bubba(_at_)domain
      To: list-admin-consent-token(_at_)domain
      X-Consent: <boffo+consent-token(_at_)domain>
      Message-ID: <boffo+consent-token+someothergarbage(_at_)domain>
      In-Reply-To: <list-consent-token+someothergarbage(_at_)domain>
      Subject: Re: Please confirm your subscription by replying

    Again the consent process is kicked off in the initial mail
    transaction with all the tokens being generated and tracked from
    there.  The fact that Bubba didn't provide a consent token via
    the web form actually doesn't matter.



    A list server upgrades to a new version which supports the
    protocol.  All that need happen is that X-Consent*: headers
    start being injected in standard list traffic, with supporting
    MUAs picking up the slack/line as they go, and the rest silently
    not noticing (ditto for users that start using MUAs that support
    the protocol):

      Return-Path: list-bounce(_at_)domain
      From: some_guy(_at_)domain
      To: some_other_guy(_at_)domain, list(_at_)domain
      X-Consent: <list-admin-consent-token(_at_)domain>
      Message-ID: <some_guy-consent-token+someothergarbage(_at_)domain>
      In-Reply-To: <some_other_guy-garbage(_at_)domain>
      X-Consent-Request: list-bounce(_at_)domain list(_at_)domain
      Subject: [LIST] Re: I heard a funny joke...

Requirement satisfaction:

  Resistant to forgery and obvious attempts to evade, manipulate, or
  compromise.

    Answer: Consent tokens are encouraged to be one way hashes using
    a per-user secret.  Given reasonable choices for the hash
    algorithm and secret size, compromise is difficult.

  Friends must be able to easily email friends.

    Answer: If they both use supporting MUAs, it all happens for
    free.  If they don't, then token encoding in Message-IDs takes
    up most of the rest of the slack, with the encouragement for
    them to enter the consenting addresses in their email address
    books being used to fill the rest of the gap.  If they don't use
    their address books in this way, then the system is no worse
    than it is currently.

  People must be able to establish consensual relationships.

    Answer: That's what the consent tokens do.

  People must be able to encode tentative consensual relationships
  for things like printed media, business cards, and the like.

    Answer: Use of a simple plus address form can do this.  For
    example bubba(_at_)dom(_dot_)aim when hading his business card to a
    colleague at a conference could quickly pen in an alternate
    address to bypass his consent/spam filters: 
bubba+word(_at_)dom(_dot_)ain(_dot_)
    Its not a one-way hashed consent token, but if he uses a
    different word every so often, and tells his mail system what
    his current word choice is, it can and will cover a very large
    part of the gap (personal experience).

  Mailing lists must work, well.

    Answer: See examples above.  Very little changes with the
    exception that mail to consent token supporting users becomes
    per-recipient customised (header re-writing).  This is a
    marginal incremental cost over list servers that already use
    VERP, but could be considered expensive by those that don't.

  Replies to a prior post must be able to be recognised as such.

    Answer: Encoding consent tokens in Message-IDs does this for
    responding MUAs that properly generate In-Reply-To: and
    References: headers.  Currently broken MUAs continue to be
    broken.  For everybody else the world improves.

  Email sent to an address provided by means other than SMTP (eg web
  based subscription or response to web-base marketing) by the
  service the address was passed to should not be interfered with.

    Answer: See the list subscription case above.  It does require
    an additional round of email exchange to prime the consent token
    pumps, but given the current mandate on double-opt-in, this
    seems reasonable.

  The protocol should be friendly to people using software and
  systems which DON'T support the consent token protocol.

    Answer: This is accomplished by requiring that specific arcs in
    the FSM (ie token negotiations) occur via messages which don't
    carry any non-token-related content.  Because of this the
    message payloads can be human-friendly and explanatory for
    non-supporting MUAs (supprting MUAs will likely hide the message
    entirely and either handle them automatically or present the
    user with a custom dialog with help links).

  Throw-away addresses should be easy (eg for use in posted small
  ads, conference registrations, etc) and should not require ISP
  involvement.

    Answer: Dated addresses solve this need.
--<cut>--

-- 
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
claw(_at_)kanga(_dot_)nu               He lived as a devil, eh?           
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg