weixin_39526546
weixin_39526546
2020-12-29 23:29

Including Connection ID in cleartext key derivation

I apologize for not catching PR#844, but I think including the connection ID in the cleartext key derivation creates some minor problems for not much benefit.

1) I suppose forcing you to derive a different key for each apparently valid CLIENT_INITIAL increases the expense of middleboxes decrypting these packets. However, it also increases the expense for end servers, trusted proxies, etc. with no real increase in security or ossification-resistance.

2) It is possible for implementers to screw up host/network order for connection ID, which will create debug-resistant crypto mismatches.

3) Most importantly, I have to store an additional crypto context in my QUIC PCB. Once I've generated 1-RTT keys, there is an interval where I must prepare to receive three different keys: Cleartext, 0-RTT, and 1-RTT, If I can store the cleartext key on a system-wide per-version basis, then I can use the two spots I need for key renegotiation anyway.

I readily concede that none of these points are showstoppers, but I would like someone to make the case for this added complexity.

该提问来源于开源项目:quicwg/base-drafts

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享
  • 邀请回答

5条回答

  • weixin_39904522 weixin_39904522 4月前

    In response to (3) above, I'd say each QUIC connection context would likely still hold the cleartext key, even if connection ID wasn't an input. You can't assume (at least client side) any individual connections have any shared state with any other connections. For instance, in WinQuic, they do not have any shared state.

    For (2), yes this can be an initial minor debug headache, but interop testing in general will always have these headaches, IMO.

    As for (1) I believe making the cleartext encrypted based on the Client's initial connection ID does solve some problems around a particular scenario that brought up related to immediately creating a new connection after a previous one was cancelled. It allows for you to ignore received handshake packets from the initial connection. So it does have some value, just not necessarily security.

    点赞 评论 复制链接分享
  • weixin_39526546 weixin_39526546 4月前

    While some implementations might not have shared state, it would certainly be valuable for server implementations that do have it to only have to compute the cleartext key once when loading the config, instead of for every incoming CLIENT_INITIAL.

    I guess I don't understand 's case. The keys are only different if the connection IDs are different, and if the connection IDs are different that's sufficient to distinguish the attempts.

    点赞 评论 复制链接分享
  • weixin_39597399 weixin_39597399 4月前

    I believe there are only two overheads in creating a new temporary initial key for handshake:

    1. create randomness, compute AES key context, and compute the GCM hash.
    2. allocate and deallocate memory for the encryption context.

    I don't have any numbers for the cost of the key setup. I would actually be interested in hearing what the cost is. But it is surely a lot faster than Diffie Hellman key exchanges.

    So, on the surface there might be something to be gained. But it comes at a cost in complexity:

    A reusable initial key must be reference counted and protected against overuse wrt. safety limits, and indexed and cached per endpoint. The key must be renegotiated with the endpoint somehow and the negotation should be safe against certain attacks. It must be verified that protection against off path attacks on the handshake remains effective. The key endpoint cache will consume space that is possibly irrelevant, for example for an endpoint the only connects once to many different peers. When the cache expires, a new key must be obtained somehow.

    点赞 评论 复制链接分享
  • weixin_39574050 weixin_39574050 4月前

    wrote:

    I guess I don't understand 's case. The keys are only different if the connection IDs are different, and if the connection IDs are different that's sufficient to distinguish the attempts.

    When the first Server Clear Text messages arrives, it carries no reference to the initial connection ID chosen by the client. There is thus no way to distinguish between the response to the latest Client Initial and a repeat of a Server Clear Text from a previous connection attempt. Same IP addresses, same ports, no clue.

    If the key depends on the connection ID, you ensure that the client will drop messages that are not relevant to the connection, thus solving the problem of spurious repeat of Server Clear Text messages.

    点赞 评论 复制链接分享
  • weixin_39526546 weixin_39526546 4月前

    Alright, this might not be how I would design SCID, but this decision makes sense in that context. Closing the issue.

    点赞 评论 复制链接分享

相关推荐