[Emu] Issue 59 - Key Update

Joseph Salowey <joe@salowey.net> Mon, 12 April 2021 02:41 UTC

Return-Path: <joe@salowey.net>
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 E1EA53A2995 for <emu@ietfa.amsl.com>; Sun, 11 Apr 2021 19:41:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 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_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=salowey-net.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 S7-e1VO_hWto for <emu@ietfa.amsl.com>; Sun, 11 Apr 2021 19:41:03 -0700 (PDT)
Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (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 3B21B3A2993 for <emu@ietf.org>; Sun, 11 Apr 2021 19:41:03 -0700 (PDT)
Received: by mail-lf1-x136.google.com with SMTP id z13so1837563lfd.9 for <emu@ietf.org>; Sun, 11 Apr 2021 19:41:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=salowey-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=8ki8LS8rpgopjmelCaOV214uoVwLSqGBt8gVaH74Qyg=; b=a88MFEEOeIoFHHjiWDSUvcfVYB5dW3k/MOBDNOxY+WOD45sANIT0lsMonPOiKA298C UKYrx2UPwXDsyRx7gnt+q4GXbYzfXJeNW3dYP/HInpYDlulCGJ42d3nb9von0FmdMOAF 7R/YZJ3JwSwBDtL0LmZAOFFLlGWGKcW0xKnsCSFTL7dQFzbLwNgPIZAcQJOcyG65CbEc GDJ3+1rCS6d+ZBD6Y3jnRgKRDzbcev1C+CTe2qWOeUEjskVI91miGABQtKUd/UcC9zFH re6w+qDBjdI8RQ7y/Nc05hbI130DHVyuZ4zEOIInA7jds404uZvJQW/dJg3V150jYiQI xu6A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=8ki8LS8rpgopjmelCaOV214uoVwLSqGBt8gVaH74Qyg=; b=TxCLM6SyQCkWzx2ankKHTN93j696HwSpHK/PijOxeRXFIKc4dlWkciKt3QXLgA4MXC CghhWoRKf4uXvbcH63spE//zm+37mEWYpmUaa+vwNjUk4JXFMrxuL5fB+MeqwmV03wQW uQd7hMoN9tTfMnxDLuEDFU99mWoGPx6Zjylb5N0e5BCxrQ+xdcYBCBm6yiml9f9ajihy z3n5nOnXDNHSsumLLsfrpJCSBNqaW2owcrt3mhB4vMxSj0hQl3AaortiP6ZNQubf9vFC do3mZG4pBnaXmhEyDathCEM2ZcntbHDAAtBJuSxW3BeeDLmHTMu/Q+wFRf7g0zkdDONr BePw==
X-Gm-Message-State: AOAM530udtw85JowyMbE4bxpkAmxTInd1idiMUzyjc5H+XttbRO2Jba9 LgVAS3i/cF6j0JtUR/eBXBAGDHgxmbxrNzz9h4832n+bMHqd8Q==
X-Google-Smtp-Source: ABdhPJxynneUFpx+L2bVaVktlktTMVX/LPfLfW2i2x/iHpXNKSJhe1D8lrL72j8hoYla0enHgzrNIo7TwFROUU3jcYw=
X-Received: by 2002:ac2:4e6f:: with SMTP id y15mr17641708lfs.428.1618195260405; Sun, 11 Apr 2021 19:41:00 -0700 (PDT)
MIME-Version: 1.0
From: Joseph Salowey <joe@salowey.net>
Date: Sun, 11 Apr 2021 19:40:48 -0700
Message-ID: <CAOgPGoA_rFLppfSFLp3-yBq5Vd9Cc4=qY1FTxg3s118Q7qkofQ@mail.gmail.com>
To: EMU WG <emu@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ac8b0805bfbd71d3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/emu/U--xSJP7_YpOfBS4XV1JIZcucJU>
Subject: [Emu] Issue 59 - Key Update
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: Mon, 12 Apr 2021 02:41:05 -0000

Please review the following proposal and discuss issues on this thread.

Alan's review pointed out the following

Section 2.1.1 says:
>    TLS 1.3 introduced the Post-Handshake KeyUpdate
>    message which is not useful and not expected in EAP-TLS.
> Q: What does it mean that the message is "not expected"?  This seems
> like a source of implementation-defined behavior, which experience
> shows has been a source of interoperability and security issues.


This does seem to require some more specification.  Here is a proposal.

"TLS 1.3 introduced the Post-Handshake KeyUpdate message which is not
useful and not expected in EAP-TLS.  Implementations SHOULD NOT send a
KeyUpdate message.  If a KeyUpdate message is received then an
implementation SHOULD ignore the message and it SHOULD NOT send a KeyUpdate
message in response."

I think this is better than "implementations MUST NOT send this message and
MUST fail upon reception".  The problem here is that the EAP TLS
implementation may not have control over this behavior.

Thanks,

Joe