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

Vincent Roca <> Mon, 17 May 2010 10:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3513828C0E3; Mon, 17 May 2010 03:13:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.272
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id gS5CTxokazdz; Mon, 17 May 2010 03:13:45 -0700 (PDT)
Received: from ( []) by (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 (HELO []) ([]) by with ESMTP/TLS/DHE-RSA-CAMELLIA256-SHA; 17 May 2010 12:08:46 +0200
Message-ID: <>
Date: Mon, 17 May 2010 12:08:45 +0200
From: Vincent Roca <>
Organization: INRIA
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20100330 Fedora/3.0.4-1.fc12 Thunderbird/3.0.4 ThunderBrowse/
MIME-Version: 1.0
To: Philip Hoyer <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [secdir] SecDir review of draft-ietf-keyprov-pskc-05
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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."