From nobody Fri Jan 8 06:45:37 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00203A0FF4 for ; Fri, 8 Jan 2021 06:45:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-1vbFCy9uu9 for ; Fri, 8 Jan 2021 06:45:34 -0800 (PST) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5C883A0FF0 for ; Fri, 8 Jan 2021 06:45:34 -0800 (PST) Received: by mail-qt1-x82d.google.com with SMTP id b9so6637798qtr.2 for ; Fri, 08 Jan 2021 06:45:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=fXEbXaLh6JpAAekUkd7EdDQP4aezcUKbEe7UDZLafcg=; b=JGu155DcsI8TXwCG2ND1E6QwbboND74R59E1Hp5KzazELzia/LgZQb8ey27nGtUZfh 8si2nKSK2WzmsC3+zfYmwdofV3SmYAOJnmAhpTTGWzz5uzV6D5Q192ZoCoWqQ2zi7GR2 qHSKhCEI/1uqZxj5inJ+Wqo/Ay00sI9KUMmdW3dWDny6L6zBT/qJhtBGq+p4dRnVcWvD QLKh3uNGnAk8Quu2uTGam98XAcC427qXJrH2PwgWFpSrpeUXWc0ebJi5wHDKmaVl8JW6 EWJjZDuAlOt857/FBU1GVqeA5L/H/QT2D3j1PugFBTiZkj15PvZIpS9z1WxQvPN4VFnW wahA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=fXEbXaLh6JpAAekUkd7EdDQP4aezcUKbEe7UDZLafcg=; b=jsPy1gNJXZtFOXXexDA3UaW9xAhLrWbrlxZQk1uGqu33YN8klujSQ60YzCYj8dcTEi tsfY94wj9Hyy9n5Y/x0qWtKm7o5TN8qUWiWxJF4N/yar98sGZtL3OGSiKWjn+ykTIfSo 8FHxP2LRevFISgRysARzloDrn0lk+1UBo3rck4o0kRZc5JYoEfR62nu+Bx5+VSnP6mgS 5Ywpix/domEDvVWKxMZ4EG5rVzKbRSBVGGi+RdgblJXboLQgdxuC4sWOdst35pOzaAIn s+LIoD5UE1wR/9s7gIjLvJG5J0a//67zFSc9ldcZjid5UG0oNYYj7oUGp4FJ+TX6WnV6 VVwg== X-Gm-Message-State: AOAM5307Ol/ApUJnkWPjIoKH9b20MJVM4RoAo8xBACaSQbhA4iIiP7nJ 9474s51byKhsOOWt1a+bMi+wwiyyeyk+d5HSPf98br7S7G78Wg== X-Google-Smtp-Source: ABdhPJwtOaQJfv+rLD3/EuU95NU6/GKYzmuKVcf1mY6+mgeiBqfw+fYSfL1X/FcuF0JydPhT0howyeiIQjaryq99Pp8= X-Received: by 2002:ac8:4e05:: with SMTP id c5mr3682585qtw.359.1610117133435; Fri, 08 Jan 2021 06:45:33 -0800 (PST) MIME-Version: 1.0 From: Jonathan Hoyland Date: Fri, 8 Jan 2021 14:47:06 +0000 Message-ID: To: saag@ietf.org Cc: Benjamin Kaduk , Michael Richardson Content-Type: multipart/alternative; boundary="000000000000c906ee05b8649b89" Archived-At: Subject: [saag] Classifying MITM attacks X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2021 14:45:37 -0000 --000000000000c906ee05b8649b89 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi SAAG, So I've been thinking about classifying MITM attacks a little over the winter break, =C3=A0 la draft-richardson , and did a quick literature survey to see what academia has to say about MITM attacks, and their variations. The best paper I found was "A survey of man in the middle attacks" [1], which doesn't propose any terminology, but does group the attacks. I think a decent ontology would be a useful bit of work. To that end, I was thinking about what kind of attacks should be in scope, and thus should unambiguously be captured in a taxonomy. Some potentially ambiguous examples: 1. If both endpoints are anonymous, is the attack still a MITM attack? What's the line between two separate connections and a MITM attack in an anonymous scenario? a. What about in a scenario where identities can't be verified, such as vehicle-to-vehicle / vehicle-to-environment communications in a remote area? 2. If I put a probe on a bus am I performing a MITM attack? At what point does a MITM attack shade into compromise of the endpoint? 1. In a group chat scenario does impersonating another user count as a MotS attack? Consider Alice, Bob, and Carol all legitimately participating in= a group chat. If Carol impersonates Bob to Alice (and herself) in the grou= p chat, how would we describe that attack? 1. If I stick a malicious QR code over an on-boarding QR code, what kind of MITM attack have I performed? a. If Mallory swaps the registration QR codes of two devices, and Alice then registers Bob's device has she performed a MITM attack? Another useful exercise might be to go through the attacks listed in [1] and check any ontology describes them appropriately. (Finding this paper online is surprisingly hard, but I'm happy to send anyone a copy.) One final question is do we want a strict taxonomy, where each attack fits into exactly one category, and relationships between attacks are captured by distance in the tree, or do we want a more flexible ontology where we can classify attacks more fuzzily, but still have basic groups? One comment specific to the draft is that it currently uses the term "in-the-rough", which I don't really like. As a non-golf player "in-the-rough" makes me think of precious stones, not a golf metaphor. Esp. as no dictionary I could find [1] [2] [3] [4] lists the golf meaning even as a subsidiary meaning, I think we should come up with something more understandable, esp. to non-golf players and non-native English speakers. Suggestions for better terminology would be welcome. I've also pushed a PR cleaning up some of the text. Regards, Jonathan [1] Conti, Mauro, Nicola Dragoni, and Viktor Lesyk. "A survey of man in the middle attacks." *IEEE Communications Surveys & Tutorials* 18.3 (2016): 2027-2051. --000000000000c906ee05b8649b89 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi SAAG,

