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

From: Franck Martin <[email-masked]>
Date: Mon, 3 Mar 2014 01:57:21 -0600 (CST)

Following a suggestion at last IETF meeting to codify TLS results in email please find the following (feedback most welcome on [email-masked]): 

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: Scott Kitterman <[email-masked]>
Date: Mon, 03 Mar 2014 09:46:54 -0500

On March 3, 2014 2:57:21 AM EST, Franck Martin <[email-masked]> wrote:
>Following a suggestion at last IETF meeting to codify TLS results in
>email please find the following (feedback most welcome on
>[email-masked]): 

...

I've reviewed the document and find it's a straightforward extension of auth-results. I have one comment though and I think it's a significant one:

Most SMTP over TLS traffic is done with self-signed certificates, so I think it's wrong to call that "fail".  I would imagine fail to describe a failure to encrypt, not a failure to verify via a CA.  

Maybe instead of pass/fail it should be verified/unverified?  A failure should be about an error condition and that isn't what the current draft describes.

Scott K

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 3 Mar 2014 16:16:07 +0100

I read the draft and didn't like the same bit.

Talking about "temperror" and "permerror" for a successfully transmitted 
message sounds very strange. Even if that's actually well defined and I 
overlooked the definitions, I think it's begging for misunderstandings.

Also, the pass/fail values disregard DANE. I would prefer to name the three 
encrypted cases "unverified", "ca" and "dane".

Arnt

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 03 Mar 2014 12:25:03 -0500

>encrypted cases "unverified", "ca" and "dane".

Those three sound good to me.  DANE is a good point. 

Scott K

---

From: Dave Cridland <[email-masked]>
Date: Mon, 3 Mar 2014 17:26:52 +0000

I don't think it is, really. Verified or unverified are the interesting
cases. "Dane" may or may not be providing additional, or alternative,
security. If a certificate is verified to have a trust path back to a known
CA with additional DANE constraints, is that "ca" or "dane", and should I
care?

On 3 March 2014 17:25, Scott Kitterman <[email-masked]> wrote:

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>

---

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

----- Original Message -----
> From: "Scott Kitterman" <[email-masked]>
> To: "IETF Apps Discuss" <[email-masked]>
> Sent: Monday, March 3, 2014 5:25:03 PM
> Subject: Re: [apps-discuss] draft-martin-authentication-results-tls-00.txt
> 
> 
> 
I was trying to stay with the current defined words in other methods and giving them a specific meaning relevant to TLS, but I'm happy to use different words too.

I would think that dane is "verified" same as with a PKI. May be a new optional property needs to be added instead?

tls.ca=dane/pki

and permerror could be converted to "unverified"

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 3 Mar 2014 20:03:24 +0100

I'd be happy if the definition of "verified" were amended to allow DANE as 
well as a known CA.

Distinguishing between DANE and CA verification is... interesting to me 
personally, but perhaps KISS and a single value is better for the world. 
So, use one value or two, as you please.

Arnt

---

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

----- Original Message -----
> From: "Arnt Gulbrandsen" <[email-masked]>
> To: [email-masked]
> Sent: Monday, March 3, 2014 7:03:24 PM

While I'm still undecided with self signed certificates, for instance in web browsers, they generate the same error message as if the certificate is expired. 

As for DANE/CA, Auth-res works mostly in a controlled environment only, so if you enable DANE, this is on your mail server, so you should know if you trust it like you trust a CA.

I'm proposing 2.1, while I'm not entirely sure if softfail (or called neutral?) should exist.

The "tls" method can have the following results:

   none: the message was sent in clear.

   pass: the message was sent encrypted and the client certificate was
   verified valid either using a trusted CA or via DANE [RFC6698].

   softfail: the message was sent encrypted but the client certificate is
   self signed.

   fail: the message was sent encrypted but the client certificate is
   not valid.  It is advised to use comments to indicate the nature of
   the problem like certifcate expired, not linked to a trusted CA,...

   temperror: the message was sent encrypted and the server was not able
   to verify the client certificate at this time.  This may indicate for
   instance that the server could not fetch the CRL.

   permerror: the message was sent encrypted and the client certificate
   was not verified by the MTA server.

---

From: Dave Cridland <[email-masked]>
Date: Mon, 3 Mar 2014 19:52:04 +0000

> So, use one value or two, as you please.

Yes, it's interesting to me, too, but it's not critical information.
Moreover, it leads to grey areas between the two.

Dave.

---

From: Scott Kitterman <[email-masked]>
Date: Mon, 03 Mar 2014 16:23:59 -0500

