Subject: [EAI] [Fwd: AD review of draft-ietf-eai-downgrade-09.txt]

From: Harald Alvestrand <[email-masked]>
Date: Mon, 17 Nov 2008 14:12:59 +0100

Forwarded with permission.

This is obviously a major item to discuss on Thursday; we should aim to 
go through at least all the points marked with "**" in the meeting.

                  Harald

Subject: AD review of draft-ietf-eai-downgrade-09.txt
From: Chris Newman <[email-masked]>
To: [email-masked]
Date: Fri, 14 Nov 2008 15:10:21 -0800
List-Id: EAI WG Design Team <eai-dt.alvestrand.no>

Here's my AD review of draft-ietf-eai-downgrade-09.txt.  My recommendation 
is to do a revision prior to last call resolving at least the "**" issues 
and any "$" issues you choose to resolve.  However, I will follow the 
wishes of the document shepherd on the matter of when to start IETF last 
call.

Permission is granted to share all or part of this review with others as 
needed.

-----
**     - I recommend resolving this before IETF last call
*      - I recommend resolving this before IESG review
$      - If you choose to do this, I recommend doing it before IETF last 
call
others - Treat as equivalent to any other last call comment; it's 
acceptable to
         not address these if they're felt to be controversial or 
disruptive.

Section 3.1:

>downgradedmailfrom = "Downgraded-Mail-From:" [FWS] "<" uPath ">" 1*[FWS]
>                                     "<" Mailbox ">" [FWS] CRLF
>downgradedrcptto = "Downgraded-Rcpt-To:" [FWS] "<" uPath ">" 1*[FWS]
>                                     "<" Mailbox ">" [FWS] CRLF

** This ABNF introduces yet-another new address format.  I think that's a 
bad idea and a topic the WG should discuss further prior to progressing 
this.  The alternative I would suggest is to use a subset of the same 
syntax used in other UTF-8 address headers so that the same parser can be 
reused:

downgraded-envelope-addr = [FWS] "<" [ A-d-l ":" ] uMailbox
        FWS "<" Mailbox ">" ">" [CFWS]

(note also that 1*[FWS] is incorrect usage)

** Another problem here is that the ABNF confuses the syntax prior to 2047 
and subsequent to 2047 encoding.  So the ABNF for the two headers is:

downgradedmailfrom = "Downgraded-Mail-From:" unstructured CRLF
downgradedrcptto = "Downgraded-Rcpt-To:" unstructured CRLF

The unstructured content is downgraded-envelope-addr treated as if it were 
unstructured with 2047 encoding (and charset UTF-8) as needed.

Section 3.2:

>   fields     =/ known-downgraded-headers ":" unstructued CRLF

unstructued => unstructured

>   [RFC2047] with charset='UTF-8'.  The header field syntax is specified

This looks sorta like a MIME parameter, but isn't because it's using single 
quotes instead of double quotes so I'm not quite sure what this means.  How 
about just saying "with charset UTF-8." so it's less confusing.

>   2.  Encode the generated header according to [RFC2047] with
>       charset='UTF-8'.

** This is problematic because 2047 can't be applied to all structured 
fields.  How about the following:

   2. Treat the generated header field content as if it were unstructured,
      and then apply [RFC2047] encoding with charset UTF-8 as necessary so
      the result is ASCII.

Section 3.3:

I suggest this section specifically prohibit application to a "Received" 
header.  It's implied but not stated anywhere.

>   2.  Encode the generated header field value according to [RFC2047]
>       with charset='UTF-8'.  To preserve space characters, the whole
>       header field value which include space characters SHOULD be
>       encoded.

