IETF Logo Mail Archive

Re: [TLS] New draft: draft-rescorla-tls13-new-flows-01

Stephen Checkoway <s@pahtak.org> Mon, 24 February 2014 01:20 UTC

Return-Path: <s@pahtak.org>
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 CFD5E1A0789 for <tls@ietfa.amsl.com>; Sun, 23 Feb 2014 17:20:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.799
X-Spam-Level:
X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 zX7B-AH0oKs0 for <tls@ietfa.amsl.com>; Sun, 23 Feb 2014 17:20:06 -0800 (PST)
Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) by ietfa.amsl.com (Postfix) with ESMTP id 909C91A0788 for <tls@ietf.org>; Sun, 23 Feb 2014 17:20:06 -0800 (PST)
Received: by mail-qg0-f43.google.com with SMTP id f51so13204787qge.2 for <tls@ietf.org>; Sun, 23 Feb 2014 17:20:06 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=a4QIWnxz323d5QlpkDvr8cC2KmXjzF70EQpdat/ORLg=; b=UiQ25idg2ZxyMwqEj1FTB7KRPwU3F/naYfT/1U2XnSsGkLIXEcx8DXbwW7PX3XgTKs dop+0SjY/B9MRSMNkUkTsBl3GkFK/UmSvrTtMB8/ca4G2TkRaf1vwVru3PPY9PAdW8OM UVCGSLn7uVImwFMEBcxbhV1gheEuQLz+ODQ8g2Hpp/Dz++6FF45IO0gH6A+0buvGUbRt vxxHS4MtYeUQLVgzUcqxb/frBZwOIj2+IzeWAmlQ5++yS/GmMrDic7vDg+zUK2Oz9omk yMy+xfAAMEEuRDFcKoNM0lDpHJUiA9nzCoinwQ7eQVyzMG2i5q0YrZLzlTY/n9DEoWMr smIw==
X-Gm-Message-State: ALoCoQmlzMPp06bangJrI9A5HBcIjN9s03nRBUqIeUqmjE92DDreZOQwIvmls29ozoxdrqEGmWr3
X-Received: by 10.224.151.147 with SMTP id c19mr26158699qaw.86.1393204805996; Sun, 23 Feb 2014 17:20:05 -0800 (PST)
Received: from zbox.pahtak.org (c-68-48-196-126.hsd1.md.comcast.net. [68.48.196.126]) by mx.google.com with ESMTPSA id d15sm45066811qaq.4.2014.02.23.17.20.04 for <multiple recipients> (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 23 Feb 2014 17:20:05 -0800 (PST)
Received: from [10.0.1.4] (ip-210-102.oberlin.net [208.66.210.102]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by zbox.pahtak.org (Postfix) with ESMTPSA id B003DAC28B5; Sun, 23 Feb 2014 20:20:02 -0500 (EST)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Stephen Checkoway <s@pahtak.org>
In-Reply-To: <CACsn0cnpT-UGR_EMupmv68uXCXGS3Qn0CUBY=6jDgaeoi2cVhQ@mail.gmail.com>
Date: Sun, 23 Feb 2014 20:20:01 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <4156173A-B7FC-4841-8733-D39009A88BDF@pahtak.org>
References: <CABcZeBNUjg_Y3MKtRrAMmYAeYFLM1QyHvr1DCbOfA6MB2tJOYQ@mail.gmail.com> <CACsn0cmZBzrvek_hKTY1Tm-+Win6UOM4paEzJ67JRrk2OZvH7A@mail.gmail.com> <CABcZeBP6miqX3XY=CQfshwfAKoeQRrr5ABhBDa3z+z9hwaYeig@mail.gmail.com> <CACsn0cnpT-UGR_EMupmv68uXCXGS3Qn0CUBY=6jDgaeoi2cVhQ@mail.gmail.com>
To: Watson Ladd <watsonbladd@gmail.com>
X-Mailer: Apple Mail (2.1827)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TTbpCAS8_QXZHfrvUDO2xYxAkUs
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] New draft: draft-rescorla-tls13-new-flows-01
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: <http://www.ietf.org/mail-archive/web/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: Mon, 24 Feb 2014 01:20:09 -0000

Hi Watson,

On Feb 23, 2014, at 7:41 PM, Watson Ladd <watsonbladd@gmail.com> wrote:

> Easy solution: limit the options so that there is one acceptable
> choice,

As much as this appeals to me, this route seems unlikely to be adopted since what's acceptable to you or me is probably not acceptable to everyone.

> with a means to negotiate a future one when that one
> acceptable choice falls.

It seems likely that this will because the default method and I'm not sure how this is simpler than offering options initially.

> I'm proposing that we secure the key we are sending SNI data to with
> some certificate

I'm not sure I'm following you here. As I understand it, the whole issue is that with SNI the server doesn't know which cert to use until after it sees the SNI. Are you proposing that there is some master cert which secures the key used for SNI data and then a separate cert for the given server name?

-- 
Stephen Checkoway

v2.23.0 | Report a Bug | By Email