Subject: Re: [dane] Call for Adoption - draft-fanf-dane-smtp-04

From: Warren Kumari <[email-masked]>
Date: Mon, 7 Jan 2013 15:14:54 -0500

On Dec 20, 2012, at 12:17 PM, Warren Kumari <[email-masked]> wrote:

> Dear DANE Working Group,
> 
> This starts a 4-week (because of time of year) consensus call on adopting  draft-fanf-dane-smtp-04 as a DANE WG document. 

Hi all,

This is a reminder to please submit feedback on adopting this (well, these) docs….

W

> 
> ----- DRAFT INFO ----
> Title           : Secure SMTP with TLS, DNSSEC and TLSA records.
> Author(s)       : Tony Finch
> Filename        : draft-fanf-dane-smtp-04.txt
> 
> Abstract:
>   SMTP has a STARTTLS extension, but (especially in the case of inter-
>   domain mail transfer) it only provides very limited security because
>   it does not specify how to authenticate the server's certificate.
>   This memo specifies how TLSA records in the DNS can be used for
>   proper SMTP server authentication.
> 
> 
> Datatracker page: https://datatracker.ietf.org/doc/draft-fanf-dane-smtp/
> TXT URL: http://www.ietf.org/id/draft-fanf-dane-smtp-04.txt
> HTML URL:  http://tools.ietf.org/html/draft-fanf-dane-smtp-04
> PDF URL: http://tools.ietf.org/pdf/draft-fanf-dane-smtp-04.pdf
> 
> 
> Please read the document and state your opinions either for or against adoption (with reasoning why!) on the mailing list.
> 
> We note that this document has already received a bunch of discussion onlist and in WG sessions.
> 
> The call for adoption ends 20th January 2013.
> 
> Thanks,
>     Ondrej and Warren.
> 
> -- 
> Never criticize a man till you've walked a mile in his shoes.  Then if he didn't like what you've said, he's a mile away and barefoot. 
> 
> 
> 

--
I don't think the execution is relevant when it was obviously a bad idea in the first place.
This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. 
   ---maf

Warren Kumari
[email-masked]

---

From: Tom Ritter <[email-masked]>
Date: Mon, 7 Jan 2013 16:55:42 -0500

> This is a reminder to please submit feedback on adopting this (well, these) docs….

I would like to see it adopted and worked on, but am not the best
person to provide feedback, so take that as you will.

-tom

---

From: Olafur Gudmundsson <[email-masked]>
Date: Mon, 07 Jan 2013 17:37:41 -0500

>> This starts a 4-week (because of time of year) consensus call on adopting  draft-fanf-dane-smtp-04 as a DANE WG document.

Support adoption
	Olafur

---

From: James Cloos <[email-masked]>
Date: Mon, 07 Jan 2013 17:59:43 -0500

+1

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 1024D/ED7DAEA6

---

From: James Cloos <[email-masked]>
Date: Mon, 07 Jan 2013 18:03:56 -0500

A point of discussion is what, if anything, the receiving MTA should do
dane-wise with and cert offered by the sending MTA.

the MTAs generally do a ptr lookup and an a or aaaa to confirm that the
latter results in the same ip as the socket; it could use the result of
that ptr lookup also to grab a _25._tcp TLSA rr.  Should it?  Should
this draft talk about that?  Should there be a draft just for that?

-JimC

---

From: Jakob Schlyter <[email-masked]>
Date: Tue, 8 Jan 2013 08:21:45 +0100

> Please read the document and state your opinions either for or against adoption (with reasoning why!) on the mailing list.

I support adoption - this is important work.

	jakob

---

From: "Marco Davids (SIDN)" <[email-masked]>
Date: Tue, 8 Jan 2013 09:52:03 +0100

> I support adoption - this is important work.

Me too.

The fact that RFC3207 does not clearly describe how a server should be
authenticated leaves room for MitM-abuse and is an issue that needs to
be addressed.

I like the idea of fixing it with DANE, especially since many
certificates used in 'STARTTLS' today, are self-signed certificates.

--
Marco

