AD review comments on draft-ietf-fax-esmtp-conneg-01.txt

[ned.freed@xxxxxxxxxxx]

Let's start with an obvious document issue, easily fixed: The IANA
considerations section. It currently says "This memo is not intended to create
any new issues for IANA." However, the document's primary goal is to define an
ESMTP extension, and registration of ESMTP extensions is an IANA activity. As
such, I suggest this section be changed to read "On publicatioj of this
document by the RFC Editor the IANA shall register the Content_Negotiation
ESMTP extension defined in section 2."

Another minor document issue is that the RFC Editor has a new policy that
references must be separated into normative and informative groups. In this
case I think there is effectively no separation: All three of the references
here appear normative to me. So the thing to do is change the title of section
9 to "NORMATIVE REFERENCES".

Another document issue is that this document begins with a SUMMARY but has no
ABSTRACT or INTRODUCTION. The RFC Editor wants to see a separate ABSTRACT and
INTRODUCTION section in all new RFCs. I would suggest keeping the current
SUMMARY as the ABSTRACT and writing a new INTRODUCTION, reiterating the
ABSTRACT but adding some additional background information if possible.

On to security considerations. What's there seems entirely appropriate.
However, there's are two other security considerations I believe deserve
mention: The possibility that a vulnerability will be disclosed by the
mechanism and the possibility of tampering with the result the mechanism
returns.

The first specific case that concerns me is that of a capability that is
typically handled by, say, a plugin that has been found to contain a security
vulnerability. Disclosure of support for this capability becomes tantamount to
disclosing a vulnerability.

The second case is one where a man in the middle changes the capabilities
associated with a given recipient. Here's a somewhat fanciful example: Suppose
the sender knows the recipient has the ability to view color documents so they
mark some things in red in what is otherwise a black and white document. But
someone interferes with the returned capabilities, making them say the
recipient only supports black and white. The document is duly downgraded, with
the result that the recipient doesn't see what the sender marked. (Of course
the man in the middle could have tampered with the document itself, but
modifying a document on the fly is a much more difficult proposition.)

I'm not suggesting that this facility be changed to address these issues,
merely that they be mentioned in the security considerations section.

Next up is failure modes. The model defined here seems simple enough: Client
asks server for capabilities for a given recipient and the server either
returns those capabilities or fails with a CONNEG-specific error code.

I wonder, however, if this isn't too simple. A server may have no trouble
delivering mail to a given recipient but might be unable to return that
recipient's capabilities. And this could be either a temporary or permanent
failure: The directory containing this information could be offline, or it
could be the case that this information simply isn't available for this
particular recipient.

Of course a client that receives a 504 can always retry the recipient without
the CONNEG parameter if it is willing to operate in the absence of capability
information. But it may want to take different actions depending on whether the 
failure is temporary or permanent: I could easily see sending some sort of
default for a permanent failure while waiting to retry in the even of a
temporary failure.

I therefore suggest that an additional 404 status code be defined that can be
returned when the server experiences a temporary failure getting capability
information.

The unconditional use of a failure code when capabilities aren't available also
concerns me. While it is true the client can simply reissue the RCPT TO without
the CONNEG parameter, handling this case effectively stalls the SMTP dialogue.
(That is, the client has to wait for the response to the RCPT TO before it
knows how to proceed.) And dialogue stalls are a significant operational issue
in practice. I therefore suggest that the mechanism be changed to allow a
CONNEG parameter value. The value would be, say, either REQUIRED or OPTIONAL.
The REQUIRED value would result in the same behavior currently described in the
document. The OPTIONAL case, however, would instruct the server to proceed
normally and return a _success_ status when the capabilities aren't available.
A corresponding 2xx code would need to be defined for this case.

This document also fails to specify what enhanced status code should be
returned in the event the server is unable to return capabilities information.
Looking at the list in RFC 1893 I'd say one possibility is x.3.3, system not
capable of selected feature. I also note in passing that there are no examples
of CONNEG failures in the examples section. Some examples of this sort need to
be added.

Another interesting case that could arise in practice is where a server is
configured to require authentication, integrity, or privacy services before
capability information can be returned. I think the document needs to discuss
this case, saying that if such requirements have not been met the CONNEG
extension should not be offered in the EHLO response. (Note that successful
security negotiation already involves repeating EHLO.)

Although several examples of returned capabilities are shown, the document
isn't very specific about how capabilities have to be formatted. In particular,
I'd expect to see capabilities often stored as a single string without any line
breaks. Some advice on how to take such a string and format it for inclusion in
the reponse seems warranted.

According to this document the only capabilities that can be returned are those
defined in RFC 2879, which is FAX-specific. I realize this document is a
product of the FAX WG, but is this really appropriate? Should more general
capabilites return be allowed? And if not, shouldn't this extension be called
FAXCONNEG or something similar?

Finally, this document makes passing reference to "use in relay scenarios". I
think some elaboration of this might be in order. In particular, I see at least
two scenarios that involve relaying: One where a server knows it will
subsequently relay the message but offers up capability information by proxy,
and another where the client is an intermediary service with message
downgrading capabilities.

That's it!

				Ned