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

[Eliot Lear <[e-mail]>]

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
[2] https://ieeexplore.ieee.org/document/9789828