IETF Logo Mail Archive

Re: [TLS] 0-RTT encrypted data limits

David Benjamin <davidben@chromium.org> Thu, 01 September 2016 14:29 UTC

Return-Path: <davidben@google.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 52CB212D6A8 for <tls@ietfa.amsl.com>; Thu, 1 Sep 2016 07:29:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.247
X-Spam-Level:
X-Spam-Status: No, score=-3.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 PUtliuQV5VKS for <tls@ietfa.amsl.com>; Thu, 1 Sep 2016 07:29:12 -0700 (PDT)
Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (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 84FAE12D581 for <tls@ietf.org>; Thu, 1 Sep 2016 07:29:12 -0700 (PDT)
Received: by mail-it0-x22a.google.com with SMTP id e124so105749930ith.0 for <tls@ietf.org>; Thu, 01 Sep 2016 07:29:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ul7fZBjFCeMTT6nPgWo5TUw1dkb5V8SZ3sKZSVhw1Hc=; b=lv9SOmCsxC7QkysZ9puImZzJ2nPH0KGSadSXx34tF9QYtEm7IJDsOsDEm5T52WU2mB vNQDy1F8k0Vp3pwxUgCRXdhdSTtCwFTgYmuY3BtG2KgnwWX76tsa35+tMlcM8tF0QCpb f0sEQg5vxTrGLmjLw9YQYmMtLltn3R6+MmmKA=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ul7fZBjFCeMTT6nPgWo5TUw1dkb5V8SZ3sKZSVhw1Hc=; b=ZpB33CShkibK8H9yi4HolZPtwMqJlxUee/jKshIyjxahfxEhX9Y/cj9sPFjhE1QzjF vyKq/V55snhD+A4TmsQA0fls/l3IyVGtC+XLvH66WL2D5FnJqHzXyOERIooThaqur6zF qi/yzDtiRc+ppehaAIEjz/p5ga3Z3tItvb0FlyuIPMn2nf4sm3HH0Xb1t/wjZHQtTLuf jWMSLOWnvpyHltMTkkAhTm6Q+HU8AgIoieNAx6aSSZ9s3f9pH/nHgHpxHUnHtaA8yVdk PvZdwWY0L0HUVtM+Izrko7J1bmY/xD4Ez3fOyxkYHPOVkaLPfPOUcw8CZbvwlPhPF0FF H6og==
X-Gm-Message-State: AE9vXwM7GMb5SRH7WUaNHfoZ/eEWj4cyN6F6sdB+5ST/yWTNdXGqZCA0ZJx/+RDJC9cIWoCs+qY2c0xPAd1k+Dh5
X-Received: by 10.36.190.75 with SMTP id i72mr4205386itf.92.1472740151674; Thu, 01 Sep 2016 07:29:11 -0700 (PDT)
MIME-Version: 1.0
References: <6918283.boJRZ9WqjH@pintsize.usersys.redhat.com> <CABcZeBMOyM2v3gt69gHzfW7k5w=OwFqCUiER-bPERfNkLGhpWQ@mail.gmail.com> <6822534.tPWjKYA1SU@pintsize.usersys.redhat.com> <CABcZeBN_TPyYD63u4t41SKn-T6ugZdpxgM8i7-tJ82tU13+yUA@mail.gmail.com> <20160901131521.rjw3jebdjwwizp2z@LK-Perkele-V2.elisa-laajakaista.fi> <CABcZeBMUA8tzsPr_6pC6kRzhPifxuz4YjSRo1KB2V52SiGWstw@mail.gmail.com>
In-Reply-To: <CABcZeBMUA8tzsPr_6pC6kRzhPifxuz4YjSRo1KB2V52SiGWstw@mail.gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Thu, 01 Sep 2016 14:29:00 +0000
Message-ID: <CAF8qwaCwqydWk30875=p1p2NkK+Ju+NtVL6meybYESN6GxCSJw@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>, Ilari Liusvaara <ilariliusvaara@welho.com>
Content-Type: multipart/alternative; boundary="94eb2c196fb896904b053b730916"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/B45jReRCiVPeqYfG9Lv1IO0FlwU>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] 0-RTT encrypted data limits
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 01 Sep 2016 14:29:15 -0000

On Thu, Sep 1, 2016 at 10:01 AM Eric Rescorla <ekr@rtfm.com> wrote:

> On Thu, Sep 1, 2016 at 6:15 AM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
>
>> On Thu, Sep 01, 2016 at 05:48:02AM -0700, Eric Rescorla wrote:
>> > On Thu, Sep 1, 2016 at 3:31 AM, Hubert Kario <hkario@redhat.com> wrote:
>> > >
>> > > I'm afraid that requiring the server to keep the connection open for
>> > > essentially arbitrary amount of time while it consumes garbage data
>> is not
>> > > unlike the Apache slowloris attack.
>> >
>> > It's not required to. It can close the connection at any time.
>>
>> Should there be recommendation for clients to cut transfer and send
>> Finished if the client receives EncryptedExtensions without
>> early_data extension?
>>
>
> I thought that was implicit, but i'd take a PR that did that.
>

(s/EncryptedExtensions/ServerHello/, but whatever.)

At this point the client must do much more than cut transfer anyway. It
probably should be phrased as starting over and retrying or so. Everything
sent has been rejected and all you thought you knew about the connection
may have changed, like ALPN. At sufficiently high layers, you should
probably just pretend you got a fresh connection and are repeating the
request (or whatever) from scratch.

In the general case, you may even need to bounce to a new connection.
Consider if our session was established with h2, we try to 0-RTT-resume it,
send 20 replayable HTTP requests across it... and only then to hear from
server, "Nope, no 0-RTT for you, try again. Oh, by the way, we're talking
http/1.1 now." At least 19 of those 20 requests must get fresh connections
anyway.

David

v2.23.0 | Report a Bug | By Email