From yngve@spec-work.net Tue Jan 1 11:54:32 2013 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 8249821E8050 for ; Tue, 1 Jan 2013 11:54:32 -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 PxXoTPQxRD02 for ; Tue, 1 Jan 2013 11:54:31 -0800 (PST) Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id 21BE521E804E for ; Tue, 1 Jan 2013 11:54:30 -0800 (PST) Received: from 38.117.34.95.customer.cdi.no ([95.34.117.38] helo=acorna.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1Tq7ur-00059p-O9; Tue, 01 Jan 2013 20:54:25 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Piyush Jain" , "Joseph Salowey (jsalowey)" References: <50BB111A.2090406@gnutls.org> <027a01cdd0bc$68d7bad0$3a873070$@ditenity.com> Date: Tue, 01 Jan 2013 20:54:23 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: User-Agent: Opera Mail/12.11 (Win32) Cc: "" 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: Tue, 01 Jan 2013 19:54:32 -0000 Hi, [Please note: New email address] The suggestion look mostly OK to me, but I think it should recommend always sending bad_certificate_status_response when the client decides to abort the handshake due to the received OCSP response (e.g. by treating "unknown" or "unauthorized" as fatal errors); I am not sure Joe's text said that clearly. A suggestion for a small update: 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 other unacceptable responses (as determined by client policy), 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 abort 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 might 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 with the handshake, but it would be inappropriate for the client to disclose a username and password until it has fully validated the server certificate. On Sun, 16 Dec 2012 01:35:14 +0100, Joseph Salowey (jsalowey) wrote: > 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-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 >> >> _______________________________________________ >> 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 -- MVH, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/ From trevp@trevp.net Mon Jan 7 12:06:35 2013 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 5E3E621F8900 for ; Mon, 7 Jan 2013 12:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, 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 MJUQr-ik0Tt6 for ; Mon, 7 Jan 2013 12:06:34 -0800 (PST) Received: from mail-ie0-f171.google.com (mail-ie0-f171.google.com [209.85.223.171]) by ietfa.amsl.com (Postfix) with ESMTP id 8C26121F88EF for ; Mon, 7 Jan 2013 12:06:34 -0800 (PST) Received: by mail-ie0-f171.google.com with SMTP id 17so24421565iea.2 for ; Mon, 07 Jan 2013 12:06:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=076NkcfjHHBpdST4NSLgAZBzfxa2QUslsdte+nzizhs=; b=i0otWk9aGBIwx0UMBWYBVXsL77AugZkL27DFWNdXa/2zcMjJ2KUdWPILRRKx9tSZ+n NV3fsJW7jJy28cCNudsw2Gd+QgSgHjsMZuWdlGVCbHTCozhy+cdASo6mQLMQ1kPHWFh2 cK+UGHiMYMuf0zKIvah2p9YNgODLi4L1J0f+qpQK4mZPaWw97iAycWQtDyXRbpCTvGfq p3yg8EVhhYl6ZppqmcZqkIMafkWIkLvq55vukQYPMgyh69zjG6mwJ2TLaLAD9rEP3MNT /qC0HFDNuPKcoZ4pq68Xv2/HZ2qZzpIRSLKkZm+ltJAED//HTVb2xTg4m61nkOluOvHB otNg== MIME-Version: 1.0 X-Received: by 10.50.187.134 with SMTP id fs6mr6503170igc.61.1357589194105; Mon, 07 Jan 2013 12:06:34 -0800 (PST) Received: by 10.64.91.169 with HTTP; Mon, 7 Jan 2013 12:06:33 -0800 (PST) X-Originating-IP: [50.37.20.153] In-Reply-To: <20130107200110.26515.66693.idtracker@ietfa.amsl.com> References: <20130107200110.26515.66693.idtracker@ietfa.amsl.com> Date: Mon, 7 Jan 2013 12:06:33 -0800 Message-ID: From: Trevor Perrin To: tls@ietf.org Content-Type: multipart/alternative; boundary=14dae9340747aa63fd04d2b85d7c X-Gm-Message-State: ALoCoQkSyhwo0jHsR/u73WhUcncCIQpfX25nIuP0DyjC8CJ9P+66f4crl9iwOVKEvaoUnc4EzCEC Cc: tack@lists.riseup.net Subject: [TLS] Fwd: New Version Notification for draft-perrin-tls-tack-02.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jan 2013 20:06:35 -0000 --14dae9340747aa63fd04d2b85d7c Content-Type: text/plain; charset=ISO-8859-1 Hi, We submitted a new TACK draft. No major changes - just some renaming and text cleanup: - renamed "TACK key" -> "TACK signing key", aka "TSK" - renamed "rollover" -> "overlapping pins / tacks" - renamed "accepted/rejected" -> "confirmed/contradicted" - renamed "well-formed" -> "valid" - changed to allow reserved bits in activation_flags - tweaked advice on expiration time - fixed advice on overlapping pins (60 days vs 30 days) - added advice on nonrevokable tacks - trimmed abstract and introduction, and pin activation - clarified that TLS key is in the "end-entity" certificate - clarified 5.2 TLS negotiation - clarified pin activation Trevor ---------- Forwarded message ---------- From: Date: Mon, Jan 7, 2013 at 12:01 PM Subject: New Version Notification for draft-perrin-tls-tack-02.txt To: tack@trevp.net A new version of I-D, draft-perrin-tls-tack-02.txt has been successfully submitted by Trevor Perrin and posted to the IETF repository. Filename: draft-perrin-tls-tack Revision: 02 Title: Trust Assertions for Certificate Keys Creation date: 2013-01-07 WG ID: Individual Submission Number of pages: 21 URL: http://www.ietf.org/internet-drafts/draft-perrin-tls-tack-02.txt Status: http://datatracker.ietf.org/doc/draft-perrin-tls-tack Htmlized: http://tools.ietf.org/html/draft-perrin-tls-tack-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-perrin-tls-tack-02 Abstract: This document defines a TLS Extension that enables a TLS server to support "pinning" to a self-chosen signing key. A client contacting a pinned host will require the server to present a signature from the signing key over the TLS server's public key. The IETF Secretariat --14dae9340747aa63fd04d2b85d7c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

We submitted a new TACK dr= aft.

No major changes - just some renaming and tex= t cleanup:

=A0- renamed "TACK key" -> "TACK signing key", = aka "TSK"
=A0- renamed "rollover" -> &quo= t;overlapping pins / tacks"
=A0- renamed "accepted/rejected" -> "confirmed= /contradicted"
=A0- renamed "well-formed" ->= ; "valid"

=A0- changed to allow reserved bits in activation_flags= =A0
=A0- tweaked advice on expiration time
=A0- fixed = advice on overlapping pins (60 days vs 30 days)
=A0- added advice= on nonrevokable tacks

=A0- trimmed abstract and introduction, and pin activat= ion
=A0- clarified that TLS key is in the "end-entity" = certificate
=A0- clarified 5.2 TLS negotiation
=A0- cla= rified pin activation


Trevor

<= br>
---------- Forwarded message ----------
Fr= om: <internet-drafts@ietf.org>
Date: Mon, Jan 7, 2013 at 12:01 PM
Subject: New Version Notification for= draft-perrin-tls-tack-02.txt
To: tack= @trevp.net



A new version of I-D, draft-perrin-tls-tack-02.txt
has been successfully submitted by Trevor Perrin and posted to the
IETF repository.

Filename: =A0 =A0 =A0 =A0draft-perrin-tls-tack
Revision: =A0 =A0 =A0 =A002
Title: =A0 =A0 =A0 =A0 =A0 Trust Assertions for Certificate Keys
Creation date: =A0 2013-01-07
WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
Number of pages: 21
URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/intern= et-drafts/draft-perrin-tls-tack-02.txt
Status: =A0 =A0 =A0 =A0 =A0http://datatracker.ietf.org/doc/draft-p= errin-tls-tack
Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org/html/draft-perrin-tls= -tack-02
Diff: =A0 =A0 =A0 =A0 =A0 =A0http://www.ietf.org/rfcdiff?url= 2=3Ddraft-perrin-tls-tack-02

Abstract:
=A0 =A0This document defines a TLS Extension that enables a TLS server to =A0 =A0support "pinning" to a self-chosen signing key. =A0A clien= t contacting
=A0 =A0a pinned host will require the server to present a signature from th= e
=A0 =A0signing key over the TLS server's public key.




The IETF Secretariat


--14dae9340747aa63fd04d2b85d7c-- From internet-drafts@ietf.org Wed Jan 9 07:05:17 2013 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 EF95721F868B; Wed, 9 Jan 2013 07:05:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.069, 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 vHQUMW6ahPN2; Wed, 9 Jan 2013 07:05:10 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4E5A21F8689; Wed, 9 Jan 2013 07:05:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.37 Message-ID: <20130109150510.23524.148.idtracker@ietfa.amsl.com> Date: Wed, 09 Jan 2013 07:05:10 -0800 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-multiple-cert-status-extension-03.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 15:05:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Transport Layer Security Working Group of= the IETF. Title : The TLS Multiple Certificate Status Request Extension Author(s) : Yngve N. Pettersen Filename : draft-ietf-tls-multiple-cert-status-extension-03.txt Pages : 9 Date : 2013-01-09 Abstract: This document defines the Transport Layer Security (TLS) Certificate Status Version 2 Extension to allow clients to specify and support multiple certificate status methods. Also defined is a new method based on the Online Certificate Status Protocol (OCSP) that servers can use to provide status information not just about the server's own certificate, but also the status of intermediate certificates in the chain. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-multiple-cert-status-extens= ion There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-multiple-cert-status-extension-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-multiple-cert-status-exte= nsion-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From yngve@spec-work.net Wed Jan 9 07:17:20 2013 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 05A5E21F8514 for ; Wed, 9 Jan 2013 07:17:20 -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 S+G3KoSt0D5V for ; Wed, 9 Jan 2013 07:17:19 -0800 (PST) Received: from smtp.domeneshop.no (smtp.domeneshop.no [194.63.252.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7FF21F8477 for ; Wed, 9 Jan 2013 07:17:19 -0800 (PST) Received: from 38.117.34.95.customer.cdi.no ([95.34.117.38] helo=acorna.invalid.invalid) by smtp.domeneshop.no with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.72) (envelope-from ) id 1TsxP3-0001f6-Qg for tls@ietf.org; Wed, 09 Jan 2013 16:17:17 +0100 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes References: <20130109151310.31632.9200.idtracker@ietfa.amsl.com> Date: Wed, 09 Jan 2013 16:17:17 +0100 To: "tls@ietf.org" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Yngve N. Pettersen" Message-ID: In-Reply-To: <20130109151310.31632.9200.idtracker@ietfa.amsl.com> User-Agent: Opera Mail/12.12 (Win32) Subject: [TLS] Fwd: New Version Notification for draft-pettersen-tls-version-rollback-removal-01.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Jan 2013 15:17:20 -0000 Hello all, I have refreshed my draft about how to leverage the TLS Renegotiation Information extension (RFC 5746) to disable automatic version rollback in TLS Clients. There are no real changes, only fixing a reference IDnit and updating my email address. ------- Forwarded message ------- From: internet-drafts@ietf.org To: yngve@spec-work.net Cc: Subject: New Version Notification for draft-pettersen-tls-version-rollback-removal-01.txt Date: Wed, 09 Jan 2013 16:13:10 +0100 A new version of I-D, draft-pettersen-tls-version-rollback-removal-01.txt has been successfully submitted by Yngve N. Pettersen and posted to the IETF repository. Filename: draft-pettersen-tls-version-rollback-removal Revision: 01 Title: Managing and removing automatic version rollback in TLS Clients Creation date: 2013-01-09 WG ID: Individual Submission Number of pages: 6 URL: http://www.ietf.org/internet-drafts/draft-pettersen-tls-version-rollback-removal-01.txt Status: http://datatracker.ietf.org/doc/draft-pettersen-tls-version-rollback-removal Htmlized: http://tools.ietf.org/html/draft-pettersen-tls-version-rollback-removal-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-pettersen-tls-version-rollback-removal-01 Abstract: Ever since vendors started deploying TLS 1.0 clients, these clients have had to handle server implementations that do not tolerate the TLS version supported by the client, usually by automatically signaling an older supported version instead. Such version rollbacks represent a potential security hazard, if the older version should become vulnerable to attacks. The same history repeated when TLS Extensions were introduced, as some servers would not negotiate with clients that sent these protocol extensions, forcing clients to reduce protocol functionality in order to maintain interoperability. This document outlines a procedure to help clients decide when they may use version rollback to maintain interoperability with legacy servers, under what conditions the clients should not allow version rollbacks, such as when the server has indicated support for the TLS Renegotiation Information extension. The intention of this procedure is to limit the use of automatic version rollback to legacy servers and eventually eliminate its use. The IETF Secretariat -- MVH, Yngve N. Pettersen Using Opera's mail client: http://www.opera.com/mail/ From mrex@sap.com Fri Jan 11 05:40:21 2013 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 53B7321F8900 for ; Fri, 11 Jan 2013 05:40:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.154 X-Spam-Level: X-Spam-Status: No, score=-10.154 tagged_above=-999 required=5 tests=[AWL=0.095, 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 TQLmQem5RLIM for ; Fri, 11 Jan 2013 05:40:20 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id DD2B021F88EF for ; Fri, 11 Jan 2013 05:40:19 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r0BDeIAa010540 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 11 Jan 2013 14:40:18 +0100 (MET) To: tls@ietf.org Date: Fri, 11 Jan 2013 14:40:18 +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: <20130111134018.37F2D1A452@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Subject: [TLS] TLSextSNI - initial SSL 2.0 Hello and session resume 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, 11 Jan 2013 13:40:21 -0000 Dear TLS-fanciers, I've recently added TLS extension SNI to our TLS implementation, and have encountered unexpected client behaviour on my server resulting in session resumption failures (per rfc6066): excerpt from the last paragraph on the bottom of page 7, rfc6066: http://tools.ietf.org/html/rfc6066#page-7 The client SHOULD include the same server_name extension in the session resumption request as it did in the full handshake that established the session. A server that implements this extension MUST NOT accept the request to resume the session if the server_name extension contains a different name. Instead, it proceeds with a full handshake to establish a new session. The cause was an "unusual" Web Browser distributed by our IT department, which has SSL 2.0 enabled in that browser. The effect of this configuration is, that the browser starts every initial handshake with an SSL 2.0 CLIENT-HELLO, offering TLS, which will result result in a TLSv1.0 full handshake. Since there is no room for TLS extensions in a SSL 2.0 CLIENT-HELLO, the session is marked as being established without SNI. On the very next handshake, the browser proposed to resume that session, which per TLS spec requires a TLS ClientHello including the session ID. Now that Brower's TLS implementation appears to blindly insert the whole chore of TLS extensions into *ANY* TLSv1.0 ClientHello, including TLS extension SNI, and this causes the my server, based on the requirement quoted above, to reject the resumption request and require a full handshake instead ... which requires a new connection ... which appears to result in another SSL 2.0 CLIENT-HELLO to be used ... ... wash, rinse, repeat. To make a long story short: it seriously impairs performance. Now I am wondering what the desired behaviour is -- and whatever the desired behaviour for this scenario will be, that this information will be posted as a caveat / clarification throught the errata process for rfc6066. To be fair, the very same session resumption failure will be possible with pure SSLv3 and TLS handshakes if a client does not follow the SHOULD, it is not limited to SSL 2.0 CLIENT-HELLO. The combination of "client SHOULD" with "the server MUST NOT resume" may have not been a very good idea. Am I really the first to notice?? I had commited my code update into our internal development tree friday before X-mas, and the collegues reported the warning messages in the servers trace file this tuesday. Suggestions? -Martin From wtc@google.com Sun Jan 13 07:43:58 2013 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 0025821F86C2 for ; Sun, 13 Jan 2013 07:43:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 4qzu0vokHixs for ; Sun, 13 Jan 2013 07:43:57 -0800 (PST) Received: from mail-ia0-f177.google.com (mail-ia0-f177.google.com [209.85.210.177]) by ietfa.amsl.com (Postfix) with ESMTP id 6F70D21F86C1 for ; Sun, 13 Jan 2013 07:43:57 -0800 (PST) Received: by mail-ia0-f177.google.com with SMTP id h8so2923385iaa.22 for ; Sun, 13 Jan 2013 07:43:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=cK4lziCaJjUrQGes1G4BrYhsRm8oDGiGWZc8d6tp6to=; b=o+a5WgaxpzJrKeomKwsxCSMO/9FJe/MG0IWwR3UabX0TUYNn+xoCvrnzTzOU4BnxN1 qGE+qSjRTDDERpkml+/Oq26P73w6OV/f9o0yTlDU6LRTkKORIh/yZpriVb5iUqvKgABr Gnll8CSS9WCcbaO52yIkpKub+RRWfc6iSy0kUJ0qKZf8jyan0Uf9L2zw72lWRQnHAVLQ /uGkwaK/Ms7C5OZBGHNdltGMyXmHmWW9gSUSp6DUwRJgP2n42DWXOnmn4wf1Vzrnryd5 unNG9d27P4fAD26aTww2axEkMtWwMKoTNo41joBa6Zdb320JIKKMVhcXz/yXa92jUs2g cq4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=cK4lziCaJjUrQGes1G4BrYhsRm8oDGiGWZc8d6tp6to=; b=cNVy/hIylJCY3o51dRdxQFQ3oYYdG257JqkbXFMq3X4zsmOAL5VYuWdqKEMxZh2u/Y hcQrDyWeVBxuALIsm+XHkuNblyPYJn5mrwzRgvs9OUdF5t7vpkE6N1zPk29zjMNAFYN0 HQXqKFal+XmR93wWqWeSYMi85jWTGxzRK+FTcDMx5P4cEEKGmIYNHTAVDVFR48HPWDjc TDfX1/YfDMJBlLV+DsAwLoVSlxHq5Paj5L+yQlU7R1hPIJkNG7fu0gPr+ORUnJZFCOsH ZzB/qKNtC49S/4dlZg9Jxz2huwQwnbYR551DOdGr1Ge+wsdNtloaDbaVVw4qb/6IM/ge yGYQ== MIME-Version: 1.0 Received: by 10.50.16.235 with SMTP id j11mr4596521igd.78.1358091836741; Sun, 13 Jan 2013 07:43:56 -0800 (PST) Received: by 10.231.60.137 with HTTP; Sun, 13 Jan 2013 07:43:56 -0800 (PST) In-Reply-To: <20130111134018.37F2D1A452@ld9781.wdf.sap.corp> References: <20130111134018.37F2D1A452@ld9781.wdf.sap.corp> Date: Sun, 13 Jan 2013 07:43:56 -0800 Message-ID: From: Wan-Teh Chang To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmsAPGkQxkQAhZXcjx93RGc4wZCmjsYfWvJPUTQhGMyGe7ZoNxIdFnFW5A0PVJ83knW2O/ro68pXOdGmAdTrufqnlzGtmxcE36DPh1Z9KfiPF+SrHbHk/mzvFNjmvV0D3nta7tc39nvbreY5xZvbOLCBNMQEvnIpSgt/ge4W2oAsMh4s/fqrsksD8Dndswp0ItKa7IF Cc: "tls@ietf.org" Subject: Re: [TLS] TLSextSNI - initial SSL 2.0 Hello and session resume 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, 13 Jan 2013 15:43:58 -0000 On Fri, Jan 11, 2013 at 5:40 AM, Martin Rex wrote: > > The effect of this configuration is, that the browser starts every > initial handshake with an SSL 2.0 CLIENT-HELLO, offering TLS, > which will result result in a TLSv1.0 full handshake. Since there > is no room for TLS extensions in a SSL 2.0 CLIENT-HELLO, the session > is marked as being established without SNI. > > On the very next handshake, the browser proposed to resume that session, > which per TLS spec requires a TLS ClientHello including the session ID. > Now that Brower's TLS implementation appears to blindly insert the > whole chore of TLS extensions into *ANY* TLSv1.0 ClientHello, including > TLS extension SNI, and this causes the my server, based on the requirement > quoted above, to reject the resumption request and require a full handshake > instead Hi Martin, I understand your description of the problem up to this point. > ... which requires a new connection ... which appears to > result in another SSL 2.0 CLIENT-HELLO to be used ... But I don't understand why your server or the browser requires a new connection. Your server and the browser should be able to complete a full handshake from the TLSv1.0 ClientHello, and once that full handshake succeeds, a new TLSv1.0 ClientHello, if any, to resume the new session should be able to succeed. Why does that not happen? Thanks, Wan-Teh From mrex@sap.com Mon Jan 14 12:06:25 2013 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 B78CC21F8B8B for ; Mon, 14 Jan 2013 12:06:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.168 X-Spam-Level: X-Spam-Status: No, score=-10.168 tagged_above=-999 required=5 tests=[AWL=0.081, 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 kCKHx7kwszXm for ; Mon, 14 Jan 2013 12:06:25 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id ADD4121F8B8A for ; Mon, 14 Jan 2013 12:06:24 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r0EK6MAi024141 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 14 Jan 2013 21:06:22 +0100 (MET) In-Reply-To: To: Wan-Teh Chang Date: Mon, 14 Jan 2013 21:06:22 +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: <20130114200622.0CDD01A455@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] TLSextSNI - initial SSL 2.0 Hello and session resume 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: Mon, 14 Jan 2013 20:06:25 -0000 Wan-Teh Chang wrote: > > Martin Rex wrote: > > > > The effect of this configuration is, that the browser starts every > > initial handshake with an SSL 2.0 CLIENT-HELLO, offering TLS, > > which will result result in a TLSv1.0 full handshake. Since there > > is no room for TLS extensions in a SSL 2.0 CLIENT-HELLO, the session > > is marked as being established without SNI. > > > > On the very next handshake, the browser proposed to resume that session, > > which per TLS spec requires a TLS ClientHello including the session ID. > > Now that Brower's TLS implementation appears to blindly insert the > > whole chore of TLS extensions into *ANY* TLSv1.0 ClientHello, including > > TLS extension SNI, and this causes the my server, based on the requirement > > quoted above, to reject the resumption request and require a full handshake > > instead > > Hi Martin, > > I understand your description of the problem up to this point. > > > ... which requires a new connection ... which appears to > > result in another SSL 2.0 CLIENT-HELLO to be used ... > > But I don't understand why your server or the browser requires a new > connection. Your server and the browser should be able to complete a > full handshake from the TLSv1.0 ClientHello, and once that full > handshake succeeds, a new TLSv1.0 ClientHello, if any, to resume the > new session should be able to succeed. > > Why does that not happen? While it is correct (as I admitted in my followup message to the list), that I could have avoided a new connection, and unless the client side TLS session cache management isn't fundamentally braindead, it would purge the TLS session for which the server refused the resumption from the client-side session cache, and sessions derived from the failed resume full handshake would be established with the correct server name and therefore not exhibit the "wash, rinse, repeat" failure cycle. Btw. The particular browser in this scenario was doing the fallback reconnect just fine. (The browser will have to, or otherwise experience connectivity problems with Extensions-intolerant TLS servers.) The performance problem that worries me is created by the TLS full handshake, rather than the necessesity having to establish a new network connection. TLS full handshakes, in particular with newer 2048-bit RSA server certs, hit a TLS server *much* harder than connection failures. The other problem is that clients will be requesting inconsistent semantics when proposing TLS session resumption in combination with a server_name in TLS extension SNI that is different from the server name than what was used to establish the connection for which session resumption is proposed. That is a defect in the TLS client that may appear to be acceptable to an implementor based on a defective client requirement (SHOULD, where a MUST is necessary) in rfc6066. -Martin From mrex@sap.com Tue Jan 22 15:44:46 2013 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 9F00D21F8B0C for ; Tue, 22 Jan 2013 15:44:46 -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=[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 YnMjANK3N8P9 for ; Tue, 22 Jan 2013 15:44:45 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 5310221F8AF8 for ; Tue, 22 Jan 2013 15:44:45 -0800 (PST) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r0MNig2D005319 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 23 Jan 2013 00:44:42 +0100 (MET) In-Reply-To: <20130114200622.0CDD01A455@ld9781.wdf.sap.corp> To: mrex@sap.com Date: Wed, 23 Jan 2013 00:44:42 +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: <20130122234442.AB7361A473@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] TLSextSNI - initial SSL 2.0 Hello and session resume 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, 22 Jan 2013 23:44:46 -0000 I change the code and did some more testing. I now believe that TLS extension SNI is mis-specified. Martin Rex wrote: > > Btw. The particular browser in this scenario was doing the fallback > reconnect just fine. (The browser will have to, or otherwise experience > connectivity problems with Extensions-intolerant TLS servers.) After reproducing the issue in my "testbed", I realized that the Web-browsers fallback upon the handshake failure didn't happen as expected (I got broken images). > > The performance problem that worries me is created by the TLS full > handshake, rather than the necessesity having to establish a new > network connection. TLS full handshakes, in particular with newer > 2048-bit RSA server certs, hit a TLS server *much* harder than > connection failures. The full-handshake is what worries me most. I changed the code to make a full handshake whenever the server_name in the ClientHello resumption proposal does not match the server_name in from the initial handshake that created the session. For this particular (pretty common Web-Browser), when SSL 2.0 is activated, it results in 4 full handshakes and 3 useless sessions in the servers TLS session cache. This is silly, because it works with a single session when the server continues to ignore TLS extension SNI (purposely or due to not implementing it). So I've changed the code again, and I will now essentially ignore the server_name on session resumption, resulting in the same behaviour as before implementing TLS extension SNI. One of the several problems of TLS ext SNI is that rfc3546 did not specify what the server should do on session resumption, and one of the _options_ that rfc3546 appears to offer is sending an unrecognized_name alert, either as Warning or Fatal: If the server understood the client hello extension but does not recognize the server name, it SHOULD send an "unrecognized_name" alert (which MAY be fatal). While rfc6066 tries to be more clear about the session resumption scenario, it is actually specifying the wrong thing to do: When the server is deciding whether or not to accept a request to resume a session, the contents of a server_name extension MAY be used in the lookup of the session in the session cache. The client SHOULD include the same server_name extension in the session resumption request as it did in the full handshake that established the session. A server that implements this extension MUST NOT accept the request to resume the session if the server_name extension contains a different name. Instead, it proceeds with a full handshake to establish a new session. When resuming a session, the server MUST NOT include a server_name extension in the server hello. Rather than prohibiting a session resume on a server_name mismatch, which by itself is irrelevant (and not backwards-compatible), it should instead have referred to the _server_credential_. In the specific case when the particular server credential/cert associated with a cached session differs from the server credential/cert that would be used when performing a full handshake, the session resume should be denied and a full handshake performed instead. In my TLS server implementation, the TLS stack itself is not aware of which credentials are in use by a particular server/service, the management of credentials is performed by the middleware on top of the TLS stack, and the TLS session cache is bound to the credentials, rather than being a global resource. And if one specific credential is administratively changed all further connections will use the new credential which has its own session cache, independent from earlier incarnations of the credential. So for my implementation, the desire not to resume a TLS session when a full handshake would result in the use of a different (server) credential is already an implied side-effect of my credential and session cache management, a comparison of server_name values is irrelevant, and might impair interop or performance. > > The other problem is that clients will be requesting inconsistent > semantics when proposing TLS session resumption in combination with > a server_name in TLS extension SNI that is different from the server > name than what was used to establish the connection for which session > resumption is proposed. That is a defect in the TLS client that > may appear to be acceptable to an implementor based on a defective > client requirement (SHOULD, where a MUST is necessary) in rfc6066. While I consider the behaviour of that particular Web Browser on my personal scorecard, the problem affects only servers that try to implement TLS extension SNI _as_specified_. Ignoring backwards compatibility and ignoring a significant installed base both seem not very reasonable, so I'm choosing a middle ground between the three of (rfc3546, rfc4366, rfc6066). Being anal about the exact wording of rfc6066 about comparing server_name on session resumption would be counter-productive to interop. -Martin From Bert.Greevenbosch@huawei.com Tue Jan 22 17:28:17 2013 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 0E31121F8694 for ; Tue, 22 Jan 2013 17:28:17 -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=[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 P96OG82MHUa9 for ; Tue, 22 Jan 2013 17:28:16 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 34C7121F85D2 for ; Tue, 22 Jan 2013 17:28:16 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ANU07319; Wed, 23 Jan 2013 01:28:15 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 23 Jan 2013 01:28:01 +0000 Received: from SZXEML410-HUB.china.huawei.com (10.82.67.137) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 23 Jan 2013 01:28:14 +0000 Received: from SZXEML509-MBX.china.huawei.com ([10.82.67.37]) by szxeml410-hub.china.huawei.com ([10.82.67.137]) with mapi id 14.01.0323.007; Wed, 23 Jan 2013 09:28:11 +0800 From: Bert Greevenbosch To: "tls@ietf.org" Thread-Topic: OSCP-lite Thread-Index: Ac35COeRE2A46AW/QumeeBirSYk90Q== Date: Wed, 23 Jan 2013 01:28:11 +0000 Message-ID: <46A1DF3F04371240B504290A071B4DB63CB70436@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_46A1DF3F04371240B504290A071B4DB63CB70436szxeml509mbx_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [TLS] OSCP-lite 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, 23 Jan 2013 01:28:17 -0000 --_000_46A1DF3F04371240B504290A071B4DB63CB70436szxeml509mbx_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, Some weeks ago, I have uploaded the following contribution: http://www.ietf.org/internet-drafts/draft-greevenbosch-tls-ocsp-lite-00.txt The draft specifies an OCSP-lite responder. It is meant for revocation of r= aw public keys. Since I uploaded the draft during the winter holidays, I thought it would b= e good to send another announcement now. :-) Your feedback is welcome! Best regards, Bert --_000_46A1DF3F04371240B504290A071B4DB63CB70436szxeml509mbx_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi all,

 

Some weeks ago, I have uploaded the following contri= bution:

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

 

The draft specifies an OCSP-lite responder. It is me= ant for revocation of raw public keys.

 

Since I uploaded the draft during the winter holiday= s, I thought it would be good to send another announcement now. :-)

 

