Re: [TLS] draft-ietf-tls-tls-13-17 posted

Ilari Liusvaara <ilariliusvaara@welho.com> Fri, 21 October 2016 15:22 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 58906129614 for <tls@ietfa.amsl.com>; Fri, 21 Oct 2016 08:22:14 -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 w-A-ZzvI7sWI for <tls@ietfa.amsl.com>; Fri, 21 Oct 2016 08:22:06 -0700 (PDT)
Received: from welho-filter3.welho.com (welho-filter3.welho.com [83.102.41.25]) by ietfa.amsl.com (Postfix) with ESMTP id EB769129608 for <tls@ietf.org>; Fri, 21 Oct 2016 08:22:05 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter3.welho.com (Postfix) with ESMTP id 4C759139B0; Fri, 21 Oct 2016 18:22:05 +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-filter3.welho.com [::ffff:83.102.41.25]) (amavisd-new, port 10024) with ESMTP id XtUmSu_WEXTb; Fri, 21 Oct 2016 18:22:05 +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 E211C2310; Fri, 21 Oct 2016 18:22:04 +0300 (EEST)
Date: Fri, 21 Oct 2016 18:21:57 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Eric Rescorla <ekr@rtfm.com>
Message-ID: <20161021152157.GB9003@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CABcZeBP6pzqtcT3rmmpjr_4R+fb6ZyiAduxQiJ87B9hnRzVBXA@mail.gmail.com> <20161021093350.GA8070@LK-Perkele-V2.elisa-laajakaista.fi> <CABcZeBPd25PQhFDW+pbGCCRQM8CVWdnK3NDizYEdgcsV7gR8fg@mail.gmail.com> <20161021140057.GA8197@LK-Perkele-V2.elisa-laajakaista.fi> <CABcZeBN=qTB1g_jfT_HZ=WnkqbKpRnDa=CahvHZeDb9w5ZbXbw@mail.gmail.com> <20161021150609.GA8844@LK-Perkele-V2.elisa-laajakaista.fi> <CABcZeBN3+PRDbJY31QYKqk4kvsL3x5D1iSB9hmbEaPe-YOg+CQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CABcZeBN3+PRDbJY31QYKqk4kvsL3x5D1iSB9hmbEaPe-YOg+CQ@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/UnF4ELDzXU254NvXeYQ-HVXod10>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] draft-ietf-tls-tls-13-17 posted
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, 21 Oct 2016 15:22:14 -0000

On Fri, Oct 21, 2016 at 08:14:50AM -0700, Eric Rescorla wrote:
> On Fri, Oct 21, 2016 at 8:06 AM, Ilari Liusvaara <ilariliusvaara@welho.com>;
> wrote:
> 
> > On Fri, Oct 21, 2016 at 08:00:33AM -0700, Eric Rescorla wrote:
> > > On Fri, Oct 21, 2016 at 7:00 AM, Ilari Liusvaara <
> > ilariliusvaara@welho.com>;
> > > wrote:
> > >
> > > > On Fri, Oct 21, 2016 at 04:39:59AM -0700, Eric Rescorla wrote:
> > > > > On Fri, Oct 21, 2016 at 2:33 AM, Ilari Liusvaara <
> > > > ilariliusvaara@welho.com>;
> > > > > wrote:
> > > > >
> > > > > And since that implementation supports RFC7250 (for the server
> > > > > > certificate), here is my interpretation of it:
> > > > > >
> > > > > > The certificate type is sent in extensions of EE certificate,
> > > > > > via the usual server_certificate_type extension (using the
> > server-side
> > > > > > syntax from RFC7250).
> > > > > >
> > > > >
> > > > > I think this probably should go in Encrypted Extensions.
> > > >
> > > > It is definitely related to the certificate chain,
> > >
> > >
> > > My argument would be that it doesn't belong in "individual certificates"
> > > because it applies to certificates as a whole. It's not like it would be
> > > legal to have a 7250 cert followed by an X.509 cert, one hopes
> >
> > Well, there can't be two server certificate "chains". But if there
> > could, I would expect the type to per-chain.
> >
> 
> Sorry, I'm not sure I am following.
> 
> What I am concerned about is the case where ServerCertificate =
> 
> [
>    {
>       Extensions : [ server_certificate_type = RawPublicKey],
>       Certificate  : <some SPKI>
>    } ,
>    {
>       Extensions : [],
>       Certificate : <some X.509 cert>
>    }
> ]
> 
> What is the other side supposed to do with that?

Well, my implementation treats it the same as TLS 1.2 handshake with
server_certificate_type=RPK and a two certificates in the chain). Which
apparently means just ignoring the second certificate.

But if it had certificate type that could use multiple slots, there
could only be one chain type (server_certificate_type can only appear
once per chain, in the first slot).



-Ilari