Hello Abe,
I think we agree on that it is hard for sender to "hide" the
identities in terms of IP.
And I am curious how we can step back a bit as you said. My concerns
focus on that if we want improve the privacy (even if one step
further), what direction could we head? I embrace any insight that can
enlighten me.
As for the event you mentioned about Apple, Apple is just another
trust point a lot of us trust. So back to the case that current
privacy are ultimately rely on trust point. Whether we could remove
the trust point is indeed a question for me.
Maybe Tor network provide an good example for the volunteer mode
rather than trust point.
Thanks,
Yihao
*From:* Abraham Y. Chen <ayc...@avinta.com>
*Sent:* 2022年1月12日 0:22
*To:* Jiayihao <jiayi...@huawei.com>
*Cc:* int-area@ietf.org; Tom Herbert <t...@herbertland.com>
*Subject:* Re: [Int-area] Where/How is the features innovation,
happening? Re: 202201111037.AYC
*Importance:* High
Hi, YiHao:
0) It appears to me that you are still applying your own technical
considerations around the subject. Doing so will perpetuate the
current stalemate. What I suggested was to step back a bit, in order
to visualize an overall picture of the logic and interactions among
the parties involved.
1) " ... I would say the current countermeasures are designed for
anyone except the LE because LE can force any part to disclose
specific data ... ": Then, make this an explicit statement as
the design criterion for the privacy measures, so that the LEs will
not have the excuses to do mass surveillance. Bragging there is no
back-door, or even refusing to support LE when requested, such as
Apple's position on a criminal case sometime ago as I heard, LEs will
get it done anyway by looking for "volunteers" from third-party
encryption crackers when their internal resources could not. Then, the
solution to the secret is out in the hacker community.
2) I learned a long time ago that a sophisticated lock is out there
for challenging a hacker to figure out a way to break into it. Way
back when, a chemist told me that even Epoxies had solvents. So, we
should not stretch our energy to cover too much aspects that some tend
to be counterproductive for the society as a whole, in the long run.
Regards,
Abe (2022-01-11 11:22)
On 2022-01-07 02:29, Jiayihao wrote:
Hello Abe,
Happy new year!
The postal system analogy is a good story to understand IP, but
not equal to the pessimistic conclusion you made. For the
conclusion part, I am fully agree with Tom’s arguments.
As you focus on IP(v4/v6) specifically, we more or less follow the
logic of How TCP/IP works. Within TCP/IP, privacy can be divided
into content encryption (A) and content delivery (B). A and B both
belong to user privacy. However, A and B are different things.
For A, Tom’s arguments is good enough. As for B, same as Tom’s but
one more thing to point. Since you care more about the LE, I would
say the current countermeasures are designed for anyone except the
LE because LE can force any part to disclose specific data that
should be uncovered under its design philosophy.
In short, in IP ecosystem, both A and B is still worth doing.
However, as I mentioned in my last mail, any design
philosophy/architecture has somehow implicit **trust party**. But
a LE could be All-powerful because the fundament of **trust
party** is break and no **trust party** anymore if you put LE into
consideration.
As you mentioned in your last email that there are conflicts
requirements, it happens all the time. RFC 8890 give the answer
and the direction IETF choose.
So back to the questions I am wondering: If we can upgrade the
architecture somehow, can we enhance the privacy by ways that more
than current countermeasures like RFC7721 can do?
Have an excellent 2022!
Best,
Yihao
*From:* Abraham Y. Chen <ayc...@avinta.com>
<mailto:ayc...@avinta.com>
*Sent:* 2022年1月1日 0:58
*To:* Tom Herbert <t...@herbertland.com> <mailto:t...@herbertland.com>
*Cc:* Jiayihao <jiayi...@huawei.com> <mailto:jiayi...@huawei.com>;
int-area@ietf.org
*Subject:* Re: [Int-area] Where/How is the features innovation,
happening? Re: 202112301817.AYC
*Importance:* High
Hi, Tom:
1) "Your argument seems to be that we shouldn't bother with things
like security or encryption at all :-) ... ": My apologies for
getting you to an unexpected conclusion. Perhaps I failed to make
an explicit statement because I thought that I was following a
thread about the IPv4 or IPv6 addresses "scrambling" schemes for
protecting the privacy of or increasing the security to users.
That is, we should look at this subject by the "Divide & Conquer"
concept. In other words, I was saying that encrypting the
"Content" part as much as the sender / receiver pair agrees to.
But, keep the "Address" part mostly clear. This way, the LE
parties will not have the excuse of performing "mass surveillance"
by scooping up everything, then take time to digest and
regurgitate the "Content" for hidden treasures. (Remember the
report that the German Chancellor's telephone calls were picked up
by spy agencies?) Rumors have been, that high performance computer
and large capacity storage device manufacturers are having a field
day supplying equipment to LE organizations such as NSA because
the current Internet trend.
2) Since my engineering training started from RF (Radio Frequency
or Wireless -- actually all bands from audio all the way to 60+
GHz), then telephony, and cellular phone before getting involved
with the Internet, allow me to briefly describe my understanding
of the characteristics of each with respect to our current
discussion. Hopefully, the below can thread different fields
together to clarify my point:
A. In the RF field, any signal that is transmitted (sent) into
the "ether" is a fair game for everyone. So, there is no "Address"
in the basic RF signal transmission. Most RF equipment does not
transmit its identification by itself unless the user does so as
part of the "Content" on purpose. For example, a commercial (AM,
FM, TV) station announces its station ID, or call-sign (Address)
as part of the broadcast (Content) according to FCC Rules. So, in
RF communication, we concentrate only on encrypting the "Content"
(such as scrambled / encode speech) for proprietary applications.
B. For traditional land-line telephony services, the caller's
phone number (Address) is fixed by wiring (nailed up) upon
subscription. Only the called party's phone number (Addressee) is
dialed once to tell the switching system who is the destination
party, so that the switches can make the connection. Once the
called party answers, the actual session consists of only
"Content" exchanges, no more "Address" information necessary.
Speech scramblers may be used on either end as a pair, for private
conversation (Content).
C. RF signals from cellular mobile phone do carry the handset
(and the cell tower) identifications (Addresses) on both ends
without the user's knowledge to facilitate establishing and
maintaining a connection, while the user constantly crosses the
boundaries between cells. Similarly, speech scramblers may be used
on either end as a pair for private conversation (Content). Note
that since VoIP is behind the scene these days, cellular mobile
service is supported by a mixture of both the traditional
telephony and the Internet infrastructures.
D. If we look at the Internet environment itself, it is kind
like the cellular mobile phone service. It is inherently wide open
like RF because packets are forwarded by unstructured mesh routers
allowing everyone to listen in. Yet, each IP packet header carries
the Addresses of both ends for directing routers to deliver the
packet, as well as for the return packet. So, how much can a
sender "hide" the identities of either or both ends for privacy
while still enables the routers to deliver the packet to its
intended destination effectively is a real challenge. Whatever the
scheme chosen, it can not be too sophisticated to over-burden the
routers which means that it is probably mot much a challenge for a
perpetrator intentionally trying to crack the scheme.
3) My sense from the above analysis is that attempting to make
the "Address" part of an IP packet "cryptic" for improving the
privacy / security properties of the "Content" is probably futile.
The more we attempt doing it, the stronger the LEs' argument for
mass surveillance, even though they probably already knew the
solution.
4) On the other hand, if we push too hard on strengthening the
encryption of the "Content" without a back door, we essentially
are helping the perpetrators. This is because if this part worked,
the LEs will not be able to monitor and catch the criminals!
5) So, we need to review the pros and cons of the end results,
before jumping into a scheme.
Happy New Year!
Abe (2021-12-31 11:57 EST)
On 2021-12-30 13:29, Tom Herbert wrote:
On Mon, Dec 27, 2021 at 7:00 PM Abraham Y. Chen
<ayc...@avinta.com> wrote:
Hi, YiHao:
0) Hope you had a Merry Christmas as well!
1) Re: Ur. Pts 1) & 2): Allow me to modify and
expand your definitions of the abbreviations, ICP & ISP, a
bit to streamline our discussion, then focusing on related
meanings of the two keyword prefixes, "C" and "A" in the
middle of them:
A. ICP (Internet Content Provider): This is the
same as you are using.
B. IAP (Internet Access Provider): This will
represent the ISP that you are referring to.
C. ISP (Internet Service Provider): This will be
used as the general expression that covers both ICP and
IAP above.
With these, I agree in general with your analysis.
2) From the above, there is a simpler (layman's instead
of engineer's) way to look at this riddle. Let's consider
the old fashioned postal service. A letter itself is the
"Content". The envelop has the "Address". The postal
service cares only what is on the envelop. In fact, it is
commonly practiced without explicitly identified that one
letter may have multiple layers of envelops that each is
opened by the "Addressee" who then forward the next
"Addressee" according to the "Address" on the inside
envelop, accordingly. To a larger scale, postal services
put envelops destined to the same city in one bag. Then,
bags destined to the same country in one container, etc.
This process is refined to multiple levels depending on
the volume of the mail and the facility (routes) available
for delivery. Then, the containers are opened
progressively along the destination route. No wonder that
the US Postal Service claimed (during the early days of
the Internet) that the mail system was the fist "packet
switching" system.
3) So, in this analogy, the "Address" on each and every
envelop has to be in the clear (not coded or encrypted in
any sense) for the mail handlers to work with. It is only
the most inner "Content", the letter itself, can have
Confidential information (or encrypted if the sender
wishes). Under this scenario, the LE (Law Enforcement) is
allowed only to track suspected mail by the "Addresses".
And, any specific surveillance is only authorized by
court, case by case. While no one can prevent LE bypassing
this procedure, cases built by violating this requirement
would be the ground for being thrown out of the court.
4) However, in the Internet environment, largely, if
not most, Addresses are dynamic. There is no way to
specify an IP Address for surveillance of a suspect. This
gives the LE the perfect excuse to scoop up everything and
then analyze offline. This gives them plenty of time to
try various ways to decrypt the encoded messages and the
opportunity to sift through everything for incidental
"surprise bonus finds". The result is that practically no
privacy is left for anyone. is means that all of the
schemes of scrambling IP Addresses are useless at the end.
So, why do we bother with doing so, at all?
Abe,
Happy New Year!
Your argument seems to be that we shouldn't bother with things
like security or encryption at all :-) While it's true that
anything sent into the Internet can be intercepted and
analyzed offline, it's clearly the intent of security and
privacy mechanisms to make offline analysis of data
ineffective or at least cost prohibitive. For encryption the
calculation is pretty straightforward, the complexity and cost
and breaking a cipher is generally correlated to the key size.
So for any given key size, it can be determined what sort of
resources are required to break the code. This is a continuous
escalation as attackers gain access for more computational
resources and there are breakthroughs like in quantum
computing that require rethinking encryption. But regardless,
the effectiveness of encryption at any given point of time is
quantifiable.
For security and privacy in IP addresses I believe we should
be similarly taking a quantitative approach. This is where
RFC7721 fails. The recommendation of RFC7721 is that for
better security, use temporary addresses with shorter
lifetimes. But the RFC doesn't attempt to quantify the
relationship between address lifetime and the security that's
offered or even say what specific lifetime is recommended for
optimal security. For instance, if the user changes their
interface address twice a day instead of once a day does that
halve the chances that some may breach their security by
correlating two different flows that they source from the
user? Probably not. But, what if they change their address
every five minutes? How much better is that than changing the
address once a day? It's intuitive that it should be better
security, but is it _really_ better? And if it is better, are
the benefits worth the aggravation of changing the address.
This is quite similar to some companies that have a policy
that everyone needs to change their passwords periodically.
Studies have shown that there is little quantitative value in
doing this and in fact the net effect is likely less security
and increased user aggravation-- even so, companies will
continue to do this because it's easier to stick with the
inertia of intuition.
The fix for the password problem is one time passwords (OTP)
and IMO that hints at the fix for the address security
problems described in RFC7712, essentially we need single use
source addresses per each connection. The security effects of
single use addresses are quantifiable, i.e. given sample
packets from independent two flows generated by the same user,
without additional information it isn't possible for a third
party to correlate that they are sourced by the same user.
Tom
Happy New Year!
Abe (2021-12-27 21:59)
On 2021-12-23 22:26, Jiayihao wrote:
Hello Abe,
Users are unwilling to be watched by any parties(ISP,
and ICP also) excepts users themselves. Actually I
would like to divide the arguments into 2 case:
network layers and below (not completely but mostly
controlled by ISP); transport layers and above (not
completely but mostly controlled by ICP).
1) For transport layers and above, Encryption
Everywhere (like TLS) is a good tool to provide user
privacy. However, it is only a tool against ISPs,
while ICPs survive and keep gaining revenue (even by
selling data like the negative news of Facebook, or
Meta, whatever you call it). As discussed, it is not
networks faults because IP provides peer-to-peer
already. You may blame CGNAT in ISP increasingly
contributes to a C/S mode in replacing P2P, like in
China where IPv4 addresses are scare and CGNAT is
almost everywhere. However, I don’t find the situation
any better in U.S. where most of IPv4 address are
located. It is a business choice to overwrite the mode
to be peer-ICP-peer(C/S mode) at application layer,
other than utilize the P2P mode that natively provided
by IP.
In this case, there are trust points and they are ICPs.
2) For network layers and below, ISP and IP still
provide a pure P2P network, and Encryption in TLS do
not blind ISP in IP layer since IP header is still in
plaintext and almost controlled by ISP. That is to
say, in an access network scenario, the access network
provide can see every trace of every user at network
layer level (although exclude the encrypted payload).
To against this, one can use Proxy(i.e., VPN, Tor) to
bypass the trace analysis just like the CGNAT does.
The only difference is that detour points (Proxies)
belong to a third party, not ISP.
In this case, there are trust points and they are
third party proxies.
The bottom line is that trust points are everywhere
explicitly or implicitly, and privacy can be leaked
from every (trust) point that you trust (or have
business with). No matter what network system you
have, no matter it is PSTN or ATM, these trust points
are just the weak points for your privacy, and the
only things users can beg is that **ALL** trust points
are 1) well behave/don’t be evil; 2)system is advanced
enough that can’t be hacked by any others; 3)
protected by law.
I would say pretty challenging and also expecting to
reach that.
Network itself just cannot be bypassed in reaching that.
Merry Christmas,
Yihao
*From:* Abraham Y. Chen <ayc...@avinta.com>
<mailto:ayc...@avinta.com>
*Sent:* 2021年12月23日 10:01
*To:* Jiayihao <jiayi...@huawei.com>
<mailto:jiayi...@huawei.com>
*Cc:* t...@herbertland.com; int-area@ietf.org
*Subject:* Re: [Int-area] Where/How is the features
innovation, happening? Re: 202112221726.AYC
*Importance:* High
Hi, YiHao:
0) I am glad that you distilled the complex and
elusive privacy / security tradeoff issues to a very
unique and concise perspective.
1) Yes, the IPv4 CG-NAT and IPv6 Temporary address
may seem to provide some privacy protection. However,
with the availability of the computing power, these
(and others such as VPN) approaches may be just
ostrich mentality. On the other hand, they provide
the perfect excuse for the government (at least US) to
justify for "mass surveillance". For example, the
following is a recent news report which practically
defeats all current "privacy protection" attempts.
https://www.usatoday.com/story/news/2021/12/08/federal-court-upholds-terrorism-conviction-mass-surveillance-case/6440325001/
<https://www.usatoday.com/story/news/2021/12/08/federal-court-upholds-terrorism-conviction-mass-surveillance-case/6440325001/>
*/[jiayihao] there is no doubt./*
2) Rather than contradicting efforts, it is time to
review whether any of these schemes such as mapping
techniques really is effective for the perceived
"protection". As much of the current science fiction
type crime scene detective novel / movie / TV program
hinted, the government probably has more capability to
zero-in on anyone than an ordinary citizen can
imagine, anyway. And, businesses have gathered more
information about us than they will ever admit.
Perhaps we should "think out of the box" by going back
to the PSTN days of definitive subscriber
identification systems, so that accordingly we will
behave appropriately on the Internet, and the
government will be allowed to only monitor suspected
criminals by filing explicit (although in secret)
requests, case by case, to the court for approval?
Happy Holidays!
Abe (2021-12-22 21:00 EST)
Hello Tom,
The privacy countermeasure for IPv4/IPv6 is interestingly
different.
IPv4 usually utilize CGNAT, i.e., M(hosts)-to-N(IPs), where M
>> N so that the host could remain anonymous
IPv6 usually utilize Temporary address, i.e., 1(host)-to-M(IPs[at
least suffix level]), where M >> 1 so that the host could remain anonymous.
HOWEVER, I don't feel any approach reaches privacy perfectly,
because access network have a global perspective on M-to-N or 1-to-M mapping.
For this, it is hard to be convinced that IPv4/6 itself can
reach a perfect privacy.
Thanks,
Yihao Jia
-----------
I believe CGNAT is better than IPv6 in terms of privacy in
addressing.
In fact one might argue that IPv4 provides better privacy and
security
than IPv6 in this regard. Temporary addresses are not single
use which
means the attacker can correlate addresses from a user between
unrelated flows during the quantum the temporary address is
used. When
a user changes their address, the attacker can continue
monitoring if
it is signaled that the address changed. Here is a fairly simple
exploit I derived to do that (from
draft-herbert-ipv6-prefix-address-privacy-00).
The exploit is:
o An attacker creates an "always connected" app that
provides some
seemingly benign service and users download the app.
o The app includes some sort of persistent identity. For
instance,
this could be an account login.
o The backend server for the app logs the identity and
IP address
of a user each time they connect
o When an address change happens, existing connections
on the user
device are disconnected. The app will receive a
notification and
immediately attempt to reconnect using the new source
address.
o The backend server will see the new connection and log
the new
IP address as being associated with the specific user.
Thus,
the server has
a real-time record of users and the IP address they
are using.
o The attacker intercepts packets at some point in the
Internet.
The addresses in the captured packets can be time
correlated
with the server database to deduce identities of
parties in
communications that are unrelated to the app.
The only way I see to mitigate this sort of surveillance is
single use
addresses. That is effectively what CGNAT can provide.
Tom
Image removed by sender.
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon>
Virus-free. www.avast.com
<https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link>
