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

[Franck Martin <[e-mail]>]

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

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.

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

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

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.