Re: [hrpc] Working group last call for draft-irtf-hrpc-guidelines

[Eliot Lear <[e-mail]>]

Hi Gurshabad,

Thanks for your responses.  Please see below.


>> For "Impacts"-
>>
>> These impacts are claimed, both here and in 8280, but the linkage isn't
>> explicitly made in each case.  Are these linkages made clear somewhere
>> else?  I may have entirely missed it, in which case this issue isn't an
>> issue at all.  Otherwise, one wonders if we are putting the cart before
>> the horse.
>>
> I think the explanation and examples under each each sub-section of 2.3
> are intended to make these links explicit. Are you referring to some
> other sort of links between rights and properties of protocols/specs?

In reviewing Section 2.3, I think my confusion comes from the examples.  
Let's consider Section 2.3.1:

The key point in the section is probably this sentence:

>  However,
>    protocols relying on middleboxes can create potential for abuse, and
>    intentional and unintentional censoring, thereby influencing
>    individuals' ability to communicate online freely and privately.

A good example for middleboxes is actually Email, not NATs or firewalls, 
because the tradeoffs for email are most plain.  Email provides a point 
of rendezvous to enable scaling.  Furthermore, having email servers, as 
opposed to directly delivering to end devices, has additional security 
benefits to reduce spamming, phishing, and malware attacks.  But those 
same middleboxes that scan for bad behaviors could scan for politically 
sensitive content, and thus infringe on people's rights, because we have 
yet to find ways to properly scale end-to-end encryption to the billions 
of people.

There isn't that much of a tradeoff for NATs these days- nobody likes 
them architecturally, but I think people would be hard pressed to 
demonstrate harm to human rights.  Moreover, NATs are designed to be 
transparent to most – but not all – protocol transactions.  and so there 
isn't much of a tradeoff, and this makes people scratch their heads when 
relating a NAT to "Right to freedom of assembly and association".

In fact, arguably this section should probably focus on applications and 
social network sites, where this tussle has played out in far more 
dramatics style over the last several years.  Consider the tradeoffs of 
a wildly popular IM application, which makes great use of middleboxes 
(there isn't really an IM system that doesn't).

> As I understand it, we are not proposing an ideal workflow as such. We
> are just listing out some assessment frameworks (which may be used
> independently or in conjunction with each other).

Up to you.

>
>> A few of the examples seem to me a bit disjoint from the IETF.  I think
>> we talked about Accessibility at some point, but an example more
>> relevant to the IETF might help people grasp the more direct relevance
>> to the organization.  I don't have a particularly good example of this,
>> but there should at least be an existence proof of the relevance to
>> us... unless...
>>
>> ... you want the guidance to be broader than just the IETF.  I see
>> absolutely nothing wrong with that, but you should scrub the doc then to
>> make sure that IETF-specific stuff is generalized.  An example might be
>> to replace "protocol" with "specification".
>>
> I don't think we're saying this explicitly anywhere, but that's
> deliberate. Since IETF is not the only place where protocols are made, I
> think that this vagueness is acceptable. Of course, one of the primary
> goals for the document remains that it is usable by people at IETF.
>
> That said, I think we were at consensus that the guidelines are not just
> relevant to protocols, but specifications (an example at IETF would be
> specifications that lay out an architecture but not a protocol) in the
> broad area of networking. For instance, I think the group has used the
> guidelines to review the MLS architecture and SUIT architecture. Made
> some changes to say 'specification' instead of protocol where relevant.


Well... as it happens I just laid out two examples for you above ;-)  
Use them if you like.


>
>> Section 2.3.13
>>
>> I don't know that we have *any* real success stories for
>> decentralization.  HTTP certainly isn't one.  Certainly designing
>> *toward* centralization might be best, but I don't think we have very
>> many examples of that *either.*  Moreover, I have argued, and continue
>> to argue, that some centralization may *facilitate* human rights.  If
>> you take into account the combination of DOH + cloud, an observer must
>> go to far greater lengths to discern even so much as the nature of the
>> traffic, much less content and actual endpoint.
>>
>> And this raises another issue: the point of much of cloud services is to
>> improve individual service reliability.  And yet those same cloud
>> services are a form of centralization.  If you consider that perhaps a
>> handful of players might force DNS traffic to a limited number of
>> resolver services, we might also say that DoH itself presents
>> centralization risks.
>>
>> These sorts of conflicts are of course to be expected.  The question is
>> whether it is worth providing guidance relating to centralization.  I
>> will claim that nobody yet has a real handle in this area, and so better
>> to say nothing in the form of guidance.  Instead, it seems to me to be
>> good fodder for future work.
>>
> I don't think I have a strong opinion about this. Before making any
> changes in this section, however, I'd love to hear what others think.


