Re: [TLS] TLS interim meeting material

Richard Barnes <> Wed, 12 September 2018 22:14 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 892B6130F5E for <>; Wed, 12 Sep 2018 15:14:13 -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 bat-ierFxw-G for <>; Wed, 12 Sep 2018 15:14:11 -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 00F08130F44 for <>; Wed, 12 Sep 2018 15:14:10 -0700 (PDT)
Received: by with SMTP id 8-v6so6978012oip.0 for <>; Wed, 12 Sep 2018 15:14:10 -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=IzgOaZeJOVLooUm04WomgJgW2ywNtBvIRarRyFgffF0=; b=TkyZzzbUGskXURVXkHDiVeboGfBzvT26fSWWPRl9m2qlnf05CEzSl4caWOMknWsL6m YNPUFFiEa3oBJ1Wox03ZbdqoY5fSCQqSpSAuq/6+VAMuXJhxd1g6ljWUrz+rUDH5lxP+ RGoEoyigcgpV3Xsc4v2Bc4g6K0UJOu7UwsdwNw7XEvhp77dts4QiC3CULgi9lKrgxR2v kpXv21LzWL1eLuaghPgyrSMa8iCC2PBNFvcygpIybyGI6p5GYgKz17VTDR8nlGLjv/MO d178+ZXJxQ/+bmQpJooGmrRpkv8kIW6LY3iuItIp8b7eX4Ah2OICOwOfUPy/bl47BBgX l9Kw==
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=IzgOaZeJOVLooUm04WomgJgW2ywNtBvIRarRyFgffF0=; b=hconjcn5d9fw2iL4htzZSl11ltU+gCWLfGRpCnU1XBzNk1dMAKlROjzqWj3pSleK2y QSfkT3tDKIlHg+iftcYe5OdAgvcrrAOC3agPnaqOxaiLO5yfRL0i0LiBYMFAV/J5Jtb0 deNI3em09/3Td1HkDFYaJs0OBoX2EmCQws56/lea5RbRIL+FwAW0gI/afAmJLStjugah QDZ4cVRvecnrMDBMMiVH9EKuoTdCHxLN3CiDrMvW/SplSa99iE6SpE5Xr6a8lfrHkosS uiZTMb+nb44aj3pG6YNaMGxtQD94F4y1/yMI6pfRQnojx9RIPe4mFJAHOq+zp6YpeNkp IRGA==
X-Gm-Message-State: APzg51COyr300ebjk7gbc8OKmkjPhxJNGQ1OKG2fSKbi8JmrpEFoAuS6 PmNJctYTgNuXqmgWHtGe38FOAhT4aj2d4GCv/Hjdyw==
X-Google-Smtp-Source: ANB0Vda5IDzbozvy886QWhdqB8dZl4Eupvtp45TualYJIrQggLr2NWPYAoPaoZkxIsVzFIQj7bl/+SzHr4Fmp7vyqCE=
X-Received: by 2002:aca:f189:: with SMTP id p131-v6mr4413172oih.14.1536790450061; Wed, 12 Sep 2018 15:14:10 -0700 (PDT)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Richard Barnes <>
Date: Wed, 12 Sep 2018 18:13:57 -0400
Message-ID: <>
To: Paul Wouters <>
Cc: "<>" <>
Content-Type: multipart/alternative; boundary="000000000000ded6df0575b3e81d"
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: Wed, 12 Sep 2018 22:14:21 -0000

I may have a conflict with the call, so I've gone ahead and put some
opinion inline below...

On Wed, Sep 12, 2018 at 5: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.

Speaking as one of the attendees, I do not agree with that conclusion.

What came to light in that meeting is that the assertive cases of DANE
require that the certificate verification in question use the provided cert
/ trust anchor.  That does not imply any semantic beyond a single TLS
connection; there is no inherent need for pinning.

Please stop using the phrase "downgrade attack".  It's deceptive.  It is
not a downgrade attack in the normal sense, i.e., an attack that causes a
TLS session between a legitimate client and a legitimate server to use
lower security (since the bogus server has to terminate the session).  The
"downgrade" here is simply that the client accepts a certificate from a
trust anchor it trusts.

> Nevertheless, we included the text we believe should go into the document.

Thank you for the explicit text, and thanks for mostly not using the word
"downgrade".  I agree that the first four paragraphs of the "Issues with
Incremental Deployment" accurately characterize the issue here.

I do not agree that we should include the SupportLifetime element.  TBH,
I'm kind of puzzled that it's in here.  It is no different from what has
been proposed in the past.  No attempt has been made to address the issues
that were raised by EKR, me, and others.  And there is clearly no consensus
for it.

It would be more productive for the group to consider a PR without that
addition, that is focused on clarifying that clients should not cache the
information they get in this way and clarifying the relationship between
this extension and record fetching via the DNS protocol.


> 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