Re: [DNSOP] Multiplexing DNS & HTTP over TLS (was: extension of DoH to authoritative servers)

Joe Abley <jabley@hopcount.ca> Thu, 14 February 2019 12:34 UTC

Return-Path: <jabley@hopcount.ca>
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 A74D2131160 for <dnsop@ietfa.amsl.com>; Thu, 14 Feb 2019 04:34:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
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 s_YGKh8hgAHZ for <dnsop@ietfa.amsl.com>; Thu, 14 Feb 2019 04:34:15 -0800 (PST)
Received: from mail-it1-x143.google.com (mail-it1-x143.google.com [IPv6:2607:f8b0:4864:20::143]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01ED0130F06 for <dnsop@ietf.org>; Thu, 14 Feb 2019 04:34:15 -0800 (PST)
Received: by mail-it1-x143.google.com with SMTP id i2so13919337ite.5 for <dnsop@ietf.org>; Thu, 14 Feb 2019 04:34:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OMz+IvzANWsVCaFb02BRXJHY9Ao6nBEHpf/qeIwrvIg=; b=CkCsSdNR6RqNUWBQsXGsO9XiNqOxDGYY99H3bnOJ4UVnL4VNizDyUom51IYUq8o+z0 VZSPHqWCRWjEpgyQlTCVgSvyZ5Ymjgi8pgmu2rXCUxKaiQBXOwBs97iOmIETD+InpbJG XEUva11lLKhi/t5N/tfXhVlpo5nGmcm/j4jGw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=OMz+IvzANWsVCaFb02BRXJHY9Ao6nBEHpf/qeIwrvIg=; b=TTx9UfEpgMGMZOb/egJabGR9znA1+laOzkHqNuNRTv972RbpH96PK83vREeKO533q0 eWuQmJHdHLOg+tUbzBwOkt2jyjM3zzuRKCDxpUrivUN0tOGTxf2hzyAZNbB2EYautjcL Pj2mB9H119XLoIzdzrRl/m7Olr+JQRjVV/iZ12P2R880E0Y6IxBG8t9EadaGv+CFxe2S FgojlOg9tZTCqGO6vUjv6O3TtFgjcTvSq6Xf7v6db3elSQox627f8x850fQr77TZBYrA 2Opx0CuwsgZdBkSBIAizj/2+WMCVDQzFrCP7HC4EwbQgahUF+6Rzi7z0kh66OpFsy1pU RvYw==
X-Gm-Message-State: AHQUAuYuSTW+rV+azP4+qC/ZMO8GmoRNgRGVYbSP7e/euDAcKtjcNV3e gRIDkg52pfka7EVXKB4HkaVNQMPJQDQ=
X-Google-Smtp-Source: AHgI3IYoggWq8aLooApdApiocTop4eNlwmwkeAYRfj7H5AElftc9yL0RBd2xsy+MR4iFy5HCq1WUJg==
X-Received: by 2002:a5e:9615:: with SMTP id a21mr1970553ioq.126.1550147653619; Thu, 14 Feb 2019 04:34:13 -0800 (PST)
Received: from ?IPv6:2607:f2c0:101:3:1925:fb8b:4a96:9b47? ([2607:f2c0:101:3:1925:fb8b:4a96:9b47]) by smtp.gmail.com with ESMTPSA id 70sm1076681ity.9.2019.02.14.04.34.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Feb 2019 04:34:12 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Joe Abley <jabley@hopcount.ca>
In-Reply-To: <3baf795c-46ff-3993-4cb1-fff10295bc0a@time-travellers.org>
Date: Thu, 14 Feb 2019 07:34:10 -0500
Cc: dnsop@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <619FF59C-F9DB-45EC-90E1-3AC1A8289592@hopcount.ca>
References: <C5525DE2-DCF3-43E5-8C41-BAA58049DC3A@verisign.com> <edc1d393-ad19-2f8e-5f58-367d9b7e3290@nic.cz> <20190214080508.zab7r6hzkbj7kp54@nic.fr> <3baf795c-46ff-3993-4cb1-fff10295bc0a@time-travellers.org>
To: Shane Kerr <shane@time-travellers.org>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Gh6mImj1s4nl72PdDNIFMbTD3KE>
Subject: Re: [DNSOP] Multiplexing DNS & HTTP over TLS (was: extension of DoH to authoritative servers)
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: Thu, 14 Feb 2019 12:34:18 -0000

On 14 Feb 2019, at 05:03, Shane Kerr <shane@time-travellers.org>; wrote:

> On 14/02/2019 09.05, Stephane Bortzmeyer wrote:
>> On Wed, Feb 13, 2019 at 10:51:00PM +0100,
>>  Vladimír Čunát <vladimir.cunat+ietf@nic.cz>; wrote
>>  a message of 118 lines which said:
>>> Technically you can run DoT on whatever port you like.
>>> Example: with knot-resolver it's easy - you just add @443, either on
>>> side of server and/or on the side of forwarding over TLS.
>> The problem is that you cannot then share this port with HTTPS
>> services (the dkg draft on demultiplexing was abandoned, apparently
>> because it doesn't work). In a world of scarce IPv4 public addresses,
>> this is a serious problem.
> 
> Interesting. I know that the multi-purpose usage smelled bad but I didn't know that it didn't work.
> 
> Is there a write-up on this?
> 
> Thinking about it naively, a demultiplexer really only needs to say "is there a non-ASCII character in the first 2 or 3 bytes of a TLS session?".

I think we can consider explicit payload identification an important feature of successful protocols. Encapsulating layers need to signal key information about the nature of their contents explicitly, or you wind up with the kind of nonsense that we saw in flow-hashing in MPLS where expected network behaviours depended on which transport protocol or address family you happen to be using way up the stack, and ugly hacks abound.

Your thought-algorithm above might be ok for discriminating between DoT and HTTPS (although I think anything that depends on a condition like "non-ASCII" is highly suspect :-) but what about other protocols, current and imagined future, that might use TLS as an encapsulating protocol, e.g. to address similar privacy concerns? This doesn't seem like a problem that is particularly theoretical.

Running whatever protocol I like on whatever port I like is fine so long as I am informed about the nature of the communication (e.g. I am involved in the decisions at both ends; I configure my ssh client and my ssh server both to use 53/tcp for my own special reasons so the use of that port is understood and doesn't need to be negotiated). In the DNS, one endpoint often has no prior knowledge of even the existence of the other endpoint. Asking one or both sides to make inferences about the nature of a session without explicit signalling does not seem robust.


Joe