Subject: [hrpc] Feedback on guidelines on human rights considerations

From: Shane Kerr <[email-masked]>
Date: Thu, 7 Jul 2016 20:30:54 +0200

Hello,

I volunteered to try to apply the guidelines in
draft-tenoever-hrpc-research to a draft that I have been working on
with some colleagues. Niels asked me to send my observations to the
list.

Summary
=======
Basically I think that it is a useful checklist.

I think the list can be shortened (pointed out in detail below). Indeed
I worry a bit that it is too long, even with a few items removed.
Perhaps something can be written about the relative importance of the
items?

My Draft
========
I'm working with my colleagues on a "DNS over HTTP" draft. This
describes a protocol for encapsulating DNS messages and then sending
them over HTTP... kind of a protocol-specific tunnel in a way.

https://datatracker.ietf.org/doc/draft-song-dns-wireformat-http/

We don't really introduce any new protocols, but kind of duct-tape two
very popular protocols together. 

This is very much useful as a tool for circumventing censorship (at
least the DNS part of censorship).

Highlights of the review
========================
I have a detailed review which is probably only interesting for my
co-authors and myself. Here are some highlights that I think might be
interesting for this group.

BTW, while I have questions below, it's not really so important to give
*me* answers. Instead the hrpc draft should be clarified so that people
using it don't end up confused too. (Although it is possible that I am
just easily confused...)

5.3.2.1.2. Privacy

I had not looked at RFC 6973 section 7. This was a useful recommendation.

*** Are there experts we can ask for advice in this area? Maybe setting
    up a list of people willing to give advice would be useful...

5.3.2.1.8. Heterogeneity Support

*** This one confuses me. Is it asking if the protocol will work in
    heterogeneous environments or what?

5.3.2.1.9. Anonymity

I had not looked at RFC 6973 section 6. This was a useful
recommendation.

5.3.2.1.12. Localization

*** This one confuses me. Even though it references Internationalization I
    still don't know how this is different or what I am supposed to be
    considering.

5.3.2.1.15. Confidentiality

As a DNS protocol, DNS over HTTP exposes a ton of confidential information!

I think that I'll add a note in the draft about this, and mention that
proxies may want to consider what and how they log information, as
well as things like DNS query minimization.

*** Thanks, this was a big "win". :)

5.3.2.1.18. Acceptability

*** I'm not clear how this differs from accessibility.

5.3.2.1.19. Availability

*** I'm not sure how this is different from open standards, although I
    suppose it could be related to legal restrictions (such as laws
    against encryption or the like)?

5.3.2.1.20. Adaptability

*** I'm not really sure what to do about this, or what it means exactly.
    We have two inter-operable implementations, both open source, if
    that is somehow related?

Conclusion
==========
My own feeling is that while this checklist is helpful in the current
form, it should probably be shortened and clarified.

Cheers,

--
Shane

---

From: Joseph Lorenzo Hall <[email-masked]>
Date: Fri, 8 Jul 2016 15:18:23 -0400

This is great to see, Shane...

>     up a list of people willing to give advice would be useful...

There is [email-masked] although I forget what purpose that
serves... and there is SAAG, but that might be too big of a tent for
this purpose. I'd be happy to find a home for this kind of function,
although I suspect more senior IETF folks (Stephen!) might have more
well-formed thoughts (although I'd still be willing to coordinate,
lead, etc.)

best, joe

-- 
Joseph Lorenzo Hall
Chief Technologist, Center for Democracy & Technology [https://www.cdt.org]
1401 K ST NW STE 200, Washington DC 20005-3497
e: [email-masked], p: 202.407.8825, pgp: https://josephhall.org/gpg-key
Fingerprint: 3CA2 8D7B 9F6D DBD3 4B10  1607 5F86 6987 40A9 A871

---

From: Niels ten Oever <[email-masked]>
Date: Tue, 12 Jul 2016 12:33:53 +0200

Hi Shane,

Comments inline:

> least the DNS part of censorship).

[email-masked] is indeed the list for this. When you have any
questions on privacy implications of your draft that list will review
and provide guidance.

>     heterogeneous environments or what?

Yes, and whether it will in turn allow for multiple types of hardwae and
multiple types of application protocols.

Where these questions and the example under 5.3.2.1.8 not clear? Any
suggestions?

>     still don't know how this is different or what I am supposed to be

Internationalization is making it possible for a protocol,
implementation or application to be localized. The localization is the
actual act of translating and contextualizing it.

This bring about questions similar to the ones that were brought up by
Ramsey Nasser at IETF95 at his presentation.

> *** Thanks, this was a big "win". :)

nice!

> *** I'm not clear how this differs from accessibility.

Here we might run into a tech <-> law translation issue again.
Accessibility as it is used in the questionnaire refers to

: The design of protocols, services or implementation that provide an
enabling environment for people with disabilities.

Acceptability is a bit broader human rights concept that refers to
sensitizing protocol, in this case, toward the multiple forms of
discrimination that might arise at the intersection of race, gender,
class, ethnicity, disability or other identities and backgrounds.

Because accessibility is a better understood (and documented) term in
technology, we chose to keep them both.

>     against encryption or the like)?

You're right. I merged this with open standards.

>     We have two inter-operable implementations, both open source, if

It is, that is exactly what this aims to encourage. So I added:

"Is your protocol written in such a way that is would be easy for other
protocols to be developed on top of it, or to interact with it?"

Would this help?

> Conclusion

Thanks a lot for this. I hope we can further discuss so we can shorten
and clarify further.

Best,

Niels

> 
> Cheers,
> 
> --
> Shane
> 
> 
> 
> _______________________________________________
> hrpc mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/hrpc
>