Re: Review of draft-mm-wg-effect-encrypt-09

Kathleen Moriarty <> Thu, 13 April 2017 03:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 59DED126C26 for <>; Wed, 12 Apr 2017 20:02:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id E8yXRMzxUGit for <>; Wed, 12 Apr 2017 20:02:24 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:400e:c00::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BDD8412751F for <>; Wed, 12 Apr 2017 20:02:22 -0700 (PDT)
Received: by with SMTP id s16so22286178pfs.0 for <>; Wed, 12 Apr 2017 20:02:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=OvSIAHEL+AV4f/b5zG8kOUUhpXyu/fxZGPB5qMbX3I4=; b=SbMeYylXqtFM35VlADGKp2uz3feQibZO+GX74+McQodMO4nVrhTnkcwxUD1VBU7Tzf 4e22IYdWlYaqAXOA9FmpAOJztQT+4ZgxjfkdSMs+MCfS3A+bJ7kuiCAYSdvKqaGVH12f YZVQ/VD+ZvEuBxJsFD1T86IOqbF7RfLlqISobD5SDZ6E/1yMYvKoOiAYOJam1NAvKHvO L3zb30Zf7P3gcPM0Rf9qxC/zNIdgoNmcT5KMYUm0OO8u1vnMs/aE9ORjboPObdKBpAb5 ZEwhbl0qAXlNw8FljNHhTlhnDRMWStmVZBHCGpjv4qCw0GIg+tMv2zZPL4Zv15ylY5Gw 0HEg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=OvSIAHEL+AV4f/b5zG8kOUUhpXyu/fxZGPB5qMbX3I4=; b=WpdRsxFH2C3HErZEF1jsL+NrFK6fK7S1ykFh89ldvc8sOwwnLtmNvnXxVgzKXIcu9q /S2gYRLNfp28LDZxe+atyNqQ9HBzPYIuUwou1OyU5iUrolgGOp9mIRRDO1/AJfMakuFj k+YCjpmWVWVGUFrVbKm5fSThZJ+w8vcODfE2GEJxVHzBDudFw3pYF2c/mlg92BZj8XB2 JdJgL9zDgbhzJ23CjjHvmUPVG1Sz5yk1h6ZqAqUSzZ0f7ikFyo1Nv0FiWvRMlDECI6JA QqwqILHinIjkmbtbvs6lGrUIvVkFL96sN2L7TG5p+H135Az2BXMgaEq12shsjNEcAEOb 12ng==
X-Gm-Message-State: AN3rC/5BiecKH6m4Hd10jp2xb1nAWGQ9toI/JCeuDUcLcPEl75A20Udj p72aQWE36OY2Qh/ltl+DyOxpwHRJsxc3
X-Received: by with SMTP id l65mr942952pga.172.1492052542241; Wed, 12 Apr 2017 20:02:22 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Wed, 12 Apr 2017 20:01:41 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
From: Kathleen Moriarty <>
Date: Wed, 12 Apr 2017 23:01:41 -0400
Message-ID: <>
Subject: Re: Review of draft-mm-wg-effect-encrypt-09
To: =?UTF-8?Q?Mirja_K=C3=BChlewind?= <>
Cc: Martin Thomson <>, IETF <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 13 Apr 2017 03:02:26 -0000

Hi Mirja and Martin,

Responding inline with adjustments that were made to address the
technical comments and responses in this section of the review.  This
will show up in version 11.