Your feedback is welcome!

 

Best regards,

Bert

 

--_000_46A1DF3F04371240B504290A071B4DB63CB70436szxeml509mbx_-- From d.thakore@cablelabs.com Thu Jan 24 09:56:58 2013 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 22B1F21F84F6 for ; Thu, 24 Jan 2013 09:56:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] 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 6duNv3GrJeZ7 for ; Thu, 24 Jan 2013 09:56:57 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id B186E21F84F3 for ; Thu, 24 Jan 2013 09:56:55 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id r0OHur7V030351 for ; Thu, 24 Jan 2013 10:56:53 -0700 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Thu, 24 Jan 2013 10:56:53 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.02.0298.004; Thu, 24 Jan 2013 10:56:53 -0700 From: Darshak Thakore To: "tls@ietf.org" Thread-Topic: new version of draft-dthakore-tls-authz Thread-Index: AQHN+lww1j1ydBJL9UG687qxsPpFQA== Date: Thu, 24 Jan 2013 17:56:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.5.0.27] Content-Type: multipart/alternative; boundary="_000_CD25A7079B11dthakorecablelabscom_" MIME-Version: 1.0 X-Approved: ondar Subject: [TLS] new version of draft-dthakore-tls-authz 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, 24 Jan 2013 17:56:58 -0000 --_000_CD25A7079B11dthakorecablelabscom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, I have uploaded a new version of the draft that specifies a new Supplementa= lData authorization extension to exchange DTCP Certificates. This version addresses a number of comments that were received during the I= ETF-85 meeting and subsequently on the mailing list. The following points are addressed in the new draft 1. Added details about the format of DTCP Certificates and provided sect= ion references to the DTCP Specs. This should help readers navigate to the = relevant parts of the DTCP Spec more easily since most of the information i= n the DTCP Specs is irrelevant to this I-D (besides the actual DTCP certifi= cate details) 2. Added a section to explain the use cases for this TLS extension and h= ow it allows devices with existing DTCP Certificates to leverage it for dif= ferent uses (besides its use and independent of its use for content protect= ion) 3. Provided clarification that this extension is only meant to exchange = DTCP certificates as additional authorization information during a TLS exch= ange. It is *not* meant to tunnel any secondary protocol within TLS, nor do= es it replace the role of X.509 certificates in the TLS protocol 4. Provided clarification in Section 3.2 about the dtcp_authz_data stuct I would greatly appreciate any comments/feedback on it. Best Regards, Darshak --_000_CD25A7079B11dthakorecablelabscom_ Content-Type: text/html; charset="us-ascii" Content-ID: <48732FF0BA87A1429550D8D07898148E@cablelabs.com> Content-Transfer-Encoding: quoted-printable
Hello all,

