Re: [TLS] Negotiating with known_configuration

Ilari Liusvaara <ilari.liusvaara@elisanet.fi> Tue, 21 July 2015 12:41 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 C1F1A1A1AA7 for <tls@ietfa.amsl.com>; Tue, 21 Jul 2015 05:41:14 -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 GjGN2KJrjjm2 for <tls@ietfa.amsl.com>; Tue, 21 Jul 2015 05:41:12 -0700 (PDT)
Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BAA61A0191 for <tls@ietf.org>; Tue, 21 Jul 2015 05:41:12 -0700 (PDT)
Received: from LK-Perkele-VII (a91-155-194-207.elisa-laajakaista.fi [91.155.194.207]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 6CB911A276A; Tue, 21 Jul 2015 15:41:10 +0300 (EEST)
Date: Tue, 21 Jul 2015 15:41:10 +0300
From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
To: Eric Rescorla <ekr@rtfm.com>
Message-ID: <20150721124110.GA20920@LK-Perkele-VII>
References: <CABcZeBOEUuVKHYRs5+DY6h8vcQ9uLWW9SXzN=VH=ovHbnEK0AA@mail.gmail.com> <CABkgnnUn5_Wo9XDRe=KQKO64MWcBGw0Pk6aviyigR+H7yVBaUg@mail.gmail.com> <CABcZeBP-2GudRXCHWBnWV7fnTuv-4nAzyxxY_FJx7UsPF_6KFg@mail.gmail.com> <CABkgnnVswNWk-ZOD32EvfJ=ORQWTXBPAKs51k9tRq3vspzi3jQ@mail.gmail.com> <CABcZeBNXqkJrEYFm1Z7cW4pzNcxBhsDVNZv_HNQFcXOG2x9_pg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <CABcZeBNXqkJrEYFm1Z7cW4pzNcxBhsDVNZv_HNQFcXOG2x9_pg@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/yz0d_AD39w09UyKH-s3kxHWJMYg>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Negotiating with known_configuration
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: <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, 21 Jul 2015 12:41:14 -0000

On Tue, Jul 21, 2015 at 01:31:41PM +0200, Eric Rescorla wrote:
> On Tue, Jul 21, 2015 at 1:30 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
> 
> > On 21 July 2015 at 04:12, Eric Rescorla <ekr@rtfm.com> wrote:
> > >
> > > Yes, that's an issue. Not entirely sure what to do about other than
> > > have the server provide its negotiation preferences out of band
> > > in that case.
> >
> > I think that we could handle that at the point we define an
> > out-of-band configuration priming mechanism.  I don't think we need a
> > full negotiation model for the server.  A simple option would list the
> > server's preference order for suites and so forth in its configuration
> > advertisement; the client would then pick from that.
> >
> Yeah, or it could just have the semantics "this is my most preferred
> configuration and if you send me anything compatible with it, I will
> pick it"

What cipher this is about? The cipher used for protecting 0RTT/Early
handshake data? The cipher used for protecting main connection?

For main connection, the server can pick from ciphersuites advertized
by client (assuming client gives ciphers that are acceptable and
are usable with configurations, i.e. GDHE_CERT-type things).

For 0-RTT/Early handshake data you want cipher that the server
supports and accepts. If it is about this, there could be multiple
allowed ciphers.


-Ilari