---

From: Patrik Wallström <[email-masked]>
Date: Tue, 8 Jan 2013 10:09:10 +0100

+1

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 08 Jan 2013 14:25:12 -0500

> this draft talk about that?  Should there be a draft just for that?

Hum in this case there are two options
a) store the DANE record in both forward and reverse zone
b) place a CNAME record in the reverse zone.

IMHO
storing DANE record in just one place is better.

	Olafur

---

From: Tony Finch <[email-masked]>
Date: Wed, 9 Jan 2013 18:41:12 +0000

> dane-wise with and cert offered by the sending MTA.

I think this might be interesting to pursue but it could be a deep rat
hole. I prefer to get server authentication complete first.

I believe it would not be feasible to tie the sending host identity to the
sending mail domain. That would repeat the error made by SPF. So the only
benefit we can get is authenticating the sending host; some other
mechanism (i.e. DKIM) is necessary for higher-level identities.

What benefit would client authentication give you? At the moment we
usually assume that bidirectional TCP is good enough for us to believe the
client IP address; this is evidently a bit shaky given the lack of routing
security, but even if we had secure routing we could still be open to
spoofing attacks from sufficiently well-placed on-path attackers.

For intra-domain mail, client authentication is useful for gaining
permission to relay arbitrary mail. It's perfectly sensible to use client
certificates for this, probably validated using a private CA. If DANE
takes off it might be preferable to use the DNS instead.

For inter-domain mail the client IP address is looked up in reputation
services and used for tracing and logging. You might care about making
this harder to spoof, but it's fairly marginal I think.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.

---

From: James Cloos <[email-masked]>
Date: Wed, 09 Jan 2013 14:41:18 -0500

>>>>> "TF" == Tony Finch <[email-masked]> writes:

>> dane-wise with and cert offered by the sending MTA.

TF> I think this might be interesting to pursue but it could be a deep rat
TF> hole. I prefer to get server authentication complete first.

Separate draft, then?

TF> I believe it would not be feasible to tie the sending host identity to the
TF> sending mail domain. That would repeat the error made by SPF. So the only
TF> benefit we can get is authenticating the sending host; some other
TF> mechanism (i.e. DKIM) is necessary for higher-level identities.

+100.  I only thought of it as a link in the chain.  *If* all of the
Received come with confirmed cert comments then *maybe* the path is
a bit more trustworthy.  Maybe even two bits. :)

TF> What benefit would client authentication give you? At the moment we
TF> usually assume that bidirectional TCP is good enough for us to believe the
TF> client IP address; this is evidently a bit shaky given the lack of routing
TF> security, but even if we had secure routing we could still be open to
TF> spoofing attacks from sufficiently well-placed on-path attackers.

Just a link in a chain, akin to a path through a (weak) web of trust.

TF> For intra-domain mail, client authentication is useful for gaining
TF> permission to relay arbitrary mail. It's perfectly sensible to use client
TF> certificates for this, probably validated using a private CA. If DANE
TF> takes off it might be preferable to use the DNS instead.

Again, well stated.

TF> For inter-domain mail the client IP address is looked up in reputation
TF> services and used for tracing and logging. You might care about making
TF> this harder to spoof, but it's fairly marginal I think.

Indeed.  Hense just a bit or so more trustworthy.  But in some cases maybe
that bit is a back-reinforcing bit?

My primary MX shows about 1/8 of my recent mail came from MXs which
presented a cert signed by something in my dist's root pool, and about
3/8 were anonymous tls, leaving about 1/2 clear text.  FWIW.

-JimC

---

From: Tony Finch <[email-masked]>
Date: Thu, 10 Jan 2013 11:52:44 +0000

> 3/8 were anonymous tls, leaving about 1/2 clear text.  FWIW.

Client certificates? I thought they were nonexistent for mail to MXs.

Years ago when I did some preliminary experiments to prepare for enabling
TLS support on our servers, I turned on an option for the server to
request a client certificate. (TLS clients do not send their certificates
unless asked.) This was supposed to be optional, but many clients treated
it as a demand and aborted the connection, which was not what I wanted.
(It implied you can't support password authentication and certificate
authentication on the same server.) So I would be wary of turning on the
same option on an MX!

