Skip to content
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.

Sign up for GitHub

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

Jump to bottom

encryption-encoding: use two octets to indicate record padding length #135

Closed
beverloo opened this issue Jan 28, 2016 · 1 comment
Closed

encryption-encoding: use two octets to indicate record padding length #135

beverloo opened this issue Jan 28, 2016 · 1 comment
Labels
encryption

Comments

@beverloo
Copy link
Contributor

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.
beverloo added a commit to beverloo/http-extensions that referenced this issue Jan 28, 2016
@beverloo
Use two octets to indicate record padding length in httpbis-encryptio…
1b2af1e 
…n-encoding

This is a proposal to address issue httpwg#135
This was referenced Jan 28, 2016
Merged
Closed
beverloo added a commit to beverloo/http-extensions that referenced this issue Jan 28, 2016
@beverloo
Rename aesgcm128 to aesgcm to provide an update path
85fb936 
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 beverloo mentioned this issue Jan 28, 2016
Merged
beverloo added a commit to beverloo/http-extensions that referenced this issue Jan 28, 2016
@beverloo
Rename aesgcm128 to aesgcm to provide an update path
917dd5d 
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
@beverloo
Use two octets to indicate record padding length in httpbis-encryptio…
6ef5014 
…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
@beverloo
Rename aesgcm128 to aesgcm to provide an update path
b920f58 
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?
@martinthomson
Copy link
Contributor

This was fixed in #136 and #137.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
encryption
Milestone
No milestone
Development

No branches or pull requests
3 participants
@martinthomson @mnot @beverloo