Re: [TLS] Updating for non-X.509 certificate types

Ilari Liusvaara <ilariliusvaara@welho.com> Fri, 10 March 2017 16:37 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 4194E128B38 for <tls@ietfa.amsl.com>; Fri, 10 Mar 2017 08:37:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-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 6pqP1ASHB_lL for <tls@ietfa.amsl.com>; Fri, 10 Mar 2017 08:37:47 -0800 (PST)
Received: from welho-filter2.welho.com (welho-filter2.welho.com [83.102.41.24]) by ietfa.amsl.com (Postfix) with ESMTP id 20E6A12940A for <tls@ietf.org>; Fri, 10 Mar 2017 08:37:47 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter2.welho.com (Postfix) with ESMTP id 03ED21F316; Fri, 10 Mar 2017 18:37:46 +0200 (EET)
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-filter2.welho.com [::ffff:83.102.41.24]) (amavisd-new, port 10024) with ESMTP id qwz-WKlTOZ-L; Fri, 10 Mar 2017 18:37:45 +0200 (EET)
Received: from LK-Perkele-V2 (87-92-51-204.bb.dnainternet.fi [87.92.51.204]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp3.welho.com (Postfix) with ESMTPSA id A701A2310; Fri, 10 Mar 2017 18:37:45 +0200 (EET)
Date: Fri, 10 Mar 2017 18:37:38 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Eric Rescorla <ekr@rtfm.com>
Message-ID: <20170310163738.GA1636@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CABcZeBNGkZVpoGqkc_ePF12mC0HaJgNbytXV70eV4oBBcyD2HQ@mail.gmail.com> <20170310124013.GA1197@LK-Perkele-V2.elisa-laajakaista.fi> <CABcZeBNuVB1pdZiQmn87asfF=ARgNNTkzVM2vnyZZ1VPJ4-B+g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CABcZeBNuVB1pdZiQmn87asfF=ARgNNTkzVM2vnyZZ1VPJ4-B+g@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/pqC__NHMemwv_BUmxIOOr2RS4pY>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Updating for non-X.509 certificate types
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: Fri, 10 Mar 2017 16:37:49 -0000

On Fri, Mar 10, 2017 at 07:02:22AM -0800, Eric Rescorla wrote:
> On Fri, Mar 10, 2017 at 4:40 AM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
> 
> > - user_mapping: Has extra handshake message.
> > - cert_type: All the problems of CCertT and SCertT, combined with
> >   fixing both to be the same.
> >
> 
> Does anyone use this?

I don't think anyone uses it. cert_type was defined in order to use
OpenPGP certs (RPK has SCertT and CCertT, altough in theory one could
use cert_type). Nobody uses OpenPGP. Even the most notable TLS library
supporting those (GnuTLS) is deprecating it.
 
> > With user_mapping, applying similar trick as in status_request is
> > not completely trivial because extensions that are answered in client
> > Certificate are offered in CertificateRequest. Okay, except that
> > extension is not an answer to ClientHello extensions, and the
> > extension assumes offer-answer relationship between client and server
> > extensions. Might need some special-casing.
> 
> Yeah, I think we should probably just consider banning user_mapping,
> at least until someone comes up with a way to use it here.

IIRC, you asked "does anyone use this" before and some MS guys said
yes, they use it.
 
Or at least I remember some guys saying that they use it.

> Could be useful to have explicit list of extensions (no registry, since
> > this list can be never updated) that lists extensions that are
> > deprecated in TLS 1.3.
> >
> 
> Currently this is by exclusion. I.e., these aren't listed as usable with
> 1.3. It does seem to me that we shouldn't ban cached_info and
> the cert type ones, because if/when they become usable with 1.3
> then they should be permissible. So I think I would rather say
> "don't advertise these with 1.3 unless you're willing to do them
> with 1.3"

The problem here is, one can't do that with TLS 1.2+1.3 dual-version
either. If client doesn't know what extension X means in TLS 1.3
(but does know it for TLS 1.2), if it advertises it, it runs the
risk that server does in fact know what X does in TLS 1.3, and then
blows up when server acts accordingly.


-Ilari