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

[Hesham ElBakoury <[e-mail]>]

Certainly fighting against ransomware attacks is very important. Many
reports are issued from both industry and academia regarding this attack
and ways to mitigate it.

For example, this Splunk report [
https://www.splunk.com/en_us/blog/learn/ransomware-attack-types.html] says:
"Recently, we’ve seen a huge rise in ransomware attacks, with more than 2.3
billion attacks in 2022 alone
<https://www.privacyaffairs.com/ransomware-attacks-in-2022/>. Statistics
show:

   - A ransomware attack occurs every 2 seconds
   <https://www.getastra.com/blog/security-audit/ransomware-attack-statistics/>.
   (That’s 43,000+ a day.)
   - The average cost of a ransomware attack is $1.85 million
   <https://www.getastra.com/blog/security-audit/ransomware-attack-statistics/>
   ."

Since this IAB report is mainly looking into encrypted data, I would assume
that you are interested in the cases where Ransomware attack is leveraging
encrypted data such as Encrypted Client Header (ECH) which can be used to
hide the adversaries command and control [
https://www.ietf.org/archive/id/draft-campling-ech-deployment-considerations-07.txt
]

Hesham

On Sat, Aug 26, 2023, 5:40 AM Arnaud Taddei <[e-mail]>
wrote:

> Thank you Hesham, I will educate myself in the (too many) forthcoming
> trips.
>
>
>
> Whilst I am sure this approach can help, I am taking it from a different
> point of view which basically boils down to ‘I cannot afford playing dice
> with the security of organizations and people’ especially when I see
> Ransomware damaging so much this world.
>
>
>
> *From: *Architecture-discuss <[e-mail]> on
> behalf of Hesham ElBakoury <[e-mail]>
> *Date: *Monday, 14 August 2023 at 23:29
> *To: *Wes Hardaker <[e-mail]>
> *Cc: *[e-mail] <[e-mail]>
> *Subject: *Re: [arch-d] draft-iab-m-ten-workshop
>
> Professor Boutaba and his team in the university of Waterloo have good
> papers on handling encrypted traffic. Examples are:
>
>
>
> 1)https://www.sciencedirect.com/science/article/abs/pii/S1389128623000932
> <https://www.google.com/url?q=https://www.sciencedirect.com/science/article/abs/pii/S1389128623000932&source=gmail-imap&ust=1692653392000000&usg=AOvVaw156PPnjCWC5AWlIlm-sKTP>
>
> 2)https://dl.acm.org/doi/10.1145/3447382
> <https://www.google.com/url?q=https://dl.acm.org/doi/10.1145/3447382&source=gmail-imap&ust=1692653392000000&usg=AOvVaw2TVawa1ZzzJI3XvfvSnMI->
>
> 3)https://arxiv.org/pdf/2308.02182
> <https://www.google.com/url?q=https://arxiv.org/pdf/2308.02182&source=gmail-imap&ust=1692653392000000&usg=AOvVaw2OOeAMSM_a1GAfQYx0KEE9>
>
> 4)
> https://www.researchgate.net/profile/Navid-Malekghaini/publication/368722877_Deep_learning_for_encrypted_traffic_classification_in_the_face_of_data_drift_An_empirical_study/links/6431cb5e4e83cd0e2f9d3a23/Deep-learning-for-encrypted-traffic-classification-in-the-face-of-data-drift-An-empirical-study.pdf
> <https://www.google.com/url?q=https://www.researchgate.net/profile/Navid-Malekghaini/publication/368722877_Deep_learning_for_encrypted_traffic_classification_in_the_face_of_data_drift_An_empirical_study/links/6431cb5e4e83cd0e2f9d3a23/Deep-learning-for-encrypted-traffic-classification-in-the-face-of-data-drift-An-empirical-study.pdf&source=gmail-imap&ust=1692653392000000&usg=AOvVaw0wTPRNqp3us8soQk1QmOwI>
>
>
>
> Hesham
>
>
>
> On Mon, Aug 14, 2023, 1:22 PM Wes Hardaker <[e-mail]> wrote:
>
> Eliot Lear <[e-mail]> writes:
>
> > Hi everyone,
>
> Hi Eliot and Arnaud,
>
> I'm responding to the larger point you both had concerned with together
> about the nature of the wording and the purpose of the IAB workshop
> report.  Thank you both for your extensive comments about the content.
>
> > 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...”
>
> I think the general of how best to describe what happens in an IAB
> workshop and what the report entails is an interesting one, and I'm
> surprised it hasn't been brought up before (well, at least to my
> knowledge so it may very much have been in past discussions).  IAB
> workshop reports (IMHO) are designed not to assert the veracity of the
> statements within, but rather to capture the discussion and the
> statements that participants made either in presentations or in ensuing
> discussions.  So, to some extent the entire report should be read as
> "[one person/several people] suggested that"...  To that end, we [the
> IAB] did discuss the best way to represent this and have published a -02
> version with a number of changes, including a new section in the
> introduction to make this more clear which I'll quote below:
>
>     1.1.  About this workshop report content
>
>        This document is a report on the proceedings of the workshop.  The
>
>        views and positions documented in this report are those of the
>
>        expressed during the workshop by participants and do not
> necessarily
>        reflect IAB views and positions.
>
>        Furthermore, the content of the report comes from presentations
> given
>        by workshop participants and notes taken during the discussions,
>
>        without interpretation or validation.  Thus, the content of this
>
>        report follows the flow and dialog of the workshop but does not
>
>        attempt to capture a consensus.
>
> The full diff between -01 and -02 can be found here:
>
>   https://author-tools.ietf.org/iddiff?url2=draft-iab-m-ten-workshop-02
> <https://www.google.com/url?q=https://author-tools.ietf.org/iddiff?url2%3Ddraft-iab-m-ten-workshop-02&source=gmail-imap&ust=1692653392000000&usg=AOvVaw3bWL4OFgd3fttCLZEOdxxz>
>
> Most of the rest of your comments were about specific statements that
> you disagreed with, but were made during the course of the workshop by
> at least "[one person/several people]".
>
> Note that the full recordings are on the IETF youtube channel as well:
>
> https://www.youtube.com/watch?v=Kizk_QrIc3s
> <https://www.google.com/url?q=https://www.youtube.com/watch?v%3DKizk_QrIc3s&source=gmail-imap&ust=1692653392000000&usg=AOvVaw1dtj0H4avRj3i-U14V8_X9>
> https://www.youtube.com/watch?v=aV1pzuCduLo
> <https://www.google.com/url?q=https://www.youtube.com/watch?v%3DaV1pzuCduLo&source=gmail-imap&ust=1692653392000000&usg=AOvVaw3VJypoKu_tLB9hGIWwOyN_>
> https://www.youtube.com/watch?v=p4NlZJlactE
> <https://www.google.com/url?q=https://www.youtube.com/watch?v%3Dp4NlZJlactE&source=gmail-imap&ust=1692653392000000&usg=AOvVaw1n2tfhTEn7wRtvMHECJha2>
>
> A number of your comments were requesting references:
>
> > Great!  Reference, please?
>
> We did not include references to work, but rather included references to
> the individual position papers which themselves often contained
> references.  And the youtube presentations also have discussions from
> the presenters and comments that will give rise to additional information.
>
> >     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.
>
> FYI, fixed the typo in MUD.  Thanks for catching that.
>
> > 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.
>
> I've argued recently that half (if not more) of an IAB workshop is to
> start the discussion and direction, and rarely should the workshop
> actually solve a problem.  The point is to get people in the room so a
> conversation starts, even if there isn't agreement at the end.  To that
> end, there should *always* (IMHO) be future work after an IAB workshop.
> For if there isn't and the problem was actually solved during the
> workshop, it probably should have been a working group instead of a
> workshop :-)
>
> --
> Wes Hardaker
> USC/ISI
>
> _______________________________________________
> Architecture-discuss mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/architecture-discuss
> <https://www.google.com/url?q=https://www.ietf.org/mailman/listinfo/architecture-discuss&source=gmail-imap&ust=1692653392000000&usg=AOvVaw3e7j6K8CJwrxzIbKf2n8aS>
>
>
> 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.