Re: [arch-d] draft-iab-m-ten-workshop

[Arnaud Taddei <[e-mail]>]

Thank you Eliot,

To start with I don’t know what is it that I am doing wrong that I don’t see any notification of such reports being published, though I thought I put myself on all the right mailing lists.

I read the ‘report’ once and I have many problems I would need to do a deeper dive and don’t know when I can do this.

So, I am glad you spotted these issues and indeed I am surprised too by the text.

I cannot judge if it represents what had been expressed or if more non-neutral interpretation were added as I was not there.

To echo your first clause, I have a very strange impression with my own chairmanship hat in other places.

Anyway, again, thank you Eliot for highlighting these issues and your very valid points.

I could add more but am wondering what is the best way to work here and mindful of being under heavy workload.

I have certainly the strong impression that there was a significant under representation of operational security expertise in the room from various horizons (not just corporate).

I remember I arrived too late for participation in this workshop but really regret not being able to attend.

This text infers many specific directions to me and assumptions on where security should be, or what security should be, vs reality check.

I think a few opportunities were missed and this is mostly because the representativity of who should have been in this workshop was unbalanced.

At minimum I would have liked to see a proper methodology for discussion recognizing the ‘design’ nature of the task and consider proper design methodologies (anything would have been good to start with) and put security, privacy together with safety and other “design characteristics” and key considerations including anthropology, ethics, legal and technology in the proper order.

More ‘tactical’ some parts are entirely missing in this analysis, am just taking one example: compliancy and the paradoxes it leads too and the irony it creates in the tension of privacy and security (think just EU: GDPR, NIS2, CRA, DORA, EBAG, etc.)

Finally, this prompts me on the fundamental representativity issues (and not just at this workshop) that then lead to some very specific directions.

From: Architecture-discuss <[e-mail]> on behalf of Eliot Lear <[e-mail]>
Date: Tuesday, 25 July 2023 at 01:08
To: [e-mail] <[e-mail]>
Subject: [arch-d] draft-iab-m-ten-workshop

Hi everyone,

I had the opportunity to read this report, and I have a few comments.  To begin with, it's nice when a report can seamlessly join various workshop components, but this report goes so far as to appear to be itself a position paper.  There are a great many unsupported and otherwise unattributed assertions made.  Under Chatham House rules one might expect such assertions along the lines of, “[one person/several people] suggested that...”

So.  Who is this work speaking for?  Apparently NOT the IAB according to the abstract, but is it all workshop participants, a rough consensus among them, or the report authors?

Ok, now the details:

The following statement is problematic:
   Additionally, there appears to be little if any actual evidence that
   encryption is causing user-meaningful network problems.

There are two negative proofs to this:

  *   The TLS working group received a presentation on precisely how TLS 1.3 would have prevented administrators to debug user-facing application failures.  A real world example was given in which a bug in a web server was causing garbage to be processed.  The problem was detected through the use of static DH and Wireshark.
  *   A static DH crypto-set was published for TLS 1.3 in order to address auditing requirements in industrial applications.  You could say that this isn't user-meaningful, but if the user is a safety or crash inspector at a railroad, you'd be wrong.

There may be new ways to address these points, but the report (and perhaps the workshop) misses the opportunity to do so by denying the problem in the first place.  Arguably, if you really believed that, you could have stopped the workshop and report right there ;-)
The current estimate for the number of events a Security Operations Center (SOC) operator can handle is about 10 per hour.

This statement seems to assume a particular size of the SOC operator and a particular complexity of an event.  Perhaps this was a statement made by a particular.  Let's not over-generalize.  Otherwise, some sort of reference seems in order.

Speaking of references, the following entire paragraph has some real problems:
Validating which alerts are true positives is challenging because lots of weird traffic creates many anomalies and not all anomalies are malicious events.  Identifying what anomalous traffic is rooted in malicious activity with any level of certainty is extremely challenging.  Unfortunately, applying the latest machine learning techniques has only produced mixed results.  To make matters worse, the large amounts of Internet-wide scanning has resulted in endless  traffic that is technically malicious but only creates an information overload and challenges event prioritization.  Any path forward must succeed in freeing up analyst time to concentrate on the more challenging events.

There are many assertions above and not a single reference.  To begin with, if you are going to state that traffic is “technically malicious” you had better explain what that means.  You may be able to leverage something from RFC 4948 (I haven't checked).  Going further, "mixed results" is a very woolly term.  If ML could reduce false positive by a significant percentage, maybe that is of value to SOC operators.  Third, if you are going to claim that scans are creating information overload, you should explain how or add a reference.  If what you mean is that real attacks are hiding in plain sight, you could say that.  But I don't understand how this relates to encryption.

The same sort of problem occurs with this paragraph:
Applying this to network traffic has been shown to allow a middlebox to verify that traffic to a web server is actually compliant with a policy without revealing the actual contents. This solution meets the above three criteria. Using ZKP within TLS 1.3 traffic turns out to be plausible.

Great!  Reference, please?
Harms need to be preemptively reduced because in general terms few users would choose network management benefits over their own privacy if given the choice.

This raises the question of who the user actually is.  Is the “user” the bank employee or the customer whose personal information the bank employee may be leaking?  This also leads to questions as to how the interests of the customer are represented in Section 2.2.2.  Is the customer first, second, third, or NO party?

Just a quip or two about this paragraph:
Within the IETF, the Manufacturer Usage Description Specification (MUDD) {?RFC8520} specification is one subset of contracts. Note that contracts are likely to only succeed in a constrained, expected environment maintained by operational staff, and may not work in an open internet environment where end users are driving all network connections.

The initial demonstration implementation of MUD (one D) was implemented using a plugin to DNSCAP that itself issued commands to iptables.  There are two real questions hiding here:

  1.  Are firewall vendors and telcos have an interest in protecting the user with such contractors?  The user certainly has that interest.
  2.  Can a contract be properly described and maintained in a secure way?

There has been some academic work on answering the latter question.[1,2]  Going further, though, some aspects of MUD (and Michael could say a good bit about this, and probably did at the workshop), require visibility.  So for instance, rather than making use of DNSCAP, a more explicit API between the resolver and the rest of network management is something that has been discussed in various corners (if memory serves, dnsop just recently).  This very much depends on whether the endpoint uses a resolver with that sort of binding.  Future work, I suppose.

Eliot
[1] https://arxiv.org/abs/2212.01598<https://www.google.com/url?q=https://arxiv.org/abs/2212.01598&source=gmail-imap&ust=1690877314000000&usg=AOvVaw2yIIytZ2xjBD7B3Gci7xWu>
[2] https://ieeexplore.ieee.org/document/9789828<https://www.google.com/url?q=https://ieeexplore.ieee.org/document/9789828&source=gmail-imap&ust=1690877314000000&usg=AOvVaw1oPzruR1gN_KhoLtZo_jKG>

-- 
This electronic communication and the information and any files transmitted 
with it, or attached to it, are confidential and are intended solely for 
the use of the individual or entity to whom it is addressed and may contain 
information that is confidential, legally privileged, protected by privacy 
laws, or otherwise restricted from disclosure to anyone else. If you are 
not the intended recipient or the person responsible for delivering the 
e-mail to the intended recipient, you are hereby notified that any use, 
copying, distributing, dissemination, forwarding, printing, or copying of 
this e-mail is strictly prohibited. If you received this e-mail in error, 
please return the e-mail to the sender, delete it from your computer, and 
destroy any printed copy of it.