On Tue, Jul 25, 2017 at 6:21 PM, Christian Huitema wrote:
>
>
> On 7/25/2017 4:57 PM, Peter Gutmann wrote:
>
> Also, when we make such a recommendation in the TLS spec, we can hope that
> it
> will be heeded by the TLS developers, but what about the developers of
> applications and protocols sitti
On 7/25/2017 4:57 PM, Peter Gutmann wrote:
>> Also, when we make such a recommendation in the TLS spec, we can hope that it
>> will be heeded by the TLS developers, but what about the developers of
>> applications and protocols sitting on top of TLS, such DTLS, QUIC or HTTP?
> They don't need to
Agreed it is basically an aesthetic change.
Thanks,
Xuelei
On Tue, Jul 25, 2017 at 4:58 PM Eric Rescorla wrote:
> Given that this document has been through 2 WGLCs, and this is basically
> an aesthetic change, I don't think it gets over the barrier.
>
> -Ekr
>
>
> On Tue, Jul 25, 2017 at 4:48 P
Given that this document has been through 2 WGLCs, and this is basically an
aesthetic change, I don't think it gets over the barrier.
-Ekr
On Tue, Jul 25, 2017 at 4:48 PM, Xuelei Fan wrote:
> Hi,
>
> The TLS 1.3 Certificate handshake message is defined as:
>
>struct {
>opaque certi
Christian Huitema writes:
>For one thing, it conflicts with the general advice that developers should
>not invent their own PRNG,
You're not inventing your own PRNG, you're using the TLS PRF, or some
equivalent (I use PBKDF2, HKDF is also nice).
>and should use a good crypto RNG when available
Hi,
The TLS 1.3 Certificate handshake message is defined as:
struct {
opaque certificate_request_context<0..2^8-1>;
CertificateEntry certificate_list<0..2^24-1>;
} Certificate;
certificate_request_context If this message is in response to a
CertificateRequest, the v
On Jul 25, 2017, at 01:29, Kazu Yamamoto (山本和彦) wrote:
>> 3. Change the definition of `select`'s `case` statements to have 0 or more
>> fields (types and names) and remove the optional label.
>> 4. Change the `select` example to match the new definition.
>
> I agree if this means 1 or more. (S
On 7/25/2017 5:20 AM, Stephen Farrell wrote:
> I guess you mean this:
>
> "
>TLS-LTS drops the requirement to generate the Client.random and
>Server.random using "a secure random number generator", typically the
>one used to generate encryption keys. The use of a secure/
>cryptog
On Mon, Jul 24, 2017 at 11:15 AM, Stephen Farrell
wrote:
>
>
> Hiya,
>
> I'm guessing many folks interested in TLS may have been
> at the QUIC session in Prague and hence missed out on the
> excellent talk by Stephen Checkoway on the juniper dual-ec
> incident. (I highly recommend taking a peek at
On 25/07/17 04:53, Peter Gutmann wrote:
> Colm MacCárthaigh writes:
>
>> I think the fix for this is really at the application level; if you
>> want defense-in-depth against PRNG problems, it's probably best to use
>> separate RNG instances for public data (e.g. client_random,
>> server_rand
10 matches
Mail list logo
