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

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

Hi, YiHao:

0)    The issue in front of us is more than skin deep. You need to look 
at it from the very basics. Otherwise, as you stated, you will be stuck. 
In contemporary marketing / business jargon, you may call what I am 
recommending as "thinking out of the box".

1)    That is, do not follow and dig deeper into what the Internet has 
been and is currently doing. Instead, ask the simple question that if 
there is an opportunity to get a fresh start for the Internet, whether 
there is a way to deploy and administer its addressing system that can 
mimic the PSTN?

Regards,


Abe (2022-02-07 18:7ST)



On 2022-02-07 04:54, Jiayihao wrote:
>
> Thanks for sharing.
>
> > 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?
>
> I feel that I'm stuck with this.
>
> If a system do not provide any authentication, then a third party is 
> needed to help authentication (Like Web PKI). If a system do provide 
> authentication, like Apple iMessage, then the trust anchor is already 
> there (Apple Inc.).
>
> In the IP layer, IP packets come to a receiver without any 
> authentication. IPsec is a (patch-like) solution example with a third 
> party for helping the authentication.
>
> For this, I am stuck with that how to architecturally improve the 
> privacy/security of IP layer other than the above methodologies, and I 
> am keep thinking the lessons we can get from Caller-ID.
>
> Thanks,
>
> Yihao
>
> *From:* Abraham Y. Chen <[e-mail]>
> *Sent:* 2022年1月25日 20:30
> *To:* Jiayihao <[e-mail]>
> *Cc:* [e-mail]; Tom Herbert <[e-mail]>
> *Subject:* Re: [Int-area] Where/How is the features innovation, 
> happening? Re: 202201250721.AYC
> *Importance:* High
>
> 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]>
>     <mailto:[e-mail]>
>     *Sent:* 2022年1月25日 3:31
>     *To:* Jiayihao <[e-mail]> <mailto:[e-mail]>
>     *Cc:* [e-mail]; Tom Herbert <[e-mail]>
>     <mailto:[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