Ok.


>
>> 2.3.17 Authenticity
>>
>> The authors write:
>>
>>>     At the same time, authentication should not be used as a way to
>>>     prevent heterogeneity support, as is often done for vendor lock-in or
>>>     digital rights management.
>> As if that should be the #1 concern.  Perhaps a bigger concern is that
>> authenticity directly conflicts with anonymity or pseudo-anonymity.  If
>> someone is forcing you to authenticate, the authentication identity can
>> and will be associated with whatever access takes place, and that
>> information can be demanded.
>>
>> Furthermore,  I'm not at all sure that the example holds up, and it
>> should be at least supported by a current reference.  Finally, there are
>> conflicts here as well: the technology that one might use for vendor
>> lock-in is  the same as that used to validate the authenticity of
>> software, for purposes of preventing malware spread.
>>
>> Also, the question itself is a bit shallow.  Authenticity of what?  If
>> we are talking about the underlying data, a mere transport connection
>> may not in and of itself provide sufficient protection.  We have plenty
>> of mail traversing encrypted tunnels and lots of spam to go with.
>>
> I agree that identity authentication can be at odds with
> anonymity/pseudonymity, but this section is not about that. I re-read
> the text and example in this section, and to me it's clear that it's
> more to do with transport/data authenticity than identity
> authentication. Would love to hear your thoughts on how we can make this
> even clearer if it's cause for confusion.

At the high level, it is that very conflict of identity authentication 
which itself provides for data authenticity (that's how Bob knows that 
it was Alice who sent the message) versus anonimity/pseudonymity (that's 
how others might know that it was Alice who sent that message) that has 
to be laid out.  The work of TLS 1.3 in particular was all about *not* 
revealing Alice's identity unless the other end is authorized to see it. 
That's probably worth capturing a bit better.  This is probably where I 
would focus the section.  It's not an easy topic, because peer to peer 
communications (as opposed to client->server) require that someone has 
to reveal something to get things going, at least using the currently 
scaled technology.

Also, the DRM discussion really is just a bit facile, and has to take 
into account the very real possibility that in some cases, the end user 
is considered the adversary.  Absent this model, services like Netflix 
could not exist, for instance.  Perhaps that's not a HR issue, but 
vendor lock-in is such a complicated issue that attempting to address it 
with a few throwaway lines isn't giving it appropriate consideration.


>
>> *Minor issues:*
>>
>> Beginning with Section 1:
>>
>>>    This is by no means an attempt to exclude specific rights or
>>>     prioritize some rights over others.  If other rights seem relevant,
>>>     please contact the authors.
>> Are we are sufficiently taking into account how linkages to other rights
>> might prevail?  Let me give an example:
>>
>> If we are talking about a new version of "whois" that retrieves
>> information necessary for law enforcement, the whole point of the
>> protocol is to expose information that some would say is private.  And
>> so the question revolves around whether appropriate protections are in
>> place to limit access to that information to authorized parties.
>> However, even doing that may not be enough, if "authorized parties" are
>> the source of abuse.  I don't know if such an example is an outlier, but
>> there it is.
>>
>> Nit: the 2nd sentence will need to be changed or removed.
> Removed the second sentence.
>
> Could you please elaborate on what you mean to demonstrate through the
> example here (with respect to linkages of rights)?

I attempted, apparently unsuccessfully, to do that with whois. This is a 
tradeoff, and perhaps better documented by ICANN than I could 
elaborate.  They've had an ongoing To Do with the EC and the GDPR, and 
they are in a far better position to explain it.

Regards,

Eliot