Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard

Doug Barton <> Wed, 07 January 2015 17:33 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id DEDA71A0055 for <>; Wed, 7 Jan 2015 09:33:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.012
X-Spam-Status: No, score=-2.012 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ht_ri_2vPhbq for <>; Wed, 7 Jan 2015 09:33:53 -0800 (PST)
Received: from ( [IPv6:2607:f2f8:ab14::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 64F931A0045 for <>; Wed, 7 Jan 2015 09:33:53 -0800 (PST)
Received: from bcn-dbarton.lan (unknown []) by (Postfix) with ESMTPSA id E5F2222B13; Wed, 7 Jan 2015 17:33:51 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=dkim; t=1420652032; bh=6pv/DGaumgkgwDwXEIlMbN2TbefaPUomILzpgtD8+VU=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=Jx3u9DWvOaHut/ePmfN2ycHbU6Kem2sBnsiR2qr58G3vXeF2lie+WqRG/m8oBc+mP 2VtLIr//PDhu7fEDXeNV8J/GVcSs9M3UOUeEm4aqXgYQGlpQIihchxw8UxUbF14qnl zuxVZcvc+SsvjuDWHr78JSiFfy0kPIA33Ecfh6Xw=
Message-ID: <>
Date: Wed, 07 Jan 2015 09:33:50 -0800
From: Doug Barton <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Dave Cridland <>, Eliot Lear <>
Subject: Re: Last Call: <draft-ietf-httpbis-http2-16.txt> (Hypertext Transfer Protocol version 2) to Proposed Standard
References: <> <> <> <> <> <>
In-Reply-To: <>
OpenPGP: id=1A1ABC84
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Cc: Delan Azabani <>, =?UTF-8?B?TcOlbnMgTmlsc3Nvbg==?= <>, " Discussion" <>, =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= <>
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 07 Jan 2015 17:33:55 -0000

On 1/7/15 5:07 AM, Dave Cridland wrote:
> On 3 January 2015 at 16:53, Eliot Lear <
> <>> wrote:
>     Finally, to address Måns' comments, additional data for the target
>     doesn't get signed (but correct me if I missed a change).  (Actually,
> I'm confused by this comment. You're saying (or you appear to be saying)
> that use of SRV would place greater emphasis on DNSSEC, but additional
> records don't get signed, and therefore the address record wouldn't be
> signed in this case.
> I'm not clear on where the requirement for DNSSEC comes into this, but
> given that without SRV (and without DNSSEC that is no longer required),
> there would be no signature on the address record anyway, I'm not sure
> it matters.

Just to correct what seems to be a bit of a misunderstanding here ...

If the target of the SRV is a host name that is also served by the same 
authoritative instance, and that record is signed, the signatures can be 
returned in the ADDITIONAL section. Whether they are or not has to do 
with packet size issues, and a variety of other variables.

If the host name is not served by that same server, whether the address 
record(s) are returned for that host name or not depends on how the 
authoritative instance is configured, as is the possibility of returning 
RRSIGs for those records. It is less likely in this case though.

> I would in any case strongly support addition of SRV into HTTP/2 URI
> resolution, and furthermore, I would strongly support additional work on
> DNS (and DNSSEC) to address any performance or security issues at that
> level.

As has been demonstrated already, it's overwhelmingly likely that using 
SRV would perform better than the 3-7 layers of CNAME indirection that 
are common for large enterprises (and their CDN networks) today. At 
minimum it will perform no worse.

> As a final comment, I would note that if "IANA policy" is causing us
> problems, we should just change it - these are technically speaking not
> IANA's policies but ours.

Fortunately that argument has always been a red herring, so there is 
nothing for the IANA to do here. :)