Re: [Add] questions about the Examples section of svcb-dns-02

David <opendak@shaw.ca> Thu, 08 April 2021 14:07 UTC

Return-Path: <opendak@shaw.ca>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40E9D3A18A1 for <add@ietfa.amsl.com>; Thu, 8 Apr 2021 07:07:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
X-Spam-Level:
X-Spam-Status: No, score=-2.12 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=shaw.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 SMM0i0m2LLVr for <add@ietfa.amsl.com>; Thu, 8 Apr 2021 07:07:39 -0700 (PDT)
Received: from smtp-out-no.shaw.ca (smtp-out-no.shaw.ca [64.59.134.12]) (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 2BB303A18D9 for <add@ietf.org>; Thu, 8 Apr 2021 07:07:38 -0700 (PDT)
Received: from [10.0.1.51] ([70.77.9.105]) by shaw.ca with ESMTPA id UVJolFDEMeHr9UVJpl9Vr7; Thu, 08 Apr 2021 08:07:38 -0600
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=shaw.ca; s=s20180605; t=1617890858; bh=cp9I1Sry8/MNKeGSQLG2X9WEYfAOaErwZkd8QdpQ0+0=; h=Subject:To:References:From:Date:In-Reply-To; b=WvyDagd4SNqSIWQJEub8wREPizwx8J9omEegFO/lySmeRl8bYUUHYhcp3/6KJwprN rXE+YLB5SQiqGZth71I9wedcaSE2RhOthxdzxLehxBXxQrm7/XYBEcT7h5h8OTU4YH CmvMoqAQ9Vrv6JQhY9ExL23n737LfmFYAgX5QfBtapoq9HLPXfdDSTvibXFLX3rluR Itl+NzZk96vXY5I1BE1D8I9V4QO0ZAvwlykCBn6Elq7XpEirCLF2zhCTpiBMijYq+V Jo4xvTG+ZbgcKxH1bNaAwsp2uUfrGnApjCikpFTgubv5KDPrON0ylvdZgXhvTHp9mV iCg000RZcJKsg==
X-Authority-Analysis: v=2.4 cv=Yq/K+6UX c=1 sm=1 tr=0 ts=606f0e2a a=VsD8yxyCjIJu8ocd7IiwMw==:117 a=VsD8yxyCjIJu8ocd7IiwMw==:17 a=IkcTkHD0fZMA:10 a=wh6levz1AAAA:20 a=VcF2PMagAAAA:8 a=48vgC7mUAAAA:8 a=Iai-90Vtg38CsrHnRCAA:9 a=QEXdDO2ut3YA:10 a=IytarbkFDjBbLqD58OCI:22 a=w1C3t2QeGrPiZgrLijVG:22
To: add@ietf.org
References: <4613b8d0773d1ae5f806347bbce909fa74439886.camel@powerdns.com> <CAHbrMsCM3pwu7zYVhVzCMKB37_gSMyb6KY3je3NVYQBAwt6kNg@mail.gmail.com> <dc371c7284d3c05d07cf0a550b37f9a624d968c9.camel@powerdns.com>
From: David <opendak@shaw.ca>
Message-ID: <ba952ca3-b6fe-be9a-8829-a926cb32e148@shaw.ca>
Date: Thu, 08 Apr 2021 08:07:36 -0600
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <dc371c7284d3c05d07cf0a550b37f9a624d968c9.camel@powerdns.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4xfKaqVO4MtxwJLhZWdwlvOK4DNbpMl9G7jyve+EE9aj16zWBktmfixpZ64yWagmajREmfGogjY/066S+jj4Gyl8JJMGguFwRAiN3Cvng5VOFarFqof0fX HJGDjy31EvDTAotz9GIh8oP6ECZTFn+zRqXR6tQRq5P/qfoUx/z3f3kY
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/2dzqHgjXAkqpZz5tVwpZGUQua1w>
Subject: Re: [Add] questions about the Examples section of svcb-dns-02
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Apr 2021 14:07:45 -0000

On 2021-04-08 1:38 a.m., Peter van Dijk wrote:
> Hi Ben,
> 
> thanks for that. Sadly, I still needed help from two other people to
> understand how DoT over 853 came out of this set. (One of them
> commented on your commit too.)
> 
> (For those reading along still confused, it's this bit:
> 
>          SVCB 1 @ alpn=h2,h3 dohpath=/dns-query{?dns}
> 
> Because it does not say 'no-default-alpn', it actually means
> 'alpn=dot,h2,h3' where the dot bit ignores the dohpath.)

As one of these people I will also echo this seems confusing and 
surprising. A casual observer of these records would need to carefully 
read and understand the draft to realize what it actually does, and 
apparently it took some of us a while to get to that. Having it be 
explicitly required or perhaps iterated more in examples would be good.

I will also point out this would also have DoT clients sending an alpn 
of 'dot' where I believe they do not today. Peter did some testing and 
sounds like that wouldn't really be an issue - but I haven't been 
following closely so not sure if this was brought up before.

> 
> I think this could be even more explicit in the draft (I'm happy to
> think about some words for that) but I really wonder if the space
> savings are worth the confusion at all.
> 
> On Wed, 2021-04-07 at 20:36 -0400, Ben Schwartz wrote:
>> Thanks for the questions!  I've adjusted the text [1] to make the examples clearer.
>>
>> DoT is the "default ALPN" in this draft, so unless it is explicitly removed (by no-default-alpn), it is present, and uses port 853 unless "port-..." is specified.  This is good for compactness but can be surprising, which is why I used that example.
>>
>> I removed the "echconfig" from the examples, as that is not the focus of this draft (and isn't even mentioned in the text).
>>
>> [1] https://github.com/bemasc/svcb-dns/commit/f61c70ed02b550613fdbb37d3171ab1e6d359e2c
>>
>> On Wed, Apr 7, 2021 at 4:32 PM Peter van Dijk <peter.van.dijk@powerdns.com> wrote:
>>> Hello Ben, and rest of WG,
>>>
>>> https://tools.ietf.org/html/draft-schwartz-svcb-dns-02#section-8 has an
>>> example RRset for a resolver, containing 3 SVCB RRs. This example is
>>> very useful!
>>>
>>> However, I have a few questions/comments about it:
>>>
>>> (1) Can you reorder the bullet list to match the order in the RRset?
>>> (i.e. put the TLS one second)
>>>
>>> (2) I see one SVCB record (with priority 2) advertising a DoT server
>>> (by leaving out the ALPN). It has port=8530. Yet, the text above says
>>> there's DoT on 853 and 8530. Where does 853 come into play, if the
>>> prio=2 SVCB record says port=8530?
>>>
>>> (3) All three example RRs have an echconfig parameter. While I
>>> understand it makes sense for an operator to be consistent in doing ECH
>>> over all their offerings, it somewhat looks like everybody is expected
>>> to do echconfig - perhaps it would be clearer to not have echconfig on
>>> all three? Then, maybe clarify that it would in fact be better to have
>>> it always, but say that the svcb-dns protocol does not demand it.
>>>
>>>
>>> For (2) it's entirely possible I'm missing something - please let me
>>> know. Thanks!
>>>
> 
> Kind regards,
>