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 9CAB51A1A2C;
 Fri, 10 Oct 2014 19:53:21 -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 U6R1IgRropfK; Fri, 10 Oct 2014 19:53:19 -0700 (PDT)
Received: from mail-pa0-x232.google.com (mail-pa0-x232.google.com
 [IPv6:2607:f8b0:400e:c03::232])
 (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits))
 (No client certificate requested)
 by ietfa.amsl.com (Postfix) with ESMTPS id 65E3E1A1A3A;
 Fri, 10 Oct 2014 19:53:19 -0700 (PDT)
Received: by mail-pa0-f50.google.com with SMTP id kx10so2791843pab.37
 for <multiple recipients>; Fri, 10 Oct 2014 19:53:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; 
 h=from:content-type:content-transfer-encoding:mime-version:subject
 :date:message-id:references:cc:in-reply-to:to;
 bh=KFkuJi+Psn1Xts2hTmhkENqE5lKlcDujdj8kXeGjsAI=;
 b=jBSTGDhtdA29D8YRxeik7xgWWfCAxlZdCcrODsp8+c56PQ+nf0rWff3M2/8MxwZM+K
 e5H72+8yUwnBhfFXPixE4/D14qzuXa0EBPqgTBD+9RZUrkY2w1rcHsiUGnaekYjaaAN8
 yQMjc4jFwFTJXoX/3BfxbwuePROmUak03gpSXm6fYzPikHW/iqhcLRItYJ/cl3POo5jt
 TOPb55cNbLOz2uXrgS+VB2/6ebdbPSTVvR/9GYuRgPSj8pJ7C4DSVx6MRePHjWmUf0CG
 Miunn91Kqj8Boe3qPm+7YF4vkeJlzz8SiCG5Tr60WViFtneAmjKSYpNWPzQdNZsR44sA
 QXpw==
X-Received: by 10.68.200.101 with SMTP id jr5mr9427750pbc.36.1412995999127;
 Fri, 10 Oct 2014 19:53:19 -0700 (PDT)
Received: from [10.251.116.201] (mobile-107-107-63-46.mycingular.net.
 [107.107.63.46])
 by mx.google.com with ESMTPSA id lb10sm4706940pbc.67.2014.10.10.19.53.17
 for <multiple recipients>
 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128);
 Fri, 10 Oct 2014 19:53:17 -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
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (1.0)
Date: Fri, 10 Oct 2014 18:58:05 -0700
Message-Id: <AFBD5392-FB3D-42B6-A12F-839DA9506DB9@gmail.com>
References: <0e2601cfe210$7a2da6c0$6e88f440$@nict.go.jp>
 <CABkgnnWzYoXGqK1wCtCRxdGqa=7WZuGHOG3DZhsGo11F_Eqn9Q@mail.gmail.com>
 <002101cfe293$0cd79a80$2686cf80$@nict.go.jp>
In-Reply-To: <002101cfe293$0cd79a80$2686cf80$@nict.go.jp>
To: Takeshi Takahashi <takeshi_takahashi@nict.go.jp>
X-Mailer: iPhone Mail (11D257)
Archived-At: http://mailarchive.ietf.org/arch/msg/secdir/Mp64dPE5Kokm5rXmRWIUh7zLO_g
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 02:53:21 -0000

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 exp=
ertise as well, it's a short schema (that I think looks good without tools) a=
nd should not take much time.

The apps ADs may appoint someone, but in the meantime, this may help us prog=
ress this draft.

Thanks for your SecDir review and the level of detail in your review.  It's h=
elpful.

Best regards,
Kathleen

Sent from my iPhone

> On Oct 7, 2014, at 5:59 PM, "Takeshi Takahashi" <takeshi_takahashi@nict.go=
.jp> wrote:
>=20
> Hello Martin,
>=20
> I see, thank you for the clarification.
>=20
> Kind regards,
> Take
>=20
> -----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@tool=
s.ietf.org; The IESG; secdir@ietf.org
> Subject: Re: Secdir review of draft-ietf-geopriv-uncertainty-03
>=20
> Thanks for the review,
>=20
> The draft is, as you note, in two pieces.  However, when I took this to th=
e working group in two parts, the overwhelming consensus there was to merge t=
he documents.  As a result, it becomes standards track with large informatio=
nal sections.  The normative parts are small, and so the use of 2119 languag=
e is also restricted.
>=20
> As for your concerns about security, the general issue of altering parts o=
f 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 f=
or confidentiality and integrity, for instance).
>=20
>> On 7 October 2014 02:24, Takeshi Takahashi <takeshi_takahashi@nict.go.jp>=
 wrote:
