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

[Chris Newman <[e-mail]>]

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

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