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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
