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

Eric Rescorla <ekr@rtfm.com> Thu, 30 April 2020 13:05 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 AF22C3A091D for <tls@ietfa.amsl.com>; Thu, 30 Apr 2020 06:05:26 -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 D1cmi-p0JCO4 for <tls@ietfa.amsl.com>; Thu, 30 Apr 2020 06:05:24 -0700 (PDT)
Received: from mail-lj1-x236.google.com (mail-lj1-x236.google.com [IPv6:2a00:1450:4864:20::236]) (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 756703A0936 for <tls@ietf.org>; Thu, 30 Apr 2020 06:05:24 -0700 (PDT)
Received: by mail-lj1-x236.google.com with SMTP id f11so6431130ljp.1 for <tls@ietf.org>; Thu, 30 Apr 2020 06:05:24 -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=Xqgh8cuYjZ+z5gqcAKSa9icp5BgjMhiR4ORAs6cR66o=; b=11ed5jskiNxCmCeqeaTva4KhVsdggWXMLc1RMWkMXtAPgYxetnuYFG0GkevMdTABbV 6BLHQE+ivYby10mMxlo8fn4241nbW4Pcro5ZINSpsnrGoYrEUjLwmVFqiSY3aJCVJgO6 1RcoLNiExy6e3uFeh/U4fN6oBK0ZMT2wPCjSUAEnQEcXXoe4/XiGwIycqMs1frDMM6yP +gYWrjcO6GdKDv6DXOzOjXuTcWGnzpwo6X4foH7hnUhGllDL6FZ+OzY4b2d3vSvCE3cM Ztu3jUxRIz3fJmxoXjWEoeugGUnbAt75NKMNOaaHk1eZ/rgHu80qhjqO2MQcBwYjwBxz x9ag==
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=Xqgh8cuYjZ+z5gqcAKSa9icp5BgjMhiR4ORAs6cR66o=; b=jBoQ2DPi3YCevoNEqLp+qgocO3MEpmzVq2sOLWFA60lIxp9o9dtGnec68lbbyDRYre WCowOJsDXC/Z4xwFIDruBEUXeRIoHBNbhTBwI/ee0CyCRXqjENMZievmkog23nvtgjjO 11QExxhlFHdMHmx7GBSeavdUHB0j5R2e0GX6CImkQcY6B6FGoUUkU1IdSizZq5fXV1Lr VOPloOqchhRPfFp1aR7aWUrvXn/Ggej9VdC+09i4cJvveFsYOdc0xG2nwN2qITCjvifW qun0HRLlodthfeLseG+JzkpT1yJtOPGZWWZxxMeuQnoewtofa0ny0mEJreYqZypeTc12 Q9vQ==
X-Gm-Message-State: AGi0Pua5Qf1STFXbimPAvG/1iIq8uL4bqlgDk39ZtXm5wKmNP+avmRkG ioSy3tmphsTjEUsyye6wWhRq+zxQLtWE6MVFoBjg3PWow28=
X-Google-Smtp-Source: APiQypIyyDWR5YyxhqF6Hxbirn+xsAQuzXhLtWZJP29iiTvhJllDqrRgDQWt8il9VmKPYHnDJbVBODtR4tpsI2EDzI0=
X-Received: by 2002:a2e:2414:: with SMTP id k20mr2145541ljk.162.1588251922520; Thu, 30 Apr 2020 06:05:22 -0700 (PDT)
MIME-Version: 1.0
References: <CA+_8xu1uyyCeV_-YgrRfEOqkc3aapzKfGJMZJWqm+iMofbBzeA@mail.gmail.com> <CABcZeBNg21wcrx4N_tqPe5ta2id56kEt50=rsG2WTUucqxycYA@mail.gmail.com> <CA+_8xu33UcnvYV40-vSx=CAiDZNO2A0rLPBcoa6cy1tufYZJCw@mail.gmail.com>
In-Reply-To: <CA+_8xu33UcnvYV40-vSx=CAiDZNO2A0rLPBcoa6cy1tufYZJCw@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 30 Apr 2020 06:04:45 -0700
Message-ID: <CABcZeBNocGGTpJPyz=MEozrdTrSTwyXm-6=Vs4ty53yy_nAeGg@mail.gmail.com>
To: research@bensmyth.com
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000a7e81805a481b72e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/9F6avEjrVbZVQZWVMQbSx22_wT0>
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: Thu, 30 Apr 2020 13:05:27 -0000

On Thu, Apr 30, 2020 at 2:46 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.
>>
>
> SH and HRR are simply used in their usual ways: Thanks for the
> clarification.
>
>
>> 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.
>>
>
> (I meant the external content type. But, that doesn't work anyhow.)
>
> I have now understood:
>
> When not consuming early data, respond with SH or HRR. For the former,
> given that all messages will be encrypted, the server must decrypt messages
> with the handshake traffic key, discard messages when decryption fails, and
> treat the first successfully decrypted message as the client's next
> handshake message, thereafter proceeding as if no early data were sent. For
> the latter, the second CH message will be unencrypted and the server can
> discard all encrypted messages (identified by record type 0x23, rather than
> 0x22), before proceeding as if no early data were sent when the second CH
> is identified.
>

Yes.

-Ekr


> Thanks for your support,
>
> Ben
>