Re: [Ecrit] Stephen Farrell's Discuss on draft-ietf-ecrit-additional-data-34: (with DISCUSS and COMMENT)

["Rosen, Brian" <[e-mail]>]

I’m okay with the MUST NOT except, and I can imagine other uses for these that will work fine if we write a document that explains them.

I’m strongly against standards track for extensions.  There are a number of organizations who have expertise that need to be able to define the data.  We can’t be experts in all things.  An example is that we’re going to extend for medical data useful to a first responder.  Clearly has major privacy issues, but we’re not the experts in that, and those that are don’t write RFCs.  NENA, the 9-1-1 organization in North America is working on extensions for location related data, and also knows 10X more about location data for emergency response than IETF does.  We need to let the experts do their jobs.

Brian

> On Sep 1, 2015, at 4:47 PM, Stephen Farrell <[e-mail]> wrote:
> 
> Stephen Farrell has entered the following ballot position for
> draft-ietf-ecrit-additional-data-34: Discuss
> 
> 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 https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-ecrit-additional-data/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> 
> I've two things I'd like to chat about. (Note: I'm not trying
> here to insist on my preferred outcome, but I would like to
> have the discussion or else be pointed at where the WG 
> already did that.)
> 
> (1) section 3: You say these MAY be used.  I'm not
> sure that's a good option.  I think the data
> minimisation recommendations argued for in RFC6973 and
> RFC7258 would argue to add a MUST NOT. For example,
> saying that these additional data MUST NOT be sent in
> any non-emergency call without explicit user
> permission on a per-call basis or something similar?
> I have to admit I'm nervous that defining all of these
> may mean that some UA somewhere starts sending some of
> them in other calls without asking. A restriction
> along those lines would also be more in line with
> webrtc too perhaps. But maybe this was discussed in
> the WG, having considered those privacy issues - was
> it? Either way, would adding such a "MUST NOT except
> if..." be a good plan?  4.3.4 is a good example of the
> kind of thing I'd not want easily emitted in a call.
> 
> (2) I'd like to (perhaps briefly) argue that the
> registries here should require more than expert
> review. Extensibility in dealing with what will
> inevitably be highly privacy sensitive data structures
> that are vulnerable to misuse once registered seems to
> perhaps call for a more stringent registration regime.
> The document itself also argues (in 4.3.7) that adding
> new kinds of data here can be counter productive for
> emergency call handling, so being more conservative in
> what we add seems unusually correct here. I'd like to
> suggest we require standards track for extensions.
> The following very recent -00 draft [1] makes some
> related arguments (but of course has no standing in
> the IETF so is just offered as a way to avoid
> repeating some arguments, not as an appeal to
> authority.)
> 
>   [1]
> https://tools.ietf.org/html/draft-nottingham-transport-metadata-impact-00
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> 
> - abstract: the "or by reference" point is made twice
> in the abstract
> 
> - intro: floor plans? HVAC status? really? Why not
> contact lists? proximity of friends? That (or
> inferring as much) seems to me to be going too far, if
> applied to all calls. I'd say just saying that this
> could be extended in future by other standards-track
> specifications is enough. (See also discuss points above)
> 
> - intro: Wedding anniversary? That's surely not
> relevant to a PSAP. 
> 
> - figure 5: "prison" is out of context here, I'd suggest 
> deleting it. If not, why not add hospital, power station 
> and many other kinds of building? There may be some 
> country specific issue or technical here, but labelling 
> that with "prison" seems inappropriate to me. 
> 
> - 4.3.8: sorry I don't get the privacy argument, can
> you try explain it to me?  (I didn't know it was
> possible to tempt an implementation, so the language
> there could be improved for sure:-)
> 
> - section 5: good that this is HTTPS only. I think
> provisioning the PKI for such a thing is easily done
> these days and is rightly not optional. It might be
> useful to say that TLS here needs to follow BCP195.  I
> agree with the earlier comment that you should be
> clear as to when mutually authenticated TLS is
> required. The secdir review [2] also raised similar
> issues and it'd be good to see responses to that too.
> (Yes, that review only arrived today so it's entirely
> reasonable to not have responded so far.)
> 
>   [2]
> https://www.ietf.org/mail-archive/web/secdir/current/msg05982.html
> 
> - section 8: the sizes of the various additional data
> items here could be characteristic and leak value
> information regardless of TLS or not-TLS - perhaps add
> a warning that these may enable relatively simple
> traffic analysis. And wouldn't it be nice if someone
> had done the analysis of this potential vulnerability?
> This is btw a real issue - recall that avatar icon
> image size was usable to identify 30+% of contacts in
> one social network even over TLS, but before the
> provider canonicalised the avatar image sizes. 
> 
> - Thanks for section 9. Good job.
> 
> 
> _______________________________________________
> Ecrit mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ecrit