Re: [TLS] TLS interim meeting material

Richard Barnes <> Thu, 13 September 2018 02:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D470C130DCF for <>; Wed, 12 Sep 2018 19:40:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Status: No, score=-1.907 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, TVD_PH_BODY_ACCOUNTS_PRE=0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001] 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 Tcf_8EQwyM8D for <>; Wed, 12 Sep 2018 19:40:45 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A1761130F32 for <>; Wed, 12 Sep 2018 19:40:43 -0700 (PDT)
Received: by with SMTP id r69-v6so7873525oie.3 for <>; Wed, 12 Sep 2018 19:40:43 -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=HXAA5JBf9ebW6Ffz3AwJwLWHSh1XAs6ZTCAw0AE5NtU=; b=e6aFYm2WAy8MGxSaKC9tMMX9aFKTPwETlePBCgl//v7BNNpld8R2k5YtA3luqdZvxd /rfP0RgmQnSSNfJKTfORDPpVk30OA6R9cDpKk3euGW9qhFUKCEi8jYH5tM+HTU0ykGLu gWsDmXDVF1EalhqSVfZK5eas1thMf2UVaFJiUAKlu+9KXZZ/+ewwOudtKpkZuOGJBtfk HsNck7iGKb0qK0Kd+QV1WqbwEyruKLKL5fWdv66QKxUeRsJ9TnV26hqQxfSQZ2dZdQzW DfT8glyudqSTMbE/jn2ZzU7doaSxIBuPA4gJQYPk8YTYuI09rBE7/5HdIjlcgVe0sBh2 6AJA==
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=HXAA5JBf9ebW6Ffz3AwJwLWHSh1XAs6ZTCAw0AE5NtU=; b=NuaAXTZoEXhDY6Dy9zZPVJ36turmPhxZJ3rtyzgHSuO98WaQsdc8d7y9ojVTxCrbvu cTe3T+xM0z8YhNB7rODOLGWfAtR91uwExznVw9pV0CIew+8pK8YJZmAs4xe0K/qgk7zv dI3WEJa4hgRaK9izCIdsDvjPIJZ6LaqQYVWavN8/iWKDtkShHhso5wMWG2WRRSvOSrNG YcLo0+y7CusnV278ZdPz+lgnMqrhqyrbhZnzd4ViV5OFZYm4T2JaePzvyBgctLpElJU1 2Ko3PC8PxH0qSWovt2Q6hPlphk9Pcf8BYd+bMDTG2otmAWqQJGt6XskQ1MwCZtqXWSuS e20Q==
X-Gm-Message-State: APzg51AzYTDEpdZ1AsQ5VoQuiF/+uT0SDoV+FQ/xBHEoFjOKLAtF2Ooh wgXw1xE09P5KEWQuEyqDiy923jksCTvC5MR6R9oKhgavvls=
X-Google-Smtp-Source: ANB0VdaQFBx269wWZUoIvLDw3SgLnyv6z3IpdsBgiYoUY/L2p3pPpnO6gL8Wf/EgA+Sy+v0/Vb5idGo8RqXgEPH07Kg=
X-Received: by 2002:aca:f189:: with SMTP id p131-v6mr5301999oih.14.1536806442753; Wed, 12 Sep 2018 19:40:42 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Richard Barnes <>
Date: Wed, 12 Sep 2018 22:40:31 -0400
Message-ID: <>
To: Paul Wouters <>
Cc: "<>" <>
Content-Type: multipart/alternative; boundary="0000000000001bf2cf0575b7a20d"
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: Thu, 13 Sep 2018 02:40:50 -0000

Your responses here reveal a lot of the assumptions that you're reading in
here that are not actually true, e.g., those noted below.

On Wed, Sep 12, 2018 at 8:56 PM Paul Wouters <> wrote:

> On Wed, 12 Sep 2018, Richard Barnes wrote:
> > 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
> That is not what came to light. What came to light was that the
> assertive use case does not exist because all TLSA selectors restrict
> and that restriction is bypassed when you can force a client not to see
> it. Unfortunately, there is no recording and no minutes, so we will redo
> that discussion on Friday for the record.
> > 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.
> DNS records have semantics beyond a single connection.

