IETF Logo Mail Archive

Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00

Hubert Kario <hkario@redhat.com> Tue, 24 October 2017 11:57 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 524A913F70D for <tls@ietfa.amsl.com>; Tue, 24 Oct 2017 04:57:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 pkkdTQ7pZEiS for <tls@ietfa.amsl.com>; Tue, 24 Oct 2017 04:57:17 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9AB613F705 for <tls@ietf.org>; Tue, 24 Oct 2017 04:57:16 -0700 (PDT)
Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3F7BB356E5; Tue, 24 Oct 2017 11:57:16 +0000 (UTC)
DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 3F7BB356E5
Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com
Authentication-Results: ext-mx06.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=hkario@redhat.com
Received: from pintsize.usersys.redhat.com (unknown [10.34.247.178]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C32F660A99; Tue, 24 Oct 2017 11:57:15 +0000 (UTC)
From: Hubert Kario <hkario@redhat.com>
To: tls@ietf.org
Date: Tue, 24 Oct 2017 13:57:07 +0200
Message-ID: <2354859.AHD1xRnffk@pintsize.usersys.redhat.com>
In-Reply-To: <CAAF6GDep7VmRX_vJG0nPPzNa6MVndux0K++_FaC4roPqT5pKNA@mail.gmail.com>
References: <7E6C8F1F-D341-456B-9A48-79FA7FEC0BC1@gmail.com> <460ef8f8-4853-2123-5721-30ef49a7c1d1@akamai.com> <CAAF6GDep7VmRX_vJG0nPPzNa6MVndux0K++_FaC4roPqT5pKNA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart12271674.h0V01Jgg56"; micalg="pgp-sha512"; protocol="application/pgp-signature"
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.30]); Tue, 24 Oct 2017 11:57:16 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/C3tH-l0Pd7QDnQ8W51Y3edvHduk>
Subject: Re: [TLS] Publication of draft-rhrd-tls-tls13-visibility-00
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: Tue, 24 Oct 2017 11:57:18 -0000

On Tuesday, 24 October 2017 00:40:44 CEST Colm MacCárthaigh wrote:
> On Mon, Oct 23, 2017 at 3:30 PM, Benjamin Kaduk <bkaduk@akamai.com> wrote:
> >  There are no doubt folks here would claim that the writing has been on
> >  the wall for> 
> > five years or more that static RSA was out and forward secrecy was on
> > the way in, and that now is the right time to draw the line and drop the
> > backwards compatibility.    In fact, there is already presumed WG
> > consensus for that position, so a strong argument indeed would be needed
> > to shift the boundary from now.  I won't say that no such argument can
> > exist, but I don't think we've seen it yet.
> 
> I don't have too strong an interest in this thread, it's not going
> anywhere, and I don't mind that. But I do want to chime in and point
> out that forward secrecy is not completely on the way in. With STEK
> based 0-RTT, it sounds like many implementors are happy to see user's
> requests, cookies, passwords and other secret tokens protected only by
> symmetric keys that are widely shared across many machines and
> geographic boundaries, with no defined key schedule, usage
> requirements or forward secrecy. Clearly, the consensus has been
> willing to accept that trade-off, and there is definite wiggle room.

which part of the HTTP 0-RTT usage policy does say that that is acceptable?

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

v2.23.0 | Report a Bug | By Email