Re: Padding in Initial Packets

Martin Thomson <mt@lowentropy.net> Wed, 01 July 2020 01:18 UTC

Return-Path: <mt@lowentropy.net>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03C0A3A086B for <quic@ietfa.amsl.com>; Tue, 30 Jun 2020 18:18:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lowentropy.net header.b=numkcfAW; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=trk8f9N4
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 awuT_yr_qYXC for <quic@ietfa.amsl.com>; Tue, 30 Jun 2020 18:18:48 -0700 (PDT)
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22C403A086D for <quic@ietf.org>; Tue, 30 Jun 2020 18:18:48 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 12FE15C0116 for <quic@ietf.org>; Tue, 30 Jun 2020 21:18:47 -0400 (EDT)
Received: from imap2 ([10.202.2.52]) by compute2.internal (MEProxy); Tue, 30 Jun 2020 21:18:47 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lowentropy.net; h=mime-version:message-id:in-reply-to:references:date:from:to :subject:content-type:content-transfer-encoding; s=fm2; bh=/sh5e asAr4mExRXrA4kCZrKQm/C0PrGRI9KWWxXj2H8=; b=numkcfAWWLdHuoRMEbjlB LzdGKQIZ5R997dDIEUtIqEDJGiIYXHSyJYqKeQKAu9wMvVzAHY2i5UR86PYBkeqB NL52PQ5rqD15ts61oMrYaftPJFjTOEN0GUhRVPfygJz3JI6CQBf835TMnb4hogtd RR+0Tz6zOjjBrcawvM8vseiOcOaWjUnlKFp5M0JWPlwbijBrENU3RM7WW+Orcm/L iOpioNTMXpCzEYpgODa0KVROvqo7kSA1OUrzgBcOzlWOvM+x+DjMcnEbMHkjvy/L SCYZgawKT6m/EZAE6XPvw/s/9Ld2rp0B56ba+JVr+UM9/G8XyxyPSHll8j9ez/K9 w==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=/sh5easAr4mExRXrA4kCZrKQm/C0PrGRI9KWWxXj2 H8=; b=trk8f9N4FCTBvNwS6Bc6Ko2bEtg9jZVEPzLtuyq2S+FAwhSKHdwLc08Uk 0z5eno32cQQis58fWYTipkwDSKl7FJCIrLsFx9ng7UzvW0fxqFtJDRlmJpNZv80e qeTL/HjQC7C2t6a4vSDSQPdbs1G1iFM+cQcD/DJ4+g7+K1xkRZpxzd7lwLg+PvI9 gy4fNH5IGDp66ig7htWFLfowt9cIhWryR7THOcE9jIMUZta3Jreyk4uGL1AehRYi 03RoIJanVG3j2HfXhYsYD294TIK//Lt3yoLeUPgT4YS5McHd60y/1w5eWoyR0PQ2 M7dexj9b/XR6sQ1bTahsKil/+eGSg==
X-ME-Sender: <xms:duT7XoqjOoQz_om_LpOtDOavy3dw9Q5vUf9tgh_BVxUtgcNS96cMig>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrtddugdeghecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgfgsehtqh ertderreejnecuhfhrohhmpedfofgrrhhtihhnucfvhhhomhhsohhnfdcuoehmtheslhho figvnhhtrhhophihrdhnvghtqeenucggtffrrghtthgvrhhnpefgjeeuudeiffeltdegle ehjedvtedtjeduudehgfegfefgkefgueeiteegffdttdenucevlhhushhtvghrufhiiigv pedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehmtheslhhofigvnhhtrhhophihrdhnvg ht
X-ME-Proxy: <xmx:duT7Xuq5E7N9awGmeT1dmiAfEWOY34hHb4UAHzlMN6VrYGzKLdmcGQ> <xmx:duT7XtO8hj8lMD96SbVsevuDkvEcu9YvOXy0yszmfJ4JfbkCtAmBmg> <xmx:duT7Xv5ja2vrnfHUQtxhPEusyXW1BttAy3RbNcqeY6JUlRryBTJCPQ> <xmx:d-T7XqKQEUkfi3A2BR4nMJ2ip4da3Rc3KFvTtM0EHxOKi0zEj9UP9g>
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 56F92E00CE; Tue, 30 Jun 2020 21:18:46 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.3.0-dev0-576-gfe2cd66-fm-20200629.001-gfe2cd668
Mime-Version: 1.0
Message-Id: <f97dbbe6-e719-4276-bd19-da6589bb2d4e@www.fastmail.com>
In-Reply-To: <LNXP123MB24602880B0AE644B9B1F3F83F26F0@LNXP123MB2460.GBRP123.PROD.OUTLOOK.COM>
References: <LNXP123MB24602880B0AE644B9B1F3F83F26F0@LNXP123MB2460.GBRP123.PROD.OUTLOOK.COM>
Date: Wed, 01 Jul 2020 11:18:05 +1000
From: "Martin Thomson" <mt@lowentropy.net>
To: quic@ietf.org
Subject: Re: Padding in Initial Packets
Content-Type: text/plain;charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/v0kO1KxIyF4x_RC2_2tuXRcRPc4>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jul 2020 01:18:50 -0000

