Re: [TLS] 0.5 RTT

Watson Ladd <watsonbladd@gmail.com> Wed, 24 February 2016 03:28 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 D9B121B30A9 for <tls@ietfa.amsl.com>; Tue, 23 Feb 2016 19:28:14 -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 Ocldd1dN8xGD for <tls@ietfa.amsl.com>; Tue, 23 Feb 2016 19:28:13 -0800 (PST)
Received: from mail-yk0-x235.google.com (mail-yk0-x235.google.com [IPv6:2607:f8b0:4002:c07::235]) (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 D20881B2E54 for <tls@ietf.org>; Tue, 23 Feb 2016 19:28:12 -0800 (PST)
Received: by mail-yk0-x235.google.com with SMTP id u9so2767001ykd.1 for <tls@ietf.org>; Tue, 23 Feb 2016 19:28:12 -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=yMZ7rvlSpxsrJUkyd76erV0+cJVNJyom1X8X59wCi0g=; b=MNwTQu5mcuPgaBKvMeJYEaAkH2NcNUMlHg9gF27LMH1Xo8I/doQk7IB+BXb6bKXsgx 3LXBxpXlDmYiOi2PdHpMnd2hXrkvLBXWoXiKd/2yzWGaArqrN0CJmKGiqfPzGIcosW8c xPtoxCXwMno32cuO6faoSi8OnEMU3dU4Y1lLcWS/D0UTAvYg88vHawOntqjdMXBh6wJZ FLn4XT0T53nbkcRdjEbemApEifgcbdz4z5Y9cznnAKt0Q6je3mtXG2sz9Rt8fqN/wS70 GCwCpdxgr9AQTQeC0FDbKxujcWAQp3/N+Dx1+uwV5ZLjSk4CnHAgBDrv+dBDtw15tETD KxUQ==
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=yMZ7rvlSpxsrJUkyd76erV0+cJVNJyom1X8X59wCi0g=; b=HMNT4oAJqLqYZTKy8yZAz5BcVTwQh32gYnNlzFzvXp39pNsK2a9IFW8/+JlJEBJgbX 9i9XUZAVE1qqxWQAbT1ZCT1oSCMJuS/mDNDUkdMdf1i4kSSB3L+E88QE5PJCWXBn1ixi gJS70lK9ljKPfsBiZOnrT1JLcuSKJtqURuNT8rfpwzP6qLh69B/f9H3dAurbP4UIUfzm BH5ilmdR5PF4oXzVucFQKNXRtmkB0dOiI+YoLu+kaVH4gFr/PF8o/excs/2sWNyVWyBi qeO0yDYZ8bgqY5X76iZX1NRjlfbcF4DfoEOE+rkUmzZnl1xVjCRhNy/hq5Ff/1M6lday LuFg==
X-Gm-Message-State: AG10YOQgDTWglQwjA0CDnNuwGXpczVQnlfRa3kWVas2dwd+1IEkeaQZVGLXfmFce208KMwbbyzRfLJ3KEv7Jbw==
MIME-Version: 1.0
X-Received: by 10.37.25.212 with SMTP id 203mr18503895ybz.163.1456284492150; Tue, 23 Feb 2016 19:28:12 -0800 (PST)
Received: by 10.13.216.138 with HTTP; Tue, 23 Feb 2016 19:28:12 -0800 (PST)
In-Reply-To: <56CD0C1C.9010501@cs.tcd.ie>
References: <CABkgnnW1LRhSA_i0nL=rDYnUwBZWg5dSys7yk6aDefYWptnpZQ@mail.gmail.com> <8FA1A0FD-B911-474F-AC08-6208A80EB980@gmail.com> <CADi0yUPOEL++R+_Nhy4NTfhzsA6UjbVbMAEiPx1Qg9+vPPHt7g@mail.gmail.com> <CABkgnnUHmtrRNnOyVXdOe-fnAcN7WVKfX=ycXiugV8A77OjQCQ@mail.gmail.com> <15C73D91-9CDD-488E-87AF-4EBB1C8202CB@gmail.com> <CABkgnnVxrpkMqdmV_JkMaEY39BZ=O07xeWcpod2fwRb3W4_sQA@mail.gmail.com> <CADi0yUN5b+CfzM-jH5xNL0dgU2u09OzmcUzV3uOwdEmP3wBr5A@mail.gmail.com> <56CD0C1C.9010501@cs.tcd.ie>
Date: Tue, 23 Feb 2016 19:28:12 -0800
Message-ID: <CACsn0c=h+uKiKJqshikwKZ96O7ncaUDLf07_EN3Mspv8Fd-BhQ@mail.gmail.com>
From: Watson Ladd <watsonbladd@gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/PK9NwwWM3tkOZN9hPM504cPZ0oM>
Cc: Karthikeyan Bhargavan <karthik.bhargavan@gmail.com>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] 0.5 RTT
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, 24 Feb 2016 03:28:15 -0000

On Tue, Feb 23, 2016 at 5:49 PM, Stephen Farrell
<stephen.farrell@cs.tcd.ie> wrote:
>
>
> On 23/02/16 22:37, Hugo Krawczyk wrote:
>>
>> (In particular, if these semantics may be based on stuff that happens
>> outside TLS, as Karthik and Watson were pointing out, then maybe we really
>> put a "Surgeon General" warning on 0.5 data of equal size to that of 0-RTT.)
>
> That, and/or also do a significant amount of work to consider other
> application uses of TLS that aren't well represented by folks who
> participate in the development of TLS1.3. And also oddities like
> EAP-TLS about which I at least am mostly ignorant but where I'd bet
> there's "fun" to be had with 0rtt.

Applications shouldn't use 0RTT unless they are absolutely,
positively, sure it won't be a problem. It's up to them to determine
what the danger is, and up to us to explain what the (minimal)
properties provided are. If they rely on extensions then either those
extensions need to be included in the security proofs, or we need to
make clear that they are not as secure as TLS 1.3, and that
implementations which enable both of them can get completely wrecked
in new and exciting ways.

>
> And we have to do that recognising that regardless of what the RFC
> says, if developers can improve performance by calling tls_send0()
> and not tls_send(), they will do the former. IOW, if we are going
> to define dangerous implements, (e.g., with replayable data) then
> I think the onus is mostly on us to know what bad effects those
> might have before we've done a good job. (We can try do that at
> IETF LC, but doing so isn't common and is often messy if we end up
> surprising folks.)

But will they call tls_send_data_replayable? or
tls_send_data_dangerously? API designers need to mark dangerous
functions accordingly. (They also need to make APIs easy to use: yes,
I am blaming the OpenSSL developers for their repeated and continued
failures to do this)

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



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