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 provide freshness [0], so intuitively reuse of DH shares should only threaten FS, however, an claims that that's actually the case should come with some analytic support. If reuse is forbidden than no such support is needed. -Ekr [0] See SIGMA page 24 for a bit more on this topic. On Mon, Jan 2, 2017 at 8:58 AM, Yoav Nir <ynir.i...@gmail.com> wrote: > On 31 Dec 2016, at 20:36, Adam Langley <a...@imperialviolet.org> 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. Presumably if they were to be > naively extended to TLS 1.3 this issue would carry over. > > 2) We probably disagree with this banking industry desire to be able > to backdoor their TLS connections, but we're not the police and fixing > DH values is probably how they would do it. If it's going to be A > Thing then it's much more likely that things will get misconfigured > and it'll be enabled in places where it shouldn't be. If we have no > detection mechanism then what we'll probably end up with is a Blackhat > talk in a few years time about how x% of banks botched forward > security at their frontends. > > Say that a value of an hour makes sense for some device and we feel > that an hour's forward-security window is reasonable for security. The > issue is that it significantly diminishes our detection ability > because clients need to remember more than an hour's worth of values > and I don't know if we can dedicate that amount of storage to this. > > Since I think the utility of this falls off as a reciprocal, I'll try > making a concrete suggestion for a time limit: 10 seconds. > > > I like this number, because that’s the number I chose when I implemented > ECDH caching in Check Point’s TLS library. It makes key generation rare > enough that it makes no difference for server load in any normal hardware, > and frequent enough that if you destroy the keys after they are last used > then attackers have a very narrow window of opportunity to get your keys. > Especially if they need to get a warrant. IoT may be abnormal hardware in > that regard. > > 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 changes are rare enough that there are at most two possibilities which > I think is manageable. With 10 seconds clock skew can ruin your system. > But I realize I’m bike shedding here. > > On 2 Jan 2017, at 6:09, Peter Gutmann <pgut...@cs.auckland.ac.nz> wrote: > > Hugo Krawczyk <h...@ee.technion.ac.il> 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 was ever mentioned in the spec, it's what > developers > have implemented themselves in order to deal with high-load conditions. > This > also means that no matter what the spec might say in the future, if you've > got > a developer facing a situation where they need 480% of available CPU to > service requests then they're going to do things like cache (EC)DH, > regardless > of what the spec says. So making it a MUST NOT will end up as what > someone on > PKIX once described as "workgroup posturing". Better to include an > advisory > note on using it, > > > Well, it just so happens… > https://github.com/tlswg/tls13-spec/pull/768/files > > Yoav > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
