Re: [TLS] Rethink TLS 1.3

Joseph Salowey <joe@salowey.net> Tue, 25 November 2014 21:10 UTC

Return-Path: <joe@salowey.net>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD61A1A6EEF for <tls@ietfa.amsl.com>; Tue, 25 Nov 2014 13:10:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VetCoPwH-bL6 for <tls@ietfa.amsl.com>; Tue, 25 Nov 2014 13:10:45 -0800 (PST)
Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 358951A1EED for <tls@ietf.org>; Tue, 25 Nov 2014 13:10:45 -0800 (PST)
Received: by mail-qa0-f42.google.com with SMTP id j7so1039283qaq.1 for <tls@ietf.org>; Tue, 25 Nov 2014 13:10:44 -0800 (PST)
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=SboeU7lV3V6JxWVbQv0OsR78U1iHqhsw2p64YxRH3Vk=; b=fKHY2WqZJgXdYQh2G9rYgKgr0FmVELbNtwo9DG5c5Tg5ASTp/SZbLyWQDCv9lmCmJC Q0vF2scNS7FPpqVWLIICtDvjNR8sGv2sRY+SyvTU2E6C7uuuXhu9ZSQNh0pKLYCjJAop VA36cG1q5zJN4aMKxG8wdCO7jrgCYnRjyE9NuxIVhk0lE0f22fQ6E+iVIr2lXCgUkTW6 PmYiXq55Yqa7LhYtfeYXiQpYRVTOXOWN30t/alN8kYVNQ3MrcH9NRPj0ho8WT9DK3aMI JVl1FtoAiWXe9Gf1DH/lvF+1c16yyVeggK7Vo9RfBTZfoK17KiyvAl8347M/TpTYrF2W dclA==
X-Gm-Message-State: ALoCoQknbSTn1eMGE/KocFj2yLHgPiUWHXMmjHS2Kxal+gBmBNn5TjWkPc5sV6AlT5jDlrVj1fk5
MIME-Version: 1.0
X-Received: by 10.224.37.133 with SMTP id x5mr40341698qad.59.1416949844451; Tue, 25 Nov 2014 13:10:44 -0800 (PST)
Received: by 10.96.215.170 with HTTP; Tue, 25 Nov 2014 13:10:44 -0800 (PST)
X-Originating-IP: [2601:8:b300:a5:c1b1:2530:58d2:4cbb]
In-Reply-To: <CACsn0c=7fzAmshr7qamiLZdRUNs8kexQPR4E6n3teqNi4HzOjQ@mail.gmail.com>
References: <20141124105948.GH3200@localhost> <20141124165601.0E7A71B004@ld9781.wdf.sap.corp> <CACsn0ckcpNYJbnb+vd=nazXQhN5m3=L1DxO+KnLXMVyWOQ-PUQ@mail.gmail.com> <3283678.0WkSFC7mCs@pintsize.usersys.redhat.com> <CACsn0c=7fzAmshr7qamiLZdRUNs8kexQPR4E6n3teqNi4HzOjQ@mail.gmail.com>
Date: Tue, 25 Nov 2014 13:10:44 -0800
Message-ID: <CAOgPGoAEyH4MRAjGHyUg1c9PuY2c6SmfB+6jgBegRi6dvVchDQ@mail.gmail.com>
From: Joseph Salowey <joe@salowey.net>
To: Watson Ladd <watsonbladd@gmail.com>
Content-Type: multipart/alternative; boundary=001a11c1f4ba24d00e0508b5585b
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/u7pt-7RIPkANYaJoj4FsVuR3v9g
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Rethink TLS 1.3
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 25 Nov 2014 21:10:48 -0000

This thread is wandering a bit off topic.  TLS 1.3 is a work in progress.
If you have suggestions on how to improve it please create a Pull Request (
https://github.com/tlswg/tls13-spec) or post the specific details to the
list.  Keep in mind that the discussions on starting over with TLS 1.3 are
not in scope as the Working Group has consensus to follow the current
path.  Also, as the Working Group removes and deprecates less secure
protocol options we need to keep in mind the reality of current
deployments.  Deprecating or removing widely deployed options requires
careful consideration, since these actions may result in a protocol that is
unusable and/or not deployable.

Cheers,

Joe

On Tue, Nov 25, 2014 at 7:14 AM, Watson Ladd <watsonbladd@gmail.com> wrote:

> On Tue, Nov 25, 2014 at 6:46 AM, Hubert Kario <hkario@redhat.com> wrote:
> > On Monday 24 November 2014 09:35:20 Watson Ladd wrote:
> >> On Mon, Nov 24, 2014 at 8:56 AM, Martin Rex <mrex@sap.com> wrote:
> >> > Nico Williams wrote:
> >> >> Henrick Hellström wrote:
> >> >>> Yes, but the point I am trying to make, is that if the implied goal
> >> >>> is to make TLS resilient even against BEAST/CRIME style attacks, the
> >> >>> threat model should be defined accordingly. It makes little sense to
> >> >>> ask for cryptographic review of the protocol, if it is inherently
> >> >>> unclear exactly what kind of threats the protocol is designed to
> >> >>> withstand.
> >> >>
> >> >> BEAST/CRIME are dramatic demonstrations of the capabilities of
> attackers
> >> >> in the Internet threat model.
> >> >
> >> > Nope.  BEAST, CRIME and Poodle are pretty boring demonstrations of the
> >> > ridiculous insecurity of WebBrowsers in their default
> > configuration.https://tcms.engineering.redhat.com/case/295339/
> >>
> >> So it's possible to get my Paypal login cookie if I browse to a
> >> malicious site on a fully patched browser? Because that's what BEAST
> >> enabled. Are you saying it's fine that SSL v3.0 leaks one byte per
> >> connection? Because that's POODLE. All of this was known in 2004, and
> >> not fixed in TLS 1.2
> >
> > are you suggesting that AEAD ciphers are vulnerable to them? based on
> what
> > mechanism?
> >
> > I mean, sure they are not mandatory or the only TLS 1.2 compatible
> ciphers,
> > but there are there...
>
> Fixed means fixed, not "you get to play choose your own ciphersuite,
> where most of the options are wrong". It means aggressively removing
> ciphers and protocols known to be weak. Instead of considering the job
> done when secure options have been added, we should consider it done
> when the insecure options have been removed.
>
> Sincerely,
> Watson Ladd
> >
> > --
> > Regards,
> > Hubert Kario
>
>
>
> --
> "Those who would give up Essential Liberty to purchase a little
> Temporary Safety deserve neither  Liberty nor Safety."
> -- Benjamin Franklin
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>