IETF Logo Mail Archive

Re: [quicwg/base-drafts] Disconnect with Initial Injection (#1951)

Kazuho Oku <notifications@github.com> Tue, 13 November 2018 02:58 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 883C312872C for <quic-issues@ietfa.amsl.com>; Mon, 12 Nov 2018 18:58:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.47
X-Spam-Level:
X-Spam-Status: No, score=-8.47 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.47, 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] 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 wtrbe1_-zF-a for <quic-issues@ietfa.amsl.com>; Mon, 12 Nov 2018 18:58:51 -0800 (PST)
Received: from out-6.smtp.github.com (out-6.smtp.github.com [192.30.252.197]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4E51124408 for <quic-issues@ietf.org>; Mon, 12 Nov 2018 18:58:50 -0800 (PST)
Date: Mon, 12 Nov 2018 18:58:49 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=github.com; s=pf2014; t=1542077929; bh=un7NwE7JJjr8YE+ToR/BKCJla2HST023fYWY25Gweb0=; h=Date:From:Reply-To:To:Cc:In-Reply-To:References:Subject:List-ID: List-Archive:List-Post:List-Unsubscribe:From; b=MjWbvhaBAAWyzVj76WYsnWpiOa444+rhT+q8HNBTWTRnTQey8Gt0PHkfBS9ACpf/P +CvAhGAkQ+sJHD5rZ/QyfQPbBtnhEQHUk64I3ywGcgSwj+qV9MrvA4yp34rlXtT+po dCNUKXf+rUm5r2mkhqbhr8r/IuvbTb8YlkHVAeb4=
From: Kazuho Oku <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+0166e4aba7158d962953ef9eb61ecff679063a44088d09f592cf000000011801ffe992a169ce1678fc4e@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/1951/438112817@github.com>
In-Reply-To: <quicwg/base-drafts/issues/1951@github.com>
References: <quicwg/base-drafts/issues/1951@github.com>
Subject: Re: [quicwg/base-drafts] Disconnect with Initial Injection (#1951)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5bea3de972b98_24843f7f5dcd45bc9648e"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: kazuho
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/miWpmYQpuu0yONDkzuIJGyutf94>
X-BeenThere: quic-issues@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 13 Nov 2018 02:58:53 -0000

My understanding is that what @huitema is proposing in
https://github.com/quicwg/base-drafts/issues/1951#issuecomment-435564424 is just defining when the endpoints should drop Initial keys (and stop sending / receiving Initial packets).

Until that happens, endpoints are expected to ACK Initial packets. So in case of HRR, the exchanges of packets will be exactly the same as we have now up to the point when the server receives the 2nd Client Hello.

I think that the approach would work fine, and that it is trivial to implement.

The only annoyance I feel about the proposal is the fact that it is an attempt to overturn our previous conclusion to use explicit ACKs. But I agree that this is an improvement in terms of security and also that it is trivial to implement. Hence my +1 to adopting the proposal.

-- 
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/1951#issuecomment-438112817

v2.23.0 | Report a Bug | By Email