[stir] Comments on draft-ietf-stir-certificates-ocsp-00.txt

Eric Rescorla <ekr@rtfm.com> Thu, 23 March 2017 23:31 UTC

Return-Path: <ekr@rtfm.com>
X-Original-To: stir@ietfa.amsl.com
Delivered-To: stir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90D7B129511 for <stir@ietfa.amsl.com>; Thu, 23 Mar 2017 16:31:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.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 3Vtrq5VZpadh for <stir@ietfa.amsl.com>; Thu, 23 Mar 2017 16:31:07 -0700 (PDT)
Received: from mail-yw0-x235.google.com (mail-yw0-x235.google.com [IPv6:2607:f8b0:4002:c05::235]) (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 D0D9C1293E3 for <stir@ietf.org>; Thu, 23 Mar 2017 16:31:06 -0700 (PDT)
Received: by mail-yw0-x235.google.com with SMTP id p77so157427033ywg.1 for <stir@ietf.org>; Thu, 23 Mar 2017 16:31:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=/C7YRQxwDmzWU9mlIqCk4LheqeLtq79yHVdQL0txh0M=; b=ke3b6Q/9nYzL5Wz7JklLp5zgd772fkEK6BrJAW8giQs/qP97G2ftQhjPovTog5zVSy f0Q6N9QqGD7Z25aXhkb/PTz9MyrSddzF14UJ2A+jKd3ynsBrGeWDU0oG8ucvnYN3vJJX hhy9rdrtC5a6qTNQsO+5dx70GFEzqRzGbdDGWoeMXJlPug8jjgGL7ETPrjFsh5gHMMTt 3vDQyNrA15maFIFTSZuf14eJsf3c/xiXv/pAFqVoWRQB+x8zJr/qLJDHmdVf3ct+c6xp rg08VaniYLLVZJK/Qi6+e5RP7RBYMN7vQdjVIcBHNWRr4T29x8XHxRG7MO2ruS2TviSd NvXw==
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=/C7YRQxwDmzWU9mlIqCk4LheqeLtq79yHVdQL0txh0M=; b=M9UmxaBcSg4pSFHVt/wK4oCuWXRu343mU8V7kqQlzDpODZeG5Xx3ldfssHyuTMhrkP wVjMNGSveU6mqX0TKXFmgeKL7sUV4l/W3WZTstKZgDHYayM0y7BqM138Tpqlul7bpKeA 0wqEYMnMniWBkDHLmIrtGSOm+dtz0FGdY67vIRpS1tVTDDosxcq3MZK4CpgIEesFt9iC drZTOLIY3P/3TAGGl+G5txvYLrr3vfP9MnXOLlm+ZcfvniiR/mN4FIaCc3MGRhqZF2Jw vX6G4dBeH78C256BC/6s50+7WLs71Uhc2bDZoeCtcKDLxyhR63MOijXVzLsvHgmW0uZM aQhg==
X-Gm-Message-State: AFeK/H2C6Qpgw9U3YkXyeOR7mVelkITfiR/DI9UERBW7KycUeOlASuLXRkOyksdLwG0pgf/XG8yrEPV+C4o7hA==
X-Received: by 10.129.108.214 with SMTP id h205mr3813651ywc.71.1490311865947; Thu, 23 Mar 2017 16:31:05 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.154.210 with HTTP; Thu, 23 Mar 2017 16:30:25 -0700 (PDT)
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 23 Mar 2017 16:30:25 -0700
Message-ID: <CABcZeBPPFn4PDa26i6Wg_hfBzzqMO+7WqOw8RWp+jODb7bgeKw@mail.gmail.com>
To: "stir@ietf.org" <stir@ietf.org>
Content-Type: multipart/alternative; boundary=001a114e81dc604a2e054b6e4594
Archived-At: <https://mailarchive.ietf.org/arch/msg/stir/q8C9akHJ668aJeA1GaHnjqVO5Tc>
Subject: [stir] Comments on draft-ietf-stir-certificates-ocsp-00.txt
X-BeenThere: stir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Secure Telephone Identity Revisited <stir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stir>, <mailto:stir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/stir/>
List-Post: <mailto:stir@ietf.org>
List-Help: <mailto:stir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stir>, <mailto:stir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Mar 2017 23:31:08 -0000

As S 5 implies, the privacy properties of the document are not
ideal, in that the RP provides the phone number of interest to
the OCSP server.

It seems like there are two scenarios of interest:

1. The certificate contains some opaque identifier.
2. The certificate contains a list of numbers, but some may
   now be invalid.

In the former case, I agree that it makes sense to have the RP
send the number it is trying to verify because otherwise the
server would have to send all valid TNs. However, in the latter
case, it seems like you could instead respond with the list of
numbers which are no longer valid. This would have some bandwidth
cost, but quite a bit better privacy.


S 3.1.1. says:
   The HVE OCSP profile [RFC5019] prohibits the use of per-request
   extensions.  As it is anticipated that STIR will use OCSP in a high-
   volume environment, many of the optimizations recommended by HVE are
   desirable for the STIR environment.  This document therefore uses the
   HVE optimizations augmented as follows:

   o  Implementations MUST use SHA-256 as the hashing algorithm for the

Is the take-home here "we want to be high volume, but we can't use
HVE because of the extension, so we're copying in a bunch of
the HVE requirements"? Maybe better to include by reference with
an exception.

-Ekr