Subject: [dane] DANE and client certificates (DANCE?)

From: Janne Snabb <[email-masked]>
Date: Mon, 11 Jun 2012 22:29:28 +0700

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
[email-masked] - http://epipe.com/

---

From: Tony Finch <[email-masked]>
Date: Mon, 11 Jun 2012 16:57:56 +0100

> ability to verify both sides of the conversation.

The point of server authentication for SMTP is to make sure you are
sending mail where you intend to.

The point of client authentication is ... what?

What the server cares about is the authenticity of the message data, which
has relatively little to do with where it came from and even less to do
with the client host name.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Thames, Dover, Wight: Cyclonic 4 or 5, becoming north or northeast 5 or 6.
Slight or moderate. Occasional rain. Moderate or good, occasionally poor.

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 11 Jun 2012 09:06:01 -0700

> The point of client authentication is ... what?

...to make the server sure it is speaking to the client it thinks it is.

> with the client host name.

That's one view; another is that the two parties both want to be sure of the others' identity.

Jakob and I are dealing with client auth in our S/MIME proposal; it could be applied to client certificates as well.

---

From: Henry Story <[email-masked]>
Date: Mon, 11 Jun 2012 18:14:33 +0200

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

Once you have Dane for server authentication it makes client authentication
with WebID even easier to deploy.

See the spec on the w3c at http://webid.info/spec/
You can also see the short video explaining how that works at http://webid.info/
And you can join the community at 
    http://www.w3.org/community/webid/

It is also possible to extend this for trust of issuers as I argued recently
in WebID and eCommerce:

    http://bblfish.net/blog/2012/04/30/

Henry

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

Social Web Architect
http://bblfish.net/

---

From: James Cloos <[email-masked]>
Date: Mon, 11 Jun 2012 12:38:28 -0400

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

TF> The point of server authentication for SMTP is to make sure you are
TF> sending mail where you intend to.

TF> The point of client authentication is ... what?

So that the person reading the message can confirm the path it took.

It is more a forensic tool than a real-time one, AFAICS.

I have seen benefit from it, albeit rarely, given the small number of
MTAs which offer or request client certs on MTA-MTA sockets.

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

---

From: Janne Snabb <[email-masked]>
Date: Tue, 12 Jun 2012 02:27:04 +0700

> The point of client authentication is ... what?

It would make automatic or manual recognition of fraudulent e-mails much
more simple and effective.

These days I receive perhaps 100 e-mails a year from someone who claims
to be from my bank and asks me to perform some important action.
Currently I can not perform that action unless I do a careful risk
assessment based on "received" headers and whatever, but I still can not
be absolutely sure because it is all guesswork as no verified
certificates are involved.

Therefore I have to assume that all of those e-mails are fraudulent and
as a result I miss the one important e-mail a year which was really from
my bank. I should have done something to renew my credit card for example.

With the feature that I am suggesting my mail system could tell me that
"we have positively authenticated that this e-mail was sent to us by a
server which is named mailserver.$my_bank.com". I could be quite
confident that the e-mail actually arrived from my bank. Equally
confident as when https connection to www.$my_bank.com presents a server
certificate identified by _443._tcp.www.$my_bank.com TLSA record. My
receiving MTA could make the authentication results available to my MUA
either using the "Authentication-Results" header or by some other
underlying mechanism.

Obviously this overlaps with some other technologies. My bank could sign
their e-mails using PGP or S/MIME, but in reality almost nobody except
geeks does that because of various difficulties (the DANE + S/MIME work
might finally make S/MIME signatures automatically verifiable). The
bank's mail server administrators might be geeky enough to implement
DAN(C)E on their servers. They would only need to set it up once and as
a result all their outgoing e-mail could be positively identified coming
from whoever controls their domain.

DANE + S/MIME and DANE/DANCE + SMTP would be complementing each other,
working on different levels of the e-mail infrastructure.

Google apparently sees some benefit in presenting a verifiable client
certificate in their outgoing SMTP sessions.

