Re: [TLS] Refactoring the negotiation syntax

Eric Rescorla <ekr@rtfm.com> Wed, 13 July 2016 22:08 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 A00E412D8EA for <tls@ietfa.amsl.com>; Wed, 13 Jul 2016 15:08:28 -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 17FiagagVHSw for <tls@ietfa.amsl.com>; Wed, 13 Jul 2016 15:08:26 -0700 (PDT)
Received: from mail-yw0-x234.google.com (mail-yw0-x234.google.com [IPv6:2607:f8b0:4002:c05::234]) (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 AE58012D901 for <tls@ietf.org>; Wed, 13 Jul 2016 15:08:26 -0700 (PDT)
Received: by mail-yw0-x234.google.com with SMTP id i12so56065797ywa.1 for <tls@ietf.org>; Wed, 13 Jul 2016 15:08:26 -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=jG0indO/E2PTOJD8RFCJQLjm4wUpzAgXZgR1pf6P1DI=; b=SlhUAIyu4+ypZ5pWbJ0DDhcYVJNX2drREXgCp6PYct9GrCx6swCvccnvf1zQxRM+FL eAT5pSUO1YlDhKBtKJfOugTcpHm0+yOxWQO+z9pBHv0S8jdH/3DsUZSDpteide5KSz3K +yXXX8rRa3x09kvp/95vqzRJXOhDCv+UxL2GjrTalSSNvuhKW0wyu0vtbX3xWB96SAd1 s4smJGCwsdIgbDQVJ8PGpWSvT61WmXIv12bbi0Z4SJSb2b/2LnbniGRvpbZ/gT6ZkYrn TsXWuDVhVrsxE35fGhV67CgtyM4wYNmjCXMh7oOLUECg7OWT54h99Usf95Rd3SvlyYXm yhUw==
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=jG0indO/E2PTOJD8RFCJQLjm4wUpzAgXZgR1pf6P1DI=; b=ZCzmD4eKjE7OCy/a9tEs7QhMJsmI8N4cG+fn0cypDC3dnnNOfxvraD6OH0Ey9s/tEl mVSzHLD4JeiEBZX/wOVeICGMm8rns5vqsdUTZHaBPyDkSYf+JfC392JQX63qBgAKH7wx xDHFxHMR8ZDcfiSH3wG/rEH6EvrqLKnWppf6BxXv5kDSaKZdjfsqBIMrqoSpFpNb6Vil SWO/cLV8mJkHTxRe8RS1B1S0rlknR5vYNGqCBvtVYZiZ1tkHIo6AXknjk9TWSVpt8AeX HRKpnqsC9+x+0SgQd6qRiE28RwLMt+BC8b+KtnAhc0q2mmZMtAY6EJATnpDe2cVflY2m tFfw==
X-Gm-Message-State: ALyK8tKftIA2wKWHxUt9rh4sh0XZ36a3rd0C3GyI9r8NMERo1mrWOMsDw7XRK3jmCe2B7hiPXA1wKzTCYQW2BA==
X-Received: by 10.129.161.129 with SMTP id y123mr8543307ywg.214.1468447706006; Wed, 13 Jul 2016 15:08:26 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.152.13 with HTTP; Wed, 13 Jul 2016 15:07:46 -0700 (PDT)
In-Reply-To: <20160713203614.GA4757@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CABcZeBPh+BGtnBb725G+YzZZzdSUh5KtViqh3Z339apSKRpygg@mail.gmail.com> <20160713203614.GA4757@LK-Perkele-V2.elisa-laajakaista.fi>
From: Eric Rescorla <ekr@rtfm.com>
Date: Wed, 13 Jul 2016 15:07:46 -0700
Message-ID: <CABcZeBPtzG+GXY00B5JPt1kfpYdQoj8NVJhtFLZLk5BrFXyfTw@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Content-Type: multipart/alternative; boundary=001a114f8db2e3836d05378b9ff5
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/efRE_s0MJT6vb5BR6guxFh4r5cM>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Refactoring the 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, 13 Jul 2016 22:08:28 -0000

On Wed, Jul 13, 2016 at 1:36 PM, Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

>
>
> > PSK is handled by extending the concept of PSK flags that we already
> > have in NewSessionTicket to also include uses of PSKs where you
> > indicate the way in which you are using the PSK (or want it to be
> > used). There a bunch of ways to encode this. I'll give you the one I
> > mostly prefer below and then a one that's a smaller change but I think
> > a little less elegant at the end [note #4].
> >
> > First, we replace the flags word of the different KE modes for the
> > ticket with lists of code points, as below:
> >
> >    enum {
> >      psk_ke(0),          // PSK key exchange
> >      psk_dhe_ke(1),      // PSK + DHE key exchange
> >      (255)
> >    } PskKeModes;
>
> In the orthogonalization above, the second entry would be PSK+GDHE
> (any supported key exchange function), but that's probably what you
> meant already.
>

Yes, we're using "dhe == GDHE"



>
> > And then add new code points for being able to use the PSK with and
> > without signatures (from the server). We had pretty rough consensus in
> > B-A that we needed this mode and [draft-thomson-tls-0rtt-and-certs-01]
> > is part of the motivation for this idea.
> >
> >    enum {
> >      psk_auth(0),        // PSK only
> >      psk_sign_auth(1),   // PSK + a signature (as in draft-thomson) [5]
> >      (255)
> >    } PskAuthModes;
>
> I think that PSK+signature modes are so different that those warrant
> promotion to a new major key exchange type.
>

Hmm...  Why?



> > You might ask why you need the server to indicate what it did.  The
> > reason is that we would like the client to know in advance (at the
> > time of the ServerHello) whether the server has sent
> > Certificate/CertificateVerify rather than having to figure it out from
> > what messages the server sends. The ke_mode field is redundant
> > (because you also infer it from the server key_shares) but I added it
> > for parity.
>
> Well, figuring out from ServerHello (and even EncryptedExtensions)
> would not be so bad if the rules were clear.


Yes, that's what I'm hoping for.


>
> >
> > 2. One question that comes up at the same time is whether we should
> > allow multiple key shares to be used, which is a structure that this
> > makes pretty easy. Basically, the server would just supply as many
> > counter-shares as it wanted and then we'd need a defined order for how
> > they were inserted into the key schedule. This feature would be nice
> > for enabling post-quantum, but probably better to just define
> > <PQ-Algorithm + Curve> code points.
>
> In order of group number? Or in order of server reply?
>
> (Both orders would be well-defined). Would also avoid the bit of
> special case of zero key in pure-PSK mode...
>

I was thinking in order of group number, but if you do combined code points
you don't
need to do this.


> 5. Note: this would allow for modes where the server signs over a PSK
> > handshake with no DHE at all. The resumption_ctx mechanism is intended
> > to ensure that that is OK, but we'd need to confirm with analysis.
>
> I should also figure out all the attacks I figured out against server
> auth in pure-PSK (at most sidenotes, given how TLS 1.3 hasn't supported
> any such modes).
>
> Yeah, if resumption_ctx stuff is actually used, it should do the trick,
> as it binds the PSK key used (and the normal handshake hash binds the
> negotiation).
>
> The resumption_ctx would also bind the key if one kept it as constant
> and omitted Certificate message.
>

Definitely like to hear about this.

-Ekr


>
>
> -Ilari
>