Moved implementation considerations to Appendix
authorBernie Hoeneisen <b@hoeneisen.ch>
Thu, 17 Oct 2019 16:22:02 +0200
changeset 1105777db18b1453
parent 1104 57b597e4508c
child 1106 719281948713
Moved implementation considerations to Appendix
ietf-lamps-hp-requirements/draft-ietf-lamps-header-protection-requirements.mkd
     1.1 --- a/ietf-lamps-hp-requirements/draft-ietf-lamps-header-protection-requirements.mkd	Wed Oct 16 22:25:46 2019 +0200
     1.2 +++ b/ietf-lamps-hp-requirements/draft-ietf-lamps-header-protection-requirements.mkd	Thu Oct 17 16:22:02 2019 +0200
     1.3 @@ -422,18 +422,72 @@
     1.4  
     1.5  {::include ../shared/fence-line.mkd}
     1.6  
     1.7 - 
     1.8 +
     1.9 +
    1.10 +# Security Considerations
    1.11 +
    1.12 +This document talks about UI considerations, including security
    1.13 +considerations, when processing messages protecting header fields.
    1.14 +One of the goals of this document is to specify UI for displaying
    1.15 +such messages which is less confusing/misleading and thus more
    1.16 +secure.
    1.17 +
    1.18 +The document is not defining new protocol, so it doesn't create any
    1.19 +new security concerns not already covered by S/MIME {{RFC8551}}, MIME
    1.20 +[RFC2045] and Email {{RFC5322}} in general.
    1.21 +   
    1.22 +
    1.23 +
    1.24 +# Privacy Considerations
    1.25 +
    1.26 +\[\[ TODO \]\]
    1.27 +
    1.28 +
    1.29 +# IANA Considerations
    1.30 +
    1.31 +This document requests no action from IANA.
    1.32 +   
    1.33 +\[\[ RFC Editor: This section may be removed before publication. \]\]
    1.34 +
    1.35 +
    1.36 +# Acknowledgments
    1.37 +
    1.38 +The authors would like to thank the following people who have provided
    1.39 +helpful comments and suggestions for this document: David Wilson,
    1.40 +Steve Kille, Wei Chuang, and Robert Williams
    1.41 +
    1.42 +Essential parts of {{I-D.luck-lamps-pep-header-protection}} have been
    1.43 +merged into this document. Special thanks to its author Claudio Luck.
    1.44 +For further Acknowledgments, please refer to Acknowledgments section
    1.45 +of {{I-D.luck-lamps-pep-header-protection}}.
    1.46 +
    1.47 +David Wilson came up with the idea of defining a new Content-Type
    1.48 +header field parameter to distinguish forwarded messages from inner
    1.49 +header field protection constructs.
    1.50 +
    1.51 +--- back
    1.52 +
    1.53 +
    1.54  <!-- =========================================================================== -->
    1.55  
    1.56  
    1.57 +# Implementation Considerations {#implementation-considerations}
    1.58  
    1.59 -# Options to Achieve Header Protection
    1.60 +This {{implementation-considerations}} contains additional information
    1.61 +and considerations regarding the implementation. Although not
    1.62 +(strictly) part of the requirements, this is useful to better
    1.63 +understand them. Parts of the text in this
    1.64 +{{implementation-considerations}} will likely be moved to the upcoming
    1.65 +implementation document.
    1.66 +
    1.67 +
    1.68 +## Options to Achieve Header Protection
    1.69  
    1.70  In the following a set of Options to achieve Email Header
    1.71  Protection. It is expected that the IETF LAMPS WG chooses an option to
    1.72  update {{RFC8551}} wrt. Header Protection.
    1.73  
    1.74 -## Option 1: Memory Hole {#memory-hole}
    1.75 +### Option 1: Memory Hole {#memory-hole}
    1.76  
    1.77  Memory Hole approach works by copying the normal message header
    1.78  fields into the MIME header section of the top level protected body
    1.79 @@ -444,7 +498,7 @@
    1.80  \[\[ TODO<!--(DKG)-->: add more information on memory hole ]\]
    1.81  
    1.82  
    1.83 -## Option 2: Wrapping with message/rfc822 or message/global {#rfc822-wrapping}
    1.84 +### Option 2: Wrapping with message/rfc822 or message/global {#rfc822-wrapping}
    1.85  
    1.86  Wrapping with message/rfc822 (or message/global) works by copying the
    1.87  normal message header fields into the MIME header section of the top
    1.88 @@ -474,7 +528,7 @@
    1.89  the message body.
    1.90  
    1.91  
    1.92 -### Content-Type Parameter "forwarded"
    1.93 +#### Content-Type Parameter "forwarded"
    1.94  
    1.95  This section outlines how the new "forwarded" Content-Type header
    1.96  field parameter could be defined (probably in a separate document)
    1.97 @@ -512,7 +566,7 @@
    1.98  
    1.99  
   1.100  
   1.101 -## Option 2.1: Progressive Header Disclosure {#progressive-header-disclosure}
   1.102 +### Option 2.1: Progressive Header Disclosure {#progressive-header-disclosure}
   1.103  
   1.104  This option is similar to Option 2 (cf. {{rfc822-wrapping}}). It also
   1.105  makes use the Content-Type parameter "forwarded"
   1.106 @@ -544,7 +598,7 @@
   1.107  {{I-D.luck-lamps-pep-header-protection}}.
   1.108  
   1.109  
   1.110 -## Examples
   1.111 +### Examples
   1.112  
   1.113  
   1.114  Examples in subsequent sections assume that an email client is trying
   1.115 @@ -594,7 +648,7 @@
   1.116  
   1.117  {::include ../shared/fence-line.mkd}
   1.118  
   1.119 -### Option 1: Memory Hole {#memory-hole-example}
   1.120 +#### Option 1: Memory Hole {#memory-hole-example}
   1.121  
   1.122  
   1.123  The following example demonstrates how header section and payload of
   1.124 @@ -639,7 +693,7 @@
   1.125  
   1.126  {::include ../shared/fence-line.mkd}
   1.127  
   1.128 -### Option 2: Wrapping with message/rfc822 or message/global {#rfc822-wrapping-example}
   1.129 +#### Option 2: Wrapping with message/rfc822 or message/global {#rfc822-wrapping-example}
   1.130  
   1.131  The following example demonstrates how header section and payload of
   1.132  a protect body part might look like.  For example, this will be the
   1.133 @@ -687,7 +741,7 @@
   1.134  
   1.135  {::include ../shared/fence-line.mkd} 
   1.136  
   1.137 -### Option 2.1 Progressive Header Disclosure {#progressive-header-disclosure-example}
   1.138 +#### Option 2.1 Progressive Header Disclosure {#progressive-header-disclosure-example}
   1.139  
   1.140  This looks similar as in option 2. Specific examples can be found in
   1.141  {{I-D.luck-lamps-pep-header-protection}}. 
   1.142 @@ -697,11 +751,11 @@
   1.143  style. \]\]
   1.144  
   1.145  
   1.146 -# Sending Side Considerations
   1.147 +## Sending Side Considerations
   1.148  
   1.149  <!-- HB: preserved as commented out for the moment, as we may re-use part of this
   1.150  
   1.151 -##  Stub Outer Header
   1.152 +###  Stub Outer Header
   1.153  
   1.154  \[\[ TODO (AM): Consider merging this section with the following one.
   1.155  At the moment advice presented by these 2 sections is contradictory.
   1.156 @@ -732,7 +786,7 @@
   1.157  
   1.158  -->
   1.159  
   1.160 -## Candidate Header Fields for Header Protection {#candidate-header-fields}
   1.161 +### Candidate Header Fields for Header Protection {#candidate-header-fields}
   1.162  
   1.163  \[\[ TODO: This section is very early stage and needs more work. \]\]
   1.164  
   1.165 @@ -792,15 +846,15 @@
   1.166  
   1.167  Note that recommendations listed above typically only apply to non
   1.168  MIME header fields (header fields with names not starting with
   1.169 -"Content-" prefix), but there are exception, e.g.  Content-Language.
   1.170 +"Content-" prefix), but there are exceptions, e.g.  Content-Language.
   1.171  
   1.172  Note that the above recommendations can also negatively affect
   1.173  anti-spam processing.
   1.174  
   1.175  
   1.176 -# Receiving Side Considerations
   1.177 +## Receiving Side Considerations
   1.178  
   1.179 -## Which Header Fields to Display to User
   1.180 +### Which Header Fields to Display to User
   1.181  
   1.182  When displaying S/MIME messages which protect header fields (whether
   1.183  they are signed-only, encrypted or encrypted+signed):
   1.184 @@ -820,7 +874,7 @@
   1.185  
   1.186  
   1.187  
   1.188 -## Mail User Agent Algorithm for deciding which version of a header field to display  {#algorithm-hf-display}
   1.189 +### Mail User Agent Algorithm for deciding which version of a header field to display  {#algorithm-hf-display}
   1.190  
   1.191  
   1.192  \[\[ TODO: describe how to recurse to find the innermost protected root
   1.193 @@ -834,52 +888,10 @@
   1.194  -->
   1.195  
   1.196  
   1.197 +
   1.198  <!-- =========================================================================== -->
   1.199  
   1.200  
   1.201 -# Security Considerations
   1.202 -
   1.203 -This document talks about UI considerations, including security
   1.204 -considerations, when processing messages protecting header fields.
   1.205 -One of the goals of this document is to specify UI for displaying
   1.206 -such messages which is less confusing/misleading and thus more
   1.207 -secure.
   1.208 -
   1.209 -The document is not defining new protocol, so it doesn't create any
   1.210 -new security concerns not already covered by S/MIME {{RFC8551}}, MIME
   1.211 -[RFC2045] and Email {{RFC5322}} in general.
   1.212 -   
   1.213 -
   1.214 -
   1.215 -# Privacy Considerations
   1.216 -
   1.217 -\[\[ TODO \]\]
   1.218 -
   1.219 -
   1.220 -# IANA Considerations
   1.221 -
   1.222 -This document requests no action from IANA.
   1.223 -   
   1.224 -\[\[ RFC Editor: This section may be removed before publication. \]\]
   1.225 -
   1.226 -
   1.227 -# Acknowledgments
   1.228 -
   1.229 -The authors would like to thank the following people who have provided
   1.230 -helpful comments and suggestions for this document: David Wilson,
   1.231 -Steve Kille, Wei Chuang, and Robert Williams
   1.232 -
   1.233 -Essential parts of {{I-D.luck-lamps-pep-header-protection}} have been
   1.234 -merged into this document. Special thanks to its author Claudio Luck.
   1.235 -For further Acknowledgments, please refer to Acknowledgments section
   1.236 -of {{I-D.luck-lamps-pep-header-protection}}.
   1.237 -
   1.238 -David Wilson came up with the idea of defining a new Content-Type
   1.239 -header field parameter to distinguish forwarded messages from inner
   1.240 -header field protection constructs.
   1.241 -
   1.242 ---- back
   1.243 -
   1.244  # Document Changelog
   1.245  
   1.246  \[\[ RFC Editor: This section is to be removed before publication \]\]
   1.247 @@ -887,6 +899,10 @@
   1.248  * draft-ietf-lamps-header-protection-requirements-00
   1.249    * Initial version
   1.250  
   1.251 +* draft-ietf-lamps-header-protection-requirements-01
   1.252 +  * Moved Implementation Considerations to Appendix
   1.253 +
   1.254 +
   1.255  # Open Issues
   1.256  
   1.257  \[\[ RFC Editor: This section should be empty and is to be removed