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

["Murray S. Kucherawy" <[e-mail]>]

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.  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).

The one useful piece of information is the negotiated cipher suite, but
> that is
> most useful if the information is provided on a hop-by-hop basis so it
> belongs
> in the Received header, IMHO.
>

Would you not want to know the identity of the client, if that's
available?  At least in the case where the client is actually associated
with a particular sending ADMD (maybe with DANE), that might be useful
information.

You kind of answer this here:

In my experience, client certificate authentication in SSL/TLS is very
> uncommon
> in all protocols. The general model for client certificate authentication
> is
> that the server has a CA that is used to sign all client certificates that
> are
> used with that server. That model doesn't work for SMTP relay (although
> it's a
> model I have implemented and works fine for SMTP Submission). For client
> certificate authentication to work, the server has to request a client
> certificate, the client has to have one configured and to use it to
> authenticate the session. I'd like to see data on how many deployed SMTP
> servers that support TLS request a client certificate. I know the servers I
> work on do not request that by default. I also doubt most SSL/TLS
> appliances
> request client certificates by default.
>

As we move (slowly) toward authenticating and securing everything, is there
no hope of this changing toward what Franck is envisioning?


> I also do not view the server's opinion of the key strength of a TLS cipher
> suite to have any value. The server's opinion can be wrong if the client
> has a
> bad SSL stack. The cipher suite that was used is a specific piece of
> factual
> data. If 10 weeks ago we used a cipher suite that was suddenly recognized
> as
> broken today, the cipher suite used information is quite valuable, but the
> server's opinion of its effective key size or strength will be worthless.
>

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.


> Finally, the draft does not state how this TLS information would be used.
> I'm
> opposed to adding all this clutter to headers unless there is some
> plausible
> utility.
>

Yes, a use case example would be good to include in any case.

-MSK, just participatin'