Re: [therightkey] Proposal for working on PKIX revocation open issues

Nico Williams <nico@cryptonector.com> Mon, 17 November 2014 16:31 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: therightkey@ietfa.amsl.com
Delivered-To: therightkey@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8BD1A6FDE; Mon, 17 Nov 2014 08:31:09 -0800 (PST)
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, RCVD_IN_DNSWL_NONE=-0.0001] 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 fJj_cGcUHT6o; Mon, 17 Nov 2014 08:31:08 -0800 (PST)
Received: from homiemail-a86.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 01E591A0123; Mon, 17 Nov 2014 08:31:08 -0800 (PST)
Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id B950136007C; Mon, 17 Nov 2014 08:31:07 -0800 (PST)
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; s=cryptonector.com; bh=9ScrUAIAEMfGoTiCDeoF FjKOEOo=; b=y8iSyfQVfHdLhxpBs0JVrXVvsge/4O2aYsa3mnwQ/N0SYB6SvS9/ 5wN4cWenNr9DrYK0bcQWjN4eOlLdDoRZ/LQkD/MYqhJTL2hZVyF1QyvoYMSnD9Sm Ca0Umf3lz3zIkEey3v6itbVvkfr/yxt+qabv+3j4ee0IAzgD1xCl0IM=
Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPSA id 8830636007B; Mon, 17 Nov 2014 08:31:07 -0800 (PST)
Received: by mail-wi0-f179.google.com with SMTP id ex7so9754916wid.0 for <multiple recipients>; Mon, 17 Nov 2014 08:31:06 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.100.129 with SMTP id ey1mr33340260wib.28.1416241866476; Mon, 17 Nov 2014 08:31:06 -0800 (PST)
Received: by 10.216.32.135 with HTTP; Mon, 17 Nov 2014 08:31:06 -0800 (PST)
In-Reply-To: <5466AF87.2050307@gmail.com>
References: <5466AF87.2050307@gmail.com>
Date: Mon, 17 Nov 2014 10:31:06 -0600
Message-ID: <CAK3OfOjUbZkFXcvcOKAbKzSznKiJuV+E4++4vP4X5u7z1J6bpQ@mail.gmail.com>
From: Nico Williams <nico@cryptonector.com>
To: "Dr. Massimiliano Pala" <massimiliano.pala@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: http://mailarchive.ietf.org/arch/msg/therightkey/4Ii19o4cn_ga8_gEbghgSVL5ZQU
Cc: "pkix@ietf.org" <pkix@ietf.org>, "therightkey@ietf.org" <therightkey@ietf.org>
Subject: Re: [therightkey] Proposal for working on PKIX revocation open issues
X-BeenThere: therightkey@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <therightkey.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/therightkey>, <mailto:therightkey-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/therightkey/>
List-Post: <mailto:therightkey@ietf.org>
List-Help: <mailto:therightkey-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/therightkey>, <mailto:therightkey-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Nov 2014 16:31:09 -0000

On Fri, Nov 14, 2014 at 7:42 PM, Dr. Massimiliano Pala
<massimiliano.pala@gmail.com> wrote:
> (a) Defining new transport protocols for revocation information availability
> (e.g., OCSP over DNS or OCSP over LDAP)

OCSP lacks for various bindings to various transports.  I think
defining more such bindings would be nice.

> (b) (Possibly) defining a more lightweight revocation mechanisms (e.g.
> Lightweight Revocation Tokens)

What would that look like?  I think stapled DANE is about as
light-weight as it's going to get.

> (c) (Possibly) helping other working groups to revise and update how
> revocation information are provided (e.g., the client authentication case)

They can do this themselves.  Assuming TLS 1.3 retains user
authentication with certificates, let the TLS WG add stapled OCSP.

> (d) (Possibly) introducing privacy consideration when it comes to revocation
> checking

If you staple OCSP then the main privacy considerations are:

a) how the end entities' certs and OCSP responses are transported
(e.g., we'd need TLS to have a mode that provides confidentiality to
the client cert, which IIUC is not in the cards for 1.3),

b) how to provide privacy protection for DNS (the elephant in the room).

Anything to be done in TLS belongs squarely in the TLS WG.  I'd love
to see DNS confidentiality, but I think we should get our priorities
straight: opportunistic security, TLS 1.3, CT, DNSSEC/DANE deployment,
...  I confess that my list of priorities is something one could argue
about, and that if we have the energy to do more of these things
concurrently, then we should.

Nico
--