Including the client's ephemeral public key in the AAD precludes use of a single-shot HPKE API #397
Comments
|
A single-shot HPKE already isn't viable because of HRR. You need to keep the second HPKE context around in case you need to encrypt second ClientHello. That said, I'm perfectly happy with omitting it. (Or including it.) This dates to #362 and #326. Of the added fields, That leaves |
|
On 11/03/2021 00:46, David Benjamin wrote:
A single-shot HPKE already isn't viable because of HRR. You need to
keep the second HPKE context around in case you need to encrypt
second ClientHello.
I've not done anything specific yet wrt HRR, and I'm guessing
those details are still in-play to some extent, so not sure.
But yeah, if the 2nd CH has to use the same keying then that
may be the case.
That said, I'm perfectly happy with omitting it or including it. This
dates to #362 and
#326. Of the added
fields, `cipher_suite` and `enc` are already incorporated into HPKE
itself anyway, so we shouldn't need to redo it in ECH.
I agree. If there's a good reason to include it in the AAD
that'd be fine, but I'm puzzled as to what that reason may
be.
Cheers,
S.
…
That leaves `config_id`, which is... almost redundant. It's part of
ECHConfig which is already authenticated, *except* in the
[optional-`config_id`
mode](https://tlswg.org/draft-ietf-tls-esni/draft-ietf-tls-esni.html#name-optional-configuration-iden),
where it is otherwise unauthenticated. But it's also ignored so...
¯\\\_(ツ)\_/¯
|
@davidben what is "it" here? The AAD? That seems orthogonal to whether or not the HPKE context (and shared KEM secret) are reused for CH2. |
|
Sorry, yeah, that was unclear. By "it" I mean |
|
The reason to authenticate these things was to be as conservative as possible. Of course, we don't have any formal analysis that tells us whether or not it's strictly necessary. But given that single-shot HPKE isn't viable in this application, I'd suggest we keep it as-is. (Unless another reason to change this comes along :) |
|
@sftcd given that this is needed for HRR to avoid two KEM operations, are you comfortable closing this? |
|
(I almost missed this in today's torrent of githubbery...)
On 30/03/2021 19:36, Christopher Wood wrote:
@sftcd given that this is needed for HRR to avoid two KEM operations,
are you comfortable closing this?
Not sure. Given that HRR is rare and only needed because no
good group was chosen, (and hence involves more D-H stuff
in any case), I'm not clear that saving a KEM operation (in
the group for ECH) is a convincing target.
Is there a pointer anywhere to the analysis that such a
saving is not a premature optimisation? It may be an ok
design of course, but I wonder if a simpler yet less CPU
efficient design might exist and be overall better.
S.
PS: It also strikes me that if anyone ever designs a TLS
extension that contains a value (e.g. a time value) that
needs to be within an RTT of something external to the h/s,
then we're maybe breaking that before it's been invented.
|
|
Reusing the context is not just about performance. It also avoids a host of complexity and weird corner cases when ECH decryptions are RPC calls. It also reduces server complexity by not needing to check for the client picking a different ECHConfig the second time, etc. I would oppose regressing those complexity improvements. |
|
On 30/03/2021 22:40, David Benjamin wrote:
Reusing the context is not just about performance.
Fair enough.
It also avoids a
host of complexity and weird corner cases when ECH decryptions are
RPC calls.
Well, HRR+ECH seems to be it's own weirdly complex corner
case as a result though. But, that may be unavoidable.
It also reduces server complexity by not needing to reason
through what happens if the client picks a different ECHConfig the
second time, etc. I would oppose regressing those complexity
improvements.
I'll re-read the HRR proposal before the interim but if that
requires re-tx'ing the same set of inner extension values
(possibly other than inner.key-share?) then that itself may
be the cause of corner cases. (And break some putative
yet to be defined extensions maybe.)
Anyway, I think it makes sense to leave this issue open until
we're a bit more settled on HRR handling.
Cheers,
S.
|
|
@sftcd, now that #423 is merged, which reuses the HPKE context for HRR, which accepts that HRR must be dealt with in the protocol, along with @davidben's comment, I'd like to propose closing this. Any objections? |
|
On 11/06/2021 23:29, Christopher Wood wrote:
@sftcd, now that #423 is merged, which reuses the HPKE context for HRR, which accepts that HRR must be dealt with in the protocol, along with ***@***.***'s comment](#397 (comment)), I'd like to propose closing this. Any objections?
Reluctant acceptance here:-)
S
|
|
Sounds good -- thanks! |
This isn't critical but I think it might be better to allow use of a single-shot HPKE API that doesn't need to first and separately generate a public/private pair before calling Seal(). The downside of forcing two HPKE calls is perhaps mostly that someone will be tempted to re-use that key pair for something else or a 2nd attempt with maybe bad effects. If someone ever did HPKE in h/w there might also be a security difference.
I'm also not entirely sure what we're protecting by including that public value ("enc") in the AAD as well so that could be better documented at least, if we keep things as-is, but perhaps including that field is really a bit of overkill?
The text was updated successfully, but these errors were encountered: