Re: [secdir] Secdir review of draft-ietf-geopriv-uncertainty-03

Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com> Sat, 11 October 2014 12:48 UTC

Return-Path: <kathleen.moriarty.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 864EF1A1BC4; Sat, 11 Oct 2014 05:48:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gNGeK7IO5Ev3; Sat, 11 Oct 2014 05:48:55 -0700 (PDT)
Received: from mail-qg0-x22f.google.com (mail-qg0-x22f.google.com [IPv6:2607:f8b0:400d:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 743671A1BBF; Sat, 11 Oct 2014 05:48:55 -0700 (PDT)
Received: by mail-qg0-f47.google.com with SMTP id i50so4987061qgf.20 for <multiple recipients>; Sat, 11 Oct 2014 05:48:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=I6pqh0NRZbb/PYwKCigIjzCnpXSZkbusfnEuvJ6msPk=; b=cJmu6VEKSSZ2xQEMPnX9fJ0mjbqyo8KfNzeTdTvden5YASLQsF9IHTUpU/ALV02Sl2 KsEE6jj9QeftmXSm+cSPFnRD6r62VoPMbCpq5cJfkJwn2AmRhXS4GoeY5v/3Jb0zpC4h zEFRZBdVrYf6eQ3mYRPDDUiK5crZDnoW4j7KB9C8mkbREPiGTBXVQlkUcgBI8/sQJd17 iDDjtfbkbcGVpwrWT4xqkVd0jBiWxG2NbeAdnktyXzUzg4RrfmrjJqcZPpcp0gKcm8K4 6Y9v/RxWESe3lGvuJdBmPmnG7+lVw5pAXhEPGxxj+37uIZTEUh/MfHy30OBAMt2SJMwY v/Jw==
X-Received: by 10.140.29.195 with SMTP id b61mr18665358qgb.27.1413031734569; Sat, 11 Oct 2014 05:48:54 -0700 (PDT)
Received: from [192.168.1.3] (209-6-114-252.c3-0.arl-ubr1.sbo-arl.ma.cable.rcn.com. [209.6.114.252]) by mx.google.com with ESMTPSA id o12sm7415080qge.11.2014.10.11.05.48.53 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 11 Oct 2014 05:48:53 -0700 (PDT)
From: Kathleen Moriarty <kathleen.moriarty.ietf@gmail.com>
X-Google-Original-From: Kathleen Moriarty <Kathleen.Moriarty.ietf@gmail.com>
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (1.0)
X-Mailer: iPhone Mail (11D257)
In-Reply-To: <000001cfe50b$d84fc0a0$88ef41e0$@nict.go.jp>
Date: Sat, 11 Oct 2014 08:48:52 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <8CDD7E04-D7F9-4428-A258-8C9E937A245A@gmail.com>
References: <0e2601cfe210$7a2da6c0$6e88f440$@nict.go.jp> <CABkgnnWzYoXGqK1wCtCRxdGqa=7WZuGHOG3DZhsGo11F_Eqn9Q@mail.gmail.com> <002101cfe293$0cd79a80$2686cf80$@nict.go.jp> <AFBD5392-FB3D-42B6-A12F-839DA9506DB9@gmail.com> <000001cfe50b$d84fc0a0$88ef41e0$@nict.go.jp>
To: Takeshi Takahashi <takeshi_takahashi@nict.go.jp>
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/4iLiE-NjJkLM7EBUXVR085kOKOE
Cc: "<geopriv-chairs@tools.ietf.org>" <geopriv-chairs@tools.ietf.org>, "<draft-ietf-geopriv-uncertainty.all@tools.ietf.org>" <draft-ietf-geopriv-uncertainty.all@tools.ietf.org>, Martin Thomson <martin.thomson@gmail.com>, The IESG <iesg@ietf.org>, "<secdir@ietf.org>" <secdir@ietf.org>
Subject: Re: [secdir] Secdir review of draft-ietf-geopriv-uncertainty-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 11 Oct 2014 12:48:58 -0000

Thank you, Take!

Sent from my iPhone

> On Oct 11, 2014, at 12:28 AM, "Takeshi Takahashi" <takeshi_takahashi@nict.go.jp> wrote:
> 
> Hi Kathleen,
> 
> I think the schema is fine.
> 
> Here is the justification.
> I've run a validator, called MSV, to check the validity of the confidence
> schema mentioned in section 7.
> The attached xsd file is the confidence schema, and the attached bmp file is
> the result of the validation produced by the MSV validator.
> Though the validation result is written in Japanese, it basically says that
> the MSV validator could not find any problem.
> 
> Kind regards,
> Take
> 
> 
> -----Original Message-----
> From: Kathleen Moriarty [mailto:kathleen.moriarty.ietf@gmail.com] 
> Sent: Saturday, October 11, 2014 10:58 AM
> To: Takeshi Takahashi
> Cc: Martin Thomson; geopriv-chairs@tools.ietf.org; secdir@ietf.org; The
> IESG; draft-ietf-geopriv-uncertainty.all@tools.ietf.org
> Subject: Re: Secdir review of draft-ietf-geopriv-uncertainty-03
> 
> Hi Take,
> 
> Can you do me a favor and validate the schema in section 7?  I'll do this as
> well, but am on travel and don't have all the tools I need.
> 
> We may need to get new XML schema experts listed.  I'm one of them, but just
> for IODEF and the others are not available so far.  I know you have the
> expertise as well, it's a short schema (that I think looks good without
> tools) and should not take much time.
> 
> The apps ADs may appoint someone, but in the meantime, this may help us
> progress this draft.
> 
> Thanks for your SecDir review and the level of detail in your review.  It's
> helpful.
> 
> Best regards,
> Kathleen
> 
> Sent from my iPhone
> 
>>> On Oct 7, 2014, at 5:59 PM, "Takeshi Takahashi"
>> <takeshi_takahashi@nict.go.jp> wrote:
>> 
>> Hello Martin,
>> 
>> I see, thank you for the clarification.
>> 
>> Kind regards,
>> Take
>> 
>> -----Original Message-----
>> From: Martin Thomson [mailto:martin.thomson@gmail.com]
>> Sent: Wednesday, October 8, 2014 6:19 AM
>> To: Takeshi Takahashi
>> Cc: draft-ietf-geopriv-uncertainty.all@tools.ietf.org; 
>> geopriv-chairs@tools.ietf.org; The IESG; secdir@ietf.org
>> Subject: Re: Secdir review of draft-ietf-geopriv-uncertainty-03
>> 
>> Thanks for the review,
>> 
>> The draft is, as you note, in two pieces.  However, when I took this to
> the working group in two parts, the overwhelming consensus there was to
> merge the documents.  As a result, it becomes standards track with large
> informational sections.  The normative parts are small, and so the use of
> 2119 language is also restricted.
>> 
>> As for your concerns about security, the general issue of altering parts
> of an object is only a concern if you have partial integrity mechanisms.
> The security considerations of RFC 4119 cover a lot of that (the use of
> S/MIME for confidentiality and integrity, for instance).
>> 
>>> On 7 October 2014 02:24, Takeshi Takahashi <takeshi_takahashi@nict.go.jp>
> wrote:
>>> Hello,
>>> 
>>> I have reviewed current version of this document as part of the 
>>> security directorate's ongoing effort to review all IETF documents 
>>> being processed by the IESG.  These comments were written primarily 
>>> for the benefit of the security area directors.  Document editors and 
>>> WG chairs should treat these comments just like any other last call
> comments.
>>> 
>>> This draft provides lots of information on how to handle uncertainty 
>>> and confidence.
>>> It also defines a schema for describing confidence information.
>>> 
>>> I believe this document is very helpful for readers.
>>> It outlines assorted techniques in a very clear way.
>>> 
>>> I think this draft is almost ready, but I have clarification 
>>> questions as follows.
>>> 
>>> 
>>> 1. standards track (std), or informational?
>>> 
>>> I am not sure what would be the criteria for being a std RFC, but I 
>>> feel like that this draft talks as if it is an informational draft.
>>> I do not mean that I object to make it as a std rfc, but 
>>> clarification is appreciated.
>>> 
>>> A std RFC specifies the interfaces that communication parties need to 
>>> follow, IMHO.
>>> The RFC 3863 and 5139 is std RFCs since they define data 
>>> format/schema each communication party needs to follow.
>>> The RFC 3693, which this draft is updating, is an informational RFC 
>>> and provides lots of useful knowledge, but it does not force anything 
>>> to communication parties.
>>> How is the case of this draft?
>>> 
>>> I know that the draft specifies a schema for the confidence 
>>> information, but I feel like this is rather smaller part of the 
>>> issues discussed in this draft.
>>> It talks about schemes to handle uncertainty, but it does not define 
>>> a single scheme to handle uncertainty. (It outlines several 
>>> techniques, but implementers need to consider which techniques to 
>>> use, and they can implement different techniques, IMHO.)
>>> 
>>> To sum up, I would appreciate if you could clarify why the draft is 
>>> in the std rfc.
>>> 
>>> 
>>> 
>>> 2. why this document is not split into two documents?
>>> 
>>> This is related to the issue 1.
>>> 
>>> Here are my understanding of the sections.
>>> Section 7 defines the confidence schema.
>>> I understood that this document normatively defines this schema and 
>>> implementers need to follow this schema.
>>> On the other hand, sections 2 - 5 provides helpful information, but 
>>> the draft does not mandate implementers to do anything.
>>> I have understood that implementers can use arbitrary techniques 
>>> (including the techniques introduced in this document) to handle
> uncertainty.
>>> 
>>> I wonder whether it would have been easier to have separate drafts 
>>> for the issues; i.e., the content described in section 7 goes to std 
>>> RFC while the rest goes to another informational rfc.
>>> 
>>> 
>>> 
>>> 3. content in sections 2-5
>>> 
>>> Thank you for your elaboration.
>>> This is very helpful to get knowledge on the uncertainty manipulation.
>>> 
>>> If this document goes to a std RFC, I would expect to see sentences 
>>> such as "SHOULD/MUST/is recommended to use the techniques to handle 
>>> uncertainty", in these sections.
>>> 
>>> 
>>> 
>>> 4. security considerations
>>> 
>>> If the confidence information is maliciously altered, does it cause 
>>> trouble to the information receiver?
>>> (I think the RFC 4119 (and RFC 3694) does not address the need to 
>>> protect confidence information.)
>>> 
>>> Information sender sents a location information with high confidence 
>>> value, but the information receiver received the information with 
>>> falsified low confidence value.
>>> I guess this could hinder some decision making of the information 
>>> receiver in some case.
>>> 
>>> So, I think it would be safer to say something like that we should 
>>> implement schemes to protect the values that is defined outside the 
>>> scope of this draft, etc.
>>> 
>>> 
>>> 
>>> Kind regards,
>>> Take
>>> 
>>> 
>>> ---
>>> Takeshi Takahashi, Ph.D.,
>>> Senior Researcher at the National Institute of Information and 
>>> Communications Technology, Japan takeshi_takahashi@nict.go.jp
> <confidenceschema.xsd>
> <schemaValidationResult.bmp>