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

Ralf Skyper Kaiser <skyper@thc.org> Sun, 03 November 2013 17:03 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 A056521E80FB for <tls@ietfa.amsl.com>; Sun, 3 Nov 2013 09:03:53 -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 YGgr395re3f3 for <tls@ietfa.amsl.com>; Sun, 3 Nov 2013 09:03:49 -0800 (PST)
Received: from mail-ie0-x22e.google.com (mail-ie0-x22e.google.com [IPv6:2607:f8b0:4001:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id ABB1111E8196 for <tls@ietf.org>; Sun, 3 Nov 2013 09:03:49 -0800 (PST)
Received: by mail-ie0-f174.google.com with SMTP id qd12so10589976ieb.19 for <tls@ietf.org>; Sun, 03 Nov 2013 09:03:49 -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=ZQ2rOeSnZLX3PyUGN1UBVHrRewnA/vFMWX3ovuzFuuE=; b=WUoYpqs7Nbz3kufAhagKgXC0BeaI4FLWXpaii5ytggzMpPcwhQYpjuSCEd17+myyKf v6ERwMFwdu4nQF78hX2GdNzleu+iPGdsCjmHdEzCLfF1iWehA5lIuk/9/K/4niHXE3/i n29rE4gIBaf2LZ5dC70bHr51v/X5/jI8NpGM4=
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=ZQ2rOeSnZLX3PyUGN1UBVHrRewnA/vFMWX3ovuzFuuE=; b=MImZUWOCNZzEsgHWH8hF6uWMVgYCOwjjwNCJOJaNhvaVVLMf1u44ACgM1QhXywxtld JSvliRAeWylGVboh11rVf2EAxOfRHCmyCZ1W01j/0c99t3T486880K0R3tx4GcW+laZF IrOvJRR/MPPwPhOozQQ+QJkXPRwoQ3gyxbjUkMRikcBkAiiYDRDjamNxsHxGgjusOgIN oO3M+Rc5IDhYE3lw5Omfj5Y7RGzLAioANBkhAa+Or+/BwcVaEpEAarOCXhOsMf3MpvoS G6ElNKXNkgr+E87Z4Nk3RDVUCueH3WM0MPMH411QoP5tDcqskrCDmQ6LjUFBnEAdbDOe LlYg==
X-Gm-Message-State: ALoCoQny9t7CitX9LfmNOSWzQocLJBr7l+F72KtcjiPx703dFW9LlactS7BlsjPV9TICpgXl8i8b
MIME-Version: 1.0
X-Received: by 10.50.30.229 with SMTP id v5mr9256467igh.27.1383498229088; Sun, 03 Nov 2013 09:03:49 -0800 (PST)
Received: by 10.64.231.100 with HTTP; Sun, 3 Nov 2013 09:03:48 -0800 (PST)
X-Originating-IP: [87.106.82.87]
In-Reply-To: <5273FC73.8010303@gnutls.org>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <20131031230955.GB32733@gmail.com> <5273FC73.8010303@gnutls.org>
Date: Sun, 3 Nov 2013 17:03:48 +0000
Message-ID: <CA+BZK2pZ=AFs5qw8dTbiV+s0KdSeFJH1-Z+UbaJZnQwHNgdXuA@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
Content-Type: multipart/alternative; boundary=047d7bacc30c7e1c8704ea48c8ad
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:03:53 -0000

Hi,

avoid renegotiation. It serves no purpose and only adds complexity. It is
so much more secure to kill and re-establish the TLS if the counters run
out instead of renegotiating.

This might be better placed in a higher layer:
It is desirable for the server to know how the client authenticated the
server. E.g. currently the a server does not know if the client matched the
Server's Certificate's CommonName against the URI or if the client
performed full certificate chain authentication. Currently the server
blindly trusts the client (e.g. user) to check the certificate chain and
match the URI<>CN.

(An example are jabber servers using TLS. Most clients allow the user to
accept any server certificate without verification. The jabber server has
no way to detect which client performed proper certificate verification and
CN<>URI match).


regards,

ralf



On Fri, Nov 1, 2013 at 7:09 PM, Nikos Mavrogiannopoulos <nmav@gnutls.org>wrote;wrote:

> On 11/01/2013 12:09 AM, Nico Williams wrote:
> >
> > My list:
> >
> >  - It should be deployable, that's first; in particular, it needs to be
> >    deployable with ECDH PFS key exchanges.
>
> (unrelated) It would actually be nice to have a wiki for anyone to add
> his wish list there.
>
>
> >  - Renegotiation should be replaced with an NPN-like extension that
> >    provides privacy to the TLS client principal name.
>
> I don't think anyone can avoid renegotiation. Since the TLS packet
> counters are 64-bit (and more importantly in DTLS 48-bits), one cannot
> avoid renegotiation to reset the counters.
>
> (nevertheless, all the practical VPNs I've seen using TLS, don't use
> renegotiation, they just re-establish the session).
>
> regards,
> Nikos
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>