Re: [TLS] I-D Action: draft-ietf-tls-oob-pubkey-08.txt

Hauke Mehrtens <hauke@hauke-m.de> Tue, 16 July 2013 11:50 UTC

Return-Path: <hauke@hauke-m.de>
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 68AA811E8299 for <tls@ietfa.amsl.com>; Tue, 16 Jul 2013 04:50:49 -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=-2.599]
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 l7MHl+kSJIFr for <tls@ietfa.amsl.com>; Tue, 16 Jul 2013 04:50:48 -0700 (PDT)
Received: from hauke-m.de (Hauke-2-pt.tunnel.tserv6.fra1.ipv6.he.net [IPv6:2001:470:1f0a:465::2]) by ietfa.amsl.com (Postfix) with ESMTP id A74C711E8276 for <tls@ietf.org>; Tue, 16 Jul 2013 04:50:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by hauke-m.de (Postfix) with ESMTP id 149C48F61 for <tls@ietf.org>; Tue, 16 Jul 2013 13:50:47 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at hauke-m.de
Received: from hauke-m.de ([127.0.0.1]) by localhost (hauke-m.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIj0i5wSTTV3 for <tls@ietf.org>; Tue, 16 Jul 2013 13:50:41 +0200 (CEST)
Received: from [192.168.1.178] (spit-414.wohnheim.uni-bremen.de [134.102.133.158]) by hauke-m.de (Postfix) with ESMTPSA id C81FA857F for <tls@ietf.org>; Tue, 16 Jul 2013 13:50:41 +0200 (CEST)
Message-ID: <51E5338F.9030100@hauke-m.de>
Date: Tue, 16 Jul 2013 13:50:39 +0200
From: Hauke Mehrtens <hauke@hauke-m.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7
MIME-Version: 1.0
To: tls@ietf.org
References: <20130715231127.14144.44003.idtracker@ietfa.amsl.com>
In-Reply-To: <20130715231127.14144.44003.idtracker@ietfa.amsl.com>
X-Enigmail-Version: 1.4.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] I-D Action: draft-ietf-tls-oob-pubkey-08.txt
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Tue, 16 Jul 2013 11:50:49 -0000

On 07/16/2013 01:11 AM, internet-drafts@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>  This draft is a work item of the Transport Layer Security Working Group of the IETF.
> 
> 	Title           : Out-of-Band Public Key Validation for Transport Layer Security (TLS)
> 	Author(s)       : Paul Wouters
>                           Hannes Tschofenig
>                           John Gilmore
>                           Samuel Weiler
>                           Tero Kivinen
> 	Filename        : draft-ietf-tls-oob-pubkey-08.txt
> 	Pages           : 15
> 	Date            : 2013-07-15
> 
> Abstract:
>    This document specifies a new certificate type and two TLS
>    extensions, one for the client and one for the server, for exchanging
>    raw public keys in Transport Layer Security (TLS) and Datagram
>    Transport Layer Security (DTLS) for use with out-of-band public key
>    validation.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-tls-oob-pubkey
> 

Thanks for the new draft.

I have some comments to this version:

In section 3. New TLS Extension the link to Section 2.3.5 of RFC 5480
is wrong, this should be just Section 2.

RFC 5480 defines a lot more OIDs which could be used as an algorithm OID
than listen in Figure 3. ECDSA defines a different OID for every
standardized curve. I think naming the OID in Figure 3 should be removed
and there should just be a pinter to the RFC. It should also be made
clear that there could be further RFC than RFC 3279, RFC3279 and RFC5480
defining OIDs used in the SubjectPublicKeyInfo, like RFCs defining a new
public key type.

Could you add some list definition where the numbers assigned by the
IANA should be added later. I like how it is done in
draft-mcgrew-tls-aes-ccm-ecc-06 for the CipherSuites [0].

Are there some intermediate version of this draft available, like a
public readable svn repository where the work on this draft is happening?

Hauke


[0]: https://tools.ietf.org/html/draft-mcgrew-tls-aes-ccm-ecc-06#section-2