[TLS] certificate type negotiaiton in draft-ietf-tls-oob-pubkey-06

Nikos Mavrogiannopoulos <nmav@gnutls.org> Sun, 02 December 2012 07:57 UTC

Return-Path: <n.mavrogiannopoulos@gmail.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 7378321F8EF6 for <tls@ietfa.amsl.com>; Sat, 1 Dec 2012 23:57:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUJSKV1XC-2s for <tls@ietfa.amsl.com>; Sat, 1 Dec 2012 23:57:15 -0800 (PST)
Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by ietfa.amsl.com (Postfix) with ESMTP id 36DED21F8EF0 for <tls@ietf.org>; Sat, 1 Dec 2012 23:57:14 -0800 (PST)
Received: by mail-wi0-f170.google.com with SMTP id hq7so508455wib.1 for <tls@ietf.org>; Sat, 01 Dec 2012 23:57:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=yWlvVB2sYjEqhImv8Fpxd+MB0GHeeKyCoW24ytrlET8=; b=E0abIZjh6nW1VBYLEVv1mfpFYI5Aa+1N7IkQ/nYUXPR8s3w2sTBxhHmv1jQdmcuzXt 0eEBdpcmZR+QlmNgYyVLDEJueN9Y1xIdQx7sqEvJCPcAOn1iE/VVYf9E+A5TSQmfrQ7P xHBEWGsCbJY8SRm3+6AAPrbQcgv3uW+YEs2oIzBx+TQmiDIwmVBsVGj0K30L/Xm1STkg 8hUh0GA6mRQ1gsyM3YwYgNI1SpL9i8gZzufHFSkJ20vEcwFvX3xK7w0bOQww730A0BnW Qsii2x/+DAKiNNtZLJ3y8uXa2EgCGpXS/GvOmvw7rVVTxydKy4JH1QoF5YrC129ojBuQ cBFg==
Received: by 10.180.84.101 with SMTP id x5mr4471956wiy.18.1354435034213; Sat, 01 Dec 2012 23:57:14 -0800 (PST)
Received: from [10.100.2.17] (94-224-100-5.access.telenet.be. [94.224.100.5]) by mx.google.com with ESMTPS id p2sm6744299wic.7.2012.12.01.23.57.12 (version=SSLv3 cipher=OTHER); Sat, 01 Dec 2012 23:57:13 -0800 (PST)
Sender: Nikos Mavrogiannopoulos <n.mavrogiannopoulos@gmail.com>
Message-ID: <50BB09D3.6010106@gnutls.org>
Date: Sun, 02 Dec 2012 08:57:07 +0100
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.10) Gecko/20121027 Icedove/10.0.10
MIME-Version: 1.0
To: tls@ietf.org
X-Enigmail-Version: 1.4.1
OpenPGP: id=96865171
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [TLS] certificate type negotiaiton in draft-ietf-tls-oob-pubkey-06
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: Sun, 02 Dec 2012 07:57:16 -0000

Hello,
 There is a bug in the draft. The CertTypeExtension structure is defined as:
   struct {
      select(ClientOrServerExtension)
          case client:
            CertificateType certificate_types<1..2^8-1>;
          case server:
            CertificateType certificate_type;
      }
   } CertTypeExtension;

but the server is expected to send more than one certificate types (as
seen in examples). This cannot happen with the current structure.

Also the whole certificate type negotiation seems complicated. Currently
the certificate types are defined as:

   enum { X.509-Accept (0),
          X.509-Offer (1),
          RawPublicKey-Accept (2),
          RawPublicKey-Offer (3),
          (255)
         } CertificateType;

So a client that accepts X.509 certificates and has a raw key will send
(from the example in the draft)

certificate_type=(X.509-Accept(0), RawPublicKey-Offer(3)) ->

                            <-  server_hello,
                                certificate_type=(X.509-Offer(1),
                                     RawPublicKey-Accept(2)),

Which can be confusing. Why sbd suggest 0,3 and the server reply with 1,2?

I think it would be much simpler to have the certificate type defined as
   enum { X.509 (0),
          RawPublicKey (1),
          (255)
         } CertificateType;

and then modify the extension as:
   struct {
      select(ClientOrServerExtension)
          case client:
            CertificateType client_certificate_types<1..2^8-1>;
            CertificateType server_certificate_types<1..2^8-1>;
          case server:
            CertificateType client_certificate_type;
            CertificateType server_certificate_type;
      }
   } CertTypeExtension;

Which will result in a simpler exchange, and there is no need to know
which side is it in order to interpret the contents of the messages.

client_certificate_type=(raw(1))
server_certificate_type=(x509(0))

                            <-  server_hello,
                                client_certificate_type=(raw(1))
                                server_certificate_type=(x.509(0))

regards,
Nikos