Subject: [secdir] Review of draft-melnikov-smtp-priority-tunneling-03

From: Shawn Emery <[email-masked]>
Date: Wed, 18 Jul 2012 01:00:24 -0600

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the IESG. 
These comments were written primarily for the benefit of the security 
area directors. Document editors and WG chairs should treat these 
comments just like any other last call comments.

This experimental draft describes a SMTP tunneling method to support 
priority message values for Mail Transfer Agents (MTA) that don't 
understand the MT-PRIORITY SMTP extension.

The security consideration section does exist and is quite detailed in 
listing the various attack scenarios and mitigating against these 
attacks.  It goes on to provide exceptions of when MT-Priority header 
values are not required to be stripped.  These have consequences such as 
breaking DKIM signatures, assuming subsequent MTAs are compliant with 
the new tunneling, or rejecting the messaging.  The document may clarify 
on when it is acceptable to break DKIM signatures and/or describe the 
environment.  On the other hand, if the MSA/MTA decides to alter the 
message and needs to resign the message then is there any ambiguity of 
what the message/fields would be when resigned?

General comments:

Thanks for providing the before and after examples as this was helpful 
in my understanding of the protocol.

Editorial comments:

s/Example of such/Examples of such/

Shawn.
--

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 19 Jul 2012 17:04:36 +0100

Hi Shawn,

On 18/07/2012 08:00, Shawn Emery wrote:
> ongoing effort to review all IETF documents being processed by the 
> IESG. These comments were written primarily for the benefit of the 
> security area directors. Document editors and WG chairs should treat 
> these comments just like any other last call comments.
>
> values are not required to be stripped.  These have consequences such 
> as breaking DKIM signatures, assuming subsequent MTAs are compliant 
> with the new tunneling, or rejecting the messaging.  The document may 
> clarify on when it is acceptable to break DKIM signatures and/or 
> describe the environment.

I don't think I know a clear answer to this and this might be 
implementation/deployment specific.

> On the other hand, if the MSA/MTA decides to alter the message and 
> needs to resign the message then is there any ambiguity of what the 
> message/fields would be when resigned?

As far as this extension is concerned, there is only one header field of 
relevance. So I don't think so.

> s/Example of such/Examples of such/

Fixed in my copy.