Draft: draft-ietf-ohai-ohttp

Commentary: Comment by How would that work ? How would the client consent ? Or show awareness ? Or become aware ? Ca n't the Target Resource also not use padding in the response ? But I guess they would n't know about being connected to obliviously or regularly , unless the  tells the server within its encrypted payload request ? Eg if a regular https server sees a certain field , it would / could know to do some padding ? ( one would assume ohttp relays are fairly well known on static IPs anyway , so the Client would n't be revealing much if it could ask the http server itself for random padding 
 There are two questions here , delays and padding . Both are areas in which the specification is not prescriptive . This is deliberate , mostly because these are areas where a single strategy would be inadvisable . Application needs vary . Well , in any number of ways . A telemetry submission service ( see also STAR ) might provide greater privacy benefit from batching requests that are forwarded from the client to gateway . In that model , the client might tolerate arbitrary delay ( see for example ) . In other cases , the client still cares about a response , but it might be willing to hang around for some time ( 10s , 30s ) for an answer . How the client consents to delays can also vary . It could be part of terms of service that are negotiated when the use of the relay is arranged . That sort of arrangement might cover all these points . If you are looking for protocol mechanisms , we 've discussed explicit signaling as an extension . A client could use something like ( see ) to indicate that within the protocol[^1 ] . An explicit signal demonstrates awareness for those cases where the delay might be conditional . [ ^1 ] : Note also that this sort of signaling might imply a need for the relay to remove that field , though perhaps all clients add it and so it does n't reveal anything if forwarded . Yes . Section 6.3 references back to this text , but it 's worth mentioning the gateway too . There are many things that might feed into a padding strategy . Sometimes this is something the gateway will know because they are configured for a particular application and can look at the payload to determine how to best pad . Clients can probably signal ( within encapsulation ) what they might prefer , if that would help . Again , it 's too application - specific to say much of use . 
  , The comment it is n’t my comment . Maybe there is another Pwouters in github Kind regards   vanaf mijn iPad 
 My apologies . I definitely got the wrong person there . 
 thanks 
 Flipping to approve , with or without my suggestion . Sorry again for my confusion .
can use padding to reduce the effectiveness of traffic analysis.
Padding is a capability provided by binary HTTP messages; see BINARY.
If the encapsulation method described in this document is used to
protect a different message type (see repurposing), that message
format might need to include padding support.
and can use padding to reduce the effectiveness of traffic analysis.
Padding is a capability provided by binary HTTP messages; see BINARY.
If the encapsulation method described in this document is used to
protect a different message type (see repurposing), that message
format might need to include padding support.