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)
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
