Re: [TLS] Review of PR #209

Martin Thomson <martin.thomson@gmail.com> Tue, 15 September 2015 21:37 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 194F11B2AA4 for <tls@ietfa.amsl.com>; Tue, 15 Sep 2015 14:37:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
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 W26k9wBQyTbq for <tls@ietfa.amsl.com>; Tue, 15 Sep 2015 14:37:36 -0700 (PDT)
Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::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 EF40D1ACD95 for <tls@ietf.org>; Tue, 15 Sep 2015 14:37:35 -0700 (PDT)
Received: by ykdt18 with SMTP id t18so179977085ykd.3 for <tls@ietf.org>; Tue, 15 Sep 2015 14:37:35 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=svriSwyJ+9SdMS+yhZ6dXQiIUzm1KhIFW/xevcLEpXo=; b=qK6Qu/5wBvgyQwoyMDKeE8vh2qr7H6moLo5v5kDHZHwIXlaChzSR1k6cCwrKp1Fu9w TkiapNjBIU3Ig+W/gsFYFqAanHrzPzwwxOPwwQNtQpKYUTeD1grIDfoE2KBPeCKjesi3 KjWx0tt7y0bupgUChTDjJ36VC2woomUDBnZgz7l9wJ+DZCS69x7Ouk9F05pgtrZddTOn 6o1Fx+oOjEHQGYJyQ57t7l4ysU082FskDgZy5i4YTRBdk7Uzv5iCKgr2kiARW1ybcvYC 4bsiWRtfQsg1ORwIKcYe5Pp+uBNrVOkycrWXlPO/8c7xmU4b8Csq+LMqY0cqt6X74I+d Abbg==
MIME-Version: 1.0
X-Received: by 10.170.220.215 with SMTP id m206mr24647780ykf.57.1442353055193; Tue, 15 Sep 2015 14:37:35 -0700 (PDT)
Received: by 10.129.133.130 with HTTP; Tue, 15 Sep 2015 14:37:35 -0700 (PDT)
In-Reply-To: <BLUPR03MB13962416E8D8AD71CFFE13C08C5C0@BLUPR03MB1396.namprd03.prod.outlook.com>
References: <CABkgnnWtUjH1b3xm_peffNxNpxXE9rudJLJpn1ExNpE7B29AhA@mail.gmail.com> <BLUPR03MB13962416E8D8AD71CFFE13C08C5C0@BLUPR03MB1396.namprd03.prod.outlook.com>
Date: Tue, 15 Sep 2015 14:37:35 -0700
Message-ID: <CABkgnnX5VrvWwEiPq2DvEWexPSjLjpjy_1JDSmj31bytZTFP6A@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Andrei Popov <Andrei.Popov@microsoft.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/g3o1H-P0JbbcTWTNfgO-yS_kpPQ>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Review of PR #209
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 15 Sep 2015 21:37:40 -0000

This sounds like a good idea.  I certainly like how it eliminates a
number of variations (particularly the one that #209 added).  It
enables unilateral client authentication, which is a big plus.

My biggest concern would be the one you note and how this interacts
with the session transcript.  It seems OK to me, but I'd like Hugo or
Karthik to spend a few cycles thinking about that one before I'm
confident there isn't an actual problem.

How many Certificate+CertificateVerify messages would a client be
permitted to send.  1? N?  (I think 1)

If the answer to the above is N, does the client's
Certificate+CertificateVerify somehow identify the CertificateRequest?
 That is, how does the server identify whether this is unilateral or
in response to its own request?

How does a client determine if the NewSessionTicket that it receives
includes its authentication? That is, how can a client know whether a
resumed session will need a certificate or not?  (I'm not sure about
this one, but the first thought that occurs is that the server could
include an indicator in the NewSessionTicket message.)

Does the session need to be rekeyed as a result of this new
information?  (I think not, though see above regarding analysis.)

Do we allow for application data between Certificate and
CertificateVerify? (I think not.)

Question: What value do you see in having a spontaneous
NewSessionTicket messages?  Is this just a case of not wanting to bind
it more formally to something that the client sends?  I worry that
we'll have cases where the session tickets encompass new states if we
permit that.


On 15 September 2015 at 13:17, Andrei Popov <Andrei.Popov@microsoft.com> wrote:
> Perhaps we can simplify the protocol by pulling client auth out of the handshake as follows:
>
> 1. CertificateRequest, client Certificate, CertificateVerify and NewSessionTicket messages use a new content type distinct from "handshake".
> 2. The client can send Certificate and CertificateVerify at any time application data is permitted, regardless of whether the server had previously sent CertificateRequest.
> 3. The server can send CertificateRequest and NewSessionTicket at any time application data is permitted. Alternatively, the server can encapsulate CertificateRequest in an application protocol message.
>
> Encapsulating CertificateRequest in an application protocol message allows the client to determine which specific application request resulted in the need for client auth. The application protocol would of course need to allow this.
>
> As far as I can tell, the above scheme seems to work in both 0-RTT and 1-RTT modes.
>
> We can decide exactly what CertificateVerify would be signing: whether it's the handshake hash or some form of RFC5705 Exported Keying Material (EKM).
>
> Thoughts?
>
> Cheers,
>
> Andrei
>
> -----Original Message-----
> From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Martin Thomson
> Sent: Saturday, July 25, 2015 8:00 AM
> To: tls@ietf.org
> Subject: [TLS] Review of PR #209
>
> Andrei proposes two changes in https://github.com/tlswg/tls13-spec/pull/209
>
> The first expands the ways in which a server can identify certificates.  This is fine.  I do wonder whether we can remove CertificateType entirely for TLS 1.3 though (that can be done separately).
>
> The second is worrisome.  I don't like that a handshake message now has two different potential locations that it might appear in.  That seems like a hazard.  I think that we need a new content type for a new message that can be used after the handshake completes.  Then there are two options:
>  a) remove CertificateRequest from the handshake entirely and allow the handshake to complete before authenticating (this has a number of hazards that make it probably worse than the duplication it addresses)
>  b) use CertificateRequest within the handshake, and the new content type outside of it
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls