Re: [TLS] Do we actually need semi-static DHE-based 0-RTT?

On Thursday, February 18, 2016 08:04:05 pm Eric Rescorla wrote: > PUBLISHED CONFIGURATIONS > The semi-static mode in principle allows the server to publish its > configuration (i.e., it's semi-static key), e.g., via DNS, which the > client can then use for 0-RTT handshakes on first contact.

Re: [TLS] Proposal: Simplified Key Schedule

I agree that once you remove the requirement to derive a key from g^xy (=ES) for protecting a static DH key then the KDF scheme can be simplified as shown (or even further - see below). Note that this is (almost) exactly the original KDF scheme of OPTLS as I presented in Dallas

[TLS] Do we actually need semi-static DHE-based 0-RTT?

TL;DR. Should we remove the semi-static DHE 0-RTT mode and just leave the PSK and PSK-DHE 0-RTT modes? DETAIL This is the last in the series of messages about changes to consider. TLS 1.3 currently supports two 0-RTT modes: - A semi-static Diffie-Hellman mode in which the server provides a

[TLS] Proposal: Simplified Key Schedule

Hi folks, TL;DR. Let's simplify the key schedule. DETAILS This is the second in a series of proposed simplifications to TLS 1.3 based on implementation experience and analysis once the protocol starts to harden. The following suggestion comes out of conversations with Richard Barnes, Karthik

[TLS] tls - New Meeting Session Request for IETF 95

A new meeting session request has just been submitted by Sean Turner, a Chair of the tls working group. - Working Group Name: Transport Layer Security Area Name: Security Area Session Requester: spt Number of Sessions: 1 Length of

Re: [TLS] Proposal: don't change keys between handshake and application layer

I want to point out that the benefits of using the application key output by the handshake protocol also for handshake traffic protection are not clear cut. I cannot comment at the level of implementation simplification that motivates this change but I can comment on the cryptographic implications

Re: [TLS] JPAKE

On Tue, Feb 16, 2016 at 12:33:56AM +, Robert Cragie wrote: > The big assumption here is that SSL/TLS is used solely in browsers. That is > not how it is being used in Thread, for example, and indeed in other > similar technologies. In Thread, it is used for local device authentication > and

Re: [TLS] Proposal: don't change keys between handshake and application layer

On Thu, Feb 18, 2016 at 7:32 AM, Wan-Teh Chang wrote: > On Wed, Feb 17, 2016 at 7:49 PM, Eric Rescorla wrote: > > > > TL;DR. > > I propose that we should not change keys between the handshake > > and application traffic keys. > > Hi Eric, > > I'm not sure if I

Re: [TLS] Proposal: don't change keys between handshake and application layer

On Wed, Feb 17, 2016 at 08:49:33PM -0700, Eric Rescorla wrote: > Hi folks, > > TL;DR. > I propose that we should not change keys between the handshake > and application traffic keys. > > The general idea is that there is no strong security reason to change > change keys between handshake and