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

From: Chris Newman <[email-masked]>
Date: Mon, 10 Nov 2014 10:09:01 -0700

--On October 21, 2014 15:07:43 -0500 Franck Martin <[email-masked]>
wrote:
> I incorporated the previous feedback I received on this list into
> http://datatracker.ietf.org/doc/draft-martin-authentication-results-tls/ 
> 
> I have not seen comments since. Several people were supportive of the work. 
> 
> I'd like to submit this document to become a WG document for eventual
> publication. 
> 
> If you have any comments on the current version, I'll update it as much as I
> can before the deadline for drafts submission 27 October. 
> 
> I have some code running, tho I need to do some fixes in the code (and it is
> not public yet), but it helped me to better understand what needs to be
> exposed on how to do it. 

My view of this draft is it adds a lot of clutter to the wrong header and that
information has little or no value.

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.

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.

There's also no standard for how to use client certificates with SMTP relay.

Server certificate authentication is widely used in SSL/TLS, but it's not
useful in SMTP relay today because there is no standard for how to do it, and
in particular for how it relates to MX records and non-primary MX hosts. Until
such a standard is published, I'm opposed to recording misleading information
about server authentication. I'll also point out that server authentication is
performed by the client and only the client knows if it verified the server's
identity. So server identity and authentication is completely contrary to the
model of authentication used by other Authentication-Results uses because the
server-authentication information for the "long hop" can only be generated from
outside the recipient's administrative domain.

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.

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.

		- Chris

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 10 Nov 2014 12:16:16 -1000

> 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

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

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

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

> opposed to adding all this clutter to headers unless there is some

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

-MSK, just participatin'

---

From: Dave Crocker <[email-masked]>
Date: Mon, 10 Nov 2014 14:23:24 -0800

On 11/10/2014 9:09 AM, Chris Newman wrote:
> My view of this draft is

+1 to each of the points in Chris' well-considered note.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Franck Martin <[email-masked]>
Date: Mon, 10 Nov 2014 18:03:33 -0600 (CST)

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

> From: "Murray S. Kucherawy" <[email-masked]>
> To: "Chris Newman" <[email-masked]>
> Cc: "Franck Martin" <[email-masked]>, "IETF Apps Discuss"
> <[email-masked]>
> 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 < [email-masked] >
> wrote:

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

> > that
> > is

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

> > used with that server. That model doesn't work for SMTP relay (although
> > it's
> > a
> 

> > suite to have any value. The server's opinion can be wrong if the client
> > has
> > a
> 

> discussion. I'm mostly arguing that there's something here worth looking at,
> and that A-R is the right place to put it.

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

---

From: Chris Newman <[email-masked]>
Date: Mon, 10 Nov 2014 14:49:05 -1000

--On November 10, 2014 12:16:16 -1000 "Murray S. Kucherawy"
<[email-masked]> wrote:
> 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

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.

> 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

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

> 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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Mon, 10 Nov 2014 15:29:35 -1000

I don't have good answers to the authentication model questions, so I'll
leave Franck to chase that down with you.  On this point:

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

I imagine in the same way that some MUAs use or are starting to use things
like DKIM.  Gmail, for example, might say this message is "From Chris
Newman via ietf.org" if ietf.org signed it with DKIM.  I'm guessing the
authenticated SMTP client could be similarly revealed.

-MSK

---

From: Ned Freed <[email-masked]>
Date: Wed, 12 Nov 2014 07:24:28 -0800 (PST)

I agree with Chris on all the points he raises here, especially the one
about putting ciptersiute information in Received: fields.

				Ned

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 12 Nov 2014 16:38:22 +0100

>> opposed to adding all this clutter to headers unless there is 

What Chris says here is "tell me a use case". Yes. Please do. Solutions 
made before any use cases are known have such an icky tendency to miss.

Arnt