[secdir] SecDir review of draft-ietf-tls-oob-pubkey-09

Yaron Sheffer <yaronf.ietf@gmail.com> Tue, 06 August 2013 17:53 UTC

Return-Path: <yaronf.ietf@gmail.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C9A421E80BE; Tue, 6 Aug 2013 10:53:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id It1O5ZCVHkMM; Tue, 6 Aug 2013 10:53:30 -0700 (PDT)
Received: from mail-ea0-x229.google.com (mail-ea0-x229.google.com [IPv6:2a00:1450:4013:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 760B021E8093; Tue, 6 Aug 2013 10:53:02 -0700 (PDT)
Received: by mail-ea0-f169.google.com with SMTP id z7so371958eaf.0 for <multiple recipients>; Tue, 06 Aug 2013 10:52:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; bh=zWe6vF5RC5FxYgXbRhAzCLV2N3ilMcTSgoEc0sm7TJU=; b=SoXF74GP6RmbU3xJX5oFkJDBYB/7Wg51SyfQfSz/nIMQbgNuvh8k0bsXiT/U7jKtY9 GZAY0e531XoaUK0F03y6qbiz4eDppjXJfxI1wnKEVRDNl2wI1hN7EvynqeVIcygpRe1g ILVDbH/LrEj0l1Zf4uMgxeDjM0WREU1zi3sOcW+oeL2g6T9xb8VNY/vWKpwXzKkuXabV UmUwLu4f8YRONxf08I/rYvfLBHaC9RV0apJNktF3SaLcaW6s8gQzS8feqYQV/oZJL/xt 5q6s/vbPPLH36faIGlaiZ40YiU9sitF64CzssVaAmarngaeUjnEAMr1Ork8SAP1K0wWI 84lw==
X-Received: by 10.15.81.129 with SMTP id x1mr2229153eey.82.1375811577322; Tue, 06 Aug 2013 10:52:57 -0700 (PDT)
Received: from [10.0.0.5] (bzq-79-182-192-146.red.bezeqint.net. [79.182.192.146]) by mx.google.com with ESMTPSA id k3sm3652505een.16.2013.08.06.10.52.55 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 06 Aug 2013 10:52:56 -0700 (PDT)
Message-ID: <520137EC.2030607@gmail.com>
Date: Tue, 06 Aug 2013 20:52:44 +0300
From: Yaron Sheffer <yaronf.ietf@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
MIME-Version: 1.0
To: IETF Security Directorate <secdir@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-tls-oob-pubkey.all@tools.ietf.org
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Subject: [secdir] SecDir review of draft-ietf-tls-oob-pubkey-09
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 06 Aug 2013 17:53:45 -0000

I have reviewed this document as part of the security directorate's 
ongoing effort to review all IETF documents being processed by the IESG. 
These comments were written primarily for the benefit of the security 
area directors. Document editors and WG chairs should treat these 
comments just like any other last call comments.

This document adds into TLS support for bare public keys (as opposed to 
keys wrapped in certificates). The main use case cited is constrained 
devices that get their trust anchors in an out-of-band manner (e.g. - 
horror - embedded in their software) as a set of trusted public keys.

Summary: this document is almost ready for publication, but needs 
several clarifications and text improvements. Since some of the missing 
pieces revolve around authentication, we may even need another last call 
if (as discussed in Berlin) the document is to be merged or coordinated 
with the Channel ID work.

Details

• 1: "an out-of-band mechanism is also used to bind the public key to 
the entity presenting the key" - this text is strange. Obtaining the 
public key can be OOB, but binding to the TLS identity is part of the 
protocol negotiation. This sentence sounds as if we're trying to avoid a 
"MUST authenticate".
• More generally, if the peer has an OOB way to obtain the public key 
(it has to have one, otherwise it wouldn't be able to bind it to an 
identity), why are we sending the full public key in the handshake, 
rather than only a fingerprint? Reading further (in the Acknowledgements 
section) it would appear this question has already been discussed in the 
WG. Shouldn't this option, or the interaction with "cached info", be 
mentioned here?
• 3, Fig. 1: why do we support a sequence of public keys? What is the 
semantics? If the semantics is that you can authenticate using *one* of 
the provided keys, then why not support mixing public keys and 
certificates, or RSA with ECDSA public keys?
• 3: "These extension MUST be omitted if the client only supports X.509 
certificates" (note the typo, should be "this") - this is IMO 
overspecified, especially since the client can send a list of length 1 
containing only the X.509 identifier.
• "The 'server_certificate_type' in the client hello indicates the type 
of certificates" - this is probably a typo, and should be "types", i.e. 
a list.
• In the two paragraphs discussing the semantics of the extensions, the 
word "supported" is used very loosely, sometimes referring to what you 
can send and sometimes to what you can accept. I suggest to clarify this 
point, and I suspect that the last sentence ("if the server does not 
send...") which is currently unclear will have to be corrected.
• 4.1: " MUST include the 'client_certificate_type' and 
'server_certificate_type' extensions" - do you really have to include 
both extensions? What if only the server presents a public key?
• 4.2, bullet #2: does the server need to have a cert type in common 
with the client, or just in common with the types that the client 
specified in the "server cert type" extension?
• 5, Fig. 8: does the client really have to indicate support of the 
server sending an X.509 cert? What if the client omits the 
server_certificate_type extension?
• 6: what exactly is meant by "to check the status of that binding"?
• 7: at least in the HTML version of this draft, the 
value/description/reference lines appear *before* the introductory sentence.

Thanks,
Yaron