Re: comments on draft-mbelshe-httpbis-spdy-00

On Wed, Aug 15, 2012 at 9:00 AM, Patrick McManus <pmcmanus@mozilla.com> wrote:
> On Tue, 2012-08-14 at 12:24 -0400, Phillip Hallam-Baker wrote:
>
>> If we take architecture seriously, the primary signaling mechanism for
>> HTTP/2.0 should be some form of statement in a DNS record to tell the
>> client 'I do HTTP 2.0'. We might also have some sort of upgrade
>> mechanism for use when the DNS records are blocked but that should be
>> a fallback.
>
> This is my current thinking as well though I'm not tied to it.. srv in
> the base case (with the possibility of dnssec) and something like
> upgrade/alternate-protocol over HTTP/1 as a slower fallback.

DNSSEC should be used if available but must not be a requirement.
HTTP2 will be doa if deployment of DNSSEC is a precondition.

Another problem with DNSSEC is deciding what a client should do when
the DNSSEC status is bad. If the answer is 'carry on anyway' then
there is very little value to DNSSEC. If the answer is 'stop' a lot of
stuff is going to break.

If people are going to propose using security, they need to come up
with a finite state machine that shows exactly how the client is
expected to behave on the available information and they have to use
the same FSM to address every use case. During the DKIM discussions we
had endless arguments when people suggested that the client address
corner case A by rejecting a message in a particular circumstance and
address corner case B by accepting it. I found that discussion
unhelpful.

That is why I am more interested in an architecture in which the
client does not attempt to use raw DNS data but may accept them
through some form of service which would curate the data. That does
not actually change the requirement for what needs to be stated in
HTTP or DNS, the service needs the same starting point information as
the client. But it does mean that corner cases can be left to the
service to cope with.

-- 
Website: http://hallambaker.com/

Received on Wednesday, 15 August 2012 13:43:17 UTC