IETF Logo Mail Archive

Re: [TLS] Negotiating with known_configuration

Eric Rescorla <ekr@rtfm.com> Tue, 21 July 2015 11:32 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 4A2AA1A01F7 for <tls@ietfa.amsl.com>; Tue, 21 Jul 2015 04:32:23 -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 ViYIZ914fdM4 for <tls@ietfa.amsl.com>; Tue, 21 Jul 2015 04:32:22 -0700 (PDT)
Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (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 C8A9A1A01C6 for <tls@ietf.org>; Tue, 21 Jul 2015 04:32:21 -0700 (PDT)
Received: by wicgb10 with SMTP id gb10so52644528wic.1 for <tls@ietf.org>; Tue, 21 Jul 2015 04:32:20 -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=8GKBw6B86qCBPuFyTXvQ7ttATNQ00nupk+QqFs6aQvI=; b=CnUAFu9trulV+LKj7AQpXCFJgXwD1w8evpfn2TiKxAFjShjq6HcnIn6+K1lYfHO5bO 4L8g+KhjfS115/Zr8k5zCurwwpkebkxctceB50tcTpl7uPPXoe504vcmzv1N2SXf/V9z oHOdTosGuzxN5IQCsqyUjCk/agi8V6x+dddjox98m6u6ijBohjMk1IifVn6N8CEM7k58 TZ5qzdkLHaX+sENfcORWUcX+RqqcknWlXPYZkirDLvLMep2PdKyxjI8cljWAPrfLLm0s LrN+OdjwRVoqOAU6crclqUnfEXD9cTnYovZMMd7cBTeH7JIzaPLXxvkABcaqcRVuvnXv E7EQ==
X-Gm-Message-State: ALoCoQkk7B7iZdnVIr55c5dzOaM6bqSal7Jhs80XfOjhfeJSMO/wDt2pEXp2LfedJTsVTie5/dJg
X-Received: by 10.194.158.42 with SMTP id wr10mr64678274wjb.81.1437478340575; Tue, 21 Jul 2015 04:32:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.27.85.75 with HTTP; Tue, 21 Jul 2015 04:31:41 -0700 (PDT)
In-Reply-To: <CABkgnnVswNWk-ZOD32EvfJ=ORQWTXBPAKs51k9tRq3vspzi3jQ@mail.gmail.com>
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>
From: Eric Rescorla <ekr@rtfm.com>
Date: Tue, 21 Jul 2015 13:31:41 +0200
Message-ID: <CABcZeBNXqkJrEYFm1Z7cW4pzNcxBhsDVNZv_HNQFcXOG2x9_pg@mail.gmail.com>
To: Martin Thomson <martin.thomson@gmail.com>
Content-Type: multipart/alternative; boundary="089e013c6478dcd2c2051b610160"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/sFAxvwn2PvgEoE3SORqXmKIUVSI>
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 11:32:23 -0000

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"

-Ekr


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

v2.26.15 | Report a Bug | By Email | System Status