Hi Tim,

That's a little curveball that Firefox throws.  Other implementations pad with PADDING frames inside Initial packets.  Our first implementation found that inconvenient and so we padded outside the packet.  The resulting "packets" are clearly not valid, but neither server nor spec cannot require that they be legitimate. QUIC doesn't authenticate the composition of QUIC packets into UDP datagrams.  So the overall result is valid, even if the individual bits are not.

The number of bugs this behaviour has exposed is so great that we ultimately decided to keep it.  Fixing it would make our code more complicated anyway.

We might change the value we use for padding from 0 to something else at some point, just to keep things fresh.

Cheers,
Martin

On Tue, Jun 30, 2020, at 20:15, tim.jebb@bt.com wrote:
>  
> Hi All,
> 
> 
> I’m fairly new to QUIC so apologies if the questions in here are dumb.
> 
> 
> I’ve been going through a QUIC pcap, which I captured from a Firefox 
> implementation of IETF draft 27 QUIC, and am a little confused about 
> the use of padding in the first Initial packet. According to Wireshark, 
> the UDP datagram contains a QUIC packet of type initial, length 272, 
> the payload of which is a Client Hello. 
> 
> 
> The remainder of the UDP datagram is 1055 zero bytes.. According to 
> Wireshark these zero bytes constitute a QUIC IETF Packet.
> 
> 
> However there doesn’t seem to be a valid QUIC packet header for these 
> bytes. AIUI according to the QUIC spec padding bytes are frames within 
> a packet, so these zero bytes seem to be just bytes in the UDP datagram 
> outside of the QUIC payload. Which would be fine as far as I can see, 
> but:
> 
> 
> Why does Wireshark say it’s QUIC IETF?
> 
> Is there anything in any of the QUIC draft RFCs mandating this 
> behaviour, if so where?
> 
> Why is it being done – can’t see the point?
> 
> If padding is to be added surely it should be as part of a QUIC packet 
> and encrypted – here there’s just a load of plaintext zero bytes.
> 
> 
> 
> Here is Wireshark’s analysis:
> 
> 
> “QUIC IETF
> 
>  QUIC Connection information
> 
>  [Packet Length: 302]
> 
>  1... .... = Header Form: Long Header (1)
> 
>  .1.. .... = Fixed Bit: True
> 
>  ..00 .... = Packet Type: Initial (0)
> 
>  .... 00.. = Reserved: 0
> 
>  .... ..10 = Packet Number Length: 3 bytes (2)
> 
>  Version: draft-27 (0xff00001b)
> 
>  Destination Connection ID Length: 17
> 
>  Destination Connection ID: 76f81a5588b2f25c5ab6dbd461a8d749e1
> 
>  Source Connection ID Length: 3
> 
>  Source Connection ID: c5ef02
> 
>  Token Length: 0
> 
>  Length: 272
> 
>  Packet Number: 0
> 
>  Payload: 04f535177fcbcfd5f06d24ffde66edf10df79205666b1851…
> 
>  TLSv1.3 Record Layer: Handshake Protocol: Client Hello
> 
>  Frame Type: CRYPTO (0x0000000000000006)
> 
>  Offset: 0
> 
>  Length: 249
> 
>  Crypto Data
> 
>  Handshake Protocol: Client Hello
> 
>  Handshake Type: Client Hello (1)
> 
>  Length: 245
> 
>  Version: TLS 1.2 (0x0303)
> 
>  Random: b1b76126ddab3c639cdfaa7d92d6cabe2ea9c1a19ea86b8b…
> 
>  Session ID Length: 0
> 
>  Cipher Suites Length: 4
> 
>  Cipher Suites (2 suites)
> 
>  Compression Methods Length: 1
> 
>  Compression Methods (1 method)
> 
>  Extensions Length: 200
> 
>  Extension: server_name (len=15)
> 
>  Extension: extended_master_secret (len=0)
> 
>  Extension: renegotiation_info (len=1)
> 
>  Extension: supported_groups (len=20)
> 
>  Extension: application_layer_protocol_negotiation (len=8)
> 
>  Extension: status_request (len=5)
> 
>  Extension: key_share (len=38)
> 
>  Extension: supported_versions (len=3)
> 
>  Extension: signature_algorithms (len=16)
> 
>  Extension: psk_key_exchange_modes (len=2)
> 
>  Extension: record_size_limit (len=2)
> 
>  Extension: quic_transports_parameters (len=42)
> 
> QUIC IETF
> 
>  [Packet Length: 1055]
> 
>  Remaining Payload: 000000000000000000000000000000000000000000000000…”
> 
> 
> Any comments or explanations?
> 
> 
> Tim
>