IETF Logo Mail Archive

Re: [TLS] RFC 8446 Early data, server response: deprotect vs. type checking

Eric Rescorla <ekr@rtfm.com> Wed, 29 April 2020 13:43 UTC

Return-Path: <ekr@rtfm.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 4DDEE3A0FD2 for <tls@ietfa.amsl.com>; Wed, 29 Apr 2020 06:43:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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=rtfm-com.20150623.gappssmtp.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 5AyI8Wdt9zpJ for <tls@ietfa.amsl.com>; Wed, 29 Apr 2020 06:43:40 -0700 (PDT)
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com [IPv6:2a00:1450:4864:20::132]) (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 EAA6D3A0FED for <tls@ietf.org>; Wed, 29 Apr 2020 06:43:39 -0700 (PDT)
Received: by mail-lf1-x132.google.com with SMTP id 188so1682040lfa.10 for <tls@ietf.org>; Wed, 29 Apr 2020 06:43:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=C04JPfb1AAdlMDBFxi/JU51KlwQGcZT0WqR5fjwtYU0=; b=0VWyYqO0XzVG9weajiJ5mOqHs8WFSyts14Efp+j6t7XQz1DvJNX0+X5Z1Vl89veK2d xknbpeVRGZZew3lvyk2eohmWOeKfr7DJDRUjIKB7WC0vJrCC1nskwFZ2ht8ahRohlHj7 W4geeecB/hGQ9gPXWOimWR0Ukvesr5/qFMUxxc9GH6l8bfEURYcUAExmUaq0kMC+3qlT tMdOEf9rNaWoVweMSrb+mgiExPPJEqusess0+E2S0RyrSGJCjzjS4124bmTr5dglVahm oVmqgMI6majeVmWvtLxcihYw97zF1GooGn+T/9NZPbwM6n7TNAOZr1wt52BtBzeCDye3 HqNw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=C04JPfb1AAdlMDBFxi/JU51KlwQGcZT0WqR5fjwtYU0=; b=A77ov3OW5MjJBi14WlUD/QozfPBkZvCu8qSgvoMik+k1nJr9756d4Qk+O9cbZCaCpr 4t/FPoopQlDorqfC8Ky9nGKD4AOQj5QTm+6q6NgAgq4TUdv8auqOiHDr/b+WwVsKbIbE 6F8hqKlugQJfwPlNe833son7e2xPGXL+KCFNYvgvPFVov6K1HdvIV6UV7iRl6BC5vFl/ tJuaA2FNbsnAltBr5bo+qQa5/RtDxLLY9YSlFaNDtI2cWh62Xz3DkU4zhk/Bchy+hL+7 ZcwJ0N0LLUMJKIxxhVGhW341cbKbVDoE8RN8yNl0xgA3ikuR0nbwMFfbTFjjMCQfnyk9 H7Og==
X-Gm-Message-State: AGi0PuYrBzK0FRYuSpdOSSbMHuCIvYa9Il3GOSCkcIbl/JOir4W4VbJe UN6zJ3URKwVXkQV6i8TnLxrwiUpGjRHuDDgdClir1Lgk3m8=
X-Google-Smtp-Source: APiQypL5wChU2ra4g8bgPkKEls7CtbI3xCNhU2sVT+ctwnYh9x3NLzUJObAOu22A0bazvr0uKLlfLKI7dCOEHH5/OFs=
X-Received: by 2002:ac2:5b92:: with SMTP id o18mr19002902lfn.140.1588167818005; Wed, 29 Apr 2020 06:43:38 -0700 (PDT)
MIME-Version: 1.0
References: <CA+_8xu1uyyCeV_-YgrRfEOqkc3aapzKfGJMZJWqm+iMofbBzeA@mail.gmail.com>
In-Reply-To: <CA+_8xu1uyyCeV_-YgrRfEOqkc3aapzKfGJMZJWqm+iMofbBzeA@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 29 Apr 2020 06:43:01 -0700
Message-ID: <CABcZeBNg21wcrx4N_tqPe5ta2id56kEt50=rsG2WTUucqxycYA@mail.gmail.com>
To: research@bensmyth.com
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a2e41305a46e220a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/iRlKfMTjo_Dam4w7sR0IxdRq0eU>
Subject: Re: [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 13:43:43 -0000

Hi Ben,

Thanks for your note and for your efforts on the tutorial!

On Wed, Apr 29, 2020 at 5:43 AM Ben Smyth <research@bensmyth.com> wrote:

> 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?
>

I expect that the first response will be the ordinary one. However, in some
cases you will be forced to employ the second one because it is not
possible to send a SH. For instance, consider the case where the server has
been reconfigured and no longer accepts the DH group that the client
employs in the CH. In that case, it will have to send HRR.



> And why does the former rely on deprotecting, when checking record content
> types is surely more efficient?
>

Unfortunately, the record types are encrypted, and this will not work.

Best,
-Ekr



> (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 mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

v2.23.0 | Report a Bug | By Email