From ekr@rtfm.com Sat Dec 1 11:42:36 2012 Return-Path: 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 DFCEE1F0C73 for ; Sat, 1 Dec 2012 11:42:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.143 X-Spam-Level: X-Spam-Status: No, score=-102.143 tagged_above=-999 required=5 tests=[AWL=0.833, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] 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 Qz+Hn9B8YVmJ for ; Sat, 1 Dec 2012 11:42:35 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id 71AD41F0C6A for ; Sat, 1 Dec 2012 11:42:26 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so1723017oag.31 for ; Sat, 01 Dec 2012 11:42:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:from:date:message-id:subject:to :content-type:x-gm-message-state; bh=Yfzz+HeVfLygMXlWsIAq1ZJebIRu63HOtkv/QlSHbuE=; b=Rdh9ArwMkrs4rW8FyTr9zwvdIP87bVA3ZVqxcgr/UKtF1juswkOjQ4J8t0QlQ/uSGK 7+vZ3oFDB6ZX/Y9HNiPxEYXzNczg8Em9RblJVApYi7Kx4lRFQAxoGZsZsOcNPKwT8+X1 dsC5/PEX1pD5qwoFwdXSgjgOzIgu0ObRcPXZuXnlwsP1mUHjFOpH5WUc1QZuxXzcKQFf SRpRMy5Mr/Ma6c3E+L2JaDn+DdK/UJFDYA2CkhX/rofmLCP5vqoyFrFISmgdZlilbHgC ZhCYakvdwq1ZBOptXhIIG++VpzTj9T6tt7OOCNawzokaP+yLFCxk55EpTO4SI947+ooD hZCg== Received: by 10.182.177.100 with SMTP id cp4mr739330obc.71.1354390945714; Sat, 01 Dec 2012 11:42:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.136.102 with HTTP; Sat, 1 Dec 2012 11:41:45 -0800 (PST) X-Originating-IP: [74.95.2.169] From: Eric Rescorla Date: Sat, 1 Dec 2012 11:41:45 -0800 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary=e89a8f838d9f34d25504cfcfb779 X-Gm-Message-State: ALoCoQmnQN8sErCRMClLbkfwtANTXhQjbBpiA1nmyV4S5ZIbUtUl7QRlKzrQ/xB9EQAQrB7HSwDK Subject: [TLS] Followup on RFC 6091 and oob-pubkeys 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Dec 2012 19:42:36 -0000 --e89a8f838d9f34d25504cfcfb779 Content-Type: text/plain; charset=ISO-8859-1 There has been a bunch of discussion on the mailing list and at the IETF meeting in Paris about whether we should reuse the RFC 6091 structures and code points (extending them for raw public keys) or define new structures and code points to handle raw public keys. To recap the state of affairs: - TLS w/o RFC 6091 provides for X.509 certificates - RFC 6091 provides support for OpenPGP as well as a generic structure to negotiate other certificate types by defining new code points. - The intent of the OOB draft is to provide support for raw public keys. The current draft uses new structures. At the meeting it was discussed whether we could reuse the 6091 code points and the discussion centered around whether 6091 allowed asymmetric certificate usage. I.e., was it possible to have the client use a certificate of type A and the server to use a certificate of type B. (I'm speaking loosely here and including raw keys within certificates for this purpose). So, for instance, the server might have a cert but the client merely a raw key. The minutes (http://www.ietf.org/proceedings/85/minutes/minutes-85-tls) reflect that there was a somewhat confusing consensus that this was needed and so if RFC 6091 precluded that we should define new structures/ code points. I volunteered to research this and report back. After reviewing RFC 6091, I believe that it requires that the client and server use the same credentials (assuming client authentication at all). Here's the relevant passage: 3.5. Client Certificate This message is only sent in response to the certificate request message. The client certificate message is sent using the same formatting as the server certificate message, and it is also required to present a certificate that matches the negotiated certificate type. If OpenPGP certificates have been selected and no certificate is available from the client, then a certificate structure of type "empty_cert" that contains an OpenPGPEmptyCert value MUST be sent. The server SHOULD respond with a "handshake_failure" fatal alert if client authentication is required. Based on the above, I believe that the WG consensus implies that we define new structures with the more general semantics. -Ekr --e89a8f838d9f34d25504cfcfb779 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There has been a bunch of discussion on the mailing list and at the
IET= F meeting in Paris about whether we should reuse the RFC 6091
str= uctures and code points (extending them for raw public keys)
or d= efine new structures and code points to handle raw public keys.

To recap the state of affairs:

- TLS w/o RFC 6091 provides for X.509 certificates
- RFC 6091 pr= ovides support for OpenPGP as well as a generic
=A0 structure to = negotiate other certificate types by defining new code
=A0 points.
- The intent of the OOB draft is to provide supp= ort for raw public keys.

The current draft uses ne= w structures. At the meeting it was discussed
whether we could re= use the 6091 code points and the discussion centered
around whether 6091 allowed asymmetric certificate usage. I.e., was it=
possible to have the client use a certificate of type A and the = server to
use a certificate of type B. (I'm speaking loosely = here and including=A0
raw keys within certificates for this purpose). So, for instance, the<= /div>
server might have a cert but the client merely a raw key. The min= utes
that there was a somewhat confusing consensus that this was needed
and so if RFC 6091 precluded that we should define new structures/
code points. I volunteered to research this and report back.

After reviewing RFC 6091, I believe that it requires th= at the client and
server use the same credentials (assuming clien= t authentication at
all). Here's the relevant passage:

3.5. =A0Client Certificate

=A0 =A0This message is only sent in response to the certificate request
=A0 =A0message. =A0The client certificate message is sent using th= e same
=A0 =A0formatting as the server certificate message, and it is also re= quired
=A0 =A0to present a certificate that matches the negotiate= d certificate
=A0 =A0type. =A0If OpenPGP certificates have been s= elected and no certificate
=A0 =A0is available from the client, then a certificate structure of t= ype
=A0 =A0"empty_cert" that contains an OpenPGPEmptyCe= rt value MUST be sent.
=A0 =A0The server SHOULD respond with a &q= uot;handshake_failure" fatal alert if
=A0 =A0client authentication is required.


Based on the above, I believe that the WG consensus impli= es that we
define new structures with the more general semantics.=

-Ekr

--e89a8f838d9f34d25504cfcfb779-- From n.mavrogiannopoulos@gmail.com Sat Dec 1 23:57:16 2012 Return-Path: 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 ; 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 ; 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 ; Sat, 1 Dec 2012 23:57:14 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id hq7so508455wib.1 for ; 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 Message-ID: <50BB09D3.6010106@gnutls.org> Date: Sun, 02 Dec 2012 08:57:07 +0100 From: Nikos Mavrogiannopoulos 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From n.mavrogiannopoulos@gmail.com Sat Dec 1 23:59:11 2012 Return-Path: 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 375A021F8EEF for ; Sat, 1 Dec 2012 23:59:11 -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 eRruM5tXH7lB for ; Sat, 1 Dec 2012 23:59:10 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6BEFB21F8FD0 for ; Sat, 1 Dec 2012 23:59:10 -0800 (PST) Received: by mail-we0-f172.google.com with SMTP id r3so711555wey.31 for ; Sat, 01 Dec 2012 23:59:09 -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:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=bYPtMuzBLPU07d1fP26E/Pl5U500whhRVU2rrn9XINI=; b=QoO324FK8j2BXENXUnZQq/LoOXnFGLSnUMyIHvIruM8gaJeajVKVMMm1NrGe7P+tV5 GoZl9mPCnXYD+GkxzEAiLYKt3qu9iaS9e5Ub112RxKsiVfafOcp4gLVSG5qJ/tiVmFL9 ipJwE2BJqXxcg5M5SsVFS8L0thoETHFCBuLt3x7CFlmlyHDsFku+ChFowROZVu0Ltw1A sFF211CTpgrLTzsElzZa8QrslUm/aCHAj9XI8ifbqgP8xLkhEdRGwR8avoX1LbJXgql3 1uJp0LFkO9PjwVssIHs6JHIoziJ0oglFo1j3YZvIJCqdxcCi2dWvEHbtyAnjXll/oyvK +CXg== Received: by 10.180.19.73 with SMTP id c9mr4497313wie.8.1354435149524; Sat, 01 Dec 2012 23:59:09 -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 dm3sm5859506wib.9.2012.12.01.23.59.08 (version=SSLv3 cipher=OTHER); Sat, 01 Dec 2012 23:59:08 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <50BB0A4B.8070806@gnutls.org> Date: Sun, 02 Dec 2012 08:59:07 +0100 From: Nikos Mavrogiannopoulos 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 References: In-Reply-To: X-Enigmail-Version: 1.4.1 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Followup on RFC 6091 and oob-pubkeys 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 07:59:11 -0000 On 12/01/2012 08:41 PM, Eric Rescorla wrote: > This message is only sent in response to the certificate request > message. The client certificate message is sent using the same > formatting as the server certificate message, and it is also required > to present a certificate that matches the negotiated certificate > type. If OpenPGP certificates have been selected and no certificate > is available from the client, then a certificate structure of type > "empty_cert" that contains an OpenPGPEmptyCert value MUST be sent. > The server SHOULD respond with a "handshake_failure" fatal alert if > client authentication is required. > Based on the above, I believe that the WG consensus implies that we > define new structures with the more general semantics. Well since the new use-cases justify that I have no objection. What my main point is about, is to keep a single certificate type extension in TLS by defining values to be used for openpgp keys as well, and deprecate both the previous extension and registry. The openpgp type could simply be marked as reserved in this draft. This way there will be no need for two different certificate type extensions for the applications that need to support both openpgp and raw keys. If the issue is exhaustion of certificate types, then it should be increased in size. regards, Nikos From n.mavrogiannopoulos@gmail.com Sun Dec 2 00:28:19 2012 Return-Path: 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 CB5E321F8FB9 for ; Sun, 2 Dec 2012 00:28:19 -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 Je8l4baSSDq1 for ; Sun, 2 Dec 2012 00:28:19 -0800 (PST) Received: from mail-wi0-f180.google.com (mail-wi0-f180.google.com [209.85.212.180]) by ietfa.amsl.com (Postfix) with ESMTP id DA53521F8FB3 for ; Sun, 2 Dec 2012 00:28:18 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id hj13so459736wib.13 for ; Sun, 02 Dec 2012 00:28:18 -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:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=pGEBva28gO+H34rWqsJow7GoulnLMwAn6slcvvN9dyE=; b=f+E+YaKCnETJdMpc6vQLSMisvf5wjFI7qXQnpG3XixM6FOC0/QIFZ+T/2X2vpMhkSJ K1uIHA1XnIzSdGI5tC2OCAEaEB8yid3sQQoLobqqKMR68bnV1cyCqe2xlfKWyAe5NKIS qnzVmUf1ZyXex5gkL2aIjr1aVPwaDkAOZVJEzZHZNBz1QrFudtZ+AnLaPGw4lY8SxePF Esr9GB2st1Lb3bUq5m8zod+/P3OCa0y81kFi37Vft/qb4J3Nzp0mqxz6eCvnuEwScrDU Tg/OJZ5lUzO6gLlWJBN/LY1gTVZWZye99WutW9R48L+GD9LZQIJid1lHDm750YSbv+rN D2aA== Received: by 10.216.200.137 with SMTP id z9mr2284834wen.184.1354436897993; Sun, 02 Dec 2012 00:28:17 -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 dw4sm6852092wib.1.2012.12.02.00.28.16 (version=SSLv3 cipher=OTHER); Sun, 02 Dec 2012 00:28:17 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <50BB111A.2090406@gnutls.org> Date: Sun, 02 Dec 2012 09:28:10 +0100 From: Nikos Mavrogiannopoulos 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 References: In-Reply-To: X-Enigmail-Version: 1.4.1 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] WGLC for draft-ietf-tls-multiple-cert-status-extension-02 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 08:28:19 -0000 On 11/16/2012 06:08 PM, Joseph Salowey (jsalowey) wrote: > This is a working group last call for draft-ietf-tls-multiple-cert-status-extension-02 on "The TLS Multiple Certificate Status Request Extension". The draft is available here: > > http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-extension-02 > Please send you comments to the TLS list by December 17, 2012. I pretty much repeat the point originally made in: http://www.ietf.org/mail-archive/web/tls/current/msg08973.html The text: "Clients requesting an OCSP response and receiving one or more OCSP responses in a "CertificateStatus" message MUST check the OCSP response(s) and abort the handshake, if the response is a revoked status or is otherwise not satisfactory with a bad_certificate_status_response(113) alert. This alert is always fatal." is very strict and IMO not applicable in this document since this document is not about a verification profile. What if a client decides to proceed with the handshake even if the status is revoked? Or if an implementation when it detects junk in this extension (due to a server misconfiguration) decides to ignore it instead of aborting. Should that make the clients non-conformant to the multiple-cert-status-extension? regards, Nikos From hannes.tschofenig@gmx.net Sun Dec 2 04:03:57 2012 Return-Path: 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 EE26A21F8D4A for ; Sun, 2 Dec 2012 04:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 zJQ5c3NWuY3c for ; Sun, 2 Dec 2012 04:03:52 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 9D6E921F8D47 for ; Sun, 2 Dec 2012 04:03:51 -0800 (PST) Received: (qmail invoked by alias); 02 Dec 2012 10:17:09 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.109]) [88.115.216.191] by mail.gmx.net (mp040) with SMTP; 02 Dec 2012 11:17:09 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX187xdp0iHo7gR5v8h1bE++CTcCY/tuFp6mJCInSrF yvzzYHMeh3I+ht Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: Date: Sun, 2 Dec 2012 12:17:06 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <37462EF4-4D59-4490-98C3-396C3FC6B901@gmx.net> References: To: Eric Rescorla X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: tls@ietf.org Subject: Re: [TLS] Followup on RFC 6091 and oob-pubkeys 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 12:03:57 -0000 Hi Erk,=20 thanks for looking at this issue.=20 Your observation confirms my impression and in = http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-06 we define such a = new structure (called certificate_type) with a generic semantic.=20 I don't care too much about the name of the new extension but I believe = it does the job. Can we stick with this design?=20 A question that was raised on the list concerned the support of OpenPGP. = Currently, the draft only defines the raw public key formats and, of = course, allows the ability to add further values to the registry. Is = this enough or should the document also populate the values for OpenPGP? Ciao Hannes On Dec 1, 2012, at 9:41 PM, Eric Rescorla wrote: > There has been a bunch of discussion on the mailing list and at the > IETF meeting in Paris about whether we should reuse the RFC 6091 > structures and code points (extending them for raw public keys) > or define new structures and code points to handle raw public keys. >=20 > To recap the state of affairs: >=20 > - TLS w/o RFC 6091 provides for X.509 certificates > - RFC 6091 provides support for OpenPGP as well as a generic > structure to negotiate other certificate types by defining new code > points. > - The intent of the OOB draft is to provide support for raw public = keys. >=20 > The current draft uses new structures. At the meeting it was discussed > whether we could reuse the 6091 code points and the discussion = centered > around whether 6091 allowed asymmetric certificate usage. I.e., was it > possible to have the client use a certificate of type A and the server = to > use a certificate of type B. (I'm speaking loosely here and including=20= > raw keys within certificates for this purpose). So, for instance, the > server might have a cert but the client merely a raw key. The minutes > (http://www.ietf.org/proceedings/85/minutes/minutes-85-tls) reflect > that there was a somewhat confusing consensus that this was needed > and so if RFC 6091 precluded that we should define new structures/ > code points. I volunteered to research this and report back. >=20 > After reviewing RFC 6091, I believe that it requires that the client = and > server use the same credentials (assuming client authentication at > all). Here's the relevant passage: >=20 > 3.5. Client Certificate >=20 > This message is only sent in response to the certificate request > message. The client certificate message is sent using the same > formatting as the server certificate message, and it is also = required > to present a certificate that matches the negotiated certificate > type. If OpenPGP certificates have been selected and no = certificate > is available from the client, then a certificate structure of type > "empty_cert" that contains an OpenPGPEmptyCert value MUST be sent. > The server SHOULD respond with a "handshake_failure" fatal alert if > client authentication is required. >=20 >=20 > Based on the above, I believe that the WG consensus implies that we > define new structures with the more general semantics. >=20 > -Ekr >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From dkg@fifthhorseman.net Sun Dec 2 08:32:33 2012 Return-Path: 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 B5F5E21F8775 for ; Sun, 2 Dec 2012 08:32:33 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0L2k4jhT3FCO for ; Sun, 2 Dec 2012 08:32:32 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id CD9B521F85A9 for ; Sun, 2 Dec 2012 08:32:24 -0800 (PST) Received: from [192.168.13.75] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 98770F970; Sun, 2 Dec 2012 11:32:21 -0500 (EST) Message-ID: <50BB8295.1030800@fifthhorseman.net> Date: Sun, 02 Dec 2012 11:32:21 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Icedove/17.0 MIME-Version: 1.0 To: Eric Rescorla References: In-Reply-To: X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: tls@ietf.org Subject: Re: [TLS] Followup on RFC 6091 and oob-pubkeys 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 16:32:33 -0000 On 12/01/2012 02:41 PM, Eric Rescorla wrote: > After reviewing RFC 6091, I believe that it requires that the client and > server use the same credentials (assuming client authentication at > all). Here's the relevant passage: > > 3.5. Client Certificate > > This message is only sent in response to the certificate request > message. The client certificate message is sent using the same > formatting as the server certificate message, and it is also required > to present a certificate that matches the negotiated certificate > type. If OpenPGP certificates have been selected and no certificate > is available from the client, then a certificate structure of type > "empty_cert" that contains an OpenPGPEmptyCert value MUST be sent. > The server SHOULD respond with a "handshake_failure" fatal alert if > client authentication is required. > > Based on the above, I believe that the WG consensus implies that we > define new structures with the more general semantics. If these general semantics are desirable (i believe they are, given the discussion), it sounds to me like a new draft would obsolete RFC 6091, since it would provide all the features of 6091 plus the capability to indicate separate cert types for each peer. It doesn't make sense for the IETF to have two registries for certificate types in TLS; I think we should re-use the certificate type registry from RFC 6091 for this proposal. Regards, --dkg From piyush@ditenity.com Sun Dec 2 08:35:30 2012 Return-Path: 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 0E31121F852A for ; Sun, 2 Dec 2012 08:35:30 -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 nJFaiNZVBL5v for ; Sun, 2 Dec 2012 08:35:29 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8B2CC21F851B for ; Sun, 2 Dec 2012 08:35:24 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so3205953ieb.31 for ; Sun, 02 Dec 2012 08:35:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:x-gm-message-state; bh=CCRSbqLxMvYCQ6gSqr4FOPmsfmY7LHdilH3eoO6x/jU=; b=Ykrnm0DVxs6cvGVBtT2NSxRSZ9047RwM7OQn0vLerUsUPE00YPnffsd/49MqmLXMmj 5XyqES8p+xi/yMD9qEnUt4aR9KT3Y6voBdcm9Oa/4Rez17b3xvt6wh+jzoC9LV6tQ6Nj UF7KZSP5raPOqjTR8voUz3MzZBFApeldwABgrfvk8eYlRZDcdkmjnB3385W55DZ0sStm xjruoUaLcux6kKXKzbI2kOkwUvEORQSYqzzV9tOShrsN8FhXgmxUaR6AuLjaa3JIb8as C2aubN0OJFPoeinm451BueibZQvGKpYEYzJ4yAQksbZKndPRp4lXpzcPimrbZmXc4jMX Ag4Q== Received: by 10.50.152.194 with SMTP id va2mr4035747igb.25.1354466124022; Sun, 02 Dec 2012 08:35:24 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id bh3sm4794248igc.0.2012.12.02.08.35.22 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 02 Dec 2012 08:35:23 -0800 (PST) From: "Piyush Jain" To: "'Nikos Mavrogiannopoulos'" , References: <50BB111A.2090406@gnutls.org> In-Reply-To: <50BB111A.2090406@gnutls.org> Date: Sun, 2 Dec 2012 08:35:18 -0800 Message-ID: <022101cdd0ab$049f82c0$0dde8840$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQCkziuYALLp/LHwcTeRJT4qG2qlCALH4HAWmkF0K6A= Content-Language: en-us X-Gm-Message-State: ALoCoQnH9ipM6yVephrIlf8IJvvgPFZ4t2UyjdWHVT3R/+zKTOYTUYmKZOqaovlnsR44UsowhKiC Subject: Re: [TLS] WGLC for draft-ietf-tls-multiple-cert-status-extension-02 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 16:35:30 -0000 The text: > "Clients requesting an OCSP response and receiving one or more OCSP > responses in a "CertificateStatus" message MUST check the OCSP > response(s) and abort the handshake, if the response is a revoked > status or is otherwise not satisfactory with a > bad_certificate_status_response(113) alert. This alert is always > fatal." It's probably okay to abort the handshake for 'revoked' status but not for 'unsatisfactory' response, given that unsatisfactory could mean a lot of things. One simple example is that OCSP response is signed using a hashing/signature example that the client does not understand. If the client is trying to obtain the certificate status directly, it can use RFC 6277 to resolve this or, in the worst case fall back to CRLs to obtain the revocation status. This brings up another interesting question. The request_extensions field of OCSPStatusRequest is marked as opaque in the current proposal. Given that, he proposed extension is useful only if the TLS server caches the status response from OCSP servers, IMO the TLS server should at least try to honor PreferredSignatureAlgorithms request extension defined in 6277. -Piyush From yngve@opera.com Sun Dec 2 09:03:42 2012 Return-Path: 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 8265621F86F8 for ; Sun, 2 Dec 2012 09:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 bzLNamfFTsyV for ; Sun, 2 Dec 2012 09:03:41 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id 4BF3121F8466 for ; Sun, 2 Dec 2012 09:03:41 -0800 (PST) Received: from acorna.oslo.osa (126.176.249.62.customer.cdi.no [62.249.176.126]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id qB2H3Y7f015406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 2 Dec 2012 17:03:35 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: tls@ietf.org, "Nikos Mavrogiannopoulos" References: <50BB111A.2090406@gnutls.org> Date: Sun, 02 Dec 2012 18:03:34 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Message-ID: In-Reply-To: <50BB111A.2090406@gnutls.org> User-Agent: Opera Mail/11.64 (Win32) Subject: Re: [TLS] WGLC for draft-ietf-tls-multiple-cert-status-extension-02 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 17:03:42 -0000 Hi, As I said last time you raised this issue, it is the same requirement as RFC 6066 sets for the original Certificate Status extension. I also think it is proper to have such a requirement, because it defines how the data should be handled and acted upon, and collects the information in a single document, so it is not necessary to chase one document after another to discover all the proper actions. This requirement clearly indicates that *if* a client request this extension, then it MUST verify the result, and act on the result in a secure fashion. That is, only proceed if the response is "good", and abort in other cases. (If a client does not want to process and act on the information, it can avoid doing so by not sending the extension support indication to the server; sending the extension is a declaration that the client accepts and will act upon the returned information in a fashion that protects the user.) The server have the option to not forward a response in case it is bad, in which case the client should fetch the response on its own. If the forwarded response is bad, then the client have to act on it, and terminate the connection. A client that proceeds despite seeing either bad data or a revoked status are IMO not conformant, and will IMO also have a security vulnerability. As this language was not just acceptable to the Working Group for RFC 6066, but the WG actually approved that 6066 added the alert message requirement, which was not present in either RFC 4366 or RFC 3546, my opinion is that the WG have so far clearly and repeatedly stated its opinion on this matter, and I therefore plan to leave this text in. On Sun, 02 Dec 2012 09:28:10 +0100, Nikos Mavrogiannopoulos wrote: > On 11/16/2012 06:08 PM, Joseph Salowey (jsalowey) wrote: > >> This is a working group last call for >> draft-ietf-tls-multiple-cert-status-extension-02 on "The TLS Multiple >> Certificate Status Request Extension". The draft is available here: >> >> http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-extension-02 >> Please send you comments to the TLS list by December 17, 2012. > > I pretty much repeat the point originally made in: > http://www.ietf.org/mail-archive/web/tls/current/msg08973.html > > The text: > "Clients requesting an OCSP response and receiving one or more OCSP > responses in a "CertificateStatus" message MUST check the OCSP > response(s) and abort the handshake, if the response is a revoked > status or is otherwise not satisfactory with a > bad_certificate_status_response(113) alert. This alert is always > fatal." > > is very strict and IMO not applicable in this document since this > document is not about a verification profile. What if a client decides > to proceed with the handshake even if the status is revoked? Or if an > implementation when it detects junk in this extension (due to a server > misconfiguration) decides to ignore it instead of aborting. > > Should that make the clients non-conformant to the > multiple-cert-status-extension? > > regards, > Nikos > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 96 90 41 51 Fax: +47 23 69 24 01 ******************************************************************** From yngve@opera.com Sun Dec 2 09:10:42 2012 Return-Path: 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 77F1121F84D2 for ; Sun, 2 Dec 2012 09:10:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 4j3AGaYZwDAj for ; Sun, 2 Dec 2012 09:10:38 -0800 (PST) Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by ietfa.amsl.com (Postfix) with ESMTP id D786F21F84D1 for ; Sun, 2 Dec 2012 09:10:37 -0800 (PST) Received: from acorna.oslo.osa (126.176.249.62.customer.cdi.no [62.249.176.126]) (authenticated bits=0) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id qB2HAZSE017551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 2 Dec 2012 17:10:36 GMT Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: tls@ietf.org References: <50BB111A.2090406@gnutls.org> Date: Sun, 02 Dec 2012 18:10:35 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen (Developer Opera Software ASA)" Organization: Opera Software AS Message-ID: In-Reply-To: User-Agent: Opera Mail/11.64 (Win32) Subject: Re: [TLS] WGLC for draft-ietf-tls-multiple-cert-status-extension-02 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 17:10:42 -0000 On Sun, 02 Dec 2012 18:03:34 +0100, Yngve N. Pettersen (Developer Opera Software ASA) wrote: > Hi, > > As I said last time you raised this issue, it is the same requirement as > RFC 6066 sets for the Just a slight correction: My draft adds a specific requirement for "revoked", mostly to be on the safe side, along with the adaption to multiple response. Otherwise the text is as in RFC6066. > original Certificate Status extension. I also think it is proper to have > such a requirement, because it defines how the data should be handled > and acted upon, and collects the information in a single document, so it > is not necessary to chase one document after another to discover all the > proper actions. > > This requirement clearly indicates that *if* a client request this > extension, then it MUST verify the result, and act on the result in a > secure fashion. That is, only proceed if the response is "good", and > abort in other cases. (If a client does not want to process and act on > the information, it can avoid doing so by not sending the extension > support indication to the server; sending the extension is a declaration > that the client accepts and will act upon the returned information in a > fashion that protects the user.) > > The server have the option to not forward a response in case it is bad, > in which case the client should fetch the response on its own. If the > forwarded response is bad, then the client have to act on it, and > terminate the connection. > > A client that proceeds despite seeing either bad data or a revoked > status are IMO not conformant, and will IMO also have a security > vulnerability. > > > As this language was not just acceptable to the Working Group for RFC > 6066, but the WG actually approved that 6066 added the alert message > requirement, which was not present in either RFC 4366 or RFC 3546, my > opinion is that the WG have so far clearly and repeatedly stated its > opinion on this matter, and I therefore plan to leave this text in. > > On Sun, 02 Dec 2012 09:28:10 +0100, Nikos Mavrogiannopoulos > wrote: > >> On 11/16/2012 06:08 PM, Joseph Salowey (jsalowey) wrote: >> >>> This is a working group last call for >>> draft-ietf-tls-multiple-cert-status-extension-02 on "The TLS Multiple >>> Certificate Status Request Extension". The draft is available here: >>> >>> http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-extension-02 >>> Please send you comments to the TLS list by December 17, 2012. >> >> I pretty much repeat the point originally made in: >> http://www.ietf.org/mail-archive/web/tls/current/msg08973.html >> >> The text: >> "Clients requesting an OCSP response and receiving one or more OCSP >> responses in a "CertificateStatus" message MUST check the OCSP >> response(s) and abort the handshake, if the response is a revoked >> status or is otherwise not satisfactory with a >> bad_certificate_status_response(113) alert. This alert is always >> fatal." >> >> is very strict and IMO not applicable in this document since this >> document is not about a verification profile. What if a client decides >> to proceed with the handshake even if the status is revoked? Or if an >> implementation when it detects junk in this extension (due to a server >> misconfiguration) decides to ignore it instead of aborting. >> >> Should that make the clients non-conformant to the >> multiple-cert-status-extension? >> >> regards, >> Nikos >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > -- Sincerely, Yngve N. Pettersen ******************************************************************** Senior Developer Email: yngve@opera.com Opera Software ASA http://www.opera.com/ Phone: +47 96 90 41 51 Fax: +47 23 69 24 01 ******************************************************************** From n.mavrogiannopoulos@gmail.com Sun Dec 2 10:34:22 2012 Return-Path: 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 8AC1921F85B3 for ; Sun, 2 Dec 2012 10:34:22 -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 4d7KAMigKsIx for ; Sun, 2 Dec 2012 10:34:22 -0800 (PST) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by ietfa.amsl.com (Postfix) with ESMTP id A9D1421F85D1 for ; Sun, 2 Dec 2012 10:34:21 -0800 (PST) Received: by mail-wg0-f46.google.com with SMTP id dr13so877969wgb.13 for ; Sun, 02 Dec 2012 10:34:20 -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 :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=ZywAuGNq6247gw2ihJ1p2dGWDVvec3d6DSgvNolKjRQ=; b=ZidQrqpVLRf7x1qh9Bmr+XJxXg3/ZScaXbodmYiwf0/JG4cQKPk16NLLY18Wi4N7+m py3gg2xYfMpfpjSWCis/PIGIo8YCFuA/+DjUybIgjcJrwuR7UTXMwXQD1hxN/ad+uNND uWhwdEuaIZqesD0GSbIJBM5sczlnYocVCUm2VoyXu3W4lyIU0uauVQ7irwg8mnSYEYIo wxn9DFA3UzYy6QXzSA2Bn7W02/ZRQeG64g1Ereyy2qblc7wbNjy2dJUAZaWUFYQFPMyx or9IBipXVWEH1SWVdACs8CdtyzXlLyTZVouFmKU8OzKs4i12UDO10WjdrFk7STzzicE/ Ye9w== Received: by 10.180.106.34 with SMTP id gr2mr6059575wib.18.1354473260716; Sun, 02 Dec 2012 10:34:20 -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 gz3sm7919640wib.2.2012.12.02.10.34.18 (version=SSLv3 cipher=OTHER); Sun, 02 Dec 2012 10:34:19 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <50BB9F25.5080401@gnutls.org> Date: Sun, 02 Dec 2012 19:34:13 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.10) Gecko/20121027 Icedove/10.0.10 MIME-Version: 1.0 To: "Yngve N. Pettersen (Developer Opera Software ASA)" References: <50BB111A.2090406@gnutls.org> In-Reply-To: X-Enigmail-Version: 1.4.1 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] WGLC for draft-ietf-tls-multiple-cert-status-extension-02 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 18:34:22 -0000 On 12/02/2012 06:03 PM, Yngve N. Pettersen (Developer Opera Software ASA) wrote: > Hi, > > As I said last time you raised this issue, it is the same requirement as > RFC 6066 sets for the > original Certificate Status extension. I also think it is proper to have > such a requirement, because it defines how the data should be handled > and acted upon, and collects the information in a single document, so it > is not necessary to chase one document after another to discover all the > proper actions. Hello Yngve, It is my opinion that, the capital MUST in the original RFC6066 may have been wrong also. However, in the RFC6066 case the text is very vague. E.g. it says: Clients ... MUST check the OCSP response and abort the handshake if the response is not satisfactory, ... So the satisfactory could mean anything depending of the context. In your draft you clarify that, by mentioning that the client is obliged to terminate the connection if the certificate is revoked. The clarification is good as a suggestion to the implementer, but it has the side-effect (due to the original MUST) that a client will not to be conformant with draft-ietf-tls-multiple-cert-status-extension-02 if it decides to go on despite the revoked status. The TLS rfcs mandate no verification policies and even when they discuss verification is informally (see F.1.1 in TLS 1.2) and there are no MUSTs or SHOULDs. Also in 7.4.6 the text explicitly mentions that a server that receives an unacceptable certificate by the client acts at its discretion. I think this should be followed in this draft as well. So while I think you addition is good, and could even be better to elaborate further, e.g. by specifying what to do when the status request is unsatisfactory[*], I don't think it should be a MUST (nor any other RFC2119 keywords). It could be just "must". [*]. As you explain in the open issue note. regards, Nikos From piyush@ditenity.com Sun Dec 2 10:39:54 2012 Return-Path: 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 E22E021F85BC for ; Sun, 2 Dec 2012 10:39:54 -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 RxmJQtdfRx6E for ; Sun, 2 Dec 2012 10:39:54 -0800 (PST) Received: from mail-ia0-f172.google.com (mail-ia0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id D5CC121F86FD for ; Sun, 2 Dec 2012 10:39:53 -0800 (PST) Received: by mail-ia0-f172.google.com with SMTP id z13so1770347iaz.31 for ; Sun, 02 Dec 2012 10:39:53 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language:x-gm-message-state; bh=onUsAky085cmj6fy6Bg6QshimkQLTCKcfuEcgcMQf7E=; b=WZNaSFl3YffKf30CsEnaMne4a6nbkezcAI1dHvtlKSqx/YjrDPJu6xAyuj2aRRbHgT CFLRuzCaI/P8E3U2XFPYBrUxjvJUgd4ofaNf5cjB3yQvCAsSeLUwQEZ0lcDCR2e73jC2 eXoJ505bNp4ABFAqNu+b84E6bwvysPpKcJ9SgtF2hWXG/pxMa/qyH8m1xycohSN4kU7/ hw0+H/0ypsyOLRACcu7LR+sTdWKo+rsZVUiuj1Tnlw7V0zwCn2JI7NcmG1aizB5akGyr 34qm2wk+K7nw6sBP4bGyGttGxto3jFGMrM+Cm/AEtyVhGEgxFlxAfNkVg83QTMrxYCYh nbfA== Received: by 10.50.34.201 with SMTP id b9mr4220625igj.55.1354473593435; Sun, 02 Dec 2012 10:39:53 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id hg2sm5023186igc.3.2012.12.02.10.39.52 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 02 Dec 2012 10:39:52 -0800 (PST) From: "Piyush Jain" To: "'Yngve N. Pettersen \(Developer Opera Software ASA\)'" , , "'Nikos Mavrogiannopoulos'" References: <50BB111A.2090406@gnutls.org> In-Reply-To: Date: Sun, 2 Dec 2012 10:39:47 -0800 Message-ID: <027a01cdd0bc$68d7bad0$3a873070$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 thread-index: AQCkziuYALLp/LHwcTeRJT4qG2qlCALH4HAWARdkKc2aONl5QA== Content-Language: en-us X-Gm-Message-State: ALoCoQl821JILuh26Ue3mFoK5dQTR9wPvwCFQ/oqH1tx34dtoL/ZbF2r4xzZHTpNS2n10P39H1qC Subject: Re: [TLS] WGLC for draft-ietf-tls-multiple-cert-status-extension-02 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Dec 2012 18:39:55 -0000 Please see inline. > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > Yngve N. Pettersen (Developer Opera Software ASA) > Sent: Sunday, December 02, 2012 9:04 AM > To: tls@ietf.org; Nikos Mavrogiannopoulos > Subject: Re: [TLS] WGLC for draft-ietf-tls-multiple-cert-status-extension-02 > > Hi, > > As I said last time you raised this issue, it is the same requirement as RFC 6066 > sets for the original > Certificate Status extension. I also think it is proper to have such a > requirement, because it defines how the data should be handled and acted > upon, and collects the information in a single document, so it is not necessary > to chase one document after another to discover all the proper actions. [Piyush] 6066 does not cover multiple cert status extension. Multiple-cert-status extension is being proposed to address the limitations of original certificate status request actions. So any improvements in how the response should be handled can be part of the new documents > > This requirement clearly indicates that *if* a client request this extension, > then it MUST verify the result, and act on the result in a secure fashion. That > is, only proceed if the response is "good", and abort in other cases. (If a client > does not want to process and act on the information, it can avoid doing so by > not sending the extension support indication to the server; sending the > extension is a declaration that the client accepts and will act upon the > returned information in a fashion that protects the user.) > [Piyush] I agree that if the response indicates that certificate is bad, the handshake should be terminated. However, absence of 'good' does not imply 'bad' in OCSP. Good and revoked are the only authoritative responses in OCSP. Any other response is non-authoritative. This implies that for responses other than good or revoked, client should try to find the status using other means before considering the certificate good or bad. Here are the other possible scenarios. - Unknown response. Not interesting because TLs servers should be smart enough to not include unknown response. However, I'm surprised that this draft does not explicitly states that tls server must not include unknown OCSP response (or unsigned OCSP responses) in status-request message. - Response not understood by client, typically because it is signed using a hashing/signing algorithm that client did not understand. It does not make sense for the client to abort the handshake in such cases. The client should try to obtain the certificate status using other means. > The server have the option to not forward a response in case it is bad, in > which case the client should fetch the response on its own. If the forwarded > response is bad, then the client have to act on it, and terminate the > connection. > [Piyush] Good point. I think the draft should call it out explicitly and prohibit the server to send any response that it thinks is not authoritative. > A client that proceeds despite seeing either bad data or a revoked status are > IMO not conformant, and will IMO also have a security vulnerability. > [Piyush] Agree if the status is revoked. Bad data is too generic. Please look at the scenario mentioned above. > > As this language was not just acceptable to the Working Group for RFC 6066, > but the WG actually approved that 6066 added the alert message > requirement, which was not present in either RFC 4366 or RFC 3546, my > opinion is that the WG have so far clearly and repeatedly stated its opinion > on this matter, and I therefore plan to leave this text in. > > On Sun, 02 Dec 2012 09:28:10 +0100, Nikos Mavrogiannopoulos > wrote: > > > On 11/16/2012 06:08 PM, Joseph Salowey (jsalowey) wrote: > > > >> This is a working group last call for > >> draft-ietf-tls-multiple-cert-status-extension-02 on "The TLS Multiple > >> Certificate Status Request Extension". The draft is available here: > >> > >> http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-extens > >> ion-02 Please send you comments to the TLS list by December 17, > >> 2012. > > > > I pretty much repeat the point originally made in: > > http://www.ietf.org/mail-archive/web/tls/current/msg08973.html > > > > The text: > > "Clients requesting an OCSP response and receiving one or more OCSP > > responses in a "CertificateStatus" message MUST check the OCSP > > response(s) and abort the handshake, if the response is a revoked > > status or is otherwise not satisfactory with a > > bad_certificate_status_response(113) alert. This alert is always > > fatal." > > > > is very strict and IMO not applicable in this document since this > > document is not about a verification profile. What if a client decides > > to proceed with the handshake even if the status is revoked? Or if an > > implementation when it detects junk in this extension (due to a server > > misconfiguration) decides to ignore it instead of aborting. > > > > Should that make the clients non-conformant to the > > multiple-cert-status-extension? > > > > regards, > > Nikos > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > -- > Sincerely, > Yngve N. Pettersen > ********************************************************** > ********** > Senior Developer Email: yngve@opera.com > Opera Software ASA http://www.opera.com/ > Phone: +47 96 90 41 51 Fax: +47 23 69 24 01 > ********************************************************** > ********** > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From fweimer@redhat.com Mon Dec 3 01:53:08 2012 Return-Path: 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 7A6AA21F88CD for ; Mon, 3 Dec 2012 01:53:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.598 X-Spam-Level: X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 Va1hCmq+bqMX for ; Mon, 3 Dec 2012 01:52:54 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by ietfa.amsl.com (Postfix) with ESMTP id 5F8FD21F85D1 for ; Mon, 3 Dec 2012 01:52:54 -0800 (PST) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qB39qqnV004040 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 3 Dec 2012 04:52:52 -0500 Received: from fweimer.str.redhat.com (oldenburg.str.redhat.com [10.33.200.60]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qB39qoQX015469 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 3 Dec 2012 04:52:51 -0500 Message-ID: <50BC7672.2050200@redhat.com> Date: Mon, 03 Dec 2012 10:52:50 +0100 From: Florian Weimer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Geoffrey Keating References: <20121128153650.7A2971A3BD@ld9781.wdf.sap.corp> <50B6333C.50606@cs.tcd.ie> <50B72900.5050400@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Cc: tls@ietf.org Subject: Re: [TLS] Impact of draft-ietf-mptcp-api on TLS 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Dec 2012 09:53:08 -0000 On 12/01/2012 12:05 AM, Geoffrey Keating wrote: > Florian Weimer writes: > >> On 11/28/2012 08:52 PM, Geoffrey Keating wrote: >> >>> Maybe a related example will help: suppose the user is trying to >>> connect to https://198.51.100.3. There is an HTTP proxy configured, >>> so what the browser actually does is make a TCP connection to >>> 192.0.2.99, send 'CONNECT https://198.51.100.3', and then start the >>> SSL negotiation. The certificate still has to mention 198.51.100.3, >>> and doesn't have to mention 192.0.2.99. >>> >>> So, in MPTCP, if the user asks for mphttps://198.51.100.3 (or >>> whatever), then 198.51.100.3 is the address that has to appear in the >>> certificate, even if the connection is redirected to some other >>> endpoint, even if the redirection happens before any data is actually >>> sent on the connection. >> >> I suspect the confusion arises because if the interaction with >> 198.51.100.3 causes another connection with a different IP address to >> be created, it hast to be verified against the IP address 198.51.100.3 >> as well. > > Do you mean what MPTCP calls a "subflow", not "connection", here? I do. > If you do mean 'subflow', the key thing about that is that there is no > 'verification' to do. The certificate won't be sent again, there > won't be a new TLS negotiation. Ah, so MPTCP only provides a single byte stream? Then there shouldn't be any TLS interpretation issues. -- Florian Weimer / Red Hat Product Security Team From stefan@aaa-sec.com Wed Dec 5 00:59:52 2012 Return-Path: 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 1853121F8BA6 for ; Wed, 5 Dec 2012 00:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.249 X-Spam-Level: X-Spam-Status: No, score=-102.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, USER_IN_WHITELIST=-100] 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 h1SwhzkK5imU for ; Wed, 5 Dec 2012 00:59:51 -0800 (PST) Received: from s87.loopia.se (s87.loopia.se [194.9.95.113]) by ietfa.amsl.com (Postfix) with ESMTP id 2D5D321F87FF for ; Wed, 5 Dec 2012 00:59:50 -0800 (PST) Received: from s87.loopia.se (localhost [127.0.0.1]) by s87.loopia.se (Postfix) with ESMTP id F10501D0B278 for ; Wed, 5 Dec 2012 09:59:47 +0100 (CET) X-Virus-Scanned: amavisd-new at outgoing-smtp.loopia.se Received: from s87.loopia.se ([127.0.0.1]) by s87.loopia.se (s87.loopia.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id XrcbDCcJC16N for ; Wed, 5 Dec 2012 09:59:47 +0100 (CET) Received: from s326.loopia.se (s34.loopia.se [194.9.94.70]) by s87.loopia.se (Postfix) with ESMTP id 310701D0B0E6 for ; Wed, 5 Dec 2012 09:59:47 +0100 (CET) Received: (qmail 88560 invoked from network); 5 Dec 2012 08:59:45 -0000 Received: from gw.aaa-sec.ideon.se (HELO [192.168.1.2]) (stefan@fiddler.nu@[85.235.7.89]) (envelope-sender ) by s326.loopia.se (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 5 Dec 2012 08:59:45 -0000 User-Agent: Microsoft-MacOutlook/14.2.5.121010 Date: Wed, 05 Dec 2012 09:59:37 +0100 From: Stefan Santesson To: "Joseph Salowey (jsalowey)" Message-ID: Thread-Topic: [TLS] Comments on the cached-info draft In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "" Subject: Re: [TLS] Comments on the cached-info draft 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 08:59:52 -0000 Hi Joe, I can't see the functionality being limited in any important way. In fact, as mentioned below, I see that it actually opens up new opportunities if you don't have to force the cached hash into existing handshake messages. Regarding caching of partial chain: If the group feels that it would be compliant with section 7.4.2 of TLS 1.2, I guess that you could allow the server to send just the end certificate if the client in a new CahcedInformationType has sent over a matching hash of the chain (excluding the server cert) that the this server usually sends together with the server certificate. This is actually much easier to accommodate if we go for the cleaner solution to just omit cached data in hs messages. This would have been semantically horrific if we would mix the server certificate with a hash of the cached chain in the same opaque blob. /Stefan On 11/28/12 6:19 AM, "Joseph Salowey (jsalowey)" wrote: >Hi Stefan, > >This new proposal of omitting the data sounds a bit simpler to me. You >say the new approach will limit the functionality in some way. In what >way is it limited? > >Do you think we could accommodate the case where the endpoint has >intermediate CA certificates cached but not the end entity certificate? >This would require parsing the certificate message, but the response >could just omit the certs that were indicated in the cachedInfo. The >parsing of the cert message is a bit more complex, but it could satisfy >some of the use cases discussed at the meeting. > >Thanks, > >Joe > > > >On Nov 7, 2012, at 7:42 AM, Stefan Santesson wrote: > >> It was quite a while since I wrote the first version of this draft. >> Now that I bring it up to my attention I found a problem that I think >> should be fixed. >> >> After a close examination I'm convinced that the current spec breaks >>TLS. >> >> >> The current approach is to exchange support for cached-info in client >>and >> server hellos. >> This includes hashes for cached objects (clients) and confirmation of >> cached objects (server). >> >> In addition to this, this protocol allows the cached data in handshake >> messages to be swapped with cached object hashes. >> This is a violation of the syntax of these handshake messages. >> >> Take the Certificate handshake message for example. The spec suggest >>here >> to replace the certificate_list vector to be replaced with a vector of >> CachedObejct structured data. >> This breaks the syntax of this handshake message. A strict processing of >> the certificate_list vector will expect an ASN.1 encoded binary >>containing >> a sequence of certificates, not a vector of data objects according to >>the >> CachedObject structure. >> >> My first thought was that we actually need a new handshake message. >> However that is not helpful either. >> The TLS spec require the Certificate handshake message to be sent in >>case >> the chosen cipher suite demands it, so it MUST be sent. >> It can't be replaced by another handshake message. >> >> My current belief is that we simply should omit the cached data, and >>that >> each cachedInfo type need to defined how to omit cached data. >> >> In case of the certificate handshake message, the certificate list >>should >> be replaced with an empty sequence. >> >> >> There is actually no need to send the hash of the cached data in the >> handshake message. Not if the confirmation of the cached info is >>exchanged >> in the server hello. Sending the hash once more in the handshake message >> is then redundant. >> >> >> So I propose the following: >> >> 1) Clients send hashes of cached objects in client hello. >> 2) Server responds with one or zero hashes per cachedInfo type, that a) >> matches a cached object sent by the client b) will be omitted by the >> server in the corresponding handshake message. >> 3) How information is omitted from the handshake message is defined per >> cached info type. For the current defined 2 types this is: >> A) cached certificate cahins in Certificate: replace the sequence of >> certificates with an empty sequence. >> B) certificate_authorities in Certificate Request: Send an empty list >>of >> DistinguishedName >> 4) Clients will act as if the cached objects (confirmed in server hello) >> were sent in the handshake messages. >> 5) Everything else according to the current spec >> >> >> The proposed approach will somewhat limit the functionality of the >>current >> spec, but it ads value in simplicity. >> I can't imagine a valid use case that would not be covered by this >>change, >> but I might overlook something. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > From piyush@ditenity.com Wed Dec 5 12:54:40 2012 Return-Path: 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 CAA9021F8CA0 for ; Wed, 5 Dec 2012 12:54:40 -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 JtP+v400bUUE for ; Wed, 5 Dec 2012 12:54:39 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCB221F8C6E for ; Wed, 5 Dec 2012 12:54:39 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so9663513ieb.31 for ; Wed, 05 Dec 2012 12:54:39 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=VuADUs+zAdhCQ4jNRHsTHb2wJqmVlxLOsa/HCSWymxE=; b=A9MmibnWWFGPJcD8/t1qLXbYVdv/gzg5/2leExzrGwDP7vsFCYwR0L4v0F59ftQj2f mgoVu6wKW/rPfuo30cMFH1DbTpd4pMCFO15JXd3I1c8tz9HhDj3Mgj9C+ih3W5Lh0aMd 8x6372GGxCrFeBWSyHY8DP+yvMDPdPg3z/MC6U5Lak+17v0M3Fvp2YXPDV3T8JFdvgAk ElpZBzF6Y/iTMZ1RfY3BlW6VdfPXOShqHe8GA4PPTTjNaoHxsQERF6IKtaNZ4lBab5xL afIOqQ8YjxYG9nb9OBSvgVT9JzbZ714IgM1pxvBqREjBKXvh9XAgWFQkSSnxY3UX9FoX DRDQ== Received: by 10.50.152.198 with SMTP id va6mr3522364igb.42.1354740878966; Wed, 05 Dec 2012 12:54:38 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id l8sm5138723igo.13.2012.12.05.12.54.37 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 05 Dec 2012 12:54:38 -0800 (PST) From: "Piyush Jain" To: "'Stefan Santesson'" , "'Joseph Salowey \(jsalowey\)'" References: In-Reply-To: Date: Wed, 5 Dec 2012 12:54:35 -0800 Message-ID: <006b01cdd32a$bd08f360$371ada20$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF3e5H6J5oRPTPnQxNox+nxboXkGpi3RefQ Content-Language: en-us X-Gm-Message-State: ALoCoQke7vPXET3mEFeZJWWfd3+2B3b2deufuPU1eeKAjP0E6EIc+++4MiFbl5lO9JBVrO9sj7G+ Cc: tls@ietf.org Subject: Re: [TLS] Comments on the cached-info draft 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Dec 2012 20:54:41 -0000 Stefan, I agree that the current text violates TLS 1.2 by changing the message specification in the handshake protocol. Your proposal addresses those violations and simplifies the cached-info exchange. But it also adds ambiguity to certain use cases allowed by cached-info draft. The current text does not limit the number of certificate chain (or trusted_cas) hashes that the client can include as part of client hello. In some cases the client can include more than one certificate chain (or trusted_cas) hashes. Examples are scenarios where the client communicates with same server with different SNIs and scenarios where client connects to the server using different cipher-suite preference or different signing/hash algorithm preference. One way to fix this would be to provide guidance on how the client and servers can determine which cached objects should be included in hello messages. I guess it will require preprocessing of SNI and signature algorithms extensions and also that of cipher-spec message at both the client and the server. Clients would only include the cached objects that comply with the above (for bandwidth optimization) and servers MUST only include those that comply the SNI, algorithms and cipher-suite. Also the servers MUST not include more than one cached object of the same type. Thoughts? -Piyush > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > Stefan Santesson > Sent: Wednesday, December 05, 2012 1:00 AM > To: Joseph Salowey (jsalowey) > Cc: > Subject: Re: [TLS] Comments on the cached-info draft > > Hi Joe, > > I can't see the functionality being limited in any important way. > In fact, as mentioned below, I see that it actually opens up new opportunities > if you don't have to force the cached hash into existing handshake messages. > > > Regarding caching of partial chain: > If the group feels that it would be compliant with section 7.4.2 of TLS 1.2, I > guess that you could allow the server to send just the end certificate if the > client in a new CahcedInformationType has sent over a matching hash of the > chain (excluding the server cert) that the this server usually sends together > with the server certificate. > > This is actually much easier to accommodate if we go for the cleaner solution > to just omit cached data in hs messages. This would have been semantically > horrific if we would mix the server certificate with a hash of the cached chain > in the same opaque blob. > > /Stefan > > > On 11/28/12 6:19 AM, "Joseph Salowey (jsalowey)" > wrote: > > >Hi Stefan, > > > >This new proposal of omitting the data sounds a bit simpler to me. You > >say the new approach will limit the functionality in some way. In what > >way is it limited? > > > >Do you think we could accommodate the case where the endpoint has > >intermediate CA certificates cached but not the end entity certificate? > >This would require parsing the certificate message, but the response > >could just omit the certs that were indicated in the cachedInfo. The > >parsing of the cert message is a bit more complex, but it could satisfy > >some of the use cases discussed at the meeting. > > > >Thanks, > > > >Joe > > > > > > > >On Nov 7, 2012, at 7:42 AM, Stefan Santesson wrote: > > > >> It was quite a while since I wrote the first version of this draft. > >> Now that I bring it up to my attention I found a problem that I think > >> should be fixed. > >> > >> After a close examination I'm convinced that the current spec breaks > >>TLS. > >> > >> > >> The current approach is to exchange support for cached-info in client > >>and server hellos. > >> This includes hashes for cached objects (clients) and confirmation of > >>cached objects (server). > >> > >> In addition to this, this protocol allows the cached data in > >> handshake messages to be swapped with cached object hashes. > >> This is a violation of the syntax of these handshake messages. > >> > >> Take the Certificate handshake message for example. The spec suggest > >>here to replace the certificate_list vector to be replaced with a > >>vector of CachedObejct structured data. > >> This breaks the syntax of this handshake message. A strict processing > >>of the certificate_list vector will expect an ASN.1 encoded binary > >>containing a sequence of certificates, not a vector of data objects > >>according to the CachedObject structure. > >> > >> My first thought was that we actually need a new handshake message. > >> However that is not helpful either. > >> The TLS spec require the Certificate handshake message to be sent in > >>case the chosen cipher suite demands it, so it MUST be sent. > >> It can't be replaced by another handshake message. > >> > >> My current belief is that we simply should omit the cached data, and > >>that each cachedInfo type need to defined how to omit cached data. > >> > >> In case of the certificate handshake message, the certificate list > >>should be replaced with an empty sequence. > >> > >> > >> There is actually no need to send the hash of the cached data in the > >>handshake message. Not if the confirmation of the cached info is > >>exchanged in the server hello. Sending the hash once more in the > >>handshake message is then redundant. > >> > >> > >> So I propose the following: > >> > >> 1) Clients send hashes of cached objects in client hello. > >> 2) Server responds with one or zero hashes per cachedInfo type, that > >>a) matches a cached object sent by the client b) will be omitted by > >>the server in the corresponding handshake message. > >> 3) How information is omitted from the handshake message is defined > >>per cached info type. For the current defined 2 types this is: > >> A) cached certificate cahins in Certificate: replace the sequence of > >>certificates with an empty sequence. > >> B) certificate_authorities in Certificate Request: Send an empty > >>list of DistinguishedName > >> 4) Clients will act as if the cached objects (confirmed in server > >>hello) were sent in the handshake messages. > >> 5) Everything else according to the current spec > >> > >> > >> The proposed approach will somewhat limit the functionality of the > >>current spec, but it ads value in simplicity. > >> I can't imagine a valid use case that would not be covered by this > >>change, but I might overlook something. > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> _______________________________________________ > >> TLS mailing list > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From mrex@sap.com Thu Dec 6 23:15:36 2012 Return-Path: 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 E91EF21F8A72 for ; Thu, 6 Dec 2012 23:15:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 tPYiHmvCfi-c for ; Thu, 6 Dec 2012 23:15:36 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 25CD121F88DA for ; Thu, 6 Dec 2012 23:15:35 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id qB77FTvQ010119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Dec 2012 08:15:31 +0100 (MET) In-Reply-To: To: Stefan Santesson Date: Fri, 7 Dec 2012 08:15:29 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121207071529.BA1901A3E5@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "" Subject: Re: [TLS] Comments on the cached-info draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Dec 2012 07:15:37 -0000 Stefan Santesson wrote: > Hi Joe, > > I can't see the functionality being limited in any important way. > In fact, as mentioned below, I see that it actually opens up new > opportunities if you don't have to force the cached hash into existing > handshake messages. > > > Regarding caching of partial chain: > If the group feels that it would be compliant with section 7.4.2 of TLS > 1.2, I guess that you could allow the server to send just the end > certificate if the client in a new CahcedInformationType has sent over a > matching hash of the chain (excluding the server cert) that the this > server usually sends together with the server certificate. > > This is actually much easier to accommodate if we go for the cleaner > solution to just omit cached data in hs messages. This would have been > semantically horrific if we would mix the server certificate with a hash > of the cached chain in the same opaque blob. Distinguishing a certificate from a hash should be extremely trivial. The hash will have a fixed length (as defined by the protocol or negotiated (were where we here?), and even the longest hash value will be significantly shorter than the shortest valid X.509 certificate. There would not have been any reason to use the caching extension if the object that is to be omitted from the handshake was not substantially larger than the hash value over that data. -Martin From jsalowey@cisco.com Sat Dec 15 16:35:17 2012 Return-Path: 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 5A51E21F853F for ; Sat, 15 Dec 2012 16:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 1dISNRQnLpjc for ; Sat, 15 Dec 2012 16:35:16 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB1021F852D for ; Sat, 15 Dec 2012 16:35:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8540; q=dns/txt; s=iport; t=1355618116; x=1356827716; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=d+j+HNNUcIS7PwWLmujHbQoHVjqyuZ2iLoW3FJhWwtE=; b=UwNILCkBWsnt4OdnQbIwr+4H6y3IsA18ytz78+VhgSsCZVC0+v1LWxIz Te7wVMy0Z54ccUhMstMdz2FQnbH3vTQasetrREMr9X2NbZcW1E7j8b+8y mx8tcnd0FwZgqGReSMcnopdqGFZS+Flpusor1qHGDVheZ24dYwnNahTjf Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAOQWzVCtJV2c/2dsb2JhbABFvlIWc4IeAQEBAwEBAQEaHTQFBgUHAgICAQgHCgQBAQEKDgYJBxsMCxQJCAIEDgUIAYgEBgy7HwSMWQsQgQGCRmEDlyaPLIJzgWQCBQIXAgQY X-IronPort-AV: E=Sophos;i="4.84,291,1355097600"; d="scan'208";a="153378930" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 16 Dec 2012 00:35:15 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id qBG0ZFnZ017829 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 16 Dec 2012 00:35:15 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.13]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Sat, 15 Dec 2012 18:35:15 -0600 From: "Joseph Salowey (jsalowey)" To: Piyush Jain Thread-Topic: [TLS] WGLC for draft-ietf-tls-multiple-cert-status-extension-02 Thread-Index: AQHNxBz4XTZ6AP0xt0yDR62IxYeJopgFqkcAgACQAQCAABrhgIAU0ZoA Date: Sun, 16 Dec 2012 00:35:14 +0000 Message-ID: References: <50BB111A.2090406@gnutls.org> <027a01cdd0bc$68d7bad0$3a873070$@ditenity.com> In-Reply-To: <027a01cdd0bc$68d7bad0$3a873070$@ditenity.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.61] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Yngve N. Pettersen \(Developer Opera Software ASA\)" , "" Subject: Re: [TLS] WGLC for draft-ietf-tls-multiple-cert-status-extension-02 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 00:35:17 -0000 I don't see a valid case for the client to continue if the response is vali= d and indicates revoked. Since unknown is a valid OCSP response I don't t= hink we should forbid it. In cases where the response is inconclusive it i= s up to the client to determine how to proceed. The client may choose to = allow the connection to complete in the case that it believes it will have = the opportunity to check the validity of the certificate through another me= ans. Such an example would be in the case of EAP-TLS where the client may = use a different method of revocation check when it has network access. How= ever the client MUST NOT engage in activities with the server that require = trust in the validity of the certificate until the certificate has been val= idated. For example, a client MUST not disclose username and password info= rmation until it has fully validated the validity of the server certificate= . =20 Here is an attempt at some suggested text:=20 "Clients requesting an OCSP response and receiving one or more OCSP responses in a "CertificateStatus" message MUST check the OCSP response(s) and abort the handshake if the response is a revoked status with a bad_certificate_status_response(113) alert. This alert is = always fatal. If the response is inconclusive then the client MAY decide to all= ow the=20 connection if it believes it will have the opportunity to check the valid= ity of the certificate through another means. The client MUST about the=20 connection if it needs to engage in activities that require trust in the= server=20 and the server certificate has not been sufficiently validated. An=20 example of where the client may wish to continue is with EAP-TLS where the client can use another mechanism to check the status of a=20 certificate once it obtains network access. In this case the client may= =20 continue withe handshake, but it would be inappropriate for the client=20 to disclose a username and password until=20 it has fully validated the validity of the server certificate." Thanks, Joe On Dec 2, 2012, at 10:39 AM, Piyush Jain wrote: > Please see inline. >=20 >> -----Original Message----- >> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of >> Yngve N. Pettersen (Developer Opera Software ASA) >> Sent: Sunday, December 02, 2012 9:04 AM >> To: tls@ietf.org; Nikos Mavrogiannopoulos >> Subject: Re: [TLS] WGLC for > draft-ietf-tls-multiple-cert-status-extension-02 >>=20 >> Hi, >>=20 >> As I said last time you raised this issue, it is the same requirement as > RFC 6066 >> sets for the original >> Certificate Status extension. I also think it is proper to have such a >> requirement, because it defines how the data should be handled and acted >> upon, and collects the information in a single document, so it is not > necessary >> to chase one document after another to discover all the proper actions. >=20 >=20 > [Piyush] 6066 does not cover multiple cert status extension. > Multiple-cert-status extension is being proposed to address the limitatio= ns > of original certificate status request actions. So any improvements in = how > the response should be handled can be part of the new documents >>=20 >> This requirement clearly indicates that *if* a client request this > extension, >> then it MUST verify the result, and act on the result in a secure fashio= n. > That >> is, only proceed if the response is "good", and abort in other cases. (I= f > a client >> does not want to process and act on the information, it can avoid doing = so > by >> not sending the extension support indication to the server; sending the >> extension is a declaration that the client accepts and will act upon the >> returned information in a fashion that protects the user.) >>=20 > [Piyush] I agree that if the response indicates that certificate is bad, = the > handshake should be terminated. However, absence of 'good' does not imply > 'bad' in OCSP. Good and revoked are the only authoritative responses in > OCSP. Any other response is non-authoritative. This implies that for > responses other than good or revoked, client should try to find the statu= s > using other means before considering the certificate good or bad. Here ar= e > the other possible scenarios. > - Unknown response. Not interesting because TLs servers should be smart > enough to not include unknown response. However, I'm surprised that this > draft does not explicitly states that tls server must not include unknown > OCSP response (or unsigned OCSP responses) in status-request message. > - Response not understood by client, typically because it is signed using= a > hashing/signing algorithm that client did not understand. It does not mak= e > sense for the client to abort the handshake in such cases. The client sho= uld > try to obtain the certificate status using other means. >=20 >> The server have the option to not forward a response in case it is bad, = in >> which case the client should fetch the response on its own. If the > forwarded >> response is bad, then the client have to act on it, and terminate the >> connection. >>=20 > [Piyush] Good point. I think the draft should call it out explicitly and > prohibit the server to send any response that it thinks is not > authoritative. >> A client that proceeds despite seeing either bad data or a revoked statu= s > are >> IMO not conformant, and will IMO also have a security vulnerability. >>=20 > [Piyush] Agree if the status is revoked. Bad data is too generic. Please > look at the scenario mentioned above. >>=20 >> As this language was not just acceptable to the Working Group for RFC > 6066, >> but the WG actually approved that 6066 added the alert message >> requirement, which was not present in either RFC 4366 or RFC 3546, my >> opinion is that the WG have so far clearly and repeatedly stated its > opinion >> on this matter, and I therefore plan to leave this text in. >>=20 >=20 >> On Sun, 02 Dec 2012 09:28:10 +0100, Nikos Mavrogiannopoulos >> wrote: >>=20 >>> On 11/16/2012 06:08 PM, Joseph Salowey (jsalowey) wrote: >>>=20 >>>> This is a working group last call for >>>> draft-ietf-tls-multiple-cert-status-extension-02 on "The TLS Multiple >>>> Certificate Status Request Extension". The draft is available here: >>>>=20 >>>> http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-extens >>>> ion-02 Please send you comments to the TLS list by December 17, >>>> 2012. >>>=20 >>> I pretty much repeat the point originally made in: >>> http://www.ietf.org/mail-archive/web/tls/current/msg08973.html >>>=20 >>> The text: >>> "Clients requesting an OCSP response and receiving one or more OCSP >>> responses in a "CertificateStatus" message MUST check the OCSP >>> response(s) and abort the handshake, if the response is a revoked >>> status or is otherwise not satisfactory with a >>> bad_certificate_status_response(113) alert. This alert is always >>> fatal." >>>=20 >>> is very strict and IMO not applicable in this document since this >>> document is not about a verification profile. What if a client decides >>> to proceed with the handshake even if the status is revoked? Or if an >>> implementation when it detects junk in this extension (due to a server >>> misconfiguration) decides to ignore it instead of aborting. >>>=20 >>> Should that make the clients non-conformant to the >>> multiple-cert-status-extension? >>>=20 >>> regards, >>> Nikos >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>=20 >>=20 >> -- >> Sincerely, >> Yngve N. Pettersen >> ********************************************************** >> ********** >> Senior Developer Email: yngve@opera.com >> Opera Software ASA http://www.opera.com/ >> Phone: +47 96 90 41 51 Fax: +47 23 69 24 01 >> ********************************************************** >> ********** >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From jsalowey@cisco.com Sat Dec 15 17:00:44 2012 Return-Path: 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 5E66D21F850E for ; Sat, 15 Dec 2012 17:00:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 BMCZGax4WkWt for ; Sat, 15 Dec 2012 17:00:43 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 4017121F8490 for ; Sat, 15 Dec 2012 17:00:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8178; q=dns/txt; s=iport; t=1355619643; x=1356829243; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=+oPXrsRtlYnz4LEOr4fYSyQxJKNbicwXK9jziY4CYEg=; b=O7rhfHuyVB4nvPmOQpuy5kqqA0uEA9oWKyUunWMF7CyDclGmMpph6U5x c+OOCpvT81Gz0qstHA4lSDSp/mxahZQcG0qfHYIzIQw09kPYtIsr+lf7w z/cKcINRUmX3Jpp5W4BEzesbsDqjuvwpA92mhUofb7/VJ3D+VTAXUWZea Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFABIczVCtJXG//2dsb2JhbABFvlIWc4IeAQEBAwEBAQE3NAsFBwQCAQgRBAEBAQoUCQcnCxQJCAIEDgUIE4dyBgy7GASMXRUBg0xhA6ZSgnOBZAEGGR4 X-IronPort-AV: E=Sophos;i="4.84,291,1355097600"; d="scan'208";a="153382202" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 16 Dec 2012 01:00:42 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id qBG10gdU007262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 16 Dec 2012 01:00:42 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.13]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.02.0318.004; Sat, 15 Dec 2012 19:00:42 -0600 From: "Joseph Salowey (jsalowey)" To: Piyush Jain Thread-Topic: [TLS] Comments on the cached-info draft Thread-Index: AQHNvQbiOxf7J2O3YEykXagetKXYEZf/Oi2AgAs+DoCAAMfDgIAP/A6A Date: Sun, 16 Dec 2012 01:00:41 +0000 Message-ID: References: <006b01cdd32a$bd08f360$371ada20$@ditenity.com> In-Reply-To: <006b01cdd32a$bd08f360$371ada20$@ditenity.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.61] Content-Type: text/plain; charset="us-ascii" Content-ID: <76D11F30F1B90540975B020C7D107848@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [TLS] Comments on the cached-info draft 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 01:00:44 -0000 Hi Piyush, I think this is a good point. In most cases the client is caching informat= ion from a previously successful handshake so it should not be too difficul= t for the client to select the appropriate hashes. I think that the numb= er of hashes of the same type that may be sent by the client or server woul= d depend upon the type of cached info. For example, if we allow caching of= intermediate certificates then multiple hashes pertaining to one certifica= te chain may be sent. It would not be permissible to send multiple hashes = for the different chains since this would result in ambiguity as to which c= hain was used. The document would have to define the appropriate behavio= r for each type. =20 Does this capture the issue? =20 Thanks, Joe On Dec 5, 2012, at 12:54 PM, Piyush Jain wrote: > Stefan, >=20 > I agree that the current text violates TLS 1.2 by changing the message > specification in the handshake protocol. >=20 > Your proposal addresses those violations and simplifies the cached-info > exchange. > But it also adds ambiguity to certain use cases allowed by cached-info > draft. >=20 > The current text does not limit the number of certificate chain (or > trusted_cas) hashes that the client can include as part of client hello. = In > some cases the client can include more than one certificate chain (or > trusted_cas) hashes. Examples are scenarios where the client communicate= s > with same server with different SNIs and scenarios where client connects= to > the server using different cipher-suite preference or different signing/h= ash > algorithm preference. >=20 > One way to fix this would be to provide guidance on how the client and > servers can determine which cached objects should be included in hello > messages. I guess it will require preprocessing of SNI and signature > algorithms extensions and also that of cipher-spec message at both the > client and the server. Clients would only include the cached objects that > comply with the above (for bandwidth optimization) and servers MUST only > include those that comply the SNI, algorithms and cipher-suite. Also the > servers MUST not include more than one cached object of the same type. >=20 > Thoughts? >=20 > -Piyush >=20 >=20 >> -----Original Message----- >> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of >> Stefan Santesson >> Sent: Wednesday, December 05, 2012 1:00 AM >> To: Joseph Salowey (jsalowey) >> Cc: >> Subject: Re: [TLS] Comments on the cached-info draft >>=20 >> Hi Joe, >>=20 >> I can't see the functionality being limited in any important way. >> In fact, as mentioned below, I see that it actually opens up new > opportunities >> if you don't have to force the cached hash into existing handshake > messages. >>=20 >>=20 >> Regarding caching of partial chain: >> If the group feels that it would be compliant with section 7.4.2 of TLS > 1.2, I >> guess that you could allow the server to send just the end certificate i= f > the >> client in a new CahcedInformationType has sent over a matching hash of t= he >> chain (excluding the server cert) that the this server usually sends > together >> with the server certificate. >>=20 >> This is actually much easier to accommodate if we go for the cleaner > solution >> to just omit cached data in hs messages. This would have been semantical= ly >> horrific if we would mix the server certificate with a hash of the cache= d > chain >> in the same opaque blob. >>=20 >> /Stefan >>=20 >>=20 >> On 11/28/12 6:19 AM, "Joseph Salowey (jsalowey)" >> wrote: >>=20 >>> Hi Stefan, >>>=20 >>> This new proposal of omitting the data sounds a bit simpler to me. Yo= u >>> say the new approach will limit the functionality in some way. In what >>> way is it limited? >>>=20 >>> Do you think we could accommodate the case where the endpoint has >>> intermediate CA certificates cached but not the end entity certificate? >>> This would require parsing the certificate message, but the response >>> could just omit the certs that were indicated in the cachedInfo. The >>> parsing of the cert message is a bit more complex, but it could satisfy >>> some of the use cases discussed at the meeting. >>>=20 >>> Thanks, >>>=20 >>> Joe >>>=20 >>>=20 >>>=20 >>> On Nov 7, 2012, at 7:42 AM, Stefan Santesson wrote: >>>=20 >>>> It was quite a while since I wrote the first version of this draft. >>>> Now that I bring it up to my attention I found a problem that I think >>>> should be fixed. >>>>=20 >>>> After a close examination I'm convinced that the current spec breaks >>>> TLS. >>>>=20 >>>>=20 >>>> The current approach is to exchange support for cached-info in client >>>> and server hellos. >>>> This includes hashes for cached objects (clients) and confirmation of >>>> cached objects (server). >>>>=20 >>>> In addition to this, this protocol allows the cached data in >>>> handshake messages to be swapped with cached object hashes. >>>> This is a violation of the syntax of these handshake messages. >>>>=20 >>>> Take the Certificate handshake message for example. The spec suggest >>>> here to replace the certificate_list vector to be replaced with a >>>> vector of CachedObejct structured data. >>>> This breaks the syntax of this handshake message. A strict processing >>>> of the certificate_list vector will expect an ASN.1 encoded binary >>>> containing a sequence of certificates, not a vector of data objects >>>> according to the CachedObject structure. >>>>=20 >>>> My first thought was that we actually need a new handshake message. >>>> However that is not helpful either. >>>> The TLS spec require the Certificate handshake message to be sent in >>>> case the chosen cipher suite demands it, so it MUST be sent. >>>> It can't be replaced by another handshake message. >>>>=20 >>>> My current belief is that we simply should omit the cached data, and >>>> that each cachedInfo type need to defined how to omit cached data. >>>>=20 >>>> In case of the certificate handshake message, the certificate list >>>> should be replaced with an empty sequence. >>>>=20 >>>>=20 >>>> There is actually no need to send the hash of the cached data in the >>>> handshake message. Not if the confirmation of the cached info is >>>> exchanged in the server hello. Sending the hash once more in the >>>> handshake message is then redundant. >>>>=20 >>>>=20 >>>> So I propose the following: >>>>=20 >>>> 1) Clients send hashes of cached objects in client hello. >>>> 2) Server responds with one or zero hashes per cachedInfo type, that >>>> a) matches a cached object sent by the client b) will be omitted by >>>> the server in the corresponding handshake message. >>>> 3) How information is omitted from the handshake message is defined >>>> per cached info type. For the current defined 2 types this is: >>>> A) cached certificate cahins in Certificate: replace the sequence of >>>> certificates with an empty sequence. >>>> B) certificate_authorities in Certificate Request: Send an empty >>>> list of DistinguishedName >>>> 4) Clients will act as if the cached objects (confirmed in server >>>> hello) were sent in the handshake messages. >>>> 5) Everything else according to the current spec >>>>=20 >>>>=20 >>>> The proposed approach will somewhat limit the functionality of the >>>> current spec, but it ads value in simplicity. >>>> I can't imagine a valid use case that would not be covered by this >>>> change, but I might overlook something. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>>=20 >>=20 >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 From jsalowey@cisco.com Sat Dec 15 17:11:04 2012 Return-Path: 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 4B51B21F8513 for ; Sat, 15 Dec 2012 17:11:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 15TYg69rnJ8I for ; Sat, 15 Dec 2012 17:11:03 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 37C8121F8510 for ; Sat, 15 Dec 2012 17:11:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5581; q=dns/txt; s=iport; t=1355620263; x=1356829863; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=H5g9EHkBEuZM24NhtcUX2/bXkJh+gvNHMy0F5QTNXYs=; b=XGnkPvsBqDe1rMtLHWXA9wlJQI4hsAi8Z+DutCcqRbbilUvdVjYVEu3f p6iF0VPqCne26894VCdYY8JweNpxdJ78uWuuASrxWWfzOjxl/QgPwfpbQ 4owrPs17Cw6URql7vwBBKTO6erz0BNNi4XGcwwx38IdnHbrhe/QofvY9m A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAF0fzVCtJXHB/2dsb2JhbABFvlIWc4IeAQEBAwEBAQE3NAsFCwIBCBgKFBAnCyUCBA4FCBOHcgYMuxQEjF0VAYNMYQOmUoJzgWQBBhke X-IronPort-AV: E=Sophos;i="4.84,291,1355097600"; d="scan'208";a="153385020" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-6.cisco.com with ESMTP; 16 Dec 2012 01:11:02 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qBG1B2qf014889 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 16 Dec 2012 01:11:02 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.13]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Sat, 15 Dec 2012 19:11:02 -0600 From: "Joseph Salowey (jsalowey)" To: Stefan Santesson Thread-Topic: [TLS] Comments on the cached-info draft Thread-Index: AQHNvQbiOxf7J2O3YEykXagetKXYEZf/Oi2AgAs+DoCAEMa1AA== Date: Sun, 16 Dec 2012 01:11:01 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.61] Content-Type: text/plain; charset="us-ascii" Content-ID: <0EDA4294828B65419C9EE831A1D893C9@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [TLS] Comments on the cached-info draft 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 01:11:04 -0000 Are there any objections to: a) Stefan's new proposal to omit the cached data b) Accommodating a cached intermediate chain so only the end-entity certi= ficate needs to be sent. =20 Thanks, Joe On Dec 5, 2012, at 12:59 AM, Stefan Santesson wrote: > Hi Joe, >=20 > I can't see the functionality being limited in any important way. > In fact, as mentioned below, I see that it actually opens up new > opportunities if you don't have to force the cached hash into existing > handshake messages. >=20 >=20 > Regarding caching of partial chain: > If the group feels that it would be compliant with section 7.4.2 of TLS > 1.2, I guess that you could allow the server to send just the end > certificate if the client in a new CahcedInformationType has sent over a > matching hash of the chain (excluding the server cert) that the this > server usually sends together with the server certificate. >=20 > This is actually much easier to accommodate if we go for the cleaner > solution to just omit cached data in hs messages. This would have been > semantically horrific if we would mix the server certificate with a hash > of the cached chain in the same opaque blob. >=20 > /Stefan >=20 >=20 > On 11/28/12 6:19 AM, "Joseph Salowey (jsalowey)" > wrote: >=20 >> Hi Stefan, >>=20 >> This new proposal of omitting the data sounds a bit simpler to me. You >> say the new approach will limit the functionality in some way. In what >> way is it limited? >>=20 >> Do you think we could accommodate the case where the endpoint has >> intermediate CA certificates cached but not the end entity certificate? >> This would require parsing the certificate message, but the response >> could just omit the certs that were indicated in the cachedInfo. The >> parsing of the cert message is a bit more complex, but it could satisfy >> some of the use cases discussed at the meeting. >>=20 >> Thanks, >>=20 >> Joe=20 >>=20 >>=20 >>=20 >> On Nov 7, 2012, at 7:42 AM, Stefan Santesson wrote: >>=20 >>> It was quite a while since I wrote the first version of this draft. >>> Now that I bring it up to my attention I found a problem that I think >>> should be fixed. >>>=20 >>> After a close examination I'm convinced that the current spec breaks >>> TLS. >>>=20 >>>=20 >>> The current approach is to exchange support for cached-info in client >>> and >>> server hellos. >>> This includes hashes for cached objects (clients) and confirmation of >>> cached objects (server). >>>=20 >>> In addition to this, this protocol allows the cached data in handshake >>> messages to be swapped with cached object hashes. >>> This is a violation of the syntax of these handshake messages. >>>=20 >>> Take the Certificate handshake message for example. The spec suggest >>> here >>> to replace the certificate_list vector to be replaced with a vector of >>> CachedObejct structured data. >>> This breaks the syntax of this handshake message. A strict processing o= f >>> the certificate_list vector will expect an ASN.1 encoded binary >>> containing >>> a sequence of certificates, not a vector of data objects according to >>> the >>> CachedObject structure. >>>=20 >>> My first thought was that we actually need a new handshake message. >>> However that is not helpful either. >>> The TLS spec require the Certificate handshake message to be sent in >>> case >>> the chosen cipher suite demands it, so it MUST be sent. >>> It can't be replaced by another handshake message. >>>=20 >>> My current belief is that we simply should omit the cached data, and >>> that >>> each cachedInfo type need to defined how to omit cached data. >>>=20 >>> In case of the certificate handshake message, the certificate list >>> should >>> be replaced with an empty sequence. >>>=20 >>>=20 >>> There is actually no need to send the hash of the cached data in the >>> handshake message. Not if the confirmation of the cached info is >>> exchanged >>> in the server hello. Sending the hash once more in the handshake messag= e >>> is then redundant. >>>=20 >>>=20 >>> So I propose the following: >>>=20 >>> 1) Clients send hashes of cached objects in client hello. >>> 2) Server responds with one or zero hashes per cachedInfo type, that a) >>> matches a cached object sent by the client b) will be omitted by the >>> server in the corresponding handshake message. >>> 3) How information is omitted from the handshake message is defined per >>> cached info type. For the current defined 2 types this is: >>> A) cached certificate cahins in Certificate: replace the sequence of >>> certificates with an empty sequence. >>> B) certificate_authorities in Certificate Request: Send an empty list >>> of >>> DistinguishedName >>> 4) Clients will act as if the cached objects (confirmed in server hello= ) >>> were sent in the handshake messages. >>> 5) Everything else according to the current spec >>>=20 >>>=20 >>> The proposed approach will somewhat limit the functionality of the >>> current >>> spec, but it ads value in simplicity. >>> I can't imagine a valid use case that would not be covered by this >>> change, >>> but I might overlook something. >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>=20 >=20 >=20 From jsalowey@cisco.com Sat Dec 15 17:28:03 2012 Return-Path: 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 9747021F8446 for ; Sat, 15 Dec 2012 17:28:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 NNw0895vdV7L for ; Sat, 15 Dec 2012 17:28:03 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id E6CFA21F8445 for ; Sat, 15 Dec 2012 17:28:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1757; q=dns/txt; s=iport; t=1355621283; x=1356830883; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Bb1DIo6pz4gF5d7ZDN7QQ2j5QyhKcaWhBJVaAJW6iIQ=; b=FwYDaA/MsYPCFnnqUEbIyCchc5aEnZB6frpbXclCsEw/TTtEXyOph4ds ZBjQjtNRujYxlDoCpX1CqH3UtxDLGsBEemMqSU4lOPRT3oKA8YMQkZC8v lCXP7yZDvncnNVJQAyLedfuzdarYpHjiuxucn4oV3t9GOu5aKlcvS5R1U 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABojzVCtJV2d/2dsb2JhbABFvlIWc4IeAQEBAwEBAQE3NAsFCwIBCBgKFBAnCyUCBA4FCIgFBgy7EASMXYNiYQOmUoJzgiI X-IronPort-AV: E=Sophos;i="4.84,291,1355097600"; d="scan'208";a="153385186" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-5.cisco.com with ESMTP; 16 Dec 2012 01:28:02 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qBG1S25b013701 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 16 Dec 2012 01:28:02 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.13]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Sat, 15 Dec 2012 19:28:02 -0600 From: "Joseph Salowey (jsalowey)" To: Nikos Mavrogiannopoulos Thread-Topic: [TLS] Followup on RFC 6091 and oob-pubkeys Thread-Index: AQHNz/wGJhOSB8EGHk+z5uD8jPHphpgFimuAgBWTWYA= Date: Sun, 16 Dec 2012 01:28:00 +0000 Message-ID: References: <50BB0A4B.8070806@gnutls.org> In-Reply-To: <50BB0A4B.8070806@gnutls.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.61] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [TLS] Followup on RFC 6091 and oob-pubkeys 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 01:28:03 -0000 On Dec 1, 2012, at 11:59 PM, Nikos Mavrogiannopoulos wrot= e: > On 12/01/2012 08:41 PM, Eric Rescorla wrote: >=20 >> This message is only sent in response to the certificate request >> message. The client certificate message is sent using the same >> formatting as the server certificate message, and it is also required >> to present a certificate that matches the negotiated certificate >> type. If OpenPGP certificates have been selected and no certificate >> is available from the client, then a certificate structure of type >> "empty_cert" that contains an OpenPGPEmptyCert value MUST be sent. >> The server SHOULD respond with a "handshake_failure" fatal alert if >> client authentication is required. >> Based on the above, I believe that the WG consensus implies that we >> define new structures with the more general semantics. >=20 >=20 > Well since the new use-cases justify that I have no objection. What my > main point is about, is to keep a single certificate type extension in > TLS by defining values to be used for openpgp keys as well, and > deprecate both the previous extension and registry. The openpgp type > could simply be marked as reserved in this draft. This way there will be > no need for two different certificate type extensions for the > applications that need to support both openpgp and raw keys. >=20 [Joe] It seems the openpgp specification need to be updated to use the ext= ension. =20 > If the issue is exhaustion of certificate types, then it should be > increased in size. >=20 > regards, > Nikos > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From jsalowey@cisco.com Sat Dec 15 17:33:19 2012 Return-Path: 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 214E921F8499 for ; Sat, 15 Dec 2012 17:33:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 MBYM2jAEw6Zq for ; Sat, 15 Dec 2012 17:33:18 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 551A321F848B for ; Sat, 15 Dec 2012 17:33:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2067; q=dns/txt; s=iport; t=1355621598; x=1356831198; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=GONHJc4wKTlVIkD4yMtGnbeWlxKoHN0D1OyGF8XTobk=; b=T1BMrELA/6bnpzJ8Jq0CjDVhIkJKVT9XM7eaW03Kd2VESF+PQCzIkXKU AUUsTE9DixYG5itLxwdatKuJBs/WLmW+W9zLZqvep9WyVddR04l2yQy2A SssNbaeh6fC3uKvGxq1TKxyht6P8d7N7Xca3LnMRtNYJX3B4onAau+c8m w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAA8kzVCtJXG+/2dsb2JhbABFvlIWc4IeAQEBAwEBAQE3NAsFCwIBCBgKFBAnCyUCBA4FCIgFBgy7DgSMXYNiYQOmUoJzgiI X-IronPort-AV: E=Sophos;i="4.84,291,1355097600"; d="scan'208";a="153384907" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-8.cisco.com with ESMTP; 16 Dec 2012 01:33:18 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qBG1XH42011971 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 16 Dec 2012 01:33:17 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.13]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Sat, 15 Dec 2012 19:33:17 -0600 From: "Joseph Salowey (jsalowey)" To: Daniel Kahn Gillmor Thread-Topic: [TLS] Followup on RFC 6091 and oob-pubkeys Thread-Index: AQHNz/wGJhOSB8EGHk+z5uD8jPHphpgGGdGAgBUFbIA= Date: Sun, 16 Dec 2012 01:33:17 +0000 Message-ID: References: <50BB8295.1030800@fifthhorseman.net> In-Reply-To: <50BB8295.1030800@fifthhorseman.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.61] Content-Type: text/plain; charset="us-ascii" Content-ID: <5392C0CC8BBD474C9D4F66EBFB4B4F39@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [TLS] Followup on RFC 6091 and oob-pubkeys 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 01:33:19 -0000 On Dec 2, 2012, at 8:32 AM, Daniel Kahn Gillmor wro= te: > On 12/01/2012 02:41 PM, Eric Rescorla wrote: >> After reviewing RFC 6091, I believe that it requires that the client and >> server use the same credentials (assuming client authentication at >> all). Here's the relevant passage: >>=20 >> 3.5. Client Certificate >>=20 >> This message is only sent in response to the certificate request >> message. The client certificate message is sent using the same >> formatting as the server certificate message, and it is also required >> to present a certificate that matches the negotiated certificate >> type. If OpenPGP certificates have been selected and no certificate >> is available from the client, then a certificate structure of type >> "empty_cert" that contains an OpenPGPEmptyCert value MUST be sent. >> The server SHOULD respond with a "handshake_failure" fatal alert if >> client authentication is required. >>=20 >> Based on the above, I believe that the WG consensus implies that we >> define new structures with the more general semantics. >=20 > If these general semantics are desirable (i believe they are, given the > discussion), it sounds to me like a new draft would obsolete RFC 6091, > since it would provide all the features of 6091 plus the capability to > indicate separate cert types for each peer. >=20 [Joe] The new draft would define a new extension, it wouldn't obsolete RFC= 60691 because it will not discuss openpgp.=20 > It doesn't make sense for the IETF to have two registries for > certificate types in TLS; I think we should re-use the certificate type > registry from RFC 6091 for this proposal. >=20 [Joe] If it was desirable for openpgp to make use of the new semantics of t= he new extension then another document would be needed to update or obsolet= e RFC 6091. =20 > Regards, >=20 > --dkg > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From piyush@ditenity.com Sun Dec 16 11:25:58 2012 Return-Path: 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 B93B721F889D for ; Sun, 16 Dec 2012 11:25:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.576 X-Spam-Level: X-Spam-Status: No, score=-3.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 HKSt+4I+gTv1 for ; Sun, 16 Dec 2012 11:25:57 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 8A5B021F889C for ; Sun, 16 Dec 2012 11:25:57 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so4995408obc.31 for ; Sun, 16 Dec 2012 11:25:57 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=MC3m4sBI5hXDJ8InICmoS78P0vsa9qt9C3B8acZbuXc=; b=Q3SkHiOn1Okr0YUWK6HraMsBao0sGnsSis7LqndDfuSKCXuBIDigXzZWTPSrZolqJJ CL2l18hCfB5eh2kJ38hAQt2dTl1Jsxc2PzTlIOak6CbHSh6PeW+5iKuyVukItkRkHXIv R81LtpPJ+x1iWY6mf/DOFPmLxQMQ2nXdwUB07NU7iiD4dY6Lroy9W2tFdqQFBgD/5TJz FDriAKjGQrQf4ycQYj48ig/I7gdKSvtf39Kkf5qUBLmK8uN5mg9D3O2Gr4fmp2Hvwaa9 EjiwoGIAMItAQVcRFoDqidSqTGh+8Fx8TFnm9s6NvBKIf5qmy9H1NUZIeaSwC0iMKvPn Iv7w== Received: by 10.60.0.138 with SMTP id 10mr9643285oee.142.1355685956823; Sun, 16 Dec 2012 11:25:56 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id c4sm8258870oee.0.2012.12.16.11.25.55 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 16 Dec 2012 11:25:56 -0800 (PST) From: "Piyush Jain" To: "'Joseph Salowey \(jsalowey\)'" , "'Stefan Santesson'" References: <006b01cdd32a$bd08f360$371ada20$@ditenity.com> In-Reply-To: Date: Sun, 16 Dec 2012 11:25:51 -0800 Message-ID: <027201cddbc3$29d457a0$7d7d06e0$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF4mXT1UQk+zS8c+cqnHbkeZekMDwF3e5H6AYSIaT8CUEfeepibsa5w Content-Language: en-us X-Gm-Message-State: ALoCoQnHaX6lLKyCeCNZLibsNNuef9qXNGt5Nhpb0Hnel5CJw6jMeiWQLUZ6rx6+kMg8InCBX3f3 Cc: tls@ietf.org Subject: Re: [TLS] Comments on the cached-info draft 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 19:25:58 -0000 Thanks Joe, Yes - I think you have captured the issue. As you mentioned, providing guidance on what to send and how to deal with each type of cached object would address the issue. Comment for Stefan - Your proposal is based on the assumption that passing vector of cached objects in certificate message violates the protocol. At first I also thought the same. However, on careful reading I think that assumption is incorrect. RFC 5246 defines ASN.1Cert as opaque. So setting it to a cert hash (or any other representation of the cert) would not be a violation. -Piyush > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > Sent: Saturday, December 15, 2012 5:01 PM > To: Piyush Jain > Cc: Stefan Santesson; > Subject: Re: [TLS] Comments on the cached-info draft > > Hi Piyush, > > I think this is a good point. In most cases the client is caching information > from a previously successful handshake so it should not be too difficult for > the client to select the appropriate hashes. I think that the number of > hashes of the same type that may be sent by the client or server would > depend upon the type of cached info. For example, if we allow caching of > intermediate certificates then multiple hashes pertaining to one certificate > chain may be sent. It would not be permissible to send multiple hashes for > the different chains since this would result in ambiguity as to which chain was > used. The document would have to define the appropriate behavior for > each type. > > Does this capture the issue? > > Thanks, > > Joe > > > On Dec 5, 2012, at 12:54 PM, Piyush Jain wrote: > > > Stefan, > > > > I agree that the current text violates TLS 1.2 by changing the > > message specification in the handshake protocol. > > > > Your proposal addresses those violations and simplifies the > > cached-info exchange. > > But it also adds ambiguity to certain use cases allowed by cached-info > > draft. > > > > The current text does not limit the number of certificate chain (or > > trusted_cas) hashes that the client can include as part of client > > hello. In some cases the client can include more than one certificate > > chain (or > > trusted_cas) hashes. Examples are scenarios where the client > > communicates with same server with different SNIs and scenarios where > > client connects to the server using different cipher-suite preference > > or different signing/hash algorithm preference. > > > > One way to fix this would be to provide guidance on how the client and > > servers can determine which cached objects should be included in hello > > messages. I guess it will require preprocessing of SNI and signature > > algorithms extensions and also that of cipher-spec message at both the > > client and the server. Clients would only include the cached objects > > that comply with the above (for bandwidth optimization) and servers > > MUST only include those that comply the SNI, algorithms and > > cipher-suite. Also the servers MUST not include more than one cached > object of the same type. > > > > Thoughts? > > > > -Piyush > > > > > >> -----Original Message----- > >> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > >> Stefan Santesson > >> Sent: Wednesday, December 05, 2012 1:00 AM > >> To: Joseph Salowey (jsalowey) > >> Cc: > >> Subject: Re: [TLS] Comments on the cached-info draft > >> > >> Hi Joe, > >> > >> I can't see the functionality being limited in any important way. > >> In fact, as mentioned below, I see that it actually opens up new > > opportunities > >> if you don't have to force the cached hash into existing handshake > > messages. > >> > >> > >> Regarding caching of partial chain: > >> If the group feels that it would be compliant with section 7.4.2 of > >> TLS > > 1.2, I > >> guess that you could allow the server to send just the end > >> certificate if > > the > >> client in a new CahcedInformationType has sent over a matching hash > >> of the chain (excluding the server cert) that the this server usually > >> sends > > together > >> with the server certificate. > >> > >> This is actually much easier to accommodate if we go for the cleaner > > solution > >> to just omit cached data in hs messages. This would have been > >> semantically horrific if we would mix the server certificate with a > >> hash of the cached > > chain > >> in the same opaque blob. > >> > >> /Stefan > >> > >> > >> On 11/28/12 6:19 AM, "Joseph Salowey (jsalowey)" > > >> wrote: > >> > >>> Hi Stefan, > >>> > >>> This new proposal of omitting the data sounds a bit simpler to me. You > >>> say the new approach will limit the functionality in some way. In > >>> what way is it limited? > >>> > >>> Do you think we could accommodate the case where the endpoint has > >>> intermediate CA certificates cached but not the end entity certificate? > >>> This would require parsing the certificate message, but the response > >>> could just omit the certs that were indicated in the cachedInfo. The > >>> parsing of the cert message is a bit more complex, but it could > >>> satisfy some of the use cases discussed at the meeting. > >>> > >>> Thanks, > >>> > >>> Joe > >>> > >>> > >>> > >>> On Nov 7, 2012, at 7:42 AM, Stefan Santesson wrote: > >>> > >>>> It was quite a while since I wrote the first version of this draft. > >>>> Now that I bring it up to my attention I found a problem that I > >>>> think should be fixed. > >>>> > >>>> After a close examination I'm convinced that the current spec > >>>> breaks TLS. > >>>> > >>>> > >>>> The current approach is to exchange support for cached-info in > >>>> client and server hellos. > >>>> This includes hashes for cached objects (clients) and confirmation > >>>> of cached objects (server). > >>>> > >>>> In addition to this, this protocol allows the cached data in > >>>> handshake messages to be swapped with cached object hashes. > >>>> This is a violation of the syntax of these handshake messages. > >>>> > >>>> Take the Certificate handshake message for example. The spec > >>>> suggest here to replace the certificate_list vector to be replaced > >>>> with a vector of CachedObejct structured data. > >>>> This breaks the syntax of this handshake message. A strict > >>>> processing of the certificate_list vector will expect an ASN.1 > >>>> encoded binary containing a sequence of certificates, not a vector > >>>> of data objects according to the CachedObject structure. > >>>> > >>>> My first thought was that we actually need a new handshake message. > >>>> However that is not helpful either. > >>>> The TLS spec require the Certificate handshake message to be sent > >>>> in case the chosen cipher suite demands it, so it MUST be sent. > >>>> It can't be replaced by another handshake message. > >>>> > >>>> My current belief is that we simply should omit the cached data, > >>>> and that each cachedInfo type need to defined how to omit cached > data. > >>>> > >>>> In case of the certificate handshake message, the certificate list > >>>> should be replaced with an empty sequence. > >>>> > >>>> > >>>> There is actually no need to send the hash of the cached data in > >>>> the handshake message. Not if the confirmation of the cached info > >>>> is exchanged in the server hello. Sending the hash once more in > >>>> the handshake message is then redundant. > >>>> > >>>> > >>>> So I propose the following: > >>>> > >>>> 1) Clients send hashes of cached objects in client hello. > >>>> 2) Server responds with one or zero hashes per cachedInfo type, > >>>> that > >>>> a) matches a cached object sent by the client b) will be omitted > >>>> by the server in the corresponding handshake message. > >>>> 3) How information is omitted from the handshake message is defined > >>>> per cached info type. For the current defined 2 types this is: > >>>> A) cached certificate cahins in Certificate: replace the sequence > >>>> of certificates with an empty sequence. > >>>> B) certificate_authorities in Certificate Request: Send an empty > >>>> list of DistinguishedName > >>>> 4) Clients will act as if the cached objects (confirmed in server > >>>> hello) were sent in the handshake messages. > >>>> 5) Everything else according to the current spec > >>>> > >>>> > >>>> The proposed approach will somewhat limit the functionality of the > >>>> current spec, but it ads value in simplicity. > >>>> I can't imagine a valid use case that would not be covered by this > >>>> change, but I might overlook something. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> TLS mailing list > >>>> TLS@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/tls > >>> > >> > >> > >> _______________________________________________ > >> TLS mailing list > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls > > From piyush@ditenity.com Sun Dec 16 11:42:17 2012 Return-Path: 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 C9D9F21F892B for ; Sun, 16 Dec 2012 11:42:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.577 X-Spam-Level: X-Spam-Status: No, score=-3.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 MnhDpnBkceGa for ; Sun, 16 Dec 2012 11:42:17 -0800 (PST) Received: from mail-oa0-f44.google.com (mail-oa0-f44.google.com [209.85.219.44]) by ietfa.amsl.com (Postfix) with ESMTP id D492B21F892A for ; Sun, 16 Dec 2012 11:42:16 -0800 (PST) Received: by mail-oa0-f44.google.com with SMTP id n5so5212719oag.31 for ; Sun, 16 Dec 2012 11:42:16 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=kOplVh6EuEEgtZ/FmsI6V9U1qbIwOz/jhq8hymLXLDQ=; b=Yf/xJ8beLYVO1IRF31ynJ++y/VszDNjQq/vgdV+G5vwlDJvufJNv6PfbZupLeEacwx eKa9HA1moLx9v3OeOaXMMUYFlG0/RPg7eATMNOS6qBs3rWE+7Ro4fV9WUWDGy6D9btzT BEj5sdHUpu61Acqd9y6YYuTPdfQ32ahvBsf6dUUrRyYIz2e3mq/ox95SWKsQFwouvOTA zJguw3y5iHpGtZYbHv/Ifpab0QtZXtSUR2lvcJnCR6isp1rwP6thN96DBMjUkM7yv4M3 19ua6fZ9X71s2Z8fIbs7h47xv0LwQTDJCAArOvwUf5iEk2oIAadK5P9u5BwZi3bS9vKd LY/w== Received: by 10.60.7.67 with SMTP id h3mr9664589oea.31.1355686936369; Sun, 16 Dec 2012 11:42:16 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id ag15sm8265299oec.11.2012.12.16.11.42.12 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 16 Dec 2012 11:42:15 -0800 (PST) From: "Piyush Jain" To: "'Joseph Salowey \(jsalowey\)'" , "'Stefan Santesson'" References: In-Reply-To: Date: Sun, 16 Dec 2012 11:42:08 -0800 Message-ID: <027d01cddbc5$71dc36b0$5594a410$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF3e5H6J5oRPTPnQxNox+nxboXkGgF8Im8SmLyuNzA= Content-Language: en-us X-Gm-Message-State: ALoCoQn8eyrLs/5Z0eNwPVVuEzXzZJoC5Rohb7PrEypdFRU+9eLMiH7EUOOXZ+IQ6HSIxv0sZWkj Cc: tls@ietf.org Subject: Re: [TLS] Comments on the cached-info draft 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 19:42:17 -0000 Just a few comments - As thought previously, the existing text does not violate TLS. TLS defines ASN.1Cert as opaqe and certificate_list as list of ASN.1Cert. So you can include a list of cached objects in certificate message. - The benefit of the new proposal is that it avoids sending of information that was already sent in server hello. - The con is that it bundles the content of server certificate message in server hello and requires some preprocessing on server and client in terms of selecting which cached object to send as part of server hello. So the question is : What is the benefit of sending the cached object extension as part of server hello? The server can avoid sending this extension in server hello and just send the cached object(s) as part of the certificate message. -Piyush > -----Original Message----- > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > Joseph Salowey (jsalowey) > Sent: Saturday, December 15, 2012 5:11 PM > To: Stefan Santesson > Cc: > Subject: Re: [TLS] Comments on the cached-info draft > > Are there any objections to: > > a) Stefan's new proposal to omit the cached data > > > b) Accommodating a cached intermediate chain so only the end-entity > certificate needs to be sent. > > > > Thanks, > > Joe > > On Dec 5, 2012, at 12:59 AM, Stefan Santesson > wrote: > > > Hi Joe, > > > > I can't see the functionality being limited in any important way. > > In fact, as mentioned below, I see that it actually opens up new > > opportunities if you don't have to force the cached hash into existing > > handshake messages. > > > > > > Regarding caching of partial chain: > > If the group feels that it would be compliant with section 7.4.2 of > > TLS 1.2, I guess that you could allow the server to send just the end > > certificate if the client in a new CahcedInformationType has sent over > > a matching hash of the chain (excluding the server cert) that the this > > server usually sends together with the server certificate. > > > > This is actually much easier to accommodate if we go for the cleaner > > solution to just omit cached data in hs messages. This would have been > > semantically horrific if we would mix the server certificate with a > > hash of the cached chain in the same opaque blob. > > > > /Stefan > > > > > > On 11/28/12 6:19 AM, "Joseph Salowey (jsalowey)" > > wrote: > > > >> Hi Stefan, > >> > >> This new proposal of omitting the data sounds a bit simpler to me. You > >> say the new approach will limit the functionality in some way. In > >> what way is it limited? > >> > >> Do you think we could accommodate the case where the endpoint has > >> intermediate CA certificates cached but not the end entity certificate? > >> This would require parsing the certificate message, but the response > >> could just omit the certs that were indicated in the cachedInfo. The > >> parsing of the cert message is a bit more complex, but it could > >> satisfy some of the use cases discussed at the meeting. > >> > >> Thanks, > >> > >> Joe > >> > >> > >> > >> On Nov 7, 2012, at 7:42 AM, Stefan Santesson wrote: > >> > >>> It was quite a while since I wrote the first version of this draft. > >>> Now that I bring it up to my attention I found a problem that I > >>> think should be fixed. > >>> > >>> After a close examination I'm convinced that the current spec breaks > >>> TLS. > >>> > >>> > >>> The current approach is to exchange support for cached-info in > >>> client and server hellos. > >>> This includes hashes for cached objects (clients) and confirmation > >>> of cached objects (server). > >>> > >>> In addition to this, this protocol allows the cached data in > >>> handshake messages to be swapped with cached object hashes. > >>> This is a violation of the syntax of these handshake messages. > >>> > >>> Take the Certificate handshake message for example. The spec suggest > >>> here to replace the certificate_list vector to be replaced with a > >>> vector of CachedObejct structured data. > >>> This breaks the syntax of this handshake message. A strict > >>> processing of the certificate_list vector will expect an ASN.1 > >>> encoded binary containing a sequence of certificates, not a vector > >>> of data objects according to the CachedObject structure. > >>> > >>> My first thought was that we actually need a new handshake message. > >>> However that is not helpful either. > >>> The TLS spec require the Certificate handshake message to be sent in > >>> case the chosen cipher suite demands it, so it MUST be sent. > >>> It can't be replaced by another handshake message. > >>> > >>> My current belief is that we simply should omit the cached data, and > >>> that each cachedInfo type need to defined how to omit cached data. > >>> > >>> In case of the certificate handshake message, the certificate list > >>> should be replaced with an empty sequence. > >>> > >>> > >>> There is actually no need to send the hash of the cached data in the > >>> handshake message. Not if the confirmation of the cached info is > >>> exchanged in the server hello. Sending the hash once more in the > >>> handshake message is then redundant. > >>> > >>> > >>> So I propose the following: > >>> > >>> 1) Clients send hashes of cached objects in client hello. > >>> 2) Server responds with one or zero hashes per cachedInfo type, that > >>> a) matches a cached object sent by the client b) will be omitted by > >>> the server in the corresponding handshake message. > >>> 3) How information is omitted from the handshake message is defined > >>> per cached info type. For the current defined 2 types this is: > >>> A) cached certificate cahins in Certificate: replace the sequence of > >>> certificates with an empty sequence. > >>> B) certificate_authorities in Certificate Request: Send an empty > >>> list of DistinguishedName > >>> 4) Clients will act as if the cached objects (confirmed in server > >>> hello) were sent in the handshake messages. > >>> 5) Everything else according to the current spec > >>> > >>> > >>> The proposed approach will somewhat limit the functionality of the > >>> current spec, but it ads value in simplicity. > >>> I can't imagine a valid use case that would not be covered by this > >>> change, but I might overlook something. > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> TLS mailing list > >>> TLS@ietf.org > >>> https://www.ietf.org/mailman/listinfo/tls > >> > > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From piyush@ditenity.com Sun Dec 16 12:12:43 2012 Return-Path: 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 E211821F8972 for ; Sun, 16 Dec 2012 12:12:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 mmLsWRmBJTgP for ; Sun, 16 Dec 2012 12:12:42 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id B507A21F8970 for ; Sun, 16 Dec 2012 12:12:42 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so5015702obc.31 for ; Sun, 16 Dec 2012 12:12:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=ylBXBCRCxhXiqVkwWl/6rJBPsNshErN8VUiBh1c4vws=; b=l5NlmUqI/QaKanjgp7u0GPs1XU8tt5Hc1P3Rj5l8mahYB3bANx8M/4M0IkWmiCqkO+ oNGBPqQRwhrIii5wVcsZjqJ8UTQdzW9+u0UogkyJY6oZ2lq0XyKhF6K585cmkmMeVm2E UONgri4GjB7XMkxFsMtGmIW2omJi2WvUdMrbhmcNgyZT4FfRQJorHrMRcQwZuZQguxBi ir005anSzulRfpMVY+sbuwwc7FxwRiOM7b+F7fAjrfgMz3ct58n5iy7RAI9iM1gPeLdp H9cmhdsC8txhS8oH7YS8LI2pgsp7JZeWkxxumom7lH8Es5UDkCsqJsdVrTJfg2+ERD8J MFQw== Received: by 10.182.114.71 with SMTP id je7mr9995769obb.20.1355688762291; Sun, 16 Dec 2012 12:12:42 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id zz6sm8337336oeb.1.2012.12.16.12.12.40 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 16 Dec 2012 12:12:41 -0800 (PST) From: "Piyush Jain" To: "'Joseph Salowey \(jsalowey\)'" References: <50BB111A.2090406@gnutls.org> <027a01cdd0bc$68d7bad0$3a873070$@ditenity.com> In-Reply-To: Date: Sun, 16 Dec 2012 12:12:36 -0800 Message-ID: <028201cddbc9$b21432b0$163c9810$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQCkziuYALLp/LHwcTeRJT4qG2qlCALH4HAWARdkKc0B8D+zcwG4BiYYmjG5fJA= Content-Language: en-us X-Gm-Message-State: ALoCoQmi0nhogBM8aeVRuPzuljmGYdkdadik/6MLYG3IvG0gEurm/uY2y7RWELV1x36zFpDXq1WO Cc: "'Yngve N. Pettersen \(Developer Opera Software ASA\)'" , tls@ietf.org Subject: Re: [TLS] WGLC for draft-ietf-tls-multiple-cert-status-extension-02 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Dec 2012 20:12:44 -0000 Thanks Joe, Agree with most. However, I do think it makes sense to recommend that server does not include an unknown response. Presence of an unknown response does not provide any benefit to the client and bloats the message. I signed "I don't know' is no better than no response at all. -Piyush > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > Sent: Saturday, December 15, 2012 4:35 PM > To: Piyush Jain > Cc: Yngve N. Pettersen (Developer Opera Software ASA); ; > Nikos Mavrogiannopoulos > Subject: Re: [TLS] WGLC for draft-ietf-tls-multiple-cert-status-extension-02 > > I don't see a valid case for the client to continue if the response is valid and > indicates revoked. Since unknown is a valid OCSP response I don't think we > should forbid it. In cases where the response is inconclusive it is up to the > client to determine how to proceed. The client may choose to allow the > connection to complete in the case that it believes it will have the > opportunity to check the validity of the certificate through another means. > Such an example would be in the case of EAP-TLS where the client may use a > different method of revocation check when it has network access. However > the client MUST NOT engage in activities with the server that require trust in > the validity of the certificate until the certificate has been validated. For > example, a client MUST not disclose username and password information > until it has fully validated the validity of the server certificate. > > Here is an attempt at some suggested text: > > "Clients requesting an OCSP response and receiving one or more OCSP > responses in a "CertificateStatus" message MUST check the OCSP > response(s) and abort the handshake if the response is a revoked > status with a bad_certificate_status_response(113) alert. This alert is > always > fatal. If the response is inconclusive then the client MAY decide to allow the > connection if it believes it will have the opportunity to check the validity > of the certificate through another means. The client MUST about the > connection if it needs to engage in activities that require trust in the server > and the server certificate has not been sufficiently validated. An > example of where the client may wish to continue is with EAP-TLS > where the client can use another mechanism to check the status of a > certificate once it obtains network access. In this case the client may > continue withe handshake, but it would be inappropriate for the client > to disclose a username and password until > it has fully validated the validity of the server certificate." > > > Thanks, > > Joe > > > On Dec 2, 2012, at 10:39 AM, Piyush Jain wrote: > > > Please see inline. > > > >> -----Original Message----- > >> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > >> Yngve N. Pettersen (Developer Opera Software ASA) > >> Sent: Sunday, December 02, 2012 9:04 AM > >> To: tls@ietf.org; Nikos Mavrogiannopoulos > >> Subject: Re: [TLS] WGLC for > > draft-ietf-tls-multiple-cert-status-extension-02 > >> > >> Hi, > >> > >> As I said last time you raised this issue, it is the same requirement > >> as > > RFC 6066 > >> sets for the original > >> Certificate Status extension. I also think it is proper to have such > >> a requirement, because it defines how the data should be handled and > >> acted upon, and collects the information in a single document, so it > >> is not > > necessary > >> to chase one document after another to discover all the proper actions. > > > > > > [Piyush] 6066 does not cover multiple cert status extension. > > Multiple-cert-status extension is being proposed to address the > > limitations of original certificate status request actions. So any > > improvements in how the response should be handled can be part of the > > new documents > >> > >> This requirement clearly indicates that *if* a client request this > > extension, > >> then it MUST verify the result, and act on the result in a secure fashion. > > That > >> is, only proceed if the response is "good", and abort in other cases. > >> (If > > a client > >> does not want to process and act on the information, it can avoid > >> doing so > > by > >> not sending the extension support indication to the server; sending > >> the extension is a declaration that the client accepts and will act > >> upon the returned information in a fashion that protects the user.) > >> > > [Piyush] I agree that if the response indicates that certificate is > > bad, the handshake should be terminated. However, absence of 'good' > > does not imply 'bad' in OCSP. Good and revoked are the only > > authoritative responses in OCSP. Any other response is > > non-authoritative. This implies that for responses other than good or > > revoked, client should try to find the status using other means before > > considering the certificate good or bad. Here are the other possible > scenarios. > > - Unknown response. Not interesting because TLs servers should be > > smart enough to not include unknown response. However, I'm surprised > > that this draft does not explicitly states that tls server must not > > include unknown OCSP response (or unsigned OCSP responses) in status- > request message. > > - Response not understood by client, typically because it is signed > > using a hashing/signing algorithm that client did not understand. It > > does not make sense for the client to abort the handshake in such > > cases. The client should try to obtain the certificate status using other > means. > > > >> The server have the option to not forward a response in case it is > >> bad, in which case the client should fetch the response on its own. > >> If the > > forwarded > >> response is bad, then the client have to act on it, and terminate the > >> connection. > >> > > [Piyush] Good point. I think the draft should call it out explicitly > > and prohibit the server to send any response that it thinks is not > > authoritative. > >> A client that proceeds despite seeing either bad data or a revoked > >> status > > are > >> IMO not conformant, and will IMO also have a security vulnerability. > >> > > [Piyush] Agree if the status is revoked. Bad data is too generic. > > Please look at the scenario mentioned above. > >> > >> As this language was not just acceptable to the Working Group for RFC > > 6066, > >> but the WG actually approved that 6066 added the alert message > >> requirement, which was not present in either RFC 4366 or RFC 3546, my > >> opinion is that the WG have so far clearly and repeatedly stated its > > opinion > >> on this matter, and I therefore plan to leave this text in. > >> > > > >> On Sun, 02 Dec 2012 09:28:10 +0100, Nikos Mavrogiannopoulos > >> wrote: > >> > >>> On 11/16/2012 06:08 PM, Joseph Salowey (jsalowey) wrote: > >>> > >>>> This is a working group last call for > >>>> draft-ietf-tls-multiple-cert-status-extension-02 on "The TLS > >>>> Multiple Certificate Status Request Extension". The draft is available > here: > >>>> > >>>> http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-exte > >>>> ns > >>>> ion-02 Please send you comments to the TLS list by December 17, > >>>> 2012. > >>> > >>> I pretty much repeat the point originally made in: > >>> http://www.ietf.org/mail-archive/web/tls/current/msg08973.html > >>> > >>> The text: > >>> "Clients requesting an OCSP response and receiving one or more OCSP > >>> responses in a "CertificateStatus" message MUST check the OCSP > >>> response(s) and abort the handshake, if the response is a revoked > >>> status or is otherwise not satisfactory with a > >>> bad_certificate_status_response(113) alert. This alert is always > >>> fatal." > >>> > >>> is very strict and IMO not applicable in this document since this > >>> document is not about a verification profile. What if a client > >>> decides to proceed with the handshake even if the status is revoked? > >>> Or if an implementation when it detects junk in this extension (due > >>> to a server > >>> misconfiguration) decides to ignore it instead of aborting. > >>> > >>> Should that make the clients non-conformant to the > >>> multiple-cert-status-extension? > >>> > >>> regards, > >>> Nikos > >>> _______________________________________________ > >>> TLS mailing list > >>> TLS@ietf.org > >>> https://www.ietf.org/mailman/listinfo/tls > >> > >> > >> -- > >> Sincerely, > >> Yngve N. Pettersen > >> > ********************************************************** > >> ********** > >> Senior Developer Email: yngve@opera.com > >> Opera Software ASA http://www.opera.com/ > >> Phone: +47 96 90 41 51 Fax: +47 23 69 24 01 > >> > ********************************************************** > >> ********** > >> _______________________________________________ > >> TLS mailing list > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls From jsalowey@cisco.com Sun Dec 16 17:47:09 2012 Return-Path: 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 1C06C21F8826 for ; Sun, 16 Dec 2012 17:47:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 uSPwwsVa65sU for ; Sun, 16 Dec 2012 17:47:08 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id B349D21F881E for ; Sun, 16 Dec 2012 17:47:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10145; q=dns/txt; s=iport; t=1355708827; x=1356918427; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=Fi6B91hET72iSLz1E8mwT6cdqc3sz/vEixeVAVMNHIY=; b=mMLqgNMxa1zxntD/LzdroevKhnpG18Kktv4NRrooXFQC+M7Gwj1TONkq IAgWgbZB9TLrT3yHqu8C8GIJOQluNilpYelkIK2W9P/5S40PCdFFTxEiE N9wT5JvmSGEFWX2pK8NwCzOR8cHhTT11k1TAq3XtmHaRbgxKPMYmqAVd8 A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFACV5zlCtJV2Z/2dsb2JhbABFvkYWc4IeAQEBAwEBAQEaHTQFBgUHAgICAQgHCgQBAQEKDgYJBxsMCxQJCAIEDgUIAYgEBgy5EQSMWQsQgQGCRmEDlyaPLIJzgWQCBQIXAgQY X-IronPort-AV: E=Sophos;i="4.84,297,1355097600"; d="scan'208";a="153542700" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-2.cisco.com with ESMTP; 17 Dec 2012 01:47:04 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id qBH1l4ro029528 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Dec 2012 01:47:04 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.13]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Sun, 16 Dec 2012 19:47:04 -0600 From: "Joseph Salowey (jsalowey)" To: Piyush Jain Thread-Topic: [TLS] WGLC for draft-ietf-tls-multiple-cert-status-extension-02 Thread-Index: AQHNxBz4XTZ6AP0xt0yDR62IxYeJogLH4HAWARdkKc0B8D+zcwG4BiYYmjG5fJD9rtddAA== Date: Mon, 17 Dec 2012 01:47:04 +0000 Message-ID: References: <50BB111A.2090406@gnutls.org> <027a01cdd0bc$68d7bad0$3a873070$@ditenity.com> <028201cddbc9$b21432b0$163c9810$@ditenity.com> In-Reply-To: <028201cddbc9$b21432b0$163c9810$@ditenity.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.61] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Yngve N. Pettersen \(Developer Opera Software ASA\)" , "" Subject: Re: [TLS] WGLC for draft-ietf-tls-multiple-cert-status-extension-02 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 01:47:09 -0000 On Dec 16, 2012, at 12:12 PM, Piyush Jain wrote: > Thanks Joe, >=20 > Agree with most.=20 > However, I do think it makes sense to recommend that server does not incl= ude > an unknown response.=20 > Presence of an unknown response does not provide any benefit to the clien= t > and bloats the message. I signed "I don't know' is no better than no > response at all. >=20 [Joe] To me, it seemed a simpler implementation just to always include wha= tever response you have. I believe the client will always have to deal wit= h the case that it may receive an unknown response. Having the client impl= ementation explicitly think about what they will do with the unknown respon= se would hopefully lead to more robust implementations.=20 > -Piyush >=20 >> -----Original Message----- >> From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] >> Sent: Saturday, December 15, 2012 4:35 PM >> To: Piyush Jain >> Cc: Yngve N. Pettersen (Developer Opera Software ASA); ; >> Nikos Mavrogiannopoulos >> Subject: Re: [TLS] WGLC for > draft-ietf-tls-multiple-cert-status-extension-02 >>=20 >> I don't see a valid case for the client to continue if the response is > valid and >> indicates revoked. Since unknown is a valid OCSP response I don't thin= k > we >> should forbid it. In cases where the response is inconclusive it is up = to > the >> client to determine how to proceed. The client may choose to allow the >> connection to complete in the case that it believes it will have the >> opportunity to check the validity of the certificate through another > means. >> Such an example would be in the case of EAP-TLS where the client may use= a >> different method of revocation check when it has network access. Howeve= r >> the client MUST NOT engage in activities with the server that require > trust in >> the validity of the certificate until the certificate has been validated= . > For >> example, a client MUST not disclose username and password information >> until it has fully validated the validity of the server certificate. >>=20 >> Here is an attempt at some suggested text: >>=20 >> "Clients requesting an OCSP response and receiving one or more OCSP >> responses in a "CertificateStatus" message MUST check the OCSP >> response(s) and abort the handshake if the response is a revoked >> status with a bad_certificate_status_response(113) alert. This alert i= s >> always >> fatal. If the response is inconclusive then the client MAY decide to > allow the >> connection if it believes it will have the opportunity to check the > validity >> of the certificate through another means. The client MUST about the >> connection if it needs to engage in activities that require trust in > the server >> and the server certificate has not been sufficiently validated. An >> example of where the client may wish to continue is with EAP-TLS >> where the client can use another mechanism to check the status of a >> certificate once it obtains network access. In this case the client ma= y >> continue withe handshake, but it would be inappropriate for the client >> to disclose a username and password until >> it has fully validated the validity of the server certificate." >>=20 >>=20 >> Thanks, >>=20 >> Joe >>=20 >>=20 >> On Dec 2, 2012, at 10:39 AM, Piyush Jain wrote: >>=20 >>> Please see inline. >>>=20 >>>> -----Original Message----- >>>> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of >>>> Yngve N. Pettersen (Developer Opera Software ASA) >>>> Sent: Sunday, December 02, 2012 9:04 AM >>>> To: tls@ietf.org; Nikos Mavrogiannopoulos >>>> Subject: Re: [TLS] WGLC for >>> draft-ietf-tls-multiple-cert-status-extension-02 >>>>=20 >>>> Hi, >>>>=20 >>>> As I said last time you raised this issue, it is the same requirement >>>> as >>> RFC 6066 >>>> sets for the original >>>> Certificate Status extension. I also think it is proper to have such >>>> a requirement, because it defines how the data should be handled and >>>> acted upon, and collects the information in a single document, so it >>>> is not >>> necessary >>>> to chase one document after another to discover all the proper actions= . >>>=20 >>>=20 >>> [Piyush] 6066 does not cover multiple cert status extension. >>> Multiple-cert-status extension is being proposed to address the >>> limitations of original certificate status request actions. So any >>> improvements in how the response should be handled can be part of the >>> new documents >>>>=20 >>>> This requirement clearly indicates that *if* a client request this >>> extension, >>>> then it MUST verify the result, and act on the result in a secure > fashion. >>> That >>>> is, only proceed if the response is "good", and abort in other cases. >>>> (If >>> a client >>>> does not want to process and act on the information, it can avoid >>>> doing so >>> by >>>> not sending the extension support indication to the server; sending >>>> the extension is a declaration that the client accepts and will act >>>> upon the returned information in a fashion that protects the user.) >>>>=20 >>> [Piyush] I agree that if the response indicates that certificate is >>> bad, the handshake should be terminated. However, absence of 'good' >>> does not imply 'bad' in OCSP. Good and revoked are the only >>> authoritative responses in OCSP. Any other response is >>> non-authoritative. This implies that for responses other than good or >>> revoked, client should try to find the status using other means before >>> considering the certificate good or bad. Here are the other possible >> scenarios. >>> - Unknown response. Not interesting because TLs servers should be >>> smart enough to not include unknown response. However, I'm surprised >>> that this draft does not explicitly states that tls server must not >>> include unknown OCSP response (or unsigned OCSP responses) in status- >> request message. >>> - Response not understood by client, typically because it is signed >>> using a hashing/signing algorithm that client did not understand. It >>> does not make sense for the client to abort the handshake in such >>> cases. The client should try to obtain the certificate status using > other >> means. >>>=20 >>>> The server have the option to not forward a response in case it is >>>> bad, in which case the client should fetch the response on its own. >>>> If the >>> forwarded >>>> response is bad, then the client have to act on it, and terminate the >>>> connection. >>>>=20 >>> [Piyush] Good point. I think the draft should call it out explicitly >>> and prohibit the server to send any response that it thinks is not >>> authoritative. >>>> A client that proceeds despite seeing either bad data or a revoked >>>> status >>> are >>>> IMO not conformant, and will IMO also have a security vulnerability. >>>>=20 >>> [Piyush] Agree if the status is revoked. Bad data is too generic. >>> Please look at the scenario mentioned above. >>>>=20 >>>> As this language was not just acceptable to the Working Group for RFC >>> 6066, >>>> but the WG actually approved that 6066 added the alert message >>>> requirement, which was not present in either RFC 4366 or RFC 3546, my >>>> opinion is that the WG have so far clearly and repeatedly stated its >>> opinion >>>> on this matter, and I therefore plan to leave this text in. >>>>=20 >>>=20 >>>> On Sun, 02 Dec 2012 09:28:10 +0100, Nikos Mavrogiannopoulos >>>> wrote: >>>>=20 >>>>> On 11/16/2012 06:08 PM, Joseph Salowey (jsalowey) wrote: >>>>>=20 >>>>>> This is a working group last call for >>>>>> draft-ietf-tls-multiple-cert-status-extension-02 on "The TLS >>>>>> Multiple Certificate Status Request Extension". The draft is > available >> here: >>>>>>=20 >>>>>> http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-exte >>>>>> ns >>>>>> ion-02 Please send you comments to the TLS list by December 17, >>>>>> 2012. >>>>>=20 >>>>> I pretty much repeat the point originally made in: >>>>> http://www.ietf.org/mail-archive/web/tls/current/msg08973.html >>>>>=20 >>>>> The text: >>>>> "Clients requesting an OCSP response and receiving one or more OCSP >>>>> responses in a "CertificateStatus" message MUST check the OCSP >>>>> response(s) and abort the handshake, if the response is a revoked >>>>> status or is otherwise not satisfactory with a >>>>> bad_certificate_status_response(113) alert. This alert is always >>>>> fatal." >>>>>=20 >>>>> is very strict and IMO not applicable in this document since this >>>>> document is not about a verification profile. What if a client >>>>> decides to proceed with the handshake even if the status is revoked? >>>>> Or if an implementation when it detects junk in this extension (due >>>>> to a server >>>>> misconfiguration) decides to ignore it instead of aborting. >>>>>=20 >>>>> Should that make the clients non-conformant to the >>>>> multiple-cert-status-extension? >>>>>=20 >>>>> regards, >>>>> Nikos >>>>> _______________________________________________ >>>>> TLS mailing list >>>>> TLS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tls >>>>=20 >>>>=20 >>>> -- >>>> Sincerely, >>>> Yngve N. Pettersen >>>>=20 >> ********************************************************** >>>> ********** >>>> Senior Developer Email: yngve@opera.com >>>> Opera Software ASA http://www.opera.com/ >>>> Phone: +47 96 90 41 51 Fax: +47 23 69 24 01 >>>>=20 >> ********************************************************** >>>> ********** >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>>=20 >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >=20 >=20 From jsalowey@cisco.com Sun Dec 16 18:11:42 2012 Return-Path: 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 3D2D821F8826 for ; Sun, 16 Dec 2012 18:11:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 LRLjYtMm9v1R for ; Sun, 16 Dec 2012 18:11:41 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id E8EB121F8829 for ; Sun, 16 Dec 2012 18:11:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7961; q=dns/txt; s=iport; t=1355710301; x=1356919901; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=S1I+L0w/+MMtfEBmUNvbMq3H7e8r2gqapj6ov+sZeuE=; b=I0QZbdBloOkZwqjejWI7kWW05bEQR1/+D4FD1IgcoBmI/U/GvHLL1+p4 gz3ceokEfxgNnrkjq0Gc59eMIvzA4Qu5pj4Bf401WUpop+fIqOy9jwJ+j Ci4l7sR/fYpHA8dhM75g3R3D4yXqI3Thi0pC6laVnOIHrGyGHMiNZd+C/ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAF9+zlCtJV2Y/2dsb2JhbABFvkYWc4IeAQEBAwEBAQE3NAsFBwQCAQgRBAEBAQoUCQcnCxQJCAIEDgUIE4dyBgy5DASMXRUBg0xhA6ZSgnOBZAEGGR4 X-IronPort-AV: E=Sophos;i="4.84,297,1355097600"; d="scan'208";a="153565496" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-8.cisco.com with ESMTP; 17 Dec 2012 02:11:40 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qBH2BerU020090 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Dec 2012 02:11:40 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.13]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Sun, 16 Dec 2012 20:11:40 -0600 From: "Joseph Salowey (jsalowey)" To: Piyush Jain Thread-Topic: [TLS] Comments on the cached-info draft Thread-Index: AQF3e5H6UQk+zS8c+cqnHbkeZekMDwF8Im8SmLyuNzCAANXWgA== Date: Mon, 17 Dec 2012 02:11:39 +0000 Message-ID: References: <027d01cddbc5$71dc36b0$5594a410$@ditenity.com> In-Reply-To: <027d01cddbc5$71dc36b0$5594a410$@ditenity.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.61] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [TLS] Comments on the cached-info draft 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 02:11:42 -0000 On Dec 16, 2012, at 11:42 AM, Piyush Jain wrote: > Just a few comments > - As thought previously, the existing text does not violate TLS. TLS defi= nes > ASN.1Cert as opaqe and certificate_list as list of ASN.1Cert. So you can > include a list of cached objects in certificate message. [Joe] While this is true for the certificate chain, is it true for other t= ypes of data that may be cached as well? would this work for distinguished= names for trusted_cas or for the multi-OCSP status response we have been = discussing? I'm a little concerned that it might not work in all cases. S= ince the cached info type has to be explicitly defined it would be sufficie= nt that it works with the types that are likely to be useful to cache. =20 > - The benefit of the new proposal is that it avoids sending of informatio= n > that was already sent in server hello. > - The con is that it bundles the content of server certificate message in > server hello and requires some preprocessing on server and client in term= s > of selecting which cached object to send as part of server hello. [Joe] I'm leaning towards it being simpler to omit the hash if possible. = =20 > So the question is : What is the benefit of sending the cached object > extension as part of server hello? The server can avoid sending this > extension in server hello and just send the cached object(s) as part of t= he > certificate message. >=20 [Joe] I'm not sure I follow you here. The server needs to know what the cl= ient has cached so it can tell if it needs to send the hash or the actual d= ata.=20 > -Piyush >=20 >> -----Original Message----- >> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of >> Joseph Salowey (jsalowey) >> Sent: Saturday, December 15, 2012 5:11 PM >> To: Stefan Santesson >> Cc: >> Subject: Re: [TLS] Comments on the cached-info draft >>=20 >> Are there any objections to: >>=20 >> a) Stefan's new proposal to omit the cached data >>=20 >>=20 >> b) Accommodating a cached intermediate chain so only the end-entity >> certificate needs to be sent. >>=20 >>=20 >>=20 >> Thanks, >>=20 >> Joe >>=20 >> On Dec 5, 2012, at 12:59 AM, Stefan Santesson >> wrote: >>=20 >>> Hi Joe, >>>=20 >>> I can't see the functionality being limited in any important way. >>> In fact, as mentioned below, I see that it actually opens up new >>> opportunities if you don't have to force the cached hash into existing >>> handshake messages. >>>=20 >>>=20 >>> Regarding caching of partial chain: >>> If the group feels that it would be compliant with section 7.4.2 of >>> TLS 1.2, I guess that you could allow the server to send just the end >>> certificate if the client in a new CahcedInformationType has sent over >>> a matching hash of the chain (excluding the server cert) that the this >>> server usually sends together with the server certificate. >>>=20 >>> This is actually much easier to accommodate if we go for the cleaner >>> solution to just omit cached data in hs messages. This would have been >>> semantically horrific if we would mix the server certificate with a >>> hash of the cached chain in the same opaque blob. >>>=20 >>> /Stefan >>>=20 >>>=20 >>> On 11/28/12 6:19 AM, "Joseph Salowey (jsalowey)" >>> wrote: >>>=20 >>>> Hi Stefan, >>>>=20 >>>> This new proposal of omitting the data sounds a bit simpler to me. > You >>>> say the new approach will limit the functionality in some way. In >>>> what way is it limited? >>>>=20 >>>> Do you think we could accommodate the case where the endpoint has >>>> intermediate CA certificates cached but not the end entity certificate= ? >>>> This would require parsing the certificate message, but the response >>>> could just omit the certs that were indicated in the cachedInfo. The >>>> parsing of the cert message is a bit more complex, but it could >>>> satisfy some of the use cases discussed at the meeting. >>>>=20 >>>> Thanks, >>>>=20 >>>> Joe >>>>=20 >>>>=20 >>>>=20 >>>> On Nov 7, 2012, at 7:42 AM, Stefan Santesson wrote: >>>>=20 >>>>> It was quite a while since I wrote the first version of this draft. >>>>> Now that I bring it up to my attention I found a problem that I >>>>> think should be fixed. >>>>>=20 >>>>> After a close examination I'm convinced that the current spec breaks >>>>> TLS. >>>>>=20 >>>>>=20 >>>>> The current approach is to exchange support for cached-info in >>>>> client and server hellos. >>>>> This includes hashes for cached objects (clients) and confirmation >>>>> of cached objects (server). >>>>>=20 >>>>> In addition to this, this protocol allows the cached data in >>>>> handshake messages to be swapped with cached object hashes. >>>>> This is a violation of the syntax of these handshake messages. >>>>>=20 >>>>> Take the Certificate handshake message for example. The spec suggest >>>>> here to replace the certificate_list vector to be replaced with a >>>>> vector of CachedObejct structured data. >>>>> This breaks the syntax of this handshake message. A strict >>>>> processing of the certificate_list vector will expect an ASN.1 >>>>> encoded binary containing a sequence of certificates, not a vector >>>>> of data objects according to the CachedObject structure. >>>>>=20 >>>>> My first thought was that we actually need a new handshake message. >>>>> However that is not helpful either. >>>>> The TLS spec require the Certificate handshake message to be sent in >>>>> case the chosen cipher suite demands it, so it MUST be sent. >>>>> It can't be replaced by another handshake message. >>>>>=20 >>>>> My current belief is that we simply should omit the cached data, and >>>>> that each cachedInfo type need to defined how to omit cached data. >>>>>=20 >>>>> In case of the certificate handshake message, the certificate list >>>>> should be replaced with an empty sequence. >>>>>=20 >>>>>=20 >>>>> There is actually no need to send the hash of the cached data in the >>>>> handshake message. Not if the confirmation of the cached info is >>>>> exchanged in the server hello. Sending the hash once more in the >>>>> handshake message is then redundant. >>>>>=20 >>>>>=20 >>>>> So I propose the following: >>>>>=20 >>>>> 1) Clients send hashes of cached objects in client hello. >>>>> 2) Server responds with one or zero hashes per cachedInfo type, that >>>>> a) matches a cached object sent by the client b) will be omitted by >>>>> the server in the corresponding handshake message. >>>>> 3) How information is omitted from the handshake message is defined >>>>> per cached info type. For the current defined 2 types this is: >>>>> A) cached certificate cahins in Certificate: replace the sequence of >>>>> certificates with an empty sequence. >>>>> B) certificate_authorities in Certificate Request: Send an empty >>>>> list of DistinguishedName >>>>> 4) Clients will act as if the cached objects (confirmed in server >>>>> hello) were sent in the handshake messages. >>>>> 5) Everything else according to the current spec >>>>>=20 >>>>>=20 >>>>> The proposed approach will somewhat limit the functionality of the >>>>> current spec, but it ads value in simplicity. >>>>> I can't imagine a valid use case that would not be covered by this >>>>> change, but I might overlook something. >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> TLS mailing list >>>>> TLS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/tls >>>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >=20 From piyush@ditenity.com Sun Dec 16 21:10:57 2012 Return-Path: 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 421B921F889B for ; Sun, 16 Dec 2012 21:10:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.58 X-Spam-Level: X-Spam-Status: No, score=-3.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 Z4ybJYZfJ4fM for ; Sun, 16 Dec 2012 21:10:55 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 6A03321F8899 for ; Sun, 16 Dec 2012 21:10:55 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so5264346obc.31 for ; Sun, 16 Dec 2012 21:10:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=9C4LrxSeeiMp+1BGBTN5R2cOuspKVoVUdj7Faa9P/JE=; b=Jy4xoAVJUqzSk07G6/OKQYcWRMT/ynInS4TRDL/v4GRgyge3dYvXllAhjOXcwy79xm nUi2OhGuy2ETFtOk2+IuMsmCTkffZNQiJn0vdmmqzX9U8ORgtQJFUe9LaAIPG11o3jMy YLuHZ3kgnDeisZ+Nime3rKd9Na5ROO2ps+c4Rp+vyKcrpfZZiOXTrNb4fe7pDZjfiKu9 1Ph2/33kGUa2OrV64L/E/DMJdn9iMN3NudXNXmV9xfVZuoLgjfoLvuXSyaDuPuKE00rf n8FcIIIg/gqqUM72Pd3gGfB0WbkhEhD6rGmn2z6NjjwEk4zetbhHxcC5u4KVwDbSuvvC Fupw== Received: by 10.60.13.134 with SMTP id h6mr10435501oec.64.1355721054690; Sun, 16 Dec 2012 21:10:54 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id o3sm9065280obk.13.2012.12.16.21.10.53 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 16 Dec 2012 21:10:54 -0800 (PST) From: "Piyush Jain" To: "'Joseph Salowey \(jsalowey\)'" References: <027d01cddbc5$71dc36b0$5594a410$@ditenity.com> In-Reply-To: Date: Sun, 16 Dec 2012 21:10:49 -0800 Message-ID: <031101cddc14$e20b9940$a622cbc0$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF3e5H6J5oRPTPnQxNox+nxboXkGgF8Im8SAoIOzNYCziHUS5iSxtFQ Content-Language: en-us X-Gm-Message-State: ALoCoQnkJpcb11Hmv4jr/ZP8aKoGv5nHnA1h3ZFt4mWkoM1H/Vvhsqyr3KfRklShtRQ2n1hmg+93 Cc: tls@ietf.org Subject: Re: [TLS] Comments on the cached-info draft 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 05:10:57 -0000 Sorry for being unclear on the last part. Let me try again. The current text requires that the server returns the cached objects as an extension in server hello. The reason cited is that the server tells the client which cached objects are understood by the server. These objects could be one of certificate chain, CA DN and possibly OCSP multi status. TLS requires that CA DN be sent in Client Certificate request message, server certificate chain be sent in Certificate message and OCSP status be sent in Certificate status message. Stefan's proposal is that since all the cached objects are sent back in Server hello, there is no need to send cert chain cache objects in Server Certificate message or cached OCSP in Certificate Status message. I think that we can do away with the requirement of returning any cached object as server hello extension. Here are the steps -The client sends the list of cache objects in client hello. -Server DOES NOT acknowledge any cached objects via hello extension - Server sends cached cert chain as part of certificate_list in Server Certificate message ( allowed - ASN.1Cert is defined as opaque in TLS) -Server Sends cached multi ocsp responses as part of Certificate status message ( allowed - OCSResponse is defined as opaque in multi-status draft) - Server sends cached ca dns as part of client certificate request message. (allowed - distinguished name is defined as opaque in TLS) The point is that there is no benefit of explicitly telling the client what cached objects server understands as part of server hello message. Server can use the cached object specified by the client on as needed basis. This way we also avoid the situation where the cached objects are sent to the client twice. This way you do not need to bundle all the information in server hello and pass the data only when it is required by the relevant TLS message and obviates the need for client and server to do any preprocessing to figure out which cached objects are sent during the hello message. Can you think of any issues with not sending the cached objects in server hello extension? Thanks -Piyush > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > Sent: Sunday, December 16, 2012 6:12 PM > To: Piyush Jain > Cc: Stefan Santesson; > Subject: Re: [TLS] Comments on the cached-info draft > > > On Dec 16, 2012, at 11:42 AM, Piyush Jain wrote: > > > Just a few comments > > - As thought previously, the existing text does not violate TLS. TLS > > defines ASN.1Cert as opaqe and certificate_list as list of ASN.1Cert. > > So you can include a list of cached objects in certificate message. > > [Joe] While this is true for the certificate chain, is it true for other types of > data that may be cached as well? would this work for distinguished names > for trusted_cas or for the multi-OCSP status response we have been > discussing? I'm a little concerned that it might not work in all cases. Since the > cached info type has to be explicitly defined it would be sufficient that it > works with the types that are likely to be useful to cache. > > > - The benefit of the new proposal is that it avoids sending of > > information that was already sent in server hello. > > - The con is that it bundles the content of server certificate message > > in server hello and requires some preprocessing on server and client > > in terms of selecting which cached object to send as part of server hello. > > [Joe] I'm leaning towards it being simpler to omit the hash if possible. > > > So the question is : What is the benefit of sending the cached object > > extension as part of server hello? The server can avoid sending this > > extension in server hello and just send the cached object(s) as part > > of the certificate message. > > > > [Joe] I'm not sure I follow you here. The server needs to know what the > client has cached so it can tell if it needs to send the hash or the actual data. > > > -Piyush > > > >> -----Original Message----- > >> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of > >> Joseph Salowey (jsalowey) > >> Sent: Saturday, December 15, 2012 5:11 PM > >> To: Stefan Santesson > >> Cc: > >> Subject: Re: [TLS] Comments on the cached-info draft > >> > >> Are there any objections to: > >> > >> a) Stefan's new proposal to omit the cached data > >> > >> > >> b) Accommodating a cached intermediate chain so only the end-entity > >> certificate needs to be sent. > >> > >> > >> > >> Thanks, > >> > >> Joe > >> > >> On Dec 5, 2012, at 12:59 AM, Stefan Santesson > >> wrote: > >> > >>> Hi Joe, > >>> > >>> I can't see the functionality being limited in any important way. > >>> In fact, as mentioned below, I see that it actually opens up new > >>> opportunities if you don't have to force the cached hash into > >>> existing handshake messages. > >>> > >>> > >>> Regarding caching of partial chain: > >>> If the group feels that it would be compliant with section 7.4.2 of > >>> TLS 1.2, I guess that you could allow the server to send just the > >>> end certificate if the client in a new CahcedInformationType has > >>> sent over a matching hash of the chain (excluding the server cert) > >>> that the this server usually sends together with the server certificate. > >>> > >>> This is actually much easier to accommodate if we go for the cleaner > >>> solution to just omit cached data in hs messages. This would have > >>> been semantically horrific if we would mix the server certificate > >>> with a hash of the cached chain in the same opaque blob. > >>> > >>> /Stefan > >>> > >>> > >>> On 11/28/12 6:19 AM, "Joseph Salowey (jsalowey)" > >>> > >>> wrote: > >>> > >>>> Hi Stefan, > >>>> > >>>> This new proposal of omitting the data sounds a bit simpler to me. > > You > >>>> say the new approach will limit the functionality in some way. In > >>>> what way is it limited? > >>>> > >>>> Do you think we could accommodate the case where the endpoint has > >>>> intermediate CA certificates cached but not the end entity certificate? > >>>> This would require parsing the certificate message, but the response > >>>> could just omit the certs that were indicated in the cachedInfo. The > >>>> parsing of the cert message is a bit more complex, but it could > >>>> satisfy some of the use cases discussed at the meeting. > >>>> > >>>> Thanks, > >>>> > >>>> Joe > >>>> > >>>> > >>>> > >>>> On Nov 7, 2012, at 7:42 AM, Stefan Santesson wrote: > >>>> > >>>>> It was quite a while since I wrote the first version of this draft. > >>>>> Now that I bring it up to my attention I found a problem that I > >>>>> think should be fixed. > >>>>> > >>>>> After a close examination I'm convinced that the current spec > >>>>> breaks TLS. > >>>>> > >>>>> > >>>>> The current approach is to exchange support for cached-info in > >>>>> client and server hellos. > >>>>> This includes hashes for cached objects (clients) and confirmation > >>>>> of cached objects (server). > >>>>> > >>>>> In addition to this, this protocol allows the cached data in > >>>>> handshake messages to be swapped with cached object hashes. > >>>>> This is a violation of the syntax of these handshake messages. > >>>>> > >>>>> Take the Certificate handshake message for example. The spec > >>>>> suggest here to replace the certificate_list vector to be replaced > >>>>> with a vector of CachedObejct structured data. > >>>>> This breaks the syntax of this handshake message. A strict > >>>>> processing of the certificate_list vector will expect an ASN.1 > >>>>> encoded binary containing a sequence of certificates, not a vector > >>>>> of data objects according to the CachedObject structure. > >>>>> > >>>>> My first thought was that we actually need a new handshake > message. > >>>>> However that is not helpful either. > >>>>> The TLS spec require the Certificate handshake message to be sent > >>>>> in case the chosen cipher suite demands it, so it MUST be sent. > >>>>> It can't be replaced by another handshake message. > >>>>> > >>>>> My current belief is that we simply should omit the cached data, > >>>>> and that each cachedInfo type need to defined how to omit cached > data. > >>>>> > >>>>> In case of the certificate handshake message, the certificate list > >>>>> should be replaced with an empty sequence. > >>>>> > >>>>> > >>>>> There is actually no need to send the hash of the cached data in > >>>>> the handshake message. Not if the confirmation of the cached info > >>>>> is exchanged in the server hello. Sending the hash once more in > >>>>> the handshake message is then redundant. > >>>>> > >>>>> > >>>>> So I propose the following: > >>>>> > >>>>> 1) Clients send hashes of cached objects in client hello. > >>>>> 2) Server responds with one or zero hashes per cachedInfo type, > >>>>> that > >>>>> a) matches a cached object sent by the client b) will be omitted > >>>>> by the server in the corresponding handshake message. > >>>>> 3) How information is omitted from the handshake message is > >>>>> defined per cached info type. For the current defined 2 types this is: > >>>>> A) cached certificate cahins in Certificate: replace the sequence > >>>>> of certificates with an empty sequence. > >>>>> B) certificate_authorities in Certificate Request: Send an empty > >>>>> list of DistinguishedName > >>>>> 4) Clients will act as if the cached objects (confirmed in server > >>>>> hello) were sent in the handshake messages. > >>>>> 5) Everything else according to the current spec > >>>>> > >>>>> > >>>>> The proposed approach will somewhat limit the functionality of the > >>>>> current spec, but it ads value in simplicity. > >>>>> I can't imagine a valid use case that would not be covered by this > >>>>> change, but I might overlook something. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> TLS mailing list > >>>>> TLS@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/tls > >>>> > >>> > >>> > >> > >> _______________________________________________ > >> TLS mailing list > >> TLS@ietf.org > >> https://www.ietf.org/mailman/listinfo/tls > > From piyush@ditenity.com Sun Dec 16 21:17:05 2012 Return-Path: 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 F01E721F85A0 for ; Sun, 16 Dec 2012 21:17:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.581 X-Spam-Level: X-Spam-Status: No, score=-3.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 AtZnLO9oCiZH for ; Sun, 16 Dec 2012 21:17:04 -0800 (PST) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9A0DA21F852A for ; Sun, 16 Dec 2012 21:17:04 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id za17so5267689obc.31 for ; Sun, 16 Dec 2012 21:17:04 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language:x-gm-message-state; bh=85dx0icWAog/CTKh5cAxqvIntHChi1DDCQNARezGVEI=; b=DBpJ5KkS90ZZspoKpnzJZXS4LSAPuCXlE51m2xDtCH+tTEpEmAg7XwuaE/QTx20v5n vryuMdpc0GKNN/Y83rCGTAuVV+4St+F6zVxCwgw01PFnlAJyYs88OOHUzOYT9qCIJp49 h6RLjjZZGNeO7tJeEdDCFABJlKZPIujjC7vWhyvLO7UUx3Xy0YW+iLxlSgpol4u17Q+c Dv9+c3P3LAXIhc8XelsTnd2L198+/di9+ie4VaNesMI6YHgjUEFphXF0wQbwMCghziHK h2o81wWhd5AmG1f/1A7zZjxbNov/LUDxJz4jRRkOL/gBQ0oDu9xZqRt2lv7Kd5lndme4 7jPQ== Received: by 10.60.169.41 with SMTP id ab9mr10423409oec.58.1355721424172; Sun, 16 Dec 2012 21:17:04 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id q4sm9084383obz.3.2012.12.16.21.17.02 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 16 Dec 2012 21:17:03 -0800 (PST) From: "Piyush Jain" To: "'Joseph Salowey \(jsalowey\)'" References: <50BB111A.2090406@gnutls.org> <027a01cdd0bc$68d7bad0$3a873070$@ditenity.com> <028201cddbc9$b21432b0$163c9810$@ditenity.com> In-Reply-To: Date: Sun, 16 Dec 2012 21:16:59 -0800 Message-ID: <031301cddc15$be5cd030$3b167090$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQCkziuYALLp/LHwcTeRJT4qG2qlCALH4HAWARdkKc0B8D+zcwG4BiYYAQVTAJ0DJoIp8JoQ8rrw Content-Language: en-us X-Gm-Message-State: ALoCoQl0E3pUcpARJHEPOiKMD1BauEWEXO0UwFImHMTGOWLvfFCfNE8StncG5iqvdvIMeawlQlmX Cc: "'Yngve N. Pettersen \(Developer Opera Software ASA\)'" , tls@ietf.org Subject: Re: [TLS] WGLC for draft-ietf-tls-multiple-cert-status-extension-02 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 05:17:06 -0000 Fair point. Clients should be able to deal with all kind of responses. I guess we can leave it to the server implementations to figure out if they see any value in attaching an unknown response. I have heard a few knowledgeable people argue that a signed unknown response is more valuable than no response even though I could never find a useful scenario where that would be true :). -Piyush > -----Original Message----- > From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > Sent: Sunday, December 16, 2012 5:47 PM > To: Piyush Jain > Cc: Yngve N. Pettersen (Developer Opera Software ASA); ; > Nikos Mavrogiannopoulos > Subject: Re: [TLS] WGLC for draft-ietf-tls-multiple-cert-status-extension-02 > > > On Dec 16, 2012, at 12:12 PM, Piyush Jain wrote: > > > Thanks Joe, > > > > Agree with most. > > However, I do think it makes sense to recommend that server does not > > include an unknown response. > > Presence of an unknown response does not provide any benefit to the > > client and bloats the message. I signed "I don't know' is no better > > than no response at all. > > > > [Joe] To me, it seemed a simpler implementation just to always include > whatever response you have. I believe the client will always have to deal > with the case that it may receive an unknown response. Having the client > implementation explicitly think about what they will do with the unknown > response would hopefully lead to more robust implementations. > > > > > -Piyush > > > >> -----Original Message----- > >> From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] > >> Sent: Saturday, December 15, 2012 4:35 PM > >> To: Piyush Jain > >> Cc: Yngve N. Pettersen (Developer Opera Software ASA); > >> ; Nikos Mavrogiannopoulos > >> Subject: Re: [TLS] WGLC for > > draft-ietf-tls-multiple-cert-status-extension-02 > >> > >> I don't see a valid case for the client to continue if the response > >> is > > valid and > >> indicates revoked. Since unknown is a valid OCSP response I don't think > > we > >> should forbid it. In cases where the response is inconclusive it is > >> up to > > the > >> client to determine how to proceed. The client may choose to allow the > >> connection to complete in the case that it believes it will have the > >> opportunity to check the validity of the certificate through another > > means. > >> Such an example would be in the case of EAP-TLS where the client may > >> use a different method of revocation check when it has network > >> access. However the client MUST NOT engage in activities with the > >> server that require > > trust in > >> the validity of the certificate until the certificate has been validated. > > For > >> example, a client MUST not disclose username and password information > >> until it has fully validated the validity of the server certificate. > >> > >> Here is an attempt at some suggested text: > >> > >> "Clients requesting an OCSP response and receiving one or more OCSP > >> responses in a "CertificateStatus" message MUST check the OCSP > >> response(s) and abort the handshake if the response is a revoked > >> status with a bad_certificate_status_response(113) alert. This alert > >> is always fatal. If the response is inconclusive then the client > >> MAY decide to > > allow the > >> connection if it believes it will have the opportunity to check the > > validity > >> of the certificate through another means. The client MUST about the > >> connection if it needs to engage in activities that require trust > >> in > > the server > >> and the server certificate has not been sufficiently validated. An > >> example of where the client may wish to continue is with EAP-TLS > >> where the client can use another mechanism to check the status of a > >> certificate once it obtains network access. In this case the client > >> may continue withe handshake, but it would be inappropriate for the > >> client to disclose a username and password until it has fully > >> validated the validity of the server certificate." > >> > >> > >> Thanks, > >> > >> Joe > >> > >> > >> On Dec 2, 2012, at 10:39 AM, Piyush Jain wrote: > >> > >>> Please see inline. > >>> > >>>> -----Original Message----- > >>>> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf > >>>> Of Yngve N. Pettersen (Developer Opera Software ASA) > >>>> Sent: Sunday, December 02, 2012 9:04 AM > >>>> To: tls@ietf.org; Nikos Mavrogiannopoulos > >>>> Subject: Re: [TLS] WGLC for > >>> draft-ietf-tls-multiple-cert-status-extension-02 > >>>> > >>>> Hi, > >>>> > >>>> As I said last time you raised this issue, it is the same > >>>> requirement as > >>> RFC 6066 > >>>> sets for the > >>>> original Certificate Status extension. I also think it is proper to > >>>> have such a requirement, because it defines how the data should be > >>>> handled and acted upon, and collects the information in a single > >>>> document, so it is not > >>> necessary > >>>> to chase one document after another to discover all the proper actions. > >>> > >>> > >>> [Piyush] 6066 does not cover multiple cert status extension. > >>> Multiple-cert-status extension is being proposed to address the > >>> limitations of original certificate status request actions. So any > >>> improvements in how the response should be handled can be part of > >>> the new documents > >>>> > >>>> This requirement clearly indicates that *if* a client request this > >>> extension, > >>>> then it MUST verify the result, and act on the result in a secure > > fashion. > >>> That > >>>> is, only proceed if the response is "good", and abort in other cases. > >>>> (If > >>> a client > >>>> does not want to process and act on the information, it can avoid > >>>> doing so > >>> by > >>>> not sending the extension support indication to the server; sending > >>>> the extension is a declaration that the client accepts and will act > >>>> upon the returned information in a fashion that protects the user.) > >>>> > >>> [Piyush] I agree that if the response indicates that certificate is > >>> bad, the handshake should be terminated. However, absence of 'good' > >>> does not imply 'bad' in OCSP. Good and revoked are the only > >>> authoritative responses in OCSP. Any other response is > >>> non-authoritative. This implies that for responses other than good > >>> or revoked, client should try to find the status using other means > >>> before considering the certificate good or bad. Here are the other > >>> possible > >> scenarios. > >>> - Unknown response. Not interesting because TLs servers should be > >>> smart enough to not include unknown response. However, I'm surprised > >>> that this draft does not explicitly states that tls server must not > >>> include unknown OCSP response (or unsigned OCSP responses) in > >>> status- > >> request message. > >>> - Response not understood by client, typically because it is signed > >>> using a hashing/signing algorithm that client did not understand. It > >>> does not make sense for the client to abort the handshake in such > >>> cases. The client should try to obtain the certificate status using > > other > >> means. > >>> > >>>> The server have the option to not forward a response in case it is > >>>> bad, in which case the client should fetch the response on its own. > >>>> If the > >>> forwarded > >>>> response is bad, then the client have to act on it, and terminate > >>>> the connection. > >>>> > >>> [Piyush] Good point. I think the draft should call it out explicitly > >>> and prohibit the server to send any response that it thinks is not > >>> authoritative. > >>>> A client that proceeds despite seeing either bad data or a revoked > >>>> status > >>> are > >>>> IMO not conformant, and will IMO also have a security vulnerability. > >>>> > >>> [Piyush] Agree if the status is revoked. Bad data is too generic. > >>> Please look at the scenario mentioned above. > >>>> > >>>> As this language was not just acceptable to the Working Group for > >>>> RFC > >>> 6066, > >>>> but the WG actually approved that 6066 added the alert message > >>>> requirement, which was not present in either RFC 4366 or RFC 3546, > >>>> my opinion is that the WG have so far clearly and repeatedly stated > >>>> its > >>> opinion > >>>> on this matter, and I therefore plan to leave this text in. > >>>> > >>> > >>>> On Sun, 02 Dec 2012 09:28:10 +0100, Nikos Mavrogiannopoulos > >>>> wrote: > >>>> > >>>>> On 11/16/2012 06:08 PM, Joseph Salowey (jsalowey) wrote: > >>>>> > >>>>>> This is a working group last call for > >>>>>> draft-ietf-tls-multiple-cert-status-extension-02 on "The TLS > >>>>>> Multiple Certificate Status Request Extension". The draft is > > available > >> here: > >>>>>> > >>>>>> http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-ex > >>>>>> te > >>>>>> ns > >>>>>> ion-02 Please send you comments to the TLS list by December 17, > >>>>>> 2012. > >>>>> > >>>>> I pretty much repeat the point originally made in: > >>>>> http://www.ietf.org/mail-archive/web/tls/current/msg08973.html > >>>>> > >>>>> The text: > >>>>> "Clients requesting an OCSP response and receiving one or more > >>>>> OCSP responses in a "CertificateStatus" message MUST check the > >>>>> OCSP > >>>>> response(s) and abort the handshake, if the response is a revoked > >>>>> status or is otherwise not satisfactory with a > >>>>> bad_certificate_status_response(113) alert. This alert is always > >>>>> fatal." > >>>>> > >>>>> is very strict and IMO not applicable in this document since this > >>>>> document is not about a verification profile. What if a client > >>>>> decides to proceed with the handshake even if the status is revoked? > >>>>> Or if an implementation when it detects junk in this extension > >>>>> (due to a server > >>>>> misconfiguration) decides to ignore it instead of aborting. > >>>>> > >>>>> Should that make the clients non-conformant to the > >>>>> multiple-cert-status-extension? > >>>>> > >>>>> regards, > >>>>> Nikos > >>>>> _______________________________________________ > >>>>> TLS mailing list > >>>>> TLS@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/tls > >>>> > >>>> > >>>> -- > >>>> Sincerely, > >>>> Yngve N. Pettersen > >>>> > >> > ********************************************************** > >>>> ********** > >>>> Senior Developer Email: yngve@opera.com > >>>> Opera Software ASA http://www.opera.com/ > >>>> Phone: +47 96 90 41 51 Fax: +47 23 69 24 01 > >>>> > >> > ********************************************************** > >>>> ********** > >>>> _______________________________________________ > >>>> TLS mailing list > >>>> TLS@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/tls > >>> > >>> _______________________________________________ > >>> TLS mailing list > >>> TLS@ietf.org > >>> https://www.ietf.org/mailman/listinfo/tls > > > > From turners@ieca.com Mon Dec 17 09:07:03 2012 Return-Path: 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 10EEF21F8B46 for ; Mon, 17 Dec 2012 09:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.953 X-Spam-Level: X-Spam-Status: No, score=-101.953 tagged_above=-999 required=5 tests=[AWL=0.312, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 p3FWhyxjA+8E for ; Mon, 17 Dec 2012 09:07:02 -0800 (PST) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [69.93.164.2]) by ietfa.amsl.com (Postfix) with ESMTP id 83E4B21F87C5 for ; Mon, 17 Dec 2012 09:07:02 -0800 (PST) Received: by gateway04.websitewelcome.com (Postfix, from userid 5007) id 0BE97C3FE4C85; Mon, 17 Dec 2012 11:07:00 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway04.websitewelcome.com (Postfix) with ESMTP id EEA6CC3FE4BFE for ; Mon, 17 Dec 2012 11:06:59 -0600 (CST) Received: from [108.45.19.185] (port=57907 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1Tke9d-0001dF-Qm; Mon, 17 Dec 2012 11:07:01 -0600 Message-ID: <50CF5135.8060504@ieca.com> Date: Mon, 17 Dec 2012 12:07:01 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Paul Wouters References: <5094553B.5060009@gnutls.org> <078C4585-EFCF-4871-B8AE-C5BBDDB90536@gmx.net> <509927C4.1070404@gnutls.org> <50992DBB.60406@edelweb.fr> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.45.19.185]:57907 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 2 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: tls@ietf.org Subject: Re: [TLS] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 17:07:03 -0000 On 11/6/12 10:55 AM, Paul Wouters wrote: > On Tue, 6 Nov 2012, Peter Sylvester wrote: > >> - What does is the problem to make the definitions compatible >> i.e. define a value for pgp? > > I believe the problem was that 6091 was not a standards track document. Yep that's it. >> - Besides that, a public key is not exactly a "certificate" type? > > It is how the TLS WG preferred the raw public key format to be > supported. I actually asked around if others really cared about this. There was some grumbling but it didn't rise to the level of this is so broken please define a new extension type or I'd put a discuss on about this. spt >> - How would one add a sunrise hash chain as a new certificate type? > > One would not. If the rae public key certificate format does not satisfy > your needs, use the existing PKIX certificate, or create a new > certificate type? > > Paul > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From n.mavrogiannopoulos@gmail.com Mon Dec 17 13:01:43 2012 Return-Path: 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 A07FA21F8861 for ; Mon, 17 Dec 2012 13:01:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 Rk6XCvA4LS6a for ; Mon, 17 Dec 2012 13:01:42 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id BE51E21F87BD for ; Mon, 17 Dec 2012 13:01:42 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id c13so9980305ieb.31 for ; Mon, 17 Dec 2012 13:01:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=dMjNLvSB5UpcTzTS5+3TFicP7b2PWNQrVMlCb8+trqk=; b=XZIeE+vfSShe14NAgMa72X0bSH8vMzNe1qNJ1vR4HYfQsJ+hACTeokro0EssnzoIfn sJ/jfeJ+gQNEQi4EmEcY1+BC836JbyQLJFHq1Klabl3rVo+Ct1q2hIp3H7yJBdpSPTOb M77gyemie0wsc7r9CGrR7ftZakJGXyuvr6wHEAK9mdHaMo9i5hKRTPmTYx8ucdDX8s0+ Jw/u97llA/6kKht9sFJ5pIaS3wEXjJdb2nyxDwQO20YeV7pB3rsy1bNJWuWxbLweoE7y UplXNM4/kIRp4YNQGiEiS3PVXj0Th3ilJ08tSW7FuujTB2i9HH4ZJOiLbIY2e2G+YEH5 /n0w== MIME-Version: 1.0 Received: by 10.50.33.233 with SMTP id u9mr10559907igi.39.1355778102393; Mon, 17 Dec 2012 13:01:42 -0800 (PST) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.64.53.98 with HTTP; Mon, 17 Dec 2012 13:01:42 -0800 (PST) In-Reply-To: <50CF5135.8060504@ieca.com> References: <5094553B.5060009@gnutls.org> <078C4585-EFCF-4871-B8AE-C5BBDDB90536@gmx.net> <509927C4.1070404@gnutls.org> <50992DBB.60406@edelweb.fr> <50CF5135.8060504@ieca.com> Date: Mon, 17 Dec 2012 23:01:42 +0200 X-Google-Sender-Auth: qgcZhlK1mMexfIeJXFuqgt9tA6U Message-ID: From: Nikos Mavrogiannopoulos To: Sean Turner Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 21:01:43 -0000 On Mon, Dec 17, 2012 at 7:07 PM, Sean Turner wrote: >>> - What does is the problem to make the definitions compatible >>> i.e. define a value for pgp? >> I believe the problem was that 6091 was not a standards track document. > Yep that's it. I don't understand how this can be a reason to have a deliberate incompatibility with its certificate type registry. If 6091 isn't standards track the new standards track can adopt the registry and augment it (unless there is a technical reason for not to --which isn't the case). As I mention in http://www.ietf.org/mail-archive/web/tls/current/msg09093.html it is very easy to re-use the previous certificate type definitions/registry. In fact this would simplify the current raw pubkey draft, by (a) not using the accept/offer negotiation which requires different interpretation of certificate types depending on whether a client or server is reading a message (a foreign negotiation to TLS), and (b) there is no need for a new registry. regards, Nikos From jsalowey@cisco.com Mon Dec 17 13:23:57 2012 Return-Path: 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 ED85821F876B for ; Mon, 17 Dec 2012 13:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 oT8jMpBCwlEM for ; Mon, 17 Dec 2012 13:23:57 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 3AE9521F86FC for ; Mon, 17 Dec 2012 13:23:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1677; q=dns/txt; s=iport; t=1355779437; x=1356989037; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=D97ghIvROzBRBRTzMxzbS4kv1TiBMBihGhcdAzTLhxk=; b=mOB/G5vN0+KQRN8pWF1fugIyyft4Wu7E134rEFinMXx2YFVcYDVE5ble ke7GAxdpKnCxquyHRdiw10JZPtpgHDYbjwoSOWMoID2dLuSaLtbq1CvbU asUekwd+3JWAs+g75capvD8sisNqu3vn5ow3l+50NsGOyxqlSmUGZxAx0 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAA6Nz1CtJV2d/2dsb2JhbABFvicWc4IeAQEBAwEBAQE3NAsFCwIBCBgKFBAnCyUCBA4FCAGIBAYMuiSMXRuDR2EDplKCc4FtNQ X-IronPort-AV: E=Sophos;i="4.84,304,1355097600"; d="scan'208";a="153921210" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 17 Dec 2012 21:23:56 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id qBHLNuPD022098 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 17 Dec 2012 21:23:56 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.13]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.02.0318.004; Mon, 17 Dec 2012 15:23:56 -0600 From: "Joseph Salowey (jsalowey)" To: Nikos Mavrogiannopoulos Thread-Topic: [TLS] draft-ietf-tls-oob-pubkey-06 Thread-Index: AQHN3Jm6ABKwdQcCo0qZc6PoH6mPYpgd5QSA Date: Mon, 17 Dec 2012 21:23:55 +0000 Message-ID: References: <5094553B.5060009@gnutls.org> <078C4585-EFCF-4871-B8AE-C5BBDDB90536@gmx.net> <509927C4.1070404@gnutls.org> <50992DBB.60406@edelweb.fr> <50CF5135.8060504@ieca.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.61] Content-Type: text/plain; charset="us-ascii" Content-ID: <7D0A26D85E1D0047A72939B6978ACFF0@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [TLS] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 21:23:58 -0000 Hi Sean, I don't think the document would need to reference 6091, it would just need= to reference the named registry. Is there a problem with a standards trac= k RFC reference a registry established by an informational document? Accord= ing to the IANA assignment rules in 6091 a new RFC could update the regist= ry with new values.=20 Thanks, Joe On Dec 17, 2012, at 1:01 PM, Nikos Mavrogiannopoulos wrote: > On Mon, Dec 17, 2012 at 7:07 PM, Sean Turner wrote: >>>> - What does is the problem to make the definitions compatible >>>> i.e. define a value for pgp? >>> I believe the problem was that 6091 was not a standards track document. >> Yep that's it. >=20 > I don't understand how this can be a reason to have a deliberate > incompatibility with its certificate type registry. If 6091 isn't > standards track the new standards track can adopt the registry and > augment it (unless there is a technical reason for not to --which > isn't the case). >=20 > As I mention in > http://www.ietf.org/mail-archive/web/tls/current/msg09093.html it is > very easy to re-use the previous certificate type > definitions/registry. In fact this would simplify the current raw > pubkey draft, by (a) not using the accept/offer negotiation which > requires different interpretation of certificate types depending on > whether a client or server is reading a message (a foreign negotiation > to TLS), and (b) there is no need for a new registry. >=20 > regards, > Nikos > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From turners@ieca.com Mon Dec 17 13:28:42 2012 Return-Path: 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 ACBFE21F8548 for ; Mon, 17 Dec 2012 13:28:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.974 X-Spam-Level: X-Spam-Status: No, score=-101.974 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 nge3GyR8rrpx for ; Mon, 17 Dec 2012 13:28:42 -0800 (PST) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [69.93.243.15]) by ietfa.amsl.com (Postfix) with ESMTP id 3331A21F84F6 for ; Mon, 17 Dec 2012 13:28:42 -0800 (PST) Received: by gateway14.websitewelcome.com (Postfix, from userid 5007) id DB595B5589EDD; Mon, 17 Dec 2012 15:28:40 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway14.websitewelcome.com (Postfix) with ESMTP id CBAE4B5589E9D for ; Mon, 17 Dec 2012 15:28:40 -0600 (CST) Received: from [108.45.19.185] (port=60805 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TkiEr-0007js-87; Mon, 17 Dec 2012 15:28:41 -0600 Message-ID: <50CF8E87.3070405@ieca.com> Date: Mon, 17 Dec 2012 16:28:39 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" References: <5094553B.5060009@gnutls.org> <078C4585-EFCF-4871-B8AE-C5BBDDB90536@gmx.net> <509927C4.1070404@gnutls.org> <50992DBB.60406@edelweb.fr> <50CF5135.8060504@ieca.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.45.19.185]:60805 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "" Subject: Re: [TLS] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 21:28:42 -0000 Joe, I can think problem to a standards track document assigning values i to a registry created by a non-standards track document. spt On 12/17/12 4:23 PM, Joseph Salowey (jsalowey) wrote: > Hi Sean, > > I don't think the document would need to reference 6091, it would just need to reference the named registry. Is there a problem with a standards track RFC reference a registry established by an informational document? According to the IANA assignment rules in 6091 a new RFC could update the registry with new values. > > Thanks, > > Joe > > > On Dec 17, 2012, at 1:01 PM, Nikos Mavrogiannopoulos > wrote: > >> On Mon, Dec 17, 2012 at 7:07 PM, Sean Turner wrote: >>>>> - What does is the problem to make the definitions compatible >>>>> i.e. define a value for pgp? >>>> I believe the problem was that 6091 was not a standards track document. >>> Yep that's it. >> >> I don't understand how this can be a reason to have a deliberate >> incompatibility with its certificate type registry. If 6091 isn't >> standards track the new standards track can adopt the registry and >> augment it (unless there is a technical reason for not to --which >> isn't the case). >> >> As I mention in >> http://www.ietf.org/mail-archive/web/tls/current/msg09093.html it is >> very easy to re-use the previous certificate type >> definitions/registry. In fact this would simplify the current raw >> pubkey draft, by (a) not using the accept/offer negotiation which >> requires different interpretation of certificate types depending on >> whether a client or server is reading a message (a foreign negotiation >> to TLS), and (b) there is no need for a new registry. >> >> regards, >> Nikos >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > From turners@ieca.com Mon Dec 17 13:33:16 2012 Return-Path: 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 16A4121F8550 for ; Mon, 17 Dec 2012 13:33:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.984 X-Spam-Level: X-Spam-Status: No, score=-101.984 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] 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 rRzR02seJZ-6 for ; Mon, 17 Dec 2012 13:33:15 -0800 (PST) Received: from gateway11.websitewelcome.com (gateway11.websitewelcome.com [69.93.35.30]) by ietfa.amsl.com (Postfix) with ESMTP id 921ED21F84E6 for ; Mon, 17 Dec 2012 13:33:15 -0800 (PST) Received: by gateway11.websitewelcome.com (Postfix, from userid 5011) id D4A92BF3AF66C; Mon, 17 Dec 2012 15:33:11 -0600 (CST) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway11.websitewelcome.com (Postfix) with ESMTP id C4CF0BF3AF623 for ; Mon, 17 Dec 2012 15:33:11 -0600 (CST) Received: from [108.45.19.185] (port=60809 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1TkiJG-0001Kc-4M; Mon, 17 Dec 2012 15:33:14 -0600 Message-ID: <50CF8F99.5040501@ieca.com> Date: Mon, 17 Dec 2012 16:33:13 -0500 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" References: <5094553B.5060009@gnutls.org> <078C4585-EFCF-4871-B8AE-C5BBDDB90536@gmx.net> <509927C4.1070404@gnutls.org> <50992DBB.60406@edelweb.fr> <50CF5135.8060504@ieca.com> <50CF8E87.3070405@ieca.com> In-Reply-To: <50CF8E87.3070405@ieca.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [108.45.19.185]:60809 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 4 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Cc: "" Subject: Re: [TLS] 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Dec 2012 21:33:16 -0000 Trying once again... I can't think of a problem for a standards track document assigning values in a registry created by a non-standards track document. spt On 12/17/12 4:28 PM, Sean Turner wrote: > Joe, > > I can think problem to a standards track document assigning values i to > a registry created by a non-standards track document. > > spt > > On 12/17/12 4:23 PM, Joseph Salowey (jsalowey) wrote: >> Hi Sean, >> >> I don't think the document would need to reference 6091, it would just >> need to reference the named registry. Is there a problem with a >> standards track RFC reference a registry established by an >> informational document? According to the IANA assignment rules in >> 6091 a new RFC could update the registry with new values. >> >> Thanks, >> >> Joe >> >> >> On Dec 17, 2012, at 1:01 PM, Nikos Mavrogiannopoulos >> wrote: >> >>> On Mon, Dec 17, 2012 at 7:07 PM, Sean Turner wrote: >>>>>> - What does is the problem to make the definitions compatible >>>>>> i.e. define a value for pgp? >>>>> I believe the problem was that 6091 was not a standards track >>>>> document. >>>> Yep that's it. >>> >>> I don't understand how this can be a reason to have a deliberate >>> incompatibility with its certificate type registry. If 6091 isn't >>> standards track the new standards track can adopt the registry and >>> augment it (unless there is a technical reason for not to --which >>> isn't the case). >>> >>> As I mention in >>> http://www.ietf.org/mail-archive/web/tls/current/msg09093.html it is >>> very easy to re-use the previous certificate type >>> definitions/registry. In fact this would simplify the current raw >>> pubkey draft, by (a) not using the accept/offer negotiation which >>> requires different interpretation of certificate types depending on >>> whether a client or server is reading a message (a foreign negotiation >>> to TLS), and (b) there is no need for a new registry. >>> >>> regards, >>> Nikos >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >> >> > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From jsalowey@cisco.com Mon Dec 17 22:39:52 2012 Return-Path: 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 0DAAB21F8B03 for ; Mon, 17 Dec 2012 22:39:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 g68rSNxbITsJ for ; Mon, 17 Dec 2012 22:39:50 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 2D78C21F889C for ; Mon, 17 Dec 2012 22:39:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12039; q=dns/txt; s=iport; t=1355812790; x=1357022390; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=YKEeJ8u2eGpo8LYQSfAE1ohIPwBKjq4dnvLJLw3/VV8=; b=O4xNX8i6YOg27uRhG9ZNr3fseYjVHPxuiXfx95xTRAHx451YPUI9AGTs T1cWzoaE5Tab9Q9gr4t/McseWrJI6WzNEPM1SCQrbSh8M+PhyAiKGf7h5 rY9QeaEDhpjaYEFuantqlD4BoEnIGSn6c7THK/1t6z4tYTh18ceWWPD3S A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAPIN0FCtJXHB/2dsb2JhbABFvjEWc4IeAQEBAwEBAQE3NAsFBwQCAQgRBAEBAQoUCQcnCxQJCAIEDgUIE4dyBgyqEJA6BIxRFQGDTGEDplKCc4FkAQYZHg X-IronPort-AV: E=Sophos;i="4.84,307,1355097600"; d="scan'208";a="154023729" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 18 Dec 2012 06:39:49 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id qBI6dne4025829 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Dec 2012 06:39:49 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.13]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Tue, 18 Dec 2012 00:39:49 -0600 From: "Joseph Salowey (jsalowey)" To: Piyush Jain Thread-Topic: [TLS] Comments on the cached-info draft Thread-Index: AQF3e5H6UQk+zS8c+cqnHbkeZekMDwF8Im8SmLyuNzCAANXWgIAAMhKAgAGrLYA= Date: Tue, 18 Dec 2012 06:39:48 +0000 Message-ID: References: <027d01cddbc5$71dc36b0$5594a410$@ditenity.com> <031101cddc14$e20b9940$a622cbc0$@ditenity.com> In-Reply-To: <031101cddc14$e20b9940$a622cbc0$@ditenity.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.61] Content-Type: text/plain; charset="us-ascii" Content-ID: <6F06B2E7523A9B47BE2E79DEDBAF2970@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [TLS] Comments on the cached-info draft 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 06:39:52 -0000 Thanks, this helps, some questions and comments below: On Dec 16, 2012, at 9:10 PM, Piyush Jain wrote: > Sorry for being unclear on the last part. Let me try again. >=20 > The current text requires that the server returns the cached objects as a= n > extension in server hello. The reason cited is that the server tells the > client which cached objects are understood by the server. > These objects could be one of certificate chain, CA DN and possibly OCSP > multi status. >=20 > TLS requires that CA DN be sent in Client Certificate request message, > server certificate chain be sent in Certificate message and OCSP status b= e > sent in Certificate status message. >=20 > Stefan's proposal is that since all the cached objects are sent back in > Server hello, there is no need to send cert chain cache objects in Server > Certificate message or cached OCSP in Certificate Status message. >=20 > I think that we can do away with the requirement of returning any cached > object as server hello extension. > Here are the steps > -The client sends the list of cache objects in client hello. > -Server DOES NOT acknowledge any cached objects via hello extension > - Server sends cached cert chain as part of certificate_list in Server > Certificate message ( allowed - ASN.1Cert is defined as opaque in TLS) > -Server Sends cached multi ocsp responses as part of Certificate status > message ( allowed - OCSResponse is defined as opaque in multi-status draf= t) > - Server sends cached ca dns as part of client certificate request messag= e. > (allowed - distinguished name is defined as opaque in TLS) >=20 > The point is that there is no benefit of explicitly telling the client wh= at > cached objects server understands as part of server hello message > =20 > Server can use the cached object specified by the client on as needed bas= is. > This way we also avoid the situation where the cached objects are sent to > the client twice. >=20 > This way you do not need to bundle all the information in server hello an= d > pass the data only when it is required by the relevant TLS message and > obviates the need for client and server to do any preprocessing to figure > out which cached objects are sent during the hello message. >=20 [Joe] The client would still need to do some processing to determine which= hash to send in the client hello.=20 > Can you think of any issues with not sending the cached objects in server > hello extension? >=20 [Joe] Its not clear to me that the server needs to send the hashes of the= cached objects at all. The server does not need to tell the client the va= lue of the hash of the data is since the client sent it in the client hello= . It just needs to be able to unambiguously determine if the server is usi= ng that cached data or providing a different set of data. If we go with = just omitting the data there may be some ambiguity between an empty message= representing cached data and an empty message representing something else.= To remove this ambiguity the server could just send an enumeration of th= e cached object types it accepted in the hello extension (the semantics fo= r the server hello extension in the current draft may be different). =20 > Thanks > -Piyush >=20 >> -----Original Message----- >> From: Joseph Salowey (jsalowey) [mailto:jsalowey@cisco.com] >> Sent: Sunday, December 16, 2012 6:12 PM >> To: Piyush Jain >> Cc: Stefan Santesson; >> Subject: Re: [TLS] Comments on the cached-info draft >>=20 >>=20 >> On Dec 16, 2012, at 11:42 AM, Piyush Jain wrote: >>=20 >>> Just a few comments >>> - As thought previously, the existing text does not violate TLS. TLS >>> defines ASN.1Cert as opaqe and certificate_list as list of ASN.1Cert. >>> So you can include a list of cached objects in certificate message. >>=20 >> [Joe] While this is true for the certificate chain, is it true for othe= r > types of >> data that may be cached as well? would this work for distinguished name= s >> for trusted_cas or for the multi-OCSP status response we have been >> discussing? I'm a little concerned that it might not work in all cases. > Since the >> cached info type has to be explicitly defined it would be sufficient tha= t > it >> works with the types that are likely to be useful to cache. >>=20 >>> - The benefit of the new proposal is that it avoids sending of >>> information that was already sent in server hello. >>> - The con is that it bundles the content of server certificate message >>> in server hello and requires some preprocessing on server and client >>> in terms of selecting which cached object to send as part of server > hello. >>=20 >> [Joe] I'm leaning towards it being simpler to omit the hash if possible= . >>=20 >>> So the question is : What is the benefit of sending the cached object >>> extension as part of server hello? The server can avoid sending this >>> extension in server hello and just send the cached object(s) as part >>> of the certificate message. >>>=20 >>=20 >> [Joe] I'm not sure I follow you here. The server needs to know what the >> client has cached so it can tell if it needs to send the hash or the > actual data. >>=20 >>> -Piyush >>>=20 >>>> -----Original Message----- >>>> From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of >>>> Joseph Salowey (jsalowey) >>>> Sent: Saturday, December 15, 2012 5:11 PM >>>> To: Stefan Santesson >>>> Cc: >>>> Subject: Re: [TLS] Comments on the cached-info draft >>>>=20 >>>> Are there any objections to: >>>>=20 >>>> a) Stefan's new proposal to omit the cached data >>>>=20 >>>>=20 >>>> b) Accommodating a cached intermediate chain so only the end-entity >>>> certificate needs to be sent. >>>>=20 >>>>=20 >>>>=20 >>>> Thanks, >>>>=20 >>>> Joe >>>>=20 >>>> On Dec 5, 2012, at 12:59 AM, Stefan Santesson >>>> wrote: >>>>=20 >>>>> Hi Joe, >>>>>=20 >>>>> I can't see the functionality being limited in any important way. >>>>> In fact, as mentioned below, I see that it actually opens up new >>>>> opportunities if you don't have to force the cached hash into >>>>> existing handshake messages. >>>>>=20 >>>>>=20 >>>>> Regarding caching of partial chain: >>>>> If the group feels that it would be compliant with section 7.4.2 of >>>>> TLS 1.2, I guess that you could allow the server to send just the >>>>> end certificate if the client in a new CahcedInformationType has >>>>> sent over a matching hash of the chain (excluding the server cert) >>>>> that the this server usually sends together with the server > certificate. >>>>>=20 >>>>> This is actually much easier to accommodate if we go for the cleaner >>>>> solution to just omit cached data in hs messages. This would have >>>>> been semantically horrific if we would mix the server certificate >>>>> with a hash of the cached chain in the same opaque blob. >>>>>=20 >>>>> /Stefan >>>>>=20 >>>>>=20 >>>>> On 11/28/12 6:19 AM, "Joseph Salowey (jsalowey)" >>>>> >>>>> wrote: >>>>>=20 >>>>>> Hi Stefan, >>>>>>=20 >>>>>> This new proposal of omitting the data sounds a bit simpler to me. >>> You >>>>>> say the new approach will limit the functionality in some way. In >>>>>> what way is it limited? >>>>>>=20 >>>>>> Do you think we could accommodate the case where the endpoint has >>>>>> intermediate CA certificates cached but not the end entity > certificate? >>>>>> This would require parsing the certificate message, but the response >>>>>> could just omit the certs that were indicated in the cachedInfo. > The >>>>>> parsing of the cert message is a bit more complex, but it could >>>>>> satisfy some of the use cases discussed at the meeting. >>>>>>=20 >>>>>> Thanks, >>>>>>=20 >>>>>> Joe >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On Nov 7, 2012, at 7:42 AM, Stefan Santesson wrote: >>>>>>=20 >>>>>>> It was quite a while since I wrote the first version of this draft. >>>>>>> Now that I bring it up to my attention I found a problem that I >>>>>>> think should be fixed. >>>>>>>=20 >>>>>>> After a close examination I'm convinced that the current spec >>>>>>> breaks TLS. >>>>>>>=20 >>>>>>>=20 >>>>>>> The current approach is to exchange support for cached-info in >>>>>>> client and server hellos. >>>>>>> This includes hashes for cached objects (clients) and confirmation >>>>>>> of cached objects (server). >>>>>>>=20 >>>>>>> In addition to this, this protocol allows the cached data in >>>>>>> handshake messages to be swapped with cached object hashes. >>>>>>> This is a violation of the syntax of these handshake messages. >>>>>>>=20 >>>>>>> Take the Certificate handshake message for example. The spec >>>>>>> suggest here to replace the certificate_list vector to be replaced >>>>>>> with a vector of CachedObejct structured data. >>>>>>> This breaks the syntax of this handshake message. A strict >>>>>>> processing of the certificate_list vector will expect an ASN.1 >>>>>>> encoded binary containing a sequence of certificates, not a vector >>>>>>> of data objects according to the CachedObject structure. >>>>>>>=20 >>>>>>> My first thought was that we actually need a new handshake >> message. >>>>>>> However that is not helpful either. >>>>>>> The TLS spec require the Certificate handshake message to be sent >>>>>>> in case the chosen cipher suite demands it, so it MUST be sent. >>>>>>> It can't be replaced by another handshake message. >>>>>>>=20 >>>>>>> My current belief is that we simply should omit the cached data, >>>>>>> and that each cachedInfo type need to defined how to omit cached >> data. >>>>>>>=20 >>>>>>> In case of the certificate handshake message, the certificate list >>>>>>> should be replaced with an empty sequence. >>>>>>>=20 >>>>>>>=20 >>>>>>> There is actually no need to send the hash of the cached data in >>>>>>> the handshake message. Not if the confirmation of the cached info >>>>>>> is exchanged in the server hello. Sending the hash once more in >>>>>>> the handshake message is then redundant. >>>>>>>=20 >>>>>>>=20 >>>>>>> So I propose the following: >>>>>>>=20 >>>>>>> 1) Clients send hashes of cached objects in client hello. >>>>>>> 2) Server responds with one or zero hashes per cachedInfo type, >>>>>>> that >>>>>>> a) matches a cached object sent by the client b) will be omitted >>>>>>> by the server in the corresponding handshake message. >>>>>>> 3) How information is omitted from the handshake message is >>>>>>> defined per cached info type. For the current defined 2 types this > is: >>>>>>> A) cached certificate cahins in Certificate: replace the sequence >>>>>>> of certificates with an empty sequence. >>>>>>> B) certificate_authorities in Certificate Request: Send an empty >>>>>>> list of DistinguishedName >>>>>>> 4) Clients will act as if the cached objects (confirmed in server >>>>>>> hello) were sent in the handshake messages. >>>>>>> 5) Everything else according to the current spec >>>>>>>=20 >>>>>>>=20 >>>>>>> The proposed approach will somewhat limit the functionality of the >>>>>>> current spec, but it ads value in simplicity. >>>>>>> I can't imagine a valid use case that would not be covered by this >>>>>>> change, but I might overlook something. >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> _______________________________________________ >>>>>>> TLS mailing list >>>>>>> TLS@ietf.org >>>>>>> https://www.ietf.org/mailman/listinfo/tls >>>>>>=20 >>>>>=20 >>>>>=20 >>>>=20 >>>> _______________________________________________ >>>> TLS mailing list >>>> TLS@ietf.org >>>> https://www.ietf.org/mailman/listinfo/tls >>>=20 >=20 >=20 From mrex@sap.com Mon Dec 17 23:20:44 2012 Return-Path: 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 A515321F85C6 for ; Mon, 17 Dec 2012 23:20:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.119 X-Spam-Level: X-Spam-Status: No, score=-10.119 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] 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 ZIax9agTF0NS for ; Mon, 17 Dec 2012 23:20:44 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id B785B21F8ADD for ; Mon, 17 Dec 2012 23:20:43 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id qBI7KcAO027683 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 18 Dec 2012 08:20:38 +0100 (MET) In-Reply-To: To: "Joseph Salowey (jsalowey)" Date: Tue, 18 Dec 2012 08:20:38 +0100 (CET) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20121218072038.7A3071A3FF@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "" Subject: Re: [TLS] Comments on the cached-info draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 07:20:44 -0000 Joseph Salowey (jsalowey) wrote: > > > Can you think of any issues with not sending the cached objects in server > > hello extension? > > [Joe] Its not clear to me that the server needs to send the hashes > of the cached objects at all. The server does not need to tell the > client the value of the hash of the data is since the client sent it > in the client hello. It just needs to be able to unambiguously > determine if the server is using that cached data or providing a > different set of data. If we go with just omitting the data there > may be some ambiguity between an empty message representing cached > data and an empty message representing something else. To remove this > ambiguity the server could just send an enumeration of the cached > object types it accepted in the hello extension (the semantics for > the server hello extension in the current draft may be different). The certificate_authorities list in the CertificateRequest handshake message is one such element, where omitting already has a valid protocol meaning (at least in TLSv1.1+), and this field also allows "small" values, potentially of the size of a hash value, so disambituation appears to be necessary. -Martin From piyush@ditenity.com Tue Dec 18 07:53:26 2012 Return-Path: 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 A463721F84E7 for ; Tue, 18 Dec 2012 07:53:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.584 X-Spam-Level: X-Spam-Status: No, score=-3.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 El3CiVUEFvVY for ; Tue, 18 Dec 2012 07:53:26 -0800 (PST) Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) by ietfa.amsl.com (Postfix) with ESMTP id 238F421F8AA6 for ; Tue, 18 Dec 2012 07:53:25 -0800 (PST) Received: by mail-ob0-f174.google.com with SMTP id ta14so788561obb.5 for ; Tue, 18 Dec 2012 07:53:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language:x-gm-message-state; bh=XEEHF+kVPQLZNZzkO8XAHp4ozJkMEcygXekyMzrwjpo=; b=bn4R+jenp2ymVgKKtTrOFfXhqpbjT7bnW4zgXk8hLmgGDW7tgOIQDuXHzzL8X3lqx/ uxkWzdpExHmwpH6IOxRJbd7NObudx4rxIbLvS/ksEbBbbjzMSdt+8GD7npIfOZ02Jffi wM3HQ+j5FERW0TD+Acr2+RalzguoLEYfqbxz2zXeiZw+K3EU5F4csp4yfkPL9i/B+Ztu kdcChqULy0QjUEHuQ6Vomoy8X8VxMSFkwYrvOvsJvUM4MMFX58QwgVQnEZwMC62St/mP XlkXMQiiQwACxBevcCUlOWD5QLJFqJrRk187YG3dqIJt6YutzXCK/xQm6oc+eKnxYMpZ uPrA== X-Received: by 10.60.32.37 with SMTP id f5mr1957541oei.19.1355846005522; Tue, 18 Dec 2012 07:53:25 -0800 (PST) Received: from hp13 (75-25-128-241.lightspeed.sjcpca.sbcglobal.net. [75.25.128.241]) by mx.google.com with ESMTPS id h13sm1375749obp.2.2012.12.18.07.53.24 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 18 Dec 2012 07:53:24 -0800 (PST) From: "Piyush Jain" To: "'Joseph Salowey \(jsalowey\)'" References: <027d01cddbc5$71dc36b0$5594a410$@ditenity.com> <031101cddc14$e20b9940$a622cbc0$@ditenity.com> In-Reply-To: Date: Tue, 18 Dec 2012 07:53:19 -0800 Message-ID: <00ab01cddd37$ce1c18a0$6a5449e0$@ditenity.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF3e5H6J5oRPTPnQxNox+nxboXkGgF8Im8SAoIOzNYCziHUSwH48tvAAt52d02YbldGMA== Content-Language: en-us X-Gm-Message-State: ALoCoQn0X0Qr4t51Wyn6G4LVq8qTpxd9Y+knqJdIEl9OPlWqUSpNf8TM00jH7M5+PY1YN77S8I+/ Cc: tls@ietf.org Subject: Re: [TLS] Comments on the cached-info draft 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Dec 2012 15:53:26 -0000 > [Joe] The client would still need to do some processing to determine which > hash to send in the client hello. > [Piyush] It'll be nice for client to do it because if will reduce the message size. But this method will work even if client sends all the cached objects it has. The extension is just a means to communicate what objects client possesses. > > > Can you think of any issues with not sending the cached objects in > > server hello extension? > > > > [Joe] Its not clear to me that the server needs to send the hashes of the > cached objects at all. The server does not need to tell the client the value of > the hash of the data is since the client sent it in the client hello. [Piyush] Agreed > It just needs to be able to unambiguously determine if the server is using that cached data > or providing a different set of data. If we go with just omitting the data > there may be some ambiguity between an empty message representing > cached data and an empty message representing something else. [Piyush] Good point. Martin gave a specific example of this - CA distinguished names. > remove this ambiguity the server could just send an enumeration of the > cached object types it accepted in the hello extension (the semantics for the > server hello extension in the current draft may be different). > [Piyush] Absolutely. And these enumerations (one per message) could be a combination of complete objects and cached objects where cached objects are picked from the list that the client sent in client hello. From stephen.farrell@cs.tcd.ie Thu Dec 20 13:39:03 2012 Return-Path: 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 0A11F21F86B0 for ; Thu, 20 Dec 2012 13:39:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.414 X-Spam-Level: X-Spam-Status: No, score=-102.414 tagged_above=-999 required=5 tests=[AWL=0.185, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 2AgIj49OPDaR for ; Thu, 20 Dec 2012 13:39:02 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 0852B21F8995 for ; Thu, 20 Dec 2012 13:39:02 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 5938CBE3E for ; Thu, 20 Dec 2012 21:38:40 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6xA8x+bOqf2y for ; Thu, 20 Dec 2012 21:38:39 +0000 (GMT) Received: from [10.87.48.8] (unknown [86.44.68.76]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id F0DFABE1C for ; Thu, 20 Dec 2012 21:38:38 +0000 (GMT) Message-ID: <50D3855E.8050902@cs.tcd.ie> Date: Thu, 20 Dec 2012 21:38:38 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "tls@ietf.org" References: <20121220193358.31474.25301.idtracker@ietfa.amsl.com> In-Reply-To: <20121220193358.31474.25301.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.4.6 X-Forwarded-Message-Id: <20121220193358.31474.25301.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [TLS] Fwd: Last Call: (Certificate Transparency) to Experimental RFC 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Dec 2012 21:39:03 -0000 Hi, Many of you probably know about certificate transparency as we had a BoF on the topic at IETF-85. I'm AD sponsoring this draft with a view to it becomming an experimental track RFC, and IETF last call has just started for that. (Running until Jan 24 - an extra week for the holidays.) Since the draft makes use of TLS-like data structures and aims to help improve security for TLS servers mainly, review from this community would be very welcome. Thanks, S. -------- Original Message -------- Subject: Last Call: (Certificate Transparency) to Experimental RFC Date: Thu, 20 Dec 2012 11:33:58 -0800 From: The IESG Reply-To: ietf@ietf.org To: IETF-Announce The IESG has received a request from an individual submitter to consider the following document: - 'Certificate Transparency' as Experimental RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-01-24. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The aim of Certificate Transparency is to have every public end- entity (for example, web servers) and intermediate TLS certificate issued by a known Certificate Authority recorded in one or more certificate logs. In order to detect misissuance of certificates, all logs are publicly auditable. In particular, domain owners or their agents will be able to monitor logs for certificates issued on their own domain. To protect clients from unlogged misissued certificates, each log signs all certificates it records, and clients can choose not to trust certificates that are not accompanied by an appropriate log signature. For privacy and performance reasons log signatures are embedded in the TLS handshake via the TLS authorization extension, in a stapled OCSP extension, or in the certificate itself via an X.509v3 certificate extension. To ensure a globally consistent view of any particular log, each log also provides a global signature over the entire log. Any inconsistency of logs can be detected through cross-checks on the global signature. Consistency between any pair of global signatures, corresponding to snapshots of a particular log at different times, can be efficiently shown. Logs are only expected to certify that they have seen a certificate, and thus we do not specify any revocation mechanism for log signatures in this document. Logs are append-only, and log signatures do not expire. The file can be obtained via http://datatracker.ietf.org/doc/draft-laurie-pki-sunlight/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-laurie-pki-sunlight/ballot/ No IPR declarations have been submitted directly on this I-D. From hannes.tschofenig@gmx.net Fri Dec 21 07:04:34 2012 Return-Path: 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 4422621F84E8 for ; Fri, 21 Dec 2012 07:04:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.98 X-Spam-Level: X-Spam-Status: No, score=-101.98 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] 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 i4kBUhGuyOtj for ; Fri, 21 Dec 2012 07:04:33 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 3400021F84BB for ; Fri, 21 Dec 2012 07:04:33 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.32]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0M5Jbd-1SsqBt14ed-00zVSv for ; Fri, 21 Dec 2012 16:04:30 +0100 Received: (qmail 3014 invoked by uid 0); 21 Dec 2012 15:04:30 -0000 Received: from 213.162.68.169 by www026.gmx.net with HTTP; Fri, 21 Dec 2012 16:04:28 +0100 (CET) Content-Type: text/plain; charset="utf-8" Date: Fri, 21 Dec 2012 16:04:28 +0100 From: "Hannes Tschofenig" In-Reply-To: <50BB09D3.6010106@gnutls.org> Message-ID: <20121221150428.160970@gmx.net> MIME-Version: 1.0 References: <50BB09D3.6010106@gnutls.org> To: Nikos Mavrogiannopoulos , tls@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1+9oSx7i9G9pSbJBe1RH9WbvmKO1Pfv+q6e+PistZ gHi4HFeF9qXAMYnH4JcDrHuTX82byvnqb4Vw== Content-Transfer-Encoding: 8bit X-GMX-UID: Kx+mcIVfeSEqRpIAqXUhl8Z+IGRvbwB7 Subject: Re: [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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 15:04:34 -0000 Hi Nikos, thanks for your review comments and for spotting a bug. In the current draft a single structure is used by both the client and the server to convey information about the "certificate" types they accept and they offer. You suggest to encode this information into two different types of payloads and that is similar to what we had in an earlier draft version (see http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-04). The feedback we got at the summer IETF meeting was that this approach was not preferred. Consequently, we changed it. Regarding your remark "Why sbd suggest 0,3 and the server reply with 1,2?". I believe the symbolic names are more intuitive for end users who read the specifications and the semantic is explained in the text. A program does not care what numbers are used for the different options. Ciao Hannes -------- Original-Nachricht -------- > Datum: Sun, 02 Dec 2012 08:57:07 +0100 > Von: Nikos Mavrogiannopoulos > An: tls@ietf.org > CC: paul@nohats.ca, Hannes Tschofenig > Betreff: certificate type negotiaiton in draft-ietf-tls-oob-pubkey-06 > 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 From hannes.tschofenig@gmx.net Fri Dec 21 07:08:16 2012 Return-Path: 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 D76DB21F8B3E for ; Fri, 21 Dec 2012 07:08:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.68 X-Spam-Level: X-Spam-Status: No, score=-100.68 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] 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 gusA5pBznuIe for ; Fri, 21 Dec 2012 07:08:15 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 3584821F84E8 for ; Fri, 21 Dec 2012 07:08:15 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.20]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0MRhn5-1Tfd4v0zUn-00SxHj for ; Fri, 21 Dec 2012 16:08:12 +0100 Received: (qmail 27837 invoked by uid 0); 21 Dec 2012 15:08:12 -0000 Received: from 213.162.68.169 by www012.gmx.net with HTTP; Fri, 21 Dec 2012 16:08:12 +0100 (CET) Content-Type: text/plain; charset="utf-8" Date: Fri, 21 Dec 2012 16:08:12 +0100 From: "Hannes Tschofenig" Message-ID: <20121221150812.160960@gmx.net> MIME-Version: 1.0 To: tls@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1/Cw2VT6+/CEyYdNq/zxgPiA6lltWdlmrSNLf0NFi rOcvYEgp0qGT1EVuxRd2SMihNzu2MjRq2rOw== Content-Transfer-Encoding: 8bit X-GMX-UID: Cx6mcIRfeSEqRpIAqXUh2Mt+IGRvbwCe Subject: [TLS] SubjectPublicKeyInfo structure in draft-ietf-tls-oob-pubkey 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 15:08:17 -0000 Hi all, Stefan Jucker, Kovatsch Matthias, and Klaus Hartke pointed out to me that the way how the SubjectPublicKeyInfo structure is placed in the cerificate payload is not clear. They have provided a figure with three options, which can be found here http://www.tschofenig.priv.at/raw-pk-cert.jpg The intention was to go for version (c). To make this more clear in the current draft version I would therefore suggest to a) Add information regarding the encoding of the SubjectPublicKeyInfo structure inside the certificate payload. // Certificate opaque ASN.1Cert<1..2^24-1>; // SubjectPublicKeyInfo opaque RawPublicKeyCert[Handshake.length]; struct { select(certificate_type){ case X.509-Offer: ASN.1Cert certificate_list<0..2ˆ24-1>; case RawPublicKey-Offer: RawPublicKeyCert certificate; }; } Certificate; b) Add an example to the appendix. For example, the following hex sequence describes a SubjectPublicKeyInfo structure inside the certificate payload: 0x30, 0x81, 0x9f, 0x30, 0x0d, 0x06, 0x09, 0x2a, 0x86, 0x48, 0x86, 0xf7, 0x0d, 0x01, 0x01, 0x01, 0x05, 0x00, 0x03, 0x81, 0x8d, 0x00, 0x30, 0x81, 0x89, 0x02, 0x81, 0x81, 0x00, 0xcd, 0xfd, 0x89, 0x48, 0xbe, 0x36, 0xb9, 0x95, 0x76, 0xd4, 0x13, 0x30, 0x0e, 0xbf, 0xb2, 0xed, 0x67, 0x0a, 0xc0, 0x16, 0x3f, 0x51, 0x09, 0x9d, 0x29, 0x2f, 0xb2, 0x6d, 0x3f, 0x3e, 0x6c, 0x2f, 0x90, 0x80, 0xa1, 0x71, 0xdf, 0xbe, 0x38, 0xc5, 0xcb, 0xa9, 0x9a, 0x40, 0x14, 0x90, 0x0a, 0xf9, 0xb7, 0x07, 0x0b, 0xe1, 0xda, 0xe7, 0x09, 0xbf, 0x0d, 0x57, 0x41, 0x86, 0x60, 0xa1, 0xc1, 0x27, 0x91, 0x5b, 0x0a, 0x98, 0x46, 0x1b, 0xf6, 0xa2, 0x84, 0xf8, 0x65, 0xc7, 0xce, 0x2d, 0x96, 0x17, 0xaa, 0x91, 0xf8, 0x61, 0x04, 0x50, 0x70, 0xeb, 0xb4, 0x43, 0xb7, 0xdc, 0x9a, 0xcc, 0x31, 0x01, 0x14, 0xd4, 0xcd, 0xcc, 0xc2, 0x37, 0x6d, 0x69, 0x82, 0xd6, 0xc6, 0xc4, 0xbe, 0xf2, 0x34, 0xa5, 0xc9, 0xa6, 0x19, 0x53, 0x32, 0x7a, 0x86, 0x0e, 0x91, 0x82, 0x0f, 0xa1, 0x42, 0x54, 0xaa, 0x01, 0x02, 0x03, 0x01, 0x00, 0x01 Decoded (for example using Peter's ASN.1 decoder http://www.cs.auckland.ac.nz/~pgut001/) this leads to something like: Offset Length Description ------------------------------------------------------------------- 0 3+159: SEQUENCE { 3 2+13: SEQUENCE { 5 2+9: OBJECT IDENTIFIER Value (1 2 840 113549 1 1 1) : PKCS #1, rsaEncryption 16 2+0: NULL : } 18 3+141: BIT STRING, encapsulates { 22 3+137: SEQUENCE { 25 3+129: INTEGER Value (1024 bit) 157 2+3: INTEGER Value (65537) : } : } : } Objections? Ciao Hannes From hannes.tschofenig@gmx.net Fri Dec 21 07:15:47 2012 Return-Path: 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 EABEE21F8651 for ; Fri, 21 Dec 2012 07:15:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.42 X-Spam-Level: X-Spam-Status: No, score=-100.42 tagged_above=-999 required=5 tests=[AWL=-1.040, BAYES_50=0.001, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] 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 XJWBnB9lg0YX for ; Fri, 21 Dec 2012 07:15:47 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id 7A05B21F85E8 for ; Fri, 21 Dec 2012 07:15:43 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.12]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0M38kj-1Sv3zl1wj1-00sxxl for ; Fri, 21 Dec 2012 16:15:42 +0100 Received: (qmail 16444 invoked by uid 0); 21 Dec 2012 15:15:42 -0000 Received: from 213.162.68.169 by www012.gmx.net with HTTP; Fri, 21 Dec 2012 16:15:41 +0100 (CET) Content-Type: text/plain; charset="utf-8" Date: Fri, 21 Dec 2012 16:15:41 +0100 From: "Hannes Tschofenig" Message-ID: <20121221151541.160980@gmx.net> MIME-Version: 1.0 To: tls@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX19KgGIgYOlKcEk5zAdwM5/Cuhu0blLKkwntfWg2hX Hh4bQlm1wYLJ2LscQPqyLYj1vh+pHJtXnCbQ== Content-Transfer-Encoding: 8bit X-GMX-UID: ShimcIZfeSEqRpIAqXUhh8p+IGRvb0CV Subject: [TLS] draft-ietf-tls-oob-pubkey: Next Steps? 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 15:15:48 -0000 Hi all, I am looking for some guidance regarding the next steps for draft-ietf-tls-oob-pubkey. I would like to hear your views regarding the following two items: 1) Should draft-ietf-tls-oob-pubkey redefine the semantic of the cert_type registry created by RFC 6091 or create a new registry? 2) Should draft-ietf-tls-oob-pubkey register OpenPGP values into the registry or leave that to another document? Ciao Hannes From jsalowey@cisco.com Fri Dec 21 07:53:29 2012 Return-Path: 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 6C63221F8799 for ; Fri, 21 Dec 2012 07:53:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 uIWJe2-QnpS2 for ; Fri, 21 Dec 2012 07:53:29 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id E540021F8797 for ; Fri, 21 Dec 2012 07:53:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=970; q=dns/txt; s=iport; t=1356105209; x=1357314809; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=v2zd2tuAR9/+XQRVRQS7lDkWR1RQKqNElKSxNkSZY9k=; b=kw3o60LnuLGtM0YQMb/PqTWDSgY85b3CvKgASM2u+kiSXvcvP488God7 NU7S1wEbDVqGiQyIzhq2+my9NYYjLnczRXTkNkUo0vjaYOijQuDxubQjB yD3P6H/2hz3AEp0Hc2k0120brS+UBdkdjxBh+4qaLAnXVfDKD1LJfT0R4 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak8FALGF1FCtJXG+/2dsb2JhbABFhXO4CRZzgh4BAQEDAQEBATc0CwULAgEIIhQQJwslAgQOBQiHeQMJBgy2IgSLbWqDYmEDplOCdIIi X-IronPort-AV: E=Sophos;i="4.84,330,1355097600"; d="scan'208";a="152532459" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-9.cisco.com with ESMTP; 21 Dec 2012 15:53:28 +0000 Received: from xhc-rcd-x13.cisco.com (xhc-rcd-x13.cisco.com [173.37.183.87]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qBLFrSin005886 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Dec 2012 15:53:28 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.13]) by xhc-rcd-x13.cisco.com ([173.37.183.87]) with mapi id 14.02.0318.004; Fri, 21 Dec 2012 09:53:28 -0600 From: "Joseph Salowey (jsalowey)" To: Hannes Tschofenig Thread-Topic: [TLS] draft-ietf-tls-oob-pubkey: Next Steps? Thread-Index: AQHN344SU0Iu1QsGHEaePwIq8s8e1JgjzBsA Date: Fri, 21 Dec 2012 15:53:27 +0000 Message-ID: References: <20121221151541.160980@gmx.net> In-Reply-To: <20121221151541.160980@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.61] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [TLS] draft-ietf-tls-oob-pubkey: Next Steps? 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 15:53:29 -0000 On Dec 21, 2012, at 7:15 AM, Hannes Tschofenig wrote: > Hi all,=20 >=20 > I am looking for some guidance regarding the next steps for draft-ietf-tl= s-oob-pubkey.=20 >=20 > I would like to hear your views regarding the following two items: >=20 > 1) Should draft-ietf-tls-oob-pubkey redefine the semantic of the cert_typ= e registry created by RFC 6091 or create a new registry?=20 >=20 [Joe] I'm leaning towards using the existing registry. I'm not sure what = you mean by changing the semantics of the registry, can you clarify? =20 > 2) Should draft-ietf-tls-oob-pubkey register OpenPGP values into the regi= stry or leave that to another document? >=20 [Joe] I we are defining a new registry I believe this should be done in a d= ifferent document.=20 > Ciao > Hannes > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From hannes.tschofenig@gmx.net Fri Dec 21 08:04:05 2012 Return-Path: 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 1DB5721F8555 for ; Fri, 21 Dec 2012 08:04:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.547 X-Spam-Level: X-Spam-Status: No, score=-101.547 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] 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 g-iRqlos2u3d for ; Fri, 21 Dec 2012 08:04:04 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id A623221F8549 for ; Fri, 21 Dec 2012 08:04:03 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.30]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0LyxXq-1SzfPM1o92-0148Lw for ; Fri, 21 Dec 2012 17:04:00 +0100 Received: (qmail 24385 invoked by uid 0); 21 Dec 2012 16:04:00 -0000 Received: from 213.162.68.169 by www012.gmx.net with HTTP; Fri, 21 Dec 2012 17:03:57 +0100 (CET) Content-Type: text/plain; charset="utf-8" Date: Fri, 21 Dec 2012 17:03:57 +0100 From: "Hannes Tschofenig" In-Reply-To: Message-ID: <20121221160357.160960@gmx.net> MIME-Version: 1.0 References: To: Stefan Santesson , tls@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1+xTtBV8Kix/hoPDr4KNlMQEwgNFqqc1aa60fp+Sz fXzgdM/HedbJ3alPfAeQ28FHmnaq4nTqlwQA== Content-Transfer-Encoding: 8bit X-GMX-UID: Oe2mcIRfeSEqRpIAqXUhKr9+IGRvbwCb Subject: Re: [TLS] Comments on the cached-info draft 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 16:04:05 -0000 Hi Stefan, I agree with you that the design could be different. Good that you suggested the current design :-) Currently, the client hello contains the hash and then the server provides the hash of the data back to the client instead of the full payload. As you suggested it is possible to omit the second hash. To your other point that the current description breaks TLS is IMHO not true. The entire purpose of the extension (and many other extensions) is that the client indicates the support for new functionality and the server (if it supports it) returns different information. In the example you provide below regarding the certificate structure the server includes a vector of hashes rather than the list of full certificate payloads. Since the client previously indicated that it supports the extension what would break? Ciao Hannes -------- Original-Nachricht -------- > Datum: Wed, 07 Nov 2012 11:42:19 -0400 > Von: Stefan Santesson > An: tls@ietf.org > CC: Hannes Tschofenig > Betreff: Comments on the cached-info draft > It was quite a while since I wrote the first version of this draft. > Now that I bring it up to my attention I found a problem that I think > should be fixed. > > After a close examination I'm convinced that the current spec breaks TLS. > > > The current approach is to exchange support for cached-info in client and > server hellos. > This includes hashes for cached objects (clients) and confirmation of > cached objects (server). > > In addition to this, this protocol allows the cached data in handshake > messages to be swapped with cached object hashes. > This is a violation of the syntax of these handshake messages. > > Take the Certificate handshake message for example. The spec suggest here > to replace the certificate_list vector to be replaced with a vector of > CachedObejct structured data. > This breaks the syntax of this handshake message. A strict processing of > the certificate_list vector will expect an ASN.1 encoded binary containing > a sequence of certificates, not a vector of data objects according to the > CachedObject structure. > > My first thought was that we actually need a new handshake message. > However that is not helpful either. > The TLS spec require the Certificate handshake message to be sent in case > the chosen cipher suite demands it, so it MUST be sent. > It can't be replaced by another handshake message. > > My current belief is that we simply should omit the cached data, and that > each cachedInfo type need to defined how to omit cached data. > > In case of the certificate handshake message, the certificate list should > be replaced with an empty sequence. > > > There is actually no need to send the hash of the cached data in the > handshake message. Not if the confirmation of the cached info is exchanged > in the server hello. Sending the hash once more in the handshake message > is then redundant. > > > So I propose the following: > > 1) Clients send hashes of cached objects in client hello. > 2) Server responds with one or zero hashes per cachedInfo type, that a) > matches a cached object sent by the client b) will be omitted by the > server in the corresponding handshake message. > 3) How information is omitted from the handshake message is defined per > cached info type. For the current defined 2 types this is: > A) cached certificate cahins in Certificate: replace the sequence of > certificates with an empty sequence. > B) certificate_authorities in Certificate Request: Send an empty list of > DistinguishedName > 4) Clients will act as if the cached objects (confirmed in server hello) > were sent in the handshake messages. > 5) Everything else according to the current spec > > > The proposed approach will somewhat limit the functionality of the current > spec, but it ads value in simplicity. > I can't imagine a valid use case that would not be covered by this change, > but I might overlook something. > > > > > > > > > > > > > > > > From hannes.tschofenig@gmx.net Fri Dec 21 09:39:20 2012 Return-Path: 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 C8F6421F8767 for ; Fri, 21 Dec 2012 09:39:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.609 X-Spam-Level: X-Spam-Status: No, score=-101.609 tagged_above=-999 required=5 tests=[AWL=0.371, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] 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 xSGUHNCn3Vgq for ; Fri, 21 Dec 2012 09:39:18 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 289FC21F8651 for ; Fri, 21 Dec 2012 09:39:16 -0800 (PST) Received: from mailout-de.gmx.net ([10.1.76.2]) by mrigmx.server.lan (mrigmx001) with ESMTP (Nemesis) id 0M0vtR-1Sx9LA39qh-00v5ph for ; Fri, 21 Dec 2012 18:39:15 +0100 Received: (qmail 823 invoked by uid 0); 21 Dec 2012 17:39:15 -0000 Received: from 213.162.68.169 by www005.gmx.net with HTTP; Fri, 21 Dec 2012 18:39:14 +0100 (CET) Content-Type: text/plain; charset="utf-8" Date: Fri, 21 Dec 2012 18:39:14 +0100 From: "Hannes Tschofenig" In-Reply-To: Message-ID: <20121221173914.160990@gmx.net> MIME-Version: 1.0 References: <20121221151541.160980@gmx.net> To: "Joseph Salowey (jsalowey)" , Hannes.Tschofenig@gmx.net X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1+oViVvCd+odr7oT0CMpK6fwIEkw14g1qvOyf+Are oFn9nQg+GAZHyJNvk6uDk0H7HqiHouNfl6lg== Content-Transfer-Encoding: 8bit X-GMX-UID: lPumcIdfeSEqRpIAqXUhzIR+IGRvb8Cb Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-oob-pubkey: Next Steps? 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 17:39:20 -0000 Hi Joe, thanks for your quick response. > 1) Should draft-ietf-tls-oob-pubkey redefine the semantic of the cert_type registry created by RFC 6091 or create a new registry? > [Joe] I'm leaning towards using the existing registry. I'm not sure what you mean by changing the semantics of the registry, can you clarify? [Hannes] IMHO re-using the registry means to create a normative reference to RFC 6091/, i.e., a downref. Is that OK for you? If we go for the current document, namely http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-06, we have to populate the registry with the following values: X.509-Accept (a), X.509-Offer (b), RawPublicKey-Accept (c), RawPublicKey-Offer (d), If we instead use two TLS extensions (namely cert-receive & cert-send as described in http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-04 or client_certificate_type & server_certificate_type as suggested by Nikos in http://www.ietf.org/mail-archive/web/tls/current/msg09093.html to carry the values) then we can go down to two values: X.509(a) RawPublicKey(b) In either case it remains to be studied what this means for an update to RFC 6091. Ciao Hannes From jsalowey@cisco.com Fri Dec 21 09:54:37 2012 Return-Path: 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 7118521F84D8 for ; Fri, 21 Dec 2012 09:54:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 sQSsOKpNsBdf for ; Fri, 21 Dec 2012 09:54:36 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id CB82321F84A1 for ; Fri, 21 Dec 2012 09:54:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2251; q=dns/txt; s=iport; t=1356112477; x=1357322077; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=O2YhyzkhxN6C5hpvg0p3rk7igSiHKj3e5N4Q2YZ7sD0=; b=ZyRdIqihYP3Rza9Idn91J+NrSXC9CF5kqaVuduRuUAInD4D56ZW96jMx r02JTtfBKJYqcCWUiAi0BgKg0MIvN3EtExlwsRsxgvGJUaglzMTG12Gst XET5bOKrnxHIEs+6or+hMv621NgWVS3WvPvwvjqlaBp75F8PgUlKY8M+7 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAC+h1FCtJXG+/2dsb2JhbABFvXwWc4IeAQEBAwE6PwULAgEIIhQQMiUCBA4FCAGHeAMJBgy2PYttahuDR2EDlyePLIJ0gW01 X-IronPort-AV: E=Sophos;i="4.84,331,1355097600"; d="scan'208";a="155583438" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-5.cisco.com with ESMTP; 21 Dec 2012 17:54:36 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qBLHsa8P031454 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 21 Dec 2012 17:54:36 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.13]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.02.0318.004; Fri, 21 Dec 2012 11:54:36 -0600 From: "Joseph Salowey (jsalowey)" To: Hannes Tschofenig Thread-Topic: [TLS] draft-ietf-tls-oob-pubkey: Next Steps? Thread-Index: AQHN344SU0Iu1QsGHEaePwIq8s8e1JgjzBsAgAAdjQCAAARGAA== Date: Fri, 21 Dec 2012 17:54:35 +0000 Message-ID: References: <20121221151541.160980@gmx.net> <20121221173914.160990@gmx.net> In-Reply-To: <20121221173914.160990@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.61] Content-Type: text/plain; charset="us-ascii" Content-ID: <555E484CD01315498C406416B0C7EB61@cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [TLS] draft-ietf-tls-oob-pubkey: Next Steps? 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Dec 2012 17:54:37 -0000 On Dec 21, 2012, at 9:39 AM, Hannes Tschofenig wrote: > Hi Joe,=20 >=20 > thanks for your quick response.=20 >=20 >=20 >> 1) Should draft-ietf-tls-oob-pubkey redefine the semantic of the cert_ty= pe registry created by RFC 6091 or create a new registry? >>=20 >=20 > [Joe] I'm leaning towards using the existing registry. I'm not sure wha= t you mean by changing the semantics of the registry, can you clarify? =20 >=20 > [Hannes] IMHO re-using the registry means to create a normative reference= to RFC 6091/, i.e., a downref. Is that OK for you? >=20 [Joe] We're trying to avoid that, but at the same time we need to do someth= ing reasonable. I'm not convinced that just reusing a registry means we mu= st reference RFC 6091. =20 > If we go for the current document, namely http://tools.ietf.org/html/draf= t-ietf-tls-oob-pubkey-06, we have to populate the registry with the followi= ng values: >=20 > X.509-Accept (a), > X.509-Offer (b), > RawPublicKey-Accept (c), > RawPublicKey-Offer (d), >=20 >=20 > If we instead use two TLS extensions (namely cert-receive & cert-send as = described in http://tools.ietf.org/html/draft-ietf-tls-oob-pubkey-04 or cli= ent_certificate_type & server_certificate_type as suggested by Nikos in htt= p://www.ietf.org/mail-archive/web/tls/current/msg09093.html to carry the va= lues) then we can go down to two values: >=20 > X.509(a) > RawPublicKey(b) >=20 [Joe] So if were were going to reuse the same registry then I think we woul= d want to use the second approach. It doesn't seem like it would be fruit= ful to use the same registry and then register all new types. =20 I think I'd summarize the two approaches as=20 1) Define a new registry as in -06, It would be up to a new document to de= fine values and specific behavior for openpgp. 2) Use the existing registry, add new raw-key entry and go with the -04 or = Nikos' suggestion. A new (possibly very short) document can define how the= new extension applies to openpgp. =20 > In either case it remains to be studied what this means for an update to = RFC 6091. >=20 > Ciao > Hannes From simon@josefsson.org Sun Dec 23 01:44:01 2012 Return-Path: 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 2F81521F857E for ; Sun, 23 Dec 2012 01:44:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.909 X-Spam-Level: X-Spam-Status: No, score=-99.909 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, USER_IN_WHITELIST=-100] 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 4hrU4A3oIPer for ; Sun, 23 Dec 2012 01:44:00 -0800 (PST) Received: from yxa-v.extundo.com (static-213-115-179-173.sme.bredbandsbolaget.se [213.115.179.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4D23D21F8566 for ; Sun, 23 Dec 2012 01:43:59 -0800 (PST) Received: from latte.josefsson.org (host-95-192-74-122.mobileonline.telia.com [95.192.74.122]) (authenticated bits=0) by yxa-v.extundo.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id qBN9hYFF027760 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 23 Dec 2012 10:43:36 +0100 From: Simon Josefsson To: "Joseph Salowey \(jsalowey\)" References: <20121221151541.160980@gmx.net> <20121221173914.160990@gmx.net> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:121223:hannes.tschofenig@gmx.net::6X7Q5POJWq9YQfnH:201F X-Hashcash: 1:22:121223:jsalowey@cisco.com::6pKeuD32dndB3MVH:8nVf X-Hashcash: 1:22:121223:tls@ietf.org::tcFGf+WKqhwF9svL:nasU Date: Sun, 23 Dec 2012 10:43:29 +0100 In-Reply-To: (Joseph Salowey's message of "Fri, 21 Dec 2012 17:54:35 +0000") Message-ID: <87licpyugu.fsf@latte.josefsson.org> User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.3 at yxa-v X-Virus-Status: Clean Cc: "" Subject: Re: [TLS] draft-ietf-tls-oob-pubkey: Next Steps? 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 09:44:01 -0000 "Joseph Salowey (jsalowey)" writes: >>> 1) Should draft-ietf-tls-oob-pubkey redefine the semantic of the >>> cert_type registry created by RFC 6091 or create a new registry? >>> >> >> [Joe] I'm leaning towards using the existing registry. I'm not sure >> what you mean by changing the semantics of the registry, can you >> clarify? >> >> [Hannes] IMHO re-using the registry means to create a normative >> reference to RFC 6091/, i.e., a downref. Is that OK for you? >> > > [Joe] We're trying to avoid that, but at the same time we need to do > something reasonable. I'm not convinced that just reusing a registry > means we must reference RFC 6091. RFC 6091 defines structures that is needed for implementing anything that relies on those structures, so it has to be referenced. I prefer to re-use existing work and thus to reference RFC 6091. To resolve the downref issue, I suggest to move RFC 6091 to Standards Track. /Simon From jsalowey@cisco.com Sun Dec 23 09:36:35 2012 Return-Path: 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 24E8721F8B30 for ; Sun, 23 Dec 2012 09:36:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] 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 SjHRLzTjgib2 for ; Sun, 23 Dec 2012 09:36:34 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6F0C421F8B2D for ; Sun, 23 Dec 2012 09:36:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1479; q=dns/txt; s=iport; t=1356284194; x=1357493794; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=uYVlPrHqsXWsdEpMPxXghbUjTWB1L+9/mqDZH/K+Pq0=; b=TTlCeu23u4DpKWkI2AIj5loVHyJ3/PWl8dEOuij+hbeAMljNvUH6dDvD 8IIu0OHHCCB3n138cCjP++Xj0XrT1h5tIdpqlGa/K/eYqtqhAEChGyuZf M2/JmLaOwmOV0bjh4O8nzDEJ35ULu323VKwYKvI0rcyoi9dIy11CERUbp E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AssHAKdA11CtJXG9/2dsb2JhbABEg0i6QhZzgh4BAQEDATo/BQsCAQg2EDIlAgQOBYgNBrREjFeDYmEDlgyQSIJ0 X-IronPort-AV: E=Sophos;i="4.84,343,1355097600"; d="scan'208";a="156014571" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-7.cisco.com with ESMTP; 23 Dec 2012 17:36:34 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qBNHaXUZ009580 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 23 Dec 2012 17:36:34 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.13]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.02.0318.004; Sun, 23 Dec 2012 11:36:33 -0600 From: "Joseph Salowey (jsalowey)" To: Simon Josefsson Thread-Topic: draft-ietf-tls-oob-pubkey: Next Steps? Thread-Index: AQHN4PIESmH7iRJ7bkKF9f+VNXaOfJgmpjVQ Date: Sun, 23 Dec 2012 17:36:33 +0000 Message-ID: <313727E6-B020-41C3-AE0C-F02C256A3100@cisco.com> References: <20121221151541.160980@gmx.net> <20121221173914.160990@gmx.net> , <87licpyugu.fsf@latte.josefsson.org> In-Reply-To: <87licpyugu.fsf@latte.josefsson.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [TLS] draft-ietf-tls-oob-pubkey: Next Steps? 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 17:36:35 -0000 Sent from my iPad On Dec 23, 2012, at 1:43 AM, "Simon Josefsson" wrote: > "Joseph Salowey (jsalowey)" writes: >=20 >>>> 1) Should draft-ietf-tls-oob-pubkey redefine the semantic of the >>>> cert_type registry created by RFC 6091 or create a new registry? >>>=20 >>> [Joe] I'm leaning towards using the existing registry. I'm not sure >>> what you mean by changing the semantics of the registry, can you >>> clarify? >>>=20 >>> [Hannes] IMHO re-using the registry means to create a normative >>> reference to RFC 6091/, i.e., a downref. Is that OK for you? >>=20 >> [Joe] We're trying to avoid that, but at the same time we need to do >> something reasonable. I'm not convinced that just reusing a registry >> means we must reference RFC 6091. >=20 > RFC 6091 defines structures that is needed for implementing anything > that relies on those structures, so it has to be referenced. >=20 [Joe] RFC 6091 structures and semantics do not meet the working group requi= rements for asymmetric use of certificate types. The proposal is to use th= e 6091 defined registry for certificate type enumeration only. If we can't= use the registry without referencing the semantics and structures then I t= hink a new registry is needed. =20 > I prefer to re-use existing work and thus to reference RFC 6091. To > resolve the downref issue, I suggest to move RFC 6091 to Standards > Track. >=20 > /Simon From dkg@fifthhorseman.net Sun Dec 23 13:29:09 2012 Return-Path: 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 C7ED821F8B4C for ; Sun, 23 Dec 2012 13:29:09 -0800 (PST) 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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BZtx3DldL295 for ; Sun, 23 Dec 2012 13:29:09 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 540EF21F8B4B for ; Sun, 23 Dec 2012 13:29:09 -0800 (PST) Received: from [192.168.1.77] (unknown [76.202.80.68]) by che.mayfirst.org (Postfix) with ESMTPSA id 3D349F970; Sun, 23 Dec 2012 16:28:50 -0500 (EST) Message-ID: <50D77792.50704@fifthhorseman.net> Date: Sun, 23 Dec 2012 16:28:50 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Icedove/17.0 MIME-Version: 1.0 To: Hannes Tschofenig References: <20121221151541.160980@gmx.net> In-Reply-To: <20121221151541.160980@gmx.net> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: tls@ietf.org Subject: Re: [TLS] draft-ietf-tls-oob-pubkey: Next Steps? 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Dec 2012 21:29:09 -0000 On 12/21/2012 10:15 AM, Hannes Tschofenig wrote: > 1) Should draft-ietf-tls-oob-pubkey redefine the semantic of the cert_type registry created by RFC 6091 or create a new registry? I lean toward using the existing cert_type registry. > 2) Should draft-ietf-tls-oob-pubkey register OpenPGP values into the registry or leave that to another document? Use the existing registry, simplify the tls-oob-draft to use separate offer- and accept-certtypes (as suggested by Nikos), and proceed from there. This would automatically include the OpenPGP certificate types for those who want to use them. --dkg From Bert.Greevenbosch@huawei.com Mon Dec 31 01:17:00 2012 Return-Path: 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 E6C3C21F8922 for ; Mon, 31 Dec 2012 01:16:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 2UeYun7Mtcmn for ; Mon, 31 Dec 2012 01:16:58 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id F1AE821F87FB for ; Mon, 31 Dec 2012 01:16:57 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANB95949; Mon, 31 Dec 2012 09:16:56 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 31 Dec 2012 09:16:21 +0000 Received: from SZXEML422-HUB.china.huawei.com (10.82.67.161) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.3; Mon, 31 Dec 2012 09:16:55 +0000 Received: from SZXEML509-MBX.china.huawei.com ([10.82.67.37]) by szxeml422-hub.china.huawei.com ([10.82.67.161]) with mapi id 14.01.0323.003; Mon, 31 Dec 2012 17:16:50 +0800 From: Bert Greevenbosch To: "tls@ietf.org" Thread-Topic: Upload of draft-greevenbosch-tls-ocsp-lite-00 Thread-Index: Ac3nN5A+S3C3XZPxTICI5lXN4HtitQ== Date: Mon, 31 Dec 2012 09:16:50 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63CB1DCB0@szxeml509-mbx> Accept-Language: en-GB, zh-CN, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.70.110.143] Content-Type: multipart/alternative; boundary="_000_46A1DF3F04371240B504290A071B4DB63CB1DCB0szxeml509mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [TLS] Upload of draft-greevenbosch-tls-ocsp-lite-00 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Dec 2012 09:17:00 -0000 --_000_46A1DF3F04371240B504290A071B4DB63CB1DCB0szxeml509mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, I have uploaded a draft, which provides a revocation verification mechanism= for raw public keys. The draft is available under the following link: http://www.ietf.org/internet-drafts/draft-greevenbosch-tls-ocsp-lite-00.txt The draft defines an OCSP-lite responder, which is heavily inspired by the = OCSP responder from RFC 2560. However, the original OCSP responder was desi= gned for X.509 certificates and certificate chains, whereas the OCSP-lite r= esponder verifies a single raw public key at a time. The idea is simple: when an entity receives a raw public key, it sends the = associated ID to the OCSP-lite responder, whereupon the OCSP-lite responder= returns a value "GOOD", "REVOKED", "EXPIRED" or "UNKNOWN". Digital signatu= res and nonces make sure the responses are authenticated and fresh. The ID = is defined as the hash over the public key, providing a secure binding betw= een the ID and the public key. It is the target to keep the OCSP-lite responder protocol as lightweight as= possible, such that it can be used by constrained devices that support the= raw public key. I look forward to your comments and suggestions! Best regards, Bert --_000_46A1DF3F04371240B504290A071B4DB63CB1DCB0szxeml509mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

I have uploaded a draft, which provides a revocation= verification mechanism for raw public keys. The draft is available under t= he following link:

http://www.ietf.org/internet-drafts/dra= ft-greevenbosch-tls-ocsp-lite-00.txt

 

The draft defines an OCSP-lite responder, which is h= eavily inspired by the OCSP responder from RFC 2560. However, the original = OCSP responder was designed for X.509 certificates and certificate chains, = whereas the OCSP-lite responder verifies a single raw public key at a time.

 

The idea is simple: when an entity receives a raw pu= blic key, it sends the associated ID to the OCSP-lite responder, whereupon = the OCSP-lite responder returns a value "GOOD", "REVOKED&quo= t;, "EXPIRED" or "UNKNOWN". Digital signatures and nonc= es make sure the responses are authenticated and fresh. The ID is defined as = the hash over the public key, providing a secure binding between the ID and= the public key.

 

It is the target to keep the OCSP-lite responder pro= tocol as lightweight as possible, such that it can be used by constrained d= evices that support the raw public key.

 

I look forward to your comments and suggestions!

 

Best regards,

Bert

 

--_000_46A1DF3F04371240B504290A071B4DB63CB1DCB0szxeml509mbx_--