Subject: [Ltru] ltru-matching draft review

From: r&d afrac <[email-masked]>
Date: Thu, 16 Mar 2006 22:36:47 +0100

I reviewed the ltru-matching draft.

1. the term "matching" is improper for the whole document.The purpose 
if filtering, even if pattern matching techniques are used. The 
purpose is not to list all the possible langtags matching the 
documented pattern, but to okay or not a langtag for a given usage. 
This is documented in 3.1.1- 3.1.3, 3.1.3 is not matching the pattern 
but the priorities (i.e. first filtered). The last paragraph of the 
very very long part 3.3. without sub-part numbers, document the 
uncertain results of a matching while filtering is respected.

2. figure 3 is in violation with 4.3. as it seems to presume that the 
x-private1-private2 can be neuronally abbreviated as x-private1. This 
obligation is not documented in RFC 3066 Bis.

3. Part 4.1 is particularly laborious and indigestible. It seems to 
introduce a lot semi-constraints with uncertain results to RFC 3066 Bis.

4. security considerations are as inappropriate as the security 
considerations of RFC 3066 Bis. This whole system introduces and uses 
an unusual pattern easily searched/filtered which is usually not 
visible to the receiving party. That receiving party when responding 
send it back and discloses its positive filtering (retro-meta-spam). 
As such the proposed filtering is a most efficient source of 
cultural, racial and religious intelligence leaks. Together with the 
dissemination of RFC 3066 Bis langtags, search engines queries using 
the proposed rules should be efficient in terms of mass profiling. 
This risk should be documented in Security Considerations.

I would suggest that parts 3.3 and 4.1 be structured in several 
separate blocks. To make them easier to read and to refer to.

jfc

_______________________________________________
Ltru mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ltru

---

From: Martin Duerst <[email-masked]>
Date: Fri, 17 Mar 2006 18:14:57 +0900

Thanks for reviewing the draft.

I have added your issues to the issues list.
Please check whether I got things right.

Some more comments from a co-chair's viewpoint below.

At 06:36 06/03/17, r&d afrac wrote:
 >1. the term "matching" is improper for the whole document.The purpose if 
filtering, even if pattern matching techniques are used. The purpose is not 
to list all the possible langtags matching the documented pattern, but to 
okay or not a langtag for a given usage. This is documented in 3.1.1- 
3.1.3, 3.1.3 is not matching the pattern but the priorities (i.e. first 
filtered). The last paragraph of the very very long part 3.3. without 
sub-part numbers, document the uncertain results of a matching while 
filtering is respected.
 >4. security considerations are as inappropriate as the security 
considerations of RFC 3066 Bis.

As a co-chair, I have to work under the assumption that the WG
thinks that the security considerations of RFC 3066bis are
adequate. I do not see any reason why to reopen this issue that
we have discussed when we actually worked on RFC 3066bis.

Regards,    Martin.

 >This whole system introduces and uses an unusual pattern easily 
searched/filtered which is usually not visible to the receiving party. That 
receiving party when responding send it back and discloses its positive 
filtering (retro-meta-spam). As such the proposed filtering is a most 
efficient source of cultural, racial and religious intelligence leaks. 
Together with the dissemination of RFC 3066 Bis langtags, search engines 
queries using the proposed rules should be efficient in terms of mass 
profiling. This risk should be documented in Security Considerations.
 >
 >I would suggest that parts 3.3 and 4.1 be structured in several separate 
blocks. To make them easier to read and to refer to.

---

From: r&d afrac <[email-masked]>
Date: Fri, 17 Mar 2006 11:20:02 +0100

At 10:14 17/03/2006, Martin Duerst wrote:

> >1. the term "matching" is improper for the whole document.The 
> purpose if filtering, even if pattern matching techniques are used. 
> The purpose is not to list all the possible langtags matching the 
> This is documented in 3.1.1- 3.1.3, 3.1.3 is not matching the 
> pattern but the priorities (i.e. first filtered). The last 
> paragraph of the very very long part 3.3. without sub-part numbers, 
> document the uncertain results of a matching while filtering is respected.
> >
> >2. figure 3 is in violation with 4.3. as it seems to presume that 
> the x-private1-private2 can be neuronally abbreviated as 
> x-private1. This obligation is not documented in RFC 3066 Bis.
> >
> >3. Part 4.1 is particularly laborious and indigestible. It seems 
> to introduce a lot semi-constraints with uncertain results to RFC 3066 Bis.
> >

There are two distinct issues.

- the lack of warning about the RFC 3066 Bis pattern, which is an RFC 
3066 Bis issue and will be documented as dangerous in a document we 
will publish. The risk there is against privacy..
- the lack of warning about the added risks by this document which 
explains how langtags are filtered and which will be used in other 
standards. The added risks comes from the generalisation of this 
method. The risk is now mass profiling.

