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

2017-01-09 Thread Kurt Roeckx
On Mon, Jan 09, 2017 at 02:55:57PM -0500, Adam Langley wrote: > On Mon, Jan 2, 2017 at 3:57 PM, Adam Langley wrote: > > I don't expect that those who want to intercept TLS connections will > > see a MUST NOT and go do something else. Rather I think they should > >

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

2017-01-09 Thread Adam Langley
On Mon, Jan 2, 2017 at 3:57 PM, Adam Langley wrote: > I don't expect that those who want to intercept TLS connections will > see a MUST NOT and go do something else. Rather I think they should > understand that TLS isn't supposed to be intercepted and, if they want > to

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

2017-01-02 Thread Adam Langley
On Mon, Jan 2, 2017 at 11:43 AM, Yoav Nir wrote: > I’m assuming that the server generates private keys and saves them to a file > along with the time period that they were used, and another machine in a > different part of the network records traffic. It’s not so much that

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

2017-01-02 Thread Colm MacCárthaigh
On Mon, Jan 2, 2017 at 11:43 AM, Yoav Nir wrote: > I’m assuming that the server generates private keys and saves them to a > file along with the time period that they were used, and another machine in > a different part of the network records traffic. It’s not so much that

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

2017-01-02 Thread Yoav Nir
> On 2 Jan 2017, at 20:59, Eric Rescorla wrote: > > > > On Mon, Jan 2, 2017 at 8:58 AM, Yoav Nir > wrote: >> >> . >> >> Since I think the utility of this falls off as a reciprocal, I'll try >> making a concrete suggestion

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

2017-01-02 Thread Eric Rescorla
On Mon, Jan 2, 2017 at 8:58 AM, Yoav Nir wrote: > On 31 Dec 2016, at 20:36, Adam Langley wrote: > > Consider the motivations here: > > 1) We know that some implementations have gotten this wrong with TLS > 1.2 and cached values for far too long.

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

2017-01-02 Thread Ilari Liusvaara
On Mon, Jan 02, 2017 at 06:58:36PM +0200, Yoav Nir wrote: > > Still, if we want to accommodate the banking industry (or whatever > part of it we’ve talked to in Seoul), then they need to be able to > tell based on a timestamp which private key was used for that handshake. > With 60 seconds key

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

2017-01-02 Thread Eric Rescorla
Yoav, Thanks for pointing to this PR. Clearly we're only going to land one of these. One thing I wanted to note, as discussed in the comments on that PR, is that at least some of the proofs of security of TLS 1.3 assume that both sides use fresh DH shares. In TLS 1.3, of course, the nonces

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

2017-01-02 Thread Hugo Krawczyk
Typo correction below. On Jan 1, 2017 12:43 PM, "Hugo Krawczyk" wrote: There is more than one way to "backdoor" the use of DH (i.e., to not enforce forward secrecy) and some of these ways are completely undetectable (in particular, they would not repeat DH values). One

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

2017-01-01 Thread Peter Gutmann
Hugo Krawczyk writes: >there may be applications with legitimate reasons not to use FS. It's not so much reasons not to use FS (well, there are some specialised cases where people want to do that as well), it's reasons to reuse (EC)DH values. This isn't something that

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

2017-01-01 Thread Dan Brown
I agree run-time detection of a peer's re-use does not solve much. Sent from my BlackBerry 10 smartphone on the Rogers network. From: Hugo Krawczyk Sent: Sunday, January 1, 2017 12:43 PM To: Adam Langley Cc: tls@ietf.org Subject: Re: [TLS] [SUSPECTED URL!]Re: Requiring that (EC)DHE public values

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

2017-01-01 Thread Hugo Krawczyk
There is more than one way to "backdoor" the use of DH (i.e., to not enforce forward secrecy) and some of these ways are completely undetectable (in particular, they would not repeat DH values). One has to be careful not to give a false sense of security by the illusion that not detecting DH