Re: [TLS] Negotiating with known_configuration

Eric Rescorla <ekr@rtfm.com> Tue, 21 July 2015 12:56 UTC

Return-Path: <ekr@rtfm.com>
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 A71341A7017 for <tls@ietfa.amsl.com>; Tue, 21 Jul 2015 05:56:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 tuf-x_cLt_UY for <tls@ietfa.amsl.com>; Tue, 21 Jul 2015 05:56:14 -0700 (PDT)
Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (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 6919F1A1B4B for <tls@ietf.org>; Tue, 21 Jul 2015 05:56:14 -0700 (PDT)
Received: by wibud3 with SMTP id ud3so126650268wib.0 for <tls@ietf.org>; Tue, 21 Jul 2015 05:56:13 -0700 (PDT)
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:content-type; bh=K+HTUQvEnjCyHASrpGJyRKbzilJDNnk08SQJQxDLxos=; b=bCV+qCpN4TmrJ539RvGewXGMdcobf7I+MhaqFy7Y4muW9hPK3DbEgbx09nTg+Xuhwp XhdTtFFd0cJ2CX/enyZ03lbqI5Sv3tdKRL2lDrcib3qIj8n41M/tiYt9ldPAJxDG7Tz5 UPPzHTZuVV4jIEn+ePL2wXO1wZ0GKUuNMjI2M4VnCTtQVSvpl02bpj5fHTt9KuGkh8IJ 5LQzcFOBYo7TSzlCTZer8xXjeILOe0XhtbfVcnd9cGr6AMxeTvgujvi3Eaex3vpvcUCM O4MRfVSO05O1CJqdvqXU80K20Y4wMpi2Hsu2sIRmOl53IfLLY30MM7ml4DnUqoHl1+ze M9SA==
X-Gm-Message-State: ALoCoQkqUPanxhcJnoKOtSULODKFfoh2012fHpWHGH53ITV6rMFlOrNWN/+IDOHJ5YwQmLLa9fcj
X-Received: by 10.180.208.114 with SMTP id md18mr31691736wic.31.1437483373103; Tue, 21 Jul 2015 05:56:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.85.75 with HTTP; Tue, 21 Jul 2015 05:55:33 -0700 (PDT)
In-Reply-To: <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> <20150721124110.GA20920@LK-Perkele-VII>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 21 Jul 2015 14:55:33 +0200
Message-ID: <CABcZeBMzhsFUGDG_-8U_BJFppRzkby3B2sgz1BFargoSW+DQhg@mail.gmail.com>
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Content-Type: multipart/alternative; boundary=001a11c37eb8d32aca051b622dab
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/nLTBfLEkG7HVg_g4wRgsmnb1KPA>
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:56:16 -0000

On Tue, Jul 21, 2015 at 2:41 PM, Ilari Liusvaara <
ilari.liusvaara@elisanet.fi> wrote:

> 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?
>

The former.


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).
>

Agreed.



> 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.
>

In principle this is true. However, there are two complications, ISTM:

1. The client has no way of knowing which ciphers the server would support
other than the one it negotiated with the client previously (assuming
in-band)

2. I'm trying to avoid questions about the security of the negotiation for
the
0-RTT data, and we already have negotiated parameters.

I haven't done any analysis of what happens if the server doesn't check
that it would negotiate the parameters that the client provides. That might
be fine, but I'm trying to be conservative.

Thanks,
-Ekr