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

Ralf Skyper Kaiser <skyper@thc.org> Sun, 03 November 2013 17:18 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 5679F21F9F88 for <tls@ietfa.amsl.com>; Sun, 3 Nov 2013 09:18:19 -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 ujWRMIeyM9Su for <tls@ietfa.amsl.com>; Sun, 3 Nov 2013 09:18:14 -0800 (PST)
Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id B9ED121F9FA5 for <tls@ietf.org>; Sun, 3 Nov 2013 09:18:13 -0800 (PST)
Received: by mail-ie0-f182.google.com with SMTP id as1so10945827iec.27 for <tls@ietf.org>; Sun, 03 Nov 2013 09:18:13 -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=RiF5WRogtBeq0nmuqUl8ZB86+Hnjg5ISmbmK3TA9/jk=; b=HtZzNfXHmOglL8Pc22nAHbf3Knw2P+WnEexP1AjM5WNWm1tRgX2mol7q+6UUL7cVYI f2JLQTj3tTgPxWllgvu1Bq+9rrDy24gWOhKkh1tJBa1ubp36qBMoz8r51lu9MT9mVviZ UCeTVXiKtDrx0r/DXgvbZ9bWU4EO2/Uo3tyFg=
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=RiF5WRogtBeq0nmuqUl8ZB86+Hnjg5ISmbmK3TA9/jk=; b=cjXqcXxz13fbaVKropL2ssG8Vv6dpXEtPS05dYypTtPoefZp5ekInrIXrzv0kejBnR HR2zTo+RSFGpW4TWuXE7p4e/hJpXCfB6dzxTRV5257br1ZAvnd0wD3tOMDcdCNaYRjCD HdAG/1TJlgvNmRXK6ww3sEBXeeXWYD18D5HEOQC4qNjCDSQkidryWP7vkF65riJqhqeM vTz/cGfx34HcLRJfRfF35MCGprohUmxY3SlauGql6bHJ1aGI0CVehdZxm4Vm/4OSpCoJ abl1zPqnI9qiTsAmbMXvn5Ie6JP9pimflIDcXXIwUThOFf4CtvW+zfoE1CEa8xtnCOG8 bGZA==
X-Gm-Message-State: ALoCoQlVdGLBnZVuHQZn9Wi4r701wksHivtu1VbekHFxn6UaVdDlA7y1Ccz6oLt4vj+8+lroEEoI
MIME-Version: 1.0
X-Received: by 10.50.128.137 with SMTP id no9mr9131943igb.36.1383499093148; Sun, 03 Nov 2013 09:18:13 -0800 (PST)
Received: by 10.64.231.100 with HTTP; Sun, 3 Nov 2013 09:18:13 -0800 (PST)
X-Originating-IP: [87.106.82.87]
In-Reply-To: <CABqy+soTKjtU69mf9F6um8FsNNaztv2hXS6iPJe6P=D-A_6b0w@mail.gmail.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <CABqy+soTKjtU69mf9F6um8FsNNaztv2hXS6iPJe6P=D-A_6b0w@mail.gmail.com>
Date: Sun, 03 Nov 2013 17:18:13 +0000
Message-ID: <CA+BZK2pD-=PCEfe2mHKEmu8W_bWkZ+dzt=9iQaVsJ7ug8-tQ6A@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
To: Robert Ransom <rransom.8774@gmail.com>
Content-Type: multipart/alternative; boundary="047d7b10cf0dfea48404ea48fba9"
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 17:18:26 -0000

Hi,



Renegotiation is a critical feature of TLS, which serves multiple purposes.

>
> * Renegotiation allows rekeying of a session.  This is absolutely
> required for any ciphersuite based on a block cipher with a 128-bit or
> smaller block, because block cipher modes' security properties degrade
> after they are used for more than some number of blocks.
>

Can you be more specific about 'some number of blocks'? This number is
astronomically large. Reconnect the TLS if you have to.


>
> * 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.



> * A TLS connection can be established by a fully trusted device which
> knows a password or other application-layer authorization credential,
> authorized to perform some operations using messages within the TLS
> connection, and then transferred with the help of renegotiation to a
> less trusted device to actually perform those operations.  This is
> similar to the preceding use, but to provide 'sideways secrecy' rather
> than forward secrecy.
>

Renegotiation comes at a huge cost of complexity (not just from a
development point of view but also from a security audit point of view).
All features of re-negotiation can be achieved by re-connecting.
Re-connecting is well understood, easily tested and audited.


>
> * One version of the Tor 'link protocol' (Tor's term for its outer
> TLS-based connection protocol) uses renegotiation to provide secrecy
> for the server's certification chain against purely passive attackers.
>  The purposes above could be served by applying a one-way function to
> the originally derived key material, then discarding the old keys;
> this purpose cannot.
>

reconnect!

regards,

ralf

>
>
> Robert Ransom
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>