I have uploaded a new version of the draft that specifies a new Supple= mentalData authorization extension to exchange DTCP Certificates. 
This version addresses a number of comments that were received during = the IETF-85 meeting and subsequently on the mailing list.

The following points are addressed in the new draft
  1. Added details about the format of DTCP Certificates and provided sectio= n references to the DTCP Specs. This should help readers navigate to the re= levant parts of the DTCP Spec more easily since most of the information in = the DTCP Specs is irrelevant to this I-D (besides the actual DTCP certificate details)
  2. Added a sec= tion to explain the use cases for this TLS extension and how it allows devi= ces with existing DTCP Certificates to leverage it for different uses (besi= des its use and independent of its use for content protection)
  3. Prov= ided clarification that this extension is only meant to exchange DTCP certi= ficates as additional authorization information during a TLS exchange. It i= s *not* meant to tunnel any secondary protocol within TLS, nor does it repl= ace the role of X.509 certificates in the TLS protocol
  4. Provided clarification in Section 3.2 about th= e dtcp_authz_data stuct

I would greatly appreciate any comments/feedback on it.

Best Regards,
Darshak
--_000_CD25A7079B11dthakorecablelabscom_-- From mark@redphonesecurity.com Thu Jan 24 13:42:19 2013 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 E77AF21F857D for ; Thu, 24 Jan 2013 13:42:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 AMG5qPV9AleM for ; Thu, 24 Jan 2013 13:42:18 -0800 (PST) Received: from g2host.com (mailfront4.g2host.com [208.42.184.242]) by ietfa.amsl.com (Postfix) with ESMTP id BB8421F0CAF for ; Thu, 24 Jan 2013 13:42:17 -0800 (PST) Received: from [24.118.98.157] (account mkbrown@visi.com HELO RPUD4) by mailfront4.g2host.com (CommuniGate Pro SMTP 5.3.11) with ESMTPA id 94452244; Thu, 24 Jan 2013 15:42:16 -0600 From: "Mark Brown" To: "'Darshak Thakore'" , References: In-Reply-To: Date: Thu, 24 Jan 2013 15:42:18 -0600 Message-ID: <003601cdfa7b$af477670$0dd66350$@redphonesecurity.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0037_01CDFA49.64AE8D10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLwwOpJzU0i14Fa6aUJh7dPD78W6pYTV+YA Content-Language: en-us Subject: Re: [TLS] new version of draft-dthakore-tls-authz 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, 24 Jan 2013 21:42:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0037_01CDFA49.64AE8D10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Darshak, I'm still concerned with replay attacks, despite the updates. The structures in 3.2 haven't changed materially, and the explanations make me more sure there's this problem: the specified RandomNonce won't prevent replay attacks. You might consider prior protocol analyses, for example this paper: http://www2.cs.uidaho.edu/~jimaf/papers/replay02.pdf To (over)simplify, follow the example of TLS CertificateVerify used for client authentication: instead of an arbitrary nonce, take a hash over *all* of the handshake messages sent/received so far (i.e. the output from the hash function run over these concatenated messages). Doing so gives a more useful session-identifying "nonce". Since the session messages "so far at this point" include client nonce, server nonce and server certificate, I'd estimate that you've overcome the 1995 Lowe attack (see http://en.wikipedia.org/wiki/Needham%E2%80%93Schroeder_protocol#Fixing_the_m an-in-the-middle_attack ). How to say this well? The text for CV gives a template, see: http://tools.ietf.org/html/rfc5246#section-7.4.8. Your structures might be: The set of all Handshake Messages in the run so far, using http://tools.ietf.org/html/rfc5246#section-7.4 : handshake_hash = Hash(handshake_messages); Your client_authz must contain an assertion as a component, such as: struct { opaque handshake_hash[hash_length]; opaque DTCPCert<1..2^24-1>; [[opaque ASN.1Cert<1..2^24-1>]]; } DTCPClientAssertion; Your client_authz SupplementalData message should contain the assertion plus its signature, e.g.: assertion_hash = Hash(DTCPClientAssertion); signature = ECDSA_Sign(assertion_hash); struct { DTCPClientAuthz client_assertion; opaque signature<1..2^16-1>; } dtcp_authz_data; This last struct is very similar to http://tools.ietf.org/html/rfc5246#section-4.7 "DigitallySigned", but omits the SignatureAndHashAlgorithm identifier for two reasons: 1) the signature and hash algorithms are DTCP's not TLS's and so the registry and code points may differ 2) the DTCPClientAssertion.DTCPCert should contain this information, and currently it's a mandatory-include part of the message. At this point, I've only presented an assertion that's appropriate for client_authz, but I think that's all that *should* be specified. I would eliminate sending server_authz from the server to the client for your use case. Sincerely, mark ------=_NextPart_000_0037_01CDFA49.64AE8D10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Darshak,

 

