[dmarc-ietf] Authentication: what is needed and why ARC is needed to acheive it.

[Douglas Foster <[e-mail]>]

Since Michael's Hammer complaint that I was taking the discussion off
topic, I have been trying to focus my thoughts and words to explain what
ARC does that cannot be replaced by DKIM2.   This is the result.

There are three types of authentication used when messages are passed
between organizations:   ARC suffers from a failure to distinguish these
three types of authentication, and fails to provide sufficient tools to
document them.   ARC needs to be fixed, not scrapped.

   - Client authentication applies to the initial connection between a
   submitting agent and a submission server.   An ARC set that documents
   client authentication must be the originating organization.   The client
   authentication ARC set will either preceed the first Received header field,
   or will follow a Received header that documents the submission connection.
    The known types of authentication are login credentials or trusted IP
   address, but the technique does not need to be documented because the
   originating organization is always assumed responsible for authenticating
   its submission clients.   The ARC set needs to include the RFC5321.MailFrom
   address, the RFC5322.From address, an authentication Pass indicator, and
   the Client Authentication indicator.

   - Server authentication applies to the connection between a client
   organization and an outbound gateway service.   The service needs to
   authenticate the client connection to ensure that it can properly invoice
   the client for services rendered.    The authenticated server is authorized
   to send messages for any address in the client domain(s).   The ARC set
   needs to include the Source IP and Helo name of the client's server and the
   Received-By name of the accepting server, so that the ARC set can be linked
   to the ARC set which documents the connection.  The ARC set also needs to
   include the RFC5321.MailFrom address, the RFC5322.From address, an
   authentication Pass indicator, the Server Authentication indicator, and the
   type of authentication.     The known types of authentication are server
   credentials, trusted IP, SPF Pass, and DMARC Pass based on DKIM.

   - Message authentication applies to all other intermediary
   connections.   The ARC set needs to include the Source IP and Helo name of
   the client's server and the Received-By name of the accepting server, so
   that the ARC set can be linked to the ARC set which documents the
   connection.  The ARC set also needs to include the RFC5321.MailFrom
   address, the RFC5322.From address, an authentication Pass indicator, the
   Message Authentication indicator, and the basis of authentication.   The
   known types of authentication are SPF Pass, DMARC Pass based on DKIM,
   trusted forwarder, and local policy/private knowledge.   An example of
   private knowledge is a server that knows that Example.Com is hosted on
   Outlook.com, even though the domain has an SPF Policy that is missing,
   malformed, or incomplete.

DKIM2 will only provide a form of Message Authentication, so it is
inherently inadequate.   When I am evalauating an intermediary, I am
looking for evidence that the intermediary cannot be duped into accepting a
fraudulent impersonation.   ARC can do that, DKIM2 cannot.   As a necessary
result of its design, ARC sets are created by server organizations, not by
their hosted clients, so it reveals the operating practices of the server
organization.   Organizations that provide ARC Sets which indicate good
authentication practices will become trusted.   Organiztions that provide
ARC Sets which indicate poor authentication practices, and those which
report nothing, will be treated with the skepticism that they deserve.

There are features of this design that faciliatate detection of fraudulent
ARC data, but that is a longer discussion.   At present, the problem is
that most ARC data is useless because it does not communicate sufficient
information to document these three types of authentication methods fully.

Doug Foster