To: Jana Iyengar <jri.ietf@gmail.com>
Cc: "Deval, Manasi" <manasi.deval@intel.com>,
 Marten Seemann <martenseemann@gmail.com>, Ian Swett <ianswett@google.com>,
 IETF QUIC WG <quic@ietf.org>, Martin Thomson <martin.thomson@gmail.com>,
 Dmitri Tikhonov <dtikhonov@litespeedtech.com>
References: <CAOYVs2q63DpkPZTbw9T24ZcFOxbvrWAGvOtUaHvCuSg_13pSkQ@mail.gmail.com>
 <CABkgnnWpgyN_OPac-uSKALEaVc8mO_LpT9gAOs-n1eKqso5QAQ@mail.gmail.com>
 <CAKcm_gMFumNgPq4FxwcgzgDUCvn_jUxb0qk7tAgYZ=LvKfxjfg@mail.gmail.com>
 <20180518134400.GA12617@ubuntu-dmitri>
 <1F436ED13A22A246A59CA374CBC543998B7C712F@ORSMSX111.amr.corp.intel.com>
 <CACpbDcdb6JK_-fmUcKMgbdm0iD2qFvQSVbM74uzo28aShb7H2w@mail.gmail.com>
 <6c99fb18-f511-7246-e248-466400675e62@huitema.net>
 <CACpbDcfjDfQP69ZvUNjcUnQBGYKJAEJuh2BMK5dQZ8eRwfzOGQ@mail.gmail.com>
From: Christian Huitema <huitema@huitema.net>
Openpgp: preference=signencrypt
Autocrypt: addr=huitema@huitema.net; prefer-encrypt=mutual; keydata=
 xsBNBFIRX8gBCAC26usy/Ya38IqaLBSu33vKD6hP5Yw390XsWLaAZTeQR64OJEkoOdXpvcOS
 HWfMIlD5s5+oHfLe8jjmErFAXYJ8yytPj1fD2OdSKAe1TccUBiOXT8wdVxSr5d0alExVv/LO
 I/vA2aU1TwOkVHKSapD7j8/HZBrqIWRrXUSj2f5n9tY2nJzG9KRzSG0giaJWBfUFiGb4lvsy
 IaCaIU0YpfkDDk6PtK5YYzuCeF0B+O7N9LhDu/foUUc4MNq4K3EKDPb2FL1Hrv0XHpkXeMRZ
 olpH8SUFUJbmi+zYRuUgcXgMZRmZFL1tu6z9h6gY4/KPyF9aYot6zG28Qk/BFQRtj7V1ABEB
 AAHNJ0NocmlzdGlhbiBIdWl0ZW1hIDxodWl0ZW1hQGh1aXRlbWEubmV0PsLAeQQTAQIAIwUC
 UhFfyAIbLwcLCQgHAwIBBhUIAgkKCwQWAgMBAh4BAheAAAoJEJNDCbJVyA1yhbYH/1ud6x6m
 VqGIp0JcZUfSQO8w+TjugqxCyGNn+w/6Qb5O/xENxNQ4HaMQ5uSRK9n8WKKDDRSzwZ4syKKf
 wbkfj05vgFxrjCynVbm1zs2X2aGXh+PxPL/WHUaxzEP7KjYbLtCUZDRzOOrm+0LMktngT/k3
 6+EZoLEM52hwwpIAzJoscyEz7QfqMOZtFm6xQnlvDQeIrHx0KUvwo/vgDLK3SuruG1CSHcR0
 D24kEEUa044AIUKBS3b0b8AR7f6mP2NcnLpdsibtpabi9BzqAidcY/EjTaoea46HXALk/eJd
 6OLkLE6UQe1PPzQC4jB7rErX2BxnSkHDw50xMgLRcl5/b1bOwE0EUhFfyAEIAKp7Cp8lqKTV
 CC9QiAf6QTIjW+lie5J44Ad++0k8gRgANZVWubQuCQ71gxDWLtxYfFkEXjG4TXV/MUtnOliG
 5rc2E+ih6Dg61Y5PQakm9OwPIsOx+2R+iSW325ngln2UQrVPgloO83QiUoi7mBJPbcHlxkhZ
 bd3+EjFxSLIQogt29sTcg2oSh4oljUpz5niTt69IOfZx21kf29NfDE+Iw56gfrxI2ywZbu5o
 G+d0ZSp0lsovygpk4jK04fDTq0vxjEU5HjPcsXC4CSZdq5E2DrF4nOh1UHkHzeaXdYR2Bn1Y
 wTePfaHBFlvQzI+Li/Q6AD/uxbTM0vIcsUxrv3MNHCUAEQEAAcLBfgQYAQIACQUCUhFfyAIb
 LgEpCRCTQwmyVcgNcsBdIAQZAQIABgUCUhFfyAAKCRC22tOSFDh1UOlBB/94RsCJepNvmi/c
 YiNmMnm0mKb6vjv43OsHkqrrCqJSfo95KHyl5Up4JEp8tiJMyYT2mp4IsirZHxz/5lqkw9Az
 tcGAF3GlFsj++xTyD07DXlNeddwTKlqPRi/b8sppjtWur6Pm+wnAHp0mQ7GidhxHccFCl65w
 uT7S/ocb1MjrTgnAMiz+x87d48n1UJ7yIdI41Wpg2XFZiA9xPBiDuuoPwFj14/nK0elV5Dvq
 4/HVgfurb4+fd74PV/CC/dmd7hg0ZRlgnB5rFUcFO7ywb7/TvICIIaLWcI42OJDSZjZ/MAzz
 BeXm263lHh+kFxkh2LxEHnQGHCHGpTYyi4Z3dv03HtkH/1SI8joQMQq00Bv+RdEbJXfEExrT
 u4gtdZAihwvy97OPA2nCdTAHm/phkzryMeOaOztI4PS8u2Ce5lUB6P/HcGtK/038KdX5MYST
 Fn8KUDt4o29bkv0CUXwDzS3oTzPNtGdryBkRMc9b+yn9+AdwFEH4auhiTQXPMnl0+G3nhKr7
 jvzVFJCRif3OAhEm4vmBNDE3uuaXFQnbK56GJrnqVN+KX5Z3M7X3fA8UcVCGOEHXRP/aubiw
 Ngawj0V9x+43kUapFp+nF69R53UI65YtJ95ec4PTO/Edvap8h1UbdEOc4+TiYwY1TBuIKltY
 1cnrjgAWUh/Ucvr++/KbD9tD6C8=
