[Sks-devel] TLS 1.3 and HKPS pool

[Kristian Fiskerstrand]

Do we care?

I'm tempted to say no.. if there is a breakage that needs to be fixed
anyhow, and for most users on LTS branches of distros it will take a
while for the libraries that use tls 1.3 to begin with will be
distributed. If a client experience issues on it they can disable it,
although it might be worthwhile to file a RFE for gnupg's dirmngr if we
encounter such issues for it to add a tls version flag; doesn't it make
more sense for the client to specify version than to try to control it
server-side (and monitoring it)

Now.. if anyone were to actually disable everything but 1.3, that'd be
exclusion worthy from the pool, but lets do this manually if so.
--
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
Veni, vidi, vacatum
I came , I saw, I left

[Hendrik Visage]

Post by Kristian Fiskerstrand

Do we care?

I'm tempted to say no..
Now.. if anyone were to actually disable everything but 1.3, that'd be
exclusion worthy from the pool, but lets do this manually if so.

I’ve not seen and TLS1.2 security issues yet (but then I might’ve missed it in the deluge of meltdown/spectre/memcached) so I don’t see the need/reason to disable TLS1.2

---
Hendrik Visage
HeViS.Co Systems Pty Ltd
T/A Envisage Systems / Envisage Cloud Solutions
[phone] or [phone]
***@envisage.co.za

[Kristian Fiskerstrand]

Post by Hendrik Visage

Post by Kristian Fiskerstrand
Now.. if anyone were to actually disable everything but 1.3, that'd be
exclusion worthy from the pool, but lets do this manually if so.

I’ve not seen and TLS1.2 security issues yet (but then I might’ve missed it in the deluge of meltdown/spectre/memcached) so I don’t see the need/reason to disable TLS1.2

I was referring to server operators here, not clients, if that wasn't
clear :)
--
----------------------------
Kristian Fiskerstrand
Blog: https://blog.sumptuouscapital.com
Twitter: @krifisk
----------------------------
Public OpenPGP keyblock at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
"Don't be afraid to go out on a limb. That's where the fruit is."
(H. Jackson Browne)

[Henry Vindin]

Post by Kristian Fiskerstrand

Post by Hendrik Visage

Post by Kristian Fiskerstrand
Now.. if anyone were to actually disable everything but 1.3, that'd be
exclusion worthy from the pool, but lets do this manually if so.

I’ve not seen and TLS1.2 security issues yet (but then I might’ve missed it in the deluge of meltdown/spectre/memcached) so I don’t see the need/reason to disable TLS1.2

I was referring to server operators here, not clients, if that wasn't
clear :)

Further to this point, server side controls have historically been in specifying the prefered ciphers to use and that sort of "when negotiation happens, the server get's to pick a preference, the client just needs to accept the best it can support" exchange.

This entirely doesn't change a bit with TLS1.3 with regards to interoperability with TLS1.2.

In fact, the majority of objections to TLS1.3 have simply been that it forces the use of a much more constrained set of ciphers which are known to be secure as technology currently stands.

Aside from a few performance focused changes and some additional security opions (note: options are optional) TLS1.2 can be configured to provide the vast majority of benefits that one would see by enabling TLS1.3.

I've never actually looker at the implementation in any clients for negotiating with an HKPS server but if your clients supports ECDHE curves as well as AEAD Hashing as well as GCM rather than only CBC ciphers then you're basically at the same level lf security as you would be with TLS1.3.

So given the incredible lack of incentive to turn off TLS1.2 (especially as it was designed to be able to be easily expanded when flaws where found) there shouldnt be any number of operators suddenly switching it off, I would imagine that anyone so focused on maintaing the "best" TLS options would also know that turning off TLS1.2 will just make your host impossible to interface with until longer lived libraries and distro's (think OS's like Redhat, still using OpenSSL 1.0.2k) and hopefully they would be savy enough with their config to make sure they were adequately securing their TLS1.2 options to allow sufficiently security TLS1.2 communications alongside their TLS1.3 config, and they would therefore allow the downgrade by unsupported clients.

Just my 2c on the seemingly very small potential for an issue.

Thanks,
Henry

[Daniel Kahn Gillmor]

Post by Kristian Fiskerstrand

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