DNS records have caching semantics.  Those are only relevant for DNS
resolution.  This is the TLS WG, not the DNS.

> You cannot tell
> whether the TLSA records were obtained via direct DNS queries or the TLS
> extension. So you can never make a decision based on purely requesting
> the exention and not getting the extension in an answer. The
> authoritative source is the DNS. This TLS extension is for those clients
> who cannot get native DNSSEC and/or want to reduce round trips. What you
> don't want is an attacker to be able to filter the TLS extension out,
> thereby removing the TLSA Usage Selectors that restrict the CA, the
> EEcert or the public key. That is a classic downgrade attack.
> > The "downgrade" here is simply that the client accepts a certificate
> from a trust anchor it trusts.
> A zone owner published a TLSA record.

A zone owner sent a TLSA record in a TLS handshake.  This document says
nothing about what is "published" through any other channel.

> They configure their TLS server to
> transport this information. It pins the certificate or root certificate.
> Someone managed to undo the TLS server extension. The added TLSA security
> is removed by the attacker, while the TLSA data remains active in the
> DNS zone. The zone owner's security has been downgraded to "as if no
> TLSA record was published". It removed the TLSA restrictions. It's a
> downgrade attack.
> > I do not agree that we should include the SupportLifetime element.  TBH,
> I'm kind of puzzled that it's in
> > here.
> Because I know of only 2 people objecting, and both people have not
> articulated their concerns beyond handwaving, claiming they explained it
> and refuse to point out where in the TLS list of TLS meeting minutes they
> conveyed this information. I don't know where to get this information so
> I cannot evaluate it. It would be helpful if you can provide it. Either
> a link to previous explanations or a newly written summary would work
> for me. What does not work is stating "it is kind of similar to HKPK
> and that didn't work, so this wont work either".

I don't seem to recall you having rebutted that point, though.

> > 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.
> Please provide a link to the "issues raised" by you or ekr or the others
> that convey why this simple two byte value won't do. Please refrain
> from comparision to other vaguely similar protocols and state clearly
> the problem with this suggested protocol change,

The similarity isn't vague; the problems are identical.  Let's look at the
Chrome intent to remove HPKP!msg/blink-dev/he9tr7p3rZ8/eNMwKPmUBAAJ?hn

They cite, for example:


There is a risk of rendering a site unusable.

There is a risk of hostile pinning, should an attacker obtain a misissued
certificate. While there are no confirmed or rumored cases of this having
happened, the risk is present even for sites that don’t use PKP.

Both of which are also problems with your pinning proposal.

> taking into account
> that the pinning is for the extension support, and not for pinning any
> data whatsoever as the live DNS is the only authoritative data for TLSA
> records. We added text that describes how to remove the extension
> pinning if you want to do that and describe clearly that you at any
> point in time without waiting on anyone or anything else, can remove the
> TLSA record from your DNS zone without breaking anything.
> > 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
> Any client that obtains DNS data with a valid TTL is allowed to cache
> and re-use it as long as the TTL allows it. Irrespective of whether this
> is part of TLS or Aviation Carriers.

The client may do that.  That doesn't mean the server is entitled to expect
the client to do that.  And if the server doesn't expect the client to
cache, then there's no downgrade at all.

> Therefore your statement that the
> client should not cache DNS data is fundamentally wrong and would go
> against normal operation of the DNS protocol.
> > and clarifying the
> > relationship between this extension and record fetching via the DNS
> protocol.
> I thought we clarified it? The TLS client works from its DNS cache. It
> can decide how to query for TLSA records. It can use regular DNS or this
> TLS extension. Or Tor. Or blockchain. When it receives the data and
> validates it, it can use the information and put the data in its cache
> for the remaining TTL time. For new TLS connections to the same origin,
> it can re-use the DNS data from cache and choose to omit the TLS
> extension completely while _still_ using TLSA record information to
> require a pinned CA or EE cert, thus protecting against a WebPKI
> compromise.
> Paul