Re: UDP Ports and QUIC version

Christian Huitema <huitema@huitema.net> Wed, 24 November 2021 20:28 UTC

Return-Path: <huitema@huitema.net>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C2E83A0BE3 for <quic@ietfa.amsl.com>; Wed, 24 Nov 2021 12:28:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.742
X-Spam-Level:
X-Spam-Status: No, score=-3.742 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01] 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 iHMblUOdGUDs for <quic@ietfa.amsl.com>; Wed, 24 Nov 2021 12:28:41 -0800 (PST)
Received: from mx43-out1.antispamcloud.com (mx43-out1.antispamcloud.com [138.201.61.189]) (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 2FED83A0BE0 for <quic@ietf.org>; Wed, 24 Nov 2021 12:28:40 -0800 (PST)
Received: from xse432.mail2web.com ([66.113.197.178] helo=xse.mail2web.com) by mx133.antispamcloud.com with esmtp (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1mpysf-0003kM-0V for quic@ietf.org; Wed, 24 Nov 2021 21:28:37 +0100
Received: from xsmtp22.mail2web.com (unknown [10.100.68.61]) by xse.mail2web.com (Postfix) with ESMTPS id 4Hzsz81nc9zBTp for <quic@ietf.org>; Wed, 24 Nov 2021 12:28:36 -0800 (PST)
Received: from [10.5.2.16] (helo=xmail06.myhosting.com) by xsmtp22.mail2web.com with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.92) (envelope-from <huitema@huitema.net>) id 1mpyse-0004bb-3R for quic@ietf.org; Wed, 24 Nov 2021 12:28:36 -0800
Received: (qmail 9441 invoked from network); 24 Nov 2021 20:28:35 -0000
Received: from unknown (HELO [172.16.130.51]) (Authenticated-user:_huitema@huitema.net@[63.145.202.35]) (envelope-sender <huitema@huitema.net>) by xmail06.myhosting.com (qmail-ldap-1.03) with ESMTPA for <paul@redbarn.org>; 24 Nov 2021 20:28:35 -0000
Message-ID: <05e1ff85-d21a-d485-03f4-179be0feb528@huitema.net>
Date: Wed, 24 Nov 2021 12:28:38 -0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2
Subject: Re: UDP Ports and QUIC version
Content-Language: en-US
To: Paul Vixie <paul@redbarn.org>, IETF QUIC WG <quic@ietf.org>
References: <CAM4esxRqTdYYSw5EMkLXjnRdhsYOgW1BDjVHdxG01md5dkEwCw@mail.gmail.com> <20211124185823.GU6443@akamai.com> <07540fa9-92e3-1c13-2965-f884aca7c795@huitema.net> <c0cfff38-50b5-4f55-25f3-b308da74b04e@redbarn.org>
From: Christian Huitema <huitema@huitema.net>
In-Reply-To: <c0cfff38-50b5-4f55-25f3-b308da74b04e@redbarn.org>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: 66.113.197.178
X-Spampanel-Domain: xsmtpout.mail2web.com
X-Spampanel-Username: 66.113.197.0/24
Authentication-Results: antispamcloud.com; auth=pass smtp.auth=66.113.197.0/24@xsmtpout.mail2web.com
X-Spampanel-Outgoing-Class: unsure
X-Spampanel-Outgoing-Evidence: Combined (0.15)
X-Recommended-Action: accept
X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9WLQux0N3HQm8ltz8rnu+BPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5x6h2yQpzTslcOqazQkKtAFKj/EwzSHE5FGYwwjsNRPCPfW VLBP1X/avoGBgoa3P0XmD6wdmZPcItWbGe10hXJtXL4FsauCVkDjmcYJdU3yWp7KuHNaaKdg7iBE ZefdsNUFWKwa/wzJUjmazeC7Imca2UrctKjK/wYBF/0syiPRDxQ6V51u76v35b1wNe/MvdKAGdwU TZKlze5ERymXAD3v2+J9PgaoF8SQHto3le4zsHTaeQtlKubP6iUTjj6yPARK6buALVaA782LKxg6 vRmng8N1aLhXqdc+jC1RcnVud53D5caUhbVtvqItBqoizkEt9O20UjkwI0v+LOlw05G4BS+iyyNq bT8dUMXMJ4tUCMj6G37ZfAMLceP5aNHPt26RBupu5v1nytoNnc138GfEJRQ2qC7jjynPIHPNqSn4 QTXUjLjYWQt1/5xnQymMoPsgr/U0flMcy2Vi/IcBgY4arPaiJ1W6hAyiRC61jekdwIcXNugoOEbH RyFULpSjm7jZ1h/HfDRQ5Ig8VhPsPE8NaP2gA77cO7WeI9Ftai6fuhzgyPWGU2D2iHj1k6EV/5vy NS0N+QzI68Q+XvmpaJKKDRojSVizNl0ce/s7u0P9b7Oijoc3SCZfWp1RjkjWCw/vIUzTXkDAiiJi mGhLUFuS2lhaIetXfCg1JdAVrOwKfLlATAweG6k0xVqFzY7jwztUoFIvD3sIcP1fhJPM6B/8ug45 qSC6qtXLrV3ftg5D1+y7nIur/GqmAlwiSf6WD3iJ+dym1L8cD17Js0v4cp1MNkc9xpWY1kAb4PEH Jewj9TcKVNeVJ9BXyu9+ceCqThTYg2px1fSoqxQCCHnLMo/m9VKh99btUAanjnMCAH2co+fBoeG+ Hs0afhsY/5zhNYWRVYKU9W9tbmVXJBqdHHDmZEKhyNAv1N35kYWaEdgLurFV5oTvAcwA4rM3FkfW 8/1kE/e7sUnsVpINvARNxpFO
X-Report-Abuse-To: spam@quarantine11.antispamcloud.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/grSWjxROJv3Ue9aWJGp1E7k2YBI>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 24 Nov 2021 20:28:44 -0000

On 11/24/2021 12:17 PM, Paul Vixie wrote:
>
>
> Christian Huitema wrote on 2021-11-24 12:02:
>> ...
>>
>> Note that port 853 is a bit of a special case. TCP port 853 was first 
>> reserved for DNS over TLS. UDP port 853 was then reserved for DNS 
>> over DTLS, which was defined in an experimental RFC. Turns out that 
>> several years later we are not aware of any deployment of DNS over 
>> DTLS. So we believe that having UDP port 853 for DNS over QUIC and 
>> TCP port 853 for DNS over TLS would keep the nice symmetry that was 
>> originally intended. 
>
> who is "we"?
The DNS over QUIC draft authors. Sorry, I should have specified.
>
>> It would for example make management of firewalls easier, "port 853 
>> is encrypted DNS for both UDP and TCP". The downside would the case 
>> of servers trying to run both DNS over QUIC and DNS over DTLS. We 
>> don't know any such server, but it is nice to have a fallback 
>> mechanism in the unforeseen case of some server somewhere trying to 
>> do that. The ability of multiplexing QUIC and DTLS on the same port 
>> gives us that.
>
> i likewise think UDP/853 for both DoD and DoQ is fine.
>
> the reason for widespread lack of deployment of DoT (TCP/853) and DoD 
> (UDP/853) is simply because the TLS (middleware) supply chain does not 
> broadly know how to authenticate a server whose domain name is 
> unknown. that is, all DNS has at the time it wishes to transmit some 
> kinds of queries is an IP6/IP4 address. putting these into 
> presentation form and comparing the certificate's common name with 
> that converted string can be done, but the logic to do so is in the 
> TLS library not the DNS server. so, deployment of DoD (DTLS, UDP/853) 
> is "stuck" at the moment.

Yes. In theory, practical solutions must exist. In practice, we need 
practice...

-- Christian Huitema