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

From: Franck Martin <[email-masked]>
Date: Fri, 7 Mar 2014 13:19:12 -0600 (CST)

Trying to get the language to converge a bit, taking the various comments received over at [email-masked]. There is still some work.

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

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

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: Alexey Melnikov <[email-masked]>
Date: Fri, 14 Mar 2014 11:45:41 +0000

Hi Franck,

> email sent using STARTTLS [RFC3207] or not.
A few very quick comments:

draft-martin-authentication-results-tls-01:

3.  IANA Considerations

    Per [IANA], the following items have been added to the "Email
    Authentication Methods" registry:

+----------+----------+--------+-----------------+-----------------+
    |  Method  | Defined  | ptype  | property        | value           |
+----------+----------+--------+-----------------+-----------------+
    |   tls    | RFC 3207 | policy | cert_client     | subject of      |
    |          |          |        |                 | client          |
    |          |          |        |                 | certificate     |
    |          |          |        |                 | section 4.1.26  |
I think you meant Section 4.1.2.6
(26 doesn't exist).
    |          |          |        |                 | of RFC 5280     |
+----------+----------+--------+-----------------+-----------------+
    |   tls    | RFC 3207 | policy | cert_server     | subject of      |
    |          |          |        |                 | server          |
    |          |          |        |                 | certificate     |
    |          |          |        |                 | section 4.1.26  |

Ditto

    |          |          |        |                 | of RFC 5280     |

A.1.  TLS Results

    A message that went over a successful TLS session:

    Authentication-Results: mail-router.example.net;
      dkim=pass (good signature) header.d=newyork.example.com
        header.b=oINEO8hg;
      tls=pass (verified, expires 20140505)
        policy.cert_verif=CA
        policy.cert_client="/C=US/ST=CA/L=ToonTown/O=ACME/
          CN=smtp.example.com"

I would much rather use LDAP format of DN and not openssl bastardization 
of it.
This also matches conventions in RFC 5280. So:

policy.cert_client="CN=smtp.example.com,O=ACME,L=ToonTown,ST=CA,C=US"

Etc.

---

From: Franck Martin <[email-masked]>
Date: Fri, 14 Mar 2014 20:39:27 -0500 (CDT)

Thanks

----- Original Message -----
> From: "Alexey Melnikov" <[email-masked]>
> To: "Franck Martin" <[email-masked]>, [email-masked]
> Sent: Friday, March 14, 2014 4:45:41 AM
> Subject: Re: [Uta] draft-martin-authentication-results-tls-01.txt
> 
> Hi Franck,
> 
> > Trying to get the language to converge a bit, taking the various comments
> > received over at [email-masked]. There is still some work.
> >

done

>  |          |          |        |                 | of RFC 5280     |

done

> policy.cert_client="CN=smtp.example.com,O=ACME,L=ToonTown,ST=CA,C=US"

Done

I'm looking at adding policy.cert_clientalt which would contain the SubjectAltName data (including the DNS-ID) if present, however this field can be quite long...

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sat, 15 Mar 2014 08:50:03 +0100

This draft contains a definition that we need to pay attention to:

"Most of these exchanges are opportunistic, meaning a best effort is
   done to establish an encrypted message exchange regardless of the
   strength of the cipher or the validity of the certificates used."

Section 1.2

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Sat, 15 Mar 2014 08:55:21 +0100

From reading this "DANE" verification seems to be only ONE set. 

DANE can be used in combination with an existing CA or without. From following Victor, he wants only one way in SMTP, with not CA/PKI verification at all.

To call that simply "DANE" would propably be misleading. Maybe Victor can propose a more distinct terminology here.

/O