Re: [TLS] Interaction between cookies and middlebox compat mode

Eric Rescorla <> Wed, 27 December 2017 19:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 033FF1275FD for <>; Wed, 27 Dec 2017 11:34:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id dTx_CyG0wL01 for <>; Wed, 27 Dec 2017 11:34:15 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 26CEF1275AB for <>; Wed, 27 Dec 2017 11:34:15 -0800 (PST)
Received: by with SMTP id q26so7851826ywa.6 for <>; Wed, 27 Dec 2017 11:34:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SvW8Ey6rl90X7r6QnsW+gbDYn53SRJU2skfX/xlxyOM=; b=gU0YMrQU8QliDCCXW+tdgjlPQCSRiHZIvwyPnNSZT+t+BgIK6P0DdGBfQYtdoVvMaE v2zIIfa92P2kufVsX5NeaX489MufUJSqekct2f0bCT1CrYHwOrPmIqWYElR7KwHF504i Rbpo082r8pJ/06BDxazdv20m3W/xC3ysTpuAtyeRpS00xENUk9siAt7DibGm88ZfXEZP t4k8WHha0QN4V3AQNoypbNXHLWZ+OVyeL6D5bmQFYainD7j7qo1EH/nswyvOwRGLEYYW zGRjlBJFoA1EgU/Wioj+U4SdWBFq+0ygh0MxW0rFa6fszlUUUHcQWdEO73c/wcfTKxso xVpw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SvW8Ey6rl90X7r6QnsW+gbDYn53SRJU2skfX/xlxyOM=; b=KAWrsGSkDVMPtbRQnPHuFZeA2Bght9ibdoUF0vx6i5QAt2EcTVYabZ2kLJ40jrLObf GQgEGcuqdkKYPZvX1oAnEC3FZPoKijZIuksNWj9pjnnOP6osH0zO1k8UD8PxgsRPhhBC 8j5ogDtWjtp+XA2LT7b8/Xj/Gm+nZPIVe8yyj/lk9cjAQxtLYNks5nf7KpXuzAvSBHQH MMUskHdLgLdFuiODRdz999G+z0WQ1VWdjUP4hNRXyOquFrJG17Atl4QfK4lNKXbQJA/I jILmHEZvSH8UujvhQWD9RNU2fwW9YO2bmugw+cKfp6cjtv8gG+n91EhgnoYQoeiYtgf8 kkHw==
X-Gm-Message-State: AKGB3mKa7k7D7QLX5mGgetQUJeih2SsS5ODYYGscP9SUvLuFMC1osFZ8 U0lXndcgVLnvw2r0cm5fO5AYbkLi5PcGPT3N89FgxUpD
X-Google-Smtp-Source: ACJfBovptMNWzasyyem9Py/o25v+yb1fbdCZfilWMU4mT+wRoiRd/EZI9IngrwbjWPMyhNna4Hdhm1d6SKO6TfTTaHg=
X-Received: by with SMTP id j189mr19819633ywb.504.1514403254283; Wed, 27 Dec 2017 11:34:14 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 27 Dec 2017 11:33:33 -0800 (PST)
In-Reply-To: <>
References: <>
From: Eric Rescorla <>
Date: Wed, 27 Dec 2017 11:33:33 -0800
Message-ID: <>
To: Matt Caswell <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="001a113f169e04c2390561577cff"
Archived-At: <>
Subject: Re: [TLS] Interaction between cookies and middlebox compat mode
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 27 Dec 2017 19:34:17 -0000

On Wed, Dec 27, 2017 at 11:17 AM, Matt Caswell <> wrote:

> Consider the scenario where a server is operating statelessly (i.e.
> using the cookie extension) and a client is operating in middlebox
> compat mode.
> In that case the client sends an initial ClientHello and receives a
> ServerHello(HRR) back with a cookie in it. Before it sends its second
> ClientHello it first sends a dummy CCS.
> >From the server perspective it is operating statelessly so until it gets
> a ClientHello with a valid cookie in it, any message it receives is
> considered the "first" one. Therefore, because the server has forgotten
> about the initial interaction with the client, the first message it sees
> is a CCS.
> Draft-22 says this:
>   "An implementation may receive an unencrypted record of type
>    change_cipher_spec consisting of the single byte value 0x01 at any
>    time during the handshake and MUST simply drop it without further
>    processing."
> Does "any time during the handshake" include the very first message it
> receives? If so then this has implications for servers that accept
> connections from TLSv1.2 (and below) clients (regardless of whether the
> server is stateless or not), i.e. an incoming connection that starts
> with a CCS and then goes on to negotiate TLSv1.2 would be accepted which
> seems odd.
> If it doesn't mean that then a stateless server will receive a CCS as
> the first message and not know how to handle it.

The way that NSS handles this is to remember that the CCS was received
and then if it turns out that you negotiate TLS 1.2, you throw an error in
that case. With that said, in most of the cases where you are stateless,
you're probably going to want to ignore bogus records anyway, which would
include unexpected CCS.


Maybe there are different rules for handling CCS for stateless servers?

Or perhaps middlebox compat mode should never be used in a scenario
> where a stateless server is being used (e.g. QUIC). Either way it seems
> that some clarification of the wording would help.

> _______________________________________________
> TLS mailing list