---------- Minutes - GEOPRIV - IETF81 Summary (prepared by Richard Barnes): 1. Chairs' Introduction The chairs noted the publication of RFC 6280 since the last IETF, and the entry of two other drafts into the RFC Editor queue. The residential gateway LIS discovery document needs reviews from people other than the authors. 2. Policy URIs draft-ietf-geopriv-policy-uri The document has been updated to address WGLC comments from Ted Hardie, Ben Campbell, and Adam Roach. The authors believe it is ready for publication request, and the chairs should submit soon. 3. HELD Measurement Extensions draft-ietf-geopriv-held-measurements The authors received a review from a Mozilla reviewer, and are awaiting one from a Skyhook reviewer. The draft will be revised based on this feedback. The chairs requested that the authors relay feedback they receive to the list. 4. Civic Address Extensibility draft-ietf-geopriv-local-civic The last remaining issue for this document was whether the IANA registry created by this document should have a single class and admission requirements, or whether it should be divided. After some discussion, there was consensus that the registry should be divided into two parts, one requiring standards action, and one with looser admission criteria (specificiation or FCFS). James Winterbottom agreed to make this change and re-submit the document. 5. GEOPRIV Policy draft-ietf-geopriv-policy Martin Thomson reviewed the single open issue with this draft, namely the question of what the document should say about obscuring of geodetic information. After some discussion, there was consensus that the authors would revise Mr. Thomson's draft text on this topic in order to clarify the risks associated with geodetic fuzzing (and making a rough analogy to civic fuzzing), and to move the example algorithm to an informative appendix. Raw notes from Matt Lepinski follow. -------- --------------- GEOPRIV --------------- Note: Residential Gateway discovery needs reviewers who are not authors! ***** Policy URI (Richard Barnes) -- Draft has completed working group last call (see slides for changes) -- Draft publication will be requested soon ***** Local Civic (James Winterbottom) -- Discussion of the registry created by the document In particular, should the elements in this new registry have a flag indicating "SHOULD IMPLEMENT" Cullen: Note that some IETF registries require a standards track document to get one of the 'primary' code points but you can get a vendor-specific code point with a much lower requirement James W: Note that if you don't implement a particular code point, there isn't any harm (since we carry it through if you don't understand it) Ted H: How does the 'SHOULD IMPLEMENT' affect the translation piece? Paul H: We just tried to do this ('SHOULD IMPLEMENT' column in registry) in DNSext and the IESG said "No" Brian R: Cites an example, when we created the fields in 4119 we added a 'suffix street type', it was mandatory to implement ... if we add a 'prefix street type' (Boulevard Coronado) in this registry it ought to be "SHOULD IMPLEMENT" James W: I'm really struggling to see how the "SHOULD IMPLEMENT" flag helps us, if something is compliant with the current document and it gets fields that it doesn't understand, it will still stick them in the PIDF-LO, so the ultimate consumer will Brian R: We should have some way to bifurcate the registry (separate standards action entries from others) James W: Is it enough to just put in a specification pointer in the registry? Robert AD: You will get push-back from the IESG if you appear to be trying to make the IANA registry itself the specification. Cullen: Just make two separate halfs of the registry, and we'll all be happy. Anything that's different from how things are normally done makes the IETF unhappy. -- Humm: Should the local Civic document define a registry with two parts (standards vs lesser bar)? Chairs call concensus in the room in favor of spliting the registry into two parts, this will be confirmed on the list (It appeared in the hum that only one or two people were humming "no" on this question) ***** Geopriv Policy : Location Obscuring (Martin Thompson) -- Based on what I've read in the academic literature, I'm not sure that location obscuring is a problem that we can every really solve, but we are going to try to it here anyway Comment (missed name): What about new 'assumptions', does one continously have to design new algorithms? Martin: Designing an algorithm that defeats a particular database, requires the algorithm have acces to that database I don't think there's anything we can do about this Cullen: You are making this sound much better than it really is. From an information-theoric point of view, we can't make this work. Even just speed constraints on humans, make this Doomed There is no algorithm that is going to work here for any meaningful set of constraints Robert AD: We have agreed that any algorithm we were to select would have some form of suckage However, I believe the community has told us that something a bit sucky is better than nothing at all [do we have an IANA registry of algorithms with a column for 'degree of suckitude'] Martin: There was a suggestionf or a column of 'suckitude' in the IANA registry, but I don't think that is going to happen Martin: I want to avoid making any statement about "how much" badness or leakage, the rule-maker makes the rules Hannes T: It doesn't make sense to provide some 'lower bar' without knowing the application context Martin: In essense we are starting a registry of encryption algorithms, and the only thing in the registry to begin with is ROT-13 Cullen: Agrees Robert AD: Do you want to abandon this approach, Cullen, and instead put in text explaining that obfuscation doesn't work Cullen: Ten years ago, I was would have said, we should never lie, there must be a better way. I no longer believe this Note: It will be quite difficult to lie in such a way that the lies are believable Cullen: If I only release the time-zone that I am in, you can corrolate this infromation and figure out what acquisitions that Cisco is looking at Richard B: But there is some value in revealing only the city you are in. There are use-cases for giving out city-level information in which users do not Ted H: You can end up with a much worse situation with lying then we were to begin with. (I could try to hide the identify of your mistress by lying and saying you are at the strip club) What you are doing here is not suitable protection against an attack. Instead, what you are doing is the equivalent to leaving civic elements out of a civic address. No better and no worse. This is all you ever could do. -- Appears to be general agreement with Ted. Whenever you give out information about location, you are giving out information and there is a cost (which we cannot prevent). We are providing a way to disclose infromation at a given granularity, we are not protecting against any attack, we are providing a mechanism for disclosing information based on user (rule-maker) preferences. -- Question: Do we include an example algorithm with a discussion of why/how it sucks? Cullen: If we don't put anything we're going to get multiple implementations which Take X and Y and add a random number to each coordinate, with a new random number each time you call the function. We should have an appendix with a non-normative algorithm that is better than the algorithm Cullen just described Alissa Chair: If we include one that you might use, aren't people going to say "Why don't you include my algorithm too?" Martin T: The problem that I have with this approach is how can the rule-maker convey his preferences in such a way that he is reasonably certain that whatever algorithm is used will behaive in a way that meets the rule-maker's expectations Jon P: There are really different threat models that you can differentaite ... there is a difference between Google and Facebook as the adversary versus some pizza place that you order from twice in your life. However, we can talk about threat models all we want, but when the rule-maker decides what infromation to share, how can we expect him to make a reasonable judgement Martin T: In all things Privacy, there is plenty of room for regrets -- PLAN GOING FORWARD: Martin and Ted will revise the document and put new text to the list within the next few weeks (including an example algorithm and its suckitude in an appendix)