Tony.

---

From: James Cloos <[email-masked]>
Date: Thu, 10 Jan 2013 12:25:43 -0500

>>>>> "TF" == Tony Finch <[email-masked]> writes:

TF> Client certificates? I thought they were nonexistent for mail to MXs.

Yes.  An example from lists.debian.org:

Received: from bendel.debian.org (bendel.debian.org [82.195.75.100])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client CN "bendel.debian.org", Issuer "ca.debian.org" (verified OK))
	by pao.uu.jhcloos.net (Postfix) with ESMTPS id 1CAFE23CC56
	for <[email-masked]>; Tue,  8 Jan 2013 06:22:46 +0000 (UTC)

and from mail from a goog group:

Received: from mail-ie0-f191.google.com (mail-ie0-f191.google.com [209.85.223.191])
	(using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
	(Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK))
	by pao.uu.jhcloos.net (Postfix) with ESMTPS id 3D04E23C010
	for <[email-masked]>; Thu, 10 Jan 2013 07:04:25 +0000 (UTC)

OTOH, mail from a list at alioth.debian looks like:

Received: from wagner.debian.org (wagner.debian.org [217.196.43.132])
	(using TLSv1 with cipher AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by pao.uu.jhcloos.net (Postfix) with ESMTPS id 9498E23C034
	for <[email-masked]>; Thu, 10 Jan 2013 07:58:00 +0000 (UTC)

I have pf configured to request but not require a cert.

Primarily just to see what they do.

TF> ... I turned on an option for the server to request a client
TF> certificate. ...  This was supposed to be optional, but many clients
TF> treated it as a demand and aborted the connection, which was not
TF> what I wanted.

I've not seen any such issue since I turned on the requests.

I just added smtpd_tls_ask_ccert = yes to my postfix main.cf.

-JimC

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 10 Jan 2013 14:59:29 -0500

I would like the draft to be more clear in section 3.2

   If any of these checks fail, the client MUST disconnect from the
   server and treat this as a temporary failure.

   The client can now proceed to deliver mail securely.

Rather than assume that the preceding sentence will be treated as throwing
an exception, I think the last line needs to say 'If all the checks
succeed, the client can now proceed...'

The dufus implementation risk here is that someone writes code that checks
for DANE SMTP records and falls back to plain SMTP after a cert check fails.

No, I don't think that is a reasonable interpretation but having seen some
pretty idiotic stuff over the years, I think it needs to be called out more
clearly. One of the reasons we could not deploy S/MIME when phishing email
started to be a problem was that the chuckleheads at AOL responded to
signed email with a message box saying 'WARNING, THE MESSAGE YOU HAVE
RECEIVED IS SIGNED'. It was fixed later but the deployed base was
prohibitive.

On Thu, Dec 20, 2012 at 12:17 PM, Warren Kumari <[email-masked]> wrote:

> Dear DANE Working Group,
>
> This starts a 4-week (because of time of year) consensus call on adopting
>  draft-fanf-dane-smtp-04 as a DANE WG document.
>
> ----- DRAFT INFO ----
> Please read the document and state your opinions either for or against
> adoption (with reasoning why!) on the mailing list.
>
> Never criticize a man till you've walked a mile in his shoes.  Then if he
> didn't like what you've said, he's a mile away and barefoot.
>
>
>
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
>

-- 
Website: http://hallambaker.com/

---

From: [email-masked] (Martin Rex)
Date: Thu, 10 Jan 2013 21:26:30 +0100 (CET)

The problem with Client certs for smtpd is that basically you will
have to violate the TLS protocol to not run into connection failures.

SSLv3 and TLSv1.0 *REQUIRE* the TLS server to send a list
of (acceptable) certificate_authorities (distinguished names)
in the CertificateRequest handshake message, and sending an empty 
list is a protocol violation.  While there was a silent change
in the CertificateRequest PDU definition in TLSv1.1 (rfc4346)
that appears to allow an empty list, there are no semantics
defined in TLSv1.1 and TLSv1.2, so this PDU change is a defect
in the TLS v1.1+v1.2 spec and must not be used.

  http://tools.ietf.org/html/rfc2246#section-7.4.4 

       opaque DistinguishedName<1..2^16-1>;

       struct {
           ClientCertificateType certificate_types<1..2^8-1>;
           DistinguishedName certificate_authorities<3..2^16-1>;
       } CertificateRequest;

If you really believe that you want to violate the TLS protocol
in this fashion, please state

 (a) that you're intentionally violating the TLS protocol
 (b) what the exact desired semantics of this behaviour are

-Martin

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 10 Jan 2013 19:29:14 -0500

Using terms like 'break' is inappropriate here. If the protocol does not
have the desired behavior then it is being fixed, not broken.

The whole point of IETF protocols is that you can extend them and adapt
them. If the protocol gets in the way, fix the protocol.

One option here would be to define a new flag to announce a client cert
availability on some different basis.

Another would be to publish the cert through DKIM.

On Thu, Jan 10, 2013 at 3:26 PM, Martin Rex <[email-masked]> wrote:

> > Received: from mail-ie0-f191.google.com (mail-ie0-f191.google.com[209.85.223.191])

---

From: [email-masked] (Martin Rex)
Date: Fri, 11 Jan 2013 06:18:19 +0100 (CET)

Before diving into the details, I'm having difficulties to see a purpose
of DANE client-certs for SMTP-AUTH / STARTTLS.

When it is about MUA->MTA (to distinguish "paying" customers from
spammers looking for an open mail relay), many clients will be roaming
around and use temporary, DHCP-assigned addresses from varying domains.

When it is about MTA->MTA, I fail to see the benefit, because it
can not possibly prevent a mail from getting delivered given the
installed base.  And assessing the validity of the mail itself
is DKIMs job, not that SMTP-AUTH.

> have the desired behavior then it is being fixed, not broken.

The TLS protocol (at least SSLv3 and TLSv1.0) is _not_ broken, just the
opposite.  But the behaviour that seems to be desired here is clearly
deep into undefined territory.

When requesting client certs in an infrastructure like SMTP-with-STARTTLS,
where there exist lots of self-signed certs, you might be in for some
surprises (about TLS connection failures).

My knowledge about hands-on OpenSSL behaviour is quite rusty, but
looking at the current openssl-1.0.1c source -- unless the application
writes and supplied its own customer Certificate verifier function,
there exist only two generic verification options;
SSL_VERIFY_PEER and SSL_VERIFY_NONE, and the latter is not even
available on the server SSL (i.e. when checking the client cert):

s3_clnt:
	i=ssl_verify_cert_chain(s,sk);
	if ((s->verify_mode != SSL_VERIFY_NONE) && (i <= 0)
		)
		{
		al=ssl_verify_alarm_type(s->verify_result);
		SSLerr(SSL_F_SSL3_GET_SERVER_CERTIFICATE,SSL_R_CERTIFICATE_VERIFY_FAILED);
		goto f_err; 
		}
	ERR_clear_error(); /* but we keep s->verify_result */

s3_srvr.c:
		i=ssl_verify_cert_chain(s,sk);
		if (i <= 0)
			{
			al=ssl_verify_alarm_type(s->verify_result);
			SSLerr(SSL_F_SSL3_GET_CLIENT_CERTIFICATE,SSL_R_NO_CERTIFICATE_RETURNED);
			goto f_err;
			}
		}
   [...]
