In an attempt to close the loop here, I've pushed a new PR version with a
64-bit sentinel with the final byte being 00 for TLS 1.2 and 01 for TLS
1.3. If anyone strongly objects to this construction, please raise your
hand now.
Otherwise, I plan to merge this on Wednesday.
https://github.com/tlsw
On Monday, November 9, 2015 3:53 PM, Eric Rescorla wrote:
> In an attempt to close the loop here, I've pushed a new PR version with a
> 64-bit sentinel with
> the final byte being 00 for TLS 1.2 and 01 for TLS 1.3. If anyone strongly
> objects to this
> construction, please raise your hand now.
On Mon, Nov 9, 2015 at 4:30 PM, Christian Huitema
wrote:
> On Monday, November 9, 2015 3:53 PM, Eric Rescorla wrote:
> > In an attempt to close the loop here, I've pushed a new PR version with
> a 64-bit sentinel with
> > the final byte being 00 for TLS 1.2 and 01 for TLS 1.3. If anyone
> strongl
On Monday, November 9, 2015 4:34 PM, Eric Rescorla wrote:
> On Mon, Nov 9, 2015 at 4:30 PM, Christian Huitema
> wrote:
>
>...
>> Editorial: your proposed text says "...MUST set the first six bytes of its
>> Random value
>> to the the bytes 44 4F 57 4E 47 52 44 01." I assume you mean the first
On Mon, Nov 9, 2015 at 4:41 PM, Christian Huitema
wrote:
> On Monday, November 9, 2015 4:34 PM, Eric Rescorla wrote:
>
> > On Mon, Nov 9, 2015 at 4:30 PM, Christian Huitema
> wrote:
> >
> >...
> >> Editorial: your proposed text says "...MUST set the first six bytes of
> its Random value
> >> to
On Monday, November 9, 2015 4:44 PM, Eric Rescorla wrote:
> On Mon, Nov 9, 2015 at 4:41 PM, Christian Huitema
> wrote:
>> On Monday, November 9, 2015 4:34 PM, Eric Rescorla wrote:
>>> On Mon, Nov 9, 2015 at 4:30 PM, Christian Huitema
>>> wrote:
>...
Could you also add a reference to the do
Would the values chosen there have a calamitous impact on Mon, 24 Dec 2125
11:21:51 GMT? I think that's the epoch when a regular TLS1.2 server would
put that value in. I know it's 110 years in the future, but would it be
better to choose a value that's in the past?
On Mon, Nov 9, 2015 at 3:52 PM,
No, you're right and I'm off : that value is in the past. I was treating it
as a 64-bit epoch value. Bad me for having a 2038-ready timestamp
interpreter.
On Mon, Nov 9, 2015 at 5:20 PM, Eric Rescorla wrote:
> On Mon, Nov 9, 2015 at 5:15 PM, Colm MacCárthaigh
> wrote:
>
>>
>> Would the values
