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

Freed-san,

Thank you for checking document and clarify issues.
I will study issues and respond next week.


[email protected] wrote:
>
>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
>

Kiyoshi Toyoda