On 2012-06-12 13:36, Ondřej Surý wrote: > 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). -- Janne Snabb / EPIPE Communications [email protected] - http://epipe.com/ _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
