[TLS] Middlebox "arms race" WAS: Re: Last Call: <draft-ietf-tls-tls13-24.txt> (The Transport Layer Security (TLS) Protocol Version 1.3) to Proposed Standard

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@gmail.com> 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@hotmail.com> 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@ietf.org> on behalf of The IESG <iesg-secretary@ietf.org>
>> Sent: Thursday, February 15, 2018 1:13:48 PM
>> To: IETF-Announce
>> Cc: draft-ietf-tls-tls13@ietf.org; tls-chairs@ietf.org; tls@ietf.org
>> 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@ietf.org mailing lists by 2018-03-01. Exceptionally, comments may be
>> sent to iesg@ietf.org 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@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>>
>> _______________________________________________
>> TLS mailing list
>> TLS@ietf.org
>> https://www.ietf.org/mailman/listinfo/tls
>
>
>
> --
>
> Best regards,
> Kathleen

-- 

Best regards,
Kathleen