Re: [TLS] Application data during renegotiation handshake
David Benjamin <davidben@chromium.org> Thu, 12 November 2015 20:43 UTC
Return-Path: <davidben@google.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 ED3971B3573 for <tls@ietfa.amsl.com>; Thu, 12 Nov 2015 12:43:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.388
X-Spam-Level:
X-Spam-Status: No, score=-1.388 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, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 uvLGUe_DGrQ7 for <tls@ietfa.amsl.com>; Thu, 12 Nov 2015 12:43:26 -0800 (PST)
Received: from mail-io0-x22f.google.com (mail-io0-x22f.google.com [IPv6:2607:f8b0:4001:c06::22f]) (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 328771B3595 for <tls@ietf.org>; Thu, 12 Nov 2015 12:43:26 -0800 (PST)
Received: by iouu10 with SMTP id u10so70073832iou.0 for <tls@ietf.org>; Thu, 12 Nov 2015 12:43:25 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=19s38QWgSU/Fwk2GvZaRAVx5trH3/awrfPsxAvyDYLc=; b=cp2+32f6pcqLMa7Ek0qYQDos6PHVtU9CSw49BDZa2fUmagxAFYn5g6irrYlOB2eupa 4zVvPHreV+56hfRxifHXJBjXJIX2FU1Auf/IednLQcupUpDYSd8ajyQ7XlbeEwcg/Smq 6ML78MmfAnWEMpblp1DD5+BWFECRHeF6Ifjoc=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=19s38QWgSU/Fwk2GvZaRAVx5trH3/awrfPsxAvyDYLc=; b=e43lho4ULIrrmJPnqPzLdkkKHYujmLIM6WUee27Ql3UWe6rYwwrTq7uEwHqV3QvIyj GNLxmTXM2ZRczrnYjZmVIUMFc0nw5BtF17HeKk3b3qUmNG7UOa94ft6chWisFtwxynV8 HhuP6ejkDnwGso+gv3nrZf5J1zjhrtjGy7IMZEkpDd4NP4xWwZ03rfTNuPCz6zP3lnkG TYRmyAzx5tvDKWLHBH/qE6Zw/pLd9ea04jDDbmwiTO1EEYyRDvUG1OrW9E1Bfjpkrs/K bjewlLbeUSowhwczD9YEmLeVdKb66rN/zT+05V9Jz8ELjY+CBc+Sd5wmb2qr4Sz8GZY6 4/yw==
X-Gm-Message-State: ALoCoQmrYvyEoI/nS/2Cw5s0MeGOEaS9M+sb9phGWrdP9rt/MDE7bs0iYwxpHgvQOOjRCHxbofyy
X-Received: by 10.107.44.210 with SMTP id s201mr20113042ios.62.1447361005518; Thu, 12 Nov 2015 12:43:25 -0800 (PST)
MIME-Version: 1.0
References: <CY1PR03MB13743E3AE466C2F8F7AC140687130@CY1PR03MB1374.namprd03.prod.outlook.com> <CAMfhd9UV=Zya6dort29J0s7NcrbrU=a-6+diD_Sq9U6h2x1fgQ@mail.gmail.com> <F36034F5-2B2C-4E36-B44D-E581AD0B813E@gmail.com>
In-Reply-To: <F36034F5-2B2C-4E36-B44D-E581AD0B813E@gmail.com>
From: David Benjamin <davidben@chromium.org>
Date: Thu, 12 Nov 2015 20:43:15 +0000
Message-ID: <CAF8qwaBYpDxynY6QpPC++AH7JR46R3NH2WmWfUS60TCWodp+cA@mail.gmail.com>
To: Yoav Nir <ynir.ietf@gmail.com>, Adam Langley <agl@imperialviolet.org>
Content-Type: multipart/alternative; boundary="001a113978f298d2b005245dfe64"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ruCeSo_DJiy4Wey5y9Gfm_dQxGM>
Cc: Mike Bishop <Michael.Bishop@microsoft.com>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Application data during renegotiation handshake
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: Thu, 12 Nov 2015 20:43:28 -0000
On Wed, Nov 11, 2015 at 10:43 PM Yoav Nir <ynir.ietf@gmail.com> wrote: > > > On 12 Nov 2015, at 3:32 AM, Adam Langley <agl@imperialviolet.org> wrote: > > > > The TLS 1.3 post-handshake client-auth was intended, as I recall, to > > support HTTP/1.1 over TLS 1.3. > > No, it was (and is) presented as a way to do client certificate > authentication with HTTP/2 not at the initial handshake. > > > With HTTP/2 isn't it cleaner to do client-auth at the HTTP layer (i.e. > > by signing exporter values)? > > It is. I thought that an HTTP authentication method based on certificates > could be a drop-in replacement for TLS layer authentication, but someone (I > think it was Mike) pointed out that with TLS-layer certificate > authentication the stream continues after the authentication, while with > HTTP-layer authentication, the stream ends with a 401 status code, and the > client has to start a new stream with the Authorization header. So > applications would need to be changed for this to work. > Using existing HTTP semantics would certainly be cleaner in a vacuum, but one could still do it in HTTP/2 layer without creating a new stream. Perhaps adapt SPDY's CREDENTIAL frame and add a new SWITCH_CREDENTIAL frame to swap a stream's credential slot mid-stream? Alternatively, HTTP/2 frontend could make the application think there were two independent requests. Am I misunderstanding the objection? What about this: 1. Client hits HTTP/2 frontend. Frontend talks to application which decides it needs client auth, expecting it on the same stream. 2. Frontend immediately aborts that request and returns a 401 to the client. Application thinks the client just gave up. 3. Client makes a new stream, now authenticated. The frontend hits the application fresh. Application requests client auth as before and frontend responds immediately with the certificate the client asserted. This is, by the way, how Chrome implements client auth today, even with renego. We never reconfigure client auth mid-stream. I think it would be helpful to have examples of exactly what the applications look like, to know what constraints the various interested parties are working with. For example, Apache httpd has some high-level configuration file. https://httpd.apache.org/docs/2.2/ssl/ssl_howto.html#arbitraryclients Existing Apache installs can easily compatibility regardless of how the HTTP/TLS interaction looks. On the other extreme, if the goal is to keep Apache httpd unchanged while only changing OpenSSL, then we have a very different picture because the OpenSSL API is SSL_renegotiate/SSL_do_handshake (send a HelloRequest) + SSL_set_state/SSL_do_handshake (don't continue until renego completes). That one is quite overfit to the old flow and will be difficult to reconcile with almost anything. draft-thomson-http2-client-certs-00's HTTP/2 mode seems to be targeting something in between. It's okay with adding a new application_context_id, but the client certificate still needs to be asserted at the transport. I'm having a hard time divining the constraints from this. David
- [TLS] Application data during renegotiation hands… Mike Bishop
- Re: [TLS] Application data during renegotiation h… Adam Langley
- Re: [TLS] Application data during renegotiation h… Yoav Nir
- Re: [TLS] Application data during renegotiation h… Nikos Mavrogiannopoulos
- Re: [TLS] Application data during renegotiation h… Matt Caswell
- Re: [TLS] Application data during renegotiation h… Hubert Kario
- Re: [TLS] Application data during renegotiation h… Martin Rex
- Re: [TLS] Application data during renegotiation h… Nikos Mavrogiannopoulos
- Re: [TLS] Application data during renegotiation h… David Benjamin
- Re: [TLS] Application data during renegotiation h… Mike Bishop
- Re: [TLS] Application data during renegotiation h… David Benjamin