f_err:
		ssl3_send_alert(s,SSL3_AL_FATAL,al);
		}

So when the server sends a CertificateRequest with an empty list of
certification_authorities (which is a clear violation of the TLS protocol),
and a defective TLSv1.0 client blindly sends a self-signed cert, or a
cert from a private CA, there is a very high probability that the
certificate path validation will fail.  An SMTP server app on top of
OpenSSL, which did not provide it's own fancy certificate path validation
function, would be faced with a fatal handshake failure.

Leaving the exact semantics, which are currently undefined within TLS,
entirely up to the individual apps implementer, rather than writing them
explicitly down into the SMTP-STARTTLS+DANE specification, would seem
like a terribly bad idea.

> them. If the protocol gets in the way, fix the protocol.

The whole point of the IETF is to **STANDARDIZE** behaviour, and
to provide expert review whether the solution the interest group / WG
is working on, is sensical (or not).

What happens much too often, though, is that protocol options and
features remain seriously underspecified and it left up to the apps
folks to come up with "interesting", implementation-defined behaviour.

Not writing down the details, and what properties are being relied
upon, is what cause the TLS renegotiation barn door to stand wide
open for a whole decade, which the apps folks had been abusing for
delayed authentication.

> availability on some different basis.

I believe this doesn't even scratch the surface of the problem.