For the first sentence, see comment above.
** The second sentence is also problematic.  RFC 2822 says lines SHOULD be 
78 characters.  The new SHOULD is contradictory to that statement, and thus 
problematic.  The simple solution would be to simply delete that sentence. 
An alternative would be to say something like:

  While RFC 2047 has a specific algorithm to deal with whitespace in
  adjacent encoded-words, there are a number of deployed implementations
  that fail to implement the algorithm correctly.  As a result, whitespace
  behavior is somewhat unpredictable in practice when multiple encoded words
  are used.  While RFC 2822 states that implementations SHOULD limit lines
  to not more than 78 characters, implementations MAY choose to allow
  overlong encoded words in order to work around faulty RFC 2047
  implementations.  Implementations that choose to do so SHOULD have an
  optional mechanism to limit line length to 78 characters.

Section 4.2:

>   The "RCPT TO" command can have an ORCPT parameter if the DSN
>   extension [RFC3461] is supported.  If the ORCPT parameter contains an
>   "utf-8" address and the address contains non-ASCII characters, the
>   ORCPT parameter MUST be converted to utf-8-addr-xtext form or utf-8-
>   addr-unitext form which are described in [RFC5337].

** The transformation that needs to occur on the content of ORCPT is to 1.
remove xtext encoding, 2. convert the result of step one to
utf-8-addr-unitext form where all non-ASCII characters are represented
as EmbeddedUnicodeChar, 3. re-apply xtext encoding to the result of step
2.

Section 5:

>   RECEIVED downgrading:   If the header field name is "Received:" and
>      the FOR clause contains a non-ASCII addresses, remove the FOR
>      clause from the header field.  The other part does not contain
>      non-ASCII values.

Actually, comments may contain non-ASCII characters (section 5.1 is 
correct, but this section is not correct on that issue).

>   UNSTRUCTURED downgrading:   If the header field has an <unstructured>
>      field which contains non-ASCII characters, encode the field
>      according to [RFC2047] with charset='UTF-8'.  To preserve space
>      characters, the whole header field value which include space
>      characters SHOULD be encoded.

See comment for section 3.3 above.

>   DISPLAY-NAME downgrading:   If the header field has any <mailbox>
>      elements and they have <display-name> elements which contain non-
>      ASCII characters, encode the <display-name> elements according to
>      [RFC2047] with charset='UTF-8'.

This shouldn't be restricted to <mailbox> as <display-name> can appear in 
the <group> structure as well.  Also it would be helpful to note that this 
is the same algorithm as WORD downgrading.

Section 5.1:

>   o  Address header fields which contain <mailbox>s

$ Consider adding:
  Disposition-Notification-To [RFC 3798]
because it's standards track.

>   o  Downgrading Non-ASCII in comments

$ As this is a simple transformation, I believe it makes sense to make this 
list as complete as possible at least with standards track headers.  Two 
that come to mind are:
   Content-Transfer-Encoding [MIME]
   Content-Language [RFC 3282]
both here and in the MIME headers section.  Also for just here:
   Accept-Language [RFC 3282]

>   o  Trace header fields

The term "trace header" adds confusion here, as you've already discussed 
trace header fields (Resent-*, Return-Path) in previous groups.  I suggest 
just calling this "Received header field".

>   o  MIME Content header fields
>...
>     Perform MIME-VALUE downgrading.

Also need to perform COMMENT downgrading.

$ Please add "Auto-Submitted" [RFC 3834] to this list.  Since we have BCP 
recommending its use, I think we should treat it as first-class.

>   o  Other header fields
>
>      All other header fields which contains non-ASCII characters are
>      user-defined, missing from this draft or future defined header
>      fields.  Perform ENCAPSULATION downgrading as a last resort.

A suggestion to make this a bit clearer and firmer:
  If the software understands the header's structure and a downgrading 
algorithm other than ENCAPSULATION is applicable, that software SHOULD use 
that algorithm; ENCAPSULATION downgrading is used as a last resort.

$ One other header of note:
  The Original-Recipient header [RFC 3798] is downgraded as described in 
section 4.2 (the same way the ORCPT parameter is downgraded).

Section 6:

