[dnsoverhttp] Comments on draft-hoffman-01

Ben Schwartz <bemasc@google.com> Wed, 01 February 2017 23:25 UTC

Return-Path: <bemasc@google.com>
X-Original-To: dnsoverhttp@ietfa.amsl.com
Delivered-To: dnsoverhttp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26F181295E7 for <dnsoverhttp@ietfa.amsl.com>; Wed, 1 Feb 2017 15:25:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.899
X-Spam-Level:
X-Spam-Status: No, score=-5.899 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, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.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 iJ3GxavVSR9l for <dnsoverhttp@ietfa.amsl.com>; Wed, 1 Feb 2017 15:25:54 -0800 (PST)
Received: from mail-io0-x231.google.com (mail-io0-x231.google.com [IPv6:2607:f8b0:4001:c06::231]) (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 A9C8512959A for <dnsoverhttp@ietf.org>; Wed, 1 Feb 2017 15:25:54 -0800 (PST)
Received: by mail-io0-x231.google.com with SMTP id v96so73141802ioi.0 for <dnsoverhttp@ietf.org>; Wed, 01 Feb 2017 15:25:54 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=+eUNehDxD0PJo612lnsDU061jf+V4t9g1YD2zTT8LkA=; b=b4Gak8Beasceub5UADrzxacupL5+n9LpZ2+SV8WKhJ0yCfGcT0eJCQxJrIQ6Yph49i UoAlgbeSrfG9drVAx68rsoOlWoiyYDgl7qpuHLwzP8u63QmGxn/Sj78DfcORAN2KwQwO 7R8Abe3Wm3jzYU8sEdMKyd6T3LzmHbJNQwO5PyQ2UdArZLSaedM0R9w1vHJyTy6Nz+rD Zf4p4cUu4v4HYzaH0q7KPQAsK3p9XDdA9yuIt59pb890D6fjr0AChLxC/pmauDFl4g8r SM9FXezpO5L9jLCn3TiloF5Ztd6TtKECK2A4/OXgQ+reZun3osVyGtoXmC3+1wV4ujrc rWDg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=+eUNehDxD0PJo612lnsDU061jf+V4t9g1YD2zTT8LkA=; b=i1BtGQ1Qc7hRsp/GN2yUDg5CWbmRVZcqguqVQkwQFkYY4PFlttSGR71Mk6lf28xffO KurUW6O0DK/anPDTRMPGvj5oGNYFEUZd9KDpvgNxEh3VNEmLW6lpDjknUJyIvbmGiurF 5xY/CgdN2Q6HbfkXigXx3e5HWbkm1Oa3koa2vFkibfZfzjS38u71r799T3tYk9dv/v73 Tupu05rQ1YtaSMHBkTnhPm3MKufy2B6m1k/73nVgD6lILix7tOLBgKdJyEZhnS/IRzT3 520g6lKtLF9YjyqP2AXsohc8ksVxcVfeLlloiMbmrs+bXtww4Da96WF52iGb1bPO0sOg 12qQ==
X-Gm-Message-State: AIkVDXJc1GXnK/LZDcckx8nZExhRxGKyQb1XT/vOJ3Bl3Ma0ErpGAZJ7UZHiBmkqE9+RYpTwIPX94Yp1x+N88Ebb
X-Received: by 10.107.15.70 with SMTP id x67mr4050330ioi.103.1485991553654; Wed, 01 Feb 2017 15:25:53 -0800 (PST)
MIME-Version: 1.0
Received: by 10.107.135.164 with HTTP; Wed, 1 Feb 2017 15:25:53 -0800 (PST)
From: Ben Schwartz <bemasc@google.com>
Date: Wed, 01 Feb 2017 18:25:53 -0500
Message-ID: <CAHbrMsD6R5vrkRwhNW9RhW4Adv+JELWYAiDevMPY-+Jn2JgW8Q@mail.gmail.com>
To: dnsoverhttp@ietf.org
Content-Type: multipart/alternative; boundary="001a113ed7feb259340547805e90"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsoverhttp/L7zzcm9qxR2bSCcaX_ZVWVSzZMI>
Subject: [dnsoverhttp] Comments on draft-hoffman-01
X-BeenThere: dnsoverhttp@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Discussion of DNS over HTTP <dnsoverhttp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsoverhttp>, <mailto:dnsoverhttp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsoverhttp/>
List-Post: <mailto:dnsoverhttp@ietf.org>
List-Help: <mailto:dnsoverhttp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsoverhttp>, <mailto:dnsoverhttp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Feb 2017 23:25:56 -0000

I've been taking a close look at this DNS over HTTP draft.  I like it a
lot, but I could use some clarification on some finer points:

1. What values must the server accept for each of these parameter values,
and what may the client send?  I think it would help to very tightly limit
the allowed parameter values (e.g. no leading zeros), but allow the server
to optionally accept a broader range of values.  That way, server
implementations can use whatever parsing functions they happen to have on
hand.

2. What is the meaning of the pad field: is it a string of bytes, or a
number of bytes?  What's the purpose of the padding option?  What if the
HTTP connection is encrypted, but the DNS over HTTP server performs
resolution that is not encrypted?  What does the maximum UDP payload size
have to do with HTTP?

3. What should the server do if parameters are duplicated?  Just choose the
first instance?

4. What is at the given path in .well-known?  Is it a static file
containing the prefix?  Is that path actually the prefix?  Could it be
both?  What is the client's intended TLS behavior when knowing only an IP
address: should it send an SNI?  Should it verify the certificate or
consider the encryption opportunistic?  (Can we adopt DNS-over-TLS's
security profiles?)

--Ben