Re: [TLS] Doing without renegotiation

Nico Williams <nico@cryptonector.com> Thu, 17 April 2014 16:16 UTC

Return-Path: <nico@cryptonector.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 DA68E1A00E6 for <tls@ietfa.amsl.com>; Thu, 17 Apr 2014 09:16:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.044
X-Spam-Level:
X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334] autolearn=no
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 gGJ1ftKqpEVV for <tls@ietfa.amsl.com>; Thu, 17 Apr 2014 09:15:58 -0700 (PDT)
Received: from homiemail-a77.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 03BF11A00DD for <tls@ietf.org>; Thu, 17 Apr 2014 09:15:58 -0700 (PDT)
Received: from homiemail-a77.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTP id 81D149406B for <tls@ietf.org>; Thu, 17 Apr 2014 09:15:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=kPztaJkz4xh3QzPTC3gpwoyyRbs=; b=lof2Aor+5dc 5iDobExOfjBxw78M7zbGZ+slh1gbKZxU9izz81kbISbHB0v1XGkUaWGpiKJShU4J VlqEzA/aVDFpBsQtBTaWdcamqafFkhdeKOli2mKK9trXK5E3Qbe8D5Euzv3cb67k oXgwCqLShViTehQjA/yNC7SqqaI3P5gY=
Received: from mail-wg0-f41.google.com (mail-wg0-f41.google.com [74.125.82.41]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a77.g.dreamhost.com (Postfix) with ESMTPSA id 3405794065 for <tls@ietf.org>; Thu, 17 Apr 2014 09:15:54 -0700 (PDT)
Received: by mail-wg0-f41.google.com with SMTP id n12so636237wgh.0 for <tls@ietf.org>; Thu, 17 Apr 2014 09:15:53 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.180.160.166 with SMTP id xl6mr13009523wib.42.1397751353044; Thu, 17 Apr 2014 09:15:53 -0700 (PDT)
Received: by 10.216.29.200 with HTTP; Thu, 17 Apr 2014 09:15:52 -0700 (PDT)
In-Reply-To: <2763DE41-00D1-4C86-8982-A11B3A77D40C@gmail.com>
References: <20140417035011.GA25499@localhost> <2763DE41-00D1-4C86-8982-A11B3A77D40C@gmail.com>
Date: Thu, 17 Apr 2014 11:15:52 -0500
Message-ID: <CAK3OfOhS2J1PEUE3nVfwXC=K1e+2Qs3QrTQxDAFnGmzZceZr-A@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: Yoav Nir <ynir.ietf@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/46IveDV25aEmE7lLJ37KpEg6u7c
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Doing without renegotiation
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: Thu, 17 Apr 2014 16:16:02 -0000

On Thu, Apr 17, 2014 at 2:47 AM, Yoav Nir <ynir.ietf@gmail.com> wrote:
> On Apr 17, 2014, at 6:50 AM, Nico Williams <nico@cryptonector.com> wrote:
>> - For authentication other than that provided by the initial handshake
>>   I propose application-specific solutions.
>
> Do you mean something like Martin’s proposal ([1][2]) or doing the whole thing in HTTP as a new HTTP authentication method?

The latter.  When using PK/PKI or PSK there's no need for more than
one round trip, so for HTTP it's pretty simple as there'd be no impact
on statelessness.

For SASL applications we'd need new SASL mechanisms (although ISTR
that there is a SASL mechanism for using PK/PKI).

That covers a large number of Internet applications that use TLS!

Nico
--