Fwd: Re: Bug in PKCS#11 HKDF section

[Robert Relyea <rrelyea@REDHAT.COM>]

-------- Forwarded Message --------

Subject:	Re: Bug in PKCS#11 HKDF section
Date:	Fri, 18 Oct 2019 11:12:34 -0700
From:	Martin Thomson <mt@lowentropy.net>
To:	Robert Relyea <rrelyea@redhat.com>

2.13.5 AES GCM and CCM Mechanism parameters has a typo:

typedef CK_ULONG CK_GENERATOR_FUCNTION;

Also, you can add 0x00 to the end of the strings I mentioned below.  The `context` field will be zero-length.

On Fri, Oct 18, 2019, at 10:55, Martin Thomson wrote:
> In Section 2.62.3 HKDF derive from here:
> https://docs.oasis-open.org/pkcs11/pkcs11-curr/v3.0/csprd01/pkcs11-curr-v3.0-csprd01.html#_Toc10561293
> 
> > All tokens must minimally support bExtract set to true and bInfo values which start with the value âtls1.3 viâ.  
> 
> There is a typo here (it's "iv", not "vi"), but that would not be 
> enough.  The bInfo parameter to HKDF-Expand in TLS 1.3 takes a 
> structure in the format:
> 
>        struct {
>            uint16 length = Length;
>            opaque label<7..255> = "tls13 " + Label;
>            opaque context<0..255> = Context;
>        } HkdfLabel;
> 
> Therefore, the string to look for is 0xLLLL08 + "tls13 iv", because the 
> leading `length` field (which corresponds to the size of the IV, 
> generally 12 bytes, or 0x000c) and the length that precedes the `label` 
> field.
> 
> Also, QUIC uses the same format with a label of "tls13 quic iv", so the 
> string to look for would be there is 0xLLLL0d + "tls13 quic iv".
> 
> See https://tools.ietf.org/html/rfc8446#section-7.1 and 
> https://quicwg.org/base-drafts/draft-ietf-quic-tls.html#protection-keys