Dear Yuhong, My personal opinion in the "arms race" (your phrasing, not mine), no AD hat on (as that one is to support the WG decision), is that it will continue until we really hear each other out and think more on the problems the other side is trying to solve. Perhaps there are ways to meet all or at least some of the goals in other ways. If we don't work together to understand the challenges, we'll never make progress and remain in this arms race. I also think that if you push on e2e in protocol design without listening to the other side, protocols may not enjoy the deployment percentages that you'd like to see, adoption could be hindered. Many of the operators have expressed that they would like to see e2e and are fully supportive of privacy goals, but are trying to figure out other ways to accomplish tasks. Logging from applications has been found to be lacking by many operators, if this could be improved on the application side, then a shift to use end point monitoring becomes more practical. From the draft I have been working on (toward the goal of increasing adoption of e2e protocols), "The Effect of Pervasive Encryption on Operators", the following logging types have been called out as being deficient: Service providers typically use only headers at layers 2,3, and 4 "packet tracing and inspection along the service path provides operators the visibility to continue to diagnose problems reported both internally and by their customers. Logging of service path upon exit for routing overlay protocols will assist with policy management and troubleshooting capabilities for traffic flows on encrypted networks. Protocol trace logging and protocol data unit (PDU) logging should also be considered to improve visibility to monitor and troubleshoot application level traffic." Within the enterprise (where they already own all the data), logging at a more granular level for application debugging will assist with a transition to rely more on end points for diagnostics. Interactions between applications an databases has been called out as an issue that could be improved with enhanced logs on transactions, queries, etc. Fraud detection does rely on transaction monitoring already, but banks are using network based tools as well for this and other incident detection (data exfiltration, etc.). In this case, pattern detection is really helpful and that might include variances in sizes of packets, destinations, times of transactions, types of data accessed (by who, when), etc. Some of this can still be done on the network with encrypted traffic streams. I personally think e2e would get further ahead in the arms race if they spent time working to solve these other issues with operators so that monitoring could move to the end point or closer to it. Yoav has said it on list before, vendors of middleboxes often update quickly. My interpretation of that is continuing to alter the protocol to break middleboxes won't work as a strategy to disrupt many middleboxes. Solving customer problems will have a much greater impact toward improving deployment in my personal opinion. Much of this debate is about control anyway - application vs. network - and not about privacy. Many operators also support the goal of privacy for end users. Best regards, Kathleen On Mon, Feb 19, 2018 at 10:58 AM, Kathleen Moriarty <kathleen.moriarty.ietf@xxxxxxxxx> wrote: > Dear Yuhong, > > As the sponsoring Area Director, my job is to take the draft forward > as was determined by working group consensus. Like Stephen, I'm also > not particularly happy about the choice to leave in 0-RTT, but I have > to support it as a WG decision. Whatever the version number in the > ServerHello decision is from the WG, I will support that decision. > The ServerHello decision doesn't really fall into the, "arms race" as > you put it. More on that in another thread. > > Best regards, > Kathleen > > On Thu, Feb 15, 2018 at 9:04 PM, Yuhong Bao <yuhongbao_386@xxxxxxxxxxx> wrote: >> I wonder what is IESG's opinion on the TLS arms race with middleboxes. >> Yes, I am talking about moving the version number in the ServerHello. >> >> ________________________________________ >> From: TLS <tls-bounces@xxxxxxxx> on behalf of The IESG <iesg-secretary@xxxxxxxx> >> Sent: Thursday, February 15, 2018 1:13:48 PM >> To: IETF-Announce >> Cc: draft-ietf-tls-tls13@xxxxxxxx; tls-chairs@xxxxxxxx; tls@xxxxxxxx >> Subject: [TLS] Last Call: <draft-ietf-tls-tls13-24.txt> (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard >> >> >> The IESG has received a request from the Transport Layer Security WG (tls) to >> consider the following document: - 'The Transport Layer Security (TLS) >> Protocol Version 1.3' >> <draft-ietf-tls-tls13-24.txt> as Proposed Standard >> >> The IESG plans to make a decision in the next few weeks, and solicits final >> comments on this action. Please send substantive comments to the >> ietf@xxxxxxxx mailing lists by 2018-03-01. Exceptionally, comments may be >> sent to iesg@xxxxxxxx instead. In either case, please retain the beginning of >> the Subject line to allow automated sorting. >> >> Abstract >> >> >> This document specifies version 1.3 of the Transport Layer Security >> (TLS) protocol. TLS allows client/server applications to communicate >> over the Internet in a way that is designed to prevent eavesdropping, >> tampering, and message forgery. >> >> >> >> >> The file can be obtained via >> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ >> >> IESG discussion can be tracked via >> https://datatracker.ietf.org/doc/draft-ietf-tls-tls13/ballot/ >> >> The following IPR Declarations may be related to this I-D: >> >> https://datatracker.ietf.org/ipr/2900/ >> >> >> >> The document contains these normative downward references. >> See RFC 3967 for additional information: >> rfc8017: PKCS #1: RSA Cryptography Specifications Version 2.2 (Informational - IETF stream) >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/tls >> >> _______________________________________________ >> TLS mailing list >> TLS@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/tls > > > > -- > > Best regards, > Kathleen -- Best regards, Kathleen
