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

Shane Kerr <shane@time-travellers.org> Thu, 14 February 2019 10:03 UTC

Return-Path: <shane@time-travellers.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 4492B12D4E6 for <dnsop@ietfa.amsl.com>; Thu, 14 Feb 2019 02:03:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 q-FVq9b4mG41 for <dnsop@ietfa.amsl.com>; Thu, 14 Feb 2019 02:03:34 -0800 (PST)
Received: from time-travellers.org (c.time-travellers.nl.eu.org [IPv6:2a02:2770::21a:4aff:fea3:eeaa]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AABC512870E for <dnsop@ietf.org>; Thu, 14 Feb 2019 02:03:34 -0800 (PST)
Received: from [2001:470:78c8:2:6574:697d:933d:dea9] by time-travellers.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <shane@time-travellers.org>) id 1guDrh-0007SA-40 for dnsop@ietf.org; Thu, 14 Feb 2019 10:03:33 +0000
To: dnsop@ietf.org
References: <C5525DE2-DCF3-43E5-8C41-BAA58049DC3A@verisign.com> <edc1d393-ad19-2f8e-5f58-367d9b7e3290@nic.cz> <20190214080508.zab7r6hzkbj7kp54@nic.fr>
From: Shane Kerr <shane@time-travellers.org>
Message-ID: <3baf795c-46ff-3993-4cb1-fff10295bc0a@time-travellers.org>
Date: Thu, 14 Feb 2019 11:03:31 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <20190214080508.zab7r6hzkbj7kp54@nic.fr>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/GNmQI3zYT2Kbfthn4PBSFCSwwuA>
Subject: [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 10:03:36 -0000

Stephane,

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?".

An HTTP message always starts with some ASCII letters, like "GET" or 
"HEAD". In contrast, a DNS over TLS client will start with a message 
length encoded in 2 bytes. Since in practice queries will be less than 
256 bytes and therefore not start out with an ASCII letter (like 'G' or 
'H'). Actually this would require a client message of 16705 bytes to 
required that *both* the first two bytes are ASCII letters:

 >>> (ord('A') << 8) | ord('A')
16705

Since this is only required for the *first* DNS query on a TLS session, 
a client could always send a short query as the first one to avoid this 
issue. (I'm not sure how this would impact known-text analysis, but 
presumably TLS is resistant to this sort of cryptanalysis since HTTP 
almost always starts with the same few bytes.)

Even if the two-byte length results in ASCII letters, the client can 
sacrifice 1 bit of the message ID and ensure that it always has 
non-ASCII values, so the 3rd byte will always be non-ASCII and therefore 
not a valid HTTP command. So if it was really necessary to handle the 
case of queries of length 16705 or greater for the first query on a 
session, a client could always limit its message ID space to 32768 
possible values, which should be fine on a stateful connection where 
message ID is only used to match out-of-order answers.



I admit the issue of hand-off from a demultiplexer to a DNS server or 
HTTP server might be non-trivial, but in principle it should be possible.



Or is the issue to do with TLS itself? I don't know enough about SNI to 
know if there may be some reason why HTTP-based TLS could be different 
from DNS-based TLS, but I suppose it is possible. 🤔

Cheers,

--
Shane