Re: [TLS] TLS interim meeting material
Paul Wouters <paul@nohats.ca> Thu, 13 September 2018 00:56 UTC
Return-Path: <paul@nohats.ca>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539F4130EEB for <tls@ietfa.amsl.com>; Wed, 12 Sep 2018 17:56:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, TVD_PH_BODY_ACCOUNTS_PRE=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d6Y12Y-WSLf1 for <tls@ietfa.amsl.com>; Wed, 12 Sep 2018 17:56:11 -0700 (PDT)
Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6877130EE9 for <tls@ietf.org>; Wed, 12 Sep 2018 17:56:10 -0700 (PDT)
Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 429gFN6w6Jz7R0; Thu, 13 Sep 2018 02:56:08 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1536800169; bh=BlKobIzdCaAmWvpXRW7pQa9sc/raJVhfo6Q76ekdSXo=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=FtVa/AfB5zjUGkmzh/H87bHKilSplb4K1w7ks28D6Akkpcd24MvSD2B8tjuT52V6+ pYoIXwt4wjOYP5RItWY93vp5POpeW1OwH9mXCXQPBxnaNWz3ic6Aw09X7Gg6iAbV2l aFKVv9wAnI5NmspetggNYURDiR6m6Bp2vjKiEXXw=
X-Virus-Scanned: amavisd-new at mx.nohats.ca
Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id Y4J2f_HPAe1y; Thu, 13 Sep 2018 02:56:05 +0200 (CEST)
Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 13 Sep 2018 02:56:04 +0200 (CEST)
Received: by bofh.nohats.ca (Postfix, from userid 1000) id B3B5B3A3159; Wed, 12 Sep 2018 20:56:03 -0400 (EDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 bofh.nohats.ca B3B5B3A3159
Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id ABE4B412EC39; Wed, 12 Sep 2018 20:56:03 -0400 (EDT)
Date: Wed, 12 Sep 2018 20:56:03 -0400
From: Paul Wouters <paul@nohats.ca>
To: Richard Barnes <rlb@ipv.sx>
cc: "<tls@ietf.org>" <tls@ietf.org>
In-Reply-To: <CAL02cgTZ25jAPUkFYLMQWztz9OLstMHkQHFpJ8YLy5KEd39tOg@mail.gmail.com>
Message-ID: <alpine.LRH.2.21.1809122030200.7975@bofh.nohats.ca>
References: <alpine.LRH.2.21.1809121721300.5141@bofh.nohats.ca> <CAL02cgTZ25jAPUkFYLMQWztz9OLstMHkQHFpJ8YLy5KEd39tOg@mail.gmail.com>
User-Agent: Alpine 2.21 (LRH 202 2017-01-01)
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/VtmI34n2995_ZyfhOQPayn6SLtU>
Subject: Re: [TLS] TLS interim meeting material
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 13 Sep 2018 00:56:14 -0000
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. 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. 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". > 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, 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. 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
- [TLS] TLS interim meeting material Paul Wouters
- Re: [TLS] TLS interim meeting material Richard Barnes
- Re: [TLS] TLS interim meeting material Paul Wouters
- Re: [TLS] TLS interim meeting material Richard Barnes
- Re: [TLS] TLS interim meeting material Paul Wouters
- Re: [TLS] TLS interim meeting material Viktor Dukhovni
- Re: [TLS] TLS interim meeting material Richard Barnes
- Re: [TLS] TLS interim meeting material Viktor Dukhovni
- Re: [TLS] TLS interim meeting material Eric Rescorla
- Re: [TLS] TLS interim meeting material Salz, Rich
- Re: [TLS] TLS interim meeting material Viktor Dukhovni
- Re: [TLS] TLS interim meeting material Paul Wouters