Re: [TLS] Requiring that (EC)DHE public values be fresh

2016-12-29 Thread Brian Smith
Adam Langley wrote: > Since this defeats forward security, and is clearly something that > implementations of previous versions have done, this change > specifically calls it out as a MUST NOT. Implementations would then be > free to detect and reject violations of this.

Re: [TLS] cross-domain cache sharing and 0rtt (was: Re: Requiring that (EC)DHE public values be fresh)

2016-12-29 Thread Adam Langley
On Thu, Dec 29, 2016 at 11:08 AM, Eric Rescorla wrote: >> >> As an individual, I'd be in favour of this change but reading >> >> over [1], section 5, I wondered if we'd analysed the effects of >> >> 0rtt/replayable-data with that kind of cross-domain re-use in mind? >> >> The

Re: [TLS] Requiring that (EC)DHE public values be fresh

2016-12-29 Thread Adam Langley
On Thu, Dec 29, 2016 at 11:28 AM, Martin Rex wrote: > First of all, forward secrecy is equally defeated by TLS session caching > (traditional as well as session tickets), and the effect of rfc5077 > TLS session tickets is likely at least a magnitude worse--and cannot > be "fixed" by

Re: [TLS] Requiring that (EC)DHE public values be fresh

2016-12-29 Thread Martin Rex
Adam Langley wrote: > > https://github.com/tlswg/tls13-spec/pull/840 is a pull request that > specifies that (EC)DH values must be fresh for both parties in TLS > 1.3. > > For clients, this is standard practice (as far as I'm aware) so should > make no difference. For servers, this is not always

Re: [TLS] cross-domain cache sharing and 0rtt (was: Re: Requiring that (EC)DHE public values be fresh)

2016-12-29 Thread Eric Rescorla
On Thu, Dec 29, 2016 at 10:50 AM, Stephen Farrell wrote: > > > On 29/12/16 18:38, Eric Rescorla wrote: > > On Thu, Dec 29, 2016 at 10:15 AM, Stephen Farrell < > stephen.farr...@cs.tcd.ie > >> wrote: > > > >> > >> Hiya, > >> > >> On 29/12/16 17:37, Adam Langley wrote:

[TLS] cross-domain cache sharing and 0rtt (was: Re: Requiring that (EC)DHE public values be fresh)

2016-12-29 Thread Stephen Farrell
On 29/12/16 18:38, Eric Rescorla wrote: > On Thu, Dec 29, 2016 at 10:15 AM, Stephen Farrell > wrote: > >> >> Hiya, >> >> On 29/12/16 17:37, Adam Langley wrote: >>> https://github.com/tlswg/tls13-spec/pull/840 is a pull request that >>> specifies that (EC)DH values

Re: [TLS] Requiring that (EC)DHE public values be fresh

2016-12-29 Thread Eric Rescorla
On Thu, Dec 29, 2016 at 10:15 AM, Stephen Farrell wrote: > > Hiya, > > On 29/12/16 17:37, Adam Langley wrote: > > https://github.com/tlswg/tls13-spec/pull/840 is a pull request that > > specifies that (EC)DH values must be fresh for both parties in TLS > > 1.3. > > >

[TLS] Requiring that (EC)DHE public values be fresh

2016-12-29 Thread Adam Langley
https://github.com/tlswg/tls13-spec/pull/840 is a pull request that specifies that (EC)DH values must be fresh for both parties in TLS 1.3. For clients, this is standard practice (as far as I'm aware) so should make no difference. For servers, this is not always the case: Springall, Durumeric &

Re: [TLS] PR#837: Forward and backward secrecy

2016-12-29 Thread Guballa Jens (ETAS-PSC/ECS)
> > > My understanding: > > A compromised long term key does not compromise captured future traffic > => forward secrecy (provided by (EC)DHE) > > This is not correct. Forward-secrecy is the below, not the above. [JG] I did not say clearly what I meant. :-) For my statement I set the presence