Re: [Cfrg] tcpinc: endpoint authentication and session ID privacy

Kyle Rose <krose@krose.org> Thu, 10 November 2016 21:52 UTC

Return-Path: <krose@krose.org>
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99663129558 for <cfrg@ietfa.amsl.com>; Thu, 10 Nov 2016 13:52:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=krose.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 KqcBhphUWS8G for <cfrg@ietfa.amsl.com>; Thu, 10 Nov 2016 13:52:34 -0800 (PST)
Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (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 D6D8B129566 for <cfrg@irtf.org>; Thu, 10 Nov 2016 13:52:33 -0800 (PST)
Received: by mail-qk0-x236.google.com with SMTP id q130so314293730qke.1 for <cfrg@irtf.org>; Thu, 10 Nov 2016 13:52:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=krose.org; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=BIXdbbmhAmgN5mylk9u83TqlpuQmVU7w+bTIRQ/CyNU=; b=O+e/+wtXO3T8YMiZ8Ulx+ltYqWs7vmBWOIh9EckXodY81QgWNnUJz78xMw85/j3Y1N i9t3Fkl/+UIrS/JxGE9ifjxh+uYCBr/VdBNgC2jlz2F4iLT3WGCteseSxp6n6zYT3BHU wiRwuQgWw9WbD7Hc/PXfs6w+QYtQrT6CjOCCI=
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=BIXdbbmhAmgN5mylk9u83TqlpuQmVU7w+bTIRQ/CyNU=; b=h2JtVMM4PEyOmVac+5eHMnlqVljwf1TBdOSmH4bIhwZaD/eTlZ9+iKuaP4i8s3zSg/ Y3+m9ChJ6/2MDulhSpMfHFAwMPQOLYIfqyoTAOHPLpuOveKt3+AStj655YhnBgDZrOhI RPXeTTTanov0yPUnEncLcXw+xRdQxFnh3eAMHOYv8VleyjynymMSe7NyTto3I6eFBt8e SaiFybR3T1tap24G6E60IyOFPQMY/T7Nd8fMgqOQsYA0QPcSheOBNyjz3KFBEpCgKdKA 9sbmXTTEIj23h2VkgRxp44lWZOWusfCtyw6tgRiO67hbq/vSzPI+sD1qX8wRBGrDuRks Uqxg==
X-Gm-Message-State: ABUngvfIU3E911m88bW26K+FqcvaCRJDIaPMdQYHhyUm0I2mtP8ay1eY16GgCKX3eLsgo3tfdzgfoIvC/fJcKw==
X-Received: by 10.55.24.36 with SMTP id j36mr8967419qkh.268.1478814752923; Thu, 10 Nov 2016 13:52:32 -0800 (PST)
MIME-Version: 1.0
Received: by 10.55.180.2 with HTTP; Thu, 10 Nov 2016 13:52:32 -0800 (PST)
X-Originating-IP: [88.128.80.101]
In-Reply-To: <20161001171651.GA8138@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CAJU8_nXtwpe1_8UpKtKnG3fmpMWuMW7Zcj6SzPAnZ9jmJi9T2g@mail.gmail.com> <a78ce42cf3504cbbb35735b0f45bc43b@usma1ex-dag1mb1.msg.corp.akamai.com> <CAJU8_nXXTVYCu+wt5QJ1RZiuqzparFwvQ33J55E-SaLhuZ6GoQ@mail.gmail.com> <20161001171651.GA8138@LK-Perkele-V2.elisa-laajakaista.fi>
From: Kyle Rose <krose@krose.org>
Date: Thu, 10 Nov 2016 16:52:32 -0500
Message-ID: <CAJU8_nWD-u5WauftE795z-D-=LL=mJC=SOCyDXctaZgNJGURBw@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Content-Type: multipart/alternative; boundary=001a11429ba2097b880540f96428
Archived-At: <https://mailarchive.ietf.org/arch/msg/cfrg/jhIhh3UoCQ4t-DdHof_NgHIjemU>
Cc: cfrg@irtf.org, tcpinc-chairs@ietf.org
Subject: Re: [Cfrg] tcpinc: endpoint authentication and session ID privacy
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Crypto Forum Research Group <cfrg.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/cfrg>, <mailto:cfrg-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cfrg/>
List-Post: <mailto:cfrg@irtf.org>
List-Help: <mailto:cfrg-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/cfrg>, <mailto:cfrg-request@irtf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Nov 2016 21:52:36 -0000

Apologies for the 6-week RTT. Now that I'm stuck on a 14 hour flight, I
finally have some time to get through the email backlog.

On Sat, Oct 1, 2016 at 1:16 PM, Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> On Sat, Oct 01, 2016 at 12:31:31PM -0400, Kyle Rose wrote:
> > No: a session ID is to be used on one connection only, with a key
> > derivation algorithm used by both hosts on secret IKM to derive future
> IDs
> > for session caching/reuse. See sections 3.3-3.4 of the tcpcrypt draft for
> > more information on how these identifiers are derived.
>
> I tried reading the relevant sections, and noticed that if SID[i], for
> i>0 gets disclosed, one can correlate the resumption attempt.
>

Not quite sure what you mean here. SID[i] is defined as

SID[i] = CPRF (ss[i], CONST_SESSID, K_LEN)

where ss[i] is secret for all i, ss[i] chains off ss[i-1], and where ss[i]
is used as the IKM for further key derivation within the connection
identified by SID[i]: in particular, I think I'm claiming that there's no
computation that gets you from SID[a] to SID[b] for a != b. Depending on
CPRF, they may or may not be indistinguishable from random to an observer
without knowledge of the inputs, but they should have no correlation with
each other. So if you reveal SID[a] in one resumption attempt and then
SID[b] in a different resumption attempt, that by itself shouldn't help an
observer correlate the attempts.


> But I presume that the SID value used for identifying the connection is
> SID[0].
>

A client is supposed to use a particular SID[i] for resumption once only,
and then advance to SID[i+1] for the next resumption attempt; and both the
client and the server should securely erase ss[i] from memory once it is
used to resume a session on a connection so SID[i] cannot be used for
subsequent resumption attempts.


> Also, the computation formula for PRK has concatenations. One needs to
> be careful with concatenations: The components must be uniquely
> parseable from concatenation.
>

Agreed. We think tcpcrypt is okay on this front. In particular:

(1) eno-transcript is uniquely parseable despite being of variable length
because it incorporates the length via the TCP option length byte, as noted
in section 4.8 of the TCP-ENO draft.

(2) Init1 and Init2 similarly incorporate the message length.

(3) The length of ES doesn't matter given its placement at the end of the
input, and while its structure is kex alg-specific, any collision here
could occur only if bytes earlier in the input corresponded to a different
kex alg: IOW, for a given kex algorithm, it will uniquely parse.

Kyle