IETF Logo Mail Archive

Re: [TLS] 0-RTT and Anti-Replay

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Tue, 07 April 2015 06:11 UTC

Return-Path: <ilari.liusvaara@elisanet.fi>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E9661B31EB for <tls@ietfa.amsl.com>; Mon, 6 Apr 2015 23:11:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 ENRqTBoKXpmJ for <tls@ietfa.amsl.com>; Mon, 6 Apr 2015 23:10:58 -0700 (PDT)
Received: from emh07.mail.saunalahti.fi (emh07.mail.saunalahti.fi [62.142.5.117]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EC531B31E5 for <tls@ietf.org>; Mon, 6 Apr 2015 23:10:58 -0700 (PDT)
Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh07.mail.saunalahti.fi (Postfix) with ESMTP id 76610402E; Tue, 7 Apr 2015 09:10:55 +0300 (EEST)
Date: Tue, 07 Apr 2015 09:10:55 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Watson Ladd <watsonbladd@gmail.com>
Message-ID: <20150407061055.GA5404@LK-Perkele-VII>
References: <CABcZeBP9LaGhDVETsJeecnAtSPUj=Kv37rb_2esDi3YaGk9b4w@mail.gmail.com> <20150406120554.GA23058@LK-Perkele-VII> <CACsn0c=wDP4hUGB73rSuHY5zsw8pOXvYgMOr6GW5ew_m7eCiAg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CACsn0c=wDP4hUGB73rSuHY5zsw8pOXvYgMOr6GW5ew_m7eCiAg@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/MouPMv0oojM4vqmCrwBup6oMfng>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] 0-RTT and Anti-Replay
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Tue, 07 Apr 2015 06:11:00 -0000

On Mon, Apr 06, 2015 at 10:38:18PM -0700, Watson Ladd wrote:
> On Mon, Apr 6, 2015 at 5:05 AM, Ilari Liusvaara
> <ilari.liusvaara@elisanet.fi> wrote:
> >
> > Also, regarding security considerations due to replayability, would
> > "MUST NOT authenticate in 0RTT data" (which e.g. means cookies that are
> > possibly authenticating can't be sent)  be useful consideration?
> 
> Only if we don't guarantee that the person who sent the 0-RTT data is
> the same person who carries out the rest of the connection. This seems
> possible, but I don't know what the right definition is.

The problems here are:
- 0RTT data is replayable (seems there's no way around).
- You can't wait for confirmation (connection reaches normal application
  data capability in 1RTT).

Also, in order to client replaying 0RTT not be able to negotiate
with replayed 0RTT data, one needs client finished type message, or
0RTT key needs to mixed into session key[1] + encrypted message
from client.


The corresponding consideration in server earlydata is "MUST NOT be
confidential.", since it is sent to unknown recipient.


[1] "unified DH-based key exchange" does not get this right, this
input is independent from ES input in late key exchange.


-Ilari

v2.23.0 | Report a Bug | By Email