-
Notifications
You must be signed in to change notification settings - Fork 141
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
encryption-encoding: use two octets to indicate record padding length #135
Labels
Comments
beverloo
added a commit
to beverloo/http-extensions
that referenced
this issue
Jan 28, 2016
…n-encoding This is a proposal to address issue httpwg#135
This was referenced Jan 28, 2016
beverloo
added a commit
to beverloo/http-extensions
that referenced
this issue
Jan 28, 2016
In order to allow existing applications to update from one octet of padding per record to two (PR httpwg#136, Issue httpwg#135), this PR renames "aesgcm128" to "aesgcm" as the value for the Content-Encoding header, as well as the parameter name in the Crypto-Key header. This also affects the context used for deriving the nonce and the content encryption key. Examples have been updated. What I did not update is the JWE mapping (currently "A128GCM"). Do we wish to change that to "AGCM", which may be less descriptive?
beverloo
added a commit
to beverloo/http-extensions
that referenced
this issue
Jan 28, 2016
In order to allow existing applications to update from one octet of padding per record to two (PR httpwg#136, Issue httpwg#135), this PR renames "aesgcm128" to "aesgcm" as the value for the Content-Encoding header, as well as the parameter name in the Crypto-Key header. This also affects the context used for deriving the nonce and the content encryption key. Examples have been updated. What I did not update is the JWE mapping (currently "A128GCM"). Do we wish to change that to "AGCM", which may be less descriptive?
beverloo
added a commit
to beverloo/http-extensions
that referenced
this issue
Feb 12, 2016
…n-encoding This is a proposal to address issue httpwg#135
beverloo
added a commit
to beverloo/http-extensions
that referenced
this issue
Feb 12, 2016
In order to allow existing applications to update from one octet of padding per record to two (PR httpwg#136, Issue httpwg#135), this PR renames "aesgcm128" to "aesgcm" as the value for the Content-Encoding header, as well as the parameter name in the Crypto-Key header. This also affects the context used for deriving the nonce and the content encryption key. Examples have been updated. What I did not update is the JWE mapping (currently "A128GCM"). Do we wish to change that to "AGCM", which may be less descriptive?
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Each record currently includes between 1 and 256 octets of padding, while the default record size is set to 4096 octets. This is in many cases not sufficient, for example in the pad-to-next-power-of-two case.
Extending the padding length to two octets will allow up to 65537 octets (65KB) of padding.
I raised this on the ietf-http-wg list here:
https://lists.w3.org/Archives/Public/ietf-http-wg/2016JanMar/0171.html
Martin raises a good point about an upgrade path for existing users. I'll reply on the mailing list to not split the discussion.
The text was updated successfully, but these errors were encountered: