Re: [TLS] TLS@IETF101 Agenda Posted

Hubert Kario <hkario@redhat.com> Wed, 14 March 2018 12:40 UTC

Return-Path: <hkario@redhat.com>
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 F3C8A127275 for <tls@ietfa.amsl.com>; Wed, 14 Mar 2018 05:40:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.301
X-Spam-Level:
X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01] autolearn=ham autolearn_force=no
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 h03c7H3Ev384 for <tls@ietfa.amsl.com>; Wed, 14 Mar 2018 05:40:06 -0700 (PDT)
Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D70391271DF for <tls@ietf.org>; Wed, 14 Mar 2018 05:40:06 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 297A64040859; Wed, 14 Mar 2018 12:40:06 +0000 (UTC)
Received: from pintsize.usersys.redhat.com (ovpn-200-29.brq.redhat.com [10.40.200.29]) by smtp.corp.redhat.com (Postfix) with ESMTP id CE2492026DFD; Wed, 14 Mar 2018 12:39:58 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Wed, 14 Mar 2018 13:39:48 +0100
Message-ID: <12691059.D1o9753ySB@pintsize.usersys.redhat.com>
In-Reply-To: <C1970611-C781-41A8-87CA-D00629AC41E7@vigilsec.com>
References: <6140B7A6-A1C7-44BC-9C65-9BE0D5E1B580@sn3rd.com> <090F06AF-371D-4B11-91AA-BD80C1ADB4E9@fugue.com> <C1970611-C781-41A8-87CA-D00629AC41E7@vigilsec.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart4769022.ZPMkgPM2d4"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.78 on 10.11.54.4
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Wed, 14 Mar 2018 12:40:06 +0000 (UTC)
X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.5]); Wed, 14 Mar 2018 12:40:06 +0000 (UTC) for IP:'10.11.54.4' DOMAIN:'int-mx04.intmail.prod.int.rdu2.redhat.com' HELO:'smtp.corp.redhat.com' FROM:'hkario@redhat.com' RCPT:''
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/iDflZfthRlBnzBCfq6cwZbAn508>
Subject: Re: [TLS] TLS@IETF101 Agenda Posted
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 14 Mar 2018 12:40:08 -0000

On Tuesday, 13 March 2018 23:16:47 CET Russ Housley wrote:
> Ted:
> > There's an easy way to do this, although as a sometime bank security geek
> > I would strongly advise you to not do it: keep using TLS 1.2.
> This is a bogus argument.  First, staying with an old protocol version often
> leads to locking in unmaintained versions of old software.

this is simply not true, the newest versions of OpenSSL, NSS, GnuTLS and 
schannel allow you to disable TLS 1.2 and TLS 1.1 protocol support to 
effectively only support TLS 1.0!

if your vendor can't implement that feature, I can hardly call such software 
"maintained" in the first place

>  Second, using TLS1.2 does not technically address the issue.  If the client
>  were to exclusively offer DHE-based ciphersuites, then the visibility
>  techniques that have been used in the past are thwarted.

sorry, but this is a complete non-sequitur; that client behaviour has nothing 
to do with TLS 1.3 existence or the way it works

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic