Subject: [Uta] draft-martin-authentication-results-tls-00.txt

From: Franck Martin <[email-masked]>
Date: Mon, 3 Mar 2014 05:34:03 -0600 (CST)

Following a suggestion at last IETF meeting to codify TLS results in email please find the following: 

A new version of I-D, draft-martin-authentication-results-tls-00.txt 
has been successfully submitted by Franck Martin and posted to the 
IETF repository. 

Name: draft-martin-authentication-results-tls 
Revision: 00 
Title: Authentication-Results Registration for TLS 
Document date: 2014-03-03 
Group: Individual Submission 
Pages: 6 
URL: http://www.ietf.org/internet-drafts/draft-martin-authentication-results-tls-00.txt 
Status: https://datatracker.ietf.org/doc/draft-martin-authentication-results-tls/ 
Htmlized: http://tools.ietf.org/html/draft-martin-authentication-results-tls-00 

Abstract: 
This memo updates the registry of properties in Authentication- 
Results: message header fields to allow relaying of the results of an 
email sent using STARTTLS [RFC3207] or not.

---

From: Chris Newman <[email-masked]>
Date: Mon, 03 Mar 2014 14:39:06 +0000

--On March 3, 2014 5:34:03 -0600 Franck Martin <[email-masked]> 
wrote:
> URL:
http://www.ietf.org/internet-drafts/draft-martin-authentication-results-tls-00.txt 
Status:
> https://datatracker.ietf.org/doc/draft-martin-authentication-results-tls/
> Htmlized:
> http://tools.ietf.org/html/draft-martin-authentication-results-tls-00
>
>
> Abstract:

I reviewed this draft and have several concerns.

I believe the "tls.client" field is harmful. It includes information that 
appears to have value but has none in practice due to lack of standardized 
client certificate validation rules and thus may be misused by spam 
filters. If you have an argument about why this information is useful, I'd 
be interested in hearing it.

The same complaint applies "tls.server", but it is additionally problematic 
absent information about whether the client claims to have verified the 
server's identity (such information could be gathered by the SMTP CLIENT 
command described in draft-newman-email-deep).

The "tls.strength" field is a value judgment that is derived from the 
tls.cipher field. However, the community's evaluation of the strength of a 
cipher suite changes over time so this becomes inaccurate over time. It's 
been my experience that protocols are better if they omit value-judgments 
and derived values.

I believe including the "tls.cipher" field in a received header rather than 
an authentication results header is more useful because it then correlates 
with the host and IP addresses of the relevant connection endpoints 
creating a more complete connection trace field.

I invite you to critique draft-newman-email-deep. It's still version -01 
and needs refinement and review. If there is an element or goal of your 
draft you feel is important and is not covered by draft-newman-email-deep, 
I'd like to understand that and make sure it is covered.

		Thanks,
		- Chris

---

From: Franck Martin <[email-masked]>
Date: Mon, 3 Mar 2014 11:13:45 -0600 (CST)

----- Original Message -----
> From: "Chris Newman" <[email-masked]>
> To: "Franck Martin" <[email-masked]>, [email-masked]
> Sent: Monday, March 3, 2014 2:39:06 PM
> Subject: Re: [Uta] draft-martin-authentication-results-tls-00.txt
> 

I fail to understand how it can be misused, by definition the receiving server is "trusted" and is reporting the result of the message reception via this header. 

The received headers are commonly forged, and it is quite difficult to know which ones are real, at the difference of the Authentication-Results header which cannot be forged, as the receiving MTA must delete this header on reception.

The Authentication-Results header is only useful within a trusted environment, it is not meant to be added to a message to be sent over the Internet: MTA--->MUA

The presence of the CN= part in the Subject, which usually contains a domain name, allows in the same fashion as SPF or DKIM to tie an email to a domain. Therefore provides an extra identifier for a wide variety of reputation mechanisms.

For instance openDMARC works in a pipeline, gathering the results of SPF and openDKIM from the authentication-results header, to apply its logic... and add to the header the results.

While draft-kucherawy-original-authres-00 has expired, this is another possible use case for the authentication-results header.

the tls.server header is less useful as you should know which certificate you have loaded on your own mail server. I added it for completeness.

> been my experience that protocols are better if they omit value-judgments

openssl usually classifies the ciphers using these values, it is just a replica of such, and left to receiving server to choose which one is which. And yes I agree they change in time, but as the Authentication-header is used in a controlled environment, this environment can provide the meaning it likes to these values.

> I'd like to understand that and make sure it is covered.

draft-newman-email-deep lacks a part about the authentication-results header ;) 

There is value today in putting TLS information in authentication-results header, and there are several use case than can be developed from there.

