Re: What to do about multipath in QUIC

[Florentin Rochet <[e-mail]>]

Hello,

I have suggested a similar idea than Kazuho in Quentin Deconinck's draft:

https://tools.ietf.org/html/draft-deconinck-quic-multipath-06#section-8.1

Playing with the IV allows the endpoints to do an implicit derivation of 
the new crypto material for the new paths (using the same key). Besides, 
a multi-key settings makes a security degradation [0], so it might be 
better to avoid it if it's easy enough :-)

Best,

Florentin

[0] https://www.isg.rhul.ac.uk/~kp/TLS-AEbounds.pdf  Section 1.3

Le 16/11/20 à 08:53, Kazuho Oku a écrit :
>
>
> 2020年11月16日(月) 16:32 Yunfei Ma <[e-mail] 
> <mailto:[e-mail]>>:
>
>     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 <[e-mail]
>     <mailto:[e-mail]>> wrote:
>
>
>
>         2020年11月16日(月) 8:25 Yanmei Liu <[e-mail]
>         <mailto:[e-mail]>>:
>
>             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
>             <[e-mail] <mailto:[e-mail]>> 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