Re: New Draft: draft-ohanlon-transport-info-header

On Tue, Nov 26, 2019 at 12:12 PM Piers O'Hanlon <piers.ohanlon@bbc.co.uk>
wrote:

>
> Sure - I guess I didn’t put it very well - I was trying to say that the
> Transport-Info header would be only be transferred between that CDN edge
> and the client - it’s a hop-by-hop heade'''


h2 doesn't have hop to hop headers. it has per stream frames though.


> r - for the last last hop.


how does one know they are the last hop?

what have you have described the side channel isn’t clear to me?
> >
> >
> > obviously the HTTP protocol is aware of this sharing - indeed it
> initiates it! but the ramifications of it are generally opaque to the
> semantics of HTTP exchanges (roughly expressed by headers and messages). So
> perhaps what you want is better carried in the protocol (e.g. as a frame)..
> if you are proposing exposing it to content it needs to be scrutinized for
> the same reason that it is useful. This can be subtle - see CRIME and
> BREACH for example.
> >
> Yes I had considered that frame based transport might be better but what
> is also required is to extract the transport/flow information for that
> stream - but if one could do that then it would potentially be ok to
> transport it in a header as the issue is that there is access to shared
> state.
>

there is a significant difference between information available to the
protocol implementation and information in the semantic header layer which
is available to javascript. The latter is held to a higher level of
isolation due to the security model of javascript.


> Also for H2/3 since this is an issue about transport rate the fact padding
> is used on each connection


padding is not really a common thing at scale and there is some controversy
over how helpful it is.


> means that there is always going to be some uncertainty introduced by
> padding in such attack. Such an attack where one flow to try to learn about
> another flow it would need to calculate it’s own portion of the flow so it
> could subtract it from the total flow rate provided by the header but’s
> going to be limited by not knowing about the padding.
>
>
I think your best argument is going to be that this side channel isn't very
meaningful for what you are reporting - but arguing that there isn't a side
channel is not going to work out well long term. The attacker is always
better motivated and more clever than your defense. Here's a fun one:
https://www.usenix.org/node/217606 from ietf 106


> Another potential mitigation technique would be to add some noise to the
> measurements which would make it harder for collusion to occur with
> coordinated attacks. The choice of the level of noise could be a function
> of the number of flows the server knows are sharing the connection, or
> maybe just some randomness so that two simultaneous requests don’t obtain
> the same result - although in practice they’re not going to obtain the same
> result as the connection parameters are constantly changing, although such
> random noise could mitigate attempts to compare trends.
>
>