Subject: [drinks] Kathleen Moriarty's No Objection on draft-ietf-drinks-spp-framework-09: (with COMMENT)

From: "Kathleen Moriarty" <[email-masked]>
Date: Thu, 05 Feb 2015 05:58:30 -0800

Kathleen Moriarty has entered the following ballot position for
draft-ietf-drinks-spp-framework-09: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-drinks-spp-framework/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for addressing the SecDir review from 2 years ago.  I see that you
have added text to 9.1 to say integrity protection and confidentiality
protections are to be supported by the transport protocol.  This and the
other considerations look good.
http://www.ietf.org/mail-archive/web/secdir/current/msg03495.html

In section 8, would it be appropriate to require that the XML is well
formed and validated to prevent application and security issues?  I think
a simple statement to that effect would be helpful in this document. 
Barry says this isn't needed for apps and is assumed.  This surfaced as a
possible concern for me as a result of it being in the INCH/MILE schema
related drafts, so it may have been an apps request at the time or could
have been that the WGs were aware of a possible issue since they involve
incident responders.  In case there is an issue, I put a question out to
someone that can help, but suspect it may be a result of additional
processing requirements that we had on the schema in addition to general
conformance that could result in an issue.  I didn't see any that are out
of the ordinary in the subsequent draft, so this may not be needed. 
Hopefully I'll have a response later, but would say there is nothing to
do unless that comes in with a reason good enough.

Text in subsequent documents that tells you how to handle non-conformance
to the schema or other issues that might result in a validation problem
(if restrictions for this go beyond XML conformance) would be needed of
that were the case, not here.  This was a request for a simple statement,
that may not be needed.

---

From: Kathleen Moriarty <[email-masked]>
Date: Thu, 5 Feb 2015 17:36:41 -0500

> http://datatracker.ietf.org/doc/draft-ietf-drinks-spp-framework/

I got a response from Roman Danyliw at CERT/CC.  Although for this
draft I have not heard what the reason is for not validating
conformance.  Is it extensibility, performance, or left up to the
implementation?  I'm guessing it's not the following from Roman:

"Yes, there has exploitation of XML parser due to actual
vulnerabilities (e.g., CVE-2014-4118) in them and because of other
cleverness (e.g.,
https://www.owasp.org/index.php/XML_External_Entity_%28XXE%29_Processing
or CVE-2014-8090).  XML parsing libraries are complicated so they're
subject to the same implementation flaws as any other piece of
software.  However, It's not clear you can jump from these flaws to
say that's why you want only loose XML conformance in a protocol.
You'd be mixing design and implementation.  You can validate XML
without using a parser, you just need to write the customer code
then."

Thanks,
Kathleen

-- 

Best regards,
Kathleen