Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)

Tom Ritter <tom@ritter.vg> Tue, 11 October 2016 13:29 UTC

Return-Path: <tom@ritter.vg>
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 4D57B1294CB for <tls@ietfa.amsl.com>; Tue, 11 Oct 2016 06:29:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level:
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ritter.vg
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 VLRtoM1oRDLh for <tls@ietfa.amsl.com>; Tue, 11 Oct 2016 06:28:59 -0700 (PDT)
Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 5555A126B6D for <TLS@ietf.org>; Tue, 11 Oct 2016 06:28:59 -0700 (PDT)
Received: by mail-io0-x22f.google.com with SMTP id j37so24306221ioo.3 for <TLS@ietf.org>; Tue, 11 Oct 2016 06:28:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=79AEfESZrwpwnwM7/xpMCiHHWJBCCJ7OjYoVYJcBprQ=; b=M4fbciwkNvbjUkH4D+MgbrmTVXmIa9aHzyucXdrThwCoML4kz5PhqxGEhk7O8EWIx7 sxK0RD1zOpbUmACYeJmEXRWxeCErE1BjeWkWGotpwsErV8CA32PoM5DnIUL73bgdWEcR 6Tzu031vXrpi24BoNzRIM+AHxY444w1vAic04=
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=79AEfESZrwpwnwM7/xpMCiHHWJBCCJ7OjYoVYJcBprQ=; b=dsF5Vmd4nz6NkbkDuOM5gk6SWARDyC9JJeAm+9ubIbvoN/Yw6iLBVUtmBIFeMkf+cv yWKIr/yMomDL52tbOSNTN4niHFUEgnKhQzG5uak/pAbnamPA2WnX39WDe7RBdXetFEtS a5HxrlFpn8aqX6D9FkkAcXlc0yDOFU/x/pLOtPyiNer7bb57hn2MUTtS7d8knS0XUrtg qk8EFM3InIi8BksNfwY7VxBSrQ3PVPRU32d9MrQoSHLSG+W89YbPwIxg6asTYU9rmeOn EbNeQtyOB+8SODgTaiEIWuo0vo4ft1pFXdYgbggyVwjqgaifmZR8Z1IfM6AWUVY3EvK/ 4Lxw==
X-Gm-Message-State: AA6/9RlyGHTw/5KhBTKXK0cV2Ps0fNkFiqkyzg+la23ZJh3+6SjMZotvPuQYJcWw0W8OnoWF1mQzrP5LlxNTybZ5
X-Received: by 10.107.63.215 with SMTP id m206mr6020268ioa.56.1476192538655; Tue, 11 Oct 2016 06:28:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.132.100 with HTTP; Tue, 11 Oct 2016 06:28:38 -0700 (PDT)
In-Reply-To: <CABcZeBPq6ujA5iA9aLFS6fC6Jgus-SFJ5E3r_4TQ=ufMhqCdaw@mail.gmail.com>
References: <CAOjisRznhk-Fww=EnRg7zXO-zaHWyNgi0g+reRBj+y3ZOhwMhw@mail.gmail.com> <20161008090257.GB10692@LK-Perkele-V2.elisa-laajakaista.fi> <CAF8qwaC4qoUqf=f6yKgfk6RAy1odcvDeMWFntMMXQ6TbJXFsYQ@mail.gmail.com> <CAOjisRwcoToEUxfTDF_Mcb3bekqT-b9cHv5M-G8Wvy5h+yfY7A@mail.gmail.com> <CABcZeBPq6ujA5iA9aLFS6fC6Jgus-SFJ5E3r_4TQ=ufMhqCdaw@mail.gmail.com>
From: Tom Ritter <tom@ritter.vg>
Date: Tue, 11 Oct 2016 08:28:38 -0500
Message-ID: <CA+cU71n_bdTxBoCHyPFPgHfyh2kg24wSXbzM=HWwaLmuTYuh-Q@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/8A3wHmU-azUUououByM1YFIWpP4>
Cc: "tls@ietf.org" <TLS@ietf.org>
Subject: Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)
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: Tue, 11 Oct 2016 13:29:01 -0000

On 8 October 2016 at 11:54, Eric Rescorla <ekr@rtfm.com>; wrote:
> I could go either way on this. It seems like this pushes complexity from the
> client to the server.
>
> Consider the case of NST. Presently, a client which doesn't want resumption
> can just ignore NST,
> but in your proposed change, the server needs to read this extension and
> then conditionally send
> NST, and the client still needs the logic to detect unexpected handshake
> messages and abort
> on them.
>
> As I said, I could go either way, and I do think it's potentially useful to
> be able to say "I won't do
> post-handshake client auth" and even more useful to be able to say "I would
> do post handshake
> message X which will be invented in 2018" (but of course we can register an
> extension for
> that then), but less useful to say "I don't like NST or KU"


I'm concerned about the information this exposes on the wire. We've
added Record Content Type protection, so things like post-handshake
client auth can't be detected on the wire (modulo behavior/length
attacks, for which we can attempt protection with padding.)

But now we're going to say in the client's plaintext "Yea, I might
want post-handsake client auth".  And it seems like the percentage of
clients who will say that will be few and far between... leading to
more fingerprinting and a step back from where we were.

-tom