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

From: "Takeshi Takahashi" <[email-masked]>
Date: Tue, 7 Oct 2014 18:24:21 +0900

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 [email-masked]

---

From: Martin Thomson <[email-masked]>
Date: Tue, 7 Oct 2014 14:18:59 -0700

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

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Wed, 8 Oct 2014 09:59:01 +0900

Hello Martin,

I see, thank you for the clarification.

Kind regards,
Take

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: Wednesday, October 8, 2014 6:19 AM
To: Takeshi Takahashi
Cc: [email-masked]; [email-masked]; The IESG; [email-masked]
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 <[email-masked]> 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.
> I think this draft is almost ready, but I have clarification questions 
> as follows.
>
>
> 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.
>
> 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.
> 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.
> 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.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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
>
>
> ---

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 10 Oct 2014 18:58:05 -0700

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" <[email-masked]> wrote:
> 
> Hello Martin,
>

---

From: "Takeshi Takahashi" <[email-masked]>
Date: Sat, 11 Oct 2014 13:28:45 +0900

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:[email-masked]] 
Sent: Saturday, October 11, 2014 10:58 AM
To: Takeshi Takahashi
Cc: Martin Thomson; [email-masked]; [email-masked]; The
IESG; [email-masked]
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

> Cc: [email-masked]; 
> [email-masked]; The IESG; [email-masked]
> 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).
>> I think this draft is almost ready, but I have clarification 
>> questions as follows.
>> 
>> 
>> I do not mean that I object to make it as a std rfc, but 
>> clarification is appreciated.
>> 
>> The RFC 3863 and 5139 is std RFCs since they define data 
>> format/schema each communication party needs to follow.
>> 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.
>> 
>> 
>> 
>> 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.
>> 
>> 
>>

---

From: Kathleen Moriarty <[email-masked]>
Date: Sat, 11 Oct 2014 08:48:52 -0400

Thank you, Take!

Sent from my iPhone

> On Oct 11, 2014, at 12:28 AM, "Takeshi Takahashi" <[email-masked]> wrote:
> 
> Hi Kathleen,
> 
> <confidenceschema.xsd>