Re: [auth48] [ISE] Re: AUTH48: RFC-to-be 9446 <draft-farrell-tenyearsafter-05> for your review

[farzaneh badii <[e-mail]>]

See my answers in line for section 4 and my comment on how my name can be
cited.

Farzaneh


On Tue, Jul 11, 2023 at 7:00 PM <[e-mail]> wrote:

> Authors,
>
> While reviewing this document during AUTH48, please resolve (as necessary)
> the following questions, which are also in the XML file.
>
> * Eliot (as ISE), please see #3 below.
>
> 1) <!-- [rfced] Steven, do you prefer your initials to be displayed as
> "S." or "S. M." in the header of the document?
>
> -->
>
>
> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in
> the title) for use on https://www.rfc-editor.org/search. -->
>
>
> 3) <!-- [rfced] Abstract. Elliot, given the following in the
> Acknowledgments section: "that of course doesn't mean that they necessarily
> agree with the text", should the Abstract or the Introduction have a
> disclaimer such as "The views expressed in this memo are those of the
> authors"?
> -->
>
>
> 4) <!-- [rfced] Introduction. Does clarifying what caused the sea change
> in the suggested text below improve the readability of the following
> sentence?
>
> Original:
>    The breathtaking scope of the operations
>    shocked the Internet technical community that was reflected in a sea
>    change within the IETF, IAB, and other standards organizations.
>
> Perhaps:
>    The breathtaking scope of the operations
>    shocked the Internet technical community, and this shock caused a sea
>    change within the IETF, IAB, and other standards organizations.
> -->
>
>
> 5) <!--[rfced] Section 2. Please consider how the passage regarding Jacob
> Appelbaum could be improved by providing more details.  Was Appelbaum's
> work with Poitras the films, "Citizenfour" and "Risk"?  The clause "who had
> not yet been accused of sexual assault by multiple women" seems unnecessary
> here. Should it be dropped?
>
> Is there a reference that can be added to support the claim that Appelbaum
> received the implant catalog from someone besides Snowden? If no supporting
> references can be added, could the passage instead focus on Appelbaum's
> reporting and the impact it had? Perhaps add a reference to <
> https://www.spiegel.de/international/world/the-nsa-uses-powerful-toolbox-in-effort-to-spy-on-global-networks-a-940969.html>
> or <
> https://www.spiegel.de/international/world/nsa-secret-toolbox-ant-unit-offers-spy-gadgets-for-every-need-a-941006.html>.
> Or perhaps the focus should be on the implant catalog and your analysis <
> https://www.schneier.com/tag/exploit-of-the-day/>?
>
> Original:
>
>    Jake Appelbaum, who
>    had not yet been accused of sexual assault by multiple women, was
>    working with Poitras.  He partnered with Spiegel to release an
>    implant catalog from the NSA’s Tailored Access Operations group.  To
>    this day, I am convinced that that document was not in the Snowden
>    archives: that Jake got it somehow, and it was released with the
>    implication that it was from Edward Snowden.
> -->
>
>
> 6) <!-- [rfced] Section 2. Please provide expansions for the conference
> acronyms in the sentence below:
>
> Current:
>    When I got back from Rio, I gave talks at a private conference in
>    Woods Hole, the Berkman Center at Harvard, something called the
>    Congress and Privacy and Surveillance in Geneva, events at both CATO
>    and New America in DC, an event at the University of Pennsylvania, an
>    event at EPIC, a "Stop Watching Us" rally in DC, the RISCS conference
>    in London, the ISF in Paris
> -->
>
>
> 7) <!-- [rfced] Section 2. Would you like to provide a short list of
> examples here, or should the phrase "for example" be removed from the last
> sentence of the paragraph?
>
> Original:
>    What struck me at the IETF was the indignation in the room, and the
>    calls to action.  And there was action, across many fronts.  We
>    technologists did a lot to help secure the Internet, for example.
> -->
>
>
> 8) <!-- [rfced] Section 3. Does rewording the following to focus on IETF
> participants improve the readability of the sentence?
>
> Original:
>    As for the IETF's reaction, informal meetings during the July 2013
>    IETF meeting in Berlin indicated that IETF participants considered
>    that these revelations showed that we needed to do more to improve
>    the security and privacy properties of IETF protocols ...
>
> Perhaps:
>    As for the IETF's reaction, IETF participants met informally during
>    the July 2013 IETF meeting in Berlin to discuss these revelations,
>    which showed that we needed to do more to improve the security and
>    privacy properties of IETF protocols ...
> -->
>
>
> 9) <!-- [rfced] Section 4. Does the following sentence say that policies
> and technical means have not been used to positively impact human rights
> and that the Snowden revelations didn't revolutionize the use of policies
> and technical means to do so? To whom does "our" refer to?
>
> Original:
>    Snowden revelations did not have a
>    revolutionary effect on our approach towards not using policies and
>    technical means that have an effect on human rights, such as freedom
>    of expression, freedom of association and assembly and privacy.
>
> Possibly:
>    The Snowden revelations did not revolutionize the use of policies
>    a technical means to support human rights such as freedom
>    of expression, freedom of association and assembly, and privacy.
> -->
>
Maybe: The Snowden revelations did not revolutionize the Internet
governance and technical approaches to support human rights such as freedom
   of expression, freedom of association and assembly, and privacy.

