On 07/03/2017 07:01 PM, Eric Rescorla wrote:
> Currently the extension table says that server_certificate_type goes
> in the Certificate message, whereas client_certificate_type does
> not. My reasoning for the latter is that the extensions are attached
> to individual certificate elements, so it w
On 4 July 2017 at 01:01, Eric Rescorla wrote:
> Hi folks,
>
> I just published draft-21, which incorporates the discussions we've
> been having about 0-RTT replay.
FYI, OpenSSL master branch is now draft-21 compliant.
Matt
___
TLS mailing list
TLS@iet
On 5 July 2017 at 11:35, Eric Rescorla wrote:
>
> Yes, that might not be a terrible idea. I'd also be open to replacing
> the hashes of 0 with an n-byte length 0 string. It's a tiny paper
> cut (and a wire format change), but would make things slightly simpler .
I'm not entirely sure what you me
On Wed, Jul 5, 2017 at 9:11 PM, Martin Thomson
wrote:
> We need the length field so that calling the function with different
> lengths results in different outputs. Not that anyone should be doing
> that, of course.
>
The reason for this is that an adversarial application might do so.
Say you
We need the length field so that calling the function with different
lengths results in different outputs. Not that anyone should be doing
that, of course.
On 6 July 2017 at 14:06, Kazu Yamamoto wrote:
>>>HKDF-Expand-Label(Secret, Label, *Value*, Length) =
>>> HKDF-Expand(Sec
>>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*;
>>
On 6 July 2017 at 12:19, Kazu Yamamoto wrote:
> The definitions would be:
>
>HKDF-Expand-Label(Secret, Label, *Value*, Length) =
> HKDF-Expand(Secret, HkdfLabel, Length)
>
>struct {
>uint16 length = *Value.length*;
>opaque label<7..255> = "tls13
>> 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, HashValue,
On Wed, Jul 5, 2017 at 2:14 PM, Martin Thomson
wrote:
> On 5 July 2017 at 20:35, Eric Rescorla wrote:
> > Yes, that might not be a terrible idea. I'd also be open to replacing
> > the hashes of 0 with an n-byte length 0 string. It's a tiny paper
> > cut (and a wire format change), but would make
On 5 July 2017 at 20:35, Eric Rescorla wrote:
> Yes, that might not be a terrible idea. I'd also be open to replacing
> the hashes of 0 with an n-byte length 0 string. It's a tiny paper
> cut (and a wire format change), but would make things slightly simpler .
I think that would be best. With th
On Wed, Jul 5, 2017 at 1:40 AM, Matt Caswell wrote:
> On 4 July 2017 at 11:50, Ilari Liusvaara wrote:
> > On Tue, Jul 04, 2017 at 11:25:35AM +0100, Matt Caswell wrote:
> >> On 4 July 2017 at 01:01, Eric Rescorla wrote:
> >> > - Modifying the key derivation for PSKs so that each session ticket
>
On 4 July 2017 at 11:50, Ilari Liusvaara wrote:
> On Tue, Jul 04, 2017 at 11:25:35AM +0100, Matt Caswell wrote:
>> On 4 July 2017 at 01:01, Eric Rescorla wrote:
>> > - Modifying the key derivation for PSKs so that each session ticket
>> > is associated with a distinct PSK.
>>
>> Draft-21 says t
On Mon, Jul 03, 2017 at 05:01:55PM -0700, Eric Rescorla wrote:
> I wanted to call the WG's attention to one issue:
>
> Currently the extension table says that server_certificate_type goes
> in the Certificate message, whereas client_certificate_type does
> not. My reasoning for the latter is that
On Tue, Jul 04, 2017 at 11:25:35AM +0100, Matt Caswell wrote:
> On 4 July 2017 at 01:01, Eric Rescorla wrote:
> > - Modifying the key derivation for PSKs so that each session ticket
> > is associated with a distinct PSK.
>
> Draft-21 says this about the ticket nonce:
>
> opaque ticke
On 4 July 2017 at 01:01, Eric Rescorla wrote:
> - Modifying the key derivation for PSKs so that each session ticket
> is associated with a distinct PSK.
Draft-21 says this about the ticket nonce:
opaque ticket_nonce<1..255>;
...
ticket_nonce A unique per-ticket value.
Within wh
On 4 July 2017 at 11:38, Eric Rescorla wrote:
>1. Clients ending 0-RTT data as described in Section 4.2.9.
Typo: ending.
Otherwise, this matches my understanding nicely.
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
One more thing I wanted to note. The section about when you could receive
prior to Finished was a bit confused. I rewrote it as follows.
Once a side has sent its Finished message and received and validated
the Finished message from its peer, it may begin to send and receive
application da
17 matches
Mail list logo
