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

["Blumenthal, Uri - 0553 - MITLL" <[e-mail]>]

I'd be perfectly happy with TLS 1.3 having nothing but PFS, and those in need of the plaintext getting it from the endpoint OOB.

Regards,
Uri

Sent from my iPhone

> On Jul 23, 2017, at 12:16, Stephen Farrell <[e-mail]> wrote:
> 
> 
> 
>> On 23/07/17 13:43, Blumenthal, Uri - 0553 - MITLL wrote:
>> Ilari,
>> 
>> I got your point.
>> 
>> But in view of the request this WG is discussing now, I see only two
>> reasonable (IMHO) opinion: 1. Tell those requestors to go away
>> because TLS 1.3 has been designed to always be forward-secure; or 2.
>> Add a *detectable* non-PFS key exchange so those requestors would
>> have something they can live with, and the rest of us could at least
>> agree or disagree to a non-PFS session establishment on a per-session
>> or a per-entity basis.
> 
> In Prague some folks were considering another option:
> 
> 3. Encourage folks who currently use static RSA keys for third
> party decryption to put in place a migration plan that gets them
> to FS without breaking TLS1.3. IOW, given they can continue to
> use TLS1.2 for some years to come, there's no rush, and plenty
> of time for transition plans to be put in place. (That'd I think
> imply some work in the ops area of the IETF if there's any IETF
> work needed at all, but nothing in the TLS wg.)
> 
> While I'd (probably entirely predictably:-) be against your
> option 2 above, I'd also note that that'd entirely screw up any
> ideas we might have of finishing TLS1.3 in the near term. Anyone
> who'd argue for such changes needs to be clear that they're also
> arguing for another year's delay.
> 
> Cheers,
> S.
> 
>> 
>> I do not know what mechanism could do the latter, or off it even
>> exists. But folding an RSA method in seems to do the job. I'd say
>> it's fine if it borrows from 1.0, as it isn't going to be the most
>> secure setting anyway.
>> 
>> Regards, Uri
>> 
>> Sent from my iPhone
>> 
>>> On Jul 23, 2017, at 03:02, Ilari Liusvaara
>>> <[e-mail]> wrote:
>>> 
>>>> 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
>>> 
>>> 
>>> 
>>> _______________________________________________ TLS mailing list 
>>> [e-mail] https://www.ietf.org/mailman/listinfo/tls
>