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

On Mon, Jan 2, 2017 at 8:58 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:

> On 31 Dec 2016, at 20:36, Adam Langley <agl@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.
>

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 <pgut001@cs.auckland.ac.nz> wrote:
>
> Hugo Krawczyk <hugo@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
>
>