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

[Chris Newman <[e-mail]>]

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 <[e-mail]> 
wrote:
> ----- Original Message -----
>> From: "Chris Newman" <[e-mail]>
>> To: "Franck Martin" <[e-mail]>, [e-mail]
>> Sent: Monday, March 3, 2014 2:39:06 PM
>> Subject: Re: [Uta] draft-martin-authentication-results-tls-00.txt
>>
>> --On March 3, 2014 5:34:03 -0600 Franck Martin <[e-mail]>
>> wrote:
>> > 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-t
>> > ls/ 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.
>>
>> 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).
>
> 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