Re: [TLS] [DTLS]: how to handle unknown identity and bad psk ?
Eric Rescorla <ekr@rtfm.com> Fri, 06 April 2018 17:27 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 DE0C912025C for <tls@ietfa.amsl.com>; Fri, 6 Apr 2018 10:27:17 -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 BiziuJZjNtEu for <tls@ietfa.amsl.com>; Fri, 6 Apr 2018 10:27:15 -0700 (PDT)
Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 A33321200C5 for <tls@ietf.org>; Fri, 6 Apr 2018 10:27:15 -0700 (PDT)
Received: by mail-oi0-x22f.google.com with SMTP id 188-v6so1736855oih.8 for <tls@ietf.org>; Fri, 06 Apr 2018 10:27:15 -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=9BOXTA4dcE043YPFpoBAmgHksHZzSmDmD0YOfx6jnQM=; b=Ir9XP8wRl/AywRa/cFyjhCHWGln0UnkmtKWRx1MrNIxNi5pLxSTIcCVs7P1cEkNVIM J5iKpL4nxg0FMHcmIolFENLzQN9w79CSCXcdlpAHCVAgKNVA5fN4Y5TjUhdZphmIgbcv BVYdc/yZLmQ8nS7NtBkggdsdAQWGCrUaGcQnhnnAnpJpdN2YvJHnjUlGqCGm98MJGCTs 4dZMkerIHw2aGLwYxutRd19U/2LvRC1+KQNhaRoaR8TIKQDBxkKiExC/LpBuOyBKC4st msaNE/by+rIZkv3SbcmGmsQR96AmkqOD9suodFxPwVa71qs1aZs9P++CIHvY/EGctYd5 hXDQ==
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=9BOXTA4dcE043YPFpoBAmgHksHZzSmDmD0YOfx6jnQM=; b=Iop7JjNtJpBiBVc7EDftLAgZ7LKoNkC/REdGF3Tj9jOTYv4YvMHF9/bKrmJAJwYVs/ HxCtLn5xEByWptEPD8eXnTpn6xd+jMhi/0XwGMX6fglvWGX+TYU7jZH2HnDbBahkkkPw iGweez4+9s90GQh+JyKLRAEqJpTw/359rsd3+JDFPgMRLeSmcJCrAfKFSlt0QeJFP59n d8+ODdptztIS5X2Jjsy0/Cs7mWnJkheE5ZB/pTWpRj8vTiWDFmsbKyOLqNwEO5SxTnnd ZLKh5CuU/vQIZ9aPN+bqJRBkHFy1DuOSfVpqHf/rRkyIY8HdMaI8waxesLycrOGrL+7d Fljw==
X-Gm-Message-State: ALQs6tCD+vBmi+0dtuf54iZZFIkqmSZPfW77JMFrnv3SKPLwFvDHnYdJ j0XstIlsAN7cLzhkRiqy4O6/3JBwMHx21NGGygCTkgnP
X-Google-Smtp-Source: AIpwx49yZTq4SiiDAsVXDjh8/AIhdA5EnpwR69wK/xusCv/XYdmhJaNjpjDaUnnCafskrP84897FzguWVSwfpBAHfOc=
X-Received: by 2002:aca:4f46:: with SMTP id d67-v6mr15090002oib.138.1523035635022; Fri, 06 Apr 2018 10:27:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.138.18.130 with HTTP; Fri, 6 Apr 2018 10:26:34 -0700 (PDT)
In-Reply-To: <e36279ab-2ac7-3ab6-a1b6-d1fac2b0aa79@simonbernard.eu>
References: <e36279ab-2ac7-3ab6-a1b6-d1fac2b0aa79@simonbernard.eu>
From: Eric Rescorla <ekr@rtfm.com>
Date: Fri, 06 Apr 2018 10:26:34 -0700
Message-ID: <CABcZeBNf+svJCN8LpkF0c_rkOAhsCSjheK8ms1qkFvpZgafrNA@mail.gmail.com>
To: Simon Bernard <contact@simonbernard.eu>
Cc: "tls@ietf.org" <tls@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000001bd8e0569315e7a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/UCrsB6RTn0jqpGugPKnRq4yjSmY>
Subject: Re: [TLS] [DTLS]: how to handle unknown identity and bad psk ?
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: Fri, 06 Apr 2018 17:27:18 -0000
On Fri, Apr 6, 2018 at 10:16 AM, Simon Bernard <contact@simonbernard.eu> wrote: > Hi, > > We are implementing DTLS with PSK over UDP and I would like to know how > "unknown identity" and "bad psk" should be handled > > Pre-Shared Key Ciphersuites for Transport Layer Security (TLS) says : > (https://tools.ietf.org/html/rfc4279#section-2) > > > If the server does not recognize the PSK identity, it MAY respond > > with an "unknown_psk_identity" alert message. Alternatively, if the > > server wishes to hide the fact that the PSK identity was not known, > > it MAY continue the protocol as if the PSK identity existed but the > > key was incorrect: that is, respond with a "decrypt_error" alert. > > In TLS the safer way seems to send a "decrypt_error" alert for both. > > But in DTLS : > https://tools.ietf.org/html/rfc6347#section-4.1.2.7 > > > In general, invalid records > > SHOULD be silently discarded, thus preserving the association; > > however, an error MAY be logged for diagnostic purposes. > > Implementations which choose to generate an alert instead, MUST > > generate fatal level alerts to avoid attacks where the attacker > > repeatedly probes the implementation to see how it responds to > > various types of error. Note that if DTLS is run over UDP, then any > > implementation which does this will be extremely susceptible to > > denial-of-service (DoS) attacks because UDP forgery is so easy. > > Thus, this practice is NOT RECOMMENDED for such transports. > > Is this record layer recommendation for all type of record ? even > HANDSHAKE(22) record (and so FINISHED message) or is it mainly for > APPLICATION_DATA(23) record ? > > Is it acceptable to send fatal alert "decrypt_error" in DTLS or should we > just ignore bad credentials silently ? > Hi Simon, The advice in 4279 is basically "make an unknown identity look like a bad key". So the idea would be to just randomize the key and then get the TLS or DTLS-type behavior. I.e., with TLS you would send decrypt_error and in DTLS the handshake would just stall because you would drop packets. -Ekr -- > Simon > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >
- [TLS] [DTLS]: how to handle unknown identity and … Simon Bernard
- Re: [TLS] [DTLS]: how to handle unknown identity … Eric Rescorla
- Re: [TLS] [DTLS]: how to handle unknown identity … Kraus Achim (INST/ECS4)
- Re: [TLS] [DTLS]: how to handle unknown identity … Simon Bernard
- Re: [TLS] [DTLS]: how to handle unknown identity … Jim Schaad