Re: Padding in Initial Packets

Mikkel Fahnøe Jørgensen <mikkelfj@gmail.com> Wed, 01 July 2020 04:12 UTC

Return-Path: <mikkelfj@gmail.com>
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 C7EC63A0BA7 for <quic@ietfa.amsl.com>; Tue, 30 Jun 2020 21:12:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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=gmail.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 sKzUKMsHJLHJ for <quic@ietfa.amsl.com>; Tue, 30 Jun 2020 21:12:35 -0700 (PDT)
Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) (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 C1F683A0B6A for <quic@ietf.org>; Tue, 30 Jun 2020 21:12:35 -0700 (PDT)
Received: by mail-yb1-xb35.google.com with SMTP id y17so9175131ybm.12 for <quic@ietf.org>; Tue, 30 Jun 2020 21:12:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=AemDyWHA4LLEq5eQs2ue5tQmpVkgsoMZRFSpZhIuScQ=; b=f+hUJhsv6FbLfAC3hWvFZRhTR8oZuCV2V635ZsRag7iJoezD8sJBwEG2gkS1xyzHnm b58ipq2UJwb+6HqVxIe+4nAckBhBcjQRRm61sS2EGhplo8Qf2JIfXcz+8ZxjwuV3bCx2 yq7TbnHKJk/0KeViU+LxAmXr3PoJLeDAXZL8EOgt9pqJBOiDaWdLmCLuG5xQBJE4nUv/ ZAmnmAmggmUJavKLOVQivYbWzpRA+E6/sMq5qGnQn3RTcJNpst3jbldEFxMzKVtv/CvN 4MLe9rda6svCa7qxztenY1ZivgJwC+tLs8z0l5a5Ce/ZngE+fllCeEhbJDhiKNu6Kw3l Y1wg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=AemDyWHA4LLEq5eQs2ue5tQmpVkgsoMZRFSpZhIuScQ=; b=D7UslLyX3a3s27UbMAhUJehuy7hoJ/9tVuJS0DFyESsTRGmG1xbpsKrItcCEyHkVLH KL0t4Utm6+3U/T8uS6fxREJWS1Uhz17XSVOPsPlKEKhtIFNchLoYpLwOtfWlm0ttQBAb aj8Vz0OGTIKbnuLc5UQsD+Srb90ZKPHONZDBxOtAzA+ui9bH4ILBAtSnzt+AJRqNOP+f Tr5HmzAe53waIVnE2A4inkF8vxL9sBljaLYoKONix5NSSQznGvVTq8bHaf+G+QkQwIPx il+SIdcEQieazq/JEuf6jLdI9lQm34NidXXkLwCulFcPIkV1fLFMb75C0qpO2hLLXP3V +Bug==
X-Gm-Message-State: AOAM532MNfAWqIiP5KuZf2RnRSOegAbz7hjYcVxK3kd70WiDwWKItu30 4tZ+qfMfgj7xEGUe1KyPh7rWaUQnsl7HjWOA+P0=
X-Google-Smtp-Source: ABdhPJxt66kEvfdO3+qZupHtJngou5y4Bl/wvUkVD1HjkOvmLusfeGARfPIT3sZ+5eSmIScedkh5+R/y6ZdAsR3cTJQ=
X-Received: by 2002:a25:fd5:: with SMTP id 204mr38484053ybp.294.1593576754816; Tue, 30 Jun 2020 21:12:34 -0700 (PDT)
Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 30 Jun 2020 21:12:34 -0700
From: =?UTF-8?Q?Mikkel_Fahn=C3=B8e_J=C3=B8rgensen?= <mikkelfj@gmail.com>
In-Reply-To: <E86FC27B-E38E-4842-BD4F-A316ADD51FE9@eggert.org>
References: <f97dbbe6-e719-4276-bd19-da6589bb2d4e@www.fastmail.com> <E86FC27B-E38E-4842-BD4F-A316ADD51FE9@eggert.org>
MIME-Version: 1.0
Date: Tue, 30 Jun 2020 21:12:34 -0700
Message-ID: <CAN1APdejsLess_eLQPnaUOWhfiZXFiGG07poGYvtQE=9xq1bTw@mail.gmail.com>
Subject: Re: Padding in Initial Packets
To: Lars Eggert <lars@eggert.org>, Martin Thomson <mt@lowentropy.net>
Cc: quic@ietf.org
Content-Type: multipart/alternative; boundary="00000000000064aecb05a9598078"
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/rm5Th5g_PTZRuwWkiiSt25aOIqM>
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 04:12:38 -0000

Maybe an an amplification attack is possible by sending all zeroes, if it
happens over a compressed link as opposed to sending random data. Maybe a
sat uplink of sorts.

This could (mostly) be avoided be having all initial data inside a QUIC
packet, although a really aggressive compressor could figure this out for
the initial packet.

Mikkel

On 1 July 2020 at 04.17.24, Lars Eggert (lars@eggert.org) wrote:

Quant similarly pads by coalescing random data (with the first byte
massaged to be of short-header type).

-- 
Sent from a mobile device; please excuse typos.

> On Jul 1, 2020, at 04:19, Martin Thomson <mt@lowentropy.net> wrote:
>
> 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
>>
>