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

Ilari Liusvaara <ilariliusvaara@welho.com> Fri, 21 October 2016 09:34 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 998E1129514 for <tls@ietfa.amsl.com>; Fri, 21 Oct 2016 02:34:01 -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 QS9ojjv1G-Se for <tls@ietfa.amsl.com>; Fri, 21 Oct 2016 02:33:59 -0700 (PDT)
Received: from welho-filter4.welho.com (welho-filter4.welho.com [83.102.41.26]) by ietfa.amsl.com (Postfix) with ESMTP id 95AF4128B44 for <tls@ietf.org>; Fri, 21 Oct 2016 02:33:59 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter4.welho.com (Postfix) with ESMTP id 3E8A616CF9; Fri, 21 Oct 2016 12:33:58 +0300 (EEST)
X-Virus-Scanned: Debian amavisd-new at pp.htv.fi
Received: from welho-smtp1.welho.com ([IPv6:::ffff:83.102.41.84]) by localhost (welho-filter4.welho.com [::ffff:83.102.41.26]) (amavisd-new, port 10024) with ESMTP id AHriKKa2TQFd; Fri, 21 Oct 2016 12:33:58 +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-smtp1.welho.com (Postfix) with ESMTPSA id F1B63C4; Fri, 21 Oct 2016 12:33:57 +0300 (EEST)
Date: Fri, 21 Oct 2016 12:33:50 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Eric Rescorla <ekr@rtfm.com>
Message-ID: <20161021093350.GA8070@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CABcZeBP6pzqtcT3rmmpjr_4R+fb6ZyiAduxQiJ87B9hnRzVBXA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CABcZeBP6pzqtcT3rmmpjr_4R+fb6ZyiAduxQiJ87B9hnRzVBXA@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/p20gel1njE7XD9bolGl-zN9_vss>
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 09:34:01 -0000

On Thu, Oct 20, 2016 at 09:32:36AM -0700, Eric Rescorla wrote:
> Folks,
> 
> I have just uploaded draft-ietf-tls-tls13-17.

Updated my own implementation from -16 to -17 (TODO: Add to
implementations page, it isn't any of the ones listed).

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


Okay, the extension is after the certificate it attaches to (which is
just weird), but turns out this wasn't that bad to implement, due to
how the code happened to be laid out (it first sliced the certificate
message to extract the certificates and only afterwards processed
those).



... Interop tests with picotls failed:

- Picotls sends extension 13 (signature_algorithms) in ServerHello,
  which my implementation does not like[1].
- Picotls still seems to have the resumption_context mixed into
  hashes. I tought that got nuked when switching to "finished
  stuffing"? This causes wrong encryption keys to be derived,
  causing the handshake to blow up.



[1] Wasn't this ripped out in -17? The -17 draft seems to list that
extension as "clear", shouldn't it be "client" as the AFAIK the
server won't send it?


-Ilari