On Monday, March 03, 2014 13:51:53 Franck Martin wrote:
> While I'm still undecided with self signed certificates, for instance in web
> browsers, they generate the same error message as if the certificate is
> expired.
> 
> As for DANE/CA, Auth-res works mostly in a controlled environment only, so
> if you enable DANE, this is on your mail server, so you should know if you
> trust it like you trust a CA.
> 

I think it's wrong to define the primary normal mode of operations as a fail 
case.  How about unverified or unknown?

Scott K

---

From: Kurt Andersen <[email-masked]>
Date: Mon, 3 Mar 2014 14:13:38 -0800

>    was not verified by the MTA server.

I think that reusing these terms will lead to confusion. At the very least,
one will have to have a lookup cheat sheet to interpret them.

To me there are two almost orthogonal aspects to this:
1) was the message sent in the clear or via TLS
2) if TLS, how "good" is the client cert

Mixing the two concepts together makes it hard to figure out what is
happening. If one was to further add in alignment requirements for cert and
content (as has been discussed in some other arenas), the mess will only
get worse.

--Kurt Andersen

---

From: Dan Wing <[email-masked]>
Date: Mon, 3 Mar 2014 22:40:01 +0000

On Mar 3, 2014, at 5:26 PM, Dave Cridland <[email-masked]> wrote:

> I don't think it is, really. Verified or unverified are the interesting cases. "Dane" may or may not be providing additional, or alternative, security. If a certificate is verified to have a trust path back to a known CA with additional DANE constraints, is that "ca" or "dane", and should I care?

Likewise, if CA validation failed but DANE validation succeeded, what should be indicated?  Is certificate pinning, or an explicitly-configured certificate, something that should get another designation as it is stronger than CA or DANE validation?

-d

---

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

----- Original Message -----

> From: "Kurt Andersen" <[email-masked]>
> To: "Franck Martin" <[email-masked]>
> Cc: "Arnt Gulbrandsen" <[email-masked]>, "IETF Apps Discuss"
> <[email-masked]>
> Sent: Monday, March 3, 2014 10:13:38 PM

> On Mon, Mar 3, 2014 at 11:51 AM, Franck Martin < [email-masked] >
> wrote:

> content (as has been discussed in some other arenas), the mess will only get
> worse.

You note that I tried to put in "pass" only a result which is TLS and "verified" via CA or DANE. A self signed certificate, should not give a "pass". From there you can trust enough the Subject provided by the client Certificate to do some forms of alignments.

---

From: Scott Kitterman <[email-masked]>
Date: Wed, 05 Mar 2014 15:56:59 -0500

On Tuesday, March 04, 2014 08:40:56 Franck Martin wrote:
> You note that I tried to put in "pass" only a result which is TLS and
> "verified" via CA or DANE. A self signed certificate, should not give a
> "pass". From there you can trust enough the Subject provided by the client
> Certificate to do some forms of alignments.

I'm fine with not giving a self-signed certificate a pass.  I think that makes 
sense.  Equally, I'm not fine with calling it a failure either.  My suggestion 
is unverified.  I'm happy to add support for this draft to the authres python 
module that I co-maintain once we get a few things sorted out:

https://launchpad.net/authentication-results-python

How about this:

Expand/replace "fail" to "unverified" and "expired" (I can't think of another 
case).  If I've concluded I don't care about verification, I think I also don't 
care about expiration, but if I do care about verification, then I think having 
"expired" is a useful error condition.  It could be used to trigger an out of 
band complaint to the sender that they need to get their key updated.

Add a new  property for ptype "cert" called "verification" with values "ca", 
"dane", "policy", and "none" (policy would be if a receiver has, based on pre-
arrangement, decided to treat a specific cert as valid from a receiver).

