Hi Rich, and thanks for your review! Responses inline.
David
On Mon, Sep 9, 2024 at 10:29 AM Rich Salz via Datatracker <noreply@ietf.org>
wrote:
> Reviewer: Rich Salz
> Review result: Has Issues
>
> I don't think anything here is a serious issue, but they would be enough to
> raise a DISCUSS in my view.
>
> Concealed doesn't seem like a great name for the mechanism, as nothing
> about it
> is hidden. Perhaps TLS-Export or something along those lines? Although I
> guess
> Sec 8 gives a reasonable rationale.
>
As much as I appreciate your suggestion, we're going to keep the bikeshed
in its
current color. We discussed this at length as a working group and landed on
something that everyone can live with, so we'll stick with that.
Sec 2. "mapping of authorized key IDs to their associated public keys." The
> antecedent for "their" should be more clear.
>
Good point. I removed the word "their":
[2] https://www.rfc-editor.org/rfc/rfc8446.html#section-4.2.3
Sec 5. It would be nice to have an example showing a realm. And nice to have
> the private key disclosed so that implementors can use this as a test
> vector.
>
Unfortunately test vectors aren't very useful when it comes to TLS
exporters,
because the exporter depends on random data from the TLS handshake.
Because of this, we made the conscious decision to not include them.
Given this uses TLS exporting and such, and that this is likely to be in a
> TLS
> library (maybe that's wrong), what was the reasoning for not using TLS
> presentation syntax?
>
This is not implemented inside TLS libraries. All implementations were made
by modifying the HTTP layer without touching TLS code. Hence the use of
QUIC syntax and not TLS, as was done in HTTP/3.
Figure 2. Same point about the (256) notation and question about TLS
> presentation syntax
>
Same answer.
Sec 3.3, to emphasize my notation point, this says all 32 bytes (and it
> should
> be *each* of its 32 bytes), but the data structure is defined in bits.
>
You're correct, QUIC notation is in bits but prose is generally in bytes.
Sec 4.1, "This can be used to point to a server-side database". That seems
> to
> be implied/mandated by Sec 2 and my comment on it.
>
Good point. I've fixed this to now say "This is used by the backend to
point to an entry in a server-side database of known keys" and added a
reference to s6.3:
Received on Monday, 9 September 2024 18:58:41 UTC