Re: [DNSOP] New Version Notification - draft-ietf-dnsop-svcb-https-06.txt

Mark Andrews <marka@isc.org> Mon, 05 July 2021 02:11 UTC

Return-Path: <marka@isc.org>
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 D6ED23A15F7; Sun, 4 Jul 2021 19:11:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, 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 (1024-bit key) header.d=isc.org header.b=ULFkhGnY; dkim=pass (1024-bit key) header.d=isc.org header.b=KWIOdNVI
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 eT_XETjQXxsZ; Sun, 4 Jul 2021 19:11:26 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (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 DB5053A15F9; Sun, 4 Jul 2021 19:11:26 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 17A663AB021; Mon, 5 Jul 2021 02:11:24 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1625451084; bh=xtxW6b+A+yP5LbWhFGiWG+rptVNDCOXiv5wZUJtaElY=; h=Subject:From:In-Reply-To:Date:Cc:References:To; b=ULFkhGnYTpHmNtcW3G9PMvprSkvL0xSINvzfDqyuus0qMsfz1RjhQGfOMw4nF3VkG tMkvbxDOndXDl0p4SVjZ3h3HtQh62XvS8zCfoqxm1hhl8+3zvObqAPsZcdHL35xmz3 A2jx+fHjPY1Jz9i3sWlyS8/jWHHbiU2XqFnNpJW0=
Received: from zmx1.isc.org (localhost.localdomain [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id DEC81160066; Mon, 5 Jul 2021 02:11:23 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 8F92B160067; Mon, 5 Jul 2021 02:11:23 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.9.2 zmx1.isc.org 8F92B160067
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1625451083; bh=GKhzVjQxN/s3zwWX2YGIx/m3uUMH8belVCOjKSOvzQw=; h=Content-Type:Mime-Version:Subject:From:Date: Content-Transfer-Encoding:Message-Id:To; b=KWIOdNVI7ETI9mVOLeRK2OrRaqEtZJjP0jaPkVEfwsQ+Xs+axGuzN3GsJybZwo4Pj cS5vq51vz+4XXg6D7sLvbderQu3JJ5yOd6Sz6pAUt9NXKWLOf7zl9mPBQV/IdGPszz qaEebv/05fM/RdsbPDwHi5Bayw2y2EhJDdOKENHM=
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7_QJ0wcPI4Be; Mon, 5 Jul 2021 02:11:23 +0000 (UTC)
Received: from smtpclient.apple (n49-177-132-25.bla3.nsw.optusnet.com.au [49.177.132.25]) by zmx1.isc.org (Postfix) with ESMTPSA id 637D1160066; Mon, 5 Jul 2021 02:11:22 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.100.0.2.22\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <CAKW6Ri6ueXvB9xAZTVPVg=dUVhQnXeOtGS7WHRViAdtEbotqzA@mail.gmail.com>
Date: Mon, 5 Jul 2021 12:11:20 +1000
Cc: dnsop <dnsop@ietf.org>, Tim Wicinski <tjw.ietf@gmail.com>, dnsop-chairs <dnsop-chairs@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <1FAD3E3B-0815-4A45-BA7B-5C390F75F70E@isc.org>
References: <162385376680.21187.3987569781956962248@ietfa.amsl.com> <CADyWQ+EuU4fe5WLAD7dRDhSfSgZfMWEk-jVW9z99x=cBKjd9uw@mail.gmail.com> <CAKW6Ri6ueXvB9xAZTVPVg=dUVhQnXeOtGS7WHRViAdtEbotqzA@mail.gmail.com>
To: Dick Franks <rwfranks@gmail.com>
X-Mailer: Apple Mail (2.3654.100.0.2.22)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/42iiPlaiL6L5IbgbsHzSvK_j7_8>
Subject: Re: [DNSOP] New Version Notification - draft-ietf-dnsop-svcb-https-06.txt
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, 05 Jul 2021 02:11:32 -0000


> On 2 Jul 2021, at 17:00, Dick Franks <rwfranks@gmail.com> wrote:
> 
> Feedback on SVCB draft 06 as requested.
> 
> On Mon, 28 Jun 2021 at 02:39, Tim Wicinski <tjw.ietf@gmail.com> wrote:
>> 8
>> 
>> The chairs would like the WG to review these changes, and give us some feedback.
> 
> 
> 6.1.  "alpn" and "no-default-alpn"
> 
>   The presentation "value" SHALL be a comma-separated list
>   (Appendix A.1) of one or more "alpn-id"s.  Zone file implementations
>   MAY disallow the "," and "\" characters instead of implementing the
>   "value-list" escaping procedure, relying on the opaque key format
>   (e.g. "key1=\002h2") in the event that these characters are needed.
> 
> If implementations MAY ignore the escape mechanism Appendix A.1 completely,
> there is little incentive to do otherwise.
> 
> However, implementations that do not exercise that option expose themselves
> to a litany of potential security weaknesses:

Not really, opaque form is easily recognised and has its own processing
rules. 

> These range from argument strings which produce corrupt content:
> 
>   example.com.   SVCB   1 example.com. ipv6hint="2001:db8:5c:5c5c::1"
> 
> not ok 29 - SVCB ipv6hint shrinkage
> #   Failed test 'SVCB ipv6hint shrinkage'
> #   at test.pl line 149.
> #          got: 'example.com.    IN    SVCB    ( \# 33 0001
> 076578616d706c6503636f6d00     ; example.com.
> #     0006 000e 20010db8005c0000000000000001 )'
> #     expected: 'example.com.    IN    SVCB    ( \# 35 0001
> 076578616d706c6503636f6d00     ; example.com.
> #     0006 0010 20010db8005c5c5c0000000000000001 )’

Opaque key form isn’t subject to double parsing despite the hint6 having
commas in the presentation form.  That’s about the only way you could be
seeing that difference.  The opaque key form knows nothing about the
internal structure, you don’t double parse opaque key form.  It’s 

	ipv6hint="2001:db8:5c:5c5c::1”

	or

	ipv6hint=2001:db8:5c:5c5c::1

	or

	key6=“ \001\012\139\000\\\\\\\000\000\000\000\000\000\000\001”

If you get keyXXXX or keyXXX=“value” you don’t do any second steps.

> to crafted RRs which silently subvert the parsing process in undesirable ways:
> 
>   example.com.   SVCB   1 example.com.
> ipv4hint="92.48.55.48,92.48.56.53,92.48.54.54,92.48.56.50"
> 
> not ok 30 - SVCB ipv4hint subversion
> #   Failed test 'SVCB ipv4hint subversion'
> #   at test.pl line 149.
> #          got: 'example.com.    IN    SVCB    ( \# 23 0001
> 076578616d706c6503636f6d00     ; example.com.
> #     0004 0004 46554252 )'
> #     expected: 'example.com.    IN    SVCB    ( \# 35 0001
> 076578616d706c6503636f6d00     ; example.com.
> #     0004 0010 5c3037305c3038355c3036365c303832 )'

Again opaque key form is just that. 

> D.3.  Failure cases
> 
> The following additional test vectors are listed below the
> corresponding requirement.
> 
> [9, para 1]
> In presentation format, the value is a [SINGLE] ECHConfigList encoded
> in Base64.
> 
>  example.com.  SVCB  1 foo.example.com. ech            ; missing argument
>  example.com.  SVCB  1 foo.example.com. ech=b25l,dHdv  ; multiple arguments
> 
> [6.2, para 2]
> The presentation "value" of the SvcParamValue is a [SINGLE] decimal
> integer between 0 and 65535 in ASCII.
> 
> Note: Character set cannot be specified here; it is whatever the
> platform or zone file uses (EBCDIC for example).
> 
>  example.com.  SVCB  1 foo.example.com. port=1234,4678 ; multiple arguments
> 
> [6.1, para 6]
> When "no-default-alpn" is specified in an RR, "alpn" must also be
> specified in order for the RR to be "self-consistent" (Section 2.4.3).
> 
>  example.com.  SVCB  1 foo.example.com. (
>                      no-default-alpn                   ; without expected alpn
>                      )
> 
> D.2.  Service form
> 
> The test vector for unsorted SvcParams would be better expressed using
> numerical keys and disentangled from extraneous clutter.
> 
>  example.com.  SVCB  1 foo.example.org. (              ; unsorted SvcParam keys
>                      key23609 key23600 mandatory=key23609,key23600
>                      )
> 
> --rwf
> 
> 
> 
>> 
>> ---------- Forwarded message ---------
>> From: <internet-drafts@ietf.org>
>> Date: Wed, Jun 16, 2021 at 10:29 AM
>> Subject: New Version Notification - draft-ietf-dnsop-svcb-https-06.txt
>> To: Tim Wicinski <tjw.ietf@gmail.com>
>> 
>> 
>> 
>> A new version (-06) has been submitted for draft-ietf-dnsop-svcb-https:
>> https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-06.txt
>> https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-06.html
>> 
>> 
>> The IETF datatracker page for this Internet-Draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/
>> 
>> Diff from previous version:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-svcb-https-06
>> 
>> IETF Secretariat.
>> 
>> 
>> _______________________________________________
>> DNSOP mailing list
>> DNSOP@ietf.org
>> https://www.ietf.org/mailman/listinfo/dnsop
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka@isc.org