>
>
> 10) <!-- [rfced] Section 4. FYI, the first sentence below is a fragment.
Please let us know how to update it.

Original:
   A range of European Union laws that aims to
   address online safety or concentration of data.  There are many more
   regulations that have an impact on the Internet.

Perhaps:
   A range of European Union laws aims to
   address online safety or concentration of data. There are many more
   regulations that have an impact on the Internet.
-->
That's good thanks.

>
>
> 11) <!-- [rfced] Section 4. Does the following suggestion improve the
> readability of the passage?
>
> Original:
>    It might have also expedited and helped with
>    more easily convening the Human Rights Protocol Considerations
>    research group in the Internet Research Task Force (IRTF).  Co-
>    chaired by Niels ten Oever (who worked at Article 19 at the time) and
>    Internet governance activist Avri Doria, the Internet Research Task
>    Force in July 2015 chartered a Research Group on "Human Rights
>    Protocol Considerations" (the HRPC RG).  The charter of the HRPC RG
>    stated that the group was established: "to research whether standards
>    and protocols can enable, strengthen or threaten human rights, as
>    defined in the UDHR and the International Covenant on Civil and
>    Political Rights (ICCPR)."
>
> Perhaps (removing some redundant text, clarifying that ten Oever and
> Doria co-chaired the RG originally, and expanding UDHR):
>    It might have also expedited and helped with
>    more easily convening the Human Rights Protocol Considerations
>    Research Group (HRPC RG) in the Internet Research Task Force (IRTF)
>    in July 2015. The HRPC RG was originally co-chaired by Niels ten
>    Oever (who worked at Article 19 at the time) and Internet governance
>    activist Avri Doria. The charter of the HRPC RG states that the group
>    was established: "to research whether standards and protocols can
>    enable, strengthen, or threaten human rights, as defined in the
>    Universal Declaration of Human Rights (UDHR) and the International
>    Covenant on Civil and Political Rights (ICCPR)."
> -->
>
Great change

