On Tue, Jul 03, 2018 at 11:08:21AM -0600, Bret Jordan wrote: > From a discussion on the PATIENT list found here: > https://www.ietf.org/mail-archive/web/patient/current/msg00078.html > <https://www.ietf.org/mail-archive/web/patient/current/msg00078.html> > > > From my personal perspective, we need to be careful with all of these > efforts. It feels like the pendulum has swung so far to one side, the side of > privacy-at-any-cost, that we are unknowingly increasing the risk to > individuals and organizations by enabling threat actors and intrusions sets > to attack networks and clients without any level of protection from the > network.
BCP 61 leads us to not expect any protection from the network, does it not? > It also feels like a lot of these initiatives are being done without > adequately involving and ensuring that enterprise networks and critical > infrastructure can work with these changes. Question, do we know how these > ideas and changes are going to impact an organizations ability to fulfill > their requirements for regulatory compliance? > > If we continue down these paths, then I fear networks will be required to > wrap all traffic in some other less secure protocol, outright deny some of > these protocols, or be forced to fully proxy all traffic or take an approach > that Google has done with their BeyondCorp design. I suspect you will find that many proponents of the proposals you find worrisome would also be enthusiastic proponents of "an approach similar to what Google has done with BeyondCorp". Such a discussion would be off-topic for the TLS list, but you would probably be well-served to have some supporting text for why this sort of approach should be considered bad, if you want to gain sympathy for your perspective. -Ben > The IETF work needs to do more outreach with enterprise networks and critical > infrastructure and be fundamentally more inclusive. Privacy-at-any-cost is > not a holistic design. > > Thanks, > Bret > PGP Fingerprint: 63B4 FC53 680A 6B7D 1447 F2C0 74F8 ACAE 7415 0050 > "Without cryptography vihv vivc ce xhrnrw, however, the only thing that can > not be unscrambled is an egg." > > > > ### Copied content from the PATIENT discussion #### > > > On Tue, Jul 3, 2018 at 8:09 AM, Kathleen Moriarty <kathleen.moriarty.ietf at > gmail.com <mailto:kathleen.moriarty.ietf%20at%20gmail.com>> wrote: > On Sun, Mar 18, 2018 at 9:06 AM, Eric Rescorla <ekr at rtfm.com > <mailto:ekr%20at%20rtfm.com>> wrote: > > > > > > On Sun, Mar 18, 2018 at 12:54 PM, Tony Rutkowski <tony at yaanatech.co..uk> > > wrote: > >> > >> Your point is one that deserves further discussion, Eric - which seems > >> likely to scale rapidly going forward. It is key. > >> > >> So how does draft-ietf-tls-sni-encryption it into the argument? > > > > > > As you suggest, SNI encryption is intended to conceal the SNI, which of > > course would make SNI inspection difficult. > > > > My evaluation of the current state of SNI encryption is that given the > > current technical state, it will not see particularly wide deployment, with > > the primary scenario being "at-risk" sites who are subject to censorship who > > either hide behind or co-tenant with sites which are not subject to > > censorship. That probably isn't going to be incredibly common right now. Of > > course, this is regrettable from the perspective of people designing these > > protocols, but I think that's the situation. > > EKR posted a draft to encrypt SNI, see: > https://www.ietf.org/mail-archive/web/tls/current/msg26468.html > <https://www.ietf.org/mail-archive/web/tls/current/msg26468.html> > > It targets the CDNs who host most of the web traffic in the US at > least. The right place to comment on this would be the TLS list of > course, but since proposals are being posted, this is a reality and > needs to be discussed. Those using SNI need to make sure their use > cases are clear and understood and argue the pros and cons. > > Kathleen, > > Thanks for pointing out this draft. > > As they say, predictions are hard, especially about the future. In March, the > ESNI problem looked pretty intractable and then subsequently we had this idea > about why it might be workable. > > -Ekr > > Best regards, > Kathleen > > > > > -Ekr > > > >> On 18-Mar-18 8:45 AM, Eric Rescorla wrote: > >> > >> On Sun, Mar 18, 2018 at 12:30 PM, Tony Rutkowski <tony at yaanatech.co.uk > >> <mailto:tony%20at%20yaanatech.co.uk>> > >> wrote: > >>> > >>> Hi Diego, > >>> > >>> It is also worth referencing a relatively recent Lawfare article on the > >>> scaling litigation in the U.S. against those supporting e2e encryption > >>> services or capabilities. > >>> > >>> https://www.lawfareblog.com/did-congress-immunize-twitter-against-lawsuits-supporting-isis > >>> > >>> <https://www.lawfareblog.com/did-congress-immunize-twitter-against-lawsuits-supporting-isis> > >>> > >>> This litigation trend is also likely to increase the insurance costs of > >>> providers. Indeed, a provider that supports TLS1.3, QUIC, SNI, etc, may > >>> not > >>> even be able to get insurance. It may be fun and games to play crypto > >>> rebel > >>> in venues like the IETF where the risk exposure is minimal, but when it > >>> comes to real world consequences and costs, the equations for providers > >>> are > >>> rather different. > >> > >> > >> I think this rather overestimates the degree to which both TLS 1.3 and > >> QUIC change the equation about what a provider is able to determine from > >> traffic inspection. As a practical matter, the primary change from TLS 1.2 > >> is that the provider does not get to see the server's certificate, but it > >> does see the SNI. Given that the SNI contains the identity of the server > >> that the client is connected to and that the other identities in the > >> certificate are often whatever the provider decided to co-locate on the > >> same > >> machine, I'm not sure how much information you are really losing. > >> > >> -Ekr > >> > >>> > >>> > >>> > >>> --tony > >>> > >>> > >>> _______________________________________________ > >>> PATIENT mailing list > >>> PATIENT at ietf.org <mailto:PATIENT%20at%20ietf.org> > >>> https://www.ietf.org/mailman/listinfo/patient > >>> <https://www.ietf.org/mailman/listinfo/patient> > >> > >> > >> > >> > >> _______________________________________________ > >> PATIENT mailing list > >> PATIENT at ietf.org <mailto:PATIENT%20at%20ietf.org> > >> https://www.ietf.org/mailman/listinfo/patient > >> <https://www.ietf.org/mailman/listinfo/patient> > >> > >> > > > > > > _______________________________________________ > > PATIENT mailing list > > PATIENT at ietf.org <mailto:PATIENT%20at%20ietf.org> > > https://www.ietf.org/mailman/listinfo/patient > > <https://www.ietf.org/mailman/listinfo/patient> > > > > > > -- > > Best regards, > Kathleen > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
