Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

[Hubert Kario <[e-mail]>]

On Thursday, 12 October 2017 00:24:36 CEST Ion Larranaga Azcue wrote:
> 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...

yes, a three-way DH with two certificates (one IPS one EE server) does seem 
like a much better approach, especially if IPS certs need to have special 
flags that make them useless for anything else and cannot be set by CAs in 
public CA programs.

>    Ion
> 
> 
> ________________________________
> De: TLS <[e-mail]> en nombre de Nick Sullivan
> <[e-mail]> Enviado: lunes, 9 de octubre de 2017 22:49
> Para: Ralph Droms; [e-mail]
> 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
> <[e-mail]<mailto:[e-mail]>> 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
> [e-mail]<mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/tls


-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic