Re: IESG Review: draft-ietf-fax-esmtp-conneg-10.txt

Folks,

Here are some responses to the IESG comments.

If there are continuing concerns, please let me/us know.


SH> Steve Bellovin:
SH> Discuss:
SH> [2004-07-06] This scheme completely breaks S/MIME.  At the very least, there
SH> needs to be discussion of that fact and its implications; ideally, there
SH> should be some mention of the architecture for -- and the security
SH> implications of -- a content-converting S/MIME gateway.

Yes, an intermediary content conversion process cannot work if the
contents are encrypted (and the intermediary does not have access to
the decryption key.)

A discussion about the implication of using esmtp conneg with a
content-based encryption mechanism is certainly appropriate.

I propose to add to:

  1. Content Negotiation section:

  Content conversion will invalidate a message's signature and will not
  be possible to perform with encrypted content. Therefore, permission
  to convert SHOULD NOT normally be given with signed or encrypted
  messages.

  2. Security Considerations section

  Use of the ESMTP CONNEG option permits content transformation by an
  intermediary, along the mail transfer path.  When the contents are
  encrypted, the intermediary cannot perform the conversion, unless it
  has access to the necessary secret information.  When the contents
  are signed, but they remain in the clear, conversion will invalidate
  the signature.


The specification needs to take note of the cited implication, but
does not need to enter into full pedagogy of the architectural
dynamics of application gateways. A document with such architectural
pedagogy would be nice, but it has little to do with this protocol
specification.


SH> The CPU load of such conversions should also be discussed in the Security
SH> Considerations section.  Is this another way to DoS a mail server?


I propose to add to the Security Considerations section:

  This specification provides for potentially unbounded computation by
  intermediary MTAs, depending upon the nature and amount of
  conversion required.  Further, this computation burden may be a
  source of opportunity for denial-of-service attacks, given that
  Internet mail typically permits intermediaries to receive messages
  from all Internet sources.

I should note that I am not aware of having computation load analysis
be typically required for IETF specifications.

SH> Ted Hardie:
SH> Discuss:
SH> [2004-07-06] In general, this does not seem adequately specified for general
SH> use.

In general, it is not possible to remedy such a concern without
hearing the detail behind it. Unfortunately, that was not supplied.


SH>  A limited use
SH> case might be made specifically for one class of devices using SMTP in a
SH> specific
SH> way, but this is not the approach the authors have taken.

That is because we started with a limited approach and were told to
make it more general.

On reflection, I feel that the generalization was entirely
appropriate, because we the IETF does not do SMTP options that require
basic reconfigurations of the Internet mail transmission model from
store-and-forward to point-to-point.


SH> Going through the draft point by point would be exhausting, and I'm not sure
SH> it would help.

I need to express concern that this makes it sound as if as if years
of diligent, reviewed working group effort and review are simply to be
tossed out.


SH>   Among the issues are:  the document allows for the
SH> conversions
SH> to happen off the message path,

That is not what the specification says.  It says that conversions do
not HAVE to happen "along" the message path.

The point is that CONPERM is a way of stating conversion restrictions
and that having that proscription carried all the way to the recipient
is useful, even if no conversions are done along the path.


SH>  but has not dealt with the issues raised
SH> by the IAB in the context of OPES;

On the contrary, we reviewed IAB and OPES draft documents that were
available at the time the specification was written and we factored
those concerns in.

If there are specific omissions or problems, we cannot resolve them
unless we are told what they are.

By the way: Is that IAB material now a requirement for all related
specifications to satisfy? When was this mandated?


SH>  the document allows for conversion
SH> and continuation of the use of CONPERM so that a later conversion may
SH> take place--creating the classic "copy of a copy" syndrome;

What does this mean and what is the "problem" with it?


SH>  the document
SH> permits a message intended for multiple recipients to be split according
SH> to the capabilities of the recipients and fails to specify whether the
SH> recipient
SH> list is retained or split;

In what ways is "Each version is then sent separately, to an
appropriate subset of the recipients" unclear, imprecise, inaccurate
or incomplete?


SH> the document punts completely how the SMTP
SH> service
SH> gets the CONNEG data in the first place, putting a critical part of the
SH> security story out of reach.

That is correct.  The document specifies a particular mechanism, not a
complete "system".  It states the security implication of this in the
opening lists of the security section.

By way of comparative example, note that the BGP specification does
not say how a BGP speaker obtains the list of hosts it announces paths
to? The BPG spec just refers to "local policies".

The fact that portions of a larger system remain unspecified ought not
to invalidate having a public portion of such a service.


SH> Alex Zinin:
SH> Discuss:
SH> [2004-07-08] Gen-art reviewer Joel Halpern:


SH> There is a consistent phrasing in this document which I think is just
SH> unfortunate.  The text says repeatedly that the conversion MUST be
SH> performed at the point where CONPERM meets CONNEG.
SH> This would, as stated, result in avoidable delivery failures.

Well, THAT certainly got MY attention...


SH> To elaborate, the client has sent the email, with CONPERM and permitted
SH> mandatory conversions, to server S1 which supports CONPERM and some
SH> conversions.  Server S2 happens to know the capabilities of target T, so it
SH> responds with CONNEG.  Let us assume that there is a non-empty intersection
SH> between the target acceptable forms and the sender specified 
SH> transforms.  So, by the spec S1 is required to perform the transform or
SH> fail the request.  But it would seem likely, particularly if T is a limited
SH> device and S2 explicitly supports T, that S2 could perform the conversion
SH> even if S1 can not.

Having S2 know about T's capabilities does not mean that S2 has the
capability to perform conversions for T.

However, if S2 does have the ability to do the conversions that T
needs done, and S2 wants to be the one to do the conversions, then all
S2 has to do is announce CONPERM without CONNEG. That is, it needs to
announce to SMTP clients that it will honor CONPERM, but stay silent
about T's capabilities. The it uses that latter knowledge to do the
conversions itself.

Let us remember that S1 already knows the maximum repertoire of conversions
that are possible for the message.  It is holding the message and it
has the originator's specification of permissible conversions.

First principals:  CONPERM/CONNEG are intended to get
recipient-tailored conversion done as early in the transmission
sequence as possible.  Experience with such conversions indicates that
this can save considerable bandwidth.

So if early conversion is not a goal, then don't use CONPERM.


SH> If the working group really intended to prohibit S1 from sending the
SH> request on to S2 without conversion, I really think some explanatory text
SH> is required.

    When CONPERM is used, conversions are performed by the first ESMTP
    host that can obtain both the originator's permission and the
    recipient's capabilities. If a relay or client is unable to
    transmit the message to a next-hop that supports CONPERM or to
    perform appropriate conversion, then it terminates message
    transmission and returns a [DSN] to the originator.

What explanation is needed, beyond the above text from the
specification?


SH> (This is particularly odd since if S2 simply chose not to tell S1 that it
SH> know the targets capabilities, the S2 would get the message, and could
SH> perform the conversion.)

Right.  And more generally, if later conversion is acceptable, then
send the message with the relevant mime headers but do not use
CONPERM.


SH> Related to this is the requirement that a server only offer CONPERM if it
SH> is able to perform conversions.  But CONPERM is a generalized capability,
SH> not a statement of specific conversions relevant to the specific 
SH> message.  Thus, the requirement is vacuous.

Mathematically vacuous, perhaps. But the actual array of conversions
to perform is likely to be quite small. The specification clearly does
work on the basis that a platform able to do ANY conversions is able
to do ALL REQUIRED conversions.

I propose to add to the following text to 2.2  ESMTP-based content
negotiation:

   This options requires that a server made an open-ended to ensure
   that acceptable conversions are performed. In particular, it is
   possible that an intermediary be required to perform conversion but
   be unable to do so. This will result in undelivered mail.


SH> It seems to me that CONPERM ought to be offered if the server is prepared to
SH> a) carry CONPERM forward
SH> b) do the right thing if the next neighbor does not support CONPERM
SH> c) do the right thing relative to a client, including failing the request
SH> if a mandatory conversion can not be performed

That is a reasonable design, but not the one the working group chose.


SH> Maybe my usage of English is odd, but as I read this spec, the 
SH> "Content_Conversion_Permission" service extension is used not to give
SH> permission to convert, but rather to mandate conversion.  permission is
SH> given by the presence of the Content-Convert header.  Shouldn't this be
SH> called the "Content_Conversion_Required" service extension?

Historical artifact.  The spec went through changes, but the name
stayed the same.


SH> I got confused in section 4.2.  To backtrack, reading everything else,
SH> CONPERM indicates that conversion is required before delivery.

It says that any conversions that are performed must be within the
specified set.


SH>   Earlier
SH> text indicates that in the absence of CONPERM, message delivery continues
SH> even if conversion can not be performed.

That's correct.  Presence of the conversion Mime headers, without
conperm, is advisory.  Conperm makes the constraints mandatory.


SH>   Then, in the Client Action
SH> portion of 4.2 on CONNEG, the text says that if the intersection of
SH> conversion goals is empty:
SH>           (1)  If the message is subject to CONPERM, the Client MAY
SH>                 continue to transmit the original content, according to
SH>                 CONPERM.

SH>           (2)  Otherwise, the Client MUST treat the conversion as
SH>                 failed.
SH> I am not sure what either bullet actually means.
SH> I am guessing that bullet 1 is trying to say that even if CONPERM was
SH> indicated for the whole message, the failure response depends upon whether
SH> the conversion of the specific body part was mandatory.  If so, it just
SH> does not say that.
SH> I am guessing that bullet 2 really means "just let the message proceed
SH> without recording any conversions" since that is what the rest of the spec
SH> says to do if one can not convert.  However, the words do not say that.

I can't blame jet-lag, so I have to admit to being confused by the
specification, also. Does anyone care to suggest whether the spec text
is a pure bug or something else?


SH> I believe the following is typographic, but it leaves the reader guessing:
SH> The list of features refers to "Content-Convert, Content-Converted, and
SH> Content-Features.  The general overview indicates that the conversions are
SH> recorded into the Content-Converted and Content-Features MIME 
SH> headers.  However, the description of the "Intermediary Actions" says that
SH> the record of conversions is placed in the "Content-Previous" headers
SH> (rather than the "Content-Converted" headers.)

damn.  yes, typos.  i really thought i fixed those references.


SH> Minor:
SH> The phrasing of the IANA considerations section is odd.

I'll review the text.


SH> [CONMSG] is either a normative reference or an informative reference.  If
SH> (as I suspect) it is used normatively some of the time, it should appear in
SH> the normative list and not in the informative list.

ack.


SH> There is no IPR disclosure.

well, i think that requirements for ipr text have changed since the
draft was written.  We will of course add the necessary text.

d/
--
 Dave Crocker <mailto:[email protected]>
 Brandenburg InternetWorking <http://www.brandenburg.com>
 Sunnyvale, CA  USA <tel:+1.408.246.8253>, <fax:+1.866.358.5301>