Re: [dnsext] [Errata Held for Document Update] RFC4343 (6361)

Kaspar Etter <me@kasparetter.com> Mon, 04 January 2021 21:26 UTC

Return-Path: <me@kasparetter.com>
X-Original-To: dnsext@ietfa.amsl.com
Delivered-To: dnsext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A60CB3A1106; Mon, 4 Jan 2021 13:26:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.019
X-Spam-Level:
X-Spam-Status: No, score=-0.019 tagged_above=-999 required=5 tests=[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
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 poTxxiSkoQya; Mon, 4 Jan 2021 13:26:18 -0800 (PST)
Received: from relay3-d.mail.gandi.net (relay3-d.mail.gandi.net [217.70.183.195]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6DC123A1104; Mon, 4 Jan 2021 13:26:17 -0800 (PST)
X-Originating-IP: 51.154.104.215
Received: from [192.168.1.4] (unknown [51.154.104.215]) (Authenticated sender: me@kasparetter.com) by relay3-d.mail.gandi.net (Postfix) with ESMTPSA id 30A8660005; Mon, 4 Jan 2021 21:26:12 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.4\))
From: Kaspar Etter <me@kasparetter.com>
In-Reply-To: <24563.26991.309998.571334@gro.dd.org>
Date: Mon, 04 Jan 2021 22:26:10 +0100
Cc: Eastlake III Donald-LDE008 <Donald.Eastlake@motorola.com>, "Eric Vyncke (evyncke)" <evyncke@cisco.com>, iesg@ietf.org, dnsext@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <EEBC7569-CC6C-48FA-AD71-4C47C1F8F87E@kasparetter.com>
References: <20210104134129.E9403F40721@rfc-editor.org> <24563.26991.309998.571334@gro.dd.org>
To: Dave Lawrence <tale@dd.org>
X-Mailer: Apple Mail (2.3608.120.23.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsext/GmhtHzMVL2ZKyMeDYb8v1WfaSsA>
Subject: Re: [dnsext] [Errata Held for Document Update] RFC4343 (6361)
X-BeenThere: dnsext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Extensions working group discussion list <dnsext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsext>, <mailto:dnsext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsext/>
List-Post: <mailto:dnsext@ietf.org>
List-Help: <mailto:dnsext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsext>, <mailto:dnsext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Jan 2021 21:26:20 -0000

Thank you for proposing an improved wording. As the author of the errata, I have to say that the addition of “on input octets” would not have helped me. The statement in the errata system is correct: My “errata” was simply a “request for clarification” and not a “request for correction”.

The following response from Evan Hunt was really helpful for me:

> This has been ambiguous for a long time.  If you check the authoritative
> servers for ietf.org, the answer section is capitalized as specified in
> the zone database, not matching the question:
> 
>   $ dig +noall +answer @ns1.ams1.afilias-nst.info. IETF.org
>   ietf.org.		1800	IN	A	4.31.198.44
> 
> However, some servers use case-insensitive name compression in their
> responses. Differently-capitalized versions of the same name are treated as
> duplicates, so if IETF.org appears in the question section, the answer
> section will refer back to that.  In my view, this behavior is incorrect,
> but it's commonplace.

I agree that the single sentence likely doesn’t give enough context for the person who will update this RFC in the future. If I have to propose a concrete change, I would go for the following:

Old:
No "case conversion" or "case folding" is done during such output operations, thus "preserving" case.
However, to optimize output, indirect labels may be used to point to names elsewhere in the DNS answer.

New:
No "case conversion" or "case folding" is done during such output operations, thus "preserving” the case of the domain name as it is stored in the database of the authoritative name server.
However, to optimize output, indirect labels may be used to point to names elsewhere in the DNS answer, typically from the answer section to the question section.

I think my confusion comes from the fact that the current situation is not really satisfying in my opinion. What’s the point of output (and thus also input) case preservation in theory if you rarely get case preservation in practice? I see the following options to improve the situation:
1. Just say that an authoritative name server can store and return domain names in any capitalization it likes instead of indicating that the case should be preserved.
2. Discourage name servers (with a “SHOULD NOT”?) from pointing from the answer section to the question section of the DNS response so that the capitalization of the DNS answer can actually be used to display the domain name to the user as the owner of the domain name intended it.
3. Preserve “name compression” and case by encouraging name servers to point from the question section to the answer section instead of the other way around. If this is not possible, simply use the capitalization of the answer section in the question section so that name compression remains the same. As far as I can tell, the RFC doesn’t say anything about whether the question section has to preserve the case of the DNS query, which is probably also something that should be addressed in a future iteration of this RFC.
4. Encourage domain names to be stored, queried, and returned in lowercase to make the behavior of ASCII domain names more similar to the behavior of IDNA2008 domain names. (Assuming that IDNs increase in importance over time, I see little reason to treat the subset of ASCII domain names differently in the long term.) Encouraging that domain names are displayed in lowercase might also be desirable in the context of mitigating homograph attacks.

I understand that this debate is beyond the scope of this errata but given the comment by Evan Hunt I have the impression that other people share my dissatisfaction with the current situation. Therefore, it might make sense to have (or revisit?) this debate in the future and then supersede RFC 4343 accordingly (instead of just changing the wording in Section 4.1.).

Best regards,
Kaspar


> On 4 Jan 2021, at 20:15, Dave Lawrence <tale@dd.org> wrote:
> 
> RFC Errata System writes:
>> After discussion with the RFC author and the errata author, the
>> conclusion is that the RFC isn't wrong but is arguably unclear for
>> some readers. 
> 
> Agreed that it could be a little confusing when focusing on that one
> sentence, despite the surrounding paragraphs trying to fill the
> context.  Was there new proposed text?  Is this sufficient, given the
> surrounding text?
> 
> Old:  No "case conversion" or "case folding" is done
>      during such output operations, thus "preserving" case.  
> 
> New:  No "case conversion" or "case folding" is done on input octets
>      during such output operations, thus "preserving" case.