Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-05.txt

"Wellington, Brian" <bwelling@akamai.com> Wed, 21 April 2021 16:44 UTC

Return-Path: <bwelling@akamai.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 B45933A2EBE; Wed, 21 Apr 2021 09:44:05 -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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=akamai.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 I6_v3G4sRFzI; Wed, 21 Apr 2021 09:44:00 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (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 C0C353A2EBC; Wed, 21 Apr 2021 09:44:00 -0700 (PDT)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.43/8.16.0.43) with SMTP id 13LGZPTD028030; Wed, 21 Apr 2021 17:43:59 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=jan2016.eng; bh=OXWMnJz2oLFKrEU9pa20KN9jmMgG3d4nDOLdZDNmM/U=; b=SG1eS7ChDlfimBlOPM6GouwOaYGHUFK/h653XnjKFwNctH+jMkO9kln/J/pFsC5SkRtx ddg8PDHJWHjitA/1lB3rRGta1pi7WGlSqRP19VI9Z8IvBQajap4+dmpE0vBq5AFiYb5C T6aSmBqhreP0xunjUDQgeuzjnU+1Vnp7bi4L/UuiyffE3ctcT1c73cxw3tNiT0jXqzhv HAkpeHPqev5tJriaN7kEWnrd1oMtADuPo3+JbCB/ipjBRo0aBbsyWfuGA9ZbCIafZJwQ M+CCR/E+CFiR5byl7OCfIHD9rqFVElj51aRJP3VeRq4qI5cNHJ1z5S4Q9cMT6QF0Qpte dA==
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19] (may be forged)) by m0050095.ppops.net-00190b01. with ESMTP id 3826ejkvcn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 21 Apr 2021 17:43:58 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.43/8.16.0.43) with SMTP id 13LGYus8012656; Wed, 21 Apr 2021 12:43:57 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.34]) by prod-mail-ppoint2.akamai.com with ESMTP id 382g9qgvm1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 21 Apr 2021 12:43:57 -0400
Received: from usma1ex-dag3mb4.msg.corp.akamai.com (172.27.123.56) by usma1ex-dag3mb4.msg.corp.akamai.com (172.27.123.56) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 21 Apr 2021 12:43:57 -0400
Received: from usma1ex-dag3mb4.msg.corp.akamai.com ([172.27.123.56]) by usma1ex-dag3mb4.msg.corp.akamai.com ([172.27.123.56]) with mapi id 15.00.1497.012; Wed, 21 Apr 2021 12:43:57 -0400
From: "Wellington, Brian" <bwelling@akamai.com>
To: Ben Schwartz <bemasc=40google.com@dmarc.ietf.org>
CC: dnsop <dnsop@ietf.org>
Thread-Topic: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-05.txt
Thread-Index: AQHXNrV21gzSSzkj5Ua8FziWi6xrT6q/RosAgAAqIgA=
Date: Wed, 21 Apr 2021 16:43:57 +0000
Message-ID: <87B615B4-9CA3-4060-93C2-E4B953C11FB2@akamai.com>
References: <161901308063.21005.875603362157576926@ietfa.amsl.com> <CAHbrMsA4TMfE+3LAT+un0FF3DGXKsYB1zAtvUwf2YKr97mJ+sQ@mail.gmail.com>
In-Reply-To: <CAHbrMsA4TMfE+3LAT+un0FF3DGXKsYB1zAtvUwf2YKr97mJ+sQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.94.169]
Content-Type: multipart/alternative; boundary="_000_87B615B49CA3406093C2E4B953C11FB2akamaicom_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-04-21_05:2021-04-21, 2021-04-21 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxscore=0 mlxlogscore=999 spamscore=0 malwarescore=0 suspectscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000 definitions=main-2104210120
X-Proofpoint-ORIG-GUID: jMpyyOQ7z4UKS4n8stDPXyGTGC9NpuWo
X-Proofpoint-GUID: jMpyyOQ7z4UKS4n8stDPXyGTGC9NpuWo
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.391, 18.0.761 definitions=2021-04-21_05:2021-04-21, 2021-04-21 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 priorityscore=1501 spamscore=0 bulkscore=0 impostorscore=0 phishscore=0 mlxlogscore=999 adultscore=0 clxscore=1011 mlxscore=0 malwarescore=0 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2104060000 definitions=main-2104210120
X-Agari-Authentication-Results: mx.akamai.com; spf=${SPFResult} (sender IP is 184.51.33.19) smtp.mailfrom=bwelling@akamai.com smtp.helo=prod-mail-ppoint2
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/DZKcP6tViymFl6axketzstO10i0>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-svcb-https-05.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: Wed, 21 Apr 2021 16:44:06 -0000

I’m not a fan of the new text in section 4.3:

Recursive resolvers MUST be able to convey SVCB records with unrecognized SvcParamKeys or malformed SvcParamValues.

It is perfectly reasonable for a recursive resolver to reject any malformed DNS record.  There’s a significant difference between “malformed” and “unknown”.  A recursive resolver should definitely allow records with unknown SvcParamKeys, but if the format of a record is known, a resolver should be allowed (encouraged, in fact) to check that it conforms to that format.

Brian


On Apr 21, 2021, at 7:13 AM, Ben Schwartz <bemasc=40google.com@dmarc.ietf.org<mailto:bemasc=40google.com@dmarc.ietf.org>> wrote:

Thanks for all the great input during WGLC.  Here's the changelog for the latest draft:

* Specify interaction with EDNS Client Subnet and Additional section caching
* Rename "echconfig" to "ech"
* Add a suite of test vectors (both valid and invalid) and more examples
* Clarify requirements for resolvers' (non-)use of SvcParams
* Clarify guidance regarding default ALPN values

On Wed, Apr 21, 2021 at 9:51 AM <internet-drafts@ietf.org<mailto:internet-drafts@ietf.org>> wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

        Title           : Service binding and parameter specification via the DNS (DNS SVCB and HTTPS RRs)
        Authors         : Ben Schwartz
                          Mike Bishop
                          Erik Nygren
        Filename        : draft-ietf-dnsop-svcb-https-05.txt
        Pages           : 56
        Date            : 2021-04-21

Abstract:
   This document specifies the "SVCB" and "HTTPS" DNS resource record
   (RR) types to facilitate the lookup of information needed to make
   connections to network services, such as for HTTPS origins.  SVCB
   records allow a service to be provided from multiple alternative
   endpoints, each with associated parameters (such as transport
   protocol configuration and keys for encrypting the TLS ClientHello).
   They also enable aliasing of apex domains, which is not possible with
   CNAME.  The HTTPS RR is a variation of SVCB for HTTPS and HTTP
   origins.  By providing more information to the client before it
   attempts to establish a connection, these records offer potential
   benefits to both performance and privacy.

   TO BE REMOVED: This document is being collaborated on in Github at:
   https://github.com/MikeBishop/dns-alt-svc
   (https://github.com/MikeBishop/dns-alt-svc).  The most recent working
   version of the document, open issues, etc. should all be available
   there.  The authors (gratefully) accept pull requests.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-svcb-https/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-dnsop-svcb-https-05.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-svcb-https-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org/>.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
DNSOP mailing list
DNSOP@ietf.org<mailto:DNSOP@ietf.org>
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org<mailto:DNSOP@ietf.org>
https://www.ietf.org/mailman/listinfo/dnsop