Re: [quicwg/base-drafts] Can a client send 0-RTT data when receiving Retry? (#1507)

ekr <notifications@github.com> Mon, 02 July 2018 12:55 UTC

Return-Path: <noreply@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 884A51292AD for <quic-issues@ietfa.amsl.com>; Mon, 2 Jul 2018 05:55:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.009
X-Spam-Level:
X-Spam-Status: No, score=-8.009 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, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=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 jP00dM1ZD0IW for <quic-issues@ietfa.amsl.com>; Mon, 2 Jul 2018 05:55:56 -0700 (PDT)
Received: from out-15.smtp.github.com (out-15.smtp.github.com [192.30.254.198]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6304512F1AC for <quic-issues@ietf.org>; Mon, 2 Jul 2018 05:55:56 -0700 (PDT)
Date: Mon, 02 Jul 2018 05:55:55 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1530536155; bh=GVnnqnjYk0TlvAYPLJNIE2Cu79quDCdJM8ER1el/SoY=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=Y4l4MBPI/vLCRzV6JRko3axL1j1rQLNFrkEiPbJad2zAY7/CFcDE72J0RaRFLluil XRkXwMxL5jQ5TOKl/pSn/nB+KdzRawwxvLWESTOyXAE6HJ1xTvCvTGLpRLBcK5o03i IW9z7gLCdwSaPWG04nHzXKqUr+ZM5ffbjKgnUaqc=
From: ekr <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4ab1c9abfadbca336adc541819da265000a894480a692cf000000011751e2db92a169ce1418d0ad@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1507/401795136@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1507@github.com>
References: <quicwg/base-drafts/issues/1507@github.com>
Subject: Re: [quicwg/base-drafts] Can a client send 0-RTT data when receiving Retry? (#1507)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5b3a20dbbdea9_274a2b04e4a52f5892755"; 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
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic-issues/rJTx1pdu5OcIfvuNlbvdpudAccc>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.26
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: Mon, 02 Jul 2018 12:55:59 -0000

> The point is that if the handshake is successful, then the ClientHello and all the 0-RTT have the same destination connection ID, so they probably end up at the same point. Add Retry and they might not.

Huh? If you do Retry, you resend initial and this includes resending CH and 0-RTT.


> I think that the TLS analogy is fine. In TLS, a server could want a different key share, but find the PSK perfectly adequate for the purposes of 0-RTT. There's no reason a server that sends HelloRetryRequest would need to stop accepting 0-RTT.

Yes, of course, but that creates complexity in the TLS state machine because of the way CH and HRR are intertwined. That is not so for Retry.



-- 
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/1507#issuecomment-401795136