[DNSOP] draft-ietf-dnsop-svcb-httpssvc-01 feedback
Eric Orth <ericorth@google.com> Fri, 06 December 2019 22:44 UTC
Return-Path: <ericorth@google.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 E95D212080F for <dnsop@ietfa.amsl.com>; Fri, 6 Dec 2019 14:44:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.001
X-Spam-Level:
X-Spam-Status: No, score=-17.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, PDS_BTC_ID=0.499, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 TMeHZD1iOvfk for <dnsop@ietfa.amsl.com>; Fri, 6 Dec 2019 14:44:10 -0800 (PST)
Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2E0D120114 for <dnsop@ietf.org>; Fri, 6 Dec 2019 14:44:09 -0800 (PST)
Received: by mail-wr1-x435.google.com with SMTP id c14so9445559wrn.7 for <dnsop@ietf.org>; Fri, 06 Dec 2019 14:44:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=DoDsADJ5nVDTOCcgB3+bLcUusnv70Z18JTlVWKSN5UI=; b=nwaUtFFmMtQyeufZIntwtwMKFkGMB/qSS2Vrr99pRfdgoPPL+0ZwHY5mQNRO0x5XpL KbdAoV61/XdRtnwu5yF+Pc1SQV5bP7WiGzRJj30RATiIk2sw98lrzNuelo+lTRO0T9ze qsEfYTzd6W97wKjs8b/beYNBD1IS057dkrPhn2XkjNhFbgI4f4PVhjSXAttXHXzmzkfA Q/Hih/muW3hJRbD5iE1WFNfRDzfb0+YIx+epj/EExYeMRzAdL8swt7gG8JJjqOeZE13n j6kdMGrjFL30a7rtNUex2QZxnaUpSOo4Ovbxi7YWD+33q0Hjj9pQPkHlzcC3Dvso54iK 1dUg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=DoDsADJ5nVDTOCcgB3+bLcUusnv70Z18JTlVWKSN5UI=; b=E0MSA7unTM72QtmJIaVC8mtCn23PR+TOd4AEdr46swixTy0PHl/XTHKXuVIdaRvjj9 7X4Wc+hHb10EV9s/INDGUGmAPGNkYRVaG/ghXE00BWbp23g9rDhyh195y14dmzeWUJ+s sBtzxbcdLnRDwGUVFt3LpolsEVcLO3GdD7sDloFEeMuaxm70AkqYMZ4qJ66753zgK/3X mJdYdf/e42Yxf25Vg+NZEptkwIU7LBlOVyXRJHLAIaWnCpXg0SISRdeun66erkGLXskZ /FzyN2Guoi3aKZH3cAyo0JBDt2ZUzDn38KUp+wA38OKhI41Ni6pFwF8iKP7UQ9d4/67A /Hbg==
X-Gm-Message-State: APjAAAVm7TxDUqUjDFb0DHLE+MoK9Dhm9Jw+m1tfsmojpRMw9xaZP/J/ l7pA1mB9Z0v/2dKvWrpgWvdoSB2x2KOJxZmFCOyBguJL
X-Google-Smtp-Source: APXvYqxgSmI68QLCHzT2NlUBJpwqZ5K9S1zbyfK3lzssT4Rgm/G40vGaBqLk/FpdBxc78PZyxbrwSmBSddfgomi5oss=
X-Received: by 2002:a5d:548e:: with SMTP id h14mr19280269wrv.380.1575672247403; Fri, 06 Dec 2019 14:44:07 -0800 (PST)
MIME-Version: 1.0
From: Eric Orth <ericorth@google.com>
Date: Fri, 06 Dec 2019 17:43:56 -0500
Message-ID: <CAMOjQcGP3=+_fb9pt3dvF27kR1ENH+=2L28EDNPQU6JF8zkrzQ@mail.gmail.com>
To: dnsop <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000097238f059910c841"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/eAyMNJkPMLYrQ--ItMTM9wV94kg>
Subject: [DNSOP] draft-ietf-dnsop-svcb-httpssvc-01 feedback
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: Fri, 06 Dec 2019 22:44:15 -0000
Been reviewing the latest draft with a bunch of relevant experts within the Chrome team. As has been stated in previous emails and in WG sessions, we generally like the HTTPSSVC approach and are very interested in trying out an implementation. Some specific feedback: - The name: I still hate the name “HTTPSSVC” because I have trouble saying it. Please paint the bikeshed a different color. - Section 1.3: Compared to previous drafts, not much value anymore in SvcFieldPriority being a first-class field outside SvcFieldValue. Client will need to fully parse SvcFieldValue to decide the real priority (to prefer ESNI and discount unsupported protocols, etc). Although I will admit that it is elegant that multiple aliases get treated as multiple 0-priority records in that one is randomly picked and non aliases get ignored. - Section 2.5: We see no valid reason to support an alias chain 8 nodes long. Such a case is likely only configuration error, and following the full chain would subject our users to bad performance that the configurer is not likely to notice and fix. Therefore, unless somebody comes up with a good reason that longer chains need to be supported, we intend to only follow 1 or 2 links before giving up on following the chain further, and the spec should be updated to say that such chains should be limited as such. I hear not everybody in the stack can reasonably enforce this limit, so maybe state that longer chains are not valid, should not be created, and clients/resolvers that can enforce limits should use the value specced here for that enforcement. I think it would also be helpful for this section to clarify the expected behavior on detection of a loop or too-long chain: Fail entirely, use the non-SVCB fallback addresses, or use the furthest-down-the-chain service records found if such records are mixed with alias records? - Section 4: Very much “yes, please” on including the recursive results in Additional to prevent additional queries. We are very sensitive to unnecessary latency in DNS. - Section 6.1: We have some concerns with the use of ALPN values to specify this. This is complicated enough that we will start a separate email thread soon to discuss this point. - Section 7: States that HTTPSSVC is only used for http and https schemes. But Chrome also deals with other schemes with implied http URLs, like websockets. There should be clarification text that HTTPSSVC is also used for these schemes, with wss:// queried as if it were https:// and ws:// queried as if it were http://. We consider it important for HSTS and HSTS-like behavior such as HTTPSSVC existence to also apply to the related ws:// URL. - Section 7.4: I believe this is saying the correct thing with a strict reading (that http://example.com:80 becomes HTTPSSVC(example.com)), but I think some more clarity would be helpful. The text of “specify port 443” and such may make it sound like you’re constructing the HTTPSSVC query URL including specifying 443 (HTTPSSVC(_443._https.example.com)), but from section 7.1, the port is obviously not supposed to be specified. Maybe some extra clarity that these rules are for constructing the actual redirect URL (not the query URL) and that that URL then gets encoded into an HTTPSSVC query via the rules of section 7.1. Also, this section seems slightly inconsistent with section 7.1 in that 7.1 states HTTPSSVC is used for http and https, but in actuality, HTTPSSVC is only used for querying https and section 7.4 shows how to create an appropriate https URL to query when you’re starting from an http URL. Also, I think this section should clarify that any HTTPSSVC result, including alias form, is sufficient for the client to read it as a signal to upgrade to HTTPS. Otherwise there may be some confusion over whether or not only service form records are sufficient. Also, this section states that connection should be abandoned on SERVFAIL because it might be a DNSSEC error. But I think the spec should clarify that the client may continue if it has reason to believe the error was not caused by DNSSEC validation (e.g. because of an EDE specifying that the error was something else). - Section 8.1: We’re very sensitive to any situation where it’s too easy to accidentally configure DNS to disable QUIC -> TCP fallback. Some of our users are behind networks where QUIC cannot get through. If the HTTPSSVC records with esiconfig are h3, section 8.1 imples we cannot try TCP because that would lose ESNI. Ideally this would be treated as a misconfiguration somehow. Failing that, perhaps the ESNI fallback rules should be left open to client policy.
- Re: [DNSOP] SVCB chain lengths Vladimír Čunát
- [DNSOP] draft-ietf-dnsop-svcb-httpssvc-01 feedback Eric Orth
- Re: [DNSOP] draft-ietf-dnsop-svcb-httpssvc-01 fee… Brian Dickson
- Re: [DNSOP] draft-ietf-dnsop-svcb-httpssvc-01 fee… Patrick McManus
- [DNSOP] SVCB chain lengths Ben Schwartz
- Re: [DNSOP] SVCB chain lengths Patrick McManus
- Re: [DNSOP] SVCB chain lengths Brian Dickson
- Re: [DNSOP] draft-ietf-dnsop-svcb-httpssvc-01 fee… Vladimír Čunát
- Re: [DNSOP] SVCB chain lengths Eric Orth
- Re: [DNSOP] SVCB chain lengths Brian Dickson
- Re: [DNSOP] SVCB chain lengths Paul Vixie
- Re: [DNSOP] SVCB chain lengths Masataka Ohta
- Re: [DNSOP] SVCB chain lengths Eric Orth
- Re: [DNSOP] SVCB chain lengths Eric Orth
- Re: [DNSOP] SVCB chain lengths Brian Dickson
- Re: [DNSOP] SVCB chain lengths Brian Dickson
- Re: [DNSOP] SVCB chain lengths Brian Dickson
- Re: [DNSOP] SVCB chain lengths John Levine
- Re: [DNSOP] SVCB chain lengths Paul Vixie