[Emu] POST WGLC Comments draft-ietf-emu-eap-tls13

Jim Schaad <ietf@augustcellars.com> Sat, 03 August 2019 21:53 UTC

Return-Path: <ietf@augustcellars.com>
X-Original-To: emu@ietfa.amsl.com
Delivered-To: emu@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C44C2120144; Sat, 3 Aug 2019 14:53:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 uMfw3yHE66ys; Sat, 3 Aug 2019 14:53:49 -0700 (PDT)
Received: from mail2.augustcellars.com (augustcellars.com [50.45.239.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 115A6120134; Sat, 3 Aug 2019 14:53:46 -0700 (PDT)
Received: from Jude (73.180.8.170) by mail2.augustcellars.com (192.168.0.56) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Sat, 3 Aug 2019 14:53:40 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: draft-ietf-emu-eap-tls13@ietf.org
CC: 'EMU WG' <emu@ietf.org>
Date: Sat, 03 Aug 2019 14:53:37 -0700
Message-ID: <02e001d54a45$e92ae900$bb80bb00$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-us
Thread-Index: AdVKJoKyKr1G5+9hQuKLAEK5rLYqPg==
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/XpRkNN-mh5BuiTD1O8iEfz9sM4M>
Subject: [Emu] POST WGLC Comments draft-ietf-emu-eap-tls13
X-BeenThere: emu@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "EAP Methods Update \(EMU\)" <emu.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/emu>, <mailto:emu-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/emu/>
List-Post: <mailto:emu@ietf.org>
List-Help: <mailto:emu-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/emu>, <mailto:emu-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 03 Aug 2019 21:53:52 -0000

I am just finally getting caught up on mail for the EMU WG and am getting
this done.

It should probably be clarified that Figure 1has the additional restriction
that the server is not sending any resumption tickets as well.    It would
also be better to label the TLS Application Data as the commitment message
as no other TLS Application data is being sent.

I think that it might be reasonable to put in a note for Figure 2 that if a
client does receive a fatal from the hello message, then changing the
offered key share algorithm is one thing that might be successful in the
future - That is put in a note to match what the request retry message does.
Okay - I found the use of the retry down below but it is not referenced from
here but it is still labeled as a server rejects the client hello.

In section 2.1.5 - You are mandating support for resumption.  Is this really
what you are planning to do?  If this is true then lots of the previous text
seems to be off because this is not part of that discussion.

In section 2.1.6 - Should there be a recommendation (or not) that when a
resumption ticket is used, then a new ticket (or set of tickets) ought to be
provided to the client.

In section 2.5 - I don't know that I have the ability to control what the
TLS block looks like to the extent that this seems to be wanting to do.

In section 5.7 - I am not sure why one could not re-check for revocation
when doing a resumption, I would expect that this is only server side that
would do it but the current paragraph two outlaws it.

I am a little surprised that the padding feature of TLS 1.3 received
absolutely no mention in this document.

Jim