IETF Logo Mail Archive

Re: [TLS] 0-RTT, server Application Data, and client Finished

Watson Ladd <watsonbladd@gmail.com> Wed, 27 January 2016 15:09 UTC

Return-Path: <watsonbladd@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 A1EBC1B2F65 for <tls@ietfa.amsl.com>; Wed, 27 Jan 2016 07:09:04 -0800 (PST)
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 pIjQ1fhqDLgX for <tls@ietfa.amsl.com>; Wed, 27 Jan 2016 07:09:02 -0800 (PST)
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 6D90D1B2F61 for <tls@ietf.org>; Wed, 27 Jan 2016 07:09:02 -0800 (PST)
Received: by mail-yk0-x22a.google.com with SMTP id v14so243679943ykd.3 for <tls@ietf.org>; Wed, 27 Jan 2016 07:09:02 -0800 (PST)
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; bh=PZJd3bnoupsfrzP2jznPKcdgnHZGnRpXbBCriEXgJXE=; b=y3g2NMkfN03P4EZLj2oiGmqysZ/lRtla1RLP2XjiiIQjPnsKGmTaECFatkwWdMFeuY RG9aJ9uya6F1yTlA5rNa0csqhokfJEoi2Zy16zZl4hSxh7KYNnjF6kEojEfoMGMQ0jH/ AdB4vmvmzvvV84Xv7nQGMk2WW4BsIQx4O3gbeF47J5+QJP8Ce2rD5TBdRE5HI2ZGF83K iwX09QtuValxerLf8ZoVnkzHgyp6OCGGE9tv6VpKZof1wWwegqOevxIet77I1rSFq6OI AzTjS3FfRx+arhYgbvc8sYFTiZTwrHThgjy5KcM5s2WQWdm4vlLSgGxx2SrhQlEZo2/0 qUXw==
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:date :message-id:subject:from:to:cc:content-type; bh=PZJd3bnoupsfrzP2jznPKcdgnHZGnRpXbBCriEXgJXE=; b=Aetl6gvvkG3NmlhQTeLmsIfhlgWcuoNdOo6s7H5CMiNpEcJcDwBfFjRA+/0Cp+mviY rx2dmQYNBqAlXaXL5CW9XcwNLi/Fhw92rkRZqJOBQaZ93bGYOlFZL6hwR1TW4s536hBI cs4FxjiRS8IVi6bL5T5gwq6ZIvwctjk1eLirpuFdqanAkEbtd47mIRXguFQmUjTec0UI AoAaz6NZnJmY8xH+g+AafRw7PcKNq842sVrfM40zebLVY3sNexLy9O3KMsuR32kJaRVy UVR0WRiOL9U24yrTAxKRmWrk/t0CAJep8kNnyexkL1YYqmxAyYrTmmM+fQQ1MIhbYN7a jj+g==
X-Gm-Message-State: AG10YORRI9Rqt3vBUdS9OTbqpud3p6kxc7lATq1PJctNWXcDLfOn8gE3V/HYu+gIpwvF5OR+B+CGYDigvvhoaQ==
MIME-Version: 1.0
X-Received: by 10.129.123.134 with SMTP id w128mr14670223ywc.345.1453907341489; Wed, 27 Jan 2016 07:09:01 -0800 (PST)
Received: by 10.13.216.150 with HTTP; Wed, 27 Jan 2016 07:09:01 -0800 (PST)
In-Reply-To: <CAH9QtQHMgkTnA5byjUFMNr3h6ur8tOFXNweZRWiLDFYnpTq24A@mail.gmail.com>
References: <CAF8qwaCty7qjJGobr+god_TDo+q82hZx2FpOitLQ0ANctWBZ0g@mail.gmail.com> <CABkgnnXD5ZudUW7d2uQSSo1ULeOgxD97H5Sd0ZN3MXy9X6+4qA@mail.gmail.com> <CAF8qwaCq7LzXp+5ULWYakLXar3_J1QmerfC7EpqHg1TXgxeu5A@mail.gmail.com> <CABkgnnWQT9WDQDJ9EW21STgr_7j4VFqCh4mWS=1Ko7o=sAyXkQ@mail.gmail.com> <CAF8qwaCAbYsQhq-VL=ktfvDLR+1y6TCkFZ7VhmVKNCVUroOJNQ@mail.gmail.com> <CABkgnnUSg1ah9pMRVrDq5SUvkH79aKQXVzW_KNN+SO+DSHoUmw@mail.gmail.com> <CAH9QtQHMgkTnA5byjUFMNr3h6ur8tOFXNweZRWiLDFYnpTq24A@mail.gmail.com>
Date: Wed, 27 Jan 2016 07:09:01 -0800
Message-ID: <CACsn0c=txbHD-i10=MJd6ExTD4pn0ORqxP3xJLRxEBhdGsRg0w@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Bill Cox <waywardgeek@google.com>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/QRDjSOWyA4tGaXNqi_OYVW-lZjE>
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] 0-RTT, server Application Data, and client Finished
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: Wed, 27 Jan 2016 15:09:04 -0000

On Wed, Jan 27, 2016 at 6:12 AM, Bill Cox <waywardgeek@google.com> wrote:
> On Tue, Jan 26, 2016 at 7:32 PM, Martin Thomson <martin.thomson@gmail.com>
> wrote:
>>
>>
>> I get your point, but I don't see that as a simplification.  In my
>> mind, post-handshake client authentication doesn't happen.  Or, I
>> don't see it being commonplace.
>
>
> The use case described to me was for a higher level of authentication, such
> as when accessing a source-code repository at work, similar to proving that
> you still possess a security key now and then.  I am not sure why FIDO does
> not fit this use case better, though.  I have a feeling this is a legacy use
> case of client certificates, and is being included to avoid having to
> transition a lot of legacy client-cert based systems to FIDO.

All certificate based authentication over HTTP is currently done by
renegotiation, when the client chooses to access a protected resource
a Renegotiation Request is sent, leading to the client certificate
being provided in the second handshake. It's true that FIDO will be a
better solution (currently unfinished), but when changing TLS stacks
to work with TLS 1.3 we need to support this case, without requiring
changes to application code below this.

>
> The CertificateVerify message is still listed as an option in the 0-RTT
> client's first flight at t = 0.  Is this a mistake?  I have not heard that
> anyone wants to do this, as there is no possibility of a traditional
> proof-of-possession in the first flight.  However, with QUIC-like strike
> registers, a reasonably accurate timestamp in the handshake, and a secure
> clock on the client, you can approximate a proof-of-possession.  This seems
> like a lot of trouble for a first-flight CertificateVerify, but if someone
> wants to do this, it could stay in the spec.  If CertficateVerify is to
> remain in the 0-RTT first flight, there needs to be some way to provide a
> timestamp in the handshake hash.  Is there a way to do this now?  The TLS
> 1.2 timestamp in the client random seems to have been removed.

All 0-RTT data is replayable, but I don't see what replaying a
authenticated replayable connection gets you.

>
> Bill
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



-- 
"Man is born free, but everywhere he is in chains".
--Rousseau.

v2.23.0 | Report a Bug | By Email