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

[Mallory Knodel <[e-mail]>]

Hi all,

Thanks so much for the reviews that came in last call.

After talking with Gurshabad, I am going to move this draft toward 
publication. Most suggestions below are about including examples, so 
keeping in tact some of that remaining discussion open for other 
reviews, such as in the IRSG, will be part of the detail that I pass on.

Thanks all,

-Mallory

On 7/1/21 9:53 AM, Eliot Lear wrote:
>
> 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
>
-- 
Mallory Knodel
CTO, Center for Democracy and Technology
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780