Re: [TLS] New review through the TLS 1.3 Editor's Copy

Ilari Liusvaara <ilariliusvaara@welho.com> Mon, 17 October 2016 19:42 UTC

Return-Path: <ilariliusvaara@welho.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 C126C12989C for <tls@ietfa.amsl.com>; Mon, 17 Oct 2016 12:42:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.331
X-Spam-Level:
X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.431] 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 aHaxn76tMKHM for <tls@ietfa.amsl.com>; Mon, 17 Oct 2016 12:42:08 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id D6BC91297C9 for <tls@ietf.org>; Mon, 17 Oct 2016 12:42:07 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 5BC86170AB; Mon, 17 Oct 2016 22:42:06 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp3.welho.com ([IPv6:::ffff:83.102.41.86]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id rkRbV9bUD6Ko; Mon, 17 Oct 2016 22:42:06 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-237-87.bb.dnainternet.fi [87.100.237.87]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id 0E3EF2310; Mon, 17 Oct 2016 22:42:06 +0300 (EEST)
Date: Mon, 17 Oct 2016 22:41:58 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Dave Garrett <davemgarrett@gmail.com>
Message-ID: <20161017194158.GA26690@LK-Perkele-V2.elisa-laajakaista.fi>
References: <20161017181030.GA26476@LK-Perkele-V2.elisa-laajakaista.fi> <201610171518.35092.davemgarrett@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <201610171518.35092.davemgarrett@gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/4orCxlxXe2AWa7BhVZXdcbfhcHA>
Cc: tls@ietf.org
Subject: Re: [TLS] New review through the TLS 1.3 Editor's Copy
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.17
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, 17 Oct 2016 19:42:10 -0000

On Mon, Oct 17, 2016 at 03:18:34PM -0400, Dave Garrett wrote:
> On Monday, October 17, 2016 02:10:30 pm Ilari Liusvaara wrote:
> > > %%% Authentication Messages
> > 
> > > If sent by a server, the signature algorithm MUST be one offered in the
> > > client's "signature_algorithms" extension unless no valid certificate chain can be
> > > produced without unsupported algorithms (see {{signature-algorithms}}).
> > 
> > This is seemingly about server signatures. In that context, an
> > unknown algorithm has absolutely no chance of working.
> 
> This came up in a discussion a while back and we decided to allow
> unsupported algorithms as a last-ditch fall-back. Opportunistic
> encryption might not care and there are systems that may trust
> certs as a whole, not caring about the signatures. The end result
> is that the client should be tasked with making the decision to
> accept or reject, not the server. Also can be helpful for debugging.

The only possible way stuff like this is going to work is for the
client either ignores Certificate/CertificateVerify entierely (can't
trust the certificate via any method) or if the client has serious
security bug.

While e.g. trusting the server by SPKI does bypass any and all
signatures in certificates, it does not bypass this server signature.


-Ilari