(1) This is about seperating certs into
  (a) client certs that can be verified by the server
  (b) client certs that can *NOT* be verified by the server

(2) Either the server will have to convey to the client sufficient
    information that the client can reliably determine whether the
    client certificate it holds is of category (1a) -- which is what
    the "certificate_authorities" list in the CertificateRequest
    handshake message was designed for, but which doesn't really
    fit PKIX-free DANE usage.

    Or the server will have to be able to request from its TLS stack
    that the TLS session is established without any certificate
    path validation, and the app itself will have to sort out the
    mess all by itself, from an unverified client cert chain emitted by TLS.
    But that will require a lot of messy cert processing details
    in an apps spec, and may require changes to deployed TLS implementations
    before it can be used.

-Martin

---

From: Tony Finch <[email-masked]>
Date: Fri, 11 Jan 2013 10:33:23 +0000

Martin Rex <[email-masked]> wrote:

> list is a protocol violation.

Right, but the client does not have to present a certificate in response,
and the server can still let the connection proceed.

Tony.

---

From: Tony Finch <[email-masked]>
Date: Fri, 11 Jan 2013 12:47:29 +0000

Phillip Hallam-Baker <[email-masked]> wrote:

> Rather than assume that the preceding sentence will be treated as
> throwing an exception, I think the last line needs to say 'If all the
> checks succeed, the client can now proceed...'

Good suggestion, thanks :-)

Tony.

---

From: Tony Finch <[email-masked]>
Date: Fri, 11 Jan 2013 13:02:47 +0000

>     in an apps spec, and may require changes to deployed TLS implementations

These worries don't seem to cause significant problems in practice.

Tony.

---

From: [email-masked] (Martin Rex)
Date: Fri, 11 Jan 2013 14:06:27 +0100 (CET)

> These worries don't seem to cause significant problems in practice.

http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf

agreed, just a minor problem .... unless you care about security in any way.

-Martin

---

From: Tony Finch <[email-masked]>
Date: Fri, 11 Jan 2013 13:49:49 +0000

> agreed, just a minor problem .... unless you care about security in any way.

That paper is about server certificate authentication not client
certificate authentication, but it does rather reinforce your point about
messy cert processing details. However one of the big problems with server
authentication is poor support for name checking, which does not apply in
the same way for client authentication.

Servers can support optional client certificates with OpenSSL and GnuTLS
and probably others.

Tony.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 23 Jan 2013 18:53:16 -0500

>> This starts a 4-week (because of time of year) consensus call on adopting  draft-fanf-dane-smtp-04 as a DANE WG document. 
[ SNIP ] 

Dear DANE Working Group,

This concludes the call for adoption on this draft. 
We judge there to be consensus to adopt this draft as a Working Group draft.

Authors, please resubmit this draft as draft-ietf-dane-<foo>.

Thanks,
Your friendly chairs...

> It is impossible to sharpen a pencil with a blunt axe.  It is equally vain
> to try to do it with ten blunt axes instead.
>     --  E.W Dijkstra, 1930-2002
> 
> 
> 

--
It is impossible to sharpen a pencil with a blunt axe.  It is equally vain
to try to do it with ten blunt axes instead.
    --  E.W Dijkstra, 1930-2002