I’m still concerned with replay attacks, despite the updates. =

 

The structures in 3.2 haven’t changed materially, and the = explanations make me more sure there’s this problem: the specified = RandomNonce won’t prevent replay attacks. You might consider prior = protocol analyses, for example this paper: http://www2= .cs.uidaho.edu/~jimaf/papers/replay02.pdf

 

To (over)simplify, follow the example of TLS CertificateVerify used = for client authentication: instead of an arbitrary nonce, take a hash = over *all* of the handshake messages sent/received so far (i.e. = the output from the hash function run over these concatenated messages). = Doing so gives a more useful session-identifying =  “nonce”. Since the session messages “so far at = this point” include client nonce, server nonce and server = certificate, I’d estimate that you’ve overcome the 1995 Lowe = attack (see http://en.wikipedia.org/wiki/Needham%= E2%80%93Schroeder_protocol#Fixing_the_man-in-the-middle_attack = ).

 

How to say this well? The text for CV gives a template, see: http://tools.ie= tf.org/html/rfc5246#section-7.4.8.

Your structures might be:

 

           &nbs= p;    The set of all Handshake Messages in the run so = far, using http://tools.ietf= .org/html/rfc5246#section-7.4 :

         =
handshake_hash =
     =3D =
Hash(handshake_messages);

 

           &nbs= p;    Your client_authz must contain an assertion as a = component, such as:

         = struct {

         &= nbsp;   opaque = handshake_hash[hash_length];

         &= nbsp;   opaque = DTCPCert<1..2^24-1>;

         &= nbsp;   [[opaque = ASN.1Cert<1..2^24-1>]];

         } = DTCPClientAssertion;

 

           &nbs= p;    Your client_authz SupplementalData message should = contain the assertion plus its signature, = e.g.:

         =
assertion_hash =
     =3D Hash(DTCPClientAssertion);
         =
signature =
         =3D =
ECDSA_Sign(assertion_hash);

 

         = struct {

         &= nbsp;   DTCPClientAuthz = client_assertion;

         &= nbsp;   opaque = signature<1..2^16-1>;

         } = dtcp_authz_data;

 

This last struct is very similar to http://tools.ietf=
.org/html/rfc5246#section-4.7 “DigitallySigned”, but omits the SignatureAndHashAlgorithm identifier for two =
reasons: 1) the signature and hash algorithms are DTCP’s not =
TLS’s and so the registry and code points may differ 2) the =
DTCPClientAssertion.DTCPCert should contain this information, and =
currently it’s a mandatory-include part of the =
message.

 

At this point, I’ve only presented an assertion that’s = appropriate for client_authz, but I think that’s all that = *should* be specified. I would eliminate sending server_authz = from the server to the client for your use case. =

 

Sincerely,

mark

