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)
- government snooper(s) in places where they don't care about
doing that openly
...port 80 would suddenly be quicker than 443 again;-(
- 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
- 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)
So I think this ends up as bad as the design in draft-rehired. Which
of them is more obviously bad is another question.
Cheers,
S.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
