Re: [DNSOP] draft-ietf-dnsop-svcb-https: HTTPS RRtype versus STS

Ralf Weber <dns@fl1ger.de> Mon, 26 October 2020 07:42 UTC

Return-Path: <dns@fl1ger.de>
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 82CBC3A19A8 for <dnsop@ietfa.amsl.com>; Mon, 26 Oct 2020 00:42:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 0zBCdLUSJOKl for <dnsop@ietfa.amsl.com>; Mon, 26 Oct 2020 00:42:02 -0700 (PDT)
Received: from smtp.guxx.net (nyx.guxx.net [85.10.208.173]) by ietfa.amsl.com (Postfix) with ESMTP id 190983A19C2 for <dnsop@ietf.org>; Mon, 26 Oct 2020 00:42:00 -0700 (PDT)
Received: by nyx.guxx.net (Postfix, from userid 107) id 427335F40095; Mon, 26 Oct 2020 07:41:59 +0000 (UTC)
Received: from [192.168.42.142] (p54b8a3a4.dip0.t-ipconnect.de [84.184.163.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by nyx.guxx.net (Postfix) with ESMTPSA id 7C7005F40095; Mon, 26 Oct 2020 07:41:58 +0000 (UTC)
From: "Ralf Weber" <dns@fl1ger.de>
To: "Paul Hoffman" <paul.hoffman@icann.org>
Cc: dnsop <dnsop@ietf.org>
Date: Mon, 26 Oct 2020 08:41:57 +0100
X-Mailer: MailMate (1.13.2r5673)
Message-ID: <8D63D4DF-9149-4415-A224-DB780467607A@fl1ger.de>
In-Reply-To: <47FDB7A6-4626-4C8C-8136-513D7648C059@icann.org>
References: <47FDB7A6-4626-4C8C-8136-513D7648C059@icann.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/255f1yGzlujft6DWrvnsZvRG8HQ>
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 07:42:05 -0000

Moin!

On 25 Oct 2020, at 21:21, Paul Hoffman wrote:

> See 
> <https://emilymstark.com/2020/10/24/strict-transport-security-vs-https-resource-records-the-showdown.html>. 
> Emily is a well-known developer on the security side of Chrome browser 
> development.
Upgrading the user to https is only one use case for the HTTPS resource 
record. In fact it is not the required behaviour as all of my HTTPS RR 
testing so far has been with http as I didn’t want to get certificates 
for the 10+ domains with different behaviour I created.  Works fine with 
the current clients (iOS 14/MacOS 11). It also solves the CNAME at the 
APEX problem and allows more options for transport before the initial 
setup of the connection.

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.

Just my .02 cents as a DNS guy ;-).

So long
-Ralf
——-
Ralf Weber