Hi Eliot,
I though a bit more about what you said. I think the suggestions to
developers were clear in my mind but maybe aren't all that clearly
formulated. Here are the most important suggestions that I read from the
text:
- Use IETF-specified protocols if possible
- Avoid using user-specified information inside broadcast/multicast messages
- Avoid persistent IDs in messages
- If you really must use a broadcast/multicast protocol and cannot use
an IETF-specified protocol, then:
- Be very conservative in how frequently you send messages
- Seek advice from IETF-specifies protocols such as message supression
in mDNS
- Try to design the protocol in a way that the information cannot be
correlated with other information in broadcast/multicast messages
- Let the user configure safe environments if possible (e.g. based on
the SSID)
The reasoning for the above list is in the text of the document. If we
spell out the above more clearly and add examples from our experiments,
would you say the document is ready for adoption? That is something we
can also do once the document has been adopted as part of the first
revision.
Best,
Rolf
Am 8/29/16 um 10:13 PM schrieb Eliot Lear:
Rolf,
Thanks. Please see below.
On 8/29/16 8:57 PM, Rolf Winter wrote:
What is needed are specific recommendations or even the strengthening of
a generalized mechanism, the obvious candidate being mDNS/DNS-SD. What
specific recommendations would the authors make when using 6761/6762?
Using a well-known protocols such as mDNS, DNS-SD, LLMNR etc. is only
solving parts of the problem. In our experiments, mDNS - albeit being
a standard - was a big problem concerning privacy as it often
contained PII. Section 2.3. addresses this.
Precisely my point and this is the real crux of the matter. It would be
VERY helpful if you were able to give some very specific examples of
discovery done wrong and how it would be done right. It is probably
worth noting that sometimes this is just moving the problem from
"impossible to solve" to "impractical to solve", such as when PII moves
from discovery to an application protocol where the information is sent
in the clear, and that might even make matters worse, because the
distance of the stretch of the connection. Another approach you might
want to explore is to examine common reasons why identifying information
ends up in discovery messages and what alternatives would prove better.
Now I realize that one draft can't fix everything, but there needs to be
enough advice for the developer to act on, and right now I don't think
there is.
Also, Section 2.5 talks about configurability as if that's a good
thing. Given the opportunity of the user to make a decision in this
space, he or she is likely to make the wrong one. We know this from
long experience. Again what is needed is far more specific
recommendations that do not require user interaction.
I would argue that some things require user configuration. But that
does not necessarily mean editing YAML files or similar which is too
technical for the average user. A good example (to me at least) is how
e.g. Windows asks a user what kind of network an unknown network is
(private, work or public I think are option here). Every user can
answer that and Windows decides how to configure itself based on that
piece of information. That is enough for potentially privacy leaking
protocols where at home a broadcast is supposingly fine, but
broadcasting your identity on the airport network is probably not.
Making a wrong decision here is also better than no decision I would
assume, because many protocols we observed broadcast/multicast
irrespective of the network location today. So the user won't be worse
off compared to today.
I would suggest then that you require more support for your assertion.
If you like I can dig up many papers that go the other way, not to
mention the long sordid history of TLS.
There is probably another avenue of consideration here as well. It is
probably also helpful to discuss scale. Use of unique identifiers can
adversely impact scale either within the server implementation or on the
network itself. There's a hint of this in Section 2.1 re performance
and energy consumption.
An the operational experience on the IETF meeting network. We can add
text here but some of that would be duplications of the referenced
work. But that is fine. On one of the networks where we did our
experiments, there was an average rate of 20kbit/s of broadcast and
multicast traffic. That does not sound like much, but that is average,
including nights and weekends, where there is hardly any traffic.
I think the case Stewart likes to look at is the baseball stadium or the
mall.
Eliot
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
