Re: [quicwg/base-drafts] Encrypting token in Retry packet (#3477)

Martin Thomson <notifications@github.com> Sat, 22 February 2020 23:47 UTC

Date: Sat, 22 Feb 2020 15:47:56 -0800
From: Martin Thomson <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJK6DF4BAXIQNCLDWVEN4L3YCZEVBNHHCD4DU3Q@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3477/590009756@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3477@github.com>
References: <quicwg/base-drafts/issues/3477@github.com>
Subject: Re: [quicwg/base-drafts] Encrypting token in Retry packet (#3477)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5e51bdac7f064_34133ff1836cd964376613"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/apvB5Vb1gqL4lwCEFX22rNfx9EQ>

This idea was discussed and dismissed.  The problem here is that the HKDF application required to get the keys is significantly more expensive than applying the AEAD.  The cost of producing a Retry was considered important enough not to take this cost.

The pseudo-packet is relatively inexpensive in practice.  Allocating an extra 21 bytes and pre-filling the connection ID in that space doesn't end up costing that much.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/3477#issuecomment-590009756

[quicwg/base-drafts] Encrypting token in Retry pa… Quoc-Viet Nguyen
Re: [quicwg/base-drafts] Encrypting token in Retr… Martin Thomson
Re: [quicwg/base-drafts] Encrypting token in Retr… Quoc-Viet Nguyen
Re: [quicwg/base-drafts] Encrypting token in Retr… Martin Thomson
Re: [quicwg/base-drafts] Encrypting token in Retr… ianswett
Re: [quicwg/base-drafts] Encrypting token in Retr… Lars Eggert