Message-ID: <90c7800b-2c91-762d-e822-883b45e2f814@huitema.net>
Date: Sat, 19 May 2018 18:37:49 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101
 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <CACpbDcfjDfQP69ZvUNjcUnQBGYKJAEJuh2BMK5dQZ8eRwfzOGQ@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------A62C4BA4F240CF141137E276"
Content-Language: en-US
Subject: Re: Payload length 0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/7kC6hTWLO6_CcFLiZmjOtbqubbs>
Precedence: list

This is a multi-part message in MIME format.
--------------A62C4BA4F240CF141137E276
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On 5/19/2018 6:16 PM, Jana Iyengar wrote:

>     The only way to prevent middlebox from hacking some part of the
>     protocol
>     is to use encryption. Any clear text hack will only be a slight road
>     bump for the middle-box hackers.
>
>
> Agreed, though I'll note that authenticating may be enough in some
> cases, encrypting may not be necessary.
>
>     For example, if we coalesce a CI and a 0-RTT packet, we could have the
>     zero RTT encryption depend on the presence of the previous packet.
>
>
> What I'm suggesting is that the length field, which is part of the
> authenticated header, include this signal as zero, or non-zero. I
> think this may be one interpretation of what you're saying: the header
> field, which is part of the AEAD hash, encodes the presence of another
> packet.

Yes, something like that would work. Maybe a flag in the first octet,
"is coalesced".

Note that, in the plausible CI + 0RTT coalescing, splitting the CI won't
work. It will be too short, and thus rejected by the server.

-- Christian Huitema


--------------A62C4BA4F240CF141137E276
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body text="#000000" bgcolor="#FFFFFF">
    <p>On 5/19/2018 6:16 PM, Jana Iyengar wrote:<br>
    </p>
    <blockquote type="cite"
cite="mid:CACpbDcfjDfQP69ZvUNjcUnQBGYKJAEJuh2BMK5dQZ8eRwfzOGQ@mail.gmail.com">
      <div class="moz-text-html" lang="x-unicode">
        <div dir="ltr">
          <div class="gmail_extra">
            <div class="gmail_quote">
              <blockquote class="gmail_quote" style="margin:0 0 0
                .8ex;border-left:1px #ccc solid;padding-left:1ex">The
                only way to prevent middlebox from hacking some part of
                the protocol<br>
                is to use encryption. Any clear text hack will only be a
                slight road<br>
                bump for the middle-box hackers.<br>
              </blockquote>
              <div><br>
              </div>
              <div>Agreed, though I'll note that authenticating may be
                enough in some cases, encrypting may not be necessary.</div>
              <div><br>
              </div>
              <blockquote class="gmail_quote" style="margin:0 0 0
                .8ex;border-left:1px #ccc solid;padding-left:1ex">
                For example, if we coalesce a CI and a 0-RTT packet, we
                could have the<br>
                zero RTT encryption depend on the presence of the
                previous packet.<br>
              </blockquote>
              <div><br>
              </div>
              <div>What I'm suggesting is that the length field, which
                is part of the authenticated header, include this signal
                as zero, or non-zero. I think this may be one
                interpretation of what you're saying: the header field,
                which is part of the AEAD hash, encodes the presence of
                another packet. <br>
              </div>
            </div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Yes, something like that would work. Maybe a flag in the first
    octet, "is coalesced". <br>
    <br>
    Note that, in the plausible CI + 0RTT coalescing, splitting the CI
    won't work. It will be too short, and thus rejected by the server.<br>
    <br>
    -- Christian Huitema<br>
    <br>
  </body>
</html>

--------------A62C4BA4F240CF141137E276--