On Sat, Jul 8, 2017 at 5:16 PM, Nick Sullivan <nicholas.sulli...@gmail.com> wrote:
> Putting questions of whether or not this belongs as a working group > document, I think there are some necessary requirements for > intra-datacenter passive decryption schemes that are not met by this draft. > > Specifically, any passive decryption scheme should the following two > properties: > 1) Both server and client must explicitly opt-in > 2) A third party should be able to tell whether or not this feature is > enabled by observing the stream > > These two requirements protect services on the wider Internet from being > accidentally (or surreptitiously forced to be) subject to unauthorized > decryption. > I absolutely agree. What you likely want is something similar to TLS 1.2 session tickets with > centrally managed session ticket keys. The client would advertise support > for "passive session decryption" in an extension and the server would > return an unencrypted extension containing the session keys encrypted by a > server "passive decryption key". The passive decryption key would be > managed in the same way as the static DH key in this draft: rotated > frequently and synchronized centrally. > This is the best proposal I've seen so far. What is the problem of publishing a scheme like this as an Informational RFC? After all, we can cite many examples of protocols described in Informational RFCs that are widely deployed by industry. If the proponents of this draft think it critical that this needs formal IETF endorsement as a standard, then I believe they ought to be also working on persuading the IETF to withdraw or at least backtrack on some of our previous statements (such as RFC 7258, which declared that IETF protocols need to have technical countermeasures to prevent pervasive monitoring). I doubt that we will be able to get consensus on IETF endorsement. Speaking only for myself, I am against the IETF/TLS wg endorsing a protocol that degrades the security of the TLS protocol. But I am perfectly fine with publishing it as Informational document. -- Shumon Huque
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
