Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]

Martin Thomson <martin.thomson@gmail.com> Thu, 04 May 2017 01:44 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: dns-privacy@ietfa.amsl.com
Delivered-To: dns-privacy@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C998D12785F for <dns-privacy@ietfa.amsl.com>; Wed, 3 May 2017 18:44:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 ZEJitFZUNLuj for <dns-privacy@ietfa.amsl.com>; Wed, 3 May 2017 18:44:30 -0700 (PDT)
Received: from mail-qk0-x22b.google.com (mail-qk0-x22b.google.com [IPv6:2607:f8b0:400d:c09::22b]) (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 A5C35129493 for <dns-privacy@ietf.org>; Wed, 3 May 2017 18:44:27 -0700 (PDT)
Received: by mail-qk0-x22b.google.com with SMTP id n4so210916qkc.0 for <dns-privacy@ietf.org>; Wed, 03 May 2017 18:44:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=LiG3HTApyk5sO53k1j0SBXynOvYFpC3LZbyr3HzJwDU=; b=iS20iQKjNrs27WZQi3VTNeM1ILcY6MXyUEKaMrXvSQYUIGieQc01oGz0OJKi/JRdYq InkNFQSuxTzV+9aJtBgdwGQQMpbNjHQFoUKELy+e0GIxKGDTGCp2ESIOQixjdkfu17+Z 7k1sNJZkHyYFNSHjtDxd8/T29mem3qE5nvJbRIqw5xGBNW1FDio1D5FrGTlnzkf7tQ5q GNjJAGueeFtmbwg3a4PfnmYXdFWg7faX5Z8aAMY5lE/b99gLi1Ds3Un4ZTwzwgR/sHeU /nldeGobPOsYHv/0H92loAzThq4zbvbJHxNaGopUAESuBwO0WKE7fsIWHwEyFi7OsF8q QEVw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=LiG3HTApyk5sO53k1j0SBXynOvYFpC3LZbyr3HzJwDU=; b=VqPq+3CR7AdLlgEc22VX3XOBMTaOCWoHxCzkTBG3vSgdxB/UAwWsuZddINDfrSjgZU RBdEX0XaiSyUSTRF5vgUff8JeGBSr0PcXrWI7IoRdKMUt5ctXN9xyZVodX503KTLaBS0 Jl0t31stN3FApiIyyVgFa5NhgKCAKxfDwrWArCojy6nMdgK6Xzo4VuzJ/Lrt4ailr9Wp oHfQ5sNiqzTArQVUKJezwBUFxTkjPTJC2kSpzjQNqYIoobtAjNy7OEA2WdyOPhQKoMiv ICzsySG8uCxzV0Xv1oGcEMIJFv/6gHvHLCscW8dMmX/TD+qaof/RSKyo9gttM3Fr1Rr/ sqHg==
X-Gm-Message-State: AODbwcAL+Ci5FhO5wQmms0qodYot8igbtCri/0odq/VTjwvNnCDZi06J D+JNhYVCgxw5YN0EmP+tBoi1vSOThg==
X-Received: by 10.55.146.68 with SMTP id u65mr803428qkd.77.1493862266855; Wed, 03 May 2017 18:44:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.168.137 with HTTP; Wed, 3 May 2017 18:44:22 -0700 (PDT)
In-Reply-To: <8737clqund.fsf@fifthhorseman.net>
References: <87tw51remp.fsf@fifthhorseman.net> <CAOdDvNoNPXNXzpVcX7TZX=Z++kWMBhG_+uDH3Vk1Jp8+adcHLQ@mail.gmail.com> <CAOdDvNruCCyB2rsF9VgaVEOjQGD82wA0AiLAghiGjDM0SpBFPQ@mail.gmail.com> <87lgqdr0fr.fsf@fifthhorseman.net> <BN6PR03MB27085632B5CBA7324894699487EA0@BN6PR03MB2708.namprd03.prod.outlook.com> <CABkgnnVLasxAfsezDp4H0cSOme5okHUY0ruG7EzgsNEW89SmDQ@mail.gmail.com> <87bmr9qwn7.fsf@fifthhorseman.net> <CABkgnnUgy+iD8R=WOBFb8bFWrtX=06unmiA5Ne3eEkt_KLcGxw@mail.gmail.com> <8737clqund.fsf@fifthhorseman.net>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 04 May 2017 11:44:22 +1000
Message-ID: <CABkgnnX4xjoCQcVEwGnkOd7zO8+cCG14GmHD6+4_vfr0_L9NsQ@mail.gmail.com>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Cc: Mike Bishop <Michael.Bishop@microsoft.com>, Patrick McManus <mcmanus@ducksong.com>, HTTP Working Group <ietf-http-wg@w3.org>, DNS Privacy Working Group <dns-privacy@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dns-privacy/ew94-pFK7mXIPJ8bSlgbk--pvNM>
Subject: Re: [dns-privacy] Demultiplexing HTTP and DNS on the same listener [New Version Notification for draft-dkg-dprive-demux-dns-http-02]
X-BeenThere: dns-privacy@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: <dns-privacy.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dns-privacy/>
List-Post: <mailto:dns-privacy@ietf.org>
List-Help: <mailto:dns-privacy-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dns-privacy>, <mailto:dns-privacy-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 May 2017 01:44:33 -0000

On 4 May 2017 at 11:26, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:
> hm, it sounds like that won't work for h2, given Patrick's point that h2
> isn't client-speaks-first.  Right?  If we tried to do something like
> "h2|dns", it seems like it would introduce a potential latency hit for
> any h2-specific client that proposed it, because the server couldn't
> send its first frame unsolicited.  I know you can't speak for Mozilla,
> but would you imagine firefox opting into this for normal http/2
> connections?

Patrick owns that decision and could tell you.

The cost would be on the DNS-enabled client, who would have to detect
and ignore any h2 preface from a server for that protocol.

> For http/1.x, the draft is arguing that using an ALPN label is
> unnecessary -- so if that's right, what would we gain from a new ALPN
> label over using the existing HTTP/1.1 mechanism (i.e., either no ALPN
> or the ALPN token "http/1.1")?

Upthread we see several reasons why that argument might not be valid.

> It looks to me like the new ALPN label introduces costs:
>
>  * implementations on both server and client need to specify it
>
>  * client implementations need to verify that it was chosen, and fail if
>    not

I would have thought that these are benefits.

>  * network monitors can see that it was offered and discriminate against
>    the offerer at least (TLS 1.3), and in some cases the established
>    connections (TLS 1.2 and earlier).

A lot depends on the population size.  If this were enabled in a
sizeable chunk of the browser market, then the TLS 1.3 option goes
away.  Note that you only create the full exposure if you decide to
implement this at a server without also implementing TLS 1.3.

> What are the benefits of introducing a new ALPN label for demuxing
> HTTP/1.1 from DNS?

Certainty, primarily.  A clear signal that both peers agree to use the
same protocol.  It might also reduce ossification effects, but I
haven't gamed that out.