>
>
> 12) <!-- [rfced] Section 4. Please help us clarify the following
> sentence.  Does DoH contribute to the fight against censorship?
>
> Original:
>    For instance, we still have doubts about implementing DNS over HTTPS
>    without seriously considering its contributions to fight with
>    censorship and bring encryption to DNS queries.
> --> For instance, the technical community and some network operators
> still have doubts about implementation of DNS over HTTPS, despite its
> potential to circumvent censorship and its ability to encrypt DNS queries.
>
>
> 13) <!-- [rfced] Section 5.1. Regarding the following note to the RFC
> Editor:
>
>    Also, the authors have requested that you provide specific guidance on
>    the spelling of arabic names, specifically those in the following
>    sentence:
>
>    In the 9th century, Abu Yusuf Ya’qub ibn ‘Ishaq aṣ-Ṣabbah al-
>    Kindh developed and wrote about frequency analysis as a way to crack
>    ciphers [Borda2011],[Kahn1996].
>
> Our research indicates that the following is the more typical spelling
> found in English, and we have updated the document accordingly:
>
>    Abū Yūsuf Yaʻqūb ibn ʼIsḥāq aṣ-Ṣabbāḥ al-Kindī
> -->
>
>
> 14) <!-- [rfced] Section 5.2. Does the following update to reword "that
> that" improve the readability of the sentence?
>
> Original:
>    NSA denied tampering with the design; a
>    Senate investigating committee found that that was correct...
>
> Perhaps:
>    NSA denied tampering with the design; a
>    Senate investigating committee found that assertion to be
>    correct...
> -->
>
>
> 15) <!-- [rfced] Informative References. FYI, we have provided proceedings
> information for the following. Please let us know if any updates are
> necessary.
>
> Original:
>    [LE]       Aas, J., Barnes, R., Case, B., Durumeric, Z., Eckersley,
>               P., Flores-López, A., Halderman, A., Hoffman-Andrews, J.,
>               Kasten, J., Rescorla, E., Schoen, S. D., and B. Warren,
>               "Let's Encrypt - an automated certificate authority to
>               encrypt the entire web", 2019,
>               <https://dl.acm.org/doi/pdf/10.1145/3319535.3363192>.
>
> Current:
>    [LE]       Aas, J., Barnes, R., Case, B., Durumeric, Z., Eckersley,
>               P., Flores-López, A., Halderman, A., Hoffman-Andrews, J.,
>               Kasten, J., Rescorla, E., Schoen, S. D., and B. Warren,
>               "Let's Encrypt: An Automated Certificate Authority to
>               Encrypt the Entire Web", CCS '19: Proceedings of the 2019
>               ACM SIGSAC Conference on Computer and Communications
>               Security, November 2019,
>               <https://dl.acm.org/doi/pdf/10.1145/3319535.3363192>.
> -->
>
>
> 16) <!-- [rfced] Informative References. We note that the URLs provided
> for ACM publications are inconsistent. Some point to acm.org; others
> point to personal websites. May be update the URLs to point to acm.org?
> The PDFs are freely available from that site.
>
> Original:
>    [Adrian2015]
>               Adrian, D., Bhargavan, K., Durumeric, Z., Gaudry, P.,
>               Green, M., Halderman, J. A., and N. Heninger, "Imperfect
>               Forward Secrecy: How Diffie-Hellman Fails in Practice.",
>               Proceedings of the 22th ACM Conference on Computer and
>               Communications Security (CCS), 2015,
>               <https://weakdh.org/imperfect-forward-secrecy.pdf>.
>
>    [Blaze1994]
>               Blaze, M., "Protocol Failures in the Escrowed Encryption
>               Standard", Proceedings of Second ACM Conference on
>               Computer and Communications Security, 1994,
>               <http://www.mattblaze.org/papers/eesproto.pdf>.
>
>    [Checkoway2016]
>               Checkoway, S., Maskiewicz, J., Garman, C., Fried, J.,
>               Cohney, S., Green, M., Heninger, N., Weinmann, R. P.,
>               Rescorla, E., and Hovav Shacham, "A Systematic Analysis of
>               the Juniper Dual EC Incident", Proceedings of the 2016 ACM
>               SIGSAC Conference on Computer and Communications
>               Security 468-79, 2016,
>               <https://dl.acm.org/citation.cfm?id=2978395>.
>
>    [LE]       Aas, J., Barnes, R., Case, B., Durumeric, Z., Eckersley,
>               P., Flores-López, A., Halderman, A., Hoffman-Andrews, J.,
>               Kasten, J., Rescorla, E., Schoen, S. D., and B. Warren,
>               "Let's Encrypt - an automated certificate authority to
>               encrypt the entire web", 2019,
>               <https://dl.acm.org/doi/pdf/10.1145/3319535.3363192>.
> -->
>
>
> 17) <!-- [rfced] Informative References. We note that the author's name
> for "Sanctions and the Internet" is given as Farzaneh Badiei. We have
> updated the author information to match the document, but have left the
> cite tag as [Badii2023].  Please let us know if any updates are necessary.
>
> Original:
>    [Badii2023]
>               Badii, F., "Sanctions and the Internet", 2023,
>               <https://digitalmedusa.org/wp-content/uploads/2023/05/
>               SanctionsandtheInternet-DigitalMedusa.pdf>.
>
> Current:
>    [Badii2023]
>               Badiei, F., "Sanctions and the Internet", Digital Medusa,
>               2023, <https://digitalmedusa.org/wp-
>               content/uploads/2023/05/SanctionsandtheInternet-
>               DigitalMedusa.pdf>.
> -->
>
No update is necessary. I prefer Badii but legally I have to use Badiei as
they transliterated my name wrong in my passport.

