Re: [TLS] datacenter TLS decryption as a three-party protocol

[Ilari Liusvaara <[e-mail]>]

On Thu, Jul 20, 2017 at 08:42:10PM +0000, Blumenthal, Uri - 0553 - MITLL wrote:
> On 7/20/17, 16:32, "[e-mail] on behalf of Ilari Liusvaara" <[e-mail]> wrote:
> > Maybe we are better off just retrofitting RSA-key-transport back
>     > into TLS-1.3? 
>     
>     This has in fact been requested. Kenny Paterson said about the request:
>      -----------------------------------------------------------------------
>     My view concerning your request: no. 
>     Rationale: We're trying to build a more secure internet.
> 
> My rationale to resurrect it: others are trying to push TLS-1.3 into
> an invisibly-insecure state. If we must satisfy them (and I’m not at
> all sure we should), then this is the most obvious way to at least
> avoid the “insecurity” being silently pushed upon you. At the very
> least you’d have an option to continue under surveillance or abort
> connection. 

This isn't just matter of what is considered "secure enough" to
include. There are fundamential technical constraints that prevent
adding static RSA back.

Early on, there were all sorts of really fundamential decisions on how
TLS 1.3 works. The results of these decisions are baked deeply in the
protocol, and are extremely hard to change. These decisions were
already very apparent in draft-02, over 3 years ago, despite -02 being
unimplementable.

One implication of those assumptions is that any asymmetric key
exchange in TLS 1.3 is at least potentially forward secure[1] (the
actual constraints on asymmetric key exchanges are even stronger
than that, but this weaker version suffices here). Static RSA is not
even potentially forward-secure, so it can not be added.

If you try to add back RSA using the most straightforward method,
what you get is not an analog of static RSA from TLS 1.2. The result
would be closer to RSA_EXPORT from TLS 1.0.


On the other hand, there is no way to construct a key exchange that is
always forward-secure. Either endpoint can always act in a way that
destroys forward-security (even without leaking any per-connection
information), but can not be detected (DH share reuse is considered
detectable) by the other end.


[1] "potentially forward secure" means that there exists interoperating
client and server implementations, so that the key exchange is forward-
secure.


-Ilari