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

HTTP 2.0 is an optimization. It does not need to work with maximum
efficiency everywhere.

Protocol negotiation should really be a DNS function. The DNS is the
Internet infrastructure for publishing assertions about names. That is
where the primary information describing the HTTP connection should be
stored.

The DNS does have some legacy deployment issues, but 95% of Internet
connections have a perfectly well behaved DNS connection. Proposing a
scheme that will not work for the remaining 5% is an obvious non
starter. Proposing a scheme that will not work quite as well for the
remaining 5% is an incentive to upgrade infrastructure.

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.

If we combine DNS protocol signalling with DNSSEC we can also address
the biggest security loophole in HTTP which is that every connection
is subject to a downgrade attack.

The way it might work is that the Web Server for example.com might
have the following records

! Advertise the service
_http2._tcp.example.com  SRV 1 1 443 www1.example.com
_http2._tcp.example.com  SRV 1 1 443 www2.example.com

! Describe the service
_http2._tcp.example.com DESC "tls=required certpath=MDIGA1UEJQYJ"
            "YIZIAWUDBAIBBCAXzJgPaoT7Fe"
            "XaPzKv6mI2D0yilif+7WhzmhMGLe/oBA=="

Since most DNS lookups are for a Web site, most DNS servers would be
tuned to return the SRV and DESC records as additional records in
response to an A record lookup as a matter of course.

One consequence of this approach is that an SRV record becomes an
application specific redirect for the HTTP protocol.


SRV already exists, we just need to decide to use it. At the moment we
have a security policy signalling mechanism being developed inband for
HTTP that should really be carried in the DNS so that it can be
wrapped by DNSSEC and so provide security on first connect.

There is also the proposed URI record which is similar to SRV but the
payload is a URI instead of a domain name. I believe that we should be
using URI records as the basis for Web service discovery. Probably in
conjunction with a .ws registry.


Further tricks that can be played with this approach is that the
client can be told it has the option of using a 'compression' or
'tokenization' function through a DNS description record.

Having written a few Web Services and recently having written a
compiler for them, I am less than excited at the prospect of
compressing HTTP headers when what follows is JSON or XML bloat. Using
LZ compression does not give me warm feelings either. What I really
want is a space reduction scheme that provides a better balance
between space and complexity. Something I can implement on a PIC
controller.

A simple way to implement such a scheme is to use a BER-like binary
format with a tag set defined by dictionaries that MAY be exchanged in
band or predefined as is most convenient for the application.

ASN.1 is a pig and BER is overly complex, but there is no rule that
says that a binary format has to have more than one way to do
something, nor is there any need to support canonincalization or to do
so in a way that is as idiotic as the DER rules.

A description option that allows the service to advertise the
compression dictionary version(s) it supports would enable space
saving to be supported simply and efficiently without introducing the
opaqueness that LZ type approaches inevitably do.


