Re: [TLS] AD Review of draft-ietf-tls-tls13

Nico Williams <nico@cryptonector.com> Mon, 22 May 2017 23:30 UTC

Return-Path: <nico@cryptonector.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 6A53312943C for <tls@ietfa.amsl.com>; Mon, 22 May 2017 16:30:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level:
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com
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 aI76ThZPArRH for <tls@ietfa.amsl.com>; Mon, 22 May 2017 16:30:46 -0700 (PDT)
Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFA621293F9 for <tls@ietf.org>; Mon, 22 May 2017 16:30:46 -0700 (PDT)
Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id 1449F20051C23; Mon, 22 May 2017 16:30:46 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=zBvr/t0858GRlC d67NE7xwj0IFU=; b=KaXsBRE7gu5bHeuJ72UsihJYG0eofjjgVfGL505T9Dz1jm x3TPwojFL8446Xxsm050WwNjTmXlps1sVZkMomvoZ6VUSbmuAzi3GeIGfE6DAchS 7IT2vT6MKHHyx0RGq1uxb7x3AH71VKHzz3/VJE7rTiLrYfotLrbdHtKhM2d1c=
Received: from localhost (cpe-70-123-158-140.austin.res.rr.com [70.123.158.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPSA id C063F20051C25; Mon, 22 May 2017 16:30:45 -0700 (PDT)
Date: Mon, 22 May 2017 18:30:41 -0500
From: Nico Williams <nico@cryptonector.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: TLS WG <tls@ietf.org>
Message-ID: <20170522233040.GR10188@localhost>
References: <89704888-5f4d-0021-74cb-4cea28c773bd@akamai.com> <ac704db142c04e7b8a836df711e9bc7f@usma1ex-dag1mb1.msg.corp.akamai.com> <1A619330-282A-44F0-871B-DF6D15850394@dukhovni.org> <CABcZeBOvRGar9ZLTo=tu+oUxRWtMucwr5Bk1dPY8C1mAa9asTg@mail.gmail.com> <20170522201729.GO10188@localhost> <CABcZeBMx5wbfchzonxQ5E6N2cOSAXSFX5JpEdTQMMaTnoCb7Dg@mail.gmail.com> <20170522204326.GP10188@localhost> <CABcZeBM1SWnganpX_VyDRiVm+ZFSoA6tZpCWX+Ec-D6So6RUGw@mail.gmail.com> <20170522210018.GQ10188@localhost> <CABcZeBMMfp4DUcNCFUYCCP6B+UQn85bq2LSoumJdywy=0GOq4Q@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABcZeBMMfp4DUcNCFUYCCP6B+UQn85bq2LSoumJdywy=0GOq4Q@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/ere5L3q3PVwekz6b_fwvfRbNPvs>
Subject: Re: [TLS] AD Review of draft-ietf-tls-tls13
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: Mon, 22 May 2017 23:30:48 -0000

On Tue, May 23, 2017 at 06:22:30AM +0900, Eric Rescorla wrote:
> On Tue, May 23, 2017 at 6:00 AM, Nico Williams <nico@cryptonector.com>
> wrote:
> > > I don't understand the question. If you treat them as unknown then
> > > either your path construction code will route around them or once you
> > > try to verify, it will fail.
> >
> > That *really* seems like a layer violation!
> 
> As I said, I don't have a problem with it. It's TLS giving instructions to
> the PKI subsystem.

It implies more APIs.

> > Well, I want it to be crystal clear that the "not MD5 and such"
> > requirement need not apply to opportunistic TLS usage.
> 
> I don't think "opportunistic" is a clearly enough defined category to be
> useful here. Rather, I think the relevant criterion is the one I
> listed above. If people agree, I'd be happy to make that change (and
> can produce text) because I think it conforms to the WG consensus.

Opportunistic == "If the server got authenticated great, if not, that's fine too"

If the server was not authenticated, the app might use channel binding,
or learn the server's cert (TOFU), or just use the connection because
the only thing the application cares about is key agreement (defeat
eavesdropers, but not active attackers).  The last one is Viktor's use
case (SMTP).

Nico
--