Skip to main content

Header Protection for Cryptographically Protected E-mail
draft-ietf-lamps-header-protection-25

Revision differences

Document history

Date Rev. By Action
2025-01-22
25 (System) IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor
2025-01-22
25 (System) IANA Action state changed to Waiting on RFC Editor from In Progress
2025-01-22
25 (System) IANA Action state changed to In Progress from Waiting on Authors
2025-01-14
25 (System) IANA Action state changed to Waiting on Authors from In Progress
2025-01-10
25 (System) RFC Editor state changed to EDIT
2025-01-10
25 (System) IESG state changed to RFC Ed Queue from Approved-announcement sent
2025-01-10
25 (System) Announcement was received by RFC Editor
2025-01-10
25 (System) IANA Action state changed to In Progress
2025-01-09
25 (System) Removed all action holders (IESG state changed)
2025-01-09
25 Cindy Morgan IESG state changed to Approved-announcement sent from Approved-announcement to be sent
2025-01-09
25 Cindy Morgan IESG has approved the document
2025-01-09
25 Cindy Morgan Closed "Approve" ballot
2025-01-09
25 Cindy Morgan Ballot approval text was generated
2025-01-09
25 Roman Danyliw IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup
2025-01-06
25 Daniel Gillmor New version available: draft-ietf-lamps-header-protection-25.txt
2025-01-06
25 Daniel Gillmor New version accepted (logged-in submitter: Daniel Gillmor)
2025-01-06
25 Daniel Gillmor Uploaded new revision
2024-11-21
24 Cindy Morgan IESG state changed to Approved-announcement to be sent::AD Followup from IESG Evaluation
2024-11-21
24 Paul Wouters
[Ballot comment]
Thanks for this document. I hope the length of it does not deter people from implementing it properly by skimming it (as in, …
[Ballot comment]
Thanks for this document. I hope the length of it does not deter people from implementing it properly by skimming it (as in, I wish it had been shorter)

I just have a few comments/nits:

        Such a Legacy Display Element need not be rendered to the user
        of an MUA that implements this specification, because the MUA
        already knows the correct Header Field information, and can
        render it to the user in the appropriate part of the MUA's user
        interface rather than in the body of the message.

"need not" is not 2119 language. Since the legacy display element can
be forged, should this not be a MUST NOT be rendered on non-legacy clients?

        If a non-structural Header Field name Z is present in Header
        Section of the Cryptographic Payload, but doesn't appear in an
        HP-Outer Header Field value at all, then the sender is effectively
        asserting that every instance of Z was made confidential

Should this say something that thus, if a Header Field name Z is present
in the outer Header Section, that it means it is forged and/or added by
an MTA, not the MUA? And maybe MUST NOT be rendered in any way?
(section 4 states this somewhat)

        If the signature fails validation, the MUA lowers the affected
        state to unprotected or encrypted-only without warning the user,
        as specified by Section 3.1 of [I-D.ietf-lamps-e2e-mail-guidance].

I wonder why a signature failure is not a "warn the user" event?
It is not the same as "unprotected", but this document tells people to treat
it as such?

Section 4.4.2: why not MUSTs instead of SHOULDs ?

        The algorithm returns a MIME object that is ready to be injected
        into the mail system.

mail message instead of mail system?


[I-D.ietf-openpgp-crypto-refresh-13] needs to be updated to RFC 9580

Section 10:

Why shouldn't a MUA always alert with a big warning when there is a From
mismatch in any way (inner, outer, HP-outer) ? Or could it display something
like "Paul Forged Wouters  on behave of someone_else@foo.com"

Section 12.2 could be written much shorter - the target audience is IANA
after all and they are experts in what they do :P



NITS:

Some combination terms are partially bolded, eg "SPECIFICATION REQUIRED".
2024-11-21
24 Paul Wouters [Ballot Position Update] New position, Yes, has been recorded for Paul Wouters
2024-11-21
24 Zaheduzzaman Sarker [Ballot comment]
Thanks for working on this specification.
2024-11-21
24 Zaheduzzaman Sarker [Ballot Position Update] New position, Yes, has been recorded for Zaheduzzaman Sarker
2024-11-21
24 Éric Vyncke
[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-avtcore-rtp-scip-05

Thank you for the work put into this document. It is very well written with …
[Ballot comment]

# Éric Vyncke, INT AD, comments for draft-ietf-avtcore-rtp-scip-05

Thank you for the work put into this document. It is very well written with an easy to read and useful introduction (the whole section 1).

Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education).

Special thanks to Russ Housley for the shepherd's detailed write-up including the WG consensus *but it lacks* the justification of the intended status (especially in the absence of implementations).

I hope that this review helps to improve the document,

Regards,

-éric


# COMMENTS (non-blocking)

## Section 1.4

MUA acronym is expanded before first use but not MTA.

## Section 1.8

s/This document describes/This document specifies/ (as its intended status is PS).

## Section 3

A text explaining *WHY* there must be a HCP registry (rather than giving some HPC examples) would be welcome. I fail to see the purpose of the registry. Even section 12.3 does not help a lot.

## Section 3.2.1

Does the use of '[...]' in hcp_baseline() make it trivial to detect (hence potentially block/monitor) protected e-mail messages ?

## Section 8

What is `e-mail ecosystem` ? I.e., some examples or a definition would help the reader.

## Section 8.2

Thanks for hinting to the operational considerations in `Many MTA operators today would ask for additional guarantees about such a message to limit the risks associated with abusive or spammy mail.`.
2024-11-21
24 Éric Vyncke [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke
2024-11-21
24 Francesca Palombini [Ballot Position Update] New position, No Objection, has been recorded for Francesca Palombini
2024-11-20
24 Amanda Baber IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2024-11-20
24 David Dong
The expert has approved the Permanent Message Header Field Names registrations with the following comment:
Looks fine to me. I’m assuming that the security and …
The expert has approved the Permanent Message Header Field Names registrations with the following comment:
Looks fine to me. I’m assuming that the security and other detailed technical aspects have been adequately considered by the WG and IESG.
2024-11-20
24 David Dong IANA Experts State changed to Expert Reviews OK from Reviews assigned
2024-11-20
24 Deb Cooley
[Ballot comment]

This is not a comment that requires addressing.  It is more of an opinion:

While this is a complex topic, the authors have …
[Ballot comment]

This is not a comment that requires addressing.  It is more of an opinion:

While this is a complex topic, the authors have done a fantastic job to make it clear and understandable.  Protected email (signed or signed and encrypted) is sadly a pretty niche idea, let alone protecting the headers that go with it.  I would love for this to change, maybe the e2e email guidance draft and this draft will help.
2024-11-20
24 Deb Cooley Ballot comment text updated for Deb Cooley
2024-11-20
24 Deb Cooley
[Ballot comment]

While this is a complex topic, the authors have done a fantastic job to make it clear and understandable.  Protected email (signed or …
[Ballot comment]

While this is a complex topic, the authors have done a fantastic job to make it clear and understandable.  Protected email (signed or signed and encrypted) is sadly a pretty niche idea, let alone protecting the headers that go with it.  I would love for this to change, maybe the e2e email guidance draft and this draft will help.
2024-11-20
24 Deb Cooley [Ballot Position Update] New position, Yes, has been recorded for Deb Cooley
2024-11-19
24 Jim Guichard [Ballot Position Update] New position, No Objection, has been recorded for Jim Guichard
2024-11-18
24 John Scudder [Ballot Position Update] New position, No Objection, has been recorded for John Scudder
2024-11-18
24 Warren Kumari
[Ballot comment]
Thank you for this document; much of this is outside my areas of expertise, but it seems reasonable from the bits that I …
[Ballot comment]
Thank you for this document; much of this is outside my areas of expertise, but it seems reasonable from the bits that I was able to understand :-)

I have a few nits to offer:
1: These stumbling blocks with Legacy MUAs, missing mechanisms, and missing guidance create a strong disincentive for existing MUAs generate messages using RFC8551HP.
P: "to generate"

2: "A sending implementation MUST NOT produce a Cryptographic Payload with parameter hp="cipher" for an non-encrypted message"
P: "for a non-encrypted"

3: "We call such converted version (or the original domain, if it didn't contain any U-label) "the ASCII version of the domain part".
P: "We call such a converted" -- I still don't like this. Perhaps "We call a version converted like this (..." ?


Sorry I don't have more to offer...
2024-11-18
24 Warren Kumari [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari
2024-11-16
24 Erik Kline [Ballot Position Update] New position, No Objection, has been recorded for Erik Kline
2024-11-14
24 Orie Steele
[Ballot comment]
I had previously a discuss that was changed to no objection:

https://mailarchive.ietf.org/arch/msg/spasm/2jaMNrdHPYFd-Ck-tH9DZrvewIQ/

I reviewed the diff since then: https://author-tools.ietf.org/iddiff?url1=draft-ietf-lamps-header-protection-21&url2=draft-ietf-lamps-header-protection-24&difftype=--hwdiff

I note the IANA review is still needed.
2024-11-14
24 Orie Steele [Ballot Position Update] New position, No Objection, has been recorded for Orie Steele
2024-11-14
24 Gunter Van de Velde [Ballot comment]
There is an IANA not OK statement which i assume will be addressed timely
2024-11-14
24 Gunter Van de Velde [Ballot Position Update] New position, No Objection, has been recorded for Gunter Van de Velde
2024-11-12
24 David Dong IANA Experts State changed to Reviews assigned from Expert Reviews OK
2024-11-11
24 Roman Danyliw Placed on agenda for telechat - 2024-11-21
2024-11-11
24 Roman Danyliw Ballot has been issued
2024-11-11
24 Roman Danyliw [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw
2024-11-11
24 Roman Danyliw Ballot writeup was changed
2024-11-11
24 Roman Danyliw Ballot approval text was generated
2024-11-11
24 Roman Danyliw Created "Approve" ballot
2024-11-11
24 Roman Danyliw Closed "Approve" ballot
2024-11-11
24 Roman Danyliw Ballot has been issued
2024-11-11
24 Roman Danyliw IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead
2024-11-11
24 Roman Danyliw Ballot writeup was changed
2024-11-11
24 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2024-11-09
24 Russ Mundy Request for Last Call review by SECDIR Completed: Ready. Reviewer: Russ Mundy. Sent review to list. Submission of review completed at an earlier date.
2024-11-09
24 Russ Mundy Request for Last Call review by SECDIR Completed: Ready. Reviewer: Russ Mundy.
2024-11-08
24 David Dong
IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-lamps-header-protection-24. If any part of this review is inaccurate, please let us know.

IANA understands that, upon …
IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-lamps-header-protection-24. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are three actions which we must complete.

First, in the Permanent Message Header Field Names registry in the Message Headers registry group located at:

https://www.iana.org/assignments/message-headers/

one new Header Field will be registered as follows:

Header Field Name: HP-Outer
Template:
Protocol: mail
Status: standard
Reference: [ RFC-to-be; Section 2.2.1 ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, also in the Permanent Message Header Field Names registry in the Message Headers registry group located at:

https://www.iana.org/assignments/message-headers/

the existing registration for:

Header Field Name: Content-Type
Template:
Protocol: MIME
Status:
Reference: [ RFC4021 ]

will have [ RFC-to-be ] added to the reference as follows:

Header Field Name: Content-Type
Template:
Protocol: MIME
Status:
Reference: [ RFC4021 ][ RFC-to-be ]

Third, a new registry is to be created called the Mail Header Confidentiality Policies registry. The new registry will be located in the MAIL Parameters registry group located at:

https://www.iana.org/assignments/mail-parameters/

The new registry will be managed via the following registry policy:

Adding an entry to this registry with an N in the "Recommended" column follows the registration policy of Specification Required. Adding an entry to this registry with a Y in the "Recommended" column or changing the "Recommended" column in an existing entry (from N to Y or vice versa) requires IETF Review. During IETF Review, the designated expert must also be consulted.

A note will be added to the registry as follows:

The Header Confidentiality Policy Name never appears on the wire. This registry merely tracks stable references to implementable descriptions of distinct policies. Any addition to this registry should be governed by guidance in Section 2.4.4.1 of [ RFC-to-be ].

There are initial registrations in the new registry as follows:

Header
Confidentiality
Policy Name Description Reference Recommended
-------------+----------+----------+---------------
hcp_no_confidentiality No header confidentiality Section 3.2.3 of [RFC-to-be] N
hcp_baseline Confidentiality for Informational Header Fields: Subject Header Field is obscured, Keywords and Comments are removed Section 3.2.1 of [RFC-to-be] Y
hcp_shy Obscure Subject, remove Keywords and Comments, remove the time zone from Date, and obscure display-names Section 3.2.2 of [RFC-to-be] N

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist
2024-11-08
24 (System) IANA Review state changed to IANA - Not OK from Version Changed - Review Needed
2024-10-21
24 Liz Flynn
The following Last Call announcement was sent out (ends 2024-11-11):

From: The IESG
To: IETF-Announce
CC: draft-ietf-lamps-header-protection@ietf.org, housley@vigilsec.com, lamps-chairs@ietf.org, rdd@cert.org, spasm@ietf.org …
The following Last Call announcement was sent out (ends 2024-11-11):

From: The IESG
To: IETF-Announce
CC: draft-ietf-lamps-header-protection@ietf.org, housley@vigilsec.com, lamps-chairs@ietf.org, rdd@cert.org, spasm@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Header Protection for Cryptographically Protected E-mail) to Proposed Standard


The IESG has received a request from the Limited Additional Mechanisms for
PKIX and SMIME WG (lamps) to consider the following document: - 'Header
Protection for Cryptographically Protected E-mail'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-11-11. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  S/MIME version 3.1 introduced a mechanism to provide end-to-end
  cryptographic protection of e-mail message headers.  However, few
  implementations generate messages using this mechanism, and several
  legacy implementations have revealed rendering or security issues
  when handling such a message.

  This document updates the S/MIME specification (RFC8551) to offer a
  different mechanism that provides the same cryptographic protections
  but with fewer downsides when handled by legacy clients.
  Furthermore, it offers more explicit usability, privacy, and security
  guidance for clients when generating or handling e-mail messages with
  cryptographic protection of message headers.

  The Header Protection scheme defined here is also applicable to
  messages with PGP/MIME cryptographic protections.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-ietf-lamps-e2e-mail-guidance: Guidance on End-to-End E-mail Security (None - Internet Engineering Task Force (IETF) stream)



2024-10-21
24 Liz Flynn IESG state changed to In Last Call from Last Call Requested
2024-10-21
24 Liz Flynn Last call announcement was changed
2024-10-21
24 Liz Flynn Last call announcement was generated
2024-10-18
24 Roman Danyliw Last call was requested
2024-10-18
24 Roman Danyliw IESG state changed to Last Call Requested from Publication Requested
2024-10-16
24 Cindy Morgan
# Shepherd Write-up for draft-ietf-lamps-header-protection-18

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with …
# Shepherd Write-up for draft-ietf-lamps-header-protection-18

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

  There is support in the LAMPS WG for this document.  It was developed over
  many years, with discussion at almost every IETF meeting during that period.
  There were several points where people were aske to try things at home, but
  only a few active LAMPS WG participants were willing to do the homework.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

  There was little controversy, and suggested improvements were readily
  accepted by the authors.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

  No one has threatened an appeal.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

  There has been some code written, but so far, vendors of major email user
  agents have not said whether they will implement. One did offer insightful
  review of the Internet-Draft during WG Last Call.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

  We are expecting more review from the email community during IETF Last Call,
  including the ART-ART review.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  No special reviews are needed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

  This document does not include a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  ABNF is used.  It was checked with BAP.  The definition for obs-utext is
  imported from RFC 5322, but BAP does not like the NULL (0x00) that is
  allowed in the obsolete definition.  Other tools might tolerate NULL that
  is embedded in the string to be parsed.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

  Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

    No concerns were noticed.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

    As reflected in the Datatracker: Proposed Standard on the IETF Stream.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

    No IPR disclosures were issued against this document.

    The authors have explicitly stated that he is unaware of any IPR
    that needs to be declared.

    The authors have explicitly stated that he do not hold any IPR
    related to this document.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front
    page is greater than five, please provide a justification.

    Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

    There are many lines with non-ASCII characters. This is intentional, and
    the authors are prepared to work with the RFC Editor to ensure that the
    publication formats produce appropriate output.

    IDnits complains about the authors initials in square brackets in
    Appendix E. This will not appear in the RFC, so these warnings were
    ignored.

    IDnits recommends '' and '' lines around the ABNF.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

    No concerns.  [I-D.ietf-lamps-e2e-mail-guidance] is being sent to the IESG
    at the same time as this document.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

    All references are freely available.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97
][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

    Yes. There is a downward reference to [I-D.ietf-lamps-e2e-mail-guidance],
    which is being sent to the IESG at the same time as this document. Please
    call out the downward reference during the IETF Last Call.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

    Yes. [I-D.ietf-lamps-e2e-mail-guidance] is being sent to the IESG at the
    same time as this document.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

    No, this document will not change the status of any other document.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

    This document registers two header fields in the "Permanent Message Header
    Field Names" registry on the IANA "Message Headers" page: HP-Removed and
    HP-Obscured.

    This document also defines the Content-Type parameter known as
    protected-headers.  There does not appear to be an IANA registry for
    parameters for Content-Type.  In the absence of such a registry, the
    Content-Type row in the "Permanent Message Header Field Names" registry
    on the IANA "Message Headers" page is updated to reference this document
    as well as RFC 4021.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

    No new IANA registries are needed.
2024-10-16
24 Cindy Morgan IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2024-10-16
24 Cindy Morgan IESG state changed to Publication Requested from Waiting for AD Go-Ahead
2024-10-16
24 Russ Housley Tag External Party cleared.
2024-10-16
24 Russ Housley IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2024-09-09
24 Roman Danyliw Waiting for WGLC to finish: https://mailarchive.ietf.org/arch/msg/spasm/WDNlqYxh1v0Ixj_KW7idKRiAgCo/
2024-09-09
24 Roman Danyliw IESG state changed to Waiting for AD Go-Ahead::External Party from Waiting for AD Go-Ahead
2024-09-09
24 Roman Danyliw Additional WGLC: https://mailarchive.ietf.org/arch/msg/spasm/WDNlqYxh1v0Ixj_KW7idKRiAgCo/
2024-09-05
24 Russ Housley Tags Revised I-D Needed - Issue raised by IESG, External Party cleared.
2024-09-04
24 Daniel Gillmor New version available: draft-ietf-lamps-header-protection-24.txt
2024-09-04
24 Daniel Gillmor New version accepted (logged-in submitter: Daniel Gillmor)
2024-09-04
24 Daniel Gillmor Uploaded new revision
2024-07-24
23 Daniel Gillmor New version available: draft-ietf-lamps-header-protection-23.txt
2024-07-24
23 Daniel Gillmor New version accepted (logged-in submitter: Daniel Gillmor)
2024-07-24
23 Daniel Gillmor Uploaded new revision
2024-07-23
22 Roman Danyliw WG is conducting an LC.  This will determine the next step.
2024-07-23
22 Roman Danyliw IESG state changed to Waiting for AD Go-Ahead::External Party from Waiting for AD Go-Ahead
2024-07-15
22 Carlos Pignataro Closed request for Last Call review by OPSDIR with state 'Overtaken by Events'
2024-07-15
22 Carlos Pignataro Assignment of request for Last Call review by OPSDIR to Ron Bonica was marked no-response
2024-07-09
22 Russ Housley Tag Revised I-D Needed - Issue raised by IESG set. Tag External Party cleared.
2024-07-09
22 Russ Housley IETF WG state changed to In WG Last Call from Submitted to IESG for Publication
2024-07-04
22 Roman Danyliw Removed from agenda for telechat
2024-07-04
22 Roman Danyliw Post PubReq/IETF LC check with the WG: https://mailarchive.ietf.org/arch/msg/spasm/eCq92sAyLrk1sauMnXwo2g11mqY/
2024-07-04
22 Roman Danyliw IESG state changed to Waiting for AD Go-Ahead::External Party from IESG Evaluation
2024-07-01
22 Orie Steele [Ballot comment]
draft -22 addressed my discuss, the remaining comments are non blocking so I have changed my position to no objection.
2024-07-01
22 Orie Steele [Ballot Position Update] Position for Orie Steele has been changed to No Objection from Discuss
2024-06-27
22 Daniel Gillmor New version available: draft-ietf-lamps-header-protection-22.txt
2024-06-27
22 Daniel Gillmor New version accepted (logged-in submitter: Daniel Gillmor)
2024-06-27
22 Daniel Gillmor Uploaded new revision
2024-06-25
21 Orie Steele
[Ballot discuss]
# Orie Steele, ART AD, comments for draft-ietf-lamps-header-protection-21
CC @OR13

https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-lamps-header-protection-21.txt&submitcheck=True

Thanks to Bron Gondwana for the ART ART review.

I would like …
[Ballot discuss]
# Orie Steele, ART AD, comments for draft-ietf-lamps-header-protection-21
CC @OR13

https://author-tools.ietf.org/api/idnits?url=https://www.ietf.org/archive/id/draft-ietf-lamps-header-protection-21.txt&submitcheck=True

Thanks to Bron Gondwana for the ART ART review.

I would like to see his comments regarding multi-valued headers answered.

Does this document not apply to structural headers, and perhaps therefore not apply to multi-valued headers?

The term "non-structural" headers is repeated several times, perhaps a brief comment on this in the introduction could be helpful.
2024-06-25
21 Orie Steele
[Ballot comment]
## Comments

### What does mistake mean here?

```
734   A receiving implementation MUST NOT mistake the presence of an
735   …
[Ballot comment]
## Comments

### What does mistake mean here?

```
734   A receiving implementation MUST NOT mistake the presence of an
735   hp="cipher" parameter in the Cryptographic Payload for the actual
736   presence of a Cryptographic Layer that provides encryption.
```

Its not clear (to me) what this sentence does for interoperability.


### Can we be more PRECIS regarding what is allowed in val_out?

```
872   The HCP can compute val_out using any technique describable in
873   pseudocode, such as copying a fixed string or invocations of other
874   pseudocode functions.  If it alters the value, it MUST NOT include
875   control or NUL characters in val_out. val_out SHOULD match the
876   expected ABNF for the Header Field identified by name.
```

Consider if a references to https://datatracker.ietf.org/doc/rfc8264/ would be helpful here.


### Clearer phrasing?

```
904   If a non-structural Header Field name A doesn't appear in an HP-Outer
905   Header Field value, then the sender is effectively asserting it was
906   not set on the outside of the message's Cryptographic Envelope by the
907   original message sender at the time the message was injected into the
908   mail system.
```

I think this could be rephrased to be clearer, starting with "By ommiting an HP-Outer Header Field, the sender asserts no protection for ... at the time the message is injected into the mail system.


### Add a section reference "unstructured"

```
919   Note that hp-outer-value is the same as unstructured from [RFC5322],
920   but without the obsolete obs-unstructured option.
```

I can't find a reference to "obs-unstructured" in RFC5322, or RFC6854.

## Nits

### Should this be normative?

```
1453   Note that the Header Confidentiality Policy hcp parameter is
1454   effectively ignored if crypto does not contain encryption.  This is
1455   by design, because a signed-only message cannot provide
1456   confidentiality.
```

MUST be ignored when ... ?


### Define MUA on first use

```
286   This document describes two different schemes for how message headers
287   can be cryptographically protected, and provides guidance for
288   implementers of MUAs that generate and interpret such messages.  It
```

### missing "the" ?

```
388   extent possible.  In some cases, like when a user-visible header like
389   the Subject is cryptographically hidden, a Legacy MUA will not be
390   able to render or reply to the message exactly same way as a
391   conformant MUA would.  But accommodations are described here that
```

### better word than yanked?

```
2222   [...].  Or the message might be yanked out of its current thread if
2223   the MUA loses access to a removed References or In-Reply-To header.
```

### better word than mooted?

```
2836   hcp_example_hide_cc is mooted as an example in Section 2.5.2 but is
2837   not formally registered by this document.
```
2024-06-25
21 Orie Steele [Ballot Position Update] New position, Discuss, has been recorded for Orie Steele
2024-06-13
21 Roman Danyliw Placed on agenda for telechat - 2024-07-11
2024-06-13
21 Roman Danyliw Ballot has been issued
2024-06-13
21 Roman Danyliw [Ballot Position Update] New position, Yes, has been recorded for Roman Danyliw
2024-06-13
21 Roman Danyliw Created "Approve" ballot
2024-06-13
21 Roman Danyliw IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup
2024-06-13
21 Roman Danyliw Ballot writeup was changed
2024-06-13
21 Roman Danyliw Ballot approval text was generated
2024-06-03
21 (System) Changed action holders to Roman Danyliw (IESG state changed)
2024-06-03
21 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2024-06-03
21 (System) IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed
2024-06-03
21 Daniel Gillmor New version available: draft-ietf-lamps-header-protection-21.txt
2024-06-03
21 Daniel Gillmor New version accepted (logged-in submitter: Daniel Gillmor)
2024-06-03
21 Daniel Gillmor Uploaded new revision
2024-04-12
20 Peter Yee Request for Last Call review by GENART Completed: Ready with Nits. Reviewer: Peter Yee. Sent review to list.
2024-03-25
20 Roman Danyliw Please review and revise per ARTART IETC LC review.
2024-03-25
20 (System) Changed action holders to Daniel Gillmor, Bernie Hoeneisen, Alexey Melnikov (IESG state changed)
2024-03-25
20 Roman Danyliw IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead
2024-03-25
20 (System) IESG state changed to Waiting for AD Go-Ahead from In Last Call
2024-03-18
20 (System) IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK
2024-03-18
20 David Dong IANA Experts State changed to Expert Reviews OK from Reviews assigned
2024-03-17
20 Bron Gondwana
Request for Last Call review by ARTART Completed: Ready with Nits. Reviewer: Bron Gondwana. Sent review to list. Submission of review completed at an earlier …
Request for Last Call review by ARTART Completed: Ready with Nits. Reviewer: Bron Gondwana. Sent review to list. Submission of review completed at an earlier date.
2024-03-17
20 Bron Gondwana Request for Last Call review by ARTART Completed: Ready with Nits. Reviewer: Bron Gondwana.
2024-03-13
20 David Dong IANA Experts State changed to Reviews assigned
2024-03-13
20 (System) IANA Review state changed to IANA - Not OK from IANA - Review Needed
2024-03-13
20 David Dong
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-lamps-header-protection-20. If any part of this review is inaccurate, please let us know.

IANA …
(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

IANA has completed its review of draft-ietf-lamps-header-protection-20. If any part of this review is inaccurate, please let us know.

IANA understands that, upon approval of this document, there are three actions which we must complete.

First, in the Permanent Message Header Field Names registry in the Message Headers registry group located at:

https://www.iana.org/assignments/message-headers/

two new Header Fields will be registered as follows:

Header Field Name: HP-Removed
Template:
Protocol: mail
Status: standard
Reference: [ RFC-to-be; Section 2.3.3 ]

Header Field Name: HP-Obscured
Template:
Protocol: mail
Status: standard
Reference: [ RFC-to-be; Section 2.3.3 ]

As this document requests registrations in an Expert Review or Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. This review must be completed before the document's IANA state can be changed to "IANA OK."

Second, also in the Permanent Message Header Field Names registry in the Message Headers registry group located at:

https://www.iana.org/assignments/message-headers/

the existing registration for:

Header Field Name: Content-Type
Template:
Protocol: MIME
Status:
Reference: [ RFC4021 ]

will have [ RFC-to-be ] added to the reference as follows:

Header Field Name: Content-Type
Template:
Protocol: MIME
Status:
Reference: [ RFC4021 ][ RFC-to-be ]

Third, a new registry is to be created called the Mail Header Confidentiality Policies registry. The new registry will be located in the MAIL Parameters registry group located at:

https://www.iana.org/assignments/mail-parameters/

The new registry will be managed via the following registry policy:

Adding an entry to this registry with an N in the "Recommended" column follows the registration policy of Specification Required. Adding an entry to this registry with a Y in the "Recommended" column or changing the "Recommended" column in an existing entry (from N to Y or vice versa) requires IETF Review. During IETF Review, the designated expert must also be consulted.

A note will be added to the registry as follows:

The Header Confidentiality Policy Name never appears on the wire. This registry merely tracks stable references to implementable descriptions of distinct policies. Any addition to this registry should be governed by guidance in Section 2.4.4.1 of [ RFC-to-be ].

There are initial registrations in the new registry as follows:

Header
Confidentiality
Policy Name Description Reference Recommended
------------+-----------+----------+------------
hcp_null No header confidentiality [ RFC-to-be ] N
hcp_minimal Subject Header Field is obscured [ RFC-to-be ] Y
hcp_strong Remove or obscure everything but From, Date, To, and Cc [ RFC-to-be ] N
hcp_hide_cc Obscure Subject, remove Cc [ RFC-to-be ] N

We understand that these are the only actions required to be completed upon approval of this document.

NOTE: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed.

For definitions of IANA review states, please see:

https://datatracker.ietf.org/help/state/draft/iana-review

Thank you,

David Dong
IANA Services Sr. Specialist
2024-03-08
20 Tero Kivinen Request for Last Call review by SECDIR is assigned to Russ Mundy
2024-03-07
20 Jean Mahoney Request for Last Call review by GENART is assigned to Peter Yee
2024-03-06
20 Carlos Pignataro Request for Last Call review by OPSDIR is assigned to Ron Bonica
2024-03-05
20 Barry Leiba Request for Last Call review by ARTART is assigned to Bron Gondwana
2024-03-04
20 Cindy Morgan IANA Review state changed to IANA - Review Needed
2024-03-04
20 Cindy Morgan
The following Last Call announcement was sent out (ends 2024-03-25):

From: The IESG
To: IETF-Announce
CC: draft-ietf-lamps-header-protection@ietf.org, housley@vigilsec.com, lamps-chairs@ietf.org, rdd@cert.org, spasm@ietf.org …
The following Last Call announcement was sent out (ends 2024-03-25):

From: The IESG
To: IETF-Announce
CC: draft-ietf-lamps-header-protection@ietf.org, housley@vigilsec.com, lamps-chairs@ietf.org, rdd@cert.org, spasm@ietf.org
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (Header Protection for Cryptographically Protected E-mail) to Proposed Standard


The IESG has received a request from the Limited Additional Mechanisms for
PKIX and SMIME WG (lamps) to consider the following document: - 'Header
Protection for Cryptographically Protected E-mail'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2024-03-25. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  S/MIME version 3.1 introduced a mechanism to provide end-to-end
  cryptographic protection of e-mail message headers.  However, few
  implementations generate messages using this mechanism, and several
  legacy implementations have revealed rendering or security issues
  when handling such a message.

  This document updates the S/MIME specification ([RFC8551]) to offer a
  different mechanism that provides the same cryptographic protections
  but with fewer downsides when handled by legacy clients.  The Header
  Protection schemes described here are also applicable to messages
  with PGP/MIME cryptographic protections.  Furthermore, this document
  offers more explicit guidance for clients when generating or handling
  e-mail messages with cryptographic protection of message headers.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lamps-header-protection/



No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    draft-ietf-lamps-e2e-mail-guidance: Guidance on End-to-End E-mail Security (None - Internet Engineering Task Force (IETF))
    draft-ietf-lamps-header-protection-requirements: Problem Statement and Requirements for Header Protection (None - Internet Engineering Task Force (IETF))



2024-03-04
20 Cindy Morgan IESG state changed to In Last Call from Last Call Requested
2024-03-04
20 Cindy Morgan Last call announcement was changed
2024-03-04
20 Roman Danyliw Last call was requested
2024-03-04
20 Roman Danyliw Last call announcement was generated
2024-03-04
20 Roman Danyliw Ballot approval text was generated
2024-03-04
20 Roman Danyliw Ballot writeup was generated
2024-03-04
20 Roman Danyliw IESG state changed to Last Call Requested from AD Evaluation::AD Followup
2024-03-01
20 Daniel Gillmor New version available: draft-ietf-lamps-header-protection-20.txt
2024-03-01
20 Daniel Gillmor New version accepted (logged-in submitter: Daniel Gillmor)
2024-03-01
20 Daniel Gillmor Uploaded new revision
2024-02-13
19 (System) Changed action holders to Roman Danyliw (IESG state changed)
2024-02-13
19 (System) Sub state has been changed to AD Followup from Revised I-D Needed
2024-02-13
19 Daniel Gillmor New version available: draft-ietf-lamps-header-protection-19.txt
2024-02-13
19 Daniel Gillmor New version accepted (logged-in submitter: Daniel Gillmor)
2024-02-13
19 Daniel Gillmor Uploaded new revision
2024-01-26
18 Roman Danyliw AD Review: https://mailarchive.ietf.org/arch/msg/spasm/sXJmFS5w7EQy-Y-SNWx_j4nxnic/
2024-01-26
18 (System) Changed action holders to Roman Danyliw, Daniel Gillmor, Bernie Hoeneisen, Alexey Melnikov (IESG state changed)
2024-01-26
18 Roman Danyliw IESG state changed to AD Evaluation::Revised I-D Needed from Publication Requested
2023-12-08
18 Russ Housley
# Shepherd Write-up for draft-ietf-lamps-header-protection-18

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with …
# Shepherd Write-up for draft-ietf-lamps-header-protection-18

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

  There is support in the LAMPS WG for this document.  It was developed over
  many years, with discussion at almost every IETF meeting during that period.
  There were several points where people were aske to try things at home, but
  only a few active LAMPS WG participants were willing to do the homework.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

  There was little controversy, and suggested improvements were readily
  accepted by the authors.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

  No one has threatened an appeal.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

  There has been some code written, but so far, vendors of major email user
  agents have not said whether they will implement. One did offer insightful
  review of the Internet-Draft during WG Last Call.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

  We are expecting more review from the email community during IETF Last Call,
  including the ART-ART review.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  No special reviews are needed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

  This document does not include a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  ABNF is used.  It was checked with BAP.  The definition for obs-utext is
  imported from RFC 5322, but BAP does not like the NULL (0x00) that is
  allowed in the obsolete definition.  Other tools might tolerate NULL that
  is embedded in the string to be parsed.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

  Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

    No concerns were noticed.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

    As reflected in the Datatracker: Proposed Standard on the IETF Stream.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

    No IPR disclosures were issued against this document.

    The authors have explicitly stated that he is unaware of any IPR
    that needs to be declared.

    The authors have explicitly stated that he do not hold any IPR
    related to this document.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front
    page is greater than five, please provide a justification.

    Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

    There are many lines with non-ASCII characters. This is intentional, and
    the authors are prepared to work with the RFC Editor to ensure that the
    publication formats produce appropriate output.

    IDnits complains about the authors initials in square brackets in
    Appendix E. This will not appear in the RFC, so these warnings were
    ignored.

    IDnits recommends '' and '' lines around the ABNF.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

    No concerns.  [I-D.ietf-lamps-e2e-mail-guidance] is being sent to the IESG
    at the same time as this document.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

    All references are freely available.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97
][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

    Yes. There is a downward reference to [I-D.ietf-lamps-e2e-mail-guidance],
    which is being sent to the IESG at the same time as this document. Please
    call out the downward reference during the IETF Last Call.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

    Yes. [I-D.ietf-lamps-e2e-mail-guidance] is being sent to the IESG at the
    same time as this document.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

    No, this document will not change the status of any other document.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

    This document registers two header fields in the "Permanent Message Header
    Field Names" registry on the IANA "Message Headers" page: HP-Removed and
    HP-Obscured.

    This document also defines the Content-Type parameter known as
    protected-headers.  There does not appear to be an IANA registry for
    parameters for Content-Type.  In the absence of such a registry, the
    Content-Type row in the "Permanent Message Header Field Names" registry
    on the IANA "Message Headers" page is updated to reference this document
    as well as RFC 4021.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

    No new IANA registries are needed.
2023-12-08
18 Russ Housley Responsible AD changed to Roman Danyliw
2023-12-08
18 Russ Housley IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up
2023-12-08
18 Russ Housley IESG state changed to Publication Requested from I-D Exists
2023-12-08
18 Russ Housley Document is now in IESG state Publication Requested
2023-12-08
18 Russ Housley
# Shepherd Write-up for draft-ietf-lamps-header-protection-18

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with …
# Shepherd Write-up for draft-ietf-lamps-header-protection-18

## Document History

1. Does the working group (WG) consensus represent the strong concurrence of a
  few individuals, with others being silent, or did it reach broad agreement?

  There is support in the LAMPS WG for this document.  It was developed over
  many years, with discussion at almost every IETF meeting during that period.
  There were several points where people were aske to try things at home, but
  only a few active LAMPS WG participants were willing to do the homework.

2. Was there controversy about particular points, or were there decisions where
  the consensus was particularly rough?

  There was little controversy, and suggested improvements were readily
  accepted by the authors.

3. Has anyone threatened an appeal or otherwise indicated extreme discontent? If
  so, please summarize the areas of conflict in separate email messages to the
  responsible Area Director. (It should be in a separate email because this
  questionnaire is publicly available.)

  No one has threatened an appeal.

4. For protocol documents, are there existing implementations of the contents of
  the document? Have a significant number of potential implementers indicated
  plans to implement? Are any existing implementations reported somewhere,
  either in the document itself (as [RFC 7942][3] recommends) or elsewhere
  (where)?

  There has been some code written, but so far, vendors of major email user
  agents have not said whether they will implement. One did offer insightful
  review of the Internet-Draft during WG Last Call.

## Additional Reviews

5. Do the contents of this document closely interact with technologies in other
  IETF working groups or external organizations, and would it therefore benefit
  from their review? Have those reviews occurred? If yes, describe which
  reviews took place.

  We are expecting more review from the email community during IETF Last Call,
  including the ART-ART review.

6. Describe how the document meets any required formal expert review criteria,
  such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.

  No special reviews are needed.

7. If the document contains a YANG module, has the final version of the module
  been checked with any of the [recommended validation tools][4] for syntax and
  formatting validation? If there are any resulting errors or warnings, what is
  the justification for not fixing them at this time? Does the YANG module
  comply with the Network Management Datastore Architecture (NMDA) as specified
  in [RFC 8342][5]?

  This document does not include a YANG module.

8. Describe reviews and automated checks performed to validate sections of the
  final version of the document written in a formal language, such as XML code,
  BNF rules, MIB definitions, CBOR's CDDL, etc.

  ABNF is used.  It was checked with BAP.  The definition for obs-utext is
  imported from RFC 5322, but BAP does not like the NULL (0x00) that is
  allowed in the obsolete definition.  Other tools might tolerate NULL that
  is embedded in the string to be parsed.

## Document Shepherd Checks

9. Based on the shepherd's review of the document, is it their opinion that this
  document is needed, clearly written, complete, correctly designed, and ready
  to be handed off to the responsible Area Director?

  Yes.

10. Several IETF Areas have assembled [lists of common issues that their
    reviewers encounter][6]. For which areas have such issues been identified
    and addressed? For which does this still need to happen in subsequent
    reviews?

    No concerns were noticed.

11. What type of RFC publication is being requested on the IETF stream ([Best
    Current Practice][12], [Proposed Standard, Internet Standard][13],
    [Informational, Experimental or Historic][14])? Why is this the proper type
    of RFC? Do all Datatracker state attributes correctly reflect this intent?

    As reflected in the Datatracker: Proposed Standard on the IETF Stream.

12. Have reasonable efforts been made to remind all authors of the intellectual
    property rights (IPR) disclosure obligations described in [BCP 79][7]? To
    the best of your knowledge, have all required disclosures been filed? If
    not, explain why. If yes, summarize any relevant discussion, including links
    to publicly-available messages when applicable.

    No IPR disclosures were issued against this document.

    The authors have explicitly stated that he is unaware of any IPR
    that needs to be declared.

    The authors have explicitly stated that he do not hold any IPR
    related to this document.

13. Has each author, editor, and contributor shown their willingness to be
    listed as such? If the total number of authors and editors on the front
    page is greater than five, please provide a justification.

    Yes.

14. Document any remaining I-D nits in this document. Simply running the [idnits
    tool][8] is not enough; please review the ["Content Guidelines" on
    authors.ietf.org][15]. (Also note that the current idnits tool generates
    some incorrect warnings; a rewrite is underway.)

    There are many lines with non-ASCII characters. This is intentional, and
    the authors are prepared to work with the RFC Editor to ensure that the
    publication formats produce appropriate output.

    IDnits complains about the authors initials in square brackets in
    Appendix E. This will not appear in the RFC, so these warnings were
    ignored.

    IDnits recommends '' and '' lines around the ABNF.

15. Should any informative references be normative or vice-versa? See the [IESG
    Statement on Normative and Informative References][16].

    No concerns.  [I-D.ietf-lamps-e2e-mail-guidance] is being sent to the IESG
    at the same time as this document.

16. List any normative references that are not freely available to anyone. Did
    the community have sufficient access to review any such normative
    references?

    All references are freely available.

17. Are there any normative downward references (see [RFC 3967][9] and [BCP
    97
][10]) that are not already listed in the [DOWNREF registry][17]? If so,
    list them.

    Yes. There is a downward reference to [I-D.ietf-lamps-e2e-mail-guidance],
    which is being sent to the IESG at the same time as this document. Please
    call out the downward reference during the IETF Last Call.

18. Are there normative references to documents that are not ready to be
    submitted to the IESG for publication or are otherwise in an unclear state?
    If so, what is the plan for their completion?

    Yes. [I-D.ietf-lamps-e2e-mail-guidance] is being sent to the IESG at the
    same time as this document.

19. Will publication of this document change the status of any existing RFCs? If
    so, does the Datatracker metadata correctly reflect this and are those RFCs
    listed on the title page, in the abstract, and discussed in the
    introduction? If not, explain why and point to the part of the document
    where the relationship of this document to these other RFCs is discussed.

    No, this document will not change the status of any other document.

20. Describe the document shepherd's review of the IANA considerations section,
    especially with regard to its consistency with the body of the document.
    Confirm that all aspects of the document requiring IANA assignments are
    associated with the appropriate reservations in IANA registries. Confirm
    that any referenced IANA registries have been clearly identified. Confirm
    that each newly created IANA registry specifies its initial contents,
    allocations procedures, and a reasonable name (see [RFC 8126][11]).

    This document registers two header fields in the "Permanent Message Header
    Field Names" registry on the IANA "Message Headers" page: HP-Removed and
    HP-Obscured.

    This document also defines the Content-Type parameter known as
    protected-headers.  There does not appear to be an IANA registry for
    parameters for Content-Type.  In the absence of such a registry, the
    Content-Type row in the "Permanent Message Header Field Names" registry
    on the IANA "Message Headers" page is updated to reference this document
    as well as RFC 4021.

21. List any new IANA registries that require Designated Expert Review for
    future allocations. Are the instructions to the Designated Expert clear?
    Please include suggestions of designated experts, if appropriate.

    No new IANA registries are needed.
2023-12-08
18 Russ Housley IETF WG state changed to WG Consensus: Waiting for Write-Up from In WG Last Call
2023-11-30
18 Daniel Gillmor New version available: draft-ietf-lamps-header-protection-18.txt
2023-11-30
18 Daniel Gillmor New version accepted (logged-in submitter: Daniel Gillmor)
2023-11-30
18 Daniel Gillmor Uploaded new revision
2023-10-17
17 Daniel Gillmor New version available: draft-ietf-lamps-header-protection-17.txt
2023-10-17
17 Daniel Gillmor New version accepted (logged-in submitter: Daniel Gillmor)
2023-10-17
17 Daniel Gillmor Uploaded new revision
2023-09-13
16 Daniel Gillmor New version available: draft-ietf-lamps-header-protection-16.txt
2023-09-13
16 Daniel Gillmor New version accepted (logged-in submitter: Daniel Gillmor)
2023-09-13
16 Daniel Gillmor Uploaded new revision
2023-07-23
15 Russ Housley Tag Revised I-D Needed - Issue raised by WGLC cleared.
2023-07-03
15 Russ Housley Tag Revised I-D Needed - Issue raised by WGLC set.
2023-04-26
15 Daniel Gillmor New version available: draft-ietf-lamps-header-protection-15.txt
2023-04-26
15 Daniel Gillmor New version accepted (logged-in submitter: Daniel Gillmor)
2023-04-26
15 Daniel Gillmor Uploaded new revision
2023-04-07
14 Russ Housley Changed consensus to Yes from Unknown
2023-04-07
14 Russ Housley Intended Status changed to Proposed Standard from None
2023-04-07
14 Russ Housley Notification list changed to housley@vigilsec.com because the document shepherd was set
2023-04-07
14 Russ Housley Document shepherd changed to Russ Housley
2023-04-07
14 Russ Housley IETF WG state changed to In WG Last Call from WG Document
2023-04-06
14 Daniel Gillmor New version available: draft-ietf-lamps-header-protection-14.txt
2023-04-06
14 Daniel Gillmor New version accepted (logged-in submitter: Daniel Gillmor)
2023-04-06
14 Daniel Gillmor Uploaded new revision
2023-03-21
13 Russ Housley Added to session: IETF-116: lamps  Wed-0030
2023-03-10
13 Daniel Gillmor New version available: draft-ietf-lamps-header-protection-13.txt
2023-03-10
13 Daniel Gillmor New version accepted (logged-in submitter: Daniel Gillmor)
2023-03-10
13 Daniel Gillmor Uploaded new revision
2023-03-08
12 Daniel Gillmor New version available: draft-ietf-lamps-header-protection-12.txt
2023-03-08
12 Daniel Gillmor New version accepted (logged-in submitter: Daniel Gillmor)
2023-03-08
12 Daniel Gillmor Uploaded new revision
2023-01-24
11 Daniel Gillmor New version available: draft-ietf-lamps-header-protection-11.txt
2023-01-24
11 Daniel Gillmor New version accepted (logged-in submitter: Daniel Gillmor)
2023-01-24
11 Daniel Gillmor Uploaded new revision
2022-12-20
10 Daniel Gillmor New version available: draft-ietf-lamps-header-protection-10.txt
2022-12-20
10 Daniel Gillmor New version accepted (logged-in submitter: Daniel Gillmor)
2022-12-20
10 Daniel Gillmor Uploaded new revision
2022-11-22
09 Daniel Gillmor New version available: draft-ietf-lamps-header-protection-09.txt
2022-11-22
09 Daniel Gillmor New version accepted (logged-in submitter: Daniel Gillmor)
2022-11-22
09 Daniel Gillmor Uploaded new revision
2022-09-08
08 (System) Document has expired
2022-03-07
08 Daniel Gillmor New version available: draft-ietf-lamps-header-protection-08.txt
2022-03-07
08 (System) New version accepted (logged-in submitter: Daniel Gillmor)
2022-03-07
08 Daniel Gillmor Uploaded new revision
2022-02-02
07 Russ Housley Changed document external resources from: None to:

mailing_list https://www.ietf.org/mailman/listinfo/spasm
mailing_list_archive https://mailarchive.ietf.org/arch/browse/spasm/
repo https://gitlab.com/dkg/lamps-header-protection.git
tracker https://gitlab.com/dkg/lamps-header-protection/-/issues
2022-02-02
07 Daniel Gillmor New version available: draft-ietf-lamps-header-protection-07.txt
2022-02-02
07 (System) New version accepted (logged-in submitter: Daniel Gillmor)
2022-02-02
07 Daniel Gillmor Uploaded new revision
2022-01-27
06 (System) Document has expired
2021-07-26
06 Daniel Gillmor New version available: draft-ietf-lamps-header-protection-06.txt
2021-07-26
06 (System) New version accepted (logged-in submitter: Daniel Gillmor)
2021-07-26
06 Daniel Gillmor Uploaded new revision
2021-07-06
05 Russ Housley Added to session: IETF-111: lamps  Thu-1500
2021-05-27
05 Daniel Gillmor New version available: draft-ietf-lamps-header-protection-05.txt
2021-05-27
05 (System) New version accepted (logged-in submitter: Daniel Gillmor)
2021-05-27
05 Daniel Gillmor Uploaded new revision
2021-05-21
04 Daniel Gillmor New version available: draft-ietf-lamps-header-protection-04.txt
2021-05-21
04 (System) New version accepted (logged-in submitter: Daniel Gillmor)
2021-05-21
04 Daniel Gillmor Uploaded new revision
2021-02-22
03 Daniel Gillmor New version available: draft-ietf-lamps-header-protection-03.txt
2021-02-22
03 (System) New version accepted (logged-in submitter: Daniel Gillmor)
2021-02-22
03 Daniel Gillmor Uploaded new revision
2020-11-10
02 Russ Housley Added to session: IETF-109: lamps  Tue-1600
2020-11-02
02 Bernie Hoeneisen New version available: draft-ietf-lamps-header-protection-02.txt
2020-11-02
02 (System) New version approved
2020-11-02
02 (System) Request for posting confirmation emailed to previous authors: Daniel Gillmor , Alexey Melnikov , Bernie Hoeneisen
2020-11-02
02 Bernie Hoeneisen Uploaded new revision
2020-11-02
01 Daniel Gillmor New version available: draft-ietf-lamps-header-protection-01.txt
2020-11-02
01 (System) New version approved
2020-11-02
01 (System) Request for posting confirmation emailed to previous authors: Alexey Melnikov , lamps-chairs@ietf.org, Bernie Hoeneisen
2020-11-02
01 Daniel Gillmor Uploaded new revision
2020-07-13
00 Bernie Hoeneisen New version available: draft-ietf-lamps-header-protection-00.txt
2020-07-13
00 (System) New version accepted (logged-in submitter: Bernie Hoeneisen)
2020-07-13
00 Bernie Hoeneisen Uploaded new revision