So I've been thinking about classifyi= ng MITM attacks a little over the winter break, =C3=A0 la draft-richardson= , and did a quick literature survey to see what academia has= to say about MITM attacks, and their variations.

The best paper I found was &quo= t;A survey of man in the middle attacks" [1], which doesn't propo= se any terminology, but does group the attacks.

I think a decent ontology would b= e a useful bit of work.

To that end, I was thinking about what kind of attacks sh= ould be in scope, and thus should unambiguously be captured in a taxonomy. =

Some p= otentially ambiguous examples:

  1. If bo= th endpoints are anonymous, is the attack still a MITM attack? What's = the line between two separate connections and a MITM attack in an anonymous= scenario?

    a. What about in a scenario where identities can= 9;t be verified, such as vehicle-to-vehicle / vehicle-to-environment commu= nications in a remote area?

  2. If I put a probe on a bus am I performing a MITM attac= k? At what point does a MITM attack shade into compromise of the endpoint?<= /span>

  1. In a group chat= scenario does impersonating another user count as a MotS attack? Consider = Alice, Bob, and Carol all legitimately participating in a group chat. If Ca= rol impersonates Bob to Alice (and herself) in the group chat, how would we= describe that attack?

  1. If I stick a malicious QR code over an on-boarding QR code, what ki= nd of MITM attack have I performed?

    a. If Mallory swaps the registration QR codes of two devi= ces, and Alice then registers Bob's device has she performed a MITM att= ack?

