[Ohai] Padding message contents

[Martin Thomson <[e-mail]>]

tl;dr I propose we simplify the padding scheme and move it to binary messages.

Changes proposed:
https://github.com/ietf-wg-ohai/oblivious-http/pull/83
https://github.com/httpwg/http-extensions/pull/1832

---
Tommy Pauly asked me a question about a bug in my implementation of the OHTTP specification that prompted me to realize that there are a few problems with the padding design.  I'd been meaning to come back to it, so here we are.

This is the current format of the plaintext input to HPKE:

Plaintext Message {
  Message Length (i),
  Message (..),
  Padding Length (i),
  Padding (..),
}

However, this is slightly redundant.  The binary message format has a really convenient property that it is length-delimited.

It also suffers from an awkward discontinuity when your padding gets long enough to reach the point that the size of the VLI length increases.  63 bytes of padding takes a single octet of length; 64 bytes takes two bytes minimum.  So with minimum-sized lengths, you go from 64 bytes all up to 66.  You can avoid that by encoding 63 bytes of length with a two byte length field, but that requires custom (read: fragile) code.

There's a simpler design, just extend the binary HTTP message with zero bytes:

Plaintext Message {
  Message (..),
  Zeros (..),
}

Binary HTTP messages are length-prefixed internally so there is no risk of ambiguity, with one wrinkle (see below).

This results in a little loss of generality, but I don't think that's a problem.  It doesn't make sense to have generic media type switching at this layer: that's complexity.  So we can (and should) recognize that message/ohttp-req maps to message/bhttp always; same for message/ohttp-res.

Another protocol that wants to reuse the work we've done here to make a similar sort of format can switch out the type of protected message by choosing a different encapsulation.  As long as that format is length-prefixed (or doesn't end in a zero byte, I guess), they can use an identical encapsulation.  But there are other things they would want to do, such as use different key derivation labels to maintain key diversity, etc...

One consequence of this sort of change is that you don't have an easy way to carve out the message part from the zeros part without understanding (and parsing) the message format.  If you could rely on your binary message format being able to handle padding, then you could just hand the whole blob over for processing.  If we also consider the potential for binary messages to be used outside of this context, having padding in that format is probably a good feature to have.

To that end, I'm going to propose that we add the ability to pad with zeroes to the binary-messages draft (which will need an email to the HTTP WG) and remove this Plaintext Message structure entirely.  The plaintext input would just be the binary-encoded http-message.

I've written a pull request with proposed changes to the binary HTTP message draft: 
https://github.com/httpwg/http-extensions/pull/1832

And a pull request for the OHTTP draft:
https://github.com/ietf-wg-ohai/oblivious-http/pull/83