Re: [quicwg/base-drafts] Tls restore compat (#1256)

[Martin Thomson <[e-mail]>]

martinthomson commented on this pull request.

I'm not a fan of making this sort of change.  It seems that it's a product of the idiosyncratic API provided by picotls more than anything else.  

Don't take that as an indictment on the goals of the API.  I really like the idea that the details of determining keys and IVs are kept contained.  I only wish that NSS were anywhere near as principled.  We have to break the PKCS#11 boundary to get HKDF to work.

For mine, a more principled AEAD API would take two labels: one for the key and one for the label, and avoid baking in the specific details of the TLS HKDF info structure.  A hacky API change could distinguish between a NULL hash and an empty hash.

In summation, I'd prefer not to have to explain to future users of QUIC that this isn't a null terminator on the string, but a product of a design decision made before QUIC even really existed.

> @@ -703,12 +703,13 @@ structure:
 struct {
    uint16 length = Length;
    opaque label<6..255> = "QUIC " + Label;
+   uint8 hashLength = 0;

This needs to be explained, or people will ask why the hash is zero length.

-- 
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/pull/1256#pullrequestreview-109208113