Another useful exercise might be to go through the attacks listed= in [1] and check any ontology describes them appropriately. (Finding this = paper online is surprisingly hard, but I'm happy to send anyone a copy.= )

One f= inal question is do we want a strict taxonomy, where each attack fits into = exactly one category, and relationships between attacks are captured by dis= tance in the tree, or do we want a more flexible ontology where we can clas= sify attacks more fuzzily, but still have basic groups?

One comment specific to= the draft is that it currently uses the term "in-the-rough", whi= ch I don't really like.

As a non-golf player "in-the-rough" makes m= e think of precious stones, not a golf metaphor.

Esp. as no dictionary I could fi= nd [1] [2] [3] [4] lists the golf meaning even as = a subsidiary meaning, I think we should come up with something more underst= andable, esp. to non-golf players and non-native English speakers. <= /p>

Suggestions fo= r better terminology would be welcome.

I've also pushed a PR cleaning up some of the text.

<= p class=3D"gmail-md-end-block gmail-md-p" style=3D"box-sizing:border-box;li= ne-height:inherit;margin:0.8em 0px;white-space:pre-wrap;color:rgb(51,51,51)= ;font-family:"Open Sans","Clear Sans","Helvetica N= eue",Helvetica,Arial,sans-serif;font-size:16px;font-style:normal;font-= variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-sp= acing:normal;text-align:start;text-indent:0px;text-transform:none;word-spac= ing:0px;text-decoration-style:initial;text-decoration-color:initial">Regards,

Jonathan<= /p>

[1] Conti, Mau= ro, Nicola Dragoni, and Viktor Lesyk. "A survey of man in the middle a= ttacks." IEEE Communications Surveys & Tutoria= ls 18.3 (2016): 2027-2051.



--000000000000c906ee05b8649b89-- From nobody Tue Jan 12 19:02:04 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E269F3A09B7; Tue, 12 Jan 2021 19:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06O00TOq_1gq; Tue, 12 Jan 2021 19:02:00 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 499F93A09A4; Tue, 12 Jan 2021 19:01:59 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 10D31r5k004465 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 12 Jan 2021 22:01:57 -0500 Date: Tue, 12 Jan 2021 19:01:52 -0800 From: Benjamin Kaduk To: Yakov Shafranovich Cc: draft-foudil-securitytxt@ietf.org, Security Area Advisory Group Message-ID: <20210113030152.GD161@kduck.mit.edu> References: <20200630222455.GX58278@kduck.mit.edu> <20200721054121.GE41010@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200721054121.GE41010@kduck.mit.edu> Archived-At: Subject: Re: [saag] results of IETF LC for draft-foudil-securitytxt-08 and next steps X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Jan 2021 03:02:02 -0000 Hi Yakov, all, On Mon, Jul 20, 2020 at 10:41:21PM -0700, Benjamin Kaduk wrote: > > On Sun, Jul 12, 2020 at 08:14:33PM -0400, Yakov Shafranovich wrote: > > > > All of the changes I am making are going into this pull request: > > https://github.com/securitytxt/security-txt/pull/192 > > Thanks for the pointer; I've left that tab open and will try to take a look > tomorrow/in the morning. [the updates did land fairly shortly thereafter] I've gotten a chance to look over the updates in the -09 and -10, and I currently believe that they are responsive to the comments received during the last call, and especially so to my summary/next steps assessment after the last call had completed. Accordingly, I plan to move forward with IESG Evaluation for it. To SAAG: if you feel that your review comments were not adequately addressed, please let me know, and I will be happy to discuss them further with you. Thanks, Ben From nobody Thu Jan 21 09:32:56 2021 Return-Path: X-Original-To: saag@ietf.org Delivered-To: saag@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A8C13A1263; Thu, 21 Jan 2021 09:32:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: kaduk@mit.edu, saag-chairs@ietf.org, saag@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161125037416.14690.11937870554681788584@ietfa.amsl.com> Date: Thu, 21 Jan 2021 09:32:54 -0800 Archived-At: Subject: [saag] saag - New Meeting Session Request for IETF 110 X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jan 2021 17:32:54 -0000 A new meeting session request has just been submitted by Benjamin Kaduk, a Chair of the saag working group. --------------------------------------------------------- Working Group Name: Security Area Open Meeting Area Name: Security Area Session Requester: Benjamin Kaduk Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 150 Conflicts to Avoid: Chair Conflict: ace acme cfrg cose curdle dots emu gnap i2nsf ipsecme kitten lake lamps mls oauth openpgp privacypass rats sacm secdispatch secevent suit teep tls tokbind trans Technology Overlap: dmarc dprive sidrops uta pearg Key Participant Conflict: irtfopen People who must be present: Roman Danyliw Benjamin Kaduk Resources Requested: Special Requests: Normally we ask for Thursday "after lunch", but for the virtual meeting any time on Thursday should be fine. --------------------------------------------------------- From nobody Sun Jan 31 13:46:32 2021 Return-Path: X-Original-To: saag@ietfa.amsl.com Delivered-To: saag@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2DBF3A1295; Sun, 31 Jan 2021 13:46:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xC6cVBljUVLF; Sun, 31 Jan 2021 13:46:25 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFBBB3A1294; Sun, 31 Jan 2021 13:46:24 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 10VLk7fL032521 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 31 Jan 2021 16:46:12 -0500 Date: Sun, 31 Jan 2021 13:46:07 -0800 From: Benjamin Kaduk To: mcgrew@cisco.com Cc: iesg@ietf.org, jordan@certainlyawesome.com, RFC Errata System , saag@ietf.org Message-ID: <20210131214607.GT21@kduck.mit.edu> References: <20210129033026.E8D46F40714@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210129033026.E8D46F40714@rfc-editor.org> Archived-At: Subject: Re: [saag] [Technical Errata Reported] RFC5116 (6415) X-BeenThere: saag@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Security Area Advisory Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Jan 2021 21:46:27 -0000 On Thu, Jan 28, 2021 at 07:30:26PM -0800, RFC Errata System wrote: > The following errata report has been submitted for RFC5116, > "An Interface and Algorithms for Authenticated Encryption". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6415 > > -------------------------------------- > Type: Technical > Reported by: Jordan Smith > > Section: 3.2 > > Original Text > ------------- > Implementations > SHOULD support 12-octet nonces in which the Counter field is four > octets long. > > Corrected Text > -------------- > Implementations > SHOULD support 12-octet nonces in which the Fixed field is four > octets long. I think it's pretty hard to make an argument that the statement is not what was intended at the time based solely on the relative lengths of fields in the figure. There are different considerations for when one wants a larger fixed of counter portion, and a change that is in effect retroactively attempting to change the stated preference seems hard to argue for via the errata system. Accordingly, I propose to mark this as rejected since there does not seem to be clear evidence that the original text is not what was intended. -Ben > Notes > ----- > The ascii diagram given shows the Fixed portion being smaller and the examples given in https://tools.ietf.org/id/draft-mcgrew-iv-gen-01.html also show that the Fixed portion is 4 bytes. > > Also an 8 byte counter gives 2^64, where a 4 byte counter would only give 2^32 > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC5116 (draft-mcgrew-auth-enc-05) > -------------------------------------- > Title : An Interface and Algorithms for Authenticated Encryption > Publication Date : January 2008 > Author(s) : D. McGrew > Category : PROPOSED STANDARD > Source : IETF - NON WORKING GROUP > Area : N/A > Stream : IETF > Verifying Party : IESG >