------=_NextPart_000_0037_01CDFA49.64AE8D10-- From n.mavrogiannopoulos@gmail.com Fri Jan 25 02:57:06 2013 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 4FA5E21F8809 for ; Fri, 25 Jan 2013 02:57:06 -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 2MDBND9ln6sA for ; Fri, 25 Jan 2013 02:57:05 -0800 (PST) Received: from mail-ee0-f54.google.com (mail-ee0-f54.google.com [74.125.83.54]) by ietfa.amsl.com (Postfix) with ESMTP id C51B121F85CC for ; Fri, 25 Jan 2013 02:57:00 -0800 (PST) Received: by mail-ee0-f54.google.com with SMTP id c41so122923eek.41 for ; Fri, 25 Jan 2013 02:57:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received: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=IP+7CV7WSd5QZytMCB+zJTeMLRdwoTZKKsoEuib0KXw=; b=gR+Pz01r9InKRu3QOEFPVWR3+09eWr/k0yi6rbOqRkg4H7Wtm1vdq93yvOE4LBh7hZ IMmnDpJqNcnXoQaopMBT26QZoZUenZRapWweW5A/sREw2QPluB9NivGt6YSVZFsbO+MF XChduThRqqfDKsuU0R+KpI8xJqfEZnml1CHetiz9EFqViHiK689T1PbwJa5GNZBlEcUM U6o9bzSFZn77f6LI6Y1EOj2KZmNEf5ka3pdzmknZYgui9vNOOH74yw2O6KiQymC6uwiv DwqadB1q9BZnpVKPnzV8IgDzk/y/HqlkdT+srb/9ultqXPc3PGGSzXsOKAJzX++flLaf G5Bw== X-Received: by 10.14.194.195 with SMTP id m43mr16791758een.44.1359111419920; Fri, 25 Jan 2013 02:56:59 -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 t4sm1083329eel.0.2013.01.25.02.56.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 25 Jan 2013 02:56:59 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <510264F5.1090301@gnutls.org> Date: Fri, 25 Jan 2013 11:56:53 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.11) Gecko/20121122 Icedove/10.0.11 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] new version of draft-dthakore-tls-authz 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, 25 Jan 2013 10:57:06 -0000 On 01/24/2013 06:56 PM, Darshak Thakore wrote: > Hello all, > > I have uploaded a new version of the draft that specifies a new SupplementalData authorization extension to exchange DTCP Certificates. > This version addresses a number of comments that were received during the IETF-85 meeting and subsequently on the mailing list. > > The following points are addressed in the new draft > > 1. Added details about the format of DTCP Certificates and provided section references to the DTCP Specs. This should help readers navigate to the relevant parts of the DTCP Spec more easily since most of the information in the DTCP Specs is irrelevant to this I-D (besides the actual DTCP certificate details) > 2. Added a section to explain the use cases for this TLS extension and how it allows devices with existing DTCP Certificates to leverage it for different uses (besides its use and independent of its use for content protection) > 3. Provided clarification that this extension is only meant to exchange DTCP certificates as additional authorization information during a TLS exchange. It is *not* meant to tunnel any secondary protocol within TLS, nor does it replace the role of X.509 certificates in the TLS protocol > 4. Provided clarification in Section 3.2 about the dtcp_authz_data stuct > > I would greatly appreciate any comments/feedback on it. Some comments: 1. What is the [[]] notation? You use it in: struct { opaque DTCPCert<1..2^24-1>; [[opaque ASN.1Cert<1..2^24-1>]]; opaque signature<1..2^16-1>; } DigitallySigned; and later you mention that the certificate is optional. If you want to make the certificate optional you do: struct { opaque DTCPCert<1..2^24-1>; opaque ASN.1Cert<0..2^24-1>; opaque signature<1..2^16-1>; } DigitallySigned; Otherwise your structure cannot be parsed (TLS structures are different from ASN.1). 2. How does the random nonce protect from replay attacks? My I understanding is that it isn't used at all. What kind of replay attacks are you considering at? Why use a new nonce and not the TLS nonces? 3. One cannot get an overview of your additions. I'd suggest another figure, similar to figure 1, that will focus on the exchange that is relevant only for your extension (that way it would be apparent what you are protecting with the nonce). e.g. ClientHello (with client_authz) --------> ServerHello(with server_authz) SupplementalData (with ???) 4. You say "cryptographically tie its dtcp_authz_data with the TLS session being established." How do you mean by cryptographically tie? (usually such a phrase implies a commitment - e.g., a signature)) regards, Nikos From d.thakore@cablelabs.com Sun Jan 27 17:12:10 2013 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 8EF7A21F8F30 for ; Sun, 27 Jan 2013 17:12:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001] 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 sc5J6zZKUU3l for ; Sun, 27 Jan 2013 17:12:09 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id 7EDBC21F8D75 for ; Sun, 27 Jan 2013 17:12:07 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id r0S1C5g4017665 for ; Sun, 27 Jan 2013 18:12:05 -0700 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Sun, 27 Jan 2013 18:12:05 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.02.0328.009; Sun, 27 Jan 2013 18:12:05 -0700 From: Darshak Thakore To: "tls@ietf.org" Thread-Topic: [TLS] new version of draft-dthakore-tls-authz Thread-Index: AQHN+lww1j1ydBJL9UG687qxsPpFQJhZd/0AgAR8PwA= Date: Mon, 28 Jan 2013 01:12:05 +0000 Message-ID: <0E515E8C52A54F4DBDF51AB79386333517F3EC6B@EXCHANGE.cablelabs.com> In-Reply-To: <003601cdfa7b$af477670$0dd66350$@redphonesecurity.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.5.0.27] Content-Type: multipart/alternative; boundary="_000_0E515E8C52A54F4DBDF51AB79386333517F3EC6BEXCHANGEcablela_" MIME-Version: 1.0 X-Approved: ondar Subject: Re: [TLS] new version of draft-dthakore-tls-authz 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, 28 Jan 2013 01:12:11 -0000 --_000_0E515E8C52A54F4DBDF51AB79386333517F3EC6BEXCHANGEcablela_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi Mark, Thanks for the feedback and the link to the paper. I agree that the dtcp_au= thz_data structure currently defined excludes the RandomNonce (or the equiv= alent running hash as you suggested) out of the signature and it should hav= e included it. I can update the struct accordingly. Given that modification= , would there still be a need to put in a running hash of all the messages? My primary concern with including a running hash in the struct is that this= structure is a payload of the SupplementalData message and as per RFC4680,= it is an application's responsibility to provide this information. I'm not= sure if we can assume that an application always has access to all message= s at the TLS protocol layer. Also one point of clarification, the client will not be generating its own = nonce, rather it will take the nonce it has received from the server in the= server's SupplementalData message and include it in its own SupplementalDa= ta message. With that modification, the struct would be something like struct { opaque random_bytes[32]; } RandomNonce; struct { RandomNonce nonce; opaque DTCPCert<1..2^24-1>; opaque ASN.1Cert<0..2^24-1>; } DigitallySigned; struct { DigitallySigned certs; opaque signature[40]; } dtcp_authz_data; When the server sends this in its SupplementalData message, it will generat= e the RandomNonce. When the client sends back its own SupplementalData mess= age, it will include the one it received from the server. With that, if we only consider the scenario of the client sending its DTCP = Certificate, there are two possible options, one in which the client is als= o using its X.509 certificate (i.e. it will send its ClientCertificate and = CertificateVerify messages also) and the other is where the client does not= have an X.509 certificate to send. For the first case, an example exchange would be something like: 1. Client sends ClientHello, Server Sends ServerHello 2. Server sends SupplementalData that only has a RandomNonce (N1) 3. Server sends Certificate, CertificateRequest and ServerHelloDone 4. Client sends SupplementalData that has [(N1, DTCP Cert, X.509 Cert) S= ignature covering all three elements] 5. Client sends Certificate message (needs to be the same X.509 Cert as = above) 6. Client sends ClientKeyExchange, ChangeCipherSpec and Finished 7. Server sends ChangeCipherSpec and Finished Would this address the replay attack? Regards, Darshak From: Mark Brown > Date: Thursday, January 24, 2013 2:42 PM To: Darshak Thakore >, "tls@ietf.org" > Subject: RE: [TLS] new version of draft-dthakore-tls-authz Hi Darshak, I=92m still concerned with replay attacks, despite the updates. The structures in 3.2 haven=92t changed materially, and the explanations ma= ke me more sure there=92s this problem: the specified RandomNonce won=92t p= revent replay attacks. You might consider prior protocol analyses, for exam= ple this paper: http://www2.cs.uidaho.edu/~jimaf/papers/replay02.pdf To (over)simplify, follow the example of TLS CertificateVerify used for cli= ent authentication: instead of an arbitrary nonce, take a hash over *all* o= f the handshake messages sent/received so far (i.e. the output from the has= h function run over these concatenated messages). Doing so gives a more use= ful session-identifying =93nonce=94. Since the session messages =93so far = at this point=94 include client nonce, server nonce and server certificate,= I=92d estimate that you=92ve overcome the 1995 Lowe attack (see http://en.= wikipedia.org/wiki/Needham%E2%80%93Schroeder_protocol#Fixing_the_man-in-the= -middle_attack ). How to say this well? The text for CV gives a template, see: http://tools.i= etf.org/html/rfc5246#section-7.4.8. Your structures might be: The set of all Handshake Messages in the run so far, using = http://tools.ietf.org/html/rfc5246#section-7.4 : handshake_hash =3D Hash(handshake_messages); Your client_authz must contain an assertion as a component,= such as: struct { opaque handshake_hash[hash_length]; opaque DTCPCert<1..2^24-1>; [[opaque ASN.1Cert<1..2^24-1>]]; } DTCPClientAssertion; Your client_authz SupplementalData message should contain t= he assertion plus its signature, e.g.: assertion_hash =3D Hash(DTCPClientAssertion); signature =3D ECDSA_Sign(assertion_hash); struct { DTCPClientAuthz client_assertion; opaque signature<1..2^16-1>; } dtcp_authz_data; This last struct is very similar to http://tools.ietf.org/html/rfc5246#sect= ion-4.7 =93DigitallySigned=94, but omits the SignatureAndHashAlgorithm iden= tifier for two reasons: 1) the signature and hash algorithms are DTCP=92s n= ot TLS=92s and so the registry and code points may differ 2) the DTCPClient= Assertion.DTCPCert should contain this information, and currently it=92s a = mandatory-include part of the message. At this point, I=92ve only presented an assertion that=92s appropriate for = client_authz, but I think that=92s all that *should* be specified. I would = eliminate sending server_authz from the server to the client for your use c= ase. Sincerely, mark --_000_0E515E8C52A54F4DBDF51AB79386333517F3EC6BEXCHANGEcablela_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Mark,

Thanks for the feedback and the link to the paper. I agree that the dt= cp_authz_data structure currently defined excludes the RandomNonce (or the = equivalent running hash as you suggested) out of the signature and it shoul= d have included it. I can update the struct accordingly. Given that modification, would there still be a ne= ed to put in a running hash of all the messages? 
My primary concern with including a running hash in the struct is that= this structure is a payload of the SupplementalData message and as per RFC= 4680, it is an application's responsibility to provide this information. I'= m not sure if we can assume that an application always has access to all messages at the TLS protocol layer= . 

