Re: [Patient] [saag] Internet Draft posted as requested -

["Black, David" <[e-mail]>]

> I generally disagree with some of your earlier points where
> you disagree with me:-) I do agree that there are hard
> problems with updates and bugs in general for endpoints and
> devices in the middle. I don't agree that breaking TLS or
> HTTPs is a viable way to improve that, It'd make it worse.

If "breaking" is defined as "MITM-ing connections without any form of knowledge or authorization by the endpoint," then I would agree that "breaking TLS or HTTPS" is a bad idea.

> But rather than repeat things I've said to you in person
> before, for this threat, maybe it is work saying that the
> proponent here claimed to be interested in a new multiparty
> security protocol (in the mailing list description) which
> could have been a worthy, if unlikely to succeed endeavour.

+1 on worthy, no comment on likelihood of success.

> In Singapore, I concluded that they are primarily or maybe
> only interested in the web as used by people and in mitm'ing
> that. So personally I think the separate mailing list would
> be better closed down as it seems to have been started on
> the basis of some confusion wrt folks' goals.

Also, no comment on people's intents, but I do want to respond to one of Stephen's earlier remarks ...

> Just for a laugh, I loaded [2] in a default setup browser (chromium).
> Among the 269 http requests that caused was [3]. Are you (Brian)
> seriously trying to claim that you actually believe that a random
> person can sensibly decide 269 times if 2001:db8::bad:1dea ought
> be allowed to mitm that connection?

A person (random or otherwise) - of course not ... however ... a community or otherwise maintained blacklist or whitelist is plausible, although that does require both that the involved middleboxes to have stable visible identities, and that there be a viable community or other maintenance organization for the list or lists.

A blacklist approach seems reasonably effective in other domains - for examples, try these links:
	https://adblockplus.org/subscriptions
	https://filterlists.com/

Thanks, --David

> -----Original Message-----
> From: saag [mailto:[e-mail]] On Behalf Of Stephen Farrell
> Sent: Sunday, December 17, 2017 7:24 PM
> To: Diego R. Lopez <[e-mail]>; Brian Witten
> <[e-mail]>; [e-mail]; [e-mail]
> Subject: Re: [saag] [Patient] Internet Draft posted as requested -
> 
> 
> Diego,
> 
> I generally disagree with some of your earlier points where
> you disagree with me:-) I do agree that there are hard
> problems with updates and bugs in general for endpoints and
> devices in the middle. I don't agree that breaking TLS or
> HTTPs is a viable way to improve that, It'd make it worse.
> But rather than repeat things I've said to you in person
> before, for this threat, maybe it is work saying that the
> proponent here claimed to be interested in a new multiparty
> security protocol (in the mailing list description) which
> could have been a worthy, if unlikely to succeed endeavour.
> In Singapore, I concluded that they are primarily or maybe
> only interested in the web as used by people and in mitm'ing
> that. So personally I think the separate mailing list would
> be better closed down as it seems to have been started on
> the basis of some confusion wrt folks' goals.
> 
> On 17/12/17 23:19, Diego R. Lopez wrote:
> >
> > I am afraid I don’t follow you here… What do you mean by “random
> > name/address that claims to be “good””? Given there are appropriate
> > roots of trust, how is this “random” trust different from the
> > certificate verification process in TLS?
> The difference in the above context is the the proponents
> here want TTPs that tell lies all the time, and that are
> so wide-spread and not well-known that they appear to the
> endpoints indistinguishable from a random router. The public
> Web PKI TTPs we have are far from perfect but at least they
> don't do that so far.
> 
> There also appears to be some magical thinking that allows
> some proponents to say that they think these new lies can
> benefit the user and give the user more control. I have no
> clue how that can reflect a genuine technical opinion.
> 
> S.
>