Re: [Doh] re original_transport indicator

"Hewitt, Rory" <rhewitt@akamai.com> Thu, 05 April 2018 20:56 UTC

Return-Path: <rhewitt@akamai.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CECC12D7E8; Thu, 5 Apr 2018 13:56:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 GPqWcJo5qgzq; Thu, 5 Apr 2018 13:56:51 -0700 (PDT)
Received: from mx0b-00190b01.pphosted.com (mx0b-00190b01.pphosted.com [IPv6:2620:100:9005:57f::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 C1E2A12D7E4; Thu, 5 Apr 2018 13:56:51 -0700 (PDT)
Received: from pps.filterd (m0050096.ppops.net [127.0.0.1]) by m0050096.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w35Kqcc4001289; Thu, 5 Apr 2018 21:56:42 +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=a0ZKYv5l0tD4/+ekm3GYFmrqU0zx6HGfB/kkggMuMbo=; b=kULKCi0dB/ehXICCogm4VgxvDx27olXsUwvdkhvTGjWI8FfwxteT+8yL4kVDecnDP+fU aXPa++TiCfkb6DqF9FN2QqoXWTzv7QC3GzF/nmzUvIuxSF3+WWbwvQX1t9b/+AaVVrsF Cm/a/sgY2wxvBtguh37MXSz0KdAbLHSgA+/zktgeg71xIFaMIthzS+WseG9eTV2wVuM+ MJ3ZmgzSVuOanEjzC/gIGarzVWc8S3KboXbShMXi1ASTtpnnlmEz3yBklKq1PPero+Wj uiRhfh1yD4+HBV1boL3OpThd3I4dopReJNmHDm20Sc7/g+auE3hRlA1C0RR0Fc1SDpfj Ww==
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by m0050096.ppops.net-00190b01. with ESMTP id 2h4n5g5apc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 05 Apr 2018 21:56:42 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w35KpRhl001932; Thu, 5 Apr 2018 16:56:41 -0400
Received: from email.msg.corp.akamai.com ([172.27.123.32]) by prod-mail-ppoint2.akamai.com with ESMTP id 2h25nvcbhx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 05 Apr 2018 16:56:41 -0400
Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com (172.27.123.103) by usma1ex-dag1mb2.msg.corp.akamai.com (172.27.123.102) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 5 Apr 2018 16:56:41 -0400
Received: from USMA1EX-DAG1MB3.msg.corp.akamai.com ([172.27.123.103]) by usma1ex-dag1mb3.msg.corp.akamai.com ([172.27.123.103]) with mapi id 15.00.1365.000; Thu, 5 Apr 2018 16:56:40 -0400
From: "Hewitt, Rory" <rhewitt@akamai.com>
To: Patrick McManus <pmcmanus@mozilla.com>, Martin Thomson <martin.thomson@gmail.com>
CC: Ted Lemon <mellon@fugue.com>, dnsop <dnsop@ietf.org>, DoH WG <doh@ietf.org>, Paul Vixie <paul@redbarn.org>, Ray Bellis <ray@bellis.me.uk>
Thread-Topic: [Doh] re original_transport indicator
Thread-Index: AQHTzSA/Hoab/GGFzky8kAfRAazUvaPypqMA
Date: Thu, 5 Apr 2018 20:56:40 +0000
Message-ID: <fb8387b410234828950a837590aad426@usma1ex-dag1mb3.msg.corp.akamai.com>
References: <CAOdDvNrO0bbSdRn8dzWiFzMx4Wc33yAh0C6SWg+DR4b4XTEmHg@mail.gmail.com>
In-Reply-To: <CAOdDvNrO0bbSdRn8dzWiFzMx4Wc33yAh0C6SWg+DR4b4XTEmHg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.113.9]
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_017B_01D3CCE5.EB3A9B20"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-05_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804050211
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-04-05_09:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1804050211
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/pjIsFtE7uOXzpeeeq9-3U53JHes>
Subject: Re: [Doh] re original_transport indicator
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Apr 2018 20:56:54 -0000

Good idea - future-proofing is great in theory, but it sounds like there's a 
lot of non-consensus on the DNSOP side that we might end up adding something 
that is superseded anyway.



Rory



From: Patrick McManus [mailto:pmcmanus@mozilla.com]
Sent: Thursday, April 5, 2018 1:54 PM
To: Martin Thomson <martin.thomson@gmail.com>;
Cc: Ted Lemon <mellon@fugue.com>;; dnsop <dnsop@ietf.org>;; DoH WG 
<doh@ietf.org>;; Paul Vixie <paul@redbarn.org>;; Ray Bellis <ray@bellis.me.uk>;
Subject: [Doh] re original_transport indicator



Hi All,



We've had quite a thread re the -05 optional parameter to the 
dns-udpwireformat registration.



The parameter is defined as having no meaning for DoH, but was included to 
accommodate a use case the dnsop wg is considering. Future proofing, if you 
like.



Upon consideration (and a read of 6838), I think including this in doh is 
premature because Media Type registrations can be updated by mechanisms laid 
out in RFC6838 and in this case such an update could occur without impacting 
existing DoH deployments. (i.e. it does not need to be future proofed).



Therefore the definition of the parameter should accompany the work that makes 
use of it if a future standards document chooses to go down that path. As a 
bonus we avoid unused clutter if it doesn't happen. I also get the feeling 
that there isn't yet strong consensus on the anticipated use case or the exact 
form it needs to take - we should let that process work itself out separately 
before registration.



I've chatted with Paul, and our recommendation is to remove the 
original_transport parameter from DoH and encourage dnsop to update the 
registration if/when a different standard needs to make use of it.



thoughts?



-Patrick