Re: [quicwg/base-drafts] Can Finished be sent as 1-RTT data? (#785)

ekr <notifications@github.com> Wed, 20 September 2017 17:28 UTC

Return-Path: <bounces+848413-a050-quic-issues=ietf.org@sgmail.github.com>
X-Original-To: quic-issues@ietfa.amsl.com
Delivered-To: quic-issues@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCBD2132D51 for <quic-issues@ietfa.amsl.com>; Wed, 20 Sep 2017 10:28:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=github.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCOOy_Ue-bvN for <quic-issues@ietfa.amsl.com>; Wed, 20 Sep 2017 10:28:03 -0700 (PDT)
Received: from o7.sgmail.github.com (o7.sgmail.github.com [167.89.101.198]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 232F1126D0C for <quic-issues@ietf.org>; Wed, 20 Sep 2017 10:28:03 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=github.com; h=from:reply-to:to:cc:in-reply-to:references:subject:mime-version:content-type:content-transfer-encoding:list-id:list-archive:list-post:list-unsubscribe; s=s20150108; bh=XrGJcaboMO5c5jACirLyAFf46/I=; b=d3jmh3UvNAqCPV5e /PYS54IzFwJP51pvv3CKZfZBjhcgUxr6yvh01t/IBkEGGVcyw/Iwd1grLcY5IlHQ ixMcqJjAoViUGkQlAgjIgP7AeIWmT2v2PdDUKJ3xVfUgnZ2K3nDNdxvQkvGGEaye 8zHpk0p3DSmY5c//jopq7+hAhP4=
Received: by filter0550p1mdw1.sendgrid.net with SMTP id filter0550p1mdw1-26967-59C2A50E-D 2017-09-20 17:27:42.205214593 +0000 UTC
Received: from github-smtp2b-ext-cp1-prd.iad.github.net (github-smtp2b-ext-cp1-prd.iad.github.net [192.30.253.17]) by ismtpd0005p1iad1.sendgrid.net (SG) with ESMTP id nJzYRN2uRXactQ9gArx7qw for <quic-issues@ietf.org>; Wed, 20 Sep 2017 17:27:42.182 +0000 (UTC)
Date: Wed, 20 Sep 2017 17:27:42 +0000
From: ekr <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab62fef08f4279c9c75c7a2e3933c9c04c6275039792cf0000000115da670e92a169ce0f7388f0@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/785/330922993@github.com>
In-Reply-To: <quicwg/base-drafts/issues/785@github.com>
References: <quicwg/base-drafts/issues/785@github.com>
Subject: Re: [quicwg/base-drafts] Can Finished be sent as 1-RTT data? (#785)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_59c2a50e8267_c733ffcfe782f7c498b2"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: ekr
X-GitHub-Recipient: quic-issues
X-GitHub-Reason: subscribed
X-Auto-Response-Suppress: All
X-GitHub-Recipient-Address: quic-issues@ietf.org
X-SG-EID: l64QuQ2uJCcEyUykJbxN122A6QRmEpucztpreh3Pak3uDyNyDBwVcsG9Dojj0K6zNB356nhvBKZMJ1 5kHdqHOEu4mTQYg8aSdyTtSfKlBpaVCHu88FCHrPLHTfpVsN/sDlSQn+pO3DUx9Nv7q19NImIiVbHn NW9iXbDftIbvXiIx4Tvt5WZihYi0GDlWiQ99lOcUOtZ52RtP/m5nTQPDsw==
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/NujmO4hc_9LyNuBgzw1PwjNq-m8>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Notification list for GitHub issues related to the QUIC WG <quic-issues.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic-issues/>
List-Post: <mailto:quic-issues@ietf.org>
List-Help: <mailto:quic-issues-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic-issues>, <mailto:quic-issues-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Sep 2017 17:28:05 -0000

Note that there are cryptographic reasons for using different keys. This
was one of the big reasons for the TLS 1.3 key schedule being the way it
is. So I'd really much rather have it be in Client Clear Text.

On Wed, Sep 20, 2017 at 9:44 AM, Christian Huitema <notifications@github.com
> wrote:

> I know that in TLS 1.3, the answer is no. But the TLS answer applies to
> TLS over TCP, for which TLS manages the transition from handshake data to
> application data. QUIC is arguably different. The stream zero frame will
> carry the Finished message as an encrypted handshake message. But the spec
> is a bit ambiguous as to whether this stream zero frame shall be carried as
> "Client Clear Text" or "1-RTT Data".
>
> I would much prefer 1-RTT data, because of repetition handling. If we
> imposed Client Clear Text, and the packet is lost, the stream zero frame
> will have to be retransmitted again as client clear text. That means
> interleaving clear text data and encrypted data within a single set of
> sequence number, and I am convinced that that can be abused to carry some
> kind of denial of service.
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/quicwg/base-drafts/issues/785>, or mute the thread
> <https://github.com/notifications/unsubscribe-auth/ABD1oT5HMe2FR9zNWo44cYAme93ZWPjDks5skUDRgaJpZM4PeKN8>
> .
>


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/issues/785#issuecomment-330922993