Re: [TLS] Problem with DTLS 1.2 handshake

Eric Rescorla <ekr@rtfm.com> Mon, 26 March 2018 14:15 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 DCE651275AB for <tls@ietfa.amsl.com>; Mon, 26 Mar 2018 07:15:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham 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 2MrhzhYqGtiQ for <tls@ietfa.amsl.com>; Mon, 26 Mar 2018 07:15:25 -0700 (PDT)
Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (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 BAB3B1273E2 for <tls@ietf.org>; Mon, 26 Mar 2018 07:15:25 -0700 (PDT)
Received: by mail-oi0-x230.google.com with SMTP id x20-v6so15919032oie.2 for <tls@ietf.org>; Mon, 26 Mar 2018 07:15:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=zqMzh5/LNStTj/YjJdCZJOQGWoiwFLjfTbtAcAQfBYw=; b=m1RyrL88ift26l2S8uZFu8lS5RSFtrXckLyO5Szz/07T+aSAYjrl/2HV1cI+tteED0 8IMbNytGIIzGPe3s7ucJzRXk5cxZOitW7LFzSTNKqKXk7PdFs9EtDZQIzGR/EXE0QouK S85pUGSlWRvbDa8tY21JNqrFmkcrowSyfLxL6q3i5Kryve7rxeTwUTEctJxBqKsugZLj UKEOkr8d8nGZ5T59CanEIc6gCLLbc4tc5P2yPOZQ3AgH/ryn4R1pUrAaiplL6mwKYz5E 5RrZcF2xwUTShfADC7jFoVfcVJ8XHArxd09/fgjH04cYS+bD+yy9IpLMNfJMMP9wF9A7 oYkQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=zqMzh5/LNStTj/YjJdCZJOQGWoiwFLjfTbtAcAQfBYw=; b=VHCPwQqX972e9ypGv9NpjbGuQPJKURrhit+LHTipP4bwmCTsWo/J+P3QKKdz5Mt+WU IyrW4rhaxwaQReIwbLbHIRRMk06F99SdBNJwwlNWmX3g39PkJKTBDGq/frQOkVtSF81m NmV6DJffRemI3DosufZyGfLIRJvpNN1TPqF3bj4kU9sMMUN/mI/+9aii+IsljoYoWEAv Sef4u5xu/DNAe5UacDlpQ7ySjN7EZUfj22MC51mb2s8rHtcK7rDYEkFx6fqCeua81jRn oCXzRbGsu/KhOhzzMajFmClZX1NykWMYSjn6bHKMsHZeOqmoCar4uWC1E3yB5bT2I3jt 764Q==
X-Gm-Message-State: AElRT7F3YZ9pjZEZMm/EdTSf8IC4LqNx33PgUjn2WAv8nKKoZs7CGDdL dNDxAanDH7qOI+ZU7RNO/CpmxusFb3+IyruGFeBm9vf8Rtc=
X-Google-Smtp-Source: AIpwx4/xnWHG6TrW0d9Mn4UtL/z+rRWOD1Uz0wEe7arRiOZ4tigGz0QnjiyQ5+Kv//f7AX6SWg9WJzIOH341bIsn/go=
X-Received: by 10.202.79.70 with SMTP id d67mr2912834oib.138.1522073724936; Mon, 26 Mar 2018 07:15:24 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.201.23.21 with HTTP; Mon, 26 Mar 2018 07:14:44 -0700 (PDT)
In-Reply-To: <028101d3c509$15631970$40294c50$@augustcellars.com>
References: <027001d3c503$a78b14c0$f6a13e40$@augustcellars.com> <CABcZeBMTusQvQXfGbq+LRWBSDrvBu2bZcV0TBzo8VLDsQSm6pw@mail.gmail.com> <028101d3c509$15631970$40294c50$@augustcellars.com>
From: Eric Rescorla <ekr@rtfm.com>
Date: Mon, 26 Mar 2018 07:14:44 -0700
Message-ID: <CABcZeBOZwajMdBJLKf+x3k-u9Eyt=-mL76N34TC65vkuUvWoVw@mail.gmail.com>
To: Jim Schaad <ietf@augustcellars.com>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="001a113d858ab275170568516763"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/nk-TU2zJAR7PBsODSoTSjAbfqXQ>
Subject: Re: [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 14:15:28 -0000

On Mon, Mar 26, 2018 at 6:48 AM, Jim Schaad <ietf@augustcellars.com> wrote:

> Yes, I am talking about the TLS record MAC.
>
>
>
> In my case this was happening because of a misconfiguration on the PSK.
> When we finally figured out that this was a MAC error on the record, then
> we immediately looked at the values of the PSK knowing that this was the
> most likely failure.
>

Well, you'll note that TLS 1.3 will not have this problem because the
binder check will fail.



> The fact that in the main handshake this leads to a large amount of
> retries by the client I am not sure that this is just a slower failure
> detection.  I agree that this is less of an issue for a simple rotate the
> keys problem.  I am slightly worried about having the same problem on a
> re-negotiation though.
>

How would that happen unless you had an implementation defect.

-Ekr





>
>
> Jim
>
>
>
>
>
> *From:* Eric Rescorla <ekr@rtfm.com>
> *Sent:* Monday, March 26, 2018 6:24 AM
> *To:* Jim Schaad <ietf@augustcellars.com>
> *Cc:* <tls@ietf.org> <tls@ietf.org>
> *Subject:* Re: [TLS] Problem with DTLS 1.2 handshake
>
>
>
> First, just for clarification, you mean the TLS record MAC on the Finished
>
> rather than the TLS Finished MAC, right?
>
>
>
> Assuming that is correct, then I believe this is reasonable behavior. It
>
> makes the protocol somewhat more resistant to damaged bits on the wire.
>
> Note that QUIC takes this position even further: every packet is integrity
>
> protected (the initial packets use a key based on the CID). The primary
>
> consequence of this is slower failure detection, but the kind of case
> you're
>
> talking about primarily happens when there is an implementation error,
>
> so not much in the field anyway.
>
>
>
> -Ekr
>
>
>
>
>
> On Mon, Mar 26, 2018 at 6:09 AM, Jim Schaad <ietf@augustcellars.com>
> wrote:
>
> 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
>
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
>