---

From: Ondřej Surý <[email-masked]>
Date: Tue, 12 Jun 2012 08:36:15 +0200

> either using the "Authentication-Results" header or by some other

We already have different technologies for that - DKIM, S/MIME...

I am not sure that reinventing the wheel for a <n>-th time, because
we failed before, would actually help anything

> might finally make S/MIME signatures automatically verifiable).

The difficulty mainly lies in the presentation that information
to the end user.  Your proposal doesn't really help with that.
It would be yet

> working on different levels of the e-mail infrastructure.

And end-user would be totally confused.  You seem to forgot the
fact that SMTP is a bunch of loosely connected servers which
might or might not relay your email.

Try to answer following questions:

How is your proposal better than DKIM?

How is your proposal better than S/MIME? (and/or PGP)

How would you present the information that the email came
through two or more SMTP relays before it has reached you?

<chair hat on>
I am not even sure this belongs here.  It changes the semantics
of SMTP protocol and since we don't have a SMTP WG (now) I think
it's more suitable to individual submission in App area.  It
seems to me that this doesn't change any semantics of DANE
protocol (short summary: "hey, receiving MTA - check TLSA record
of the sending MTA").

But of course the WG will is my will, so if you want to take this
work into the WG, we can try to recharter and convince our AD that
this really belongs here.  But it would take a lot of strong
arguments to convince me and not to mention our beloved AD :).
</chair hat on>

O.
--
 Ondřej Surý -- Chief Science Officer
 -------------------------------------------
 CZ.NIC, z.s.p.o.    --    Laboratoře CZ.NIC
 Americka 23, 120 00 Praha 2, Czech Republic
 mailto:[email-masked]    http://nic.cz/
 tel:+420.222745110       fax:+420.222745112
 -------------------------------------------

---

From: Janne Snabb <[email-masked]>
Date: Tue, 12 Jun 2012 22:43:47 +0700

> We already have different technologies for that - DKIM, S/MIME...

Ok. I thought I was pointing out an obvious lack of feature in DANE
which limits its use cases and was inquiring if there is a reason for
that. Looks like everyone is missing my point because I used SMTP in my
example. I thought SMTP would be a good example because it is well known
and could easily benefit from DANE + DANCE. Looks like it was a bad
example because everyone is afraid of improving SMTP after the previous
attempts to improve internet mail have failed miserably. Please forget
SMTP for the rest of this mail. I would like to try once more to get my
point across before giving up.

What I am proposing is a generic mechanism which can be easily utilized
by any protocol running on top of TLS/DTLS and which uses a
well-known/pre-defined port number at the server side and a known DNS
name on the client side. It would be an extension of the current DANE
work to cover not only verification of server certificates but also
client certificates within the scope of DANE (the endpoints must be
"named entities" in the DNS for this to be useful -- which already
applies to the current DANE work as a fundamental requirement). Many use
cases of TLS/DTLS require authentication of both parties, not just the
server (which DANE currently implements).

Read the following again (from my original mail):

> 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).

The goal of IPSEC was to implement transparent end-to-end security in
the internet. It failed due to various reasons (key management/trust,
NAT traversal, complexity, disagreements, etc).

Now we have TLS and DTLS. They are ok because it is relatively easy
to run almost any existing protocol on top of them. TLS provides
confidentiality as well as authentication of both ends of a
communication circuit.

The #1 problem with TLS is key management and trust. DANE addresses that
problem nicely (or currently half - the server side - of that problem).
By using the pre-existing DNS trust infrastructure we can now attach any
certificates to any entities which have names in DNS. This liberates the
consumers from the complexities of PKI, CRLs, CAs, CSRs, cut'n'pasting
PEM encoded blobs around, trusting or not trusting some untrustworthy
CAs, etc. We can now make all of this very simple by just generating a
self-signed certificate and put the corresponding TLSA record in the
DNS. After that everyone else can just use DNS to verify that
certificate and be secure.

