Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)
David Benjamin <davidben@chromium.org> Sat, 08 October 2016 15:06 UTC
Return-Path: <davidben@google.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 8630012952D for <tls@ietfa.amsl.com>; Sat, 8 Oct 2016 08:06:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.695
X-Spam-Level:
X-Spam-Status: No, score=-5.695 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-2.996, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=chromium.org
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 vdF7IVBkGiuz for <tls@ietfa.amsl.com>; Sat, 8 Oct 2016 08:06:40 -0700 (PDT)
Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (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 48E60129427 for <TLS@ietf.org>; Sat, 8 Oct 2016 08:06:40 -0700 (PDT)
Received: by mail-it0-x232.google.com with SMTP id l13so38792804itl.1 for <TLS@ietf.org>; Sat, 08 Oct 2016 08:06:40 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=aZgtMwUp2l3DdxqAnuMIdcmEUb3QMnF4hH9lPUdfs8E=; b=n1WJVQoynLi1PsDW/sLFSQ0NfeffIBMy8M4V2CIZa+dtv1xcSV5Fw2F/teXvf6WPxZ LYJ1i4tbMoSWKWgJmN9jPp+GDNnRcUdjWpfwh/kTyfyDkl0Rw2FZ0Q7S/Ur/7nVXXMPe PtdYdhHS8pPApUTxA0SzEnYkI3miNAs7Tee08=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=aZgtMwUp2l3DdxqAnuMIdcmEUb3QMnF4hH9lPUdfs8E=; b=RlBO9/2m517C3HWIXxU0fo1qTXzQg5TzX2NEkRP8U3tBnGUC3lo1yGVCJuzg6W5csd L1HGCTqQ6aEW1NYMdh8une24qNSWt9sYMTYP4we93jrKHVqtu0/le+22W6BlbB2J83fW QXFFi9OXMUeVwFO7AlrI+90gKVVE1eSNsiRlAxG2MH+WQLoFiILFfdoqMBn0mlScYLOl ++zSgGt5MHHxUnFTO4Z0oB9xdyr/HYu3xqOpjiVQKELW6nnYW8aZc2Xh13XP8gI/e3bY x41pV3ANoJXWClG5lIKKVWbiCxcjXB0ornoBa/s8pVr+Ci8+1akM6nEdITagGA/e/6vA Fu8w==
X-Gm-Message-State: AA6/9RlFFdn4X7q7IySj/qeoez5eAsCdmprbRJauQ3xTr78scG5BV8ljClFhKaVSD7wuKsdet5aYMjBxzmGo5TG3
X-Received: by 10.36.20.9 with SMTP id 9mr3432178itg.24.1475939199533; Sat, 08 Oct 2016 08:06:39 -0700 (PDT)
MIME-Version: 1.0
References: <CAOjisRznhk-Fww=EnRg7zXO-zaHWyNgi0g+reRBj+y3ZOhwMhw@mail.gmail.com> <20161008090257.GB10692@LK-Perkele-V2.elisa-laajakaista.fi>
In-Reply-To: <20161008090257.GB10692@LK-Perkele-V2.elisa-laajakaista.fi>
From: David Benjamin <davidben@chromium.org>
Date: Sat, 08 Oct 2016 15:06:28 +0000
Message-ID: <CAF8qwaC4qoUqf=f6yKgfk6RAy1odcvDeMWFntMMXQ6TbJXFsYQ@mail.gmail.com>
To: Ilari Liusvaara <ilariliusvaara@welho.com>, Nick Sullivan <nicholas.sullivan@gmail.com>
Content-Type: multipart/alternative; boundary="001a11446af8b3127b053e5bdf23"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/i2QuCkesWyocx2Wx1WGwW2h_EPQ>
Cc: "tls@ietf.org" <TLS@ietf.org>
Subject: Re: [TLS] Making post-handshake messages optional in TLS 1.3 (#676)
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: Sat, 08 Oct 2016 15:06:42 -0000
On Sat, Oct 8, 2016 at 5:03 AM Ilari Liusvaara <ilariliusvaara@welho.com> wrote: On Sat, Oct 08, 2016 at 01:03:21AM +0000, Nick Sullivan wrote: > There has been a lot of discussion lately about post-handshake messages > that do not contain application data and how to handle them. This PR is an > attempt to make the story more explicit by adding a new post_handshake > extension to TLS 1.3. > > Supporting all types of post-handshake messages can require extra > complexity and logic, even when the features that these messages enable are > not needed. Some types of connections/implementations don't need to support > key updates (some unidirectional connections), session tickets (pure PSK > implementations) and post-handshake client auth (most browsers). These are > all currently SHOULDs in the spec and they don't need to be. Post-handshake authentication is the only one of these that is genuinely annoying. This is because you can't even reject it without a MAC, that additionally continues the handshake hash. KeyUpdate is rather simple, and NST can just be ignored (leading to some waste in bandwidth). Yeah, after the fix to how KeyUpdate is acked, I don't think we'd have problems with either of the way, while post-handshake auth is indeed horrific. Furthermore, the post-handshake authentication mechanism doesn't look to be featureful enough for kind of post-handshake auth e.g. HTTP/2 wants, And there are serious questions about how it should interact with applications. An extension also doesn't really capture things if we intend for, say, this to be used for legacy protocols like HTTP/1.1 (where we don't have as rich a framing layer) but not HTTP/2 (where we do and can use it as a substrate for all this silliness). I was anticipating that, if this ends up being used in the HTTP world like renego is, it would be like our renego stuff: off by default, forbidden in HTTP/2, and with all interleave forbidden. Further, what useful thing could a server even do with this extension? Decline to do post-handshake auth doesn't work. Either the application protocol doesn't use post-handshake auth (please pick this one) or it does. One doesn't need to send a client_writes_first extension in HTTP/1.1. Post-handshake auth another knob on the TLS <-> application protocol boundary. This means each application protocol must specify for itself what post-handshake auth means: what to do with the context field, when it may be received, what it does to application flow, etc. Then the spec must be clear that if the application protocol does not opt in, CertificateRequest is forbidden. A CertificateRequest at an unexpected point (say, half-way through a HTTP/1.1 body) is also forbidden. Also make it clear this is for legacy protocols and new ones do not use it. This is analogous to how HTTP/2 forbids renego at the spec level. (TLS 1.2 got the "defaults" for renego wrong.) No one ever wrote down the exact rules for the client-auth/renego hack in HTTP/1.1, but whatever spec does this for post-handshake auth should do the same for renego. It is a lot of spec work for such a tiny-seeming feature, but this is consistent with how messy the feature actually is. David
- [TLS] Making post-handshake messages optional in … Nick Sullivan
- Re: [TLS] Making post-handshake messages optional… Ilari Liusvaara
- Re: [TLS] Making post-handshake messages optional… David Benjamin
- Re: [TLS] Making post-handshake messages optional… Nick Sullivan
- Re: [TLS] Making post-handshake messages optional… David Benjamin
- Re: [TLS] Making post-handshake messages optional… Ilari Liusvaara
- Re: [TLS] Making post-handshake messages optional… Eric Rescorla
- Re: [TLS] Making post-handshake messages optional… Nick Sullivan
- Re: [TLS] Making post-handshake messages optional… Benjamin Kaduk
- Re: [TLS] Making post-handshake messages optional… Martin Thomson
- Re: [TLS] Making post-handshake messages optional… Tom Ritter
- Re: [TLS] Making post-handshake messages optional… Hannes Tschofenig
- Re: [TLS] Making post-handshake messages optional… Eric Rescorla
- Re: [TLS] Making post-handshake messages optional… Nick Sullivan
- Re: [TLS] Making post-handshake messages optional… Andrei Popov
- Re: [TLS] Making post-handshake messages optional… Mike Bishop
- Re: [TLS] Making post-handshake messages optional… Daniel Kahn Gillmor
- Re: [TLS] Making post-handshake messages optional… Ilari Liusvaara
- Re: [TLS] Making post-handshake messages optional… Hannes Tschofenig
- Re: [TLS] Making post-handshake messages optional… David Benjamin