[TLS] RFC 8446 Early data, server response: deprotect vs. type checking
Ben Smyth <research@bensmyth.com> Wed, 29 April 2020 12:21 UTC
Return-Path: <research@bensmyth.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731233A0E0E for <tls@ietfa.amsl.com>; Wed, 29 Apr 2020 05:21:56 -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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=bensmyth.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 kE1S07DA0By2 for <tls@ietfa.amsl.com>; Wed, 29 Apr 2020 05:21:53 -0700 (PDT)
Received: from 1.smtp.34sp.com (1.smtp.34sp.com [46.183.9.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A8D73A0E0B for <tls@ietf.org>; Wed, 29 Apr 2020 05:21:52 -0700 (PDT)
Received: from smtpauth2.mailarray.34sp.com (lvs5.34sp.com [46.183.13.73]) by 1.smtp.34sp.com (Postfix) with ESMTPS id 1D6CB1480075 for <tls@ietf.org>; Wed, 29 Apr 2020 13:21:18 +0100 (BST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bensmyth.com; s=dkim; t=1588162878; bh=r/tsO2yI8tfZ5lNokqnLYbxxn9jBvpKqMHylhU6qxq0=; h=Reply-To:From:Date:Subject:To; b=iEHSdxraXiYJR/n4AL13MqXSPo8aO33QI4TX/aSXyIvrM1HyvfByCj/tOBBaOhANp bzavV/CX8qaf+on9RQyY4MZcGRIwkaI0p0J9nJOHnP2hNu9eCY683waXjhe0d85MWY 19/ebshEWgVraGJM/JFMi49M922YQ4CiMYiNHR40=
Received: from mail-ed1-f54.google.com ([209.85.208.54]:39501) by smtpauth2.mailarray.34sp.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from <research@bensmyth.com>) id 1jTliH-0006WY-Vg for tls@ietf.org; Wed, 29 Apr 2020 13:21:18 +0100
Received: by mail-ed1-f54.google.com with SMTP id k22so1334895eds.6 for <tls@ietf.org>; Wed, 29 Apr 2020 05:21:17 -0700 (PDT)
X-Gm-Message-State: AGi0Puaa0mbFfRXKTBqH9t4DepjPIeDFAk2bvvGmU/uUJvkZGJPKEhts +ekPKVh+HKX5yTyDhcwS2MhjwBrGdu9KBPjHupE=
X-Google-Smtp-Source: APiQypIJcwXCS+jnqtkM4O4UZtJN9U35mQRZfKQ/IQJ/+RJwXMEjUgC1c8A97f72+5ZheqKiB6OpgWfTh09iWWy/bUs=
X-Received: by 2002:a50:ee0e:: with SMTP id g14mr2231518eds.34.1588162877169; Wed, 29 Apr 2020 05:21:17 -0700 (PDT)
MIME-Version: 1.0
Reply-To: research@bensmyth.com
From: Ben Smyth <research@bensmyth.com>
Date: Wed, 29 Apr 2020 14:20:50 +0200
X-Gmail-Original-Message-ID: <CA+_8xu1uyyCeV_-YgrRfEOqkc3aapzKfGJMZJWqm+iMofbBzeA@mail.gmail.com>
Message-ID: <CA+_8xu1uyyCeV_-YgrRfEOqkc3aapzKfGJMZJWqm+iMofbBzeA@mail.gmail.com>
To: tls@ietf.org
Content-Type: multipart/alternative; boundary="00000000000023a92305a46cfc36"
X-Authenticated-As: research@bensmyth.com
X-OriginalSMTPIP: 209.85.208.54
X-34spcom-MailScanner-Information: Please contact the ISP for more information
X-34spcom-MailScanner-ID: 1D6CB1480075.A70A5
X-34spcom-MailScanner: Found to be clean
X-34spcom-MailScanner-SpamCheck: not spam, SpamAssassin (score=-20.1, required 6.5, autolearn=disabled, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, HTML_MESSAGE 0.00, SPF_PASS -0.00, X34SP_ALLOW_GMAIL_EVEN_IF_BLACKLISTED -10.00, X34SP_OVERRIDE -10.00)
X-34spcom-MailScanner-From: research@bensmyth.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/1YJWFKNu1EhMAleX3BASsMDFTXI>
Subject: [TLS] RFC 8446 Early data, server response: deprotect vs. type checking
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Apr 2020 12:42:39 -0000
Section 4.2.10 requires a server receiving early data to behave in ways including (p53): * Ignore the extension and return a regular 1-RTT response. The server then skips past early data by attempting to deprotect received records using the handshake traffic key, discarding records which fail deprotection... * Request that the client send another ClientHello by responding with a HelloRetryRequest... The server then ignores early data by skipping all records with an external content type of "application_data"... What are the use cases for each behaviour? And why does the former rely on deprotecting, when checking record content types is surely more efficient? (I'm extending my TLS 1.3 tutorial -- https://bensmyth.com/publications/2019-TLS-tutorial/ -- to include discussion of early data and I'm struggling to understand the rationale behind these two behaviours.) Best regards, Ben
- [TLS] RFC 8446 Early data, server response: depro… Ben Smyth
- Re: [TLS] RFC 8446 Early data, server response: d… Eric Rescorla
- Re: [TLS] RFC 8446 Early data, server response: d… Ben Smyth
- Re: [TLS] RFC 8446 Early data, server response: d… Eric Rescorla