Re: [TLS] TLS interim meeting material

Richard Barnes <> Fri, 14 September 2018 15:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 11354130F18 for <>; Fri, 14 Sep 2018 08:19:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, T_DKIMWL_WL_MED=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id iPPtpl-bfLGc for <>; Fri, 14 Sep 2018 08:19:00 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D5267130F1F for <>; Fri, 14 Sep 2018 08:18:59 -0700 (PDT)
Received: by with SMTP id r69-v6so13170960oie.3 for <>; Fri, 14 Sep 2018 08:18:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Cmq0y4j1g2U16k+5os2/IQfurMA4boLwGjxrom6DzLI=; b=ViInwF34q3poKipWJ09J7NTxQPaHMBgd8uZYCqbnq6OaeFovZCJYRZIWpGJVpeh1pC FOJ0wg+EDq4WAre1YpOE2kKhZl9GAjB1ZiQxldhTtBgQsyREyGkqbT78Do4TsiBGyCvO 2x12+A6ZTPDQlIH85lvVbj2pK5fbVrj8D4evdl9QTSFdspx5n/w0kNM2e61V5k4vn8D7 hATAU6MuqjK093pczTeFPq93pQEuNlkM1tRR6Lpqr5OFCpQZrTndkEcuybkvucDl0UL8 iYDW2syyAG6TPGDVMM7Fod4WzUUhItVCwF5USnIZqM4hSMmJI83gpGRlfFcM9Xq+bqm4 W7sw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Cmq0y4j1g2U16k+5os2/IQfurMA4boLwGjxrom6DzLI=; b=ixd0SBNhtXrfdW1InmkJa51/7BikI2qYMm9tMYldDmd5QH7A+mx1MLXsm332DSPdOP xbIIxlhSGU1ic5cIHNmoJTTKDqURkQ1LOW5VIxazF/kdFJBzrheCPp3LFMkkwCUQxBBx ONqJCEUT0ZB6D1MAQEWvgg4VP57Hxci0uQTnYG9XiJJZlOVCL6GS/u9fwzJA0TY4exo2 fG+ACQKjOsD7koW5Iie7mbf2Juwls62BeryMkwSITKLXCNvSWDoUR8jGK0sgjQnRHw/F mAWaR8J3VpbHKKlNjYLpc8DkPgc/41y5y4WXvYNK2WOtSxhyGvxoJzaojD7YucPnYd1Z InQA==
X-Gm-Message-State: APzg51CsWxGx/0Txb85TCEi08yWkv/xXig9VRZWBlenVlzPZQITivZKY bdqbeIo848wWzXB49ywWSPY3i96oU0Wj43vZRGJ+Lj3CPtk=
X-Google-Smtp-Source: ANB0VdZc3heLVkiCHGerphels8r+dqIXEHSC1O5d1ZPOSclITdNUhHNPjbsj2hNAUBn2Y44ULiYnCxjKHHVqiMsIsIA=
X-Received: by 2002:aca:3e03:: with SMTP id l3-v6mr10566568oia.54.1536938338938; Fri, 14 Sep 2018 08:18:58 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Richard Barnes <>
Date: Fri, 14 Sep 2018 10:18:51 -0500
Message-ID: <>
To: Paul Wouters <>
Cc: "<>" <>
Content-Type: multipart/alternative; boundary="000000000000bc058f0575d6579c"
Archived-At: <>
Subject: Re: [TLS] TLS interim meeting material
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: Fri, 14 Sep 2018 15:19:15 -0000

One other bit of context here: DANE itself doesn't prevent these
"downgrade" attacks in its native form, to say nothing of TLS.

Recall that caching is optional for DNS clients, and the usage of DNSSEC
validation results is up to the application.

Suppose you had an application with the following logic when connecting to
a server:

- Attempt to fetch validated DANE records for the server
- If that succeeds, apply the DANE records on the connection. Do not cache
- If resolution fails, either because of a DNS failure or a validation
failure, fall back to the normal PKI

Such a client has the same security profile as a client using the current
DANE-TLS mechanism. And AFAICT, there is nothing in the current DANE spec
set that forbids this behavior.

The fault, dear Brutus, is not in the TLS transport, but in DANE itself.
Servers simply cannot expect that clients will persist DANE information.

Now, you could argue that we should do better in the TLS transport.  But
now you're in the realm of feature requests, not security vulnerabilities,
and feature gaps should not be blocking on a document that already had WG


On Wed, Sep 12, 2018 at 4:40 PM Paul Wouters <> wrote:

> Hi,
> We have made available what we believe is a good starting point for
> further discussion regarding tls-dnssec-chain draft.
> While I thought we had reached some additional consensus in a side
> meeting at IETF 102 that every use case was per definition restrictive,
> and that thus downgrade protection was mandatory for this document,
> not everyone then present still seems to agree with that.
> Nevertheless, we included the text we believe should go into the document.
> We can further discuss the preventing of downgrade attacks at the
> meeting if people have better ideas or _specific_ concerns about our
> current approach.
> Paul, Viktor and Nico
> Repository
> Diff Commits:
> The following changes were drafted
> * Mandatory Denial of Existence (DoE) or TLSA data (no empty extension
> data)
>    This prevents a downgrade attack and gives a method to "clear pinning")
> * Add two byte SupportLifetime to the extension and define the behaviour
>    of TLS client and TLS server with respect to this extension. This
>    prevents downgrade attacks.
> * Explain that receiving validated DoE data implies setting
> SupportLifetime to 0
>    (AKA it "clears the pin")
> * Describe how to phase out using the TLS extension without causing
> problems
> * Mandate use of SNI
> * Added port information to the extension_data to support TLS servers
>    behind NAPT that cannot determine the original port of the origin
>    based on the received packet.
> * Do not mandate DNS record ordering, it is complicated with CNAME/DNAME
>    (the reverse order would actually make more sense for implementors)
> * Describe behaviour when a TLS server receives an SNI it does not expect
>    (and has no extension data for)
> * Describe that TLS clients can obtain TLSA data directly from DNS or
>    via this extension and that TLS clients can omit the extension
>    completely if they have a non-expired cached TLSA RRset already.
> * Clarify TLS servers don't need to do DNS queries themselves, but can
>    depend on an external process to get fresh DNS data for populating
>    the extension.
> Still to do:
> * Describe the interaction of TLSA records with CNAME and DNAME as a
>    TLSA record can have a CNAME/DNAME at the beginning of the chain or
>    at the end. (RFC7671 CNAME chasing does not work well)
> * Provisioning TLSA chains with virtual hosting and cname constraints
>    (eg domain owner points to Hoster's webfarm via CNAME)
> _______________________________________________
> TLS mailing list