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

Viktor Dukhovni <> Mon, 13 July 2015 03:29 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 220E71A0358; Sun, 12 Jul 2015 20:29:54 -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 TyWCCogufohP; Sun, 12 Jul 2015 20:29:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id EEAF51A0354; Sun, 12 Jul 2015 20:29:51 -0700 (PDT)
Received: by (Postfix, from userid 1034) id C439E284D6A; Mon, 13 Jul 2015 03:29:50 +0000 (UTC)
Date: Mon, 13 Jul 2015 03:29:50 +0000
From: Viktor Dukhovni <>
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 03:29:54 -0000

On Sun, Jul 12, 2015 at 10:54:07PM -0400, Paul Wouters wrote:

> >>What are the valid reasons for performing th CT checks? If there are not
> >>any, why not make this requirement a "MUST NOT" instead?
> CT auditors log EE-certs. Checking the CT logs also provides a way to
> signal rogue EE-certs to the original webserver via a gossip/client
> protocol. So I would not say Usage 3 should never check the CT logs.

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).
Furthermore such a certificate is only ever "rogue" if DNSSEC is
compromised to publish rogue TLSA RRs.  So the "CA" we're keeping
honest is the zone signing the TLSA RRset.  I don't believe we have
a CT specification for that yet.

> >CT checks are designed to help keep public CAs honest (detect
> >surreptitiously misissued certificates).
> It's a litte more than just that:
>    Certificate transparency aims to mitigate the problem of misissued
>    certificates by providing publicly auditable, append-only, untrusted
>    logs of all issued certificates.  The logs are publicly auditable so
>    that it is possible for anyone to verify the correctness of each log
>    and to monitor when new certificates are added to it.

Well, with DANE-EE(3) there is no X.509 trusted issuer to keep
honest.  With "3 1 1" an attacker can replace anything in the
certificate other than the public key, giving an astronomical number
of potential certificates to that match the TLSA RRset and might
be logged.  It makes no sense to log the "certificate" it is just
excess baggage.  The TLSA RRset, with DS/DNSKEY/RRSIG records all
the way back to the root ZONE make a lot more sense here, but there
is no CT spec for that I am aware of.

> > With DANE-EE(3), no public
> >CA is involved, so CT (for the X.509 WebPKI) is logically out of
> >scope.
> I don't think that whether or not public/private CA's are in used in
> the TLSA record matters. A client that wants to confirm an EE-cert
> via DNSSEC _and_ CT should be able to do so.

Perhaps if it were possible, but I'm afraid it is not.  From the

    Each CT log will have the power to choose which CAs it accepts
    certificates from. This could lead to a situation where a Root
    Certificate is trusted by one or more browsers, but is not
    permitted to submit newly issued certs to any of the trusted
    CT logs. How can we ensure that this sort of situation doesn't

    We recommend that all logs accept a liberal list of CAs including
    at least the Apple, Microsoft and Opera roots. The CA check is
    for anti-spam and attribution only, so we do not foresee this
    becoming a problem in practice.

Thus CT logs will not accept self-signed, domain-issued, ...
certificates.  Since CT is just keeping the public CAs honest, and
DANE-EE(3) or DANE-TA(2) with a private CA do not use public CAs,
CT simply does not apply.

> >So using "3 0 0" reduces opportunities to use RPK, and might fail
> >to interoperate with RPK-only DANE clients that don't go the extra
> >mile to support "3 0 0" (e.g. they may lack code to parse X.509
> >certificates).  Is that enough reason to say "MUST NOT rely"?
> >
> >Is 2119 language appropriate here, we're not telling servers to
> >not publish "3 0 0", rather we're telling them that if they do,
> >they can't (must not) expect RPK to work.  Is "MUST NOT rely"
> >or "SHOULD NOT rely" a suitable means to say that, or should
> >this be downcased to non-normative english text?
> No, I think you should not try to dictate the local policy behaviour.

You're misreading the text.  It is warning server operators that
"3 0 0" is less suitable for serving RPK clients (if that's what
the server wants) than "3 1 X" is.  This is true, because clients
that want to deal with just keys would have to support extracing
those from a "3 0 0" RRset, where-as with "3 1 X" the key or its
digest is right there.  Thus no local policy is dictated, rather
server operators are advised to be conservative in what they send.

> >This was changed in -13:
> >
> >  If a server uses just DANE-EE(3) TLSA records, and all its clients
> >  are DANE clients, the server need not employ SNI (i.e., they may
> >  ignore the client's SNI message) even when the server is known via
> >  multiple domain names that would otherwise require separate
> >  certificates.
> I am confused. If DANE is only talking about how to verify a certain
> certificate received over TLS, I do not think this document should
> modify the TLS protocol with respect to SNI. It's out of scope.

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.