Also one point of clarification, the client will not be generating its= own nonce, rather it will take the nonce it has received from the server i= n the server's SupplementalData message and include it in its own Supplemen= talData message.

With that modification, the struct would be something like 

      struct {          
          opaque random_bytes[32];
      } RandomNonce;

      struct {
          RandomNonce nonce; 
          opaque DTCPCert<1..2^24-1>;
          opaque ASN.1Cert<0..2^24-1>;<= /div>
      } DigitallySigned;
              
      struct {
          DigitallySigned certs;
          opaque signature[40];   <= /div>
      } dtcp_authz_data;

When the server sends this in its SupplementalData message, it will ge= nerate the RandomNonce. When the client sends back its own SupplementalData= message, it will include the one it received from the server.

With that, if we only consider the scenario of the client sending its = DTCP Certificate, there are two possible options, one in which the client i= s also using its X.509 certificate (i.e. it will send its ClientCertificate= and CertificateVerify messages also) and the other is where the client does not have an X.509 certificate= to send.
For the first case, an example exchange would be something like:
  1. Client sends ClientHello, Server Sends ServerHello
  2. Server sends= SupplementalData that only has a RandomNonce (N1)
  3. Server sends Cer= tificate, CertificateRequest and ServerHelloDone
  4. Client sends Suppl= ementalData that has [(N1, DTCP Cert, X.509 Cert) Signature covering all th= ree elements]
  5. Client sends Certificate message (needs to be the sam= e X.509 Cert as above) 
  6. Client sends ClientKeyExchange, Change= CipherSpec and Finished
  7. Server sends ChangeCipherSpec and Finished<= /li>

Would this address the replay attack?

Regards,
Darshak


From: Mark Brown <mark@redphonesecurity.com>
Date: Thursday, January 24, 2013 2:= 42 PM
To: Darshak Thakore <d.thakore@cablelabs.com>, "tls@ietf.org" <tls@ietf.org>
Subject: RE: [TLS] new version of d= raft-dthakore-tls-authz

Hi Darshak,

 

I=92m still concerned with replay = attacks, despite the updates.

 

The structures in 3.2 haven=92t ch= anged materially, and the explanations make me more sure there=92s this pro= blem: the specified RandomNonce won=92t prevent replay attacks. You might consider prior protocol analyses, for example th= is paper: http://www= 2.cs.uidaho.edu/~jimaf/papers/replay02.pdf

 

To (over)simplify, follow the exam= ple of TLS CertificateVerify used for client authentication: instead of an = arbitrary nonce, take a hash over *all* of the handshake messages sent/received so far (i.e. the output from the h= ash function run over these concatenated messages). Doing so gives a more u= seful session-identifying  =93nonce=94. Since the session messages =93= so far at this point=94 include client nonce, server nonce and server certificate, I=92d estimate that you=92ve overcome= the 1995 Lowe attack (see http://en.wikipedia.org/wiki/Needham%E2%80%93Schroeder_protocol#Fixing_the_= man-in-the-middle_attack ).

 

How to say this well? The text for= CV gives a template, see: http://tools.i= etf.org/html/rfc5246#section-7.4.8.

Your structures might be:

 

     &nbs= p;          The set of all Han= dshake Messages in the run so far, using http://tools.iet= f.org/html/rfc5246#section-7.4 :

 &=
nbsp;       handshake_hash      =3D Hash(handsh=
ake_messages);

 

     &nbs= p;          Your client_authz = must contain an assertion as a component, such as:

         struct {=

           &n= bsp; opaque handshake_hash[hash_length];

           &n= bsp; opaque DTCPCert<1..2^24-1>;

           &n= bsp; [[opaque ASN.1Cert<1..2^24-1>]];

         } DTCPClientAsserti= on;

 

     &nbs= p;          Your client_authz = SupplementalData message should contain the assertion plus its signature, e= .g.:

 &=
nbsp;       assertion_hash      =3D Hash(DTCPClientAssertion);
 &=
nbsp;       signature        &nbs=
p; =3D ECDSA_Sign(assertion_hash<=
span style=3D"font-size:12.0pt;color:black">);

 

         struct {=

           &n= bsp; DTCPClientAuthz client_assertion;

           &n= bsp; opaque signature<1..2^16-1>;

         } dtcp_authz_data;<= o:p>

 

This last struct =
is very similar to http://tools.ietf.org/html/rfc5246#section-4.7 =93DigitallySigned=
=94, but omits the SignatureAndHashAlgorithm identifier for two reasons: 1)=
 the signature and hash algorithms are DTCP=92s not TLS=92s and so the regi=
stry and code points may differ 2) the DTCPClientAssertion.DTCPCert should =
contain this information, and currently it=92s a mandatory-include part of =
the message.=

 

At this point, I=92ve only present= ed an assertion that=92s appropriate for client_authz, but I think that=92s= all that *should* be specified. I would eliminate sending server_authz from the server to the client for you= r use case.

 

Sincerely,

