Re: [TLS] DNS-based Encrypted SNI

Ilari Liusvaara <ilariliusvaara@welho.com> Wed, 04 July 2018 04:34 UTC

Return-Path: <ilariliusvaara@welho.com>
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 48149130E3E for <tls@ietfa.amsl.com>; Tue, 3 Jul 2018 21:34:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
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 lNs-cGm_jISe for <tls@ietfa.amsl.com>; Tue, 3 Jul 2018 21:34:19 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B3CE126CB6 for <tls@ietf.org>; Tue, 3 Jul 2018 21:34:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 8C0DA4F8B8 for <tls@ietf.org>; Wed, 4 Jul 2018 07:34:17 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id 4S3a80jGC--Z for <tls@ietf.org>; Wed, 4 Jul 2018 07:34:17 +0300 (EEST)
Received: from LK-Perkele-VII (87-92-19-27.bb.dnainternet.fi [87.92.19.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 1ADC772 for <tls@ietf.org>; Wed, 4 Jul 2018 07:34:15 +0300 (EEST)
Date: Wed, 04 Jul 2018 07:32:49 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: "tls@ietf.org" <tls@ietf.org>
Message-ID: <20180704043249.GA10665@LK-Perkele-VII>
References: <CABcZeBMR=5QQjSS68H2mQoyG1cHVa5+Z_5SH0Md07kTBVSr3Sw@mail.gmail.com> <alpine.LRH.2.21.1807022343380.3445@bofh.nohats.ca> <BN6PR14MB11065355B19B16FEDCEDF28083420@BN6PR14MB1106.namprd14.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <BN6PR14MB11065355B19B16FEDCEDF28083420@BN6PR14MB1106.namprd14.prod.outlook.com>
User-Agent: Mutt/1.10.0 (2018-05-17)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/xFK4LTC5RIp-ItDtGhyPTEgjaBM>
Subject: Re: [TLS] DNS-based Encrypted SNI
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.26
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: Wed, 04 Jul 2018 04:34:23 -0000

On Tue, Jul 03, 2018 at 07:50:00PM +0000, Tim Hollebeek wrote:
> One of the things we found out with CAA is that this extremely optimistic view
> of the support for unknown RR types by large hosting providers is not 
> accurate.

As context, problems with CAA were not limited to various DNS hosters
not supporting it or DNS recursives choking on it, but also things like:

1) Broken replies from _authoritative_ nameservers for CAA queries.
2) Timeouts from _authoritative_ nameservers for CAA queries.
3) Broken DNSSEC proofs for empty record sets.

The most worrisome here is the 2). Even with good DNS recursive, you
would still take timeouts.


There are quite a bit of CAA-related problem reports on Let's Encrypt
forums. Those are almost never of incorrect CAA records and rarely
questions on how to add CAA, but generally problems caused by some
authoritative nameserver being broken and causing CAA lookups to
fail or return bogus answers.


-Ilari