Re: [pkix] RFC 5742 review of draft-hotz-kx509 and about RFC 4211
denis.pinkas@bull.net Fri, 01 June 2012 07:24 UTC
Return-Path: <denis.pinkas@bull.net>
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 1B1F321F861D for <pkix@ietfa.amsl.com>; Fri, 1 Jun 2012 00:24:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.248
X-Spam-Level:
X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001]
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 txBWCFg+SVks for <pkix@ietfa.amsl.com>; Fri, 1 Jun 2012 00:24:17 -0700 (PDT)
Received: from odin2.bull.net (odin2.bull.net [129.184.85.11]) by ietfa.amsl.com (Postfix) with ESMTP id A173821F861C for <pkix@ietf.org>; Fri, 1 Jun 2012 00:24:16 -0700 (PDT)
Received: from MSGC-003.bull.fr (MSGC-003.frcl.bull.fr [129.184.87.131]) by odin2.bull.net (Bull S.A.) with ESMTP id D0960120036; Fri, 1 Jun 2012 09:24:14 +0200 (CEST)
In-Reply-To: <8762bbaa15.fsf@windlord.stanford.edu>
References: <4FC6AEDA.4010709@cs.tcd.ie> <OF2C174BF8.9661F84B-ONC1257A0F.0035B9F3-C1257A0F.0059FC5B@bull.net> <8762bbaa15.fsf@windlord.stanford.edu>
To: Russ Allbery <rra@stanford.edu>, hotz@jpl.nasa.gov
MIME-Version: 1.0
X-KeepSent: EBA66BA3:DC95987A-C1257A10:00278E13; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.5.2 August 10, 2010
From: denis.pinkas@bull.net
Message-ID: <OFEBA66BA3.DC95987A-ONC1257A10.00278E13-C1257A10.0028AC03@bull.net>
Date: Fri, 01 Jun 2012 09:24:13 +0200
X-MIMETrack: Serialize by Router on MSGC-003/SRV/BULL(Release 8.5.2FP1|November 29, 2010) at 01/06/2012 09:24:14, Serialize complete at 01/06/2012 09:24:14
Content-Type: multipart/alternative; boundary="=_alternative 00287E8CC1257A10_="
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 07:24:18 -0000
First of all, thank you for both of you for your fast response. I am not arguing there is an RFC 5742 conflict with this document. Since you said that is an attempt to document an existing deployed protocol, we cannot change it. Since you said that designing a better protocol is an expected follow-on work, I raise the question to both the editors and the WG chairs whether the document should be on the experimental track rather than on the informational track. Clearly, I believe that only changes to the security consideration sections should be made, keeping in mind that confidentiality an integrity protection can be done at lower layers. This is what the security considerations section should recommend. Finally, I believe an errata on RFC 4211 should be prepared, but this is a separate concern with Jim. Denis De : Russ Allbery <rra@stanford.edu> A : denis.pinkas@bull.net Cc : hotz@jpl.nasa.gov, Jim Schaad <ietf@augustcellars.com>, pkix <pkix@ietf.org> Date : 01/06/2012 07:20 Objet : Re: [pkix] RFC 5742 review of draft-hotz-kx509 and about RFC 4211 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/>
- [pkix] RFC 5742 review of draft-hotz-kx509 Stephen Farrell
- Re: [pkix] RFC 5742 review of draft-hotz-kx509 an… denis.pinkas
- Re: [pkix] RFC 5742 review of draft-hotz-kx509 an… Russ Allbery
- Re: [pkix] RFC 5742 review of draft-hotz-kx509 an… denis.pinkas
- Re: [pkix] RFC 5742 review of draft-hotz-kx509 an… Henry B. Hotz
- Re: [pkix] [Ietf-krb-wg] RFC 5742 review of draft… Sam Hartman
- Re: [pkix] RFC 5742 review of draft-hotz-kx509 an… Stephen Kent
- [pkix] Fwd: RFC 5742 review of draft-hotz-kx509 Stephen Farrell