2020年11月16日(月) 16:32 Yunfei Ma <[email protected]
<mailto:[email protected]>>:
Dear Kazuho,
Thanks for providing this alternative solution. I think it's
great, but please correct me if I am wrong. In the quic-tls-32
section 5.3., it reads:
_"The exclusive OR of the padded packet number and the IV forms
the AEAD nonce."_
__
So my question is: if we want to embed the sequence number of the
connection ID into the AEAD nonce, don't we need to incorporate
this method into section 5.3.?
That's true. AEAD takes three inputs: secret, IV, nonce.
In order to avoid reuse, we need to make either of the three a
per-path variable. My point is that changing the definition of nonce
is the easiest, because it is a value that is calculated for each
encrypt / decrypt operation, and because we have space to incorporate
the path identifier (being the sequence number included in the
NEW_CONNECTION_ID frame).
That's going to be a small enough change that can be made in the
multipath extension.
Thanks,
Yunfei
On Sun, Nov 15, 2020 at 9:19 PM Kazuho Oku <[email protected]
<mailto:[email protected]>> wrote:
2020年11月16日(月) 8:25 Yanmei Liu <[email protected]
<mailto:[email protected]>>:
Hi Christian and Lucas,
Thanks a lot for the advice :-)
> The use of AEAD is only safe if the same packet number
is not reused twice with the same key. If we use multiple
packet number contexts, AEAD is only safe if these
contexts use different encryption keys. This requires
adding a key derivation procedure for the "sub
connection", and also adding ways to identify the relevant
key in the incoming packets. This gets complicated very
quickly, especially if we want to keep the possibility of
using zero-length connection identifiers on the client side.
> I use a concept very similar to the sub-connection, but
only as a way to manipulate paths, so the client can
instruct the server when paths ought to be abandoned.
Otherwise, I just keep track of which PN maps to which path.
We have tried to use the same packet number space in all
the paths (or sub-connections) before, and have found that
it brought much complexity in implementation for loss
recovery.
In the meanwhile, the AEAD security problem mentioned
above should be solved. Another way to solve this problem
is using different keys in different paths, but it also
brings much complexity in key derivation as you have
mentioned.
We have found a third solution in
https://tools.ietf.org/id/draft-huitema-quic-mpath-req-01.txt
: create nonces by mixing the IV with both the path
specific connection ID and the packet sequence number.
If we can mix Destination Connection ID in for each
packet's AEAD nonce, then it will be safe to use the same
key in all the paths with different packet number spaces.
Or as an alternative, we can encode the sequence number of the
connection ID directly in the unused part of AEAD nonce (size
of nonce is 96 bits in AES-GCM, 128 bits in chacha20-poly1305,
but we only use 62 bits). The benefit of such an approach is
that endpoints would not be required to have additional state
related to AEAD. Endpoints already have the mapping between
connection IDs and their sequence numbers, all they need to do
is pass that sequence number as part of the AEAD nonce.
But since QUIC-TLS has been in the last-call period, would
it be able to add this modification into QUIC-TLS?
I do not think we have to, especially if we embed the sequence
number of the connection ID into the AEAD nonce.
Thanks,
Yanmei
On Fri, 13 Nov 2020 at 01:04, Christian Huitema
<[email protected] <mailto:[email protected]>> wrote:
On 11/12/2020 3:10 AM, Mikkel Fahnøe Jørgensen wrote:
1. We think QUICv1 has already laid down the foundation to
build a general-purpose multi-path since migration can be viewed as a special
type of multi-path. Therefore, we think one should reuse the design of
migration in QUIC-v1 as much as possible, along with the features such as
PATH_CHALLENGE/PATH_RESPONSE for path challenge and address validation, and
NEW_CONNECTION_ID/RETIRE_CONNECTION_ID for CID renegotiation of new path(which
is called Sub-connection in our draft). Reusing these features of QUIC-v1 with
small extensions has enabled us to get general-purpose multi-path features with
very little efforts in
Alibaba’s XQUIC(an implementation of QUIC-v1).
Yes. That's a major investment in QUIC V1, and we
should keep it.
2. We find that the simplest way to add a second path is to
use a sub-connection. The concept of sub-connection is directly inherited from
connection in QUIC-transport, defined as the logic session of each physical
path. Similar to a connection, each sub-connection has its own packet number
space for the purpose of loss detection and recovery.
I did not want to do that in my own draft for a couple
of reasons. The main one is the interaction with
encryption.
The use of AEAD is only safe if the same packet number
is not reused twice with the same key. If we use
multiple packet number contexts, AEAD is only safe if
these contexts use different encryption keys. This
requires adding a key derivation procedure for the
"sub connection", and also adding ways to identify the
relevant key in the incoming packets. This gets
complicated very quickly, especially if we want to
keep the possibility of using zero-length connection
identifiers on the client side.
I use a concept very similar to the sub-connection,
but only as a way to manipulate paths, so the client
can instruct the server when paths ought to be
abandoned. Otherwise, I just keep track of which PN
maps to which path.
3. To merge the gap between migration and the general-purpose
multi-path, several new features need to be supported:
- (1) how to manage the lifecycles of individual
sub-connections.
- (2) how to distinguish packets coming from different
sub-connections.
- (3) how to co-operate with a multi-path scheduler.
We would appreciate hearing any thoughts, comments and
suggestions.
I think we need more work on the
"multi-path scheduler". We have heard of three
application scenarios: maintaining the lowest RTT when
sending voice segments (Apple Siri), avoiding
buffering delays when playing music (Apple Music), and
using two available links with equal preference (Ali
Baba "high speed train"). I wish that we could
distillate that into a couple of simple concepts.
-- Christian Huitema
--
Kazuho Oku
--
Kazuho Oku
