Re: [Int-area] Where/How is the features innovation, happening? Re: 202201250721.AYC

["Abraham Y. Chen" <[e-mail]>]

Hi, YiHao:

0)    Re: Ur. Pt. 0): Correct. However, the Caller-ID terminology was 
introduced when the caller's name was displayed on Called's phone. So, 
when only b) is shown, it is at best a subset, or the minor part, of the 
Caller-ID service.

1)    Re: Ur. Pt. 1): Why do you need a way to certify / authenticate a 
caller if a system is set up with explicit originator identification in 
the first place?

Regards,


Abe (2022-01-25 07:29)


On 2022-01-24 22:42, Jiayihao wrote:
>
> Hello Abe,
>
> 0) Sorry I get it confused and assume that the a) Caller-ID and b) 
> “incoming caller number” are different things. If b) is part of a), I 
> get it wrong. I currently living in China, and my carrier always bring 
> the b) “incoming caller number” each time I get a call, so probably 
> still a modern life style : )
>
> 1) "... PKI/Certificate ..." is a patch-style tech and it works quite 
> well, ant it is true things are different if we built a system from 
> scratch. But is there anything you mean behind it that preform equally 
> or better compare to " ...  PKI/Certificate ...   " (in the context of 
> Caller-ID or others)?
>
> Thanks,
>
> Yihao
>
> *From:* Abraham Y. Chen <[e-mail]>
> *Sent:* 2022年1月25日 3:31
> *To:* Jiayihao <[e-mail]>
> *Cc:* [e-mail]; Tom Herbert <[e-mail]>
> *Subject:* 202201241417.AYC Re: [Int-area] Where/How is the features 
> innovation, happening? Re: 202201152233.AYC
> *Importance:* High
>
> Hi, YiHao:
>
> 1)    Re: Ur. Pt. 0):    I am getting curious. May I ask where are you 
> and how old are you? May be not landline. But, cellular mobile phone 
> services always have at least the numerical part of the Caller-ID 
> function, due to concerns such as who is going to pay for the air-time.
>
> 2)    Re: Ur. Pts. 1) & 3):    Good analysis. As to DNS, it is an 
> unnecessary "reverse" effort relative to the white-book practice in 
> the PSTN field.
>
> 3)    Re: Ur. Pts. 2) & 4):    " ...  PKI/Certificate ... ":    I do 
> not believe this is necessary if we review the subject from the ground up.
>
> Regards,
>
> Abe (2022-01-24 14:30 EST)
>
> On 2022-01-23 22:11, Jiayihao wrote:
>
>     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 <[e-mail]>
>     <mailto:[e-mail]>
>     *Sent:* 2022年1月17日 1:21
>     *To:* Jiayihao <[e-mail]> <mailto:[e-mail]>
>     *Cc:* [e-mail]; Tom Herbert <[e-mail]>
>     <mailto:[e-mail]>
>     *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 <[e-mail]>
>         <mailto:[e-mail]>
>         *Sent:* 2022年1月12日 0:22
>         *To:* Jiayihao <[e-mail]> <mailto:[e-mail]>
>         *Cc:* [e-mail]; Tom Herbert <[e-mail]>
>         <mailto:[e-mail]>
>         *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 <[e-mail]>
>             <mailto:[e-mail]>
>             *Sent:* 2022年1月1日 0:58
>             *To:* Tom Herbert <[e-mail]>
>             <mailto:[e-mail]>
>             *Cc:* Jiayihao <[e-mail]>
>             <mailto:[e-mail]>; [e-mail]
>             *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
>                 <[e-mail]> 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 <[e-mail]>
>                         <mailto:[e-mail]>
>                         *Sent:* 2021年12月23日10:01
>                         *To:* Jiayihao <[e-mail]>
>                         <mailto:[e-mail]>
>                         *Cc:* [e-mail]; [e-mail]
>                         *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>
>


-- 
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus