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

Ned,
Thank you for your attention and feedback on
draft-ietf-fax-esmtp-conneg-01.txt and previously
draft-ietf-fax-tiff-fx-regbis-04.txt. There, however, appears to be some
oversight as draft-ietf-fax-tiff-fx-reg-01.txt was last called at the same
time or before these drafts yet it has not received any feedback. This is
concerning because tiff-fx-reg and tiff-fx were identified by you and John
Klensin as deserving of priority to try and realize a mid-September 02
approval by IESG as Draft Standards. Given that we are approaching mid-June
it is now questionable whether end-of-2002 is possible for approval by IESG
as Draft Standards.

Please comment.

Lloyd

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Sunday, June 09, 2002 1:45 PM
> To: [email protected]; [email protected];
> [email protected]
> Cc: [email protected]; [email protected]
> Subject: AD review comments on draft-ietf-fax-esmtp-conneg-01.txt
> 
> 
> 
> 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
>