On Thursday, 12 October 2017 15:16:08 CEST Stephen Farrell wrote: > (With the obvious caveat that I hate the whole > idea... :-)
to be clear: me too > On 12/10/17 13:57, Hubert Kario wrote: > >> 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. > > But... even if one did add names/certs for the wiretapper > or IPS or whatever then there could be more than one of > those who'd like to be able to interfere with the TLS > session, and there's no way I can see that makes sense for > the client and server to negotiate which wiretappers they > allow/like. my point is, that I may be forced to disclose contents of all my communications to a specific entity, so I effectively have to trust it (willingly or not), but that doesn't mean that I have to allow for wiretapping for arbitrary parties > This is all just squaring-the-circle, TLS is meant to be > a 2-party protocol (ignoring CAs) and I don't see any way > to make TLS a multi-party protocol that works. 1. Alice sends a share to Bob: g^a 2. Bob sends Alice's and his share to Carol: g^a, g^b, g^ab 3. Carol replies to Bob with her share added to Alice's and his: g^ac, g^bc 4. Bob sends the Carol's reply to Alice as a Server Key Share: g^bc 5. Alice calculates the shared secret g^bca 6. Bob calculates the shared secret: g^acb 7. Carol calculates the shared secret: g^abc so it doesn't look to me like it requires a lot of chamfer to fit that square peg in the round hole, only the 2 and 3 need to happen out-of band. of course, I haven't analysed how Carol would be authenticated in that communication (if signing just the SKS by Carol is enough, transferred in the encrypted extensions, with server signature of the handshake in certificate verify being sufficient for integrity) -- 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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
