ietf
[Top] [All Lists]

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

2015-01-07 11:34:12
On 1/7/15 5:07 AM, Dave Cridland wrote:
On 3 January 2015 at 16:53, Eliot Lear <lear(_at_)cisco(_dot_)com
<mailto:lear(_at_)cisco(_dot_)com>> 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. :)

Doug


<Prev in Thread] Current Thread [Next in Thread>