[TLS] Comments on draft-ietf-tls-tls13-cert-with-extern-psk-02

"Hammell, Jonathan F" <Jonathan.Hammell@cyber.gc.ca> Thu, 18 July 2019 16:01 UTC

Return-Path: <Jonathan.Hammell@cyber.gc.ca>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 8547B1207ED for <tls@ietfa.amsl.com>; Thu, 18 Jul 2019 09:01:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id K-AR0dTE7eni for <tls@ietfa.amsl.com>; Thu, 18 Jul 2019 09:01:22 -0700 (PDT)
Received: from cranberry.cse-cst.gc.ca (cranberry.cse-cst.gc.ca []) (using TLSv1.2 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75DBF120806 for <tls@ietf.org>; Thu, 18 Jul 2019 09:01:14 -0700 (PDT)
From: "Hammell, Jonathan F" <Jonathan.Hammell@cyber.gc.ca>
To: "'tls@ietf.org'" <tls@ietf.org>
Thread-Topic: Comments on draft-ietf-tls-tls13-cert-with-extern-psk-02
Thread-Index: AdU9gb6zaT80scqmTia+rfA7cCzu0g==
Date: Thu, 18 Jul 2019 16:01:12 +0000
Accept-Language: en-US
Content-Language: en-US
x-classification: UNCLASSIFIED
Content-Type: multipart/alternative; boundary="_000_9e7a09914b644bdc93f5ba4e074c83a3cybergcca_"
MIME-Version: 1.0
Message-Id: <20190718160114.75DBF120806@ietfa.amsl.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/dGOsI6DCfepG94OEcoYA-eJfXzU>
Subject: [TLS] Comments on draft-ietf-tls-tls13-cert-with-extern-psk-02
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 18 Jul 2019 16:01:25 -0000

Classification: UNCLASSIFIED

I realize publication has been requested for this draft, but I have a few comments that the author might want to address, if still possible.

1. The draft says that if none of the PSKs provided by the client are acceptable to the server, then the extension must be omitted from the ServerHello message.  Nothing is said about how the client should behave if it receives this: continue or abort with what error code?

2. It can be detected if two PSK identifiers sent in the same ClientHello have the same PSK value by observing the binder values.  Granted, I can't think why this would occur, but it might be important to point this out in the Security Considerations in order for implementers to be clear about security guarantees.

3. Section 4, paragraph 3 states that "If none of the external
   PSKs in the list provided by the client is acceptable to the server,
   then the "tls_cert_with_extern_psk" extension is omitted from the
   ServerHello message."

Section 5 has a similar statement but using the word "MUST": "If none of the
   offered external PSKs in the list provided by the client are
   acceptable to the server, then the "tls_cert_with_extern_psk"
   extension MUST be omitted from the ServerHello message."

These statements should be consistent in the requirement language.

4. Section 5, paragraph starting with "The identities are a list of external PSK identities...": s/identities may be know to other parties/identities may be known to other parties

Best regards,

Jonathan Hammell
Canadian Centre for Cyber Security