IETF Logo Mail Archive

Re: [quicwg/base-drafts] Padding requirement seems to be incorrect. (#3053)

David Schinazi <notifications@github.com> Tue, 01 October 2019 19:41 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 22AB7120043 for <quic-issues@ietfa.amsl.com>; Tue, 1 Oct 2019 12:41:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.281
X-Spam-Level:
X-Spam-Status: No, score=-6.281 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 ovlQ1OJx4_Kz for <quic-issues@ietfa.amsl.com>; Tue, 1 Oct 2019 12:41:54 -0700 (PDT)
Received: from out-2.smtp.github.com (out-2.smtp.github.com [192.30.252.193]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FB74120018 for <quic-issues@ietf.org>; Tue, 1 Oct 2019 12:41:54 -0700 (PDT)
Received: from github-lowworker-e8b54ca.ac4-iad.github.net (github-lowworker-e8b54ca.ac4-iad.github.net [10.52.23.39]) by smtp.github.com (Postfix) with ESMTP id 7DFE11C02E7 for <quic-issues@ietf.org>; Tue, 1 Oct 2019 12:41:53 -0700 (PDT)
Date: Tue, 01 Oct 2019 12:41:53 -0700
From: David Schinazi <notifications@github.com>
Reply-To: quicwg/base-drafts <reply+AFTOJKYWK6MCDULMNBAQSM53UDWJDEVBNHHB3EM4KU@reply.github.com>
To: quicwg/base-drafts <base-drafts@noreply.github.com>
Cc: Subscribed <subscribed@noreply.github.com>
Message-ID: <quicwg/base-drafts/issues/3053/537196679@github.com>
In-Reply-To: <quicwg/base-drafts/issues/3053@github.com>
References: <quicwg/base-drafts/issues/3053@github.com>
Subject: Re: [quicwg/base-drafts] Padding requirement seems to be incorrect. (#3053)
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="--==_mimepart_5d93ac016e08e_36e3f7e134cd9681069e8"; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Precedence: list
X-GitHub-Sender: DavidSchinazi
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/8vblDmbxe5rVAmgtJ-247ZIyajY>
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, 01 Oct 2019 19:41:56 -0000

I think the specification should mandate padding of server initial packets as well.

When I was traveling a couple weeks ago, I was on a network where, when using IPv6, it allowed 1200-byte UDP packets through from client to server but blackholed them from server to client. Since our implementation pads initials in both directions, we were able to detect this failure during the handshake and fall back to TCP/TLS. If the server didn't pad its initials, we would have succeeded at the handshake but never gotten an HTTP response.

-- 
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/3053#issuecomment-537196679

v2.23.0 | Report a Bug | By Email