IETF Logo Mail Archive

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

Nico Williams <nico@cryptonector.com> Mon, 22 May 2017 20:17 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 E3874120727 for <tls@ietfa.amsl.com>; Mon, 22 May 2017 13:17:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 AKGPiWFv82Xu for <tls@ietfa.amsl.com>; Mon, 22 May 2017 13:17:35 -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 63658128954 for <tls@ietf.org>; Mon, 22 May 2017 13:17:35 -0700 (PDT)
Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id D726520051C27; Mon, 22 May 2017 13:17:34 -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=Rhmw/hb6EpcX41 KcF2rQpzDRSnU=; b=oDaAO1ReinDyELtCT6W39Vs7j0cHWnRy4nHPoNsPKxDi/q gqSdgnT6Avs2Ef0NxtkFbQVLVKfsj7TeoC4RNeJPhOPZOdfGg3h91sb4HW+VnJzl sOy6cKlZNoaMMZ5SrKjz9d3RUXij2/s6bBVGc8BbGYzQCauzjds9H3uAv48X4=
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 9618320051C22; Mon, 22 May 2017 13:17:34 -0700 (PDT)
Date: Mon, 22 May 2017 15:17:30 -0500
From: Nico Williams <nico@cryptonector.com>
To: Eric Rescorla <ekr@rtfm.com>
Cc: TLS WG <tls@ietf.org>
Message-ID: <20170522201729.GO10188@localhost>
References: <44AED5C2-B21C-442A-8412-9134D1C10BCD@dukhovni.org> <201705192143.19490.davemgarrett@gmail.com> <20170520054117.GM10188@localhost> <80AB5C55-41BA-471E-A55A-86E98299B652@dukhovni.org> <f262447d-5bd1-68c8-dac6-ad2224733235@akamai.com> <35E448DD-7F74-4563-9707-DFAB66125FAA@dukhovni.org> <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>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CABcZeBOvRGar9ZLTo=tu+oUxRWtMucwr5Bk1dPY8C1mAa9asTg@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/13r11-7Yg-zGvR-rezPhMxvfvec>
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 20:17:37 -0000

On Tue, May 23, 2017 at 04:42:45AM +0900, Eric Rescorla wrote:
> Well, I certainly think past the Web PKI, because one of the cases I
> care about is WebRTC, which doesn't do any PKI validation at all.
> 
> In any case, I think there are two issues:
> 1. Forbid TLS 1.3 implementations from accepting MD5 and SHA-1.
> 2. Require a specific failure if the peer presents such a certificate.
> 
> There was pretty strong consensus to do #1 and I don't support removing
> it. That seems like a pretty modest layering violation. If people think that
> the mandate for this specific alert is too onerous, I could live with
> removing
> that.

I don't understand how you can have (1) and not (2).

Unlike Viktor (though I also don't like the layering violation) I'm not
proposing removing that text altogether, but tweaking it to allow
opportunistic and other TLS usage.

Instead of altogether forbidding certs with MD5 signatures, forbid them
when the application expects TLS to authenticate the server [with PKIX,
as opposed to certain DANE usage values, or with pre-shared certs,
etc.].  I.e., a server authentication security level knob is needed.

Nico

> On Tue, May 23, 2017 at 2:46 AM, Viktor Dukhovni <ietf-dane@dukhovni.org>
> wrote:
> > > On May 22, 2017, at 1:37 PM, Salz, Rich <rsalz@akamai.com> wrote:
> > > I strongly believe the text should stay as it is, for the most good to
> > the most people.  Viktor is in the weeds, arguably by himself.
> >
> > Right, all by myself...  With support from Nico, Ilari, and others
> > who've upthread accepted that certificate verification is properly
> > RFC5280 and not TLS, before I suggested removal of the text in
> > question (which solves no real problem, but does create needless
> > interoperability issues for various TLS use-cases).
> >
> > The dominant use case is not the only one that needs consideration,
> > and text that breaks other use-cases is NOT just fine, and the TLS
> > WG really does need to think more broadly than the Web PKI.  This is
> > not the HTTPS working group.

v2.23.0 | Report a Bug | By Email