Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps

mrex@sap.com (Martin Rex) Thu, 06 July 2017 20:32 UTC

Return-Path: <mrex@sap.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 ADACE12EC1E; Thu, 6 Jul 2017 13:32:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level:
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-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 oi6yI-s-76aQ; Thu, 6 Jul 2017 13:32:41 -0700 (PDT)
Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90BBB126DC2; Thu, 6 Jul 2017 13:32:41 -0700 (PDT)
Received: from mail07.wdf.sap.corp (mail04.sap.corp [194.39.131.56]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id 3x3TvC3hqHz25fP; Thu, 6 Jul 2017 22:32:39 +0200 (CEST)
X-purgate-ID: 152705::1499373159-00000810-56044B32/0/0
X-purgate-size: 2009
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate-type: clean
X-SAP-SPAM-Status: clean
Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail07.wdf.sap.corp (Postfix) with ESMTP id 3x3TvB1MtmzGnsf; Thu, 6 Jul 2017 22:32:38 +0200 (CEST)
Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 1F32D1A6C7; Thu, 6 Jul 2017 22:32:38 +0200 (CEST)
In-Reply-To: <901C29488D8446E4176CF83E@PSB>
To: John C Klensin <john-ietf@jck.com>
Date: Thu, 6 Jul 2017 22:32:38 +0200 (CEST)
CC: Mark Andrews <marka@isc.org>, "Roy T. Fielding" <fielding@gbiv.com>, dnsop <dnsop@ietf.org>, IETF Rinse Repeat <ietf@ietf.org>
Reply-To: mrex@sap.com
X-Mailer: ELM [version 2.4ME+ PL125 (25)]
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="US-ASCII"
Message-Id: <20170706203238.1F32D1A6C7@ld9781.wdf.sap.corp>
From: mrex@sap.com (Martin Rex)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/gzZkoEEv77M4z05SomjBJr9-A6s>
Subject: Re: [DNSOP] Minor editorial change to draft-ietf-dnsop-sutld-ps
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 06 Jul 2017 20:32:44 -0000

John C Klensin wrote:
> 
> --On Thursday, July 6, 2017 09:11 +1000 Mark Andrews
> <marka@isc.org>; wrote:
> 
>>...
>> And the actual presentation limit for LDH with DNS is 253
>> (encodes as 255 octets on the wire).  Remember URI names do
>> not have a final period and the each label has length octet
>> when encoded as a DNS name and the name is terminated by the
>> root label (0x00) in DNS wire form and the DNS wire name is
>> limited to 255 octets.
> 
> My apologies for nit-picking, but RFC 3986, Section 3.2.2 is
> quite clear than DNS names in URIs are permitted to have a final
> period and encouraged to do so under some circumstances.
> Specifically,
> 
> 	"The rightmost domain label of a fully qualified domain
> 	name in DNS may be followed by a single "." and should
> 	be if it is necessary to distinguish between the
> 	complete domain name and some local domain."


Also apologies from my side for nitpicking.

While I do believe that final periods on DNS names in URLs should work,
they still seem somewhat unusual, and there is a varing amount of breakage
around _matching_ DNS names with a final period to names without one
in various areas of communication protocols.

example: rfc2818 section 3.1 server endpoint identification
While _recent_ versions of Firefox & Chrome seem to no longer fail to
match them to TLS server certs, users of the blue stuff from Redmond
seem to be less lucky and still face cert hostname mismatch errors.

(but Google Chrome started delibertatly violating a MUST requirement from
 rfc2818 3.1 for certs without SANs, so name matching in Chrome _is_ broken,
 just differently broken).

There are other places where the DNS names from URLs will be placed,
e.g. TLS extension SNI client-side, TLS extension SNI server-side (virtual
hosts), HTTP Host: header fields, Cookies?, Same-origin-policies?

and I would not be surprised about more failures comparing DNS names
where one carries a final period.

-Martin