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

[Kathleen Moriarty <[e-mail]>]

Thank you, Take!

Sent from my iPhone

> On Oct 11, 2014, at 12:28 AM, "Takeshi Takahashi" <[e-mail]> 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:[e-mail]] 
> Sent: Saturday, October 11, 2014 10:58 AM
> To: Takeshi Takahashi
> Cc: Martin Thomson; [e-mail]; [e-mail]; The
> IESG; [e-mail]
> 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"
>> <[e-mail]> wrote:
>> 
>> Hello Martin,
>> 
>> I see, thank you for the clarification.
>> 
>> Kind regards,
>> Take
>> 
>> -----Original Message-----
>> From: Martin Thomson [mailto:[e-mail]]
>> Sent: Wednesday, October 8, 2014 6:19 AM
>> To: Takeshi Takahashi
>> Cc: [e-mail]; 
>> [e-mail]; The IESG; [e-mail]
>> 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 <[e-mail]>
> 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 [e-mail]
> <confidenceschema.xsd>
> <schemaValidationResult.bmp>