mark

 --_000_0E515E8C52A54F4DBDF51AB79386333517F3EC6BEXCHANGEcablela_-- From d.thakore@cablelabs.com Sun Jan 27 17:40:46 2013 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 2F7F321F8809 for ; Sun, 27 Jan 2013 17:40:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, HELO_EQ_MODEMCABLE=0.768, HOST_EQ_MODEMCABLE=1.368] 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 RFN9vP3A17bZ for ; Sun, 27 Jan 2013 17:40:45 -0800 (PST) Received: from ondar.cablelabs.com (ondar.cablelabs.com [192.160.73.61]) by ietfa.amsl.com (Postfix) with ESMTP id BA39921F87FA for ; Sun, 27 Jan 2013 17:40:44 -0800 (PST) Received: from kyzyl.cablelabs.com (kyzyl [10.253.0.7]) by ondar.cablelabs.com (8.14.5/8.14.5) with ESMTP id r0S1ehxS019303 for ; Sun, 27 Jan 2013 18:40:43 -0700 Received: from exchange.cablelabs.com (10.5.0.19) by kyzyl.cablelabs.com (F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com); Sun, 27 Jan 2013 18:40:43 -0700 (MST) X-Virus-Status: clean(F-Secure/fsigk_smtp/407/kyzyl.cablelabs.com) Received: from EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee]) by EXCHANGE.cablelabs.com ([fe80::797a:96d1:3c53:18ee%11]) with mapi id 14.02.0328.009; Sun, 27 Jan 2013 18:40:43 -0700 From: Darshak Thakore To: "tls@ietf.org" Thread-Topic: [TLS] new version of draft-dthakore-tls-authz Thread-Index: AQHN+lww1j1ydBJL9UG687qxsPpFQJhaVf6AgAOmPgA= Date: Mon, 28 Jan 2013 01:40:43 +0000 Message-ID: <0E515E8C52A54F4DBDF51AB79386333517F3FCA1@EXCHANGE.cablelabs.com> In-Reply-To: <510264F5.1090301@gnutls.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.5.121010 x-originating-ip: [10.5.0.27] Content-Type: text/plain; charset="us-ascii" Content-ID: <811EEA5E6612084A8FA4CE183B6BA4B7@cablelabs.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Approved: ondar Subject: Re: [TLS] new version of draft-dthakore-tls-authz 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, 28 Jan 2013 01:40:46 -0000 Hi Nikos, On #1, Yes the intent of the [[]] was to make the certificate optional. Thanks for the suggestion, i've changed that and will get reflected in the next draft. On #2, In my earlier response to Mark's comments, i provided a sample TLS exchange that shows how the nonce is used. The reason a separate nonce is specified is because an application that is generating the SupplementalData payload may not have access to the TLS nonces. The server generates the nonce and the client will include it in its dtcp_authz_data payload. With the update mentioned in the earlier email, the signature that the client includes in its SupplementalData message will cover the nonce also along with its DTCP Cert and the optional X.509 cert. On #3, I can include a figure that demonstrates the example exchange i included earlier. Should something like that go into the appendix? On #4, When a client sends a SupplementalData payload like [(Nonce, DTCP Cert, X.509 Cert) Signature covering the three elements] followed by a Certificate message that includes the same X.509 Cert used above, a server can verify that the possessor of the X.509 Certificate also posseses the DTCP Cert (proven by the Signature above generated using the private key associated with the DTCP Cert). Regards, Darshak=20 On 1/25/13 3:56 AM, "Nikos Mavrogiannopoulos" wrote: >On 01/24/2013 06:56 PM, Darshak Thakore wrote: > >> Hello all, >>=20 >> I have uploaded a new version of the draft that specifies a new >>SupplementalData authorization extension to exchange DTCP Certificates. >> This version addresses a number of comments that were received during >>the IETF-85 meeting and subsequently on the mailing list. >>=20 >> The following points are addressed in the new draft >>=20 >> 1. Added details about the format of DTCP Certificates and provided >>section references to the DTCP Specs. This should help readers navigate >>to the relevant parts of the DTCP Spec more easily since most of the >>information in the DTCP Specs is irrelevant to this I-D (besides the >>actual DTCP certificate details) >> 2. Added a section to explain the use cases for this TLS extension >>and how it allows devices with existing DTCP Certificates to leverage it >>for different uses (besides its use and independent of its use for >>content protection) >> 3. Provided clarification that this extension is only meant to >>exchange DTCP certificates as additional authorization information >>during a TLS exchange. It is *not* meant to tunnel any secondary >>protocol within TLS, nor does it replace the role of X.509 certificates >>in the TLS protocol >> 4. Provided clarification in Section 3.2 about the dtcp_authz_data >>stuct >>=20 >> I would greatly appreciate any comments/feedback on it. > > >Some comments: >1. What is the [[]] notation? > >You use it in: > struct { > opaque DTCPCert<1..2^24-1>; > [[opaque ASN.1Cert<1..2^24-1>]]; > opaque signature<1..2^16-1>; > } DigitallySigned; >and later you mention that the certificate is optional. If you want to >make the certificate optional you do: > struct { > opaque DTCPCert<1..2^24-1>; > opaque ASN.1Cert<0..2^24-1>; > opaque signature<1..2^16-1>; > } DigitallySigned; > >Otherwise your structure cannot be parsed (TLS structures are different >from ASN.1). > >2. How does the random nonce protect from replay attacks? My I >understanding is that it isn't used at all. What kind of replay attacks >are you considering at? Why use a new nonce and not the TLS nonces? > >3. One cannot get an overview of your additions. I'd suggest another >figure, similar to figure 1, that will focus on the exchange that is >relevant only for your extension (that way it would be apparent what you >are protecting with the nonce). > >e.g. > ClientHello (with client_authz) --------> > > ServerHello(with server_authz) > SupplementalData (with ???) > >4. You say "cryptographically tie its dtcp_authz_data with the TLS >session being established." > >How do you mean by cryptographically tie? (usually such a phrase implies >a commitment - e.g., a signature)) > >regards, >Nikos >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls From stephen.farrell@cs.tcd.ie Mon Jan 28 07:30:09 2013 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 D6ADA21F8786; Mon, 28 Jan 2013 07:30:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.299 X-Spam-Level: X-Spam-Status: No, score=-102.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, 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 IUwlEaFpUHhz; Mon, 28 Jan 2013 07:30:09 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 2707721F8763; Mon, 28 Jan 2013 07:30:09 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 87988BE33; Mon, 28 Jan 2013 15:29:47 +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 5R-obiGss9Zk; Mon, 28 Jan 2013 15:29:42 +0000 (GMT) Received: from [IPv6:2001:770:10:203:d03a:b6e9:52e7:3e1e] (unknown [IPv6:2001:770:10:203:d03a:b6e9:52e7:3e1e]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 254EABE6B; Mon, 28 Jan 2013 15:29:39 +0000 (GMT) Message-ID: <51069964.2070208@cs.tcd.ie> Date: Mon, 28 Jan 2013 15:29:40 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "tls@ietf.org" , Apps Discuss X-Enigmail-Version: 1.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [TLS] independent submission for IRC/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, 28 Jan 2013 15:30:10 -0000 Hiya, The IESG will do an RFC 5742 review of this [1] draft on Feb 7. The draft registers a port basically and says that that port is used for irc/tls. I reckon that it doesn't conflict with work that the IETF is doing. I'll probably have comments on the draft, but 5742 review is just to see that it doesn't conflict with work we're doing or plan to do (roughly, read the RFC if you care more) so my and other AD comments will be treated the same as anyone else's. If you have technical comments, I'm sure the authors and the independent submission editor would be interested in those, so send them that way rather than discuss them on these lists. (You can do that by sending a mail to: draft-hartmann-default-port-for-irc-via-tls-ssl@tools.ietf.org cc'ing rfc-ise@rfc-editor.org) *Please* don't reply to this unless your reply is relevant to the 5742 review. Cheers, S. [1] https://datatracker.ietf.org/doc/draft-hartmann-default-port-for-irc-via-tls-ssl/ From mark@redphonesecurity.com Mon Jan 28 12:57:02 2013 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 30B1A21F870E for ; Mon, 28 Jan 2013 12:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 Fm2QHGOU-GXJ for ; Mon, 28 Jan 2013 12:56:57 -0800 (PST) Received: from g2host.com (mailfront3.g2host.com [208.42.184.241]) by ietfa.amsl.com (Postfix) with ESMTP id BFF8D21F88A9 for ; Mon, 28 Jan 2013 12:56:55 -0800 (PST) Received: from [24.118.98.157] (account mkbrown@visi.com HELO RPUD4) by mailfront3.g2host.com (CommuniGate Pro SMTP 5.3.11) with ESMTPA id 95521295; Mon, 28 Jan 2013 14:56:54 -0600 From: "Mark Brown" To: "'Darshak Thakore'" , References: <003601cdfa7b$af477670$0dd66350$@redphonesecurity.com> <0E515E8C52A54F4DBDF51AB79386333517F3EC6B@EXCHANGE.cablelabs.com> In-Reply-To: <0E515E8C52A54F4DBDF51AB79386333517F3EC6B@EXCHANGE.cablelabs.com> Date: Mon, 28 Jan 2013 14:56:49 -0600 Message-ID: <018001cdfd99$fe5f6260$fb1e2720$@redphonesecurity.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0181_01CDFD67.B3C826B0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQG+k/Eiwehat1MRXRszyylUJ3hmS5h+A3eg Content-Language: en-us Subject: Re: [TLS] new version of draft-dthakore-tls-authz 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, 28 Jan 2013 20:57:02 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0181_01CDFD67.B3C826B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Darshak, Thanks for the solid response. Sounds like you're saying: 1) For server_authz you'll generate the RandomNonce message you specify below as a challenge in a challenge-response protocol 2) For client_authz you'll repeat the server's RandomNonce value, plus the certs you're interested in sending, within the envelope (so to speak) of that which is DigitallySigned (per your spec below) 3) To accomplish authorization, the server will verify the signature and validate the RandomNonce value as being "the value that I sent to this client." Does this overcome replay attacks? Not an easy question. We should consider if a MITM could splice in bad RandomNonce values or somehow gain advantage by replaying old signed ones. MITM would *have* to make the server believe that an old RandomNonce value, call it N1, was valid. It seems unlikely, IMO, unless MITM could force a collision such that server thought "Yeah, I just sent this N1 to the client," even when it was the same N1 value some client had signed a while ago. This seems reasonably safe when considering your suggestions from a protocol point of view. So far, then, I think your suggestions are just fine, IMO. How about when considering the implementation point of view? Did you assume that the application layer is going to implement the random number generator (RNG) and the store of N1, N2, . corresponding to TLS handshake H1, H2, . in a "hardened" way? Where I'm headed with this is to suggest that the implementation would be best if you used some existing TLS implementation for the RNG. To explain, I'd start by observing that NIST SP800-90A approves of two DRBG's: AES and SHA. If you seed them properly, these functions will do the job very well. Should the application layer implement SHA? Not if the TLS layer already has done so. And how should it be seeded? The TLS layer already does this very well - using two computers' contributions toward entropy instead of just one, which is a higher bar than most applications like to hit. And how should the relation between N1, N2, . and H1, H2, . be implemented? The TLS layer already does this quite well (each TLS session state includes the running hash I suggested, on a per-handshake basis). If you grant that TLS does a nice job of seeding and maintaining a DRBG on a per-session basis, then should the TLS layer or the application layer reach into the TLS state structures and duplicate the current hash state and finalize it into a hash output? Because problems with weak RNGs implemented by non-crypto developers are historically problematic, I'd recommend sticking with the running handshake message hash as the RNG for this application of tls_authz. Then you could be quite sure your validation step (in 3) would be quite strong for years to come. --mark From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Darshak Thakore Sent: Sunday, January 27, 2013 7:12 PM To: tls@ietf.org Subject: Re: [TLS] new version of draft-dthakore-tls-authz Hi Mark, Thanks for the feedback and the link to the paper. I agree that the dtcp_authz_data structure currently defined excludes the RandomNonce (or the equivalent running hash as you suggested) out of the signature and it should have included it. I can update the struct accordingly. Given that modification, would there still be a need to put in a running hash of all the messages? My primary concern with including a running hash in the struct is that this structure is a payload of the SupplementalData message and as per RFC4680, it is an application's responsibility to provide this information. I'm not sure if we can assume that an application always has access to all messages at the TLS protocol layer. Also one point of clarification, the client will not be generating its own nonce, rather it will take the nonce it has received from the server in the server's SupplementalData message and include it in its own SupplementalData message. With that modification, the struct would be something like struct { opaque random_bytes[32]; } RandomNonce; struct { RandomNonce nonce; opaque DTCPCert<1..2^24-1>; opaque ASN.1Cert<0..2^24-1>; } DigitallySigned; struct { DigitallySigned certs; opaque signature[40]; } dtcp_authz_data; When the server sends this in its SupplementalData message, it will generate the RandomNonce. When the client sends back its own SupplementalData message, it will include the one it received from the server. With that, if we only consider the scenario of the client sending its DTCP Certificate, there are two possible options, one in which the client is also using its X.509 certificate (i.e. it will send its ClientCertificate and CertificateVerify messages also) and the other is where the client does not have an X.509 certificate to send. For the first case, an example exchange would be something like: 1. Client sends ClientHello, Server Sends ServerHello 2. Server sends SupplementalData that only has a RandomNonce (N1) 3. Server sends Certificate, CertificateRequest and ServerHelloDone 4. Client sends SupplementalData that has [(N1, DTCP Cert, X.509 Cert) Signature covering all three elements] 5. Client sends Certificate message (needs to be the same X.509 Cert as above) 6. Client sends ClientKeyExchange, ChangeCipherSpec and Finished 7. Server sends ChangeCipherSpec and Finished Would this address the replay attack? Regards, Darshak From: Mark Brown Date: Thursday, January 24, 2013 2:42 PM To: Darshak Thakore , "tls@ietf.org" Subject: RE: [TLS] new version of draft-dthakore-tls-authz Hi Darshak, I'm still concerned with replay attacks, despite the updates. The structures in 3.2 haven't changed materially, and the explanations make me more sure there's this problem: the specified RandomNonce won't prevent replay attacks. You might consider prior protocol analyses, for example this paper: http://www2.cs.uidaho.edu/~jimaf/papers/replay02.pdf To (over)simplify, follow the example of TLS CertificateVerify used for client authentication: instead of an arbitrary nonce, take a hash over *all* of the handshake messages sent/received so far (i.e. the output from the hash function run over these concatenated messages). Doing so gives a more useful session-identifying "nonce". Since the session messages "so far at this point" include client nonce, server nonce and server certificate, I'd estimate that you've overcome the 1995 Lowe attack (see http://en.wikipedia.org/wiki/Needham%E2%80%93Schroeder_protocol#Fixing_the_m an-in-the-middle_attack ). How to say this well? The text for CV gives a template, see: http://tools.ietf.org/html/rfc5246#section-7.4.8. Your structures might be: The set of all Handshake Messages in the run so far, using http://tools.ietf.org/html/rfc5246#section-7.4 : handshake_hash = Hash(handshake_messages); Your client_authz must contain an assertion as a component, such as: struct { opaque handshake_hash[hash_length]; opaque DTCPCert<1..2^24-1>; [[opaque ASN.1Cert<1..2^24-1>]]; } DTCPClientAssertion; Your client_authz SupplementalData message should contain the assertion plus its signature, e.g.: assertion_hash = Hash(DTCPClientAssertion); signature = ECDSA_Sign(assertion_hash); struct { DTCPClientAuthz client_assertion; opaque signature<1..2^16-1>; } dtcp_authz_data; This last struct is very similar to http://tools.ietf.org/html/rfc5246#section-4.7 "DigitallySigned", but omits the SignatureAndHashAlgorithm identifier for two reasons: 1) the signature and hash algorithms are DTCP's not TLS's and so the registry and code points may differ 2) the DTCPClientAssertion.DTCPCert should contain this information, and currently it's a mandatory-include part of the message. At this point, I've only presented an assertion that's appropriate for client_authz, but I think that's all that *should* be specified. I would eliminate sending server_authz from the server to the client for your use case. Sincerely, mark ------=_NextPart_000_0181_01CDFD67.B3C826B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Darshak,

 

