weixin_39646725
2020-12-30 03:19 阅读 0

Certificate compression

The document currently (though I hope to remove this) makes certificate compression a requirement of the cryptographic handshake. TLS doesn't really do compression, though it does provided cached-info (RFC 7924). Is this sufficient or do we need to ask the TLS working group for a compression feature. I'm assuming that if we did need to ask, we would also be responsible for providing a design.

Note that TLS 1.3 aims to provide confidentiality for certificates and compression is generally fraught with hazards that compromise confidentiality. It also potentially a feature that could leak information about a client's past connections to servers. If we due pursue this, any design we create would need to carefully consider these (and likely other) risks.

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

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

8条回答 默认 最新

  • weixin_39700063 weixin_39700063 2020-12-30 03:19

    FTR I raised the issue on the TLS list here, however the main response was "compression is scary", but it could just be due to lack of details on my part.

    Unfortunately I haven't been able to find the time to do any experimenting (or indeed reply to the mail thread), and haven't heard from Victor.

    As for caching, it seems to me RFC7924 is quite a bit less flexible than what we have in Google QUIC (namely, you can only cache full chains, not single entries AFAICT, so e.g. you can't just cache intermediates), but again haven't been able to do any experimenting.

    点赞 评论 复制链接分享
  • weixin_39738273 weixin_39738273 2020-12-30 03:19

    I am still working on figuring out what would be the impact of compression with and without a pre-shared dictionary, as well as what dictionary we should use. I expect to have some preliminary answers in a week or two.

    With regards to the other ways of compression, I feel like both RFC 7924 and QUIC-style cached certificate chain should not matter in most cases since if we talked to a host before, what we really want is to just do a session resumption. But I might be wrong, and I am not sure how a cert cache would behave in real-life situations when a lot of sites use it.

    点赞 评论 复制链接分享
  • weixin_39646725 weixin_39646725 2020-12-30 03:19

    I suspect that this will be handled by the TLS working group (if at all). , , what would you prefer we do to this issue given that it is out of our hands?

    点赞 评论 复制链接分享
  • weixin_39717318 weixin_39717318 2020-12-30 03:19

    My take is that we have enough on our plate without defining this too; it can be introduced later with an extension or a new version if it's defined elsewhere.

    In particular, I'd be concerned that adding compression would trigger a need for a round of crypto review, and as discussed before, the TLS WG is better at getting that.

    So, I'm inclined to think we should close this issue with no action -- provided that Martin can remove the requirement (how's that going?).

    点赞 评论 复制链接分享
  • weixin_39646725 weixin_39646725 2020-12-30 03:19

    Well, all we need is a decision to remove the requirement. The text-removing part already happened.

    点赞 评论 复制链接分享
  • weixin_39717318 weixin_39717318 2020-12-30 03:19

    ok to close this then?

    点赞 评论 复制链接分享
  • weixin_40001025 weixin_40001025 2020-12-30 03:19

    Is presenting this at TLS WG in Chicago, so I think it's fine to close this and make it a TLS WG item.

    点赞 评论 复制链接分享
  • weixin_39646725 weixin_39646725 2020-12-30 03:19

    We might keep this open if we think that tracking the TLS work in the form of an issue is the right thing to do, but I'm going to close this for now. Reopen if you disagree.

    点赞 评论 复制链接分享

相关推荐