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 _______________________________________________ Sks-devel mailing list Sks-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/sks-devel