IETF Logo Mail Archive

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

Viktor Dukhovni <ietf-dane@dukhovni.org> Mon, 22 May 2017 21:31 UTC

Return-Path: <ietf-dane@dukhovni.org>
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 1144B1292FD for <tls@ietfa.amsl.com>; Mon, 22 May 2017 14:31:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dXfK2iY5SpNg for <tls@ietfa.amsl.com>; Mon, 22 May 2017 14:31:57 -0700 (PDT)
Received: from mournblade.imrryr.org (mournblade.imrryr.org [108.5.242.66]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 830F6128D3E for <tls@ietf.org>; Mon, 22 May 2017 14:31:57 -0700 (PDT)
Received: from [172.31.31.193] (gzac12-mdf2-1.aoa.twosigma.com [208.77.215.155]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mournblade.imrryr.org (Postfix) with ESMTPSA id 9103B7A32F1 for <tls@ietf.org>; Mon, 22 May 2017 21:31:56 +0000 (UTC) (envelope-from ietf-dane@dukhovni.org)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Viktor Dukhovni <ietf-dane@dukhovni.org>
In-Reply-To: <CABcZeBMMfp4DUcNCFUYCCP6B+UQn85bq2LSoumJdywy=0GOq4Q@mail.gmail.com>
Date: Mon, 22 May 2017 17:31:55 -0400
Content-Transfer-Encoding: quoted-printable
Reply-To: TLS WG <tls@ietf.org>
Message-Id: <E3BB180E-EC66-4F92-868B-E04F9E63CDF6@dukhovni.org>
References: <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> <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>
To: TLS WG <tls@ietf.org>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/iW-dWsvjigtNMPPELQ4A8tRe5_g>
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 21:31:59 -0000

> On May 22, 2017, at 5:22 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> I don't think "opportunistic" is a clearly enough defined category to be useful
> here.

If you mean:

> I don't think "strongly authenticate" is useful here. I think the
> requirement is that the RP must not accept these algorithms in any
> context which would require validating signatures made using them.

That's fine.

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

The above formulation (where the relying party does not accept certain
signature algorithms as valid in the context of validating issuer
signatures) works for me.  All I'm looking for is not requiring the
RP to abort the handshake as soon as the algorithm is encountered,
even when the signature would never be checked!

So if putting the consensus to ban MD5/SHA-1 in its *proper context*
is consistent with the WG consensus, let's do that.

-- 
	Viktor.

v2.23.0 | Report a Bug | By Email