Re: [DNSOP] draft-ietf-dnsop-svcb-https: HTTPS RRtype versus STS
Vittorio Bertola <vittorio.bertola@open-xchange.com> Mon, 26 October 2020 09:54 UTC
Return-Path: <vittorio.bertola@open-xchange.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8569E3A1A53 for <dnsop@ietfa.amsl.com>; Mon, 26 Oct 2020 02:54:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=open-xchange.com
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 g1n-3euWkW7E for <dnsop@ietfa.amsl.com>; Mon, 26 Oct 2020 02:54:31 -0700 (PDT)
Received: from mx3.open-xchange.com (alcatraz.open-xchange.com [87.191.39.187]) (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 0C1CF3A1A51 for <dnsop@ietf.org>; Mon, 26 Oct 2020 02:54:30 -0700 (PDT)
Received: from open-xchange.com (imap.open-xchange.com [10.20.30.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx3.open-xchange.com (Postfix) with ESMTPS id 017B96A266; Mon, 26 Oct 2020 10:54:29 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=open-xchange.com; s=201705; t=1603706069; bh=GA8lgd0700q34uAMXm2ZBQ02Q2hw/CpVXBOt2WkdCFo=; h=Date:From:To:Cc:In-Reply-To:References:Subject:From; b=RDh3/SsS/Dn69WvXVYwswZ11gzZSESVaO/zNx8G8Bpi7znKyXxLPFe8hj/JZGROwJ CxjmkyM6Xw2wVaydBamdzCDe9811627eUZxH3hw6x+MAulWr/Q5x2ZiLt17u0WpOrC PWPiO7aIKaQGB+fypdqwMn/GZfGKTh5GHW9hNYOmVrzr9av2/l0Ft4ndBt/bRrrDA9 b8SMQ5kDRdK+NhGspWw2i+oPqxA25yyo8qgfWoM4Vo+p0JmQYPkBRPgjY82Nvr5TZe 8Xyd4obslB8GiAT3wjLTkFAfEkX0gY8IKGusTmX4n/FU/xJXCQ8xeqakAC6T+Ty1LW Jca8+bQ5rYR3g==
Received: from appsuite-gw1.open-xchange.com (appsuite-gw1.open-xchange.com [10.20.28.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by open-xchange.com (Postfix) with ESMTPSA id E674B3C07B3; Mon, 26 Oct 2020 10:54:28 +0100 (CET)
Date: Mon, 26 Oct 2020 10:54:28 +0100
From: Vittorio Bertola <vittorio.bertola@open-xchange.com>
To: Ralf Weber <dns@fl1ger.de>, Paul Hoffman <paul.hoffman@icann.org>
Cc: dnsop <dnsop@ietf.org>
Message-ID: <1652407644.40055.1603706068841@appsuite-gw1.open-xchange.com>
In-Reply-To: <8D63D4DF-9149-4415-A224-DB780467607A@fl1ger.de>
References: <47FDB7A6-4626-4C8C-8136-513D7648C059@icann.org> <8D63D4DF-9149-4415-A224-DB780467607A@fl1ger.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
Importance: Normal
X-Mailer: Open-Xchange Mailer v7.10.4-Rev10
X-Originating-Client: open-xchange-appsuite
Autocrypt: addr=vittorio.bertola@open-xchange.com; prefer-encrypt=mutual; keydata= mQENBFhFR+UBCACfoywFKBRfzasiiR9/6dwY36eLePXcdScumDMR8qoXvRS55QYDjp5bs+yMq41qWV9 xp/cqryY9jnvHbeF3TsE5yEazpD1dleRbkpElUBpPwXqkrSP8uXO9KkS9KoX6gdml6M4L+F82WpqYC1 uTzOE6HPmhmQ4cGSgoia2jolxAhRpzoYN99/BwpvoZeTSLP5K6yPlMPYkMev/uZlAkMMhelli9IN6yA yxcC0AeHSnOAcNKUr13yXyMlTyi1cdMJ4sk88zIbefxwg3PAtYjkz3wgvP96cNVwAgSt4+j/ZuVaENP pgVuM512m051j9SlspWDHtzrci5pBKKFsibnTelrABEBAAG0NUJlcnRvbGEsIFZpdHRvcmlvIDx2aXR 0b3Jpby5iZXJ0b2xhQG9wZW4teGNoYW5nZS5jb20+iQFABBMBAgAqBAsJCAcGFQoJCAsCBRYCAwEAAp 4BAhsDBYkSzAMABQMAAAAABYJYRUflAAoJEIU2cHmzj8qNaG0H/ROY+suCP86hoN+9RIV66Ej8b3sb8 UgwFJOJMupZfeb9yTIJwE4VQT5lTt146CcJJ5jvxD6FZn1Htw9y4/45pPAF7xLE066jg3OqRvzeWRZ3 IDUfJJIiM5YGk1xWxDqppSwhnKcMOuI72iioWxX0nGQrWxpnWJsjt08IEEwuYucDkul1PHsrLJbTd58 fiMKLVwag+IE1SPHOwkPF6arZQZIfB5ThtOZV+36Jn8Hok9XfeXWBVyPkiWCQYVX39QsIbr0JNR9kQy 4g2ZFexOcTe8Jo12jPRL7V8OqStdDes3cje9lWFLnX05nrfLuE0l0JKWEg8akN+McFXc+oV68h7nu5A Q0EWEVH5QEIAIDKanNBe1uRfk8AjLirflZO291VNkOAeUu+dIhecGnZeQW6htlDinlYOnXhtsY1mK9W PUu+xshDq7lXn2G0LxldYwyJYZaJtDgIKqVqwxfA34Lj27oqPuXwcvGhdCgt0SW/YcalRdAi0/AzUCu 5GSaj2kaGUSnBYYUP4szGJXjaK2psP5toQSCtx2pfSXQ6MaqPK9Zzy+D5xc6VWQRp/iRImodAcPf8fg JJvRyJ8Jla3lKWyvBBzJDg6MOf6Fts78bJSt23X0uPp93g7GgbYkuRMnFI4RGoTVkxjD/HBEJ0CNg22 hoHJondhmKnZVrHEluFuSnW0wBEIYomcPSPB+cAEQEAAYkBMQQYAQIAGwUCWEVH5QIbDAQLCQgHBhUK CQgLAgUJEswDAAAKCRCFNnB5s4/KjdO8B/wNpvWtOpLdotR/Xh4fu08Fd63nnNfbIGIETWsVi0Sbr8i E5duuGaaWIcMmUvgKe/BM0Fpj9X01Zjm90uoPrlVVuQWrf+vFlbalUYVZr51gl5UyUFHk+iAZCAA0WB rsmACKvuV1P7GuiX3UV9b59T9taYJxN3dNFuftrEuvsqHimFtlekUjUwoCekTJdncFusBhwz2OrKhHr WWrEsXkfh0+pURWYAlKlTxvXuI7gAfHEQM+6OnrWvXYtlhd0M1sBPnCjbyG63Qws7Rek9bEWKtH6dA6 dmT2FQT+g1S9Mdf0WkPTQNX0x24dm8IoHuD3KYwX7Svx43Xa17aZnXqUjtj1
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/aJR8rMNB-iJmVa8RohFXb9G2xL8>
Subject: Re: [DNSOP] draft-ietf-dnsop-svcb-https: HTTPS RRtype versus STS
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 26 Oct 2020 09:54:33 -0000
> Il 26/10/2020 08:41 Ralf Weber <dns@fl1ger.de> ha scritto: > > I also think that any list hardcoded in browser/OS deployments is a bad > idea for a long term solution (that include auto upgrades of DoH servers > ;-) and it looks like STS has already shown that. DNS being an > distributed mechanism is far better suited as it does not require an > update of the end device. In fact, this "client-side hardcoded list vs TOFU discovery vs dynamic discovery via DNS" discussion - also addressed by the post - comes up quite often in a number of different places (HTTPS, DoH, DANE/MTA-STS...). I also think that dynamic discovery is better and is the only solution fully in line with the decentralized nature of the Internet, but I see the performance and security advantages of hardcoding some values that are known to be valid and stable (e.g., in the case of HTTPS, Google could do that for their own properties). Perhaps a general analysis and best practice document on this topic could be useful. -- Vittorio Bertola | Head of Policy & Innovation, Open-Xchange vittorio.bertola@open-xchange.com Office @ Via Treviso 12, 10144 Torino, Italy
- [DNSOP] draft-ietf-dnsop-svcb-https: HTTPS RRtype… Paul Hoffman
- Re: [DNSOP] draft-ietf-dnsop-svcb-https: HTTPS RR… Ralf Weber
- Re: [DNSOP] draft-ietf-dnsop-svcb-https: HTTPS RR… Vittorio Bertola