Thanks for the solid response. Sounds like you’re saying: =

 

1)      = For server_authz you’ll generate the RandomNonce message you = specify below as a challenge in a challenge-response = protocol

2)      = For client_authz you’ll repeat the server’s RandomNonce = value, plus the certs you’re interested in sending, within the = envelope (so to speak) of that which is DigitallySigned (per your spec = below)

3)      = To accomplish authorization, the server will verify the signature and = validate the RandomNonce value as being “the value that I sent to = this client.”

 

Does this overcome replay attacks? Not an easy question. We should = consider if a MITM could splice in bad RandomNonce values or somehow = gain advantage by replaying old signed ones. MITM would *have* to = make the server believe that an old RandomNonce value, call it N1, was = valid. It seems unlikely, IMO, unless MITM could force a collision such = that server thought “Yeah, I just sent this N1 to the = client,” even when it was the same N1 value some client had signed = a while ago. This seems reasonably safe when considering your = suggestions from a protocol point of view.

 

So far, then, I think your suggestions are just fine, = IMO.

 

How about when considering the implementation point of view? Did you = assume that the application layer is going to implement the random = number generator (RNG) and the store of N1, N2, … corresponding to = TLS handshake H1, H2, … in a “hardened” = way?

 

Where I’m headed with this is to suggest that the = implementation would be best if you used some existing TLS = implementation for the RNG. To explain, I’d start by observing = that NIST SP800-90A approves of two DRBG’s: AES and SHA. If you = seed them properly, these functions will do the job very well. Should = the application layer implement SHA? Not if the TLS layer already has = done so. And how should it be seeded? The TLS layer already does this = very well – using two computers’ contributions toward = entropy instead of just one, which is a higher bar than most = applications like to hit. And how should the relation between N1, N2, = … and H1, H2, … be implemented? The TLS layer already does = this quite well (each TLS session state includes the running hash I = suggested, on a per-handshake basis). If you grant that TLS does a nice = job of seeding and maintaining a DRBG on a per-session basis, then = should the TLS layer or the application layer reach into the TLS state = structures and duplicate the current hash state and finalize it into a = hash output?

 

Because problems with weak RNGs implemented by non-crypto developers = are historically problematic, I’d recommend sticking with the = running handshake message hash as the RNG for this application of = tls_authz. Then you could be quite sure your validation step (in 3) = would be quite strong for years to come.

 

--mark

 

From:= = tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of = Darshak Thakore
Sent: Sunday, January 27, 2013 7:12 = PM
To: tls@ietf.org
Subject: Re: [TLS] new version = of draft-dthakore-tls-authz

 

Hi Mark,

 

Thanks for the feedback and the link to the paper. I agree that the = dtcp_authz_data structure currently defined excludes the RandomNonce (or = the equivalent running hash as you suggested) out of the signature and = it should have included it. I can update the struct accordingly. Given = that modification, would there still be a need to put in a running hash = of all the messages? 

My primary concern with including a running hash in the struct is that = this structure is a payload of the SupplementalData message and as per = RFC4680, it is an application's responsibility to provide this = information. I'm not sure if we can assume that an application always = has access to all messages at the TLS protocol = layer. 

 

Also one point of clarification, the client will not be generating its = own nonce, rather it will take the nonce it has received from the server = in the server's SupplementalData message and include it in its own = SupplementalData message.

 

With that modification, the struct would be something = like 

 

      struct {         =  

          opaque = random_bytes[32];

      } RandomNonce;

 

      struct {

          RandomNonce = nonce; 

          opaque = DTCPCert<1..2^24-1>;

          opaque = ASN.1Cert<0..2^24-1>;

      } = DigitallySigned;

            =   

      struct {

          DigitallySigned = certs;

          opaque signature[40]; =   

      } = dtcp_authz_data;

 

When the server sends this in its SupplementalData message, it will = generate the RandomNonce. When the client sends back its own = SupplementalData message, it will include the one it received from the = server.

 

With that, if we only consider the scenario of the client sending its = DTCP Certificate, there are two possible options, one in which the = client is also using its X.509 certificate (i.e. it will send its = ClientCertificate and CertificateVerify messages also) and the other is = where the client does not have an X.509 certificate to = send.

For the first case, an example exchange would be something = like:

  1. Client = sends ClientHello, Server Sends ServerHello
  2. Server = sends SupplementalData that only has a RandomNonce = (N1)
  3. Server = sends Certificate, CertificateRequest and = ServerHelloDone
  4. Client = sends SupplementalData that has [(N1, DTCP Cert, X.509 Cert) Signature = covering all three elements]
  5. Client = sends Certificate message (needs to be the same X.509 Cert as = above) 
  6. Client = sends ClientKeyExchange, ChangeCipherSpec and = Finished
  7. Server = sends ChangeCipherSpec and Finished

 

Would this address the replay = attack?

 

Regards,

Darshak

 

 

From: Mark Brown <mark@redphonesecurity.com&g= t;
Date: Thursday, January 24, 2013 2:42 PM
To: = Darshak Thakore <d.thakore@cablelabs.com>, = "tls@ietf.org" <tls@ietf.org>
Subject: RE: = [TLS] new version of = draft-dthakore-tls-authz

 

Hi Darshak,

 

I’m still concerned with replay attacks, despite the updates. =

 

The structures in 3.2 haven’t changed materially, and the = explanations make me more sure there’s this problem: the specified = RandomNonce won’t prevent replay attacks. You might consider prior = protocol analyses, for example this paper: http://www2= .cs.uidaho.edu/~jimaf/papers/replay02.pdf

 

To (over)simplify, follow the example of TLS CertificateVerify used = for client authentication: instead of an arbitrary nonce, take a hash = over *all* of the handshake messages sent/received so far (i.e. = the output from the hash function run over these concatenated messages). = Doing so gives a more useful session-identifying =  “nonce”. Since the session messages “so far at = this point” include client nonce, server nonce and server = certificate, I’d estimate that you’ve overcome the 1995 Lowe = attack (see http://en.wikipedia.org/wiki/Needham%= E2%80%93Schroeder_protocol#Fixing_the_man-in-the-middle_attack = ).

 

How to say this well? The text for CV gives a template, see: http://tools.ie= tf.org/html/rfc5246#section-7.4.8.

Your structures might be:

 

           &nbs= p;    The set of all Handshake Messages in the run so = far, using http://tools.ietf= .org/html/rfc5246#section-7.4 :

         =
handshake_hash =
     =3D Hash(handshake_messages);

 

           &nbs= p;    Your client_authz must contain an assertion as a = component, such as:

         = struct {

         &= nbsp;   opaque handshake_hash[hash_length];

         &= nbsp;   opaque DTCPCert<1..2^24-1>;

         &= nbsp;   [[opaque ASN.1Cert<1..2^24-1>]];

         } = DTCPClientAssertion;

 

           &nbs= p;    Your client_authz SupplementalData message should = contain the assertion plus its signature, e.g.:

         =
assertion_hash =
     =3D Hash(DTCPClientAssertion);
         =
signature =
         =3D =
ECDSA_Sign(assertion_hash);

 

         = struct {

         &= nbsp;   DTCPClientAuthz client_assertion;

         &= nbsp;   opaque signature<1..2^16-1>;

         } = dtcp_authz_data;

 

This last struct is very similar to http://tools.ietf=
.org/html/rfc5246#section-4.7 “DigitallySigned”, but omits the SignatureAndHashAlgorithm identifier for two =
reasons: 1) the signature and hash algorithms are DTCP’s not =
TLS’s and so the registry and code points may differ 2) the =
DTCPClientAssertion.DTCPCert should contain this information, and =
currently it’s a mandatory-include part of the =
message.

 

At this point, I’ve only presented an assertion that’s = appropriate for client_authz, but I think that’s all that = *should* be specified. I would eliminate sending server_authz = from the server to the client for your use case.

 

Sincerely,

mark

------=_NextPart_000_0181_01CDFD67.B3C826B0-- From stephen.farrell@cs.tcd.ie Tue Jan 29 15:54:06 2013 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 9516921F8846 for ; Tue, 29 Jan 2013 15:54:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 w07KBdkvGCzk for ; Tue, 29 Jan 2013 15:54:05 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id D1F2721F8840 for ; Tue, 29 Jan 2013 15:53:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id CF4B0BE38 for ; Tue, 29 Jan 2013 23:53:34 +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 fpWSVTOkyUQK for ; Tue, 29 Jan 2013 23:53:25 +0000 (GMT) Received: from [10.87.48.3] (unknown [86.44.73.156]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E6CE1BE33 for ; Tue, 29 Jan 2013 23:53:24 +0000 (GMT) Message-ID: <510860F4.1030106@cs.tcd.ie> Date: Tue, 29 Jan 2013 23:53:24 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130106 Thunderbird/17.0.2 MIME-Version: 1.0 To: "tls@ietf.org" References: <20130129195334.25816.18294.idtracker@ietfa.amsl.com> In-Reply-To: <20130129195334.25816.18294.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5 X-Forwarded-Message-Id: <20130129195334.25816.18294.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: Tue, 29 Jan 2013 23:54:06 -0000 Hi, As it says below, we need to do a 2nd IETF LC for this draft as the authors have decided to switch from using a 5878 extension to a TLS extension. If you've comments on that aspect please make 'em in the usual manner as also described below. I'm sure the authors are interested in other comments too, but would also appreciate if you could check whether your comment was already discussed during the 1st IETF LC. Thanks, S. -------- Original Message -------- Subject: Last Call: (Certificate Transparency) to Experimental RFC Date: Tue, 29 Jan 2013 11:53:34 -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-02-26. 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. As a result of comments received in the first last call and based on additional coding, the authors are now proposing to define a new TLS extension (see section 3.3.1) which requires IETF review. So this is a second IETF last call primarily intended to ensure that that change gets the appropriate review. Abstract This document describes an experimental protocol for publicly logging the existence of TLS certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority activity and notice the issuance of suspect certificates, as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates which do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services which implement the protocol operations for submissions and queries that are defined in this document. 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.