IETF Logo Mail Archive

Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)

Eric Rescorla <ekr@rtfm.com> Thu, 04 February 2021 14:32 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 674B13A1526 for <tls@ietfa.amsl.com>; Thu, 4 Feb 2021 06:32:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.896
X-Spam-Level:
X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 MQ6YvyQtgOri for <tls@ietfa.amsl.com>; Thu, 4 Feb 2021 06:32:18 -0800 (PST)
Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (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 C93583A1529 for <tls@ietf.org>; Thu, 4 Feb 2021 06:32:17 -0800 (PST)
Received: by mail-lj1-x22d.google.com with SMTP id c18so3619486ljd.9 for <tls@ietf.org>; Thu, 04 Feb 2021 06:32:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YNMND1KRRcssyJgG/vpRh3BPT9cleuNP8MTs5lhpYOs=; b=krHS/3A1K8WvWYWgVgUT0Pg7DLqQq4cqkRL9rhwyOYMhqlaomE/WkIxJgdo6uaYN8+ 3//f+bJl+kDXscBOvZyWSO6nNLcRFcjR5bVX3rVUX1JeugKLm9QI9hun9aEBh6yYHqd7 xYGYvea1O7EJvzStsBriNVlX597SGQ+xA1wtkhPUn5vYnatN4AINgFB0RQlznspVAjuG 2r1RKldURTj+hO5Xoc/yUF2/o5BxAeyz8LXVuvAPKzOmkn/J2Mhz25dI6fZDty5oVhy2 QYKe4PlC7hlE2yqWJUvKnYQnl7VZGlBcwlSPJmb0d66Zroq1ENcuEuoftoWruHc00vWy RABA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YNMND1KRRcssyJgG/vpRh3BPT9cleuNP8MTs5lhpYOs=; b=ImYXpAxf+t44cUClIrQnMp6x+J5NLuS7TPvHRbL/U5u9qrdLF+L9T+EH5TU4PRnzVT +5jyIS8kno07v1wDmFSb454afIgBFjUPfl4aJfHguzoJ9yITQEdrEd60iJeErCCuZ4WC 62mf60iAnLunNRBq42TY+bx18ZSf11shf2ItxXTTfvkkz4WqNb4LYb+1Z9RnBkM0GW2D k2Req0WjR7E0RdlgRAeJKuZ2qXdjKgC7A8oXBQ8xyD3bOAE+ewg6EMJUrAPymiK4RTIW rnIRhvAXYuxHpsxP5PcjGW1gUKZVpIGXy1JFhjeM3mAXF3/0Da/APrqrYzHU7Ts2tNIs fcrA==
X-Gm-Message-State: AOAM532pHVaHJ+W6/pTSvngTS3pXi5J5umTh4a3lNrUbJ7OupyOV8oCT io9Z8Xh+OCpbn/TOQ9mXNh1mr8F+5dsnb8EP5bPDlQ==
X-Google-Smtp-Source: ABdhPJx0bXO20M2l1TW9vZcEU/gwiCfpsM/uFVHvJ+fIYkEsx6oLYOjGpzuXd3V3BN+nPWGOu3MOpo/SS5mf+wM6nM4=
X-Received: by 2002:a2e:9b83:: with SMTP id z3mr4936039lji.82.1612449135844; Thu, 04 Feb 2021 06:32:15 -0800 (PST)
MIME-Version: 1.0
References: <e669002f-caff-1e6e-e28b-d09157eb0c07@ericsson.com> <6241F0B6-C722-449E-AC3A-183DE330E7B5@deployingradius.com> <9ddd1593-3131-f5cc-d0db-74bf3db697bf@ericsson.com> <3CB58153-8CCA-4B1E-B530-BA67A6035310@deployingradius.com> <CAOgPGoA3U+XpZMY7J+KGovNx6MtAdEzRaGW33xVJdQNWSi4LVg@mail.gmail.com> <770e6a49-52fc-4e8b-91af-48f85e581fbb@www.fastmail.com> <CAOgPGoBGOMXH-kMhQSujWxnACdmBL845u0ouE0fUYc4rWtUrZg@mail.gmail.com> <ca4c526e-79a0-4fa7-abda-2b626795f068@www.fastmail.com> <3409F71E-4CE4-46BB-8079-BFBE9BE83C9A@deployingradius.com> <66157321-55DC-4831-8EF2-D75934D9024C@deployingradius.com> <20210129183220.GI21@kduck.mit.edu> <1A830492-3404-4BCC-844B-D7D950458BD9@deployingradius.com> <CABcZeBMAtmPfG0rctvO8UvnhPqY1etk=SxnonP_t6ysNxH7hVA@mail.gmail.com> <470E0468-E1D8-486E-A2CA-2F042EE8F2C2@ericsson.com> <CABcZeBNGtyGKLGCvbBDg=3JWpuCD7trBX5Du=FOs1yVD0kzoWw@mail.gmail.com>
In-Reply-To: <CABcZeBNGtyGKLGCvbBDg=3JWpuCD7trBX5Du=FOs1yVD0kzoWw@mail.gmail.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Thu, 04 Feb 2021 06:31:39 -0800
Message-ID: <CABcZeBOUJ5k=ZvWEFLPUxrDofBa4J+OBiHJscv7bjocT5=fUww@mail.gmail.com>
To: John Mattsson <john.mattsson@ericsson.com>
Cc: EMU WG <emu@ietf.org>, Benjamin Kaduk <kaduk@mit.edu>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f5f1e905ba83912e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/bBRs9QD3RRGa3oBWGmwuBzZ-lds>
Subject: Re: [TLS] [Emu] Fwd: Benjamin Kaduk's Discuss on draft-ietf-emu-eap-tls13-13: (with DISCUSS and COMMENT)
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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, 04 Feb 2021 14:32:19 -0000

On Thu, Feb 4, 2021 at 6:29 AM Eric Rescorla <ekr@rtfm.com> wrote:

>
>
> On Thu, Feb 4, 2021 at 12:57 AM John Mattsson <john.mattsson@ericsson.com>
> wrote:
>
>> Hi,
>>
>>
>>
>> I think the idea of a new TLS extension to make TLS 1.3 and EAP-TLS
>> interact better is a very promising idea. This would probably take some
>> time to get specified and implemented so it is probably a future
>> optimization/simplification rather that something EAP-TLS 1.3 should wait
>> for.
>>
>>
>>
>> An extension that "I do not send any post-handshake messages" would work
>> and remove the need for a commitment message.
>>
>>
>>
>> ------------------------------------
>>
>> NoPostHandShake Extension
>>
>> ------------------------------------
>>
>>
>>
>> Clients MAY send this extension in ClientHello. It contains no data.
>>
>>
>>
>> Servers MAY send this extension in EncryptedExtentions. It contains no
>> data.
>>
>>
>>
>> When the "NoPostHandShake" extension is negotiated, the server MUST NOT
>> send any post handshake messages.
>>
>>
>>
>> -------------------------------------
>>
>>
>>
>> However, this would also stop the client from doing resumption which is
>> also very important. EAP-TLS fragments TLS into a large number of
>> round-trips, and database lookup to authorize clients is often slow, so
>> resumption is essential to get good performance.
>>
>>
>>
>> The current Post-Handshake NewSessionTicket is not well-suited for
>> EAP-TLS as is introduces the demand for the commitment message as well as
>> introducing an extra round-trip.
>>
>
> I don't really understand what EAP needs here, but it seems to me that the
> commitment message (or the close_notify) is serving two purposes:
>

> 1. Saying that the handshake completed successfully
>

Though note that this is an external semantic to TLS for close_notify. It's
not specified with that reqt.

-Ekr

2. Saying that there will be no more messages
>
> I understand from the discussion that knowing that there will be no more
> messages is useful. Do you think that the client knowing that the handshake
> completed is unnecessary?
>
> -Ekr
>
>

v2.23.0 | Report a Bug | By Email