Re: [dane] I-D Action: draft-ietf-dane-srv-04.txt

[Viktor Dukhovni <[e-mail]>]

On Sat, Feb 15, 2014 at 07:53:46AM +0100, Martin Rex wrote:

> > There is no "true today" for DANE, as there are in effect no "real"
> > DANE implementations aside from the one in Postfix (I've looked at
> > some experimental implementations, but they are all incomplete and
> > often insecure).
> 
> This is about TLS implementations.  Keep in mind that the server does
> not even need to know about DANE at all -- anyhow the server WILL
> be acting on the KeyUsage in his very own certificate and drive
> the choice of cipher suites based on the KeyUsage requirements
> from the quoted part of the TLS spec:

The CU=DANE-EE(3) requirements in the SMTP and SRV drafts apply
ONLY to the verifier, i.e. the client.  The server does not perform
a lookup of its own TLSA RRs, ... and just sits there and does TLS.
The only server-side TLS requirement with DANE is a requirement on
the server operator to configure the server to include the root CA
in the server certificate message when the server operator configures
TLSA records with CU=DANE-TA(2) to specify trust in a root CA.

In particular the server is quite free to enforce keyUsage or other
policy, ... on itself.  It is up to the server operator to make
sure the server does not commit "TLS suicide" by deciding its own
private keys and certificate chain are no longer suitable for TLS.

> Defective implementations excepted, the TLS protocol engine will
> look at the KeyUsage attribute of the Server certificate and check
> the cipher suite selection for compatibility -- and the application
> call will NOT have a say in this.

You seem to be wedded to the idea that DANE support will be in
application code and not in "TLS engine code".  Having actually
implemented a complete DANE verifier, I can assure you that there
will be very few applications indeed that attempt to do this.

DANE will only be adopted by applications when it is implemented
in the TLS engine, and applications can just tell the TLS engine
the server name/protocol/port or perhaps provide the relevant TLSA
records and list of acceptable server names and ask the TLS engine
to do all the work.

> Whether a TLS server or TLS client will act on the expiration of an
> X.509 server certificate is also implementation dependent, and similarly,
> the application caller (that is using DANE for establishing trust),
> may not get a say in that.  That is particularly true for the server-side
> which may not necessarily see/use any DANE code.

Again a statement of the view that DANE in the TLS client is outside
the TLS engine.  DANE changes the semantics of the server certificate
chain and needs to augment the chain processing in the TLS engine.

> I would really appreciate if you would refrain from suggesting to
> create and use bogus X.509 certificates with DANE, _including_ CU=3.
> DANE is an alternative means to establish trust, and for
> CU=3 it additionally shortcuts/omits the name checks.  But not more.

I am not suggesting that servers create "bogus" certificates.  I
am requiring *clients* with CU=DANE-EE(3) to ignore the certificate
content except to the extent needed to match the certificate with
the TLSA certificate association data field.

The reason for this is that the most frequent (and essentially
only) source of failure I observed in a decade of being a postmaster
at large site that in fact applied PKIX secure-channel policy to
some peer domains was certificate expiration.  There was nothing
appreciably more wrong with the peer domain's certificate, the day
after it expired than the day before.  Just an operational oversight.

With DANE "IN TLSA 3 ? ?" we have an opportunity to move the
expiration time outside the certificate, where it is difficult
to change (requires someone to replace the server chain before
a fixed future date).  When the expiration time is in DNSSEC,
it extends automatically every time the same zone file content
is re-signed.  No unplanned outages.

The server operator is free to plan key/cert roll-over whenever it
is convenient, independently of any artificial horizon in the
server's certificate.  Moving expiration out of the certificate
will be the most important thing we can do to promote use of TLS!

With many servers to manage, operations teams hate certificate
expiration!  Invariably some server is forgotten and is updated
after an outage.

With DANE "3 ? ?" the server operator can use the certificate
expiration as in an input to a self-audit tool that reminds him
to replace the certificate when convenient, but failure to do so
is no longer a problem for either the client or the server.

> If you desperately want naked keys, join Paul Wouters in his effort
> to get that working with TLS.

This would only work when all the TLSA RRs in the RRset are
"DANE-EE(3) SPKI(1) ?".  If any other TLSA RRs are present it is
not safe to signal support for bare keys.  And of course bare key
support in TLS engines is some years away.  I am not prepared to
wait that long.

Handling a mixture of certificates and bare keys makes APIs rather
more complex, and breaks backwards compatibility.  So I don't expect
that DANE clients that support X.509 chains will bother to signal
support for bare keys any time soon.

-- 
	Viktor.