Deployment news (comcast.net publishes TLSA RRs)

[Viktor Dukhovni]

On Fri, Nov 20, 2015 at 10:38:14PM -0500, Patrick Domack wrote:

> >Perhaps we need a new protocol by which a TLS server can securely
> >pre-publish the next certificate without activating it (say include
> >it in a new TLS extension), thus allowing the DNS server operator
> >to automate TLSA record updates by querying the SMTP server
> >(authenticated via the current records).
> 
> That sounds pretty difficult to adjust for, and would need a lot of changes.

Well, it requires IETF action and software support on the server
side, yes.

> I like the current dnssec method, where we can publish multiple keys. I will
> generally publish a new key a month ahead of time for my ksk rollover, then
> rotate it, and then a month later remove the old key.

This works today, but automating the publication of the "future"
TLSA record is the part that some will struggle with.

> The same method could be done for tlsa, by publishing multiple records.

Not could, is.  See:

	https://tools.ietf.org/html/rfc7671#section-8.1
	...

> I have not tested if any software accepts this or not, but just publishing the
> new one a week ahead of time, rotating it, and removing the old one at the
> same or later time (in case of failback), to me sounds like the perferred
> method.

Yes, that's what section 8 of RFC7671 describes.  And of course
this is supported by Postfix and Exim, and will soon(ish) be
supported by OpenSSL.

The problem is that if certificate deployment is fully automated
(see today's Let's Encrypt thread on this list), then prepublishing
the next TLSA record becomes difficult.

The work-arounds, are:

    * Keep the key the same while getting new certificates for it,
      publish "DANE-EE(3) SPKI(1) SHA2-256(1)" records, change keys
      manually, and go through the usual prepublication process for
      the key digest.

    * Switch to using "DANE-TA(2) SPKI(1) SHA2-256(1)" records,
      with a selector of SPKI rather that Cert, because with a
      third-party issuing CA, you have less control over when the
      CA cert might get re-issued to extend its life, or cross-sign
      it, ...  Then you're good while the same CA (private key)
      continues to issue your certificates.  The CA cert needs to
      appear in your chain even if it is a root CA.

	https://tools.ietf.org/html/rfc7671#section-5.2

-- 
	Viktor.