On Tue, Aug 14, 2012 at 10:35 AM, Eliot Lear <lear@cisco.com> wrote:
>
> I have a stack of comments and questions for the SPDY document.  This is
> a taste of what needs to get done to get this document through the
> standardization process.  Before I get to what's there, let me get to
> what's not, first:
>
> Most importantly, there needs to be clarity in the connection model, and
> currently there is nothing.  The HTTP scheme implies use of port 80.
> What next?  Seems to me there are many choices:
>
> 1.  Try sending a 2.0 message and see what happens
> 2.  Wait for a response from the server that has the right version #
> 3.  Use some sort of DNS trickery to divine the appropriate version –
> AND port.
> 4.  Go with a happy eyeballs approach and try BOTH 1.1 and 2.0
> initially, perhaps with a slight delay on 1.1 with caching of state.
>
> But we have to pick one.
>
> Rinse and repeat for TLS, albeit the mechanism may be better advertised.
>
> Speaking of advertising, it'd be nice if there was a capabilities
> exchange.  SETTINGS sort of goes there but requires more round trips.
>
>
> In Section 2.2.1:
>
> With "Version" defined in Control frames, what are the semantics for a
> mismatch?  Is an error generated?
>
> There is discussion of a both a minimum and maximum frame size, but
> there is no negotiation defined.
>
> In Section 2.2.2:
>
> Under "Data frame processing requirements", experience shows that it is
> better to shut down a connection when the protocol goes awry, and no
> more so is this the case than with multiplexed connections.
>
> Section 2.3:
>
> Nit: "Streams may be cancelled."  I think you meant closed.
>
> 2.3.1 (and elsewhere):
>
> I think RST_STREAM should be removed in favor of dropping a connection
> with an error when one side or the other just gets it wrong.  This is
> not protocol school.  There should be enough diagnostics produced to
> indicate what the problem is, and then go off.
>
> 2.3.2:
>
> I don't know about anyone else, but first I laughed about the sentence
> about streams not wrapping, and then I stopped, when I realized that
> thus far we have stretched every possible HTTP parameter to its max, so
> why not this too?  What I don't understand is why all the verbiage about
> the ordering of streams in the first place.  What's the goal?  Again,
> when sending protocol errors, best to shut down the connection afterwards.
>
> This paragraph requires additional discussion:
>
>>    Upon receipt of a SYN_STREAM, the recipient can reject the stream by
>>    sending a stream error (Section 2.4.2) with the error code
>>    REFUSED_STREAM.  Note, however, that the creating endpoint may have
>>    already sent additional frames for that stream which cannot be
>>    immediately stopped.
>
> This means the sender MUST retain any data transmitted and accepted at
> the TCP layer until the application sends "REFUSED_STREAM".
>
> Finally a nit: do you really mean "monotonic" or do you mean "linearly"
> or "in increments of two"?
>
> Section 2.3.3:
>
> Oh where to begin?  First of all, why not match nearly every other
> network protocol out there, especially IP, and have at least the higher
> value match higher priority?  But beyond this, experience shows that
> stream priority behaviors have to be defined.  Also, once we have
> streams some fool, quite possibly this one, will ask the question: and
> is there a need for a mapping to DSCPs should someone try to tunnel IP
> through one of these streams?
>
>
> Section 2.3.6:
>
> I like that in this particular instance you produce a specific error
> STREAM_ALREADY_CLOSED where elsewhere you state a simple
> PROTOCOL_ERROR.  However, in this case, since it *is* a protocol error,
> as I've argued previously, the connection should be closed.
>
>
> Section 2.4.1: This needs work.  You want to handle several different
> types of errors:
>
> 1.  Protocol errors (shut down the connection and go away)
> 2.  Application errors (these are errors that occur above the framing
> layer, but are NOT protocol errors).  An application error may be a
> resource constraint, a permissions problem, or some other
> application-layer error (e.g, "451 my boss is a jerk").
>
> Each of these sorts of errors can happen at either the stream or session
> level.  1 is easy: just shut down the connection.  2 is the one that
> needs to be clarified, IMHO.  GOAWAY may not be the entirely correct
> approach.  This is something that BEEP got right, IMHO.  There's a
> pretty clean separation between the BEEP layer and the layer above.
>
>
> Section 2.5: Huh?  What is the actual meaning of "intelligently" here?
>
> Section 2.6.1: how do you derive the size for "slot"?  Also, this should
> be reviewed by the TLS folks.  How does it relate to the
> SETTINGS_CLIENT_CERTIFICATE_VECTOR_SIZE setting?
>
> Section 2.6.3:
>
> Why is there a CANCEL and also FLAG_FIN?
>
> Error code 10: Invalid credentials.  Is this best left to "permission
> denied" without getting into the reasons in the protocol (just log them).
>
> Section 2.6.5:
>
> If either side can send this, then a server is open to any number of
> resource attacks, especially as regards to persistent settings.
>
> Section 2.6.9 needs to be reworked with the assumption that TLS may not
> be there at all.
>
> Section 3.1: Connection management
>
> You might want to amend this to allow clients to open an additional
> connection once all stream values are used.
>
> Skipping along...
>
> In Section 3.3:
>
> What does it mean: "Browsers MUST implement throttles to protect against
> unreasonable push attacks"?  How shall browsers throttle?  By delaying
> response?
>
>



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

Received on Tuesday, 14 August 2012 16:25:26 UTC