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

["Diego R. Lopez" <[e-mail]>]

Hi,



First of all, let me say I am glad to see this discussion reopened, and glad to see as well some proposals that sound more constructive than the usual religious entrenchments that are so common in this front, especially when I see certain acknowledgement we are not necessarily talking of mitm-ing, and we are not only talking about HTTPS and/or web access. It is about exploring the solution space for network-hosted device protection in a network with widespread (OK, let's not use "pervasive") use of end-to-end encryption.



This said, there a few points I'd like to make in response to Stephen's comments...



On 16/12/2017, 16:27, "PATIENT on behalf of Stephen Farrell" <[e-mail] on behalf of [e-mail]> wrote:



    On 14/12/17 22:58, Brian Witten wrote:

    > The logic, in the short form of roughly five points would be:



    Let's see if there is or is not logic to be found...



    > ** (1)

    > ** Endpoints have vulnerabilities.  ( unfortunately lots of them.

    > For this part I believe there is overwhelming evidence, but please

    > LMK if you disagree. )



    That's incomplete to the point of being misleading. Middleboxes

    are as likely to have bugs. And if those are mitm'ing many https

    connections the impact of a problem is higher than for the client

    side. Probably also higher impact for most instances of servers

    too. And the mitms are certainly in a position to mitm connections

    to high-value servers (if they can do one they can do all) so all

    mitm code bugs could argued to be worse than endpoint bugs.



Is not here a flaw in your logic? Nobody has mentioned middleboxes (or “things”, as they have called below) yet…



    > ** (2) ** These vulnerabilities are often

    > difficult (sometimes nearly impossible) for device owners, users,

    > etc, to mitigate “in” these endpoints. ( this is true today for

    > countless devices, and increasingly true for increasingly closed

    > devices, particularly in IOT and mobile. )



    Where's the evidence for that? What percentage is "often"?

    (Speaking about "countless" devices, is pure rhetorical

    noise and not useful if you are honestly trying to provide

    verifiable evidence.)



The most recent I have found is here: https://danluu.com/android-updates/ . It only refers to Android devices, though it mentions other systems as Windows XP. And it does not take into account IoT devices, to name another category. May be all of those are not “countless”, but it makes the use of the word a reasonably accurate figure of speech anyway.



    Why would middleboxes be easier to patch? It seems from many

    anecdotes (I'd love to see real numbers), that at least browsers

    and web servers these days are managed much better in terms of

    updates.



I cannot speak for other people supporting this, but we have not in mind only web browsers or web access use cases. I remember constrained devices were mentioned a couple of times in Singapore.



    > ** (3) ** For that reason,

    > those endpoint owners/users/etc often need to put some “thing” in the

    > network to mitigate those endpoint vulnerabilities. **



    That's simply false. Even if I accepted your stated and flawed

    premises, the above still doesn't follow at all. Just to call

    out your flawed logic in one way: buggy difficult to fix clients

    *could* be fixed or replaced over time, so your claim that

    a mitm middlebox is *needed* is obviously false.



OK. May be “need” is a too strong word here, at least in the general case (not sure about some kinds of devices…). But my own experience as user is that “can require” is, again, reasonably accurate



    > (4) ** For

    > that to be effective (against attacks in encrypted traffic), that

    > “thing” needs keys to inspect the encrypted traffic.  ( This can be

    > done any of many ways, as it’s done today. )



    Also clearly incorrect. See [1] (recently quoted by Martin T on some

    other list) for a proof that your claim that this is *needed* is also

    just false.



    [1] https://arxiv.org/abs/1607.01639



This is an interesting reference. Thanks for sending it. I guess this kind of solutions is in the minds of many, and recommendations on them (including a sound base of datasets for training and validation, as I have mentioned elsewhere) could be an interesting result of an effort like PATIENT. But the paper acknowledges limitations and ways for further improvement, and it has been applied to a particular case: distinguishing legitimate from malware-originated encrypted traffic. Nothing is said about malware payload detection to prevent infection, as an example of a key feature.



    > ** (5) ** Where that’s

    > done today, it can be done much more safely, therefore we should spec

    > standards for how to do it more safely.  ( Lots of ideas have been

    > published in research, and I include some details on that further

    > below, but maturing the right ones and baking them into a standard is

    > of course typically a “bigger group” effort. )



    Afaics all of those approaches are inherently flawed and consider

    it someone reasonable that a human can decide when to trust a

    random name/address that claims to be "good." None (i.e. zero) of

    the approaches proposed would improve the overall environment and

    therefore none (i.e. zero) of those ought be standardised.



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?



Be goode,



--

"Esta vez no fallaremos, Doctor Infierno"

Dr Diego R. Lopez

Telefonica I+D

https://www.linkedin.com/in/dr2lopez/

e-mail: [e-mail]

Tel:         [phone]

Mobile:  [phone]

----------------------------------





________________________________

Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.

The information contained in this transmission is privileged and confidential information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it.

Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição