Re: [pkix] RFC 5742 review of draft-hotz-kx509 and about RFC 4211

Russ Allbery <rra@stanford.edu> Fri, 01 June 2012 05:14 UTC

Return-Path: <rra@stanford.edu>
X-Original-To: pkix@ietfa.amsl.com
Delivered-To: pkix@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20EE521F85BD for <pkix@ietfa.amsl.com>; Thu, 31 May 2012 22:14:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id huFN7f+Ol5Qa for <pkix@ietfa.amsl.com>; Thu, 31 May 2012 22:14:35 -0700 (PDT)
Received: from smtp.stanford.edu (smtp3.Stanford.EDU [171.67.219.83]) by ietfa.amsl.com (Postfix) with ESMTP id EFD6721F85BB for <pkix@ietf.org>; Thu, 31 May 2012 22:14:34 -0700 (PDT)
Received: from smtp.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 410BD45CC20; Thu, 31 May 2012 22:14:33 -0700 (PDT)
Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.67.225.134]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.stanford.edu (Postfix) with ESMTPS id 2541445E0C4; Thu, 31 May 2012 22:14:31 -0700 (PDT)
Received: by windlord.stanford.edu (Postfix, from userid 1000) id E36F92F435; Thu, 31 May 2012 22:14:30 -0700 (PDT)
From: Russ Allbery <rra@stanford.edu>
To: denis.pinkas@bull.net
In-Reply-To: <OF2C174BF8.9661F84B-ONC1257A0F.0035B9F3-C1257A0F.0059FC5B@bull.net> (denis pinkas's message of "Thu, 31 May 2012 18:22:53 +0200")
Organization: The Eyrie
References: <4FC6AEDA.4010709@cs.tcd.ie> <OF2C174BF8.9661F84B-ONC1257A0F.0035B9F3-C1257A0F.0059FC5B@bull.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.4 (gnu/linux)
Date: Thu, 31 May 2012 22:14:30 -0700
Message-ID: <8762bbaa15.fsf@windlord.stanford.edu>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Cc: pkix <pkix@ietf.org>, Jim Schaad <ietf@augustcellars.com>
Subject: Re: [pkix] RFC 5742 review of draft-hotz-kx509 and about RFC 4211
X-BeenThere: pkix@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: PKIX Working Group <pkix.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pkix>, <mailto:pkix-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pkix>
List-Post: <mailto:pkix@ietf.org>
List-Help: <mailto:pkix-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pkix>, <mailto:pkix-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 Jun 2012 05:14:36 -0000

denis.pinkas@bull.net writes:

> I skimmed through the document and read the following two sentences:

>    The public key in the request is sent in the clear, and without any
>    guarantees that the requestor actually possesses the corresponding
>    private key.

>    [RFC4211], Appendix C contains a more detailed discussion of why 
>    proof-of-possession is important.

> I have concerns with both sentences.

> [RFC4211] is incorrect and this has security implications on the
> proposed protocol.

Hi Denis,

As Henry has mentioned, we have the limitation with this particular
document that we're attempting to document an existing, deployed protocol
sufficiently that interoperable implementations can be created.  This
protocol is deficient in multiple ways, and designing a better protocol is
expected follow-on work.  Changing something fundamental, such as
requiring confidentiality in this protocol exchange, would defeat the
point of the current work.

Therefore, I think that any remedy here should be limited to clearly
documenting the issue in the Security Considerations section rather than
changing the protocol.

If I'm understanding your message properly, you're saying that there is a
partial defense against the lack of proof-of-possession by adding
confidentiality protection to the exchange.  I'm not sure in this context
whether this really changes the security analysis of this protocol, given
that no confidentiality is used.  But if I'm missing something, could you
suggest something that we could add to Security Considerations?

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>