Draft: draft-ietf-quic-tls

Commentary: Also , examples use final version numbers . IMPORTANT : the TLS extension codepoint needs to be updated , both in the text and in the examples ( which will result in changes to authentication tags and the affected ciphertext ) . 
 I plugged the test vectors into the quiche test suite and it checks out 
 Hey there ! We are currently implementing the Initial packet encryption process and it successfully works with the client Initial example from the appendix A.2 of the QUIC - TLS draft . However , when running tests with values for the server Initial example from the appendix A.3 , tests regarding the parsing , header sampling , header protection and final encryption result all succeed , except for the header protection mask : the value we generate is : , while the draft explicitly specifies it should be something completely different : . Note that the value we generate is indeed used later on for the header protection and final encryption result , which both reveal successful . Therefore , three possibilities we thought of , in ascending order of probability : Our implementation is completely broken . The mask value provided by the current version of the specification ( A.3 ) is correct , but all others are incorrect . Only the mask value is incorrect , while the rest is correct . We think the last option is the most probable one , as it could just mean it was forgotten to be updated in a recent draft version . If you think this is the case as well , then I would gladly open up a PR in order to close this , I just wanted to make sure beforehand . Otherwise , I would happily accept a tad of guidance towards a correct implementation . Thanks in advance ,  . 
 Investigated a bit more . Looking at the result of a , we can see that : is indeed meant to update example vectors , but does it only partially it seems : while is for other secrets , but did it completely . So it should confirm our hypothesis . 
 hi Our editors are taking some slight respite , we 'll respond soon . 
 No problem I was just adding some more information I forgot to mention yesterday . Thanks for the heads up : +1 : 
 It seems to me that the header is not correct . Thoughts ? 
 For me the header looks fine : it is consistent with the final result . What looks wrong to you 
 I 'll assign this to since I think that is his code . 
 I can confirm this , but it wo n't matter as  will have new values entirely . The mask value should be for the second example . 
 would you link this issue to the PR that will update the values for  so it gets closed then ? 
 New values seem to work in my testing .
Paragraph (version A):
This secret is determined by using HKDF-Extract (see Section 2.2 of
HKDF) with a salt of 0xafbfec289993d24c9e9786f19c6111e04390a899 and a
IKM of the Destination Connection ID field.  This produces an
intermediate pseudorandom key (PRK) that is used to derive two
separate secrets for sending and receiving.
Paragraph (version B):
This secret is determined by using HKDF-Extract (see Section 2.2 of
HKDF) with a salt of 0x38762cf7f55934b34d179ae6a4c80cadccbb7f0a and a
IKM of the Destination Connection ID field.  This produces an
intermediate pseudorandom key (PRK) that is used to derive two
separate secrets for sending and receiving.
Paragraph (version A):
The secret key, K, is 128 bits equal to
0xccce187ed09a09d05728155a6cb96be1.
Paragraph (version A):
The nonce, N, is 96 bits equal to 0xe54930f97f2136f0530a8c1c.
Paragraph (version B):
The secret key, K, is 128 bits equal to
0xbe0c690b9f66575a1d766b54e368c84e.
Paragraph (version B):
The nonce, N, is 96 bits equal to 0x461599d35d632bf2239825bb.
Paragraph (version A):
The secret key and the nonce are values derived by calling HKDF-
Expand-Label using
0x8b0d37eb8535022ebc8d76a207d80df22646ec06dc809642c30a8baa2baaff4c as
the secret, with labels being "quic key" and "quic iv" (protection-
keys).
Paragraph (version B):
The secret key and the nonce are values derived by calling HKDF-
Expand-Label using
0xd9c9943e6101fd200021506bcc02814c73030f25c79d71ce876eca876e6fca8e as
the secret, with labels being "quic key" and "quic iv" (protection-
keys).
Paragraph (version A):
This document registers the quic_transport_parameters extension found
in quic_parameters in the TLS ExtensionType Values Registry TLS-
REGISTRIES.
Paragraph (version B):
IANA has registered a codepoint of 57 (or 0x39) for the
quic_transport_parameters extension (defined in quic_parameters) in
the TLS ExtensionType Values Registry TLS-REGISTRIES.