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

Eric Rescorla <ekr@rtfm.com> Thu, 18 August 2016 12:55 UTC

Return-Path: <ekr@rtfm.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 2F4EE12DC6A for <tls@ietfa.amsl.com>; Thu, 18 Aug 2016 05:55:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com
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 rGm5Qp48DAWb for <tls@ietfa.amsl.com>; Thu, 18 Aug 2016 05:55:57 -0700 (PDT)
Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 227CB12DC48 for <tls@ietf.org>; Thu, 18 Aug 2016 05:55:57 -0700 (PDT)
Received: by mail-yw0-x22a.google.com with SMTP id u134so9007372ywg.3 for <tls@ietf.org>; Thu, 18 Aug 2016 05:55:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=fWFuzNa9HuMgRK5qvasaPh1DIkQc1BQ4nnaz5Bi0vtI=; b=2FsoSnYcSRZ1/B92vt64Cs25uvS/J36HvXHRPjeAtEHTVeCXUiJYstMuo7fNbiHoMs kaTCojd8dxWHNSZQ0nAC8a7o6MJWu3Pfm/izBIyUnU5XawQqIjegymRgqDV7YU2QjCZJ xeXfqzzVJft9wxhLlqtR9njy9RQzbH49joYnU84/DfWNKiXyvKy9k8ysG7z3zTp3q9EJ GyALv3RZvTDJVWuWdi3mmkYmG3mD0l1sQsYhsv+kOJ/EHJSC6NJA87mgs4LQXdYaA7Yp G7FA4ZEyCBoD84HSsVXnZXbScLyGKCG8g3KVAawQ05s/alBdfGX9wg1IJFN/0l7uT5e+ PoXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=fWFuzNa9HuMgRK5qvasaPh1DIkQc1BQ4nnaz5Bi0vtI=; b=SDe0lLEbvKzQYXya6JAbbA7kVdLwYsZixRZslFJjLQfOPMp9DbJuSlaZRFV0mbVeSu qeJhK1JLhdRivqduXCDCXPTVEoZwEMo7rcggxLr8PJunqWeYw0xzchKacgvM2E5xonnP QM+sqTcaVMpzu4Nthtlf4mNuftZGEuRp/gVqnd1wP27lxc0xZxlv6OCfUSe6b9bBw/wm kN0vyxHnzjS52LwkcQ00zMpgdbxkxMsLjf8jRRXXO4/XbHcw3eOlY87sCaA0dtuuP7hd 69hX2pftB8He2VaYnUSZfW/2FvCfaJCwtSzlOmaxCt3Q0W4ARcKcSr2Tp7LNhAPQPdzY gVZA==
X-Gm-Message-State: AEkooust1CaQpHHf+qE7CmL3wiQDQ3XvQkKvV6Arwlui5fMBwG6HVwtlHQ/XIHlswZZ4T3haiK7tXbzjKXpqSw==
X-Received: by 10.129.92.215 with SMTP id q206mr1525386ywb.8.1471524956456; Thu, 18 Aug 2016 05:55:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.129.48.193 with HTTP; Thu, 18 Aug 2016 05:55:16 -0700 (PDT)
In-Reply-To: <20160818124602.syi2whfbrom7xfi6@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>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 18 Aug 2016 05:55:16 -0700
Message-ID: <CABcZeBOqQJ8Hc+FFV5r3xHQNAEyOpNHnvwYADZjnHyOaRV6rZg@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>
Content-Type: multipart/alternative; boundary=001a114d85ce4ef785053a581a43
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/8I_HNNsxf30o86xviYEWf7Nbx5E>
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 12:55:59 -0000

On Thu, Aug 18, 2016 at 5:46 AM, Ilari Liusvaara <ilariliusvaara@welho.com>
wrote:

> On Thu, Aug 18, 2016 at 05:29:34AM -0700, Eric Rescorla wrote:
> > Thanks for the quick review.
> >
> > On Wed, Aug 17, 2016 at 10:26 PM, Ilari Liusvaara <
> ilariliusvaara@welho.com>
> > wrote:
> >
> > - I note that accepting PSK and selecting the auth mode seem to be
> > >   in separate messages, which seems quite annoying implementation-
> > >   wise..
> >
> >
> > Can you elaborate on this? The intend is that they both appear in
> > ServerHello
> > (in pre_shared_key and signature_algorithms respectively).
>
> Eeh, I thought it was in EncryptedExtensions. Reading the text
> again, it is IMO really unclear where it goes.
>
> Checking the extension table, it says "Client". Which impiles that
> servers don't send it, but 4.2.2 says servers must send it in some
> cases.
>

Agreed. Table fail. Anyway, if it goes anywhere (see below) it should go in
ServerHello. That was the intent for this draft.


> - Can the server send arbitrary certificate in response to PSK or is
> > >   it somehow restricted? The document does not seem to talk about it.
> > >
> >
> > The document right now is supposed to be PSK XOR server signs, so the
> > answer is supposed to be "no". If/when we allow both together, then
> > we'll have to address this, which is a bit tricky.
>
> 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 HelloRetryRequest is problematic in pure-PSK case[1].
> > >
> > >
> > > [1] One way to do it would be to move the group to extension, which
> > > would only be sent if new group was needed. Then one could always
> > > require at least one extension (the field could also be renamed).
> > > Also, one could make it so that HRR extensions don't have to
> > > correspond to CH extensions (and unsupported one is a fatal error).
> > >
> >
> > Agreed on both counts. PR wanted.
> > https://github.com/tlswg/tls13-spec/issues/560
>
> 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.

-Ekr


>
>
> -Ilari
>