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

Ilari Liusvaara <ilariliusvaara@welho.com> Fri, 10 March 2017 17:24 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 BD6CD1299D2 for <tls@ietfa.amsl.com>; Fri, 10 Mar 2017 09:24:28 -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 4NsejL3vt1np for <tls@ietfa.amsl.com>; Fri, 10 Mar 2017 09:24:20 -0800 (PST)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0F912999D for <tls@ietf.org>; Fri, 10 Mar 2017 09:23:57 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id E63941F03A; Fri, 10 Mar 2017 19:23:55 +0200 (EET)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp2.welho.com ([IPv6:::ffff:83.102.41.85]) by localhost (welho-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id oVN4uvp22Ztb; Fri, 10 Mar 2017 19:23:55 +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-smtp2.welho.com (Postfix) with ESMTPSA id AE7CB21C; Fri, 10 Mar 2017 19:23:55 +0200 (EET)
Date: Fri, 10 Mar 2017 19:23:49 +0200
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Eric Rescorla <ekr@rtfm.com>
Message-ID: <20170310172349.GC1636@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> <20170310163738.GA1636@LK-Perkele-V2.elisa-laajakaista.fi> <CABcZeBPeRYSVOXRm4rReQ-f3E1giJYiVgwJ4PmEOP7zaiZiRdQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CABcZeBPeRYSVOXRm4rReQ-f3E1giJYiVgwJ4PmEOP7zaiZiRdQ@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/wb7raoCEVDWkRNLUxBJX9D9zYhM>
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 17:24:29 -0000

On Fri, Mar 10, 2017 at 08:42:38AM -0800, Eric Rescorla wrote:
> On Fri, Mar 10, 2017 at 8:37 AM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
> 

> > 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.
> >
> 
> Right. I am saying that you must not offer these and 1.3 simultaneously
> unless you implement whatever 1.3 thingy we finally define for it.

I think that is a bad idea.

And after all, all the currently deprecated extensions are allowed in
multi-version TLS 1.3 ClientHello. And sometimes that is rather
important, given that this list contains security fix extensions like
extended_master_secret and renegotiation_info.

Also, I think that the definition of certificate types is so bad that
making the thing work in TLS 1.3 is not going to be feasible. Which
impiles replicating the functions with new extensions with completely
new semantics.

The reason is, cert_types see fit to completely redefine the certficate
message in all sorts of ways. And mapping those ways to standard TLS
1.3 Certificate message structure is too hard.



cached_info is much much easier. Basically if its extension is moved
to EE, but everything else held constant, it will AFAICT work in 
TLS 1.3 just fine, including in dual-version cases. If you get
the version wrong, things still work (smooth fallback) because of
hash check.





-Ilari