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

"Philip Hoyer" <> Tue, 18 May 2010 13:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CBEC73A698C; Tue, 18 May 2010 06:17:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.409
X-Spam-Status: No, score=0.409 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_50=0.001, HELO_EQ_FR=0.35]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zfIsq8URNeF5; Tue, 18 May 2010 06:17:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 224DF3A69A0; Tue, 18 May 2010 06:15:06 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BDCFF18393A; Tue, 18 May 2010 15:14:57 +0200 (CEST)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Tue, 18 May 2010 15:17:50 +0200
Message-ID: <>
In-Reply-To: <>
Thread-Topic: SecDir review of draft-ietf-keyprov-pskc-05
Thread-Index: Acr1qVnRMyhx+GMiSp++tqcZPZHluQA4xe/A
References: <> <> <>
From: Philip Hoyer <>
To: Vincent Roca <>
X-Mailman-Approved-At: Tue, 18 May 2010 06:32:05 -0700
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: Tue, 18 May 2010 13:17:57 -0000

I have changed the draft to encompass your revised wording of point 2

Thanks for your help,


-----Original Message-----
From: Vincent Roca [] 
Sent: Monday, May 17, 2010 11:09 AM
To: Philip Hoyer
Subject: Re: SecDir review of draft-ietf-keyprov-pskc-05

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
> 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
> 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
verification is possible once [...]. Since the TLS endpoints could 
differ from
the key provisioning endpoints, this solution is weaker than the
solution that relies on a digital signature of the PSKC."