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 <stephen.farr...@cs.tcd.ie> 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 >>> <ilariliusva...@welho.com> wrote: >>> >>>> On Thu, Jul 20, 2017 at 08:42:10PM +0000, Blumenthal, Uri - 0553 >>>> - MITLL wrote: >>>>> On 7/20/17, 16:32, "ilariliusva...@welho.com on behalf of Ilari >>>>> Liusvaara" <ilariliusva...@welho.com> 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 >>> TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls >
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
