Re: [secdir] Secdir review of draft-ietf-httpbis-http2-encryption-10

Martin Thomson <martin.thomson@gmail.com> Thu, 02 March 2017 03:33 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B5A1297C3; Wed, 1 Mar 2017 19:33:06 -0800 (PST)
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=unavailable 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 Trj8v6Oif6qi; Wed, 1 Mar 2017 19:33:06 -0800 (PST)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 596B3129462; Wed, 1 Mar 2017 19:25:13 -0800 (PST)
Received: by mail-qk0-x236.google.com with SMTP id n127so104209306qkf.0; Wed, 01 Mar 2017 19:25:13 -0800 (PST)
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=Q+8uHJcwqrseqG2GpjnkjlVLk+pPH9YHjR+64UWLfAI=; b=RqDQtkTEulbPN3RY//ojCmbfYdrdTUmDgLWTePWYKQrra71yeZRyTIwE6UGDu/2W+9 5XKZnOXa/ug/viC9MmCbS2FHLJ8u65JGzXSjbvzGYWw7pTL5dJhX7O005GQVlfHHVdO9 PzCdvyhC8mGhTfBxeXuN35mXhRr21q/qnlDssuYUM2RmAX4rcpDNegO9nbdf1ZQknrB9 qFSbZ3rnFietmJAWTw4mbSxf7jnh5M0FqZvZaIrOEzAY9aRUN8jYRtKPvlKKatVq4ew1 lPLC6ePVRNkjiux7qFQaItDDHE83k5LZt/xRNNdYar/U1gBDpNb/KkHKAqGDH5UbUypH Cv5w==
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=Q+8uHJcwqrseqG2GpjnkjlVLk+pPH9YHjR+64UWLfAI=; b=EUDsWSV7T2+i+kvHPUHDhZWTZqWU8J4MTOVrOtK5oNASTO4u/3WSqP3bu1nZeLnVl6 yNQJdT43+PmHocfxAJOj3Nor0Y8KvzZ1k258dEizPyXLqn3WHewq7TjS1gpLjcGn1i2c rgjXTqlC9Gs+fQFLMWF6gN+MQqLvekAPpwb7PRIdmzi0cTFIll1o6bz3bDdt9KyqaE1i 6aUUFt4TyOk8cMlTVJSW8C8yEpheo6zWJ5f93cVfQiSzrY9EQ6tqYFWgMCfxPUAkHcXM kVZd1HrhahF8LhEjsIUczkvzPh2AcjCvL3Kp20egSmuDaxLxLoRD5ZvVjxnFcLy2EcxC QRwQ==
X-Gm-Message-State: AMke39nQSdQsPvtaASN+kMXlh7C/BS1BhzhoTHAPoLidP5EOkjua4PtdnFPjs5nVOqtm1BtlNgM6kOIiY6TJaA==
X-Received: by 10.237.51.5 with SMTP id u5mr15539959qtd.247.1488425112515; Wed, 01 Mar 2017 19:25:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.19.112 with HTTP; Wed, 1 Mar 2017 19:25:12 -0800 (PST)
In-Reply-To: <82B77F70-AC41-498D-A553-3E0E445936E0@mnot.net>
References: <CY4PR17MB0997309E466E776272827771DF290@CY4PR17MB0997.namprd17.prod.outlook.com> <82B77F70-AC41-498D-A553-3E0E445936E0@mnot.net>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Thu, 02 Mar 2017 14:25:12 +1100
Message-ID: <CABkgnnVFgsiAOyjjyZg4GwnPWBqj=S1b6=_61nX1pA24YLBxZA@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/pmg2vmq80D7v8pLEGCm3jlUMLA8>
Cc: HTTP Working Group <ietf-http-wg@w3.org>, "secdir@ietf.org" <secdir@ietf.org>, The IESG <iesg@ietf.org>
Subject: Re: [secdir] Secdir review of draft-ietf-httpbis-http2-encryption-10
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 02 Mar 2017 03:33:07 -0000

>> I believe the answer is that without that restriction there are scenarios where the feature could make it logistically easier to impersonate a server without modifying DNS responses. But more explanation in the document would have been helpful.

That's maybe *part* of the reason, which is to say that I'm not 100%
confident that I could write down exactly why in a way that wouldn't
be  either subtly wrong, or in other ways act as an irritant.  For
instance, I think that part of the reason is that it is just so damned
easy to get a valid cert that we create the more incentives to deploy
a server that could do HTTPS, even when that is not possible for other
reasons.  But then, it's entirely possible that the real reason is
subjective.  That's why I agree with Mark:

> I'm a little reluctant to start adding rationale for each requirement en masse at this stage; it feels likely that we'd misrepresent something.