Re: [alto] Redistribution (was: Reprise of REST comments)

[Richard Alimi <[e-mail]>]

Hi Martin,

On Wed, Jan 5, 2011 at 2:56 PM, Thomson, Martin
<[e-mail]> wrote:
> On 2011-01-05 at 19:38:02, Richard Alimi wrote:
>> > Digital signatures are one way of checking, but there are other
>> options:
>> >
>> >  - MD5 is pretty weak by modern standards, but a HEAD request to the
>> URI could produce a Content-MD5 header.
>> >  - Use a link header (and a HEAD request) to include a link to a
>> digest if MD5 is no good.
>> >  - Wait for someone else to invent some better HTTP integrity
>> mechanism.  Mark Nottingham is interested in designing something for
>> more general caching applications.
>> >
>> > I'm going to advise that the latter is the course you want to follow,
>> perhaps leaving other options open in the meantime.  No point in
>> inheriting more complexity than absolutely necessary.
>> >
>>
>> Each of these three options requires the ALTO Client to send a message
>> to the HTTP server to verify, right?  One of the goals of
>> redistribution is to allow ALTO Clients to not contact an ALTO Server
>> at all in the common case. With the existing solution, ALTO Clients
>> need only download a certificate upon initial contact with the server,
>> and can then verify ALTO Responses without contacting the server at
>> all.  Section 12.4 has some additional discussion on this.
>
> There's a fair difference between asking for data (and all that entails) and just asking for metadata in terms of denial of service.
>
> If, however, redistribution is a fundamental part of the architecture, then there's a lot of work to be done in getting that right.
>
> I'm not the security guy, but that signature mechanism looks like it needs some work.  I like the fact that you have put the signature in metadata, but how does a client decide which of the many available public keys to use?  There are potentially multiple sources that can provide a public key; before redirection comes into play.
>

I think Section 8.1.3 should answer the question here. Was it still
ambiguous after reading this?  If so, we can certainly clarify it.

> From an HTTP perspective, I think that you will find that trailers are poorly supported.  Current advice indicates that they have to be able to be ignored (see [1]), which might interfere with your use case - though this is definitely the right way to use trailers.
>

That's unfortunate.  I think the requirements here are that an ALTO
Server should be able to generate and an append a signature even for a
dynamically-generated response which is streamed (as opposed to
buffered) to a client.  An alternative was to put the signature as
some trailing portion of the JSON message (e.g., the last member of
the outer-most object), but that seemed ugly since it seemed to
require signing a subset of the JSON message, thus requiring us to
define some canonical form that would be used for signature
verification.  Do you know of other alternatives beyond these two?

>  At a minimum, drop the PEM encoding, it doesn't play well with HTTP headers, nor does it really make sense: you just have a numeric value, so base64 alone should suffice.
>

Thanks - we can update that.

> On balance, I'd still encourage you to investigate this separately to the rest of the protocol.  You might find that you can get someone else to do the hard work for you.  I also suspect that this sort of thing could be a sticking point in the many reviews this work has to navigate; don't let a small thing prevent the bigger thing from happening.
>

Splitting it out to a separate draft would be okay I think. Other
feedback from the WG here?

Rich

> --Martin
>
> [1] http://tools.ietf.org/html/draft-ietf-httpbis-p1-messaging-12#page-36
>