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

Kathleen Moriarty <> Thu, 05 February 2015 22:36 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E0AD31A6FEE; Thu, 5 Feb 2015 14:36:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id G-siKHY6ELXk; Thu, 5 Feb 2015 14:36:43 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4010:c04::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8EC7F1A6F0E; Thu, 5 Feb 2015 14:36:43 -0800 (PST)
Received: by with SMTP id z11so11504221lbi.10; Thu, 05 Feb 2015 14:36:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=szJagYjF5GiU1HvInSpYKQX7iNrrkfcLGJZXt39UmTI=; b=0mPeDPwGSP/IOoOPbnt87eUm2UnQcMGdvZ2pYBZDjMUi3fR5KA8tsIcWBh/5vR5I0Q 9lglGaIl5ImZ5WjN0rawas0sfNBEfZbsJWRameQENpla7sSSD4+JfRNd7GejQebWPtJF 5O9sLBRm3h1aN72qh3mTs0nZakW33RVDbOUbMAvmh1i7bncjwEUC6xUpHS2q5hoZhJIP gJdyFvprCMtsTKU4SmbGYOaX/8hmzH6xyQ9COWuXWiJgWoQ2UK0lqUSJXuR7gS8Kqmhu nNq2sfsfUisLhW0OEevLDihuacGQ03/v/3OAgHfhnKa7ZjwjV+z76Ac5nnQpvr8yUdeX zzXw==
MIME-Version: 1.0
X-Received: by with SMTP id kx1mr298287lac.75.1423175801947; Thu, 05 Feb 2015 14:36:41 -0800 (PST)
Received: by with HTTP; Thu, 5 Feb 2015 14:36:41 -0800 (PST)
In-Reply-To: <>
References: <>
Date: Thu, 5 Feb 2015 17:36:41 -0500
Message-ID: <>
From: Kathleen Moriarty <>
To: The IESG <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
X-Mailman-Approved-At: Thu, 19 Feb 2015 00:22:32 -0800
Subject: Re: [drinks] Kathleen Moriarty's No Objection on draft-ietf-drinks-spp-framework-09: (with COMMENT)
X-Mailman-Version: 2.1.15
Precedence: list
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Feb 2015 22:36:46 -0000

On Thu, Feb 5, 2015 at 8:58 AM, Kathleen Moriarty
<> wrote:
> 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
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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.
> 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.

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.,
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



Best regards,