Re: [apps-discuss] WG adoption for draft-martin-authentication-results-tls ?

[Chris Newman <[e-mail]>]

--On November 10, 2014 12:16:16 -1000 "Murray S. Kucherawy"
<[e-mail]> wrote:
> On Mon, Nov 10, 2014 at 7:09 AM, Chris Newman <[e-mail]>
> wrote:
>> My view of this draft is it adds a lot of clutter to the wrong header and
>> that
>> information has little or no value.
> 
> I disagree at least with the wrong header argument.  We created
> Authentication-Results because we need a place to collect information about
> email authentication methods' results when the message enters an ADMD,
> because Received fields can be reordered, scrubbed, malformed, etc.  It
> seems to be to be exactly the right place to do it.

Point me to the standard that describes the client certificate authentication
model for MTA to MTA SMTP relay, and I might agree. Absent that, there's no
authentication model and thus no authentication information to record. RFC 3207
clearly defines any form of TLS authentication as a local matter, and thus any
information about that authentication is of no relevance to the end-user's
client because there is no model for interoperability.

> However, it can only
> record what the MTA at ADMD ingress saw, so if the STARTTLS information for
> the entire handling chain is what's needed, this can't do it (but I also
> imagine that can't be done reliably at all).

Recording use of STARTTLS cipher suites on a hop-by-hop basis as trace
information is quite helpful. It's not authentication information and not
reliable, but it can identify weak points in the privacy chain where pressure
can be applied to upgrade systems. It can also be correlated with MTA logs in
the event a full privacy assessment is necessary.

> Would you not want to know the identity of the client, if that's
> available?

I'm fairly certain that X.509 Subject/Issuer DNs with no defined relationship
to SMTP relay are of no value to end-user clients. I'm skeptical they would be
useful if a standardized relationship was defined.

> At least in the case where the client is actually associated
> with a particular sending ADMD (maybe with DANE), that might be useful
> information.

How would an end-user's client use this information?

> The various details about what gets reported are certainly open for
> discussion.  I'm mostly arguing that there's something here worth looking
> at, and that A-R is the right place to put it.

An SMTP MTA relay client certificate authentication model could be quite
useful. Once such a model existed it may make sense to put the results in an
authentication-results header if it provided information that an end-user's
mail client could act on in a constructive and useful way. But this proposal is
like building the cart before anyone knows what a horse looks like.

		- Chris