draft-martin-authentication-results-tls could be folded within draft-newman-email-deep, however it could be easier/faster for MTAs to implement the authentication headers than the whole of draft-newman-email-deep. Same would go for the received headers portion of draft-newman-email-deep, if separated from this document it would provide a much smaller incremental upgrade to MTA designers. You may have noticed that in current received headers the cipher string displayed there is the one from openssl. It needs some standardization.

I don't know which path is preferable or faster, but it seems to me folks would refrain to implement "parts" of an RFC, while standardization in the current implementation of TLS on MTAs is needed.

If I understand draft-newman-email-deep is to provide an end to end controlled encryption path, may be to supplement GPG-S/MIME which does not have much traction outside some walled garden.

I'll read more draft-newman-email-deep and provide review on it.

---

From: Chris Newman <[email-masked]>
Date: Tue, 04 Mar 2014 09:54:49 +0000

I'm now thinking our proposals have two different goals and should be kept 
separate.

The goal of my received-header proposal is to record a trace of TLS usage 
for every hop of email transfer. This allows the recipient to get a sense 
of the level of privacy from undetectable passive attacks achieved during 
transfer. I believe this information can be leveraged in various ways to 
improve deployed cipher suites as well as to identify transfer connections 
where protection from passive attacks is missing and needs to be added.

If I understand correctly, I think you're trying to introduce a new 
TLS-based anti-spam weighting factor that raises the cost for spammers 
somewhat. That's actually a goal I had not considered prior to this 
discussion. It's an interesting goal, but there are a number of highly 
problematic details that would need to be corrected to achieve it. Today's 
TLS in SMTP today does not work the way TLS does for other protocols; it is 
completely unauthenticated and the client and server certificates have no 
meaning unless an additional protocol, such as DANE+SMTP is also required.

So before it's useful to put anything related to TLS in an authentication 
results header, you need to actually write down the rules and requirements 
for the form of TLS authentication necessary to achieve the goal you're 
pursuing.

If I've correctly identified your goal, I can try to provide suggestions on 
how to achieve it. Please let me know if you'd like that.

A few brief comments below:

--On March 3, 2014 11:13:45 -0600 Franck Martin <[email-masked]> 
wrote:
>> http://www.ietf.org/internet-drafts/draft-martin-authentication-results-
>> tls-00.txt Status:
>> > https://datatracker.ietf.org/doc/draft-martin-authentication-results-t
>> > ls/ Htmlized:
>> appears to have value but has none in practice due to lack of
>> standardized client certificate validation rules and thus may be misused
>> by spam filters. If you have an argument about why this information is
>> useful, I'd be interested in hearing it.
>>
>> The same complaint applies "tls.server", but it is additionally
>> problematic absent information about whether the client claims to have
>> verified the server's identity (such information could be gathered by
>> the SMTP CLIENT command described in draft-newman-email-deep).
>
> I fail to understand how it can be misused, by definition the receiving
> server is "trusted" and is reporting the result of the message reception
> via this header.
>
> The received headers are commonly forged, and it is quite difficult to
> know which ones are real, at the difference of the Authentication-Results
> header which cannot be forged, as the receiving MTA must delete this
> header on reception.

The top received header and the Authentication-Results header have the same 
level of trust.

> The Authentication-Results header is only useful within a trusted
> environment, it is not meant to be added to a message to be sent over the
> Internet: MTA--->MUA

I question the degree to which such "trusted environments" exist.

> The presence of the CN= part in the Subject, which usually contains a
> domain name, allows in the same fashion as SPF or DKIM to tie an email to
> a domain. Therefore provides an extra identifier for a wide variety of
> reputation mechanisms.

FYI, that use of CN= is deprecated by the PKIX specification (RFC 5280) 
that sets the rules for TLS certificates. You'd also need to record the 
relevant subjectAltNames. But none of that's useful if no TLS 
authentication is performed.

		- Chris

---

From: Franck Martin <[email-masked]>
Date: Tue, 4 Mar 2014 08:35:16 -0600 (CST)

----- Original Message -----
> To: "Franck Martin" <[email-masked]>
> Cc: [email-masked]
> Sent: Tuesday, March 4, 2014 9:54:49 AM
yes, but the goal is more to record the result of the TLS in a machine parseable header, that mail plugins are used to read.

I need to better understand your CN= comment, so I will read the doc. I'm more based on experience, Subjects that I have seen in use.

Note, that I thrived to give pass only to something which is authenticated and verified, like via CA or DANE. Self signed certificate should not give a result pass. I try to explain this in the definitions, may be they need to be more developed than one sentence ;)

I'm happy to see your suggestions so I better understand this space.