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

[Hubert Kario <[e-mail]>]

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