>> Hello,
>>=20
>> I have reviewed current version of this document as part of the=20
>> security directorate's ongoing effort to review all IETF documents=20
>> being processed by the IESG.  These comments were written primarily=20
>> for the benefit of the security area directors.  Document editors and=20
>> WG chairs should treat these comments just like any other last call comme=
nts.
>>=20
>> This draft provides lots of information on how to handle uncertainty=20
>> and confidence.
>> It also defines a schema for describing confidence information.
>>=20
>> I believe this document is very helpful for readers.
>> It outlines assorted techniques in a very clear way.
>>=20
>> I think this draft is almost ready, but I have clarification questions=20=

>> as follows.
>>=20
>>=20
>> 1. standards track (std), or informational?
>>=20
>> I am not sure what would be the criteria for being a std RFC, but I=20
>> 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=20=

>> is appreciated.
>>=20
>> A std RFC specifies the interfaces that communication parties need to=20
>> follow, IMHO.
>> The RFC 3863 and 5139 is std RFCs since they define data format/schema=20=

>> each communication party needs to follow.
>> The RFC 3693, which this draft is updating, is an informational RFC=20
>> and provides lots of useful knowledge, but it does not force anything=20
>> to communication parties.
>> How is the case of this draft?
>>=20
>> I know that the draft specifies a schema for the confidence=20
>> information, but I feel like this is rather smaller part of the issues=20=

>> discussed in this draft.
>> It talks about schemes to handle uncertainty, but it does not define a=20=

>> single scheme to handle uncertainty. (It outlines several techniques,=20
>> but implementers need to consider which techniques to use, and they=20
>> can implement different techniques, IMHO.)
>>=20
>> To sum up, I would appreciate if you could clarify why the draft is in=20=

>> the std rfc.
>>=20
>>=20
>>=20
>> 2. why this document is not split into two documents?
>>=20
>> This is related to the issue 1.
>>=20
>> Here are my understanding of the sections.
>> Section 7 defines the confidence schema.
>> I understood that this document normatively defines this schema and=20
>> implementers need to follow this schema.
>> On the other hand, sections 2 - 5 provides helpful information, but=20
>> the draft does not mandate implementers to do anything.
>> I have understood that implementers can use arbitrary techniques=20
>> (including the techniques introduced in this document) to handle uncertai=
nty.
>>=20
>> I wonder whether it would have been easier to have separate drafts for=20=

>> the issues; i.e., the content described in section 7 goes to std RFC=20
>> while the rest goes to another informational rfc.
>>=20
>>=20
>>=20
>> 3. content in sections 2-5
>>=20
>> Thank you for your elaboration.
>> This is very helpful to get knowledge on the uncertainty manipulation.
>>=20
>> If this document goes to a std RFC, I would expect to see sentences=20
>> such as "SHOULD/MUST/is recommended to use the techniques to handle=20
>> uncertainty", in these sections.
>>=20
>>=20
>>=20
>> 4. security considerations
>>=20
>> If the confidence information is maliciously altered, does it cause=20
>> trouble to the information receiver?
>> (I think the RFC 4119 (and RFC 3694) does not address the need to=20
>> protect confidence information.)
>>=20
>> Information sender sents a location information with high confidence=20
>> value, but the information receiver received the information with=20
>> falsified low confidence value.
>> I guess this could hinder some decision making of the information=20
>> receiver in some case.
>>=20
>> So, I think it would be safer to say something like that we should=20
>> implement schemes to protect the values that is defined outside the=20
>> scope of this draft, etc.
>>=20
>>=20
>>=20
>> Kind regards,
>> Take
>>=20
>>=20
>> ---
>> Takeshi Takahashi, Ph.D.,
>> Senior Researcher at the National Institute of Information and=20
>> Communications Technology, Japan takeshi_takahashi@nict.go.jp
>=20