Re: [TLS] What would make TLS cryptographically better for TLS 1.3

Ralf Skyper Kaiser <skyper@thc.org> Sun, 03 November 2013 23:12 UTC

Return-Path: <skyper@thc.org>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939FF21E8127 for <tls@ietfa.amsl.com>; Sun, 3 Nov 2013 15:12:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.425
X-Spam-Level:
X-Spam-Status: No, score=-0.425 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.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 EkBFp9YWjL+1 for <tls@ietfa.amsl.com>; Sun, 3 Nov 2013 15:12:40 -0800 (PST)
Received: from mail-ie0-x230.google.com (mail-ie0-x230.google.com [IPv6:2607:f8b0:4001:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 697C921E812D for <tls@ietf.org>; Sun, 3 Nov 2013 15:12:33 -0800 (PST)
Received: by mail-ie0-f176.google.com with SMTP id u16so11410647iet.35 for <tls@ietf.org>; Sun, 03 Nov 2013 15:12:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thc.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=4oOBahAGkf+GJMF5oF9q9ueVkXcuGWm5d1620YttQK4=; b=dJDhO6Y1PrFeCNJr/BIBx/exqvJZ25EGTx31i8CMJIaBFxClJnqhn4PvtQ3wR8KzRS GGuCw0ZdaDYYd2qoKOkYflzPYm+fPWtVkmv972HaLA+18idlMyLbKiWGwzlyi51yXHXy UrQGT0VyoetXnlNCjwVijmKApHiVVCPADTDw0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=4oOBahAGkf+GJMF5oF9q9ueVkXcuGWm5d1620YttQK4=; b=YL75MD1caOEURz5b268I+Xj0ZniIr6UJSN/WXQ42WHCm0rHgLm8517ePMCQcrGoudn ITgUFVgOv3mKR+0b8aq9+oFzCFtF0MMzjs5Lc+J20d0ixFSWdg0ATzbosvVCyiU/9gF3 GuWljJE6rthvmIOhcTYve86Ho5kVnEGVjPlcSDCtu3YdQWr7TR73FjV6lHr4CzWBOjRV AkQIRIKBvVGNEb8yGxwUIIwQV0akxCtW4VJ86jYuBE73UKeBlJR31bPaFF8d0t0r2lCY lQ1HzKv16tYP9Kj4IgbNYsJrKlbtVGrzwT/bRSeY6pjlQaClUCbzfTRiauLeDjkOWsjz J5Fg==
X-Gm-Message-State: ALoCoQms8X+airg7OqJbiH6OZGvP8dh0VlM2/zhbOUe6XPNtZ5C/ZbGJTT47pxr4/XmWXvK6HfNS
MIME-Version: 1.0
X-Received: by 10.43.158.10 with SMTP id ls10mr8220424icc.20.1383520350845; Sun, 03 Nov 2013 15:12:30 -0800 (PST)
Received: by 10.64.231.100 with HTTP; Sun, 3 Nov 2013 15:12:30 -0800 (PST)
X-Originating-IP: [87.106.82.87]
In-Reply-To: <CABqy+sre3V5eZXotTYGj=dg4774B4TYQB3jpnQ_8JFg-N0W4Bw@mail.gmail.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <CABqy+soTKjtU69mf9F6um8FsNNaztv2hXS6iPJe6P=D-A_6b0w@mail.gmail.com> <CA+BZK2pD-=PCEfe2mHKEmu8W_bWkZ+dzt=9iQaVsJ7ug8-tQ6A@mail.gmail.com> <CABqy+sre3V5eZXotTYGj=dg4774B4TYQB3jpnQ_8JFg-N0W4Bw@mail.gmail.com>
Date: Sun, 3 Nov 2013 23:12:30 +0000
Message-ID: <CA+BZK2oRv-c7vKPqshhmgadg=DNWTnAXCvPrJubWhrUzNCgtXg@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
To: Robert Ransom <rransom.8774@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c1ead60d4ff404ea4def98
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] What would make TLS cryptographically better for TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 03 Nov 2013 23:12:44 -0000

Hi,

someone who can compromise the server to extract the currently used session
keys can also extract all future session keys (or at least is most likely
able to). There is no (practical) need or added security when the session
key is renegotiated every 15 minutes.

ralf



On Sun, Nov 3, 2013 at 8:30 PM, Robert Ransom <rransom.8774@gmail.com>wrote;wrote:

> On 11/3/13, Ralf Skyper Kaiser <skyper@thc.org> wrote:
>
> >> * Applications can also use renegotiation-based rekeying to improve
> >> forward secrecy; for example, the Mixminion specification
> >> (<
> >>
> https://github.com/nmathewson/mixminion-doc/blob/a661212831d2afc3200339b2634ca16452e3aeec/spec/minion-spec.txt
> >> >,
> >> section 4, line 1040) requires that relay-to-relay TLS connections be
> >> rekeyed using renegotiation every 15 minutes for this purpose.
> >>
> >
> > Mixminion falsely assume  that the security degrades if a connection is
> > live for more than 15 minutes. That's security wise not true. In today's
> > security design (TLS) the negotiated session key material is secure for
> > years (if not decades). Gone are the times when DES was used and DES
> could
> > be cracked in 24h and it was desirable to use a new DES key every 24
> hours.
> > Gone. Gone Gone.
> >
> > If you negotiate session keys that could be cracked within a year you
> > should not have negotiated those sessions keys in the first place.
>
> Mixminion correctly assumes that anyone who obtains a session key by
> compromising a server can use that key to decrypt all traffic
> protected by it, no matter how long brute-force search would have
> taken to find the key.
>
>
> Robert Ransom
>