Hi,
I'm trying to implement channel bindings defined RFC 5929.
I have three questions:
Q1) "tls-unique" is defined as "The first TLS Finished message sent
(note: the Finished struct, not the TLS record layer message
containing it)"
Is it excluding HandshakeType and the length of the
Hi Stephen,
> Initially, I thought proposal I would be the best, but now I have a
> mild preference for proposal III. I think it makes the language
> simpler over all. It essentially becomes two primitive types
> (`opaque` and `uint8`) and four type definitions:
I like III, too. But I don't
Hi Stephen,
Thank you for your nice work.
> Concretely, I think we should make the following changes.
> 1. Replace `length` with `TLSCiphertext.length` in the definition of
> `TLSCiphertext`.
I agree.
> 2. Replace `Hash.length` with `hash_length` throughout (9 instances).
I agree.
> 3.
Hi Matt,
You might be also interested in this issue:
https://github.com/tlswg/tls13-spec/issues/1040
--Kazu
> I note in draft-21 the following text:
>
>When clients use a PSK obtained externally to send early data, then
>the following additional information MUST be provisioned to both
>>HKDF-Expand-Label(Secret, Label, *Value*, Length) =
>> HKDF-Expand(Secret, HkdfLabel, Length)
>>
>>struct {
>>uint16 length = *Value.length*;
>>opaque label<7..255> = "tls13 " + Label;
>>opaque hash_value<0..255> = *Value*;
>>
>> I think that would be best. With the change to the transcript hash,
>> the context would then be:
>> 1. a transcript hash (size = hash function output)
>> 2. 0 (size = 0)
>> 3. ticket nonce (size = 1..255)
>>
>
> Yeah, I can do a PR for this.
HKDF-Expand-Label(Secret, Label,
Hi Nick,
> At the TRON workshop at NDSS there was interest in a hackathon project to
> work on TLS 1.3 implementations and to test interoperability. I have added
> this as a topic for the IETF 95 Hackathon. If you are interested in
> participating, please sign up here:
Which is this hackathon
> That's what we do in Chrome/BoringSSL. We send one fake NamedGroup at the
> front of supported_groups and then put it in key_shares with a one-byte
> fake KeyShareEntry.
>
> It costs five bytes total and, having already caught a bug with it, seems
> valuable. It ensures that servers are capable
Hi David,
> I was thinking of making the following changes:
>
> - Cite TLS 1.3 instead of TLS 1.2.
>
> - Add some text to use the same code point pattern for TLS 1.3
> signature_algorithms.
>
> - Add some text to suggest advertising GREASE values in key_shares if
> advertised in
Hello Martin,
> I've updated the test vectors draft.
>
> The vectors should now be correct with respect to draft-18. I
> implemented exporters as well, so calculations for those are now
> shown.
Thank you for very useful document.
I would be nice if this example includes secp256r1 instead of
10 matches
Mail list logo
