Hello Abe,
0) Really appreciate sharing the story of Call-ID. It is really a
fresh term and tech to me, and seems I haven’t got a chance to
experience the Call-ID time. Really good to learn.
1) Based on my rough understanding of Call-ID, it is a classical
example of how we choice to name an object. Assuming we want to visit
the Apple Campus (the Headquarters of Apple Inc.) with our Google map,
we can type a) Apple Campus (Name); b) 1 Infinite Loop, Cupertino, CA
95014 (Locator 1); c) 37.33182°N 122.03118°W(Locator 2). The only
difference is which one people would like to use, or which one is more
friendly to human in their practice. My understanding is that people
prefer Name while computer prefer Locator, so usually a system would
like to provide the Name to users and build a subordinate Mapping
system as while to corelate the name and the locator. DNS is just a
good example we use every day.
2) Agree on your insight that authentication to just Call-ID(phone
number) do not make much sense because it only provide the
authentication of Locator, while leave the Name, which users are more
willing to perceive, unauthenticated. I find that IETF STIR wg is
working on this topic. Although I am not familiar right now, I feel a
PKI/Certificate should be involved in order to gain practical value.
3) In a peer to peer context, IMHO, the Name based interface is more
practically valuable compared to Locator based one, just like the name
instead of phone number in the Call-ID case because the numbers do not
offer any meaning even it is authenticated.
4) Agree on “….that we must have a "system view"….” and “…Some are not
based on technology, but business practices or just mentality….”. But
I feel there is no Silver Bullet and I don’t have an answer yet. It is
really enjoyable to discuss and I will keep thinking on this.
Many thanks, Abe,
Yihao
*From:* Abraham Y. Chen <ayc...@avinta.com>
*Sent:* 2022年1月17日 1:21
*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: 202201152233.AYC
*Importance:* High
Hi, YiHao:
1) "... I am curious how we can step back a bit as you said. ...
current privacy are ultimately rely on trust point. ...": I have
already outlined (perhaps hinted) what is needed to deal with this
issue. That is, we have to look at the overall environment, not just
keep digging deeper into the technology itself. No matter how great
the technology is, there are always ways to get around or to defeat
it. Some are not based on technology, but business practices or just
mentality. In the case of the APPLE refusing to support LE, it was the
combination of business decision (The LE decided to do it by
themselves and to look for help from "volunteers") and the technical
challenge (viewed by "hackers" as fun with reward) that bypassed the
"trust point".
2) To demonstrate my point, I would like to share a brief history
of a related topic, although based on an opposite initial intention,
for you to compare and to figure out how to deal with the incident
privacy / security goal. It was a service started with great results,
but deteriorated by various business considerations and other
influences to a point of nearly useless. The service was called
Caller-ID. When it was first introduced to identify the caller for the
convenience of the called party, it also put a big dent on
telemarketers. That was because the capability was based on a facility
inherent in the telephone system that no outsiders could touch. With
the breakup of the Bell System, the Baby-Bells (There were seven to
start with. They have gone through the M&A processes to become one
AT&T again!) started to compete against one another. Some marketing
genius invented the idea of offering (of course with compensation in
return) big subscribers to customize their Caller-ID messages for
various purposes, such as announcing sales. -- Note: Thanks to digital
technology, the telephone switching equipment used by big business
(called PABX) had become just as powerful as those used by local
telcos (COs - Central Offices) where Caller-ID information originated.
This allowed telemarketers (pretty big operations) to masquerade
behind any phone number desired, such as using the same local exchange
prefix number as that of the target subscribers to pretend being a
neighbor. Still, a called could pick out welcomed callers by paying
some attention to the message displayed. After VoIP became widely
used, rather than mimicking the practice employed by cellular phone
industry, making sense out of the VoIP based phone numbers became
mind-boggling for practically everyone. No wonder that Robocalls
became much prevalent than the past telemarketer calls.
https://en.wikipedia.org/wiki/Caller_ID#History
3) With the FCC's Authentication program, the Robocalls may be
tempered for awhile. But, the caller name has been dropped out of the
Caller-ID message, because the carriers now treat such as their own
valuable merchandise that the called party has to pay to receive it
(Try figuring out how to identify such relationships and then to
establish agreements?) An incoming call now may have a "[V]" prefix
indicating it has passed the "Stir/Shaken" Verification process,
followed by only a caller phone number without name which becomes
pretty much the same challenge for most people to begin with. So, the
Caller-ID service has pretty much lost its original intended main
purpose.
https://www.fcc.gov/call-authentication
4) In brief, Caller-ID was designed under an environment of
uniformly structured system (the PSTN). Even so, it quickly degraded
to a service with minimal residual value when system fragmentation,
diverse marketing incentives, narrow-mindedness (individual's
"freedom"?), etc. came into play. With distributed network
architecture and operation philosophy as the foundation, I will
venture to say that the Internet would have a hard time to just mimic
the identification of the "well-behaved" subscribers like the original
Caller-ID service, let alone hiding their identity and providing
security. What I am saying is that we must have a "system view" of all
parameters involved in an issue, before we could define what we can do
and which we want to do. Then, the chosen technology may have a chance
to deliver the expected goal. Otherwise, we will be just spinning the
wheels on partial solutions from the diverse individualized perspectives.
Regards,
Abe (2022-01-16 12:20 EST)
On 2022-01-13 01:33, Jiayihao wrote:
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>
<mailto:ayc...@avinta.com>
*Sent:* 2022年1月12日 0:22
*To:* Jiayihao <jiayi...@huawei.com> <mailto:jiayi...@huawei.com>
*Cc:* int-area@ietf.org; Tom Herbert <t...@herbertland.com>
<mailto: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>
