[perpass] TLS/SSL Key Rotation

Yakov Shafranovich <yakov-ietf@shaftek.org> Tue, 03 September 2013 23:19 UTC

Return-Path: <yakov@shaftek.org>
X-Original-To: perpass@ietfa.amsl.com
Delivered-To: perpass@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D118021E8087 for <perpass@ietfa.amsl.com>; Tue, 3 Sep 2013 16:19:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.898
X-Spam-Level:
X-Spam-Status: No, score=-2.898 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
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 ey3PGCj8Xsaz for <perpass@ietfa.amsl.com>; Tue, 3 Sep 2013 16:19:21 -0700 (PDT)
Received: from mail-vb0-f44.google.com (mail-vb0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 50AD621E8055 for <perpass@ietf.org>; Tue, 3 Sep 2013 16:19:20 -0700 (PDT)
Received: by mail-vb0-f44.google.com with SMTP id e13so4421850vbg.17 for <perpass@ietf.org>; Tue, 03 Sep 2013 16:19:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:from:date:message-id:subject :to:content-type; bh=2W4kn2zUkMBebKRI1d4p1tTS5VLFf7taxBihhEOIX/0=; b=cIsDKlFwc+mye2DKvmWtPNIgjMahmSdOmrBghaz4Wo8W8l2gLMmi8rYPs1oSSCAW3q DimMKk23B3Y1SN64GSvIyZY7K8ABeah6nos92oZqWXm0vvNmYxJC6b9WCO1pgO3StXSo T/Wq9o+RGuB5UVEjoP6KZDIFrcIlGWhfOm+vE5mXzpstrDoc3SniGn50BLwqu+6O205g 7a1nj8G4kXga5KV5nvqNbEM/ZQsNHBrbXbXIEeFd0XLU5jtQqjx6sxWWqD/90XT660Do sdiV0OEGVqh2zsckURaVL/J+y/vsZXbKYGTQqRSNn5rLztivkv+U6/YadRZcS1J0HOF5 8EGw==
X-Gm-Message-State: ALoCoQnbzCYFYrRVGcd3Gy8FPr8O6nHTz/iMz2XlWLBeNcbR5Upf4RVVVa4Y5SKHhiPitxnBLLwX
X-Received: by 10.52.166.132 with SMTP id zg4mr4262vdb.71.1378250359353; Tue, 03 Sep 2013 16:19:19 -0700 (PDT)
MIME-Version: 1.0
Sender: yakov@shaftek.org
Received: by 10.52.183.4 with HTTP; Tue, 3 Sep 2013 16:18:49 -0700 (PDT)
X-Originating-IP: [96.244.132.139]
From: Yakov Shafranovich <yakov-ietf@shaftek.org>
Date: Tue, 03 Sep 2013 19:18:49 -0400
X-Google-Sender-Auth: bbR2XtmppcoKPv5kf6EdNJvJ-Ws
Message-ID: <CAPQd5oRJK60472CC3ZPT38QZo7Ld8TjN545-JQLasuDDNAfVDw@mail.gmail.com>
To: perpass@ietf.org
Content-Type: text/plain; charset="ISO-8859-1"
Subject: [perpass] TLS/SSL Key Rotation
X-BeenThere: perpass@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "The perpass list is for discussion of the privacy properties of IETF protocols and concrete ways in which those could be improved. " <perpass.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perpass>, <mailto:perpass-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/perpass>
List-Post: <mailto:perpass@ietf.org>
List-Help: <mailto:perpass-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perpass>, <mailto:perpass-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Sep 2013 23:19:29 -0000

[splitting threads]

On Tue, Sep 3, 2013 at 8:47 AM, Stephen Farrell
<stephen.farrell@cs.tcd.ie> wrote:
> On 09/03/2013 01:11 PM, Yakov Shafranovich wrote:
>> The CA/browser forum has begun some steps in this direction by
>> lowering validity of SSL server certificates to 18 months. Is there a
>> place for a discussion on recommending a lower time period for key
>> rotation with the ensuing implications for those who do not want/can
>> not use PFS?
>
> This list is a fine place for discussing that if you
> think that a shorter RSA key rollover duty cycle would
> impact on pervasive monitoring. I'm not clear as to
> how it would though. Have you some scenario in mind?
>

The scenario would be where the RSA key on the server is compromised
or forcefully disclosed via a court order or other legal mechanism.
The shorter the interval, the less data would be available to the
potential attacker. There has been media discussion about this with
the US Government [1] where providers are forced to hand over their
keys.

I would also point out that TLS/SSL is used in non web scenarios as
well. In cases of provider to provider SMTP, XMPP, SIP, etc.
connections, there is a lot more data that can be sucked up if the key
is compromised. Unlike web browsers, where there are some mechanisms
in place to warn the user, SMTP, XMPP, SIP, etc. connections on a
provider to provider level would be automated and no user may see the
warnings until after the fact.

Yakov

[1] http://news.cnet.com/8301-13578_3-57595202-38/feds-put-heat-on-web-firms-for-master-encryption-keys/