>   Content-Type:
>   Content-Disposition:
>      Perform MIME-VALUE downgrading.
   also COMMENT downgrading.

Section 7:

The standard pattern for security considerations is to state a threat that 
is related to or a consequence of the protocol and state a mitigation for 
that threat (or state why not mitigating the threat is acceptable for this 
case).

>   o  A Downgraded message's header fields contain ASCII characters
>      only.  But they still contain MIME encapsulated header fields
>      which contains non-ASCII UTF-8 characters.

* This doesn't state a threat.  The simple way to fix that is to say "thus 
it inherits the security considerations of MIME encoded headers [RFC 2047] 
and UTF-8 [STD63].

>   o  Rewriting headers increases the opportunities for undetected
>      spoofing.

* This needs a statement about why it's acceptable or how to mitigate it.

>   o  Addresses that do not appear in the message headers may appear in

* This is missing the mitigation, which is to not generate a 
Downgrade-Rcpt-To header.

>   o  The techniques described here invalidates methods that depend on

* The two obvious mitigations are to stick to 7-bit when using these 
techniques (as most/all of them presently require), or make sure you have 
UTF8SMTP end-to-end when needed.

>   o  Many gateways and servers on the Internet will discard headers

... Such gateways violate RFC 2979 and can be upgraded to correct the 
problem.

>8.1.  Trivial downgrading

It's not clear to me if this is a normative part of the specification or 
not.

>8.2.  7bit transport consideration
>  ... If the
>   body contains multiple MIME parts, this conversion must be performed
>   for each MIME part according to [RFC2045].

Actually, 8->7 MIME downgrading was never specified and the reference to 
2045 here is simply misleading.  The constraints on such downgrading are 
stated in RFC 1652.

>   Furthermore, IANA is requested to reserve all the field names that
>   start with "Downgraded-" for unknown header fields downgrading
>   described in Section 3.3, in accordance with the procedures set out
>   in [RFC3864].

** RFC 3864 includes no such procedure.  To do this, you need to "Update" 
RFC 3864 so that it supports reserved prefixes.  Reserving a prefix 
requires a new IANA registration procedure added to the existing registry 
(likely IESG review).  The SASL registry (RFC 5222) followed a similar 
pattern where the initial registry rules were modified to support reserved 
prefixes.  For this case, when someone attempts to register a 
"Downgraded-*" header in the future, you need to specify the rules 
necessary to accept or reject such registration attempts as otherwise the 
rules in RFC 3864 apply.

		- Chris

_______________________________________________
EAI-DT mailing list
[email-masked]
http://www.alvestrand.no/mailman/listinfo/eai-dt

_______________________________________________
IMA mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ima

---

From: Chris Newman <[email-masked]>
Date: Thu, 20 Nov 2008 16:43:29 -0600

> section 4.2 (the same way the ORCPT parameter is downgraded).

Turning this into a suggested change:

-----
Section 5, add (at end):

   TYPED-ADDRESS downgrading:  Address headers of this form with an address 
type of
   "utf-8", "utf-8-addr-xtext", or "utf-8-addr-unitext" are downgraded as 
described
   in section 4.2.  COMMENT downgrading is also performed in this case.  If 
the
   address type is unrecognized and the header contains non-ASCII, then 
fall back to
   using ENCAPSULATION downgrading on the entire header.

Section 5.1, add after sub-section "o  Address header fields which contain 
<mailbox>s":

   o  Address header fields with typed addresses:

   Original-Recipient  [RFC3798]

   If the header contains non-ASCII, perform TYPED-ADDRESS downgrading.
-----

As a technical contributor, I'm inclined to include this change for 
completeness since this header is draft-standard and there's code reuse 
from ORCPT=.  But I could understand arguments to the contrary given this 
is a bit more complex than I initially thought.

The other five headers I recommended simply need to be added to the 
relevant existing lists in section 5.1.

		- Chris