Now, again, TLS provides facilities for authenticating both ends of a
communication circuit. DANE implements only the other half of that. In
TLS one of the two communicating parties is a client and the other one
is a server, even though both endpoints may really be servers with known
names in DNS. A client certificate is not different from a server
certificate. TLS is able to authenticate both endpoints. DANE can only
authenticate the receiving/server end of the connection. Why such an
omission? The features of DANE should match the features of TLS. I
believe and hope that the intention of DANE is to be protocol-agnostic
and not artificially limit its usability to verifying only web site
certificates. The current DANE work already has all the pieces for
client authentication using the same TLSA DNS record. We need only a
couple of paragraphs which explain how to attach a client certificate to
client's DNS name.

Here is a new example:

I process credit card payments.

My customers have POS (point-of-sale) systems which accept credit cards
and connect to my server to process the payments.

The protocol is proprietary, but it runs on top of TLS (it could be even
XML-RPC or SOAP over HTTPS or whatever else you like). The POS terminals
connect to TCP port 555 on my server and use an ephemeral port on their
side.

Obviously I need to authenticate the incoming connections from the POS
terminals. The POS terminals also need to authenticate my server, which
is already possible with DANE, and therefore I am ignoring that part
because it does not require attention any more.

With the current pre-DANE technology I need to tell my customers to
cut'n'paste PEM encoded blobs back and forth in their POS systems. Also
my customers, myself or some third party must run a CA. Or otherwise
both parties have to manually enter and remove POS specific
keys/certificates at both ends every time a new POS is installed or old
one is removed/stolen.

If we have DANCE, I can tell my customers to create their certificates
any way they wish and to just specify the POS terminals' names and TLSA
records in their DNS. I can specify at my payment processing server that
anything that authenticates with a name matching *.pos.$customername.com
is to be trusted. My customers can manage that namespace themselves.
They only need to register the name of the POS terminal in their DNS and
attach a DANCE TLSA record to it.

There is one big benefit from using DANE/DANCE: If the customer later
wants to start using a different payment processor, they only need to
change the payment server's address in their POS terminals and inform
the new provider that their terminals authenticate using a DNS name in a
specific sub-domain. There is no need to re-create keys, re-issue
certificates, change trusted CAs or anything like that. All the key
management complexity is completely gone.

For example:

55.2.0.192.in-addr.arpa.        PTR   sunnytown6.pos.example.com.
sunnytown6.pos.example.com.     A     192.0.2.55
_555._tcp._client.sunnytown6.pos.example.com. TLSA XXXXXXXXXX

Note the port number in the client's TLSA record. This record announces
that when this named entity makes an _outgoing_ connection _to_ TCP port
555 of any other entity it shall authenticate using the specified TLS
certificate. We need the "_client" label or something similar to
distinguish between client and server TLSA records (no need to invent a
new DNS record for this).

This makes DNS names useful for strong client authentication. I can
just put "*.pos.example.com" in my ACL and my payment server can
instantly perform strong authentication of any entity residing in that
namespace. Now DNS name based ACLs are useful for strong authentication
of clients. I am not vulnerable to IP or DNS spoofing because I have
TLS+DNSSEC+DAN(C)E.

If you read this far, thank you for your time. If you are planning to
reply along the lines "this would not work because POS systems..." you
have missed my point and are wasting your time. I do not know anything
about current POS systems except that they need a secure channel and
authentication of both endpoints, which can be implemented as in this
example by using TLS. The last time I touched a POS system was more than
15 years ago and at that time the "secure channel" part was addressed by
using a X.25 circuit and the "authentication" part was solved by using
static addresses and access-lists. I think POS is a better example than
SMTP because people should not be able to argue about the need of client
authentication in this TLS use case.

My goal is to convince this WG that TLS client authentication is needed
in many TLS use cases and can/should be included in DANE (or
alternatively there should be a conscious decision to leave it out if
for example there is some flaw in my thinking that I do not see myself).