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

[Henry Vindin]

On Mon, Mar 19, 2018 at 11:08:13PM +0100, Kristian Fiskerstrand wrote:
> On 03/19/2018 10:40 PM, Hendrik Visage wrote:
> >> 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

pgpr10BVAmadG.pgp
Description: PGP signature