Re: Stream0 Design Team Proposal

Jana Iyengar <> Wed, 23 May 2018 21:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 36CEF12D7E6 for <>; Wed, 23 May 2018 14:50:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.999
X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0L0Jcl66fBNC for <>; Wed, 23 May 2018 14:50:06 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c06::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7107E1201F8 for <>; Wed, 23 May 2018 14:50:06 -0700 (PDT)
Received: by with SMTP id c9-v6so24608255iob.12 for <>; Wed, 23 May 2018 14:50:06 -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; bh=i6K8NIw5y3opTcywTEFxNFscL804qmaMW6ocUt+nlxg=; b=QmFCdR/nFAKhNvWOrjAMV/TnAVUOtybuM0qz2xeILQAfPlORkcjj4KnHisGSAeRV9o TbEQ5PCJtfyoX+LhVDWFtWcSpeVe3J3ydMV5vWAMzZBEQ0MrBDGjBevS3EehtmPxtXe1 6pfFjWCPyGY7zRoYqWiwHG5QzhF0tDsgUQX6YvV8xWWuTSbgOIVzkUf6hxPgxC8LaMz/ /JIVcDDgG6VDx+UJEYLbpbwC34Xs43TviuXMeC3AueaACjOK2q5R2JNp1f0DtjI+mpUP DgZAA4loEIuDwQVszLA3k5i6wAMFHYvZ+pcbem8L859gwnwXKpMg5j2DQ0tW6dSWm+Fg lF0g==
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; bh=i6K8NIw5y3opTcywTEFxNFscL804qmaMW6ocUt+nlxg=; b=bpWphLgGdd7qq+CMPDfT5nx92Hizt/TSo1TeC0lZsXTVJElexmHwfROD/sXhJ0nE1C QtbVT1egay5llZ2MQPTJYsoZAJ2uk58Ft9Ewct+VOYubCfNqQ7ErtYynf8wvdyuQ/Zre Tgw+/nw/oJvyHP5XvRQlrmooT2dmSnqNP9KTJE7ZsqWla5asBh44ESAMHEu1xXJbBjwX LiL1WIQ1q8Fm34KbS+3c0VGFTjx87mA9Z8vzcpvn1re2ShZs8JQObs7BP2aih+MF6FSY iVdqjbFrTl1WcGjUTksGmJ3xe5Ec1LYpqDvL54UwalMRJiczd1lzLj2ClvVBUzxHP3gJ vWDw==
X-Gm-Message-State: ALKqPwfYdzpKv21bepXwvj3+1Gg17P49//rTNtF8ts2XEBZeq9kVu8rA 4IS4zhTieIBauKtvMS7Njy5olLf2P12EC6alBLI=
X-Google-Smtp-Source: ADUXVKKCYT9qytigJ4jlfyRj+IuI9LJxmElAbl2ayBMezS4hSiUiDtJMFKzgitrmPnJlyXechr0odLKIPP64+3g0Dxo=
X-Received: by 2002:a6b:d617:: with SMTP id w23-v6mr4076563ioa.8.1527112205680; Wed, 23 May 2018 14:50:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a4f:27d4:0:0:0:0:0 with HTTP; Wed, 23 May 2018 14:50:05 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <> <>
From: Jana Iyengar <>
Date: Wed, 23 May 2018 14:50:05 -0700
Message-ID: <>
Subject: Re: Stream0 Design Team Proposal
To: Mikkel Fahnøe Jørgensen <>
Cc: Ted Hardie <>, Eric Rescorla <>, Eric Rescorla <>, IETF QUIC WG <>, Ian Swett <>
Content-Type: multipart/alternative; boundary="0000000000008d47b6056ce68454"
Archived-At: <>
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 23 May 2018 21:50:08 -0000


I agree that we should be careful and describe differences in detail where
they exist before making any conclusions about a security analysis. Perhaps
we ought to bring this in front of the tlswg and make sure that folks there
get a chance to poke holes in this proposal.

That said, I don't believe your mapping from records to frames is right. As
I see it, the equivalent of a TLS record in this proposal is a QUIC packet.
Both are encrypted similarly, and both contain pieces of or one or multiple
messages. Padding in TLS is present within the records but outside
messages. Equivalently, padding in this proposal is present within packets
but outside frames carrying TLS messages.

- jana

On Wed, May 23, 2018 at 2:20 PM, Mikkel Fahnøe Jørgensen <
> wrote:

> I believe you have misunderstood. In this document, there are no TLS
>> records and TLS handshake messages are carried in CRYPTO_HS frames.
>> Accordingly, padding is provided in the same fashion as QUIC ordinarily
>> does, i.e., using PADDING frames.
>> That's what I understood from the design document.  The point I'm making
> is that this actually a substantive change to the padding structure that
> was previously present (in TLS records), and the security analysis has to
> take that into account, so it (and similar things) should be described.
> As an example of things to consider, padding is probably a fair point.
> From a practical perspective, padding could be seen as a pain from older
> crypto formats that needs to be dealt with in TLS while the crypto
> primitives of QUIC already has an answer to this problem.
> But if TLS messages contain encryption primitives beyond what QUIC
> provides in early handshake that assumption breaks down while the QUIC
> crypto is still weak. For example concerning the encoding of key exchange
> parameters. So at the very least it must be stated that this is not an
> issue and why it is not issue.