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

[Stephen Farrell <[e-mail]>]

Hi David,

On 18/12/17 16:18, Black, David wrote:
>> 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.

Even with supposed "knowledge" (see the number 269 below),
cookies and other bearer tokens mean that so-called visibility
is the same as allowing impersonation unless one doesn't
actually ever apply the mitm technology to the web. The chances
of that seem to be zero to me.

And of course, many of the so-called "visibility" schemes,
immediately do allow for endpoint impersonation for everything
and not just bearer-token situations, whenever the middlebox
so chooses, regardless of the language used to describe those
schemes. Which brings us back to them being no better than the
current ickky corporate mitm root-ca stuff.

> 
>> 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.

My guess is that success would require there being some application
that wanted to use the putative multiparty protocol. I'm sure there
might be some such application but I've no idea if there's one that
would justify the effort.

And of course, it'd be a first-order requirement that that putative
new protocol not be confusable with https or tls, or else it'd
inherit all the downsides and reasons to not use that protocol for
any application that can use https or tls, and that ever needs to
be secure against mitm attack. (Which is why I think success there
isn't really likely.)

> 
>> 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, 

My comment was about my own conclusion.

> 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 

That is the exact claim to which I was responding and is,
as you note, nonsense. None of this mitm stuff is really
about giving users control of anything.

> ... 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/

IIUC, those kinds of service are aimed at allowing endpoints
to decide to just not send http requests. I don't see that they
are particularly relevant to this discussion, but I don't know
details of any middlebox-oriented services like that. (That's
one reason I asked for evidence of efficacy.)

It's also worth noting that for mail, where MTAs are a good
example of known and fairly well-identified servers, we have
decades of history of MTA inspection of cleartext missing
lots of "bad" content, and of variously good and less good
blocklists.

If the proponents of these mitm schemes honestly and openly
faced up to such issues and argued for another decades-long
arms-race and acknowledged the downsides (e.g. assisting
censorship, breaking all sorts of application assumptions,
and enabling pervasive monitoring) of mitm'ing https and/or
tls then that at least would be credible. It'd still be a bad
plan, but at least one for which we could discuss the technical
(de)merits and not have to deal with the nonsense claims such
at the one we both noted above.

Cheers,
S.


> 
> 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.
>> 
>