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

Ralf Skyper Kaiser <skyper@thc.org> Sun, 03 November 2013 23:48 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 632E111E8259 for <tls@ietfa.amsl.com>; Sun, 3 Nov 2013 15:48:21 -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 d8SsF7NKcEWk for <tls@ietfa.amsl.com>; Sun, 3 Nov 2013 15:48:17 -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 4132A11E8252 for <tls@ietf.org>; Sun, 3 Nov 2013 15:48:17 -0800 (PST)
Received: by mail-ie0-f174.google.com with SMTP id qd12so11216624ieb.33 for <tls@ietf.org>; Sun, 03 Nov 2013 15:48:16 -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=R7s2dLvPqG/v5Lez32XKcSgvniA6UanDH2lA8lmQyO4=; b=G81mTnwucmG6dFfkFmW6WLbp/l7N5+/P6JUajAWxH47i90lbZvz/uQoL5LGN79+Jk9 z2KIQKETiGRgSKG+yo2at58V2/SoJAJ0MboxkU4SjqHLTMWo9bUSUTSNemanx8Jd6Q8b BzEiOtZolexlwj9zb5D0gj4pD1T+Cf7OOxfoU=
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=R7s2dLvPqG/v5Lez32XKcSgvniA6UanDH2lA8lmQyO4=; b=VirSNujE8yU+PNsXLhb6XrTGjQpkP4I4rEGR6vOvLlWttPXypPNKn0vyQexcWPI+zM cyUckN++fbGah2pmBJpz4yZVX4U1vgLCs8wHHW/7RUbfK8/m0MHaXpTBL9nqrNlWqqnA fFfeRHE6NZmoOFPSROxCth0P4Ha6Vti8Dd1i0274uwPlcuyywHZRmaJ2TExnlTXklN90 1Dd5qjxG6eCT76YsfBGvR8Vm2rl1lCnGAKSF/8hCJFPMBgCwWztaUkLYHJ7DU8IfAoIO zJ5Rg5SwtGQz4o7VzidXaRBzpAxyvPefCYJQB97gRHPZ87/a3SSmQpS1Vne30YQQO/Id poYA==
X-Gm-Message-State: ALoCoQkrErE7ZWKmniley/80ASele+iURaMWe1ShDJDvuwS6qcNoyjAA8hNkjsCzNNWFOXQm9e5g
MIME-Version: 1.0
X-Received: by 10.50.131.163 with SMTP id on3mr2333052igb.46.1383522496780; Sun, 03 Nov 2013 15:48:16 -0800 (PST)
Received: by 10.64.231.100 with HTTP; Sun, 3 Nov 2013 15:48:16 -0800 (PST)
X-Originating-IP: [87.106.82.87]
In-Reply-To: <CACsn0c=-3gP_ofXGz38o2yx2181WqUa5E1wVSJcr+x-wirQRwg@mail.gmail.com>
References: <CACsn0cnS7LWo+AN1maw-KYGhWXY1BLNPNOjiL-Y3UU3zG-Je_Q@mail.gmail.com> <20131031230955.GB32733@gmail.com> <5273FC73.8010303@gnutls.org> <CA+BZK2pZ=AFs5qw8dTbiV+s0KdSeFJH1-Z+UbaJZnQwHNgdXuA@mail.gmail.com> <4A91BFED-6C57-47AC-8815-ACAC50E23491@checkpoint.com> <CA+BZK2omT6pB05gM-dYvM__pJpqmMQBCVpLyFpVV7heLfnD18w@mail.gmail.com> <CACsn0c=-3gP_ofXGz38o2yx2181WqUa5E1wVSJcr+x-wirQRwg@mail.gmail.com>
Date: Sun, 3 Nov 2013 23:48:16 +0000
Message-ID: <CA+BZK2q9BjjiHLXWsA3cc7Qma8QUv5z-qiiA-A6pimwPPbX3=Q@mail.gmail.com>
From: Ralf Skyper Kaiser <skyper@thc.org>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: multipart/alternative; boundary=047d7b2e0d1ff5b14904ea4e6e6e
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:48:21 -0000

Hi,

Yoav, Waton did not mean to 'move the entire client side auth' into the
application layer.

Instead it is possible to remove renegotiation from the standard and still
be able to authenticate clients by certificate without UI pop up.

In the earlier example with HTTPS and 'Login with certificate button': The
button could indicate to the client to establish a new TLS connection and
authenticate the client by certificate (without the need of renegotiation).
There are endless options to make this neatly without UI pop-up as well.


regards,

ralf



On Sun, Nov 3, 2013 at 11:28 PM, Watson Ladd <watsonbladd@gmail.com> wrote:

> On Sun, Nov 3, 2013 at 3:23 PM, Ralf Skyper Kaiser <skyper@thc.org> wrote:
> > Hi Yoav,
> >
> > i agree with the UI issue. That's the only use that I can see where
> > renegotiation is useful.
> >
> > I would guess here that 99% of all TLS users (if not 99.99%) do not need
> > this feature.
> >
> > The 99.99% of all users would have to carry the risk of complexity to
> > satisfy the need of the 0.01% of users.
> >
> > There are hopefully other ways to satisfy the need of the 0.01% without
> the
> > 99.99% of us having to take an extra risk (complexity). (Anyone? Ideas
> are
> > welcome...).
> Kick it into the application layer.
> >
> > (ps when i'm speaking about complexity i do not mean the working hours it
> > would take to write the code [earlier replies by somebody indicated this]
> > but rather the security complexity [making mistakes and auditing a
> > process/procedures/... that is rarely used]).
> >
> > regards,
> >
> > ralf
> >
> >
> >
> >
> > On Sun, Nov 3, 2013 at 7:18 PM, Yoav Nir <ynir@checkpoint.com> wrote:
> >>
> >>
> >> On Nov 3, 2013, at 9:03 AM, Ralf Skyper Kaiser <skyper@thc.org> wrote:
> >>
> >> > 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.
> >> >
> >>
> >> Hi, Ralf
> >>
> >> The one use of renegotiation that I'm aware of, is for overcoming a UI
> >> issue in browsers. If you do a TLS handshake with mutual authentication
> (so
> >> the server sends a CertReq), the browser pops up a dialog box with all
> the
> >> certificates you might have. Website designers with to avoid that,
> >> especially on the welcome screen, so the web server does not send a
> CertReq.
> >> Instead, they present a welcome screen with a button or link that says
> >> "Login with certificates" Clicking that performs a regular SSL
> handshake (or
> >> does nothing at all if the connection is already established), but when
> the
> >> request comes in ("GET /login_with_certs HTTP/1.1"), the web server
> sends a
> >> HELLO_REQUEST, and in the resulting handshake it sends the CertReq, so
> the
> >> pop-up appears when the user *is* expecting it.
> >>
> >> I totally agree that renegotiation for rekeying is useless for people
> who
> >> are not doing DES-CBC and 3DES-CBC. It's even superfluous for them in
> most
> >> cases (you're pretty save doing 500,000,000 blocks, and that's 4 GB in
> 3DES.
> >> How many sites do you browse with 4 GB?  Maybe downloading stuff…)
> >>
> >> But before we can drop renegotiation from the standards, or recommend
> that
> >> implementors don't implement it, we need an alternate mechanism to
> upgrade
> >> from server-authenticated to mutually-authenticated within the same
> session.
> >> That is a real market need. How about allowing a CertReq sent from the
> >> server to the client in the middle of a connection, followed by the
> client
> >> sending a Certificate and Certificate Verify. For simplicity, we could
> >> always do that after the Finished, so that it's always
> Server-authenticated
> >> session when the Finished is sent.
> >>
> >> Yoav
> >>
> >
> >
> > _______________________________________________
> > TLS mailing list
> > TLS@ietf.org
> > https://www.ietf.org/mailman/listinfo/tls
> >
>
>
>
> --
> "Those who would give up Essential Liberty to purchase a little
> Temporary Safety deserve neither  Liberty nor Safety."
> -- Benjamin Franklin
>