I'm a newcomer here, so I may be wrong in some aspects (I apologize in advance for that) but at least I'd like to give my opinion...
I really don't feel confortable with the approach taken in this draft. Most of the proponents of these kind of "tapping" limit their scope to datacenters, but I agree with others in that it should be treated as if it will be used on the internet as a whole (as the specification does not prevent this kind of use, and we can't know how users and hosting companies will react to this functionality being available). It's true that with this approach the client has to opt-in but once it has opted-in, the client has no control over which third party the encryption keys are passed to. Imagine a client opts-in because he knows there is an IPS within the network and the company hosting the server asks him to (I know at least one of our clients would certainly consider this). But some time later a malicious third party manages to coerce the hosting company to provide the keys to them instead (or in addition to) the IPS. From the point of view of the client, he wouldn't notice anything different (only a change in the key identifier but could be due to key renewal)... I think a way to solve this would be involving the client more in the visibility negotiation. For me, the client not only has to opt-in to the tapping, but should also have the possibility to unambiguosly identify the tapping third-party and accept or reject the connection accordingly. I had some naive idea for this but I was unable to accomodate it in the handshake as it is currently defined (in fact, I don't think this kind of control for the client can be provided without major changes to the handhsake protocol). I also don't like the way security so greatly depends on SSWrapDH1 (as addressed in point 6 of Security Considerations). I expect many administrators will create long-lived keys in order to avoid the work to have to redistribute them, leaving connections open to attack during months after they take place (until SSWrapDH1 key renewal)... Anyway, I think key life length could be addressed in later drafts, but the inability of the client to identify (and possibly reject) the tapping third party is a "no go" for me... Ion ________________________________ De: TLS <tls-boun...@ietf.org> en nombre de Nick Sullivan <nicholas.sulli...@gmail.com> Enviado: lunes, 9 de octubre de 2017 22:49 Para: Ralph Droms; tls@ietf.org Asunto: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00 Ralph and Russ, This draft addresses the two main concerns I had with draft-green: 1) Client opt-in 2) On-the wire visibility There are clearly some details missing from this draft (such as how Ke is used as a symmetric key), but generally I think this approach is more explicit and therefore less likely to unintentionally impact the broader internet if used in the datacenter setting. Nick On Mon, Oct 2, 2017 at 1:31 PM Ralph Droms <rdroms.i...@gmail.com<mailto:rdroms.i...@gmail.com>> wrote: We are about to publish draft-rhrd-tls-tls13-visibility-00. The TLS extension defined in this I-D takes into account what we heard from the discussion regarding TLS visibility and draft-green-tls-static-dh-in-tls13-00 in Prague. Specifically, it provides an opt-in capability for both the TLS client and server and makes it clear on the wire that visibility will be enabled for the session. The new mechanism does not depend on static handshake or session keys. - Ralph and Russ _______________________________________________ TLS mailing list TLS@ietf.org<mailto:TLS@ietf.org> https://www.ietf.org/mailman/listinfo/tls
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
