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

Eric Rescorla <ekr@rtfm.com> Thu, 28 December 2017 17: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 1906E1243FE for <tls@ietfa.amsl.com>; Thu, 28 Dec 2017 09:43:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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_NONE=-0.0001, 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 meZ9WD-yaxAi for <tls@ietfa.amsl.com>; Thu, 28 Dec 2017 09:43:09 -0800 (PST)
Received: from mail-yb0-x22b.google.com (mail-yb0-x22b.google.com [IPv6:2607:f8b0:4002:c09::22b]) (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 2098C126DC2 for <tls@ietf.org>; Thu, 28 Dec 2017 09:43:09 -0800 (PST)
Received: by mail-yb0-x22b.google.com with SMTP id f16so664560ybn.0 for <tls@ietf.org>; Thu, 28 Dec 2017 09:43:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=s4BqBOlm51V63Okxnyl68V7E9rSV3PzPuyqflMaX16E=; b=sSMd8FrchKdm0HnYkWD6vTaUliIOq+NQvayZR7YZ8Ae3LL529SyEKRGZy79uuHyqNu n3zezEy7JpuiLuqh4c3xixVOyhlVxbWQTm7iSabp2CBHSNHf3QDO1O5bN6Ee7lga/65/ L0y2NaN6O0nOr4x0dFFH79f87kcwZ4RCusQzTpu68dhSftzCRvIshY6hKfpwuU+m0QLI 6G6tUDw7mDkVK+bzpZS5KxWstEMke2RUfN6TfrL+zFRM3xHPDwPChGHkjj/bdu3OVtek QK/iKc4iU53aom8fLOSOVPyip4X+TMd7alxiijEXcA/XqBGt/cuuqzETklrRRTKo1EZL f8bg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=s4BqBOlm51V63Okxnyl68V7E9rSV3PzPuyqflMaX16E=; b=rPDA4cYacUGobk+BeZ4eJ+oGw9W71TWTrVA4Us3ZQVIgMi40DEoYdrd7GWHOX/UznO 9PAep/FAEU06FoFnmA6uQZ2/3X7RBVyqo1/DCHD1xg6sOBrsCjoXQwyb+Cf+y+RDkJl5 GwD1vU/S+UDDagicz6qKaqDljK0wbt9a3ufSJbSgCOe9Zsi6AZQa0KDdKVOuxMWWtf5K R9gsnCj/lu5vH+Vg/CnVHSlR26mvz7eWPVLTiwUuWQA5np9gwrCcRtHNVUBx5xeaQPeq yda2trk69T2YAxtkXHZvtIBhJS3isBJnXi8zC6WoHV/4Y6Hya1WW6k8B/5wXxeVAq4MX Q/Hg==
X-Gm-Message-State: AKGB3mL174gWD4wbcDG26y/sv1EUi/tQw1wsDuxze7Jf5W84IM09aBSe VrDaUPdJHJvvUXw2m4ie//UmE9LhoeIrJNj/MqedMmm/
X-Google-Smtp-Source: ACJfBotnOOS0v/VEsySUhOneStY7WHl13z5PjRF81zfvxuBZwVvie+c9WBI+nzo2vKT9+c9e0DwgtoBLZ3SswqRrOwA=
X-Received: by 10.37.134.137 with SMTP id z9mr7292098ybk.497.1514482988023; Thu, 28 Dec 2017 09:43:08 -0800 (PST)
MIME-Version: 1.0
Received: by 10.129.123.132 with HTTP; Thu, 28 Dec 2017 09:42:27 -0800 (PST)
In-Reply-To: <4c37d15e-7375-d4d0-62d1-c6d295fb7080@openssl.org>
References: <9a7b1178-f856-ec63-c4b7-e2b29993e133@openssl.org> <CABcZeBMS9TeR-kFem4xHiWGVyKn5LbvDomdzL6vV_3XrKkravQ@mail.gmail.com> <37a087f4-efbe-7eae-5539-d220ff67e243@openssl.org> <CABcZeBOfcKTDnc+FcTPutMazSEhg3V8_tWqzeqpv=N6ki9jN9g@mail.gmail.com> <4c37d15e-7375-d4d0-62d1-c6d295fb7080@openssl.org>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 28 Dec 2017 09:42:27 -0800
Message-ID: <CABcZeBNii93boJJBKehxiHa8DZng4FyRZXhu0qD-jx_snzFdvA@mail.gmail.com>
To: Matt Caswell <matt@openssl.org>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="089e082608f08514a505616a0c91"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/-GuA1dE8oxg1jI_kGineJrAShlY>
Subject: Re: [TLS] Interaction between cookies and middlebox compat mode
X-BeenThere: tls@ietf.org
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." <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, 28 Dec 2017 17:43:12 -0000

On Thu, Dec 28, 2017 at 8:12 AM, Matt Caswell <matt@openssl.org> wrote:

>
>
> On 28/12/17 12:28, Eric Rescorla wrote:
> >     I think it would be helpful
> >     to be more explicit in the text if that is the case, i.e. identify
> the
> >     first point in the handshake and the last point in the handshake
> where
> >     CCS is valid. There probably should also be some words about how
> servers
> >     implementing older TLS versions should handle a CCS that comes first.
> >
> >
> > I could add those.
> >
> >
> >     However, I'm concerned about the added complexity of interpreting
> things
> >     that way. Suddenly a CCS arriving is no longer handled by just
> dropping
> >     it and forgetting it - you now have to store state about that and
> >     remember it later on in the process in other TLS versions. The CCS
> >     workaround was supposed to be a simple no-op to implement and it no
> >     longer appears that way in this interpretation.
> >
> >
> > Well, it seems like the issue here is you want the client to send CH1,
> > CCS, CH2
> > so we need the server to accept that. Am I missing something?
>
> The point is a stateless server will not know about CH1 at the point
> that it receives CCS.


Well, sort of.

Specifically, there are three valid things that a server (whether stateless
or stateful) can receive:

- CH1 [I.e. a CH without a cookie]
- CH2 [i.e., a CH with a cookie]
- CCS

It should respond to any other message with an alert and abort the
handshake.
A stateful server should also tear down the transport connection, so that
subsequent
messages are considered an error. This obviously isn't an option for a
stateless server,
so, yes, a stateless server might in principle receive arbitrary amounts of
junk
before CH1 or between CH1 and CH2, and it would still survive, albeit by
sending alerts.



> Actually, as Ilari points out, there could be any
> junk (including partial records) arriving between CH1 and CH2. So this
> feels more like a special case for stateless servers.
>
> In other words I would prefer to say that a CCS that arrives first is
> not allowed. That simplifies the general case and requires no special
> coding for servers implementing older versions of TLS.


This issue only seems to arise for people who are both doing TLS 1.3 and
TLS 1.2 *and* doing stateless implementations, which is kind of an odd
configuration because a number of the conditions in TLS 1.3 that involve
HRR (and thus can be stateless). It doesn't arise for QUIC (because no
TLS 1.2) and mostly doesn't arise for DTLS (if you reject all kinds of
junk).  Or am I wrong?


However, we add
> additional words around what stateless servers do with "junk" they
> receive that doesn't look like a ClientHello (i.e. they ditch it). That
> "junk" would include a CCS. That seems like a much cleaner solution.
>

I'm not enthusiastic about this, as it entails not alerting in cases of
clear
protocol error.

-Ekr




> Matt
>
>