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

[Stephen Farrell <[e-mail]>]

Hi,

I've read through the text and am fine with this being
published. (Though I'm also fine re-confirming that if
needed when all changes are done.)

Responses to the points specific to my text, or to bits
others mightn't cover, below:

On 12/07/2023 00:00, [e-mail] wrote:
> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in the title) for use on https://www.rfc-editor.org/search. -->

I guess "pervasive monitoring" "privacy" "security" would be
good keywords.

> 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 ...
> -->

I prefer the original, which seems sufficiently clear to me
so would rather not make that change.

> 
> 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>.
> -->

Fine change.

> 
> 
> 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>.
> -->

That also seems like a good set of changes.


> 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>.
> -->

Again, I think that's fine.

> 
> 
> 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>.
> -->

Good catch! I forgot that the MPLS WG adopted the work
(before it fizzled;-(). Referring to the WG draft is better
yes, so please do make that change.

I note your text above says "normative references" but of
course there are none for this document and the document
text itself is correct.

> 
> 
> 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>.
> -->

I think that's also fine.

> 
> 
> 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.
> -->

I think we're good in that respect.

Cheers,
Stephen.

> 
> 
> 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) :
> 
>