Re: [secdir] SecDir review of draft-ietf-keyprov-pskc-05

Vincent Roca <vincent.roca@inrialpes.fr> Mon, 17 May 2010 10:13 UTC

Return-Path: <vincent.roca@inrialpes.fr>
X-Original-To: secdir@core3.amsl.com
Delivered-To: secdir@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3513828C0E3; Mon, 17 May 2010 03:13:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.272
X-Spam-Level:
X-Spam-Status: No, score=-4.272 tagged_above=-999 required=5 tests=[AWL=-0.623, BAYES_50=0.001, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gS5CTxokazdz; Mon, 17 May 2010 03:13:45 -0700 (PDT)
Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by core3.amsl.com (Postfix) with ESMTP id 1514D3A69A1; Mon, 17 May 2010 03:08:55 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.53,247,1272837600"; d="scan'208";a="62933274"
Received: from ornon.inrialpes.fr (HELO [194.199.24.115]) ([194.199.24.115]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 17 May 2010 12:08:46 +0200
Message-ID: <4BF115AD.5010400@inrialpes.fr>
Date: Mon, 17 May 2010 12:08:45 +0200
From: Vincent Roca <vincent.roca@inrialpes.fr>
Organization: INRIA
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 ThunderBrowse/3.2.8.1
MIME-Version: 1.0
To: Philip Hoyer <phoyer@actividentity.com>
References: <4BDF2F06.2030406@inrialpes.fr> <5BFE9E473DBFC24CA87F18F29B3F0AC406890884@sur-corp-ex-02.corp.ad.activcard.com>
In-Reply-To: <5BFE9E473DBFC24CA87F18F29B3F0AC406890884@sur-corp-ex-02.corp.ad.activcard.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: draft-ietf-keyprov-pskc.all@tools.ietf.org, iesg@ietf.org, secdir@ietf.org
Subject: Re: [secdir] SecDir review of draft-ietf-keyprov-pskc-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 17 May 2010 10:13:47 -0000

Hello Philip,

I see we agree on most items (I removed them). Two comments:

> 5- section 13.1:
>     why isn't the IPsec/ESP not considered also as a third
>     solution to provide the confidentiality, integrity and sender
>     authentication services? Why do the authors only focus
>     on PCKS integrated or TLS solutions? It's not clear.
> [PH] the authors felt that the usage of the container was intended for
> application level interchange of keys. Especially in online scenarios
> where TLS is much more prevalent than IPSec. This does not mean that one
> could not envisage use of the PSKC over IPsec and hence use IPsec
> protection mechanisms.
>    
[VR] I understand. Thanks for the clarification.

> 9- section 13.3: it is said:
> "A weaker payload authenticity guarantee may be provided by the
>   transport layer if it is configured to digest each message it
>   transports."
>
>     Why is this feature necessarily weaker? The source can be
>     authenticated with the same level of security as if it was
>     done by the recipient end.
> [PH] it is weaker in the sense that the TLS endpoints could differ from
> the key provisioning endpoints. So in that sense the signature in the
> message would protect it from message sender to receiver.
>    
[VR] Said this way, I fully agree. I suggest you clarify the
I-D as well, e.g.:

"Authenticity guarantee may be provided by [...]. However, no authenticity
verification is possible once [...]. Since the TLS endpoints could 
differ from
the key provisioning endpoints, this solution is weaker than the previous
solution that relies on a digital signature of the PSKC."

Cheers,

     Vincent