Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics

Benjamin Kaduk <> Tue, 06 November 2018 16:06 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4B3691277BB for <>; Tue, 6 Nov 2018 08:06:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.161
X-Spam-Status: No, score=-1.161 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.999, RCVD_IN_DNSWL_LOW=-0.7, T_SPF_TEMPERROR=0.01] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gNAdQESbx-h9 for <>; Tue, 6 Nov 2018 08:06:35 -0800 (PST)
Received: from ( [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6F7951200D7 for <>; Tue, 6 Nov 2018 08:06:10 -0800 (PST)
Received: from pps.filterd ( []) by ( with SMTP id wA6G38F9023870 for <>; Tue, 6 Nov 2018 16:06:10 GMT
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=date : from : to : subject : message-id : references : mime-version : content-type : in-reply-to; s=jan2016.eng; bh=hcvzuTUX8M6OvOa0ZZF++Kl1WiCmrcWNvOYTPIUhHlk=; b=lN1Bxk5p4YlxR12AtiN8+E9ptAC4DL8RHCybOUy6MnSmOFnnN27C+0JIg3227YoiJBF7 389BxAR/Fz+s9rTg5VvuZfSlU/Hml6ikWo9gyV/LmWa6F9Y4eF58KcUCylZ1BzEnYtdF 6pOULNJAKIo13tPtYr+FAWwii5cC0LxcW1znSbXM7WfSYhFGTulGty2kPZbXKg4Xt70B mW4QZbE+rOZiJIN8Vd7cU71NHIIpn8SmCpTSH1KiaHMdz05IGOfDw5aABrivOvk03G89 qP4L1AhrjOKw+qKxAi+GBygEglGYLqptFc7EYEpvH5NWn9ea0nslquCJLWQyzZp7y1Jn YA==
Received: from prod-mail-ppoint2 ( []) by with ESMTP id 2njyasaeyb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <>; Tue, 06 Nov 2018 16:06:09 +0000
Received: from pps.filterd ( []) by ( with SMTP id wA6FnrYG004213 for <>; Tue, 6 Nov 2018 11:06:08 -0500
Received: from ([]) by with ESMTP id 2njywsasny-1 for <>; Tue, 06 Nov 2018 11:06:08 -0500
Received: from ( []) by (Postfix) with ESMTP id 7001A829B5 for <>; Tue, 6 Nov 2018 16:05:15 +0000 (GMT)
Received: from bkaduk by with local (Exim 4.86_2) (envelope-from <>) id 1gK3qs-0001gG-Mw for; Tue, 06 Nov 2018 10:05:14 -0600
Date: Tue, 06 Nov 2018 10:05:14 -0600
From: Benjamin Kaduk <>
To: "<>" <>
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.24 (2015-08-30)
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-06_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=2 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811060139
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-11-06_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=2 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1807170000 definitions=main-1811060141
Archived-At: <>
Subject: Re: [TLS] some thoughts on dnssec-chain-extension, pinning, and broader semantics
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 06 Nov 2018 16:06:40 -0000

On Mon, Nov 05, 2018 at 09:00:29AM -0500, Viktor Dukhovni wrote:
> > On Nov 5, 2018, at 8:01 AM, Benjamin Kaduk <> wrote:
> > 
> > Once we start talking about pinning of any sort, we move from this
> > extension just being "transport some DNS records" into conveying some
> > sort of additional semantics.
> Transporting some bits *always* carries additional semantics, otherwise

Of course!  But if we don't precisely specify those semantics, we expect
to get DISCUSS positions at IESG evaluation (as "not interoperably

> why carry the bits.  For example, already in -07 there is clear text
> specifying that the transported records can be cached for their DNS TTL,
> and that once delivered DANE records should not be ignored on failure.
> That rather looks like semantics to me, much more than transport some bits.

Is it new semantics for this TLS extension, or just the semantics of "you
have a DANE record; this is what you do with it"?

> > It seems that we have not really had a structured discussion about what
> > semantics and information flows we might or might not want to convey in
> > this extension (in one or both directions!), and I'm reluctant to consider
> > adding such semantics without such a discussion.
> I really don't think that at this juncture it is productive to wipe the
> slate clean and consider all possible proposals, even ones that nobody
> has put forward as yet.  Why would we want to do that.  There is clearly

When we do work at the IETF, proposals are not presented as a "take it
or leave it" option -- usually, they are starting points for further
analysis and discussion: "is this optimal?", "is it better if we tweak
it in this way?", etc.  I am presenting a framework in which to try to
answer these questions, starting from the proposal on the table.

In other words, I am pointing out that there is a process step that
needs to happen before this draft can be published.  This need not start
from a "clean slate", but we do need to be confident that we understand
what we are publishing.

> just one primary contentious issue to resolve, and I rather think your
> train of thought is a distraction from the issue at hand.

The IETF process requires reaching a consensus understanding of the
technical facts of an issue.  My train of thought is an effort to seek
that understanding in the area of downgrade countermeasures, since in my
judgement it has not been achieved by the previous WG discussions.  If
we have no WG consensus understanding of pinning, we cannot publish
pinning.  That could mean not publishing at all, or publishing something
that lacks pinning.  The latter would of course not preclude other work on
pinning by interested parties.

> > If we accept the premise that the intention of DANE as relevant in this
> > space is to allow the server to convey to the client the server's
> > preferences for how the client should authenticate the server, we may also
> > want to consider the case where a server operator wants to eventually get
> > to a DANE-only state where it can ignore the web PKI.
> Nobody is looking for this.  There's no point.  WebPKI certificates are
> free (and worth every penny).  DANE adoption is far too light to even
> begin to contemplate abandoning WebPKI, and we're probably two decades
> away from being able to do that, by which point the quantum computer
> apocalypse may have made many of the current designs moot.

That's good input; thanks.

> > (There may not be
> > many or any servers that actually end up wanting to do this, but it's not
> > unreasonable to consider the possibility.)
> It seems unreasonable to me, because no such signalling was for example
> proposed for raw public keys or various PSK methods, etc.  And of course
> the server operator can log the use of the extension and draw conclusions
> about client support based on that, and the overall technology landscape.
> There's no need to include this in the discussion.

The chairs should feel free to shut this down if needed.
But I'll note that the server's logging is not going to get any signal
from clients that can get DANE records via their normal resolver, with
the current proposal.

> > Similarly, the server may want to indicate things like:
> > 
> > (a) the server wants to be authenticated via DANE (yes, this is just the
> >    contents of the DNS)
> And any client with a decent network environment can just query the
> DNS directly, and never use the extension and have the record hot
> in the local cache.  So there's no need for anything too complicated
> here.  We just need to provide as much of the downgrade-resistance
> that DNSSEC gives automatically, also to clients that for some time

I think I'm confused about what you mean by "the downgrade-resistance
that DNSSEC gives automatically".

> will be able to do DNSSEC.
> > I deliberately am not trying to come to a conclusion in this message, as I
> > am not confident that I have even come up with all the potential semantics
> > worth thinking about, and I think that any motion in this space should only
> > be taken with WG consensus.
> I think at this point hypothetical semantics is not a helpful direction.

I'm sorry you feel that way.  We've seen a few participants raise a
specific pinning proposal but they seem to have squelched discussion of
any other pinning options.  It seems that in any case the semantics are
hypothetical until we have a consensus and/or deployment experience.

> If you have a concrete proposal, that has merit in addition to or in
> place of what has been proposed, please explain.  If there are problems
> or lack of clarity with what has been proposed, please explain.

I have made my proposals to the list.  The WG as a whole does not have
consensus on a conclusion or the relative merits of the concrete
proposals that have been made to the list.

> I very much fear that the only possible outcome of sky's-the-limit
> brainstorming is paralysis.  Please try and focus on actual proposals.

My original mail, trimmed in your response, did list actual proposals.
Some of them are probably easy to find flaws in, which is the sort of
response I was asking for.  Having a written record of what has been
proposed and how the various proposals compare on a technical basis is
very helpful when judging consensus.

> > I would love to hear others' thoughts on what I am missing from the above
> > lists, reasoning for/against including protocol elements to indicate
> > the listed semantics, and whether/which existing protocol elements already
> > convey which of the enumerated semantics.
> The proposal on the table is to a minimal form of time-limited commitment
> to the extension by mutual agreement between client and server, to address
> downgrade attacks via extension stripping by attackers with unauthorised
> WebPKI credentials.  This is need because while DNS lookups either deliver
> the relevant DNSSEC data or clearly fail, the extension is optional and
> failure to deliver it is a-priori not in any way anomalous.
> We're just trying to address that gap.  If you can make a strong case
> for addressing some additional gaps, or addressing this gap in a better
> way, please do.  Once again, I'm very concerned that the direction you're
> setting out on is counter-productive.

I, on the other hand, am very concerned that you are pushing for the WG
to publish a solution without proper discussion of its merits and
potential alternatives.  I am trying to help you frame such a discussion
and come to a consensus conclusion following IETF process, and you are
avoiding a technical discussion.  Continuing down your path is likely to
either cause the document to die or to revert to the previous consensus
"HTTPS" use case, leaving any particular pinning policy to be determined
outside this TLS extension, whether at the application protocol layer or
in the implementation.

If you believe that I, acting as Area Director, am attempting to abuse
process to stymie consensus work, you have various appeal and recall
options available.  I'm happy to chat further with you about those
options if you want.