On Friday, 13 October 2017 14:45:35 CEST Stephen Farrell wrote: > On 13/10/17 12:05, Hubert Kario wrote: > > 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 > > IMO the more we hear of that the better > > > 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) > > So the problems with that are numerous but include: > > - there can be >1 carol, (and maybe all the carols also need to > "approve" of one another), if we were crazy enough to try do > this we'd have at least: > - corporate outbound snooper > - data-centre snooper (if you buy those supposed use-cases)
true > - government snooper(s) in places where they don't care about > doing that openly out of scope and directly against the WG agenda > ...port 80 would suddenly be quicker than 443 again;-( well, that would be an argument for making the server report the encryption keys to the middlebox instead of this squaring of the hole > - carol is quite likely to only have a name like: 2001:db8::bad:1dea > or your.friendly-listener.bigcdn.example.net and authenticating > those is essentially meaningless to the endpoints in most TLS contexts > whether or not those endpoints have humans associated with them not a problem, you need to trust the organisation (internal CA), not specific machines > - the TLS endpoints can't handle the semantics of allowing in Carol(s) > as those endpoints were designed to use TLS and not bolloxed-TLS (be > that mcTLS or draft-rehired) which is the entire point of it - we don't want this to be something clandestine or invisible to the client > So I think this ends up as bad as the design in draft-rehired. Which > of them is more obviously bad is another question. "draft-rehired"? -- 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
