[Uta] NEWSFLASH: DANE TLSA records published for web.de!

Viktor Dukhovni <ietf-dane@dukhovni.org> Thu, 14 April 2016 18:39 UTC

Return-Path: <ietf-dane@dukhovni.org>
X-Original-To: uta@ietfa.amsl.com
Delivered-To: uta@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3752712D6D5; Thu, 14 Apr 2016 11:39:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ZC1ymrTmI2H; Thu, 14 Apr 2016 11:38:58 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B848A12D5D6; Thu, 14 Apr 2016 11:38:57 -0700 (PDT)
Received: by mournblade.imrryr.org (Postfix, from userid 1034) id D4C76284DCA; Thu, 14 Apr 2016 18:38:56 +0000 (UTC)
Date: Thu, 14 Apr 2016 18:38:56 +0000
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
To: uta@ietf.org, dane@ietf.org
Message-ID: <20160414183856.GL26423@mournblade.imrryr.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <http://mailarchive.ietf.org/arch/msg/uta/SR2EKnnj8749AtVeIvjEEEXz7fg>
Subject: [Uta] NEWSFLASH: DANE TLSA records published for web.de!
X-BeenThere: uta@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: dane-users@sys4.de
List-Id: UTA working group mailing list <uta.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/uta>, <mailto:uta-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/uta/>
List-Post: <mailto:uta@ietf.org>
List-Help: <mailto:uta-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uta>, <mailto:uta-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Apr 2016 18:39:00 -0000

The web.de domain has just published DANE TLSA records for its MX
hosts.  This follows earlier "pilot" deployments with the smaller
mail.com and mail.de domains.

    web.de. IN MX 100 mx-ha02.web.de. ; AD=1
    _25._tcp.mx-ha02.web.de. IN TLSA 3 1 1 409c9e91a2a9f4d7881dbf0094b3839d4343a4a57d9bf559fdeb0c1f4c5b8b3e ; passed

    Subject = CN=mx-ha02.web.de,emailAddress=server-certs@1und1.de,L=Montabaur,ST=Rhineland-Palatinate,O=1&1 Mail & Media GmbH,C=DE
    Issuer = CN=TeleSec ServerPass DE-2,street=Untere Industriestr. 20,L=Netphen,postalCode=57250,ST=Nordrhein Westfalen,OU=T-Systems Trust Center,O=T-Systems International GmbH,C=DE
    Inception = 2014-07-22T11:21:46Z
    Expiration = 2017-07-27T23:59:59Z

    web.de. IN MX 100 mx-ha03.web.de. ; AD=1
    _25._tcp.mx-ha03.web.de. IN TLSA 3 1 1 33fccf0e82584b6133cf18d24ae592cc6cbc9cfcab13291a5585a2b20a30eb19 ; passed

    Subject = CN=mx-ha03.web.de,emailAddress=server-certs@1und1.de,L=Montabaur,ST=Rhineland-Palatinate,O=1&1 Mail & Media GmbH,C=DE
    Issuer = CN=TeleSec ServerPass DE-2,street=Untere Industriestr. 20,L=Netphen,postalCode=57250,ST=Nordrhein Westfalen,OU=T-Systems Trust Center,O=T-Systems International GmbH,C=DE
    Inception = 2014-07-22T11:22:46Z
    Expiration = 2017-07-27T23:59:59Z

This is a major milestone in DANE adoption.  [ IIRC they host
mailboxes for a substantial fraction of the population of Germany. ]

One approach to making sure that DANE TLSA records are less likely
to fail that should work well for sites using CA-issued certificates
is to publish both "3 1 1" and "2 1 1" TLSA records:

    mx.example. IN TLSA 3 1 1 <digest of server public key>
    mx.example. IN TLSA 2 1 1 <digest of immediate issuer public key>

    * The "3 1 1" record protects against "expiration" accidents, and
      unexpected changes in the issuer's public key (if new certificate
      chain deployment is automated).

    * The "2 1 1" record protects against key rotation errors should a
      a new server private key be deployed without updating the TLSA
      RRs.  Provided the new certificate is issued by the same CA
      is unexpired, ... the "2 1 1" record will match.

With a bit of monitoring to ensure that both records match,
simultaneous failures of both is much less likely.

This even makes it possible to avoid pre-deployment DNS TLSA records
updates when rotating certificates, provided at least one of the
issuer public key or the server public key is unchanged in the new
chain.

In particular, this is the best practice with Let's Encrypt
issued SMTP server certificates, as explained in:

    https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/

-- 
	Viktor.