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

[Franck Martin <[e-mail]>]

----- Original Message -----

> From: "Murray S. Kucherawy" <[e-mail]>
> To: "Chris Newman" <[e-mail]>
> Cc: "Franck Martin" <[e-mail]>, "IETF Apps Discuss"
> <[e-mail]>
> Sent: Monday, November 10, 2014 2:16:16 PM
> Subject: Re: [apps-discuss] WG adoption for
> draft-martin-authentication-results-tls ?

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

I think many questions about the usefulness of AR are answered in http://tools.ietf.org/html/rfc7001 remembers this is just an update of this RFC. 

Some example could be useful indeed. 

While this information should also be in Received Headers, I never succeeded to teach appropriately a tech support to read correctly received headers and not be tricked. It is way much easier to say read the AR header. 

Finally, SMTP servers work in dual mode (client+server) while HTTP servers works in sever mode only. The server certificate in SMTP is often used as the client certificate too. This is why you may see more client certificates with SMTP than with HTTP. 

Is the information useful, may be. I'm not sure all the fields described in the protocol are useful. As it is the early days, I just want them there, so implementation can pick what they think is useful, and if adopted by the workgroup some fields will be culled as we get better understanding and data. 

However one may envision that one day, TLS authentication may be used in policy protocols like DMARC.