IETF Logo Mail Archive

Re: [TLS] PR ¤468: Cookie for hrr

Eric Rescorla <ekr@rtfm.com> Sun, 22 May 2016 14:49 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 A0BF912D0AE for <tls@ietfa.amsl.com>; Sun, 22 May 2016 07:49:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
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: 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 9UVrLweZQuiY for <tls@ietfa.amsl.com>; Sun, 22 May 2016 07:49:53 -0700 (PDT)
Received: from mail-yw0-x22c.google.com (mail-yw0-x22c.google.com [IPv6:2607:f8b0:4002:c05::22c]) (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 14E1912B069 for <tls@ietf.org>; Sun, 22 May 2016 07:49:53 -0700 (PDT)
Received: by mail-yw0-x22c.google.com with SMTP id c127so33151429ywb.1 for <tls@ietf.org>; Sun, 22 May 2016 07:49:53 -0700 (PDT)
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=E3Mms8prBpCRjV4k8uFKJhFhDKEjElsyJ87UUuzkGM0=; b=D727Iy/18aVQsc16LOgmw0mYUXX3BKzB8ENU2PwXgS7sw5QF7hjUlprkhiSoSDcZ+A Bc4i7WQZkatuDQdFabGc1SSM2cujsSG2A5PdNewXAfFvU4yGHHmIWVz/uXMEyYkt3Sl5 M6a1gs4MjDY9pS0nzS+oZi7pUnBM/Su/gOoKAevN3RoS9pmAxtg5RhYn3RYmHMQfhL0c Xd8y0xMBIQo2yTRJ7zFd4fd7NymYNRIq8pxtT5QW1gXWPuW9StdXv0nBANPrXwxwVnDH nWWyctAiJBZdt9IsObibnzbWfOLNLP+qqTdSN6w8LymPhMyvW4bfe1cnXAUXbSWULFSI TbMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=E3Mms8prBpCRjV4k8uFKJhFhDKEjElsyJ87UUuzkGM0=; b=KieGEfi97d7hgmk9ayaE6ZOBG/86W+/aPFxiEks9+ZIbcd2lkV4uXQlHE92ef2yhjg lf0zLdgmv/QoKErTvnxCsqwjD4K2L3a8zMQxdWnyRG3scvmDY9oVYUGDLj3I/MfnFYR6 oGHr2LKAz8wgS5w9nQMuoWQN0vxcdw7d1cfs90c9/y0QbbeSUIkc4SnwqBq/r1Ca9COn fS+uYTqyjK1XgbKWZVqKnqWNYNfT3jOuPQ+L/w4KkWJN61w2ChYRcv+dINt7sGnswV85 JhiFUVOdHcCRYnxjrQOnOn8roIvjoML2RslHrw6wXE2Tb2Qe7k+t+09wicIR/9pPzf/m Stjg==
X-Gm-Message-State: AOPr4FXbVLhhpac6x9SbwKTgUVHDT6ohvdB7iG0+K+rZCWspZGeDf/FaWh0rMqyMsG6pnKr1mH0bEMfZFLVXlQ==
X-Received: by 10.129.163.146 with SMTP id a140mr7289060ywh.254.1463928592298; Sun, 22 May 2016 07:49:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.132.12 with HTTP; Sun, 22 May 2016 07:49:12 -0700 (PDT)
In-Reply-To: <20160522142212.GA17666@LK-Perkele-V2.elisa-laajakaista.fi>
References: <20160522142212.GA17666@LK-Perkele-V2.elisa-laajakaista.fi>
From: Eric Rescorla <ekr@rtfm.com>
Date: Sun, 22 May 2016 07:49:12 -0700
Message-ID: <CABcZeBPEQMJvBkb9kNvE4XeV8PyXoi=MchxrjPmmmYbJ8aXamQ@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Content-Type: multipart/alternative; boundary="94eb2c1287eeb8a0af05336f6f06"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/sXWlYsZw2BA_v9tuinl-fzHiGmw>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] PR ¤468: Cookie for hrr
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: Sun, 22 May 2016 14:49:54 -0000

On Sun, May 22, 2016 at 7:22 AM, Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> Looking at PR #468:
> - It isn't at all obvious how to use it for stateless rejection.
> - It is even less obvious how to recover (not causing non-retryable
>   fault) from bad cookie (e.g. expired) remembered from previous
>   connection.
>
> There are some tricks for both, but with latter, the 255-byte
> cookie space can become quite cramped...
>

I'll make the space biggeer.



>
> I think it would be easier if either:
> - Cookies could not be remembered across connections.
>

Yes, MT and I discussed this last night and came to the same conclusion.
I will make it so.

-Rk


> - HRR and EE cookies had separate slots those go to in CH.
>
> (Of course, neither of those solves the "failed 0-RTT" case...)
>
>
> Also, some clients do burst connects, where multiple TLS
> connections are connected in parallel. Through quite frequently
> these would be pure-PSK, keyed off one master GDHE-CERT
> connection.
>
>
>
> -Ilari
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>

v2.23.0 | Report a Bug | By Email