Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension

Sam Hartman <> Fri, 13 April 2018 15:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 78EF4126D73 for <>; Fri, 13 Apr 2018 08:26:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.253
X-Spam-Status: No, score=-0.253 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_DYNAMIC=0.982, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ut1BpWLUYHt0 for <>; Fri, 13 Apr 2018 08:26:42 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0A2BB126D0C for <>; Fri, 13 Apr 2018 08:26:38 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7B08C29E74 for <>; Fri, 13 Apr 2018 11:26:37 -0400 (EDT)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8TPWs4TyhTss for <>; Fri, 13 Apr 2018 11:26:37 -0400 (EDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "laptop", Issuer "laptop" (not verified)) (Authenticated sender: hartmans-laptop) by (Postfix) with ESMTPSA for <>; Fri, 13 Apr 2018 11:26:37 -0400 (EDT)
Received: by (Postfix, from userid 8042) id A9D2EC6062; Fri, 13 Apr 2018 11:26:35 -0400 (EDT)
From: Sam Hartman <>
Date: Fri, 13 Apr 2018 11:26:35 -0400
Message-ID: <>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: <>
Subject: Re: [TLS] Consensus Call on draft-ietf-tls-dnssec-chain-extension
X-Mailman-Version: 2.1.22
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: Fri, 13 Apr 2018 15:26:43 -0000

I realize I'm not following the TLS working group.  I was asked to
review this issue by someone who was confused and hurt by the current
process and was asking for a less involved opinion.  Since I took the
trouble to review the document, to review a good chunk of the current
list discussion, I decided to share my opinions.  I understand that I'm
coming at this late.  There are both advantages and disadvantages to

I will answer the questions, but I ask you to please focus more on my
analysis of the proposed change than my answers to the question.  I
don't think I have anything special to bring to the answers to the
questions other than the opinion of someone who is trying as hard as
they can to inform themselves.
I do think an outsider's evaluation of some of the assumptions and
implications of the change may help others make up their mind.

1) Do you support publication in its current form?

I thought I was going to have to quibble about the question and say that
while I supported bringing the document back to the WG I wouldn't go so
far as to   say I didn't support publication.

However, reading the discussion, there are key statements related to the
scope of this document that based on current discussion don't seem to
have consensus now even though they mmay have had consensus in the past:

* The scope discussion in the introduction, particularly pointing out
  that this document is applicable to web browsers and SIP seems very
  much under debate in the current discussion.

* Section 8 states that using this extension in a TOFU manner would be a
  reasonable thing to do.  I think that absent a mechanism to limit the
  scope of pinning or to securly move away from this extension that
  claim is harmful to interoperability and ultimately security.

So, even if all we do is remove that text in the introduction and remove
the TOFU claim, I think a change is worth the cost.

2) Do you support denial-of-existence proofs and TTL for pinning?

Yes, I think this work would be valuable; here's why.

First I'd like to explain my understanding of the assumptions under
which this change is valuable.

You don't need this change if you have reliable client configuration.
Reliable client configuration  can come in an application where this extension is mandated.  That
is, you know all your code supports this extension and you know you're
being deployed with TLSA records signed up to a trust anchor that the
client supports.  So say you're only deployed on the public DNS in
signed zones.
Alternatively reliable client configuration could come in a list of
sites that are known to support this extension that is centrally

Without that reliable configuration, you won't be able to rely on this
extension to improve security for first contact.  That's true with or
without the proposed changes.

With the proposed changes you could implement TOFU semantics in a manner
that I and the proponents believe is operationally viable.
I think that will provide enhanced security under the following

* Clients talk to server more than once

* There is sufficient value in protecting second and follow-on sessions
  that mittigation is valuable even though we'll never protect the first

* We trust the DNS root more than our X.509 PKI, or at least we gain
  enhanced security by validating against both

* Clients are willing to pin security information--namely that a given
  server uses this extension

* We're talking about an application where we cannot mandate use of this
  extension.  Remember that you need to mandate not only code support
  that people actually deploy only with signed dnssec zones and TLSA
  records before you
  can mandate the extension.  

I think those assumptions are common enough that it is worth fixing the

That said, I'd like to disagree with Victor on one point.  I think for
any change there is nontrivial work to be done to get it right and there
is a potential downside.  His cost analysis seems to imply that there's
no chance we'll make things worse with the change and that the only cost
is delay.  In my discussions, I quickly came across a number of issues
surrounding how the proposed changes would interact with private DNS
that were more complex than the person asking me to review implied.
Victor may have considered all those issues, but I think there is a cost
to the change.
I think it is worth paying, but I'd urge people to be a bit more
realistic about the potential cost of making a mistake or making it more
likely people will reduce interoperability by complicating the spec.

In conclusion, in ranked order, I prefer:

1) Working on Victor's changes

2) Removing the scope text and TOFU language

3) the current spec

4) no spec ever on this topic