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

Viktor Dukhovni <> Thu, 12 April 2018 18:45 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 858D212E042 for <>; Thu, 12 Apr 2018 11:45:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kH01MBgA-01q for <>; Thu, 12 Apr 2018 11:45:11 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 69D5212E8A9 for <>; Thu, 12 Apr 2018 11:45:04 -0700 (PDT)
Received: from [] ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id B14757A3309 for <>; Thu, 12 Apr 2018 18:45:03 +0000 (UTC) (envelope-from
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: Viktor Dukhovni <>
In-Reply-To: <>
Date: Thu, 12 Apr 2018 14:45:02 -0400
Content-Transfer-Encoding: 7bit
Reply-To: TLS WG <>
Message-Id: <>
References: <> <> <> <>
To: TLS WG <>
X-Mailer: Apple Mail (2.3445.6.18)
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: Thu, 12 Apr 2018 18:45:21 -0000

> On Apr 12, 2018, at 2:20 PM, Willem Toorop <> wrote:
> I notice that existing STS documents (HSTS [RFC6797] and MTA-STS
> [draft-ietf-uta-mta-sts]) are all one layer above TLS.  Is a STS TTL
> conveyed in a ServerHello message secure when it would be just for SSL?

The reason for that of course is that those "STS-flavours" are
commitments to do TLS vs plaintext, and so can't presume TLS as
a transport.  The question being settled is whether the peer does
TLS or not.

> I can see this might be different for the DANE use case because of the
> signed statements that come alongside the TTL, but for example...

Here the issue not whether TLS is supported, but whether the TLS
support includes support for this extension, and so TLS as a
transport is both natural and simultaneously supports all
relevant applications, rather than having to add per-application

> In case of built-in STS with the extension, what does a 0 TTL mean?
>  - When 0 has been the only value seen ever, it is clear to me that the
>    mechanism is equivalent with what we have in the draft now, but..

	Yes.  Don't pin, we're not promising ongoing support for the

>  - When another value has been seen before, is a value of 0 then enough
>    to clear the pin?  Or would a DoE proof (or insecurity proof)
>    alongside it be necessary?
>    In case of the latter, what does that mean for sites that do have
>    DANE records, but no servers that support the extension?  Can they
>    be hampered (for an indefinite period) by a MiTM?  That would be
>    really bad for DANE deployment.

	* Positive TTL values require TLSA records, denial of existence
          should not be able to set a positive value.

	* Once a positive TTL is in effect it can only be set back to 0
	  in one of two ways:

		1.  Along with TLSA records that authenticate the handshake.
                    (possibly limited to PKIX-EE/TA per application profile)

		2.  Along with DNSSEC-authenticated denial of existence of
                    said TLSA records or of zone security.

That is downgrades to not pinning require more than a mis-issued WebPKI
certs.  The domain should either prove non-existence of signed TLSA
RRs, or signal a 0 TTL along with valid TLSA RRs that match the cert

You can think of the above as an initial draft of the text for
option (C).