In the room last week, I hummed for "TLS 4".
that said, I overall agree with Andrei's sentiment..
> I'm voting in favor of any re-branding of TLS 1.3 where the
> protocol name remains "TLS" and major version becomes > 1.
HTH,
=JeffH
+10k
Rich Salz responded:
> DKG proposed:
>> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml
>> doesn't have a "TLS version" registry. Would it be simpler to have IANA
>> create that and just populate it with:
>>
>>Value | Description | Reference
>>--+---
t; tls-unique. The 1.3 key schedule appears to be under discussion, so
> things might change.
Thanks Andrei, the above confirms my own assessment/suspicions.
=JeffH
> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of =JeffH
> Sent: Tuesday, February 23,
Stephen replied:
> On 23/02/16 23:29, =JeffH wrote:
>> is anyone writing up some notes from TRON
>>
<https://www.internetsociety.org/events/ndss-symposium-2016/tls-13-ready-or-not-tron-workshop-programme>
>> to share here on the list?
>>
>> especially wr
Hi Ilari,
Ilari replied on Wed, 17 Feb 2016:
> On Wed, Feb 17, 2016 at 11:25:12AM -0800, =JeffH wrote:
>> Hi,
>>
>> RFC5705 section 4 "Exporter Definition" [1] states..
>>
>>The exporter takes three input values:
>>
>>o a disambigua
is anyone writing up some notes from TRON
<https://www.internetsociety.org/events/ndss-symposium-2016/tls-13-ready-or-not-tron-workshop-programme>
to share here on the list?
especially wrt the "What do we know and where are we going?" topic :)
inquiring minds and all
hemeral Secret, but I am not able discern such a definition
(unlike the clear definitions for xSS, xES, etc in S 7.1).
thanks,
=JeffH
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
exporter master secret",
handshake_hash, L)
[...]
..i.e., does the above step "8." effectively define the TLS 1.3 keying
material exporter?
thanks,
=JeffH
[1] https://tools.ietf.org/html/rfc5705#section-4
[2] https://tools.ietf.or
lient Write Key | "client write key" |
| ||
| Server Write Key | "server write key" |
[...]
+--++
thx,
=JeffH
[1] https://
ON Fri, 22 Jan 2016 15:53:27 Benjamin Kaduk noted:
> On 01/22/2016 03:26 PM, =JeffH wrote:
> > On 01/22/2016 12:29 PM, =JeffH wrote:
> >> [ fixed pitch font advised here ]
> >
> > the below is corrected to use "byte count" rather than "in
On 01/22/2016 12:29 PM, =JeffH wrote:
[ fixed pitch font advised here ]
the below is corrected to use "byte count" rather than "index" or "indicies"
(and to ditch the tabs)..
> On 01/22/2016 09:42 AM, =JeffH wrote:
> > [ resending from different
[ fixed pitch font advised here ]
> On 01/22/2016 09:42 AM, =JeffH wrote:
> > [ resending from different account - my work addr ends up in spam
> > bucket for many it seems ]
> >
> > On 1/20/16, 11:01 AM, "Benjamin Kaduk" wrote:
> > >On 01/20/2016 1
the 2-byte length field, with length value zero, and a
zero-length (ie, absent, empty) vector content, correct ?
thanks,
=JeffH
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
eld followed by 128 bytes of data).
>
>Wouldn't the ceiling more properly be 2^16-4 in that case?
hm, I'm not sure -- what would be the rationale? The exact multiple
criteria? but 2^16 / 32 = 2048 while (2^16-4) / 32 = 2047.875
i do have further questions regarding variable-length vectors, and how
they are specified, that subsequent discussion will hopefully tease out.
thanks,
=JeffH
___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
14 matches
Mail list logo
