Design team output #99
Conversation
Co-authored-by: Benjamin M. Schwartz <ben@bemasc.net>
…-quic-proxy into bemasc-scramble
Co-authored-by: David Schinazi <DavidSchinazi@users.noreply.github.com>
Proposal: Packet Transforms
fixes #94 This PR creates two registries, however, not sure we really need the parameter names one? Both registrations are proposed with Specification Requires Policy but I could also see reasons to actually go for IETF Review. Any views? Following the model in https://www.iana.org/assignments/http-parameters/http-parameters.xhtml both registries have a "Description" and "Notes" section, however, not sure we really need those.
IANA registries for parameter names and transform names
Co-authored-by: David Schinazi <DavidSchinazi@users.noreply.github.com>
Co-authored-by: Tommy Pauly <tpauly@apple.com>
Co-authored-by: Benjamin M. Schwartz <ben@bemasc.net>
Co-authored-by: Tommy Pauly <tpauly@apple.com>
Co-authored-by: David Schinazi <DavidSchinazi@users.noreply.github.com>
Co-authored-by: mirjak <mirja.kuehlewind@ericsson.com>
Co-authored-by: Benjamin M. Schwartz <ben@bemasc.net>
Co-authored-by: David Schinazi <DavidSchinazi@users.noreply.github.com>
Co-authored-by: Benjamin M. Schwartz <ben@bemasc.net>
Co-authored-by: mirjak <mirja.kuehlewind@ericsson.com>
Co-authored-by: Benjamin M. Schwartz <ben@bemasc.net>
Co-authored-by: mirjak <mirja.kuehlewind@ericsson.com>
| @@ -203,6 +204,7 @@ Each client <-> proxy HTTP stream MUST be mapped to a single target-facing socke | |||
|
|
|||
| Multiple streams can map to the same target-facing socket, but a | |||
| single stream cannot be mapped to multiple target-facing sockets. | |||
| Each stream MUST also be associated with a single Packet Transform. | |||
There was a problem hiding this comment.
Here, shouldn't we map a stream to a mode (proxying / forwarding)? Then we can say that if a given stream is associated to the forwarding mode, then a single packet transform must be mapped to this stream.
There was a problem hiding this comment.
Technically, forwarding mode is always additional to proxying mode. The long header packets have to be sent in proxying mode anyway, so proxying mode is available and could be used for some short header packets as well.
There was a problem hiding this comment.
Agreed, then implicitly, mapping to "forwarding" means that long header packets are proxyed, and short header packets are forwarded.
draft-ietf-masque-quic-proxy.md
Outdated
|
|
||
| Packet transforms are identified by an IANA-registered name, and negotiated in | ||
| the HTTP headers (see {{client-behavior}}). This document defines two initial | ||
| transforms: "null" and "scramble". |
There was a problem hiding this comment.
In the light of an issue filled by Martin Thomson, I agree that the "null" transform can be named "identity transform" to adopt a similar naming as in mathematics and cryptography.
draft-ietf-masque-quic-proxy.md
Outdated
| the HTTP headers (see {{client-behavior}}). This document defines two initial | ||
| transforms: "null" and "scramble". | ||
|
|
||
| > QUESTION: Should one or both of these be Mandatory To Implement? |
There was a problem hiding this comment.
I am in favor of making both transforms mandatory to implement. The null / identity transform is straightforward to implement as soon as a proxy supports forwarded mode, and I think making the scramble transform mandatory allows clients willing to use a proxy using the forwarded mode to benefit from a minimal security level.
A side question that this question triggered: Are we willing to provide a mechanisms to negotiate transform between the client and proxy?
There was a problem hiding this comment.
Mandatory for whom? I find the idea of making them both mandatory for both clients and proxies to be slightly strange. Perhaps you are thinking of making them both mandatory for proxies, so that clients can choose to offer only one?
draft-ietf-masque-quic-proxy.md
Outdated
| that crossed the forwarder, providing a compact proof that a specific client | ||
| was communicating to a specific target. | ||
|
|
||
| Use of this transform is NOT RECOMMENDED if "scramble" can be deployed. |
There was a problem hiding this comment.
If we agree that the scramble method is mandatory to implement, then, why should we keep the null / identity transform?
There was a problem hiding this comment.
I can certainly imagine that we say "scramble" is MTI for proxies, but clients can choose whether they want the extra protection.
There was a problem hiding this comment.
If we let clients the choice not to use the additional protection, then I suggest making scramble and null/identity MTI by the proxies, and recommend that clients use scramble or alternative method of their choice to protect their communication.
Closes #101
null -> identity
|
If I understand correctly, the scramble transform can be defeated by a single injected packet (ie with duplicated iv bytes, leading to key/iv reuse with aes-ctr). I think we should explicitly mention this in the security considerations, as this is both lower effort than most active attacks, and difficult to detect. |
Expand on active attack differences
Creating a PR for the output of the design team, to add a way to encrypt packets in forwarded mode.
Rendered view of this PR
Rendered diff with main