sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] TLS 1.3 and HKPS pool


From: Daniel Kahn Gillmor
Subject: Re: [Sks-devel] TLS 1.3 and HKPS pool
Date: Fri, 23 Mar 2018 13:55:36 +0000

On Mon 2018-03-19 17:24:07 -0400, Phil Pennock wrote:
> On 2018-03-19 at 22:14 +0100, Kristian Fiskerstrand wrote:
>> On 03/19/2018 10:08 PM, Phil Pennock wrote:
>> > Do we care?
>> 
>> I'm tempted to say no..


I also agree that we do not care, and should issue no guidance that
encourages servers or clients to disable TLS 1.3.

If we need any guidance along the selection of transport crypto
parameters, we need guidance like:

 * support and prefer forward-secure key exchanges (ECDHE or FFDHE) over
   non-forward-secure RSA key exchange.
 * use ephemeral keys of at least 2048-bits (FFDHE) or 256-bits (ECDHE)
 * use a reasonable selection of ciphersuites
 * do not enable export ciphers
 * do not support SSLv3
 * and so on...

iow, the same guidance we'd give for anyone running an HTTPS endpoint.

> Another point in favor of that: I'd forgotten that TLS1.3 moves
> certificate exchange to be protected by the session, so encrypted.  Thus
> I suspect that we won't have SNI available for choosing TLS versions and
> ciphersuites until after TLS1.3 has already been negotiated.

Sadly, SNI iand ALPN are both still in the claer in the TLS 1.3
handshake.  I was unable to convince the TLS working group that the
additional latency cost of protecting SNI from passive monitoring was
a price worth paying for the additional metadata privacy. :/

so we don't have to worry about the effect of that on the pool.

Note that there are features coming down the pike for HTTPS+TLS+DNS that
might allow hiding the SNI behind a "fronting service" name, but that
would require special configuration, and we should probably have that
discussion separately.

TLS1.3 itself should just be a smooth upgrade.

One issue that we might have (and we might also have today in TLS 1.2)
is failed TLS session resumption from an HKPS client that switches
between servers in the pool, depending on how the client handles TLS
session tickets.  That also probably deserves a separate thread though,
since it's orthogonal to the TLS 1.3 question. 

   --dkg



reply via email to

[Prev in Thread] Current Thread [Next in Thread]