>
>
> 18) <!-- [rfced] Normative References. FYI, RFC 7540 has been obsoleted by
> RFC 9113.  We have updated the reference. Please let us know if any changes
> are necessary.
>
> Original:
>    [RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
>               Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
>               DOI 10.17487/RFC7540, May 2015,
>               <https://www.rfc-editor.org/info/rfc7540>.
>
> Current:
>    [RFC9113]  Thomson, M., Ed. and C. Benfield, Ed., "HTTP/2", RFC 9113,
>               DOI 10.17487/RFC9113, June 2022,
>               <https://www.rfc-editor.org/info/rfc9113>.
> -->
>
>
> 19) <!-- [rfced] Normative References. The I-D
> draft-farrelll-mpls-opportunistic-encrypt was replaced by
> draft-ietf-mpls-opportunistic-encrypt (also expired). Would you like to
> update the reference?
>
> Original:
>    Of course, not all such initiatives bore fruit, for example attempts
>    to define a new MPLS encryption mechanism
>    [I-D.farrelll-mpls-opportunistic-encrypt] foundered due to a lack of
>    interest and the existence of the already deployed IEEE MACSEC
>    scheme.
>
>    [I-D.farrelll-mpls-opportunistic-encrypt]
>               Farrel, A. and S. Farrell, "Opportunistic Security in MPLS
>               Networks", Work in Progress, Internet-Draft, draft-
>               farrelll-mpls-opportunistic-encrypt-05, 17 June 2015,
>               <https://datatracker.ietf.org/doc/html/draft-farrelll-
>               mpls-opportunistic-encrypt-05>.
> -->
>
>
> 20) <!-- [rfced] Informative References. FYI, RFC 7484 has been obsoleted
> by RFC 9224.  We have updated the reference accordingly. Please let us know
> if any updates are necessary.
>
> Original:
>    [RFC7484]  Blanchet, M., "Finding the Authoritative Registration Data
>               (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March
>               2015, <https://www.rfc-editor.org/info/rfc7484>.
>
> Current:
>
>    [RFC9224]  Blanchet, M., "Finding the Authoritative Registration Data
>               Access Protocol (RDAP) Service", STD 95, RFC 9224,
>               DOI 10.17487/RFC9224, March 2022,
>               <https://www.rfc-editor.org/info/rfc9224>.
> -->
>
>
> 21) <!-- [rfced] Terminology. Please review the "Inclusive Language"
> portion of the online Style Guide <
> https://www.rfc-editor.org/styleguide/part2/#inclusive_language> and let
> us know if any changes are needed.  For example, please consider whether
> the following should be updated: dummy, dumb, black bag, etc.
> -->
>
>
> Thank you.
>
> RFC Editor/jm
>
>
>
> On 7/11/23 5:55 PM, [e-mail] wrote:
>
> *****IMPORTANT*****
>
> Updated 2023/07/11
>
> RFC Author(s):
> --------------
>
> Instructions for Completing AUTH48
>
> Your document has now entered AUTH48.  Once it has been reviewed and
> approved by you and all coauthors, it will be published as an RFC.
> If an author is no longer available, there are several remedies
> available as listed in the FAQ (https://www.rfc-editor.org/faq/).
>
> You and you coauthors are responsible for engaging other parties
> (e.g., Contributors or Working Group) as necessary before providing
> your approval.
>
> Planning your review
> ---------------------
>
> Please review the following aspects of your document:
>
> *  RFC Editor questions
>
>    Please review and resolve any questions raised by the RFC Editor
>    that have been included in the XML file as comments marked as
>    follows:
>
>    <!-- [rfced] ... -->
>
>    These questions will also be sent in a subsequent email.
>
> *  Changes submitted by coauthors
>
>    Please ensure that you review any changes submitted by your
>    coauthors.  We assume that if you do not speak up that you
>    agree to changes submitted by your coauthors.
>
> *  Content
>
>    Please review the full content of the document, as this cannot
>    change once the RFC is published.  Please pay particular attention to:
>    - IANA considerations updates (if applicable)
>    - contact information
>    - references
>
> *  Copyright notices and legends
>
>    Please review the copyright notice and legends as defined in
>    RFC 5378 and the Trust Legal Provisions
>    (TLP – https://trustee.ietf.org/license-info/).
>
> *  Semantic markup
>
>    Please review the markup in the XML file to ensure that elements of
>    content are correctly tagged.  For example, ensure that <sourcecode>
>    and <artwork> are set correctly.  See details at
>    <https://authors.ietf.org/rfcxml-vocabulary>.
>
> *  Formatted output
>
>    Please review the PDF, HTML, and TXT files to ensure that the
>    formatted output, as generated from the markup in the XML file, is
>    reasonable.  Please note that the TXT will have formatting
>    limitations compared to the PDF and HTML.
>
>
> Submitting changes
> ------------------
>
> To submit changes, please reply to this email using ‘REPLY ALL’ as all
> the parties CCed on this message need to see your changes. The parties
> include:
>
>    *  your coauthors
>
>    *  [e-mail] (the RPC team)
>
>    *  other document participants, depending on the stream (e.g.,
>       IETF Stream participants are your working group chairs, the
>       responsible ADs, and the document shepherd).
>
>    *  [e-mail], which is a new archival mailing list
>       to preserve AUTH48 conversations; it is not an active discussion
>       list:
>
>      *  More info:
>
> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc
>
>      *  The archive itself:
>         https://mailarchive.ietf.org/arch/browse/auth48archive/
>
>      *  Note: If only absolutely necessary, you may temporarily opt out
>         of the archiving of messages (e.g., to discuss a sensitive matter).
>         If needed, please add a note at the top of the message that you
>         have dropped the address. When the discussion is concluded,
>         [e-mail] will be re-added to the CC list and
>         its addition will be noted at the top of the message.
>
> You may submit your changes in one of two ways:
>
> An update to the provided XML file
>  — OR —
> An explicit list of changes in this format
>
> Section # (or indicate Global)
>
> OLD:
> old text
>
> NEW:
> new text
>
> You do not need to reply with both an updated XML file and an explicit
> list of changes, as either form is sufficient.
>
> We will ask a stream manager to review and approve any changes that seem
> beyond editorial in nature, e.g., addition of new text, deletion of text,
> and technical changes.  Information about stream managers can be found in
> the FAQ.  Editorial changes do not require approval from a stream manager.
>
>
> Approving for publication
> --------------------------
>
> To approve your RFC for publication, please reply to this email stating
> that you approve this RFC for publication.  Please use ‘REPLY ALL’,
> as all the parties CCed on this message need to see your approval.
>
>
> Files
> -----
>
> The files are available here:
>    https://www.rfc-editor.org/authors/rfc9446.xml
>    https://www.rfc-editor.org/authors/rfc9446.html
>    https://www.rfc-editor.org/authors/rfc9446.pdf
>    https://www.rfc-editor.org/authors/rfc9446.txt
>
> Diff file of the text:
>    https://www.rfc-editor.org/authors/rfc9446-diff.html
>    https://www.rfc-editor.org/authors/rfc9446-rfcdiff.html (side by side)
>
> Diff of the XML:
>    https://www.rfc-editor.org/authors/rfc9446-xmldiff1.html
>
> The following files are provided to facilitate creation of your own
> diff files of the XML.
>
> Initial XMLv3 created using XMLv2 as input:
>    https://www.rfc-editor.org/authors/rfc9446.original.v2v3.xml
>
> XMLv3 file that is a best effort to capture v3-related format updates
> only:
>    https://www.rfc-editor.org/authors/rfc9446.form.xml
>
>
> Tracking progress
> -----------------
>
> The details of the AUTH48 status of your document are here:
>    https://www.rfc-editor.org/auth48/rfc9446
>
> Please let us know if you have any questions.
>
> Thank you for your cooperation,
>
> RFC Editor
>
> --------------------------------------
> RFC9446 (draft-farrell-tenyearsafter-05)
>
> Title            : Reflections on Ten Years Past The Snowden Revelations
> Author(s)        : S. Farrell, F. Badii, B. Schneier, S. Bellovin
> WG Chair(s)      :
> Area Director(s) :
>
>
>