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.
Phillip Hallam-Baker wrote:
>
> Using terms like 'break' is inappropriate here. If the protocol does not
> 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.
>
> 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.
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.
>
> One option here would be to define a new flag to announce a client cert
> 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
> On Thu, Jan 10, 2013 at 3:26 PM, Martin Rex <[email protected]> wrote:
>
> > 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
> >
> >
> > James Cloos wrote:
> > >
> > > 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 protected]>; 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 protected]>; 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 protected]>; 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
> > > --
> > > James Cloos <[email protected]> OpenPGP: 1024D/ED7DAEA6
> > > _______________________________________________
> > > dane mailing list
> > > [email protected]
> > > https://www.ietf.org/mailman/listinfo/dane
> > _______________________________________________
> > dane mailing list
> > [email protected]
> > https://www.ietf.org/mailman/listinfo/dane
> >
>
>
>
> --
> Website: http://hallambaker.com/
_______________________________________________
dane mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dane
