Re: [TLS] draft-ietf-tls-tls13-15

Ilari Liusvaara <ilariliusvaara@welho.com> Thu, 18 August 2016 13:35 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 DF17F12DE7E for <tls@ietfa.amsl.com>; Thu, 18 Aug 2016 06:35:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.147
X-Spam-Level:
X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.247] 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 XG_5QLPoA7mi for <tls@ietfa.amsl.com>; Thu, 18 Aug 2016 06:35:52 -0700 (PDT)
Received: from welho-filter1.welho.com (welho-filter1.welho.com [83.102.41.23]) by ietfa.amsl.com (Postfix) with ESMTP id D82F812DE7C for <tls@ietf.org>; Thu, 18 Aug 2016 06:35:51 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by welho-filter1.welho.com (Postfix) with ESMTP id C9609F031; Thu, 18 Aug 2016 16:35:49 +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-filter1.welho.com [::ffff:83.102.41.23]) (amavisd-new, port 10024) with ESMTP id asBhdpTL1eso; Thu, 18 Aug 2016 16:35:49 +0300 (EEST)
Received: from LK-Perkele-V2 (87-100-177-32.bb.dnainternet.fi [87.100.177.32]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by welho-smtp1.welho.com (Postfix) with ESMTPSA id 8C44DC4; Thu, 18 Aug 2016 16:35:49 +0300 (EEST)
Date: Thu, 18 Aug 2016 16:35:41 +0300
From: Ilari Liusvaara <ilariliusvaara@welho.com>
To: Eric Rescorla <ekr@rtfm.com>
Message-ID: <20160818133541.6b2eb5kshva4m5br@LK-Perkele-V2.elisa-laajakaista.fi>
References: <CABcZeBMqykSnQp__TRaNmyhpcLPaU=eeuM120zgAoprwd0555w@mail.gmail.com> <20160818052622.zim6nxwwqw3hzmr6@LK-Perkele-V2.elisa-laajakaista.fi> <CABcZeBOaLhBq64Yw2D-5oXfE56_2atMX8tN31Y=yt9VkWNX2=g@mail.gmail.com> <20160818124602.syi2whfbrom7xfi6@LK-Perkele-V2.elisa-laajakaista.fi> <CABcZeBOqQJ8Hc+FFV5r3xHQNAEyOpNHnvwYADZjnHyOaRV6rZg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CABcZeBOqQJ8Hc+FFV5r3xHQNAEyOpNHnvwYADZjnHyOaRV6rZg@mail.gmail.com>
User-Agent: Mutt/1.6.2-neo (2016-08-08)
Sender: ilariliusvaara@welho.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/zazFClBGRkq-ERsD4v2RFoWnPbs>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] draft-ietf-tls-tls13-15
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: Thu, 18 Aug 2016 13:35:55 -0000

On Thu, Aug 18, 2016 at 05:55:16AM -0700, Eric Rescorla wrote:
> On Thu, Aug 18, 2016 at 5:46 AM, Ilari Liusvaara <ilariliusvaara@welho.com>
> wrote:
> 
> Agreed. Table fail. Anyway, if it goes anywhere (see below) it should go in
> ServerHello. That was the intent for this draft.

Okay, good to know (/me goes to change it in his code).

> > Then why does that server signature_algorithms exist? I think that
> > special PSK authentication modes should be specified in the PSK
> > extension, so non-PSK clients don't get confused and do inapporiate
> > things with those indications.
> >
> 
> Can you elaborate on what you mean here? If it's what I think you mean
> (namely put it in the server's pre_share_key message) I used to have that
> and davidben convinced me this was better. There's no perfect encoding
> here, AFAICT, so if you want to make an alternate suggestion that we could
> take a look at, that would be great.

The issue I'm thinking about is that if missing signature_algorithms means
no certificate, some dumb TLS implementation (and there are plenty of those)
will heed that even in non-PSK mode...
 
> > David Bejamin already posted a PR about that. Doesn't clearly say
> > that unknown reason handling.
> >
> 
> Yeah, I read the list before the PRs. I'll take a look but if you want to
> comment that would be great.

The only comment is that I would prefer to allow extensions the without
client including them in ClientHello[1] (obviously fatal if unknown one is
seen[2]), instead of special-casing Cookie.



[1] Of course, if the error is related to values in extension, then the
client had to include it in its ClientHello.


[2] Basically, if client is told that its ClientHello is wrong in some
way it does not understand, obviously it can't fix it.



-Ilari