Re: [secdir] [dane] SecDir Review of draft-ietf-dane-ops-12

Viktor Dukhovni <> Mon, 13 July 2015 04:01 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0132F1A1A0C; Sun, 12 Jul 2015 21:01:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id avyQhruVr6pw; Sun, 12 Jul 2015 21:01:00 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3C7831A19E4; Sun, 12 Jul 2015 21:01:00 -0700 (PDT)
Received: by (Postfix, from userid 1034) id 2E0A4284D6A; Mon, 13 Jul 2015 04:00:59 +0000 (UTC)
Date: Mon, 13 Jul 2015 04:00:59 +0000
From: Viktor Dukhovni <>
To: Paul Wouters <>
Message-ID: <>
References: <> <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <>
Cc: IETF Security Directorate <>, "" <>,
Subject: Re: [secdir] [dane] SecDir Review of draft-ietf-dane-ops-12
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 13 Jul 2015 04:01:02 -0000

On Sun, Jul 12, 2015 at 11:37:07PM -0400, Paul Wouters wrote:

> >DANE-EE(3) certs are often self-signed, and there's no way to
> >control the "spam" problem on the CT logs with DANE-EE(3).
> You don't know what audit logs will use for policies. Perhaps some
> audit logs will be dedicated to only self-signed certs. I do not
> think the dane document should dictate CT behaviour.

The problem is that the CT documents are otherwise liable to dictate
DANE behaviour.  For example, require SCTs in DANE-EE validated
certs.  That would be unfortunate.  This document notes that the
present experimental CT in RFC 6962 is inapplicable to DANE.

CT logs that record leaf certificates would be essentially useless,
A rogue TLSA RRset with a "3 1 1" binding will work regardless of
the certificate content, just based on the public key.  A misissued
TLSA RRset will bind a certificate that contains no information as
to which domain was compromised.  Here's a certificate with an
empty subject and issuer name, what will the CT log make of that?


And yet it will match IN TLSA 3 1 1 20041CBFD6570C48ACD8D526572137B9090E8037D115FB3C21218D9E9992A9C2

The *only* way to do CT for DANE TLSA is to do CT for DNS, and there
is no CT for DNS in RFC 6962.

> >Furthermore such a certificate is only ever "rogue" if DNSSEC is
> >compromised to publish rogue TLSA RRs.
> Not if they use a CT log for prepublishing somehow. Although that is
> unlikely to happen with SCT's without a CA, I still think you should
> not make those decisions on this document.

It is not a policy decision, it is just logic.  The impossible
cannot be done.

> >You're confused.  The server is free to ignore the client's SNI
> >extension when it has a single certificate that works for all hosted
> >domains, because clients authenticate the server via the certificate
> >or key digest, and don't care about what name is in the certificate.
> >We're not modifying TLS, we're explaining that the server is free
> >to ignore the client's SNI extension.
> How is that not modifying TLS server behaviour?

It is not modifying the TLS protocol, servers are already free to
ignore SNI and return whatever certificate chain they please.  This
document explains that with DANE-EE(3) this yields results that
are satisfactory to the client.

As for modifying TLS, we're for example mandating the transmission
of self-signed roots with DANE-TA(2), and that too is within the
realm of what TLS can do, we're just defining a behaviour profile
that makes DANE-TA(2) work (it does not otherwise).