[TLS] Problem with DTLS 1.2 handshake

Jim Schaad <ietf@augustcellars.com> Mon, 26 March 2018 13:09 UTC

Return-Path: <ietf@augustcellars.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 C29C3124D68 for <tls@ietfa.amsl.com>; Mon, 26 Mar 2018 06:09:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 NZ-jLEEdCpOD for <tls@ietfa.amsl.com>; Mon, 26 Mar 2018 06:09:28 -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 03E611201FA for <tls@ietf.org>; Mon, 26 Mar 2018 06:09:28 -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.1347.2; Mon, 26 Mar 2018 06:07:14 -0700
From: Jim Schaad <ietf@augustcellars.com>
To: tls@ietf.org
Date: Mon, 26 Mar 2018 06:09:18 -0700
Message-ID: <027001d3c503$a78b14c0$f6a13e40$@augustcellars.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdPFAsfDJjYzSSm4TLSOxPjiFRewjQ==
Content-Language: en-us
X-Originating-IP: [73.180.8.170]
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/sbPuZCw5zOs2LpkAPX6I2isGBTM>
Subject: [TLS] Problem with DTLS 1.2 handshake
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 26 Mar 2018 13:09:30 -0000

I appear to have run across an implementation that does not appear to
violate the specification, but which in my opinion is just plain wrong.

I am doing a handshake with PSK.  On the second flight from the client it
sends 

[ChangeCipherSpec]
Finished

The server sees that the ChangeCipherSpec occurs and moves to use the keys.
It then attempts to validate the MAC on the Finished message and silently
ignores the Finish message because the MAC is incorrect and the text says
that it is legal to ignore packets which have a bad MAC.  This means that my
client re-sends the same flight to the server on and on because it never
gets a response and assumes that the packet must be getting lost in transit.


The document does not say that ignoring of bad MACs does not apply until the
Finished message is received and processed.  I am not sure, but I believe
the document needs to say that one cannot ignore a failed MAC on the first
block of data in any epoch and must error on those messages.  

I have not looked to see if this is an issue for DTLS 1.3, but it could
easily be.

Jim