I think those changes would resolve the issues we've discussed here.  
Additionally, I was reviewing what information is available via the Postfix 
policy service (see http://www.postfix.org/SMTPD_POLICY_README.html ) to get an 
idea how much information would be available to an external application to 
support injecting this header field.  That led me to some additional 
questions/suggestions:

How are low/medium/high strength defined?  I looked in RFC 3207, which is the 
given reference, and didn't see it.  As you will notice, Postfix returns the 
number of bits in the key, not low/medium/high.  I would imagine that today's 
high is tomorrow's medium, so I think using a numeric value for key size would 
be better than low/medium/high.  In combination with the algorithm, key size 
should be sufficient to make a determination if security for the connection was 
adequate or not (in combination with protocol [see below]).  Certainly I think 
it would be better than a generic and undefined low/medium/high.

I also noticed (now) that protocol version is not included.  While today I 
doubt many care about SSLv3/TLSvWhatever, I suspect that eventually they will 
(if it was SSLv2, you ought to care).  I'd propose adding a ptype for protocol 
with a property of "version" and values of "SSLv2", "SSLv3", "TLSv1", 
"TLSv1.1", and "TLSv1.2".

I would also suggest adding a "fingerprint" property for the "key" ptype.  I 
can envision knowing exactly which key was used being useful.

Based on those changes, the example in the current draft might end up looking 
like:

     tls=pass (verified, expires 20140505)
       tls.verification="ca"
       tls.client="/C=US/ST=CA/L=ToonTown/O=ACME/CN=smtp.example.com"
       tls.key.cipher=TLS_RSA_WITH_RC4_128_SHA
       tls.protocol="TLSv1"
       tls.fingerprint="68:B3:29:DA:98:93:E3:40:99:C7:D8:AD:5C:B9:C9:40"
       tls.strength=1024;

Finally, trying to modify the example caused me to notice that, unlike all the 
5451/7001 examples you don't include the ptype in your example.  I think it's 
mandatory and to the extent the ABNF may allow for ptype to be omitted when 
property is present, I think it's a bug in the ABNF (I'm curious for msk's 
opinoin on that).  Based on that, I think it should be:

     tls=pass (verified, expires 20140505)
       tls.cert.verification="ca"
       tls.cert.client="/C=US/ST=CA/L=ToonTown/O=ACME/CN=smtp.example.com"
       tls.key.cipher=TLS_RSA_WITH_RC4_128_SHA
       tls.protocol.version="TLSv1"
       tls.key.fingerprint="68:B3:29:DA:98:93:E3:40:99:C7:D8:AD:5C:B9:C9:40"
       tls.key.strength=1024;

What do you think?

Scott K

---

From: Franck Martin <[email-masked]>
Date: Thu, 6 Mar 2014 05:11:31 -0600 (CST)

----- Original Message -----
> Sent: Wednesday, March 5, 2014 8:56:59 PM
> > > Subject: Re: [apps-discuss]
> > > draft-martin-authentication-results-tls-00.txt
> > > 

cool

> band complaint to the sender that they need to get their key updated.

I'm fine with new name, I'm keeping the old one, till a new naming converge ;)

> arrangement, decided to treat a specific cert as valid from a receiver).

ok

> it would be better than a generic and undefined low/medium/high.

Well, the strength is mainly coming from openssl classification of ciphers
https://www.openssl.org/docs/apps/ciphers.html

Note that postfix pass the openssl name of the cipher, not the RFC approved name, this is why they pass the number of bits too.

for instance:
SSL_RSA_WITH_RC4_128_SHA   becomes RC4-SHA (128 bits)

So you will have to maintain a table of correspondence, and while you are at it, you can add a strength. I'm not to bent over it, it is just I think it is better that the MTA calls the level of encryption than the MUA to have to figure it out.

> "TLSv1.1", and "TLSv1.2".

I'm not fully sure it is needed, because from the openssl cipher list it seems to imply ciphers are associated with a specific version, and the RFC naming at least makes a difference between SSL and TLS just by the name.

> can envision knowing exactly which key was used being useful.

fine

>        tls.key.fingerprint="68:B3:29:DA:98:93:E3:40:99:C7:D8:AD:5C:B9:C9:40"

looks good, I think no one put the method in front, so let's wait for Murray's advice, but personnaly I would stick to what people have been doing so far.

so from your example, this seems more in line with current usage:

      tls=pass (verified, expires 20140505)
        cert.verification="ca"
        cert.client="/C=US/ST=CA/L=ToonTown/O=ACME/CN=smtp.example.com"
        key.cipher=TLS_RSA_WITH_RC4_128_SHA
        protocol.version="TLSv1"
        key.fingerprint="68:B3:29:DA:98:93:E3:40:99:C7:D8:AD:5C:B9:C9:40"
        key.strength=1024;

Note, I have been made aware there is a problem because ptype can only be smtp/header/body/policy as per 7001. I will dutifully ignore this important fact for the moment unless we can wrap all of this inside a policy ptype ;)

      tls=pass (verified, expires 20140505)
        policy.certverification="ca"
        policy.certclient="/C=US/ST=CA/L=ToonTown/O=ACME/CN=smtp.example.com"
        policy.keycipher=TLS_RSA_WITH_RC4_128_SHA
        policy.protocol="TLSv1"
        policy.keyfingerprint="68:B3:29:DA:98:93:E3:40:99:C7:D8:AD:5C:B9:C9:40"
        policy.keystrength=1024;