HTTP/2 and TLS 1.3 post-handshake authenication
David Benjamin <davidben@chromium.org> Mon, 01 April 2019 23:23 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13CB21201B9 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 1 Apr 2019 16:23:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level:
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, MAILING_LIST_MULTI=-1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 FsEbWfILNAlU for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 1 Apr 2019 16:23:12 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [IPv6:2603:400a:ffff:804:801e:34:0:38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FE941201B8 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 1 Apr 2019 16:23:12 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.89) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1hB6E1-0007hO-Rg for ietf-http-wg-dist@listhub.w3.org; Mon, 01 Apr 2019 23:20:21 +0000
Resent-Date: Mon, 01 Apr 2019 23:20:21 +0000
Resent-Message-Id: <E1hB6E1-0007hO-Rg@frink.w3.org>
Received: from titan.w3.org ([2603:400a:ffff:804:801e:34:0:4c]) by frink.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <davidben@google.com>) id 1hB6E0-0007ge-AL for ietf-http-wg@listhub.w3.org; Mon, 01 Apr 2019 23:20:20 +0000
Received: from mail-qt1-x82f.google.com ([2607:f8b0:4864:20::82f]) by titan.w3.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.89) (envelope-from <davidben@google.com>) id 1hB6Dy-00058i-T3 for ietf-http-wg@w3.org; Mon, 01 Apr 2019 23:20:20 +0000
Received: by mail-qt1-x82f.google.com with SMTP id k14so13137991qtb.0 for <ietf-http-wg@w3.org>; Mon, 01 Apr 2019 16:19:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:from:date:message-id:subject:to; bh=jpmF7BZrVzHkPckLw0s30WID8mUASlPW4s3zPZOMUTw=; b=Gn/TGagMDj+lVi6x7RL5Bo67yVNKCO1Beec7V6XRQyPN3Zv29XdPNlMgbLOV2g+WxW pi6/apoolbx1+me17lfUxjF+3g/dGVQLe7Godh9QtVVuGE7e2/9SJAroSQABPEo4/Jcu Y2piLnPopykocXi7/vogXffA/a7Ie7U5iVVQ4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=jpmF7BZrVzHkPckLw0s30WID8mUASlPW4s3zPZOMUTw=; b=RuuRuW4Il2ioXN0GuhpKRm/nfVufGE1nwhN+oTh+Bg7zj67FsQdiPOUDOyIdmHjGEe RQQmac/O+kYBk2sYp5fEsCJleV+kFcDyPo/WLFDg79Ey4WpTR/XZHV9lvTIMP3Ni+fnw VfjlmRnw+zSCwKZ7AOXlz1zpjuPGbLqQCAntr3KqgtlQPlEtiGp83b/WleOAWZVg5u3a /QQRZeBdvbJI5XXqM7RTy/RgU2fWaL0chdUecsaUPoLsvoHOsXpdk/1/Z/NX1pjbBEWG VGTqJn34X+Tbszw1yL3FS51K6xMkh0Gg/NEGbAKwPiw4rUHkrx24B7CwhC+eG8xVL8TH TSwQ==
X-Gm-Message-State: APjAAAXX9TXekYLFiVfESE/iF5NcVJrcSl4Fq0rqqyVUgNOnX7DNuuAF huTAepJqgzpageznxK0S4u/N7GILUXHuKlVRRLncJfe6Py0Z
X-Google-Smtp-Source: APXvYqx79dE6yFC1wf0bfjIc1SkCMSLU1EwMIFPYOCh/P/EqYnosr78KZOJ6Z7PTLNxkrCcVfteKyEj1ueqFD1vRk7M=
X-Received: by 2002:ac8:2684:: with SMTP id 4mr45323153qto.67.1554160797380; Mon, 01 Apr 2019 16:19:57 -0700 (PDT)
MIME-Version: 1.0
From: David Benjamin <davidben@chromium.org>
Date: Mon, 01 Apr 2019 18:19:41 -0500
Message-ID: <CAF8qwaCB6jsa03jtL+9W06s+Aqh1+ftwZaM+PH-b=5Omq5KG_w@mail.gmail.com>
To: HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: multipart/alternative; boundary="00000000000040e17c0585804257"
Received-SPF: pass client-ip=2607:f8b0:4864:20::82f; envelope-from=davidben@google.com; helo=mail-qt1-x82f.google.com
X-W3C-Hub-Spam-Status: No, score=-11.5
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1hB6Dy-00058i-T3 1d1d721f86bbe42752f010f9cc9013da
X-Original-To: ietf-http-wg@w3.org
Subject: HTTP/2 and TLS 1.3 post-handshake authenication
Archived-At: <https://www.w3.org/mid/CAF8qwaCB6jsa03jtL+9W06s+Aqh1+ftwZaM+PH-b=5Omq5KG_w@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/36493
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
Hi all, HTTP/2 and TLS 1.3 have a minor incompatibility around post-handshake authentication. Mike Bishop suggested that, rather than add some text in the secondary certs draft, it would better to make a separate document that actually updates HTTP/2. I've done so and uploaded a draft. https://tools.ietf.org/html/draft-davidben-http2-tls13-00 https://www.ietf.org/id/draft-davidben-http2-tls13-00.txt HTTP/2 was specified against TLS 1.2, which had a renegotiation mechanism to rekey the connection. It additionally changed parameters, so in HTTP/1.1, this is often used in a hack to implement reactive client auth <https://tools.ietf.org/html/draft-ietf-httpbis-http2-secondary-certs-03#section-1.2.1>. This hack doesn't work in a multiplexed protocol like HTTP/2, because the client cannot tell which request triggered the authentication request. Thus, HTTP/2 forbids renegotiation <https://tools.ietf.org/html/rfc7540#section-9.2.1>. TLS 1.3 removed renegotiation and replaced it with two features: a lightweight key update, and post-handshake client authentication. The former is meant to be transparent and is compatible with HTTP/2. The latter reintroduces renegotiation's multiplexing problems. There is no spec text which says how to interpret HTTP/2's existing renegotiation ban in TLS 1.3. The draft fixes it by documenting the status quo. KeyUpdate is fine. It is internal to the TLS stack and works just fine in existing servers[*]. Post-handshake auth is forbidden. No existing servers request it because they already do not request renegotiation, and no existing clients accept it because they cannot usefully interpret it. Instead, the reactive client auth use case for HTTP/2 is instead being covered by draft-ietf-httpbis-http2-secondary-certs. Note it's not sufficient to lean on the TLS 1.3 post_handshake_auth extension because that extension is not correlated with ALPN. A client may wish to support post-handshake auth with HTTP/1.1, for continuity with the TLS 1.2 renego hack, while still supporting HTTP/2. David [*] Aside from an OpenSSL bug <https://mailarchive.ietf.org/arch/msg/tls/Aw1WY5gBAifAZXowgx5Ym82RIKI> which, pertinently, made some applications misinterpret it as a renegotiation to be blocked. That bug has been fixed in OpenSSL 1.1.1b <https://www.openssl.org/news/changelog.html#x1>.
- HTTP/2 and TLS 1.3 post-handshake authenication David Benjamin
- Re: HTTP/2 and TLS 1.3 post-handshake authenicati… Martin Thomson
- Re: HTTP/2 and TLS 1.3 post-handshake authenicati… David Benjamin
- Re: HTTP/2 and TLS 1.3 post-handshake authenicati… Patrick McManus
- Re: HTTP/2 and TLS 1.3 post-handshake authenicati… David Benjamin