[dane] DANE and client certificates (DANCE?)

Janne Snabb <snabb@epipe.com> Mon, 11 June 2012 15:29 UTC

Message-ID: <4FD60ED8.6050203@epipe.com>
Date: Mon, 11 Jun 2012 22:29:28 +0700
From: Janne Snabb <snabb@epipe.com>
MIME-Version: 1.0
To: dane@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [dane] DANE and client certificates (DANCE?)
Precedence: list

Hi,

I looked at the current DANE specifications and drafts with my mail
server admin hat on and was surprised to notice that there is nothing
about client certificate validation.

Is this an intentional omission? Is it something that is postponed for
later date?

I tried to look through the mailing list archives, but did not find
anything relevant. The DANE WG charter does not seem to be limited to
server authentication, it just talks about authentication of "Named
Entities" which in my mind can be both clients and servers. Obviously
many people are only thinking about web site certificates and web browsers.

Looks like the current DANE specification could be called DANSE
(DNS-based Authentication of Named _Server_ Entities). It could be
relatively easily extended to cover client authentication (DANCE:
DNS-based Authentication of Named _Client_ Entities). DANSE+DANCE could
then be finally called DANE when merged together. :)


I was thinking that something similar to the following could work:

1. Mail server foo.example.com wants to send an e-mail to mail server
bar.example.net using SMTP.

2. foo.example.com opens a TCP connection to bar.example.net port 25 and
issues STARTTLS. foo.example.com might verify the server certificate of
bar.example.net with DAN(S)E or it might not.

3. bar.example.net requests a client certificate in the TLS handshake.

4. foo.example.com supplies a client certificate to certify that the
SMTP connection really comes from it and not from someone who has
hijacked their IP address.

5. bar.example.net is configured to verify SMTP senders using DANCE. It
performs the following DNS lookups and validations:
 A. reverse lookup the client IP address (returns foo.example.com)
 B. lookup A/AAAA records of foo.example.com and ensure that one of the
returned IP addresses matches the IP of the incoming connection
 C. lookup TLSA records of _25._tcp._client.foo.example.com (the label
"_client" could be something different, this is just an example)
 D. verify that one of the TLSA records matches the client certificate

(Lookups C and probably B need to be DNSSEC validated. Lookup A does not
need to be DNSSEC validated.)

6. At this point bar.example.net knows if foo.example.com authenticated
with the correct certificate and can proceed accordingly depending on
the local policies. It might reject the connection/e-mail if the client
did not provide the correct certificate.


This way a named client entity (typically a server of some sort, not a
end-user workstation) could securely announce that when connecting to a
well-known port at any other entity it shall authenticate using a
specific client certificate (or a certificate signed by specific CA).

IMHO it seems pretty pointless to implement DANE for SMTP without the
ability to verify both sides of the conversation.

Any thoughts?

-- 
Janne Snabb / EPIPE Communications
snabb@epipe.com - http://epipe.com/

[dane] DANE and client certificates (DANCE?) Janne Snabb
Re: [dane] DANE and client certificates (DANCE?) Tony Finch
Re: [dane] DANE and client certificates (DANCE?) Paul Hoffman
Re: [dane] DANE and client certificates (DANCE?) Henry Story
Re: [dane] DANE and client certificates (DANCE?) James Cloos
Re: [dane] DANE and client certificates (DANCE?) Janne Snabb
Re: [dane] DANE and client certificates (DANCE?) Ondřej Surý
Re: [dane] DANE and client certificates (DANCE?) Janne Snabb