On Mon, Jan 2, 2017 at 8:58 AM, Yoav Nir <[email protected]> wrote:
> On 31 Dec 2016, at 20:36, Adam Langley <[email protected]> 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. > Yoav, Why do you need a precise clock here? If you're going to retrospectively decrypt, you are going to need a list of all the private keys, so why can't you just index that by the public key in the handshake? -Ekr On 2 Jan 2017, at 6:09, Peter Gutmann <[email protected]> wrote: > > Hugo Krawczyk <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/tls > >
_______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
