On Sat, Oct 11, 2014 at 03:19:58PM +0100, Jeremy Harris wrote:
> Read the doc/doc-txt/experimental-spec.txt
> file for information on DANE use.
Comments on that text:
1. In the paragraph:
The TLSA record for the server may have "certificate usage" of
DANE-TA(2) or DANE-EE(3). The latter specifies the End Entity
directly, i.e. the certificate involved is that of the server
(and should be the sole one transmitted during the TLS handshake);
this is appropriate for a single system, using a self-signed
certificate.
the text seems to suggest that servers with DANE-EE(3) TLSA records
may not present certificate chains containing additional issuing
CAs (intermediate or root). This is not the case. The only
requirement is that the leaf certificate match the TLSA record.
The leaf need not be self-signed and additional certificates may
be presented for interop with any clients using the traditional
PKI.
2. In the paragraph:
DANE-TA usage is effectively declaring a specific CA to be
used; this might be a private CA or a public, well-known one.
A private CA at simplest is just a self-signed certificate
which is used to sign cerver certificates, but running one
securely does require careful arrangement.
It can also be any intermediate authority public or private. For
example one can designate the specific intermediate CA that issues
the serevr's certificate, rather than a root CA or some parent
intermediate CA.
If a private CA is used then either all clients must be primed
with it, or (probably simpler) the server TLS handshake must
transmit the entire certificate chain from CA to server-certificate.
There is no either-or here. The server's handshake MUST contain
the certificate of the CA that is specified in the TLSA record.
If a public CA is used then all clients must be primed with it
(losing one advantage of DANE) - but the attack surface is
reduced from all public CAs to that single CA. DANE-TA is
commonly used for several services and/or servers, each having
a TLSA query-domain CNAME record, all of which point to a single
TLSA record.
Once again this is not an option. Even if the CA is a "public CA"
(whatever that means, there is no universally agreed list of such),
with DANE-TA(2) it MUST be sent on the wire. The note about the
CNAME records could be amplified, this is the primary reason for
using DANE-TA(2) records.
--- Example ---
; published once by server operator and valid indefinitely.
_25._tcp.mx1.example.com. IN CNAME _tlsa._dane.example.com.
_25._tcp.mx2.example.com. IN CNAME _tlsa._dane.example.com.
; published by trust-anchor operator and updated as new CA
; keys are issued (typically every decade or so). Two of
; same listed for at least one TTL when rotating keys before
; issuing keys under a new cert
_tlsa._dane.example.com IN TLSA 2 0 1 {CA cert digest}
--- Example ---
Here the responsibility for updating TLSA records rests with the
CA operator, and server operators just deploy certs as usual, making
sure to not let them expire, but without a need to update the DNS
each time. Only if a key is compromised do server operators touch
the DNS, replacing the CNAME (temporarily until the compromised
key's cert expires) with a "3 1 1" record. They can put the
CNAME back when the compromised cert has expired.
3. In the paragraph:
The TLSA record should have a Selector field of SPKI(1) and a
Matching Type field of SHA2-512(2).
this contradicts RFC6698, which says that only SHA2-256 is required.
So it is in principle possible to run into interoperability issues
by publishing just SHA2-512. If one was really worried about
SHA2-256, one could publish both, and then (per my not yet IETF
adopted, but implemented in Postfix digest agility proposal) the
client must ignore SHA2-256 when SHA2-512 is also published.
For now SHA2-256 alone is probably best practice.
4. Here there's a bit of a botch:
openssl x509 -in -pubkey -noout <certificate.pem \
| openssl rsa -outform der -pubin 2>/dev/null \
| openssl sha512 \
| awk '{print $2}'
Either use "-in certificate.pem" or leave out the "-in" option and
use "< certificate.pem". The hybrid above is not going to work.
5. The OCSP recommentation is not the right way of handling
"revocation" with DANE. This text:
The use of OCSP-stapling should be considered, allowing
for fast revocation of certificates (which would otherwise
be limited by the DNS TTL on the TLSA records). However,
this is likely to only be usable with DANE-TA. NOTE: the
default of requesting OCSP for all hosts is modified iff
DANE is in use, to:
should be replaced with something that explains that with DANE you
don't "revoke" certificates. You simply remove them from TLSA RRs.
The TTLs of TLSA RRs should be kept reasonably short (no more than
say 1 hour). The signature lifetimes of zones should also not be
excessively long (to migitate MiTM replays of stale data).
With DANE-EE(3) just publish a new "3 1 1" binding. With DANE-TA(2)
replace the CNAME to the shared TLSA RRset with a server-specific
"3 1 1" binding.
Good riddance to CRLs, OCSP, OCSP stapling, ...
--
Viktor.
