Hiya,
> Hasn’t this been the whole point of the discussion?! The proposal to
> separate PRNGs into those that supply publicly-visible randomness
> (nonces, etc), and those that supply “secret” randomness (keying
> material and such)? Thus, having *two* PRNGs, each (hopefully)
> properly seeded?
>
From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Ben Schwartz
Sent: 31 October 2017 01:35
To: Richard Barnes
Cc:
Subject: Re: [TLS] New Version Notification for draft-friel-tls-over-http-00.txt
On Mon, Oct 30, 2017 at 7:02 PM, Richard Barnes
mailto:r...@ipv.sx>> wrote:
It requires awaren
> -Original Message-
> From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Stephen Farrell
> Sent: 30 October 2017 22:56
> To: Richard Barnes ;
> Subject: Re: [TLS] New Version Notification for
> draft-friel-tls-over-http-00.txt
>
>
>
> On 30/10/17 22:17, Richard Barnes wrote:
> >
Hi Owen,
On 31/10/17 21:03, Owen Friel (ofriel) wrote:
>> Interesting. One bit puzzles me: wouldn't the new content-type
>> give the game away and cause middleboxes to block this?
>>
>> S.
>>
> [ofriel] The intention isn’t to try and obscure the fact that there
> is an ATLS session. Even if th
(From https://github.com/tlswg/dtls13-spec/issues/25)
Using the TLS process for KeyUpdate - as the current draft does -
leads to a suboptimal set of choices in implementations.
Sending KeyUpdate followed immediately by a key change means that
KeyUpdate isn't a reliable indicator of a key change a