[Lurk] review of draft-erb-lurk-rsalg-00

"Fossati, Thomas (Nokia - GB)" <thomas.fossati@nokia.com> Sat, 02 April 2016 21:40 UTC

Return-Path: <thomas.fossati@nokia.com>
X-Original-To: lurk@ietfa.amsl.com
Delivered-To: lurk@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD9512D5A8; Sat, 2 Apr 2016 14:40:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level:
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovwTX19ScGnu; Sat, 2 Apr 2016 14:40:00 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B285D12D5A1; Sat, 2 Apr 2016 14:39:57 -0700 (PDT)
Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 27A96E95BCA6D; Sat, 2 Apr 2016 21:39:52 +0000 (GMT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u32Ldt47000801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 2 Apr 2016 21:39:55 GMT
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u32Ldthx012227 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 2 Apr 2016 23:39:55 +0200
Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.8]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Sat, 2 Apr 2016 23:39:55 +0200
From: "Fossati, Thomas (Nokia - GB)" <thomas.fossati@nokia.com>
To: "draft-erb-lurk-rsalg@ietf.org" <draft-erb-lurk-rsalg@ietf.org>
Thread-Topic: review of draft-erb-lurk-rsalg-00
Thread-Index: AQHRjSgxLdvcKsY9MEOp/jtebfUpbA==
Date: Sat, 02 Apr 2016 21:39:54 +0000
Message-ID: <D32606D6.629BA%thomas.fossati@alcatel-lucent.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.2.160219
x-originating-ip: [135.239.27.41]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <AC73FAA8BA698D41B9CFA11097CC2DCB@exchange.lucent.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/lurk/vEctpjZM-lbVp-ol9e5sT9W1IDA>
Cc: "lurk@ietf.org" <lurk@ietf.org>
Subject: [Lurk] review of draft-erb-lurk-rsalg-00
X-BeenThere: lurk@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Limited Use of Remote Keys <lurk.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/lurk>, <mailto:lurk-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/lurk/>
List-Post: <mailto:lurk@ietf.org>
List-Help: <mailto:lurk-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/lurk>, <mailto:lurk-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 02 Apr 2016 21:40:02 -0000

Hi,

thanks for the draft. The RSALG idea is really nice.

A few comments:

- Re: missing support for TLSv1.x x>2.  We should probably think this a
bit more: TLSv1.3 would probably be in the wild by the time LURK is
finished?

- There is no explicit requirement on the LURK box in terms of the
algorithms it needs to support.  What is the assumption?  Probably there
should to be an interface to allow the Server to know about the LURK box
capabilities, so that it can negotiate TLS parameters with the client that
won't fail the handshake mid-air?

- I see the Server Key Exchange is still TBD, though a few things can be
extrapolated from Section 4.  I might be missing something, but I don't
understand how the {client,server}_version fields would be relevant to a
server_kx request?  Which makes me wonder whether the request types could
be refined a bit: it looks like server_kx and rsalg requests are different
enough to be separate entities?  Also, a RFC7627 version of rsalg would be
quite different from the one currently defined.  Any intention to support
it?

- Last para of Section 3.2: "An attacker who later gains access to
KeyOwner [...]" s/KeyOwner/Server/?

- Cert/key rotation functionality is missing  and I really think this
should really be a requirement for any LURK proposal.


There's a further point that I'm not very sure (I'd like to hear other
people's opinion): the security of TLS is not limited to the
signature/decryption process.  A good pseudo-random source at the Server
is also critical.  Would it be within LURK scope to let the Key Owner
audit relevant session parameters?  This could help if the Server is
compromised -- or if it's just misbehaving.


Cheers, Thomas.