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

Paul Wouters <> Mon, 13 July 2015 02:54 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id CF0921ACD80; Sun, 12 Jul 2015 19:54:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.69
X-Spam-Status: No, score=0.69 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id AizfT2seN91C; Sun, 12 Jul 2015 19:54:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8553D1ACD7B; Sun, 12 Jul 2015 19:54:14 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by (Postfix) with ESMTP id 3mV8h363c5z1H8; Mon, 13 Jul 2015 04:54:11 +0200 (CEST)
Authentication-Results:; dkim=pass (1024-bit key) header.b=CBca+BIO
X-OPENPGPKEY: Message passed unmodified
X-Virus-Scanned: amavisd-new at
Received: from ([IPv6:::1]) by localhost ( [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id h2FJR7k9N15E; Mon, 13 Jul 2015 04:54:10 +0200 (CEST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS; Mon, 13 Jul 2015 04:54:10 +0200 (CEST)
Received: from ( []) by (Postfix) with ESMTP id 132F780042; Sun, 12 Jul 2015 22:54:09 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=default; t=1436756049; bh=KoykGpZ+3auXyfoF/MTusWD5vv79qjP1tVtmRETvXaU=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=CBca+BIOztBym8h6MSJqYz3z6tz9ONqOX3APTGKajBQQ2/TprXO7kB559NTmR4zxH ePXNeuBqbX1HZzawMy+ENau3i9o111weLwEd0tJ0bwaZSlysXVZAm0OqIcyVcmS/di gSAzsM5CzUUgISdzsW2/8F5bKm5gaCQ8ZlZWFC2Y=
Received: from localhost (paul@localhost) by (8.15.1/8.15.1/Submit) with ESMTP id t6D2s7Ya012828; Sun, 12 Jul 2015 22:54:08 -0400
X-Authentication-Warning: paul owned process doing -bs
Date: Sun, 12 Jul 2015 22:54:07 -0400
From: Paul Wouters <>
To: Viktor Dukhovni <>
In-Reply-To: <>
Message-ID: <>
References: <> <>
User-Agent: Alpine 2.11 (LFD 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"; format="flowed"
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 02:54:17 -0000

On Sat, 11 Jul 2015, Viktor Dukhovni wrote:

>> * Section 4.8, page 8:
>>> Therefore, when a TLS client
>>> authenticates the TLS server via a TLSA record with usage DANE-EE(3),
>>> CT checks SHOULD NOT be performed.
>> 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.

> 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.

>  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.

>> * Section 5.1, page 10:
>>> Servers SHOULD NOT rely on
>>> "DANE-EE(3) Cert(0) Full(0)" TLSA records to publish authentication
>>> data for raw public keys.
> I am open to MUST NOT, if that's better.
> Note that the impact of such inadvisable reliance, is that some
> clients capable of using raw public keys (but also capable of
> handling certificate chains) might choose to not do so.  And other
> clients, that support only raw public keys, might go the extra mile
> and support extracing the public key from a "3 0 0" record, assuming
> they can parse X.509 certificates (part of the rationale for RPK
> is to allow clients to shed such code).

You keep trying to force different policies for raw public keys versus
(possibly throw away) x509 container based public keys. Because we know
software will only upgrade over a very long slow time, we know there
is going to be a substantial amount of time when "basically" raw keys
will go into a throw-away x509 container. Therefor, as I said before,
it is not wise to differentiate between the two. An EE-cert could be
a raw public key in disguise purely for compatibility reasons.

> 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.

> 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.