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

[Viktor Dukhovni <[e-mail]>]

On Mon, Feb 17, 2014 at 02:30:57PM +0100, Martin Rex wrote:

> > Having actually implemented a complete DANE verifier, I can assure
> > you that there will be very few applications indeed that attempt
> > to do this.
> 
> A number of TLS protocol implementations come with utility functions
> to make the task easier for applications to consume TLS.

We should not descend into a scholastic debate of the fine details
of where the boundary lies between "TLS engine code" and library
code that performs related functions on behalf of the application.

Both TLS protocol processing and certificate trust chain verification
a la DANE, will need to be provided by a complete SSL/TLS toolkit
to enable its applications to employ DANE.  DANE will require
various changes in those toolkits, some of those might be in the
protocol engine some in the related functions.

This said, my intention with DANE-EE(3) semantics is not necessarily
to preempt various features of the EE certificate that are not
covered by the TLSA record.  Rather, my goal was to make sure that
the TLSA record content is not trumped the content of the certificate
(whose signer is not even trusted since we're not checking any PKIX
trust chain).

We've already agreed that name checks are more than adequately
handled by the implied binding with the port, protocol and server
name in the TLSA base domain.

Beyond that, I'd like to make sure that also the validity interval
is from DNSSEC (no sudden failure so long the DNS zone continues
to publish a matching TLSA RR).  Similarly, RFC 5280 extended Key
Usage (sequence of KeyPurposeId) is superseded by the RRtype (TLSA)
to imply an acceptable purpose of id-kp-serverAuth.

So I can live with a weaker requirement, if that settles the issue.
With DANE-EE(3):

    - No PKIX signature verification.  Covered by TLSA association
      data field, and in any case we don't have a trusted issuer
      whose signature can be checked.  [ Obvious. ]

    - No name checks based on certificate content.  Covered
      by TLSA (service, protocol, base domain) triple.  [ Already agreed. ]

    - No expiration checks based on certificate content.  Covered
      by TLSA RRset's RRSIG expiration time.	[ Still under discussion. ]

    - No purpose checks based on extended key usage.  Covered by
      TLSA RRtype.	[ Still under discussion. ]

If there are other elements of the certificate potentially relevant
to the TLS protocol engine, any related functions or the application,
I can live with that.

It was my purpose to make the requirement as simple as possible,
and ignoring everything in the certificate is much simpler to
state than ignoring a subset.

In particular I have no objection to TLS protocol engines complying
with the keyUsage bits from:

    http://tools.ietf.org/html/rfc5280#section-4.2.1.3

Of the two "Still under discussion" fields, the expiration is by
far the most important for the operational success of DANE.  By
far the most common problem is expired certificates, and with
DANE-EE(3), we have an opportunity to eliminate this problem.
There is no more expiration, rather TLSA records are withdrawn from
DNS by the server operator once the certificate is no longer
appropriate (for whatever reason).  

The server operator should of course audit deployed certificates
and may use the expiration date as a reminder to rotate keys, but
with DANE-EE(3) I think it makes much more sense to leave the timing
of key rotation to the server operator, not the client.

-- 
	Viktor.