Security considerations should be neutral and list all the reasonably 
raised risks. Not listing risks isnot a way to defend a document. On 
the contrary it is a way to raise suspicions about the document. 
Everyone will know and assess these risks. Not listing them as for 
RFC 3066 bis does no good for the use of the document. We will 
document this not to hurt the system, but to make credible that we refer to it.
jfc

> searched/filtered which is usually not visible to the receiving 
> party. That receiving party when responding send it back and 
> discloses its positive filtering (retro-meta-spam). As such the 
> proposed filtering is a most efficient source of cultural, racial 
> and religious intelligence leaks. Together with the dissemination 
> of RFC 3066 Bis langtags, search engines queries using the proposed 
> rules should be efficient in terms of mass profiling. This risk 
> should be documented in Security Considerations.
> >

---

From: Mark Davis <[email-masked]>
Date: Fri, 17 Mar 2006 10:29:05 -0800

> we have discussed when we actually worked on RFC 3066bis.
I agree.

Mark

Martin Duerst wrote:
> searched/filtered which is usually not visible to the receiving party. 
> That receiving party when responding send it back and discloses its 
> positive filtering (retro-meta-spam). As such the proposed filtering 
> is a most efficient source of cultural, racial and religious 
> intelligence leaks. Together with the dissemination of RFC 3066 Bis 
> langtags, search engines queries using the proposed rules should be 
> efficient in terms of mass profiling. This risk should be documented 
> in Security Considerations.
> >

---

From: r&d afrac <[email-masked]>
Date: Sun, 19 Mar 2006 04:16:57 +0100

>>we have discussed when we actually worked on RFC 3066bis.

Then, I will appeal this. An US disregard for privacy laws may suit 
the Internationalised US Internet. It does not the Multilingual 
Internet, I think the IETF propositions should be kept interoperable 
with. If not, we will need to document non-US users that before 
warning them, as we will, we tried our best to protect them.
jfc

---

From: Martin Duerst <[email-masked]>
Date: Sun, 19 Mar 2006 18:24:09 +0900

At 12:16 06/03/19, r&d afrac wrote:
 >Then, I will appeal this.

Sorry, but there's no need to appeal WG/chair/IESG decisions for
RFC 3066bis (the registry draft) anymore. To some extent you have
already done so, for the rest, the appeals period is over.

Also, there is no need to appeal any decisions re. the matching draft,
because these haven't yet been made.

The only thing I was trying to say above is that if you think that
the security section of the matching draft needs to be changed, then
propose how to do it and explain why you think it is needed.
But leave RFC 3066bis out of the discussion; the WG has finished
its work on that document and is now concentrating on the matching
draft.

Regards,    Martin.

---

From: Martin Duerst <[email-masked]>
Date: Sun, 19 Mar 2006 18:53:07 +0900

[chair hat on]

 >- the lack of warning about the RFC 3066 Bis pattern, which is an RFC 
3066 Bis issue and will be documented as dangerous in a document we will 
publish. The risk there is against privacy..

For this issue, as far as it relates to RFC 3066bis, it is out of
discussion. As for "will be documented", issues should make proposals,
not try to guess the future. So I currently don't know what this issue
is about, and therefore am not able to add it to the issues list.

explains how langtags are filtered and which will be used in other 
standards. The added risks comes from the generalisation of this method. 
The risk is now mass profiling.

Assuming that "this document" means the matching draft, I have added
this issue to the issues list, as issue number 8.

If possible, please provide actual language that addesses this issue,
so that the WG has a better base for discussion.

I have noted issue 6 as 'split up'. Currently, issue 8 is the only
successor (result of the split) to issue 6, but this current state
does not preclude adding other issues as sucessors to issue 6, if
and when they are stated in a way that I as a chair am confident
enough I know what the issue is about.

Regards,    Martin.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 19 Mar 2006 19:38:39 +0100

On Sun, Mar 19, 2006 at 04:16:57AM +0100,
 r&d afrac <[email-masked]> wrote 
 a message of 22 lines which said:

> An US disregard for privacy laws may suit the Internationalised US
> Internet. It does not the Multilingual Internet, I think the IETF
> propositions should be kept interoperable with. If not, we will need
> to document non-US users that before warning them, as we will, we
> tried our best to protect them.

Just for the record, I want to emphasize that the <div
lang="no">troll</div> known as "r&d afrac" does *not* represent the
Internet users outside of the US. There are real privacy issues on the
Internet but it is certainly not a "us vs. then" issue (the european
governments agreed to transfer the airplane passenger data to the US,
including the meal choices which allow, unlike the language, to infer
the religion.)

The whole issue is a <div lang="la">non sequitur</div>. 

The language in 3066bis is perfect ("Language tags used in content
negotiation, like any other information exchanged on the Internet,
might be a source of concern because they might be used to infer the
nationality of the sender, and thus identify potential targets for
surveillance.") and I don't think the IETF could say more.