On Wed, Apr 12, 2017 at 2:42 PM, Kathleen Moriarty
<> wrote:
> Mirja,
> Sorry for the top post.
> Thank you for responding on the outstanding items that were more
> technical in nature (QUIC and load balancing).  We'll integrate your
> suggested edits in the next revision.
> Kathleen
> On Wed, Apr 12, 2017 at 2:28 PM, Mirja Kühlewind
> <> wrote:
>> Hi Martin, hi Kathleen,
>> I would like to comment (for now) just on this one section, as my name was called out.
>>> Am 11.04.2017 um 05:54 schrieb Kathleen Moriarty <>om>:
>>>>> Section 2.1
>>>>> This is one of the few sections that talk about what it means to operate a
>>>>> service as opposed to operate a network.
>>>>> Overall, this section doesn't work particularly well.  The distinction
>>>>> between
>>>>> integrated and standalone load balancing is an interesting division, but
>>>>> it
>>>>> doesn't leverage this distinction well.  What causes a standalone
>>>>> load-balancer
>>>>> to be necessary?
>> My understanding is that the stand-alone load balancer was only brought up to better explain what an integrated load balancer is, assuming that the integrated (more complex) case is the common one.
>> However, to answer your question, for a stand-alone laod balancer it is assumed that you only have a small number of servers at one single location and you only need one box that does the load-balancing on these different servers. So all this box needs to know is the IP address of these servers.
>>>>> Is this something a network operator uses?  I see text
>>>>> on NFV
>>>>> later, but it's far removed from the original text and it seems
>>>>> aspirational
>>>>> rather than concrete.  On the other hand, many of the concerns in this
>>>>> document
>>>>> simply don't apply to an integrated load balancer.
>> To my understanding all the concerns apply to integrated load balancers. Integrated only means that the load balancer shares some information with the server and based on this knowledge the load balancer can identify based on some information in the packets which server this packet should be forwarded to.
>>>>> The amount of text on QUIC here is surprising.  Given how much of QUIC is
>>>>> changing right now, we shouldn't publish a document that attempts to make
>>>>> claims
>>>>> about what QUIC is or how it is operated.  This attempts to dive into the
>>>>> details of QUIC connection migration in a way that presumes much about the
>>>>> outcome of issues that the QUIC working group is still struggling with.
>>>>> I would strongly recommend removing QUIC-specific language from this
>>>>> section and
>>>>> the document as a whole.  We have an operational document in the QUIC
>>>>> working
>>>>> group that would be a good venue to discuss some of these concerns.
>>> While we read this as  more of a substantive remark, the text on
>>> load balancers and QUIC were added per Mirja's IESG review.  We would
>>> need to check with her about making any changes here.  They were
>>> specific additions that were requested.
>>> Further, it is only IETF QUIC that is in active development.
>>> Google QUIC (referred to as GQUIC in IETF discussions) is a more
>>> stable experiment now.
>> I fully agree to remove the quic specific language. It’s definitely too early to say something in this document (and GQUIC is probably not documented well enough to rely on this). This text wasn’t provided by me but I recommended a contributor for this text who is also active in the quic wg and missed this when he send the text.
>> I recommend to simply remove the following sentences:
>> "QUIC is an example of such
>>    protocol in development by IETF QUIC WG right now.“
>> "New connection-migration-tolerant protocols, such as QUIC, are
>>    deliberately designed to allow such extra information available in
>>    plain text (QUIC's server-generated flow IDs).“

These sentences have been removed.  Thanks for your guidance on these questions.

>>>>> Is this an oblique reference to (the much-loved) RFC 7974?
>> No, not at all. There are other ways middleboxes can add information. But in this case actually the server would add information because the load balancers and the server share some knowledge.
>>>>>   Current protocols, such as TCP, allow the development of stateless
>>>>> integrated
>>>>>   load balancers by availing such load balancers of additional plain text
>>>>>   information in client-to-server packets.
>>>>> Otherwise, I don't know what it means.
>> A server could select a certain sequence number (range), or TCP timestamp, I guess...
>>>>> BTW, I like this parenthetical:
>>>>>   (That said, care must be exercised to make sure that the information
>>>>> encoded
>>>>>   by the endpoints is not sufficient to identify unique flows and
>>>>> facilitate
>>>>>   Persistent Surveillance attack vector.)
>>>>> I'm going to take this to the QUIC working group, because QUIC certainly
>>>>> doesn't
>>>>> meet that bar right now.  It fully facilitates Persistent Surveillance in
>>>>> its
>>>>> current form (proper noun?  I haven't really seen that term before, even
>>>>> though
>>>>> it draws a neat parallel with Pervasive Surveillance).
>>> OK, let us know what you hear back.  These changes were in response to
>>> the sponsoring AD's request of that work.
>> I think this sentence should be removed in this document and a reference to RFC 7258 should be added, instead of coming up with new terminology here that sets the bar higher that what was agreed in RFC 7258.

Thanks, Mirja.  Deborah suggested some new text for the abstract and
introduction that hits on this same point as well.  It should assist
with some of Martin's tone comments.  As for this specific suggestion,
we deleted the text as advised and added the following per your

       As noted in Section 2 of RFC7258, careful consideration
        in protocol design to mitigate PM is important, while ensuring
        manageability of the network.
>>>>> Editorial:
>>>>> * "pop" is a term of art that needs explanation.
>>>>> * "QUIC?s", "network?s" - avoid smart quotes, and - more generally - the
>>>>>  possessive form for the inanimate.
>>>>> * "QUIC's server-generated flow IDs" -> "QUIC's connection IDs".
>>> Thanks for the nit corrections.
>> Thanks!
>> I will further comment later!
>> Mirja
> --
> Best regards,
> Kathleen

Your assistance is much appreciated.


Best regards,