IETF Logo Mail Archive

Re: Call for Adoption: Secondary Certificate Authentication in HTTP/2

Martin Thomson <martin.thomson@gmail.com> Mon, 11 July 2016 04:06 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 5A92F12B04F for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 10 Jul 2016 21:06:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.308
X-Spam-Level:
X-Spam-Status: No, score=-8.308 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 P4yieAWqOVgq for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Sun, 10 Jul 2016 21:06:18 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A258C12B028 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Sun, 10 Jul 2016 21:06:18 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1bMSQI-0003vV-LM for ietf-http-wg-dist@listhub.w3.org; Mon, 11 Jul 2016 04:02:22 +0000
Resent-Date: Mon, 11 Jul 2016 04:02:22 +0000
Resent-Message-Id: <E1bMSQI-0003vV-LM@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <martin.thomson@gmail.com>) id 1bMSQF-0003ug-1t for ietf-http-wg@listhub.w3.org; Mon, 11 Jul 2016 04:02:19 +0000
Received: from mail-qk0-f180.google.com ([209.85.220.180]) by maggie.w3.org with esmtps (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <martin.thomson@gmail.com>) id 1bMSQD-0000op-CC for ietf-http-wg@w3.org; Mon, 11 Jul 2016 04:02:18 +0000
Received: by mail-qk0-f180.google.com with SMTP id o67so17182530qke.1 for <ietf-http-wg@w3.org>; Sun, 10 Jul 2016 21:01:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=CUY5NQo8C9JFrR4a0FJHM8Mb7OoDAuf+t3ec11d1a3I=; b=obpfb4niVI/0rA1rLj65DEcij6eFpA1bec+Bhkk6N7JME0LWdRNq3vfJt81QAUV/v7 JhJQRmXzhgsxmePp6iC45QBM3HREdruoSv1CI0MfC6QhaIia4///VXcJF4IBkeNujC7R vg7DrSa/4UyrWKaiucOP0UibrUM7DoilESJobC7cFfVNMCRRYe2kRIVEzAUhb3go1fvp cQpbzu9ThjCq43gNfukTLzyjokDohTOybLN9GDKDc3VcwICn7ET7D5vazDzDkl3ZzGK7 fofg4N4CzQYNb03T8MnkvIt1lnlLTYGeIoC2ZOpMOLsiLmW5SdlIvYYPMivTgDchI+z+ nJ3Q==
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; bh=CUY5NQo8C9JFrR4a0FJHM8Mb7OoDAuf+t3ec11d1a3I=; b=PVXydRFz6KCyrQsS+uKvhZkBjjT59aVmdNuMYEl+FG2V2zH9KNX3Sq/KAOhmVIKP99 ukop8kXyYpViCPGSxxBhmU9oSn7uL36a9km5yIPmG22hF8axLdcTF2J5nJgUd2RISay9 Q0EmZK/jrOOhUfYfcYL4J8q0jMIkRhZeSz6WnD46yEh2kWGDOPoczG406Yap3kwoqIK+ 9akINXy8rzb078UStlegHH5vlOvFFFjZ2v3Zfz7LfwrprNWoiwItCYaHMjQOO/LnrC8W dm8oGXMFE8ytR4sFjcapLACotvxp8f89N5L2vycs0/FDATS7k4SRk/bXiLoy+BKVbDBB 7/rw==
X-Gm-Message-State: ALyK8tIDIVTwQC4dNjue4lgFl5OJ4yR/OkOxx9lykO7o4qXwgYeEyqOIsf5x7uuoNOZHWS/Wb98Ro6LAdy1JpA==
X-Received: by 10.55.201.70 with SMTP id q67mr22181940qki.124.1468209711337; Sun, 10 Jul 2016 21:01:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.140.22.38 with HTTP; Sun, 10 Jul 2016 21:01:50 -0700 (PDT)
In-Reply-To: <CABcZeBOuf0k5VwSO1nMp-P0YXF-j8pZ7ZVF1h-_pMU54LnwpJQ@mail.gmail.com>
References: <F9D2CFF3-57C2-41BD-ACB1-FA6C991458D7@mnot.net> <CABcZeBPTYgcfecKErhacR=jfXkoRPESgUQ=1pzPEWg092fqZvw@mail.gmail.com> <BL2PR03MB1905D20659B406937EA7C021873B0@BL2PR03MB1905.namprd03.prod.outlook.com> <CABcZeBOuf0k5VwSO1nMp-P0YXF-j8pZ7ZVF1h-_pMU54LnwpJQ@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 11 Jul 2016 14:01:50 +1000
Message-ID: <CABkgnnXL-hS-raH5cC3c0nzpTHWP8speLbOhFNppv4p5LB5nQQ@mail.gmail.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: Mike Bishop <Michael.Bishop@microsoft.com>, Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=209.85.220.180; envelope-from=martin.thomson@gmail.com; helo=mail-qk0-f180.google.com
X-W3C-Hub-Spam-Status: No, score=-7.9
X-W3C-Hub-Spam-Report: AWL=1.833, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1bMSQD-0000op-CC 36cfebbabcdf8729e0b5c047b247c883
X-Original-To: ietf-http-wg@w3.org
Subject: Re: Call for Adoption: Secondary Certificate Authentication in HTTP/2
Archived-At: <http://www.w3.org/mid/CABkgnnXL-hS-raH5cC3c0nzpTHWP8speLbOhFNppv4p5LB5nQQ@mail.gmail.com>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/31867
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: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On 11 July 2016 at 11:23, Eric Rescorla <ekr@rtfm.com> wrote:
> 1. It's not possible to force a counterparty to demonstrate that he still
> has control of a given signing key. So, for instance, if you were a server
> and wanted a user to demonstrate that he still had access to the key (like,
> it's in a token and you're authorizing a high value transaction). Because
> what he signs is the same every time, the counterparty can just replay the
> previous assertion.

I think that there is still room for restructuring how the assertions
are made so that integrating a request identifier (which might be
large and random) into the signature is a good idea.

> 2. If you have two certificates with the same key pair, a signature for one
> is a signature for both (for the same reason as #1).

Yes, we should cover the certificate with the signature.  It's
relatively easy to do.  And even if this isn't something that can be
exploited, it keeps this design from diverging too much from TLS
unnecessarily.

v2.23.0 | Report a Bug | By Email