[secdir] Secdir review of draft-ietf-doh-dns-over-https

Magnus Nyström <magnusn@gmail.com> Tue, 14 August 2018 06:42 UTC

Return-Path: <magnusn@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 5D96C126CB6; Mon, 13 Aug 2018 23:42:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 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_NONE=-0.0001, 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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id dUCwjb-9N_JX; Mon, 13 Aug 2018 23:42:26 -0700 (PDT)
Received: from mail-pf1-x436.google.com (mail-pf1-x436.google.com [IPv6:2607:f8b0:4864:20::436]) (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 C3D9712D7F8; Mon, 13 Aug 2018 23:42:26 -0700 (PDT)
Received: by mail-pf1-x436.google.com with SMTP id p12-v6so8842060pfh.2; Mon, 13 Aug 2018 23:42:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=C6YEIeCv6ovv0s93UVkLez2rZ/JKk/5ZL2jRxFH6zRI=; b=oxhp/rDbaqGnm533DyUtoKXO8JqAiyN6uUvYPhOT54Mko63dL61tKG7cUr1MvYdcDT bvn0JwSmzeBp1Fv1IvhIgi4V8DoHynNx5YdKdx6g6CD16BblHTvBdWMkleFHZEwhxSL2 bDJD4KpeGpWDeIhIJwEXD4njSubshf7AQ9LY64CsznO1d8iv9hQmtXGTcj43DALCgPF3 jbjRdM/by8M1n1Valrhm/3BwEjR4wVo5RTGS7KK4LL8V1PwhSbkmCe7MtYrX9z6eyk/G jYSKea+FBCRWt55K/xtn2JeyS/4jsB6HUPgE1UoLwmE0sabSANu3wwdwxmvagqmgwtpD gBSA==
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=C6YEIeCv6ovv0s93UVkLez2rZ/JKk/5ZL2jRxFH6zRI=; b=gjhSQF+13dc+HYz2OgkrW6mWMZBw8XlAZwPtZ2kDSg/cQvK4Jvc7RbWjg8Knrmx8bQ vqa1Y+LPEyF8sAGJJkWgpMvSQTmQyeSbZ0wJqUuE90RG/JU4t2OjbAn/MpRJ7+AgKXb4 OtodIoN7GF8X0TqpW3hKa3IQWN9lXKLtO5g3wz87Uqm6Nko7sbmjQkiKWaMHCxerFAZU IRw3yn/tokUfK2iCXC2PUoiSc3fndfT+wMIZLZECCSqxNm1pE295jP3hM9Lmf+SM6W7P PLxGS4nLIYOyh7g5T71CTh/ciwcKTAxITYD1VzmwlN91lTa07MLrWf17WaY8bm5Np9r0 E8LA==
X-Gm-Message-State: AOUpUlFIxwVoN1Z1x2FGT0hXSNm6KJR1nF6VirIdHyPV5y6g8sTmQPpk vRhDHF0SurZ1jEUUf1pdbCNd+uJOkqB+wtFBTMhU6RpO
X-Google-Smtp-Source: AA+uWPyaljauWpeqSjG4GNa2yA+itiwrzVKAph0fRzaHnXXWgvBR6n71i5OntwZcNEKwChxT4YHo3OdTYJ+F++pFvzg=
X-Received: by 2002:a63:4b5a:: with SMTP id k26-v6mr19297552pgl.384.1534228946171; Mon, 13 Aug 2018 23:42:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a17:90a:bd0f:0:0:0:0 with HTTP; Mon, 13 Aug 2018 23:42:25 -0700 (PDT)
From: =?UTF-8?Q?Magnus_Nystr=C3=B6m?= <magnusn@gmail.com>
Date: Mon, 13 Aug 2018 23:42:25 -0700
Message-ID: <CADajj4Y6-iNNg1XOW4kZO8kGE3sEOWie6RNcgMasyiKebkuNHw@mail.gmail.com>
To: "secdir@ietf.org" <secdir@ietf.org>, draft-ietf-doh-dns-over-https@ietf.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/va1ORQ6XkutrKdxnIH65C2Lpacw>
Subject: [secdir] Secdir review of draft-ietf-doh-dns-over-https
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.27
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 Aug 2018 06:42:28 -0000

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat
these comments just like any other last call comments.

This document describes a protocol for sending DNS queries, and
receiving DNS responses, over HTTPS. The document reads well, has rich
privacy and security considerations sections and includes numerous
examples which is very helpful.


Section 3: Why remove this section altogether before publication? It
seems it provides some useful information on the background for why
the protocol is designed the way it is?

Section 4: Was the "A DoH client MUST NOT use a different URI simply
because it was discovered outside of the client's configuration"
intended to state: "A DoH client MUST NOT use URIs discovered outside
of the client's configuration"? The latter seems clearer.

Section 10: It is stated that HTTP/2 implementations will benefit from
the TLS 1.2 profile developed for HTTP/2. How about HTTP/1.1
implementations? Should there be a TLS profile for them? Also, any
particular TLS 1.3 considerations - e.g, 0-RTT and the use of the GET
option here?

- It seems like the references section needs some updates - e.g., I
found references to RFC 7828 and RFC 6891 in the text but not in the
references section.

-- Magnus