Re: [TLS] PR for new negotiation syntax

Ilari Liusvaara <ilariliusvaara@welho.com> Wed, 03 August 2016 18:15 UTC

Return-Path: <ilariliusvaara@welho.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 46F9912D0B4 for <tls@ietfa.amsl.com>; Wed, 3 Aug 2016 11:15:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.187
X-Spam-Level:
X-Spam-Status: No, score=-3.187 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.287] autolearn=ham autolearn_force=no
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 HYIrV0wAIAt2 for <tls@ietfa.amsl.com>; Wed, 3 Aug 2016 11:15:36 -0700 (PDT)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 6A9CE12B00D for <tls@ietf.org>; Wed, 3 Aug 2016 11:15:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 6C12210598; Wed, 3 Aug 2016 21:15:34 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id y-JoEGfcd13M; Wed, 3 Aug 2016 21:15:33 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp2.welho.com (Postfix) with ESMTPSA id 45897283; Wed, 3 Aug 2016 21:15:33 +0300 (EEST)
Date: Wed, 3 Aug 2016 21:15:27 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Eric Rescorla <ekr@rtfm.com>
Message-ID: <20160803181527.GA31372@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CABcZeBMgDvw_Nt=Ev5nyEpdu_zWOg0ZFMLqgm19Qa=FTwvVnzw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CABcZeBMgDvw_Nt=Ev5nyEpdu_zWOg0ZFMLqgm19Qa=FTwvVnzw@mail.gmail.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/QwiwVwN1x0xr9yhUwCt1VFsSIqg>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] PR for new negotiation syntax
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: Wed, 03 Aug 2016 18:15:39 -0000

On Wed, Aug 03, 2016 at 08:30:22AM -0700, Eric Rescorla wrote:
> Folks,
> 
> As promised, I've written a PR that describes the new negotiation
> syntax we discussed in Berlin. I also have prototype implementation of
> this in NSS and it's quite a bit cleaner than the previous negotiation
> design. I think that others have found the same thing.

Yup, looks much cleaner.
 
> https://github.com/tlswg/tls13-spec/pull/559
>
> IMPORTANT: This new negotiation syntax allows for two modes that were
> not previously available with TLS 1.3: PSK and PSK-(EC)DHE with
> server-side signatures. This construction should be safe with
> resumption-PSK (this is why we introduced the resumption_ctx design),
> but as noted in Antoine's recent message [0], this is not safe with
> non-resumption PSK with the all-zeroes resumption context that we now
> use with external PSKs. I have an action item to fix that, so just
> keep that in the back of your head as you review this PR.

The idea is to essentially use "resumption master secret" as PSK
and then to derive the two subkeys off that on handshake, right?


Also I noticed that now there is no indication on if the group
indication in HRR is valid or not (pure-PSK). Dirty hack would be
to grab some reserved value (FF01?) for "I don't need any more
groups" (which isn't the same as "no group"). Or perhaps one could
stick it into extension[1].


Also, now that there are signatures even with 0-RTT, one should recheck
the 0-RTT extension checking logic (the original logic is now invalid,
but I think conclusions[2] for free certificate case are still valid).

However, if the thing does not use free certificates (in which case
the logic should absolutely be specified, or one WILL get massive
interop problems!) the conclusions definitely are not valid..


[1] One design would be to move group to extensions, rename
'extensions' to something like 'problems'. Then require 'problems' to
be non-empty and require clients to abort if they see problem types
they don't recognize (but problem types don't need to be advertized).


[2] The original conclusions were that out of extensions, only
server_name and application_layer_protocol_negotiation matter.



-Ilari