From quynh.dang@nist.gov Mon Jun 10 07:08:56 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 208E721F8B35 for ; Mon, 10 Jun 2013 07:08:56 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWfj5L9j86Mp for ; Mon, 10 Jun 2013 07:08:50 -0700 (PDT) Received: from wsget1.nist.gov (wsget1.nist.gov [129.6.13.150]) by ietfa.amsl.com (Postfix) with ESMTP id 785C021F848E for ; Mon, 10 Jun 2013 07:08:43 -0700 (PDT) Received: from WSXGHUB1.xchange.nist.gov (129.6.18.96) by wsget1.nist.gov (129.6.13.150) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 10 Jun 2013 10:08:17 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB1.xchange.nist.gov ([129.6.18.96]) with mapi; Mon, 10 Jun 2013 10:08:40 -0400 From: "Dang, Quynh" To: "tls@ietf.org" Date: Mon, 10 Jun 2013 10:08:37 -0400 Thread-Topic: key sizes in TLS. Thread-Index: Ac5l5AI+ssUui/A4RZyD97r3UOf27w== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_CDDB56252EB5Bqdangnistgov_" MIME-Version: 1.0 X-Mailman-Approved-At: Mon, 10 Jun 2013 07:22:39 -0700 Subject: [TLS] key sizes in 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, 10 Jun 2013 14:08:56 -0000 --_000_CDDB56252EB5Bqdangnistgov_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Currently (as I understand it), client has no mechanism (or extension) to l= et the server know what DH-sizes are acceptable (for security reason) when = doing DH-RSA and DH-DSS key exchanges and what RSA and DSS key sizes are ac= ceptable for server authentication. Also, there is no extension or mechanism for which the server can tell the = client which key sizes it will accept for client's authentication (in a cer= tificate request the server can tell the client which algorithm(s) it would= accept for the client's authentication, but not key sizes). If I understand it correctly, the client just generates DH parameters compa= rable with the DH parameters, which the client receives from the server. (I= suppose the client could terminate the connection using its local policy w= hen the DH parameters don't meet its security strength requirement). So, I = guess it would be nice if the client could let the server know what key siz= e(s) will be acceptable to the client. I don=92t know if it would make sense to specify (1) a method for which the= client can use to let the server know what key size(s) (DSS or RSA and DH)= are acceptable and (2) a method for which the server can let the client kn= ow what key size(s) is/are acceptable to the server for the client's authen= tication. Even with some (or proposed) ECC-based cipher suites, there is similar issu= e about key sizes for client=92s authentication. I would appreciate if you share what you think about the issues. Regards, Quynh. --_000_CDDB56252EB5Bqdangnistgov_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Currently (as I understand it), client has no mechanism (or extension) to let the server know what DH-sizes are acceptable (for securit= y reason) when doing DH-RSA and DH-DSS key exchanges and what RSA and DSS key sizes are acceptable for server authentication.

 

Also, there is no extension or mechanism for which the server can tell the client which key sizes it will accept for client's authentication = (in a certificate request the server can tell the client which algorithm(s) it would accept for the client's authentication, but not key sizes).

 

If I understand it correctly, the client just generates DH parame= ters comparable with the DH parameters, which the client receives from the serve= r. (I suppose the client could terminate the connection using its local policy wh= en the DH parameters don't meet its security strength requirement). So, I gues= s it would be nice if the client could let the server know what key size(s) will= be acceptable to the client.

 

 

I don=92t know if it would make sense to specify (1) a method for= which the client can use to let the server know what key size(s) (DSS or RSA and = DH) are acceptable and (2) a method for which the server can let the client kno= w what key size(s) is/are acceptable to the server for the client's authentication.

 

Even with some (or proposed) ECC-based cipher suites, there is similar issue about key sizes for client=92s authentication.

 

 

I would appreciate if you share what you think about the issues.<= o:p>

 

Regards,

Quynh.

--_000_CDDB56252EB5Bqdangnistgov_-- From wwwrun@rfc-editor.org Mon Jun 10 17:04:44 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 D93F521F89A6; Mon, 10 Jun 2013 17:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.153 X-Spam-Level: X-Spam-Status: No, score=-102.153 tagged_above=-999 required=5 tests=[AWL=-0.153, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVYnHOegzoBK; Mon, 10 Jun 2013 17:04:44 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 9C94121F960D; Mon, 10 Jun 2013 17:04:41 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 346EB62106; Mon, 10 Jun 2013 17:02:51 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130611000253.346EB62106@rfc-editor.org> Date: Mon, 10 Jun 2013 17:02:51 -0700 (PDT) Cc: tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] RFC 6961 on The Transport Layer Security (TLS) Multiple Certificate Status Request Extension 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, 11 Jun 2013 00:04:45 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6961 Title: The Transport Layer Security (TLS) Multiple Certificate Status Request Extension Author: Y. Pettersen Status: Standards Track Stream: IETF Date: June 2013 Mailbox: yngve@spec-work.net Pages: 10 Characters: 21473 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tls-multiple-cert-status-extension-08.txt URL: http://www.rfc-editor.org/rfc/rfc6961.txt This document defines the Transport Layer Security (TLS) Certificate Status Version 2 Extension to allow clients to specify and support several certificate status methods. (The use of the Certificate Status extension is commonly referred to as "OCSP stapling".) Also defined is a new method based on the Online Certificate Status Protocol (OCSP) that servers can use to provide status information about not only the server's own certificate but also the status of intermediate certificates in the chain. This document is a product of the Transport Layer Security Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From n.mavrogiannopoulos@gmail.com Tue Jun 11 03:12:12 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 23A8C21F8ECE for ; Tue, 11 Jun 2013 03:12:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLMeb2IAQHWz for ; Tue, 11 Jun 2013 03:12:07 -0700 (PDT) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) by ietfa.amsl.com (Postfix) with ESMTP id 81B6A21F8F3E for ; Tue, 11 Jun 2013 03:12:07 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id 10so6838238lbf.36 for ; Tue, 11 Jun 2013 03:12:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=9lFLq1fzx5KnteEJid/i1Vrw554ArUxoXtltTNXgt0w=; b=i2djlHZAxDWbIahniWczvGAMPHV3BjFZqRUF6lkZWBOIcT6bnbJwla2HSQxAYJ6xYR 86bR00zHNflV6SkkEEgr3SzcNmBCxCCoiwWda+4e74FMb3nxL4afAvzv18dlvKFK352Q 0NMjC4sKttwqvgeUwy34ZaZEFCJvE3Wp1qh76okbMoDxLHvJWGwVN8CSnw2XMoUrPTHS +TZVnVE/9zvDMJ7rdiN3aMPBqHVSUlrTAAKQ6XKYt9eh4qwtepqmuTSV7pz2xLFSOYnc ZBx94K2z6XDCxXTj4mvTIPtTU5zpMmhlHCU4FnntHBPxbwuqqADOZQWx2B9danVgbo7+ 8wSw== MIME-Version: 1.0 X-Received: by 10.152.20.6 with SMTP id j6mr7106217lae.2.1370945526202; Tue, 11 Jun 2013 03:12:06 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.112.74.114 with HTTP; Tue, 11 Jun 2013 03:12:06 -0700 (PDT) In-Reply-To: References: Date: Tue, 11 Jun 2013 12:12:06 +0200 X-Google-Sender-Auth: t5_Uch9TnzwbmD0oL8p_jGBKoDM Message-ID: From: Nikos Mavrogiannopoulos To: "Dang, Quynh" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] key sizes in 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: Tue, 11 Jun 2013 10:12:12 -0000 On Mon, Jun 10, 2013 at 4:08 PM, Dang, Quynh wrote: > I don=E2=80=99t know if it would make sense to specify (1) a method for w= hich the > client can use to let the server know what key size(s) (DSS or RSA and DH= ) > are acceptable and (2) a method for which the server can let the client k= now > what key size(s) is/are acceptable to the server for the client's > authentication. You are correct. That is an omission from the DHE key exchange in TLS. At least in gnutls it caused several connection failure issues once we required a DH group of more than 768 bits in the client. Overall my impression is that the DHE-based ciphersuites are pretty much neglected. There are also optimizations that could be done (e.g., the server specifying the size of the generator's subgroup), but no-one ever bothered to update the protocol. > Even with some (or proposed) ECC-based cipher suites, there is similar is= sue > about key sizes for client=E2=80=99s authentication. Which ones do you mean? The ECC-based ciphersuites (with named curves) have the size of the curve hard-coded so I have noticed no such issues there. In that aspect they are better than their DH counterparts. If you mean the ECC ciphersuites with explicit curves I think you should reconsider their usage [0]. regards, Nikos [0]. https://www.cosic.esat.kuleuven.be/publications/private/article-2216.p= df From n.mavrogiannopoulos@gmail.com Tue Jun 11 03:16:00 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 4425621F9590 for ; Tue, 11 Jun 2013 03:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EGWTnTvERzCF for ; Tue, 11 Jun 2013 03:15:58 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id C2A5B21F949F for ; Tue, 11 Jun 2013 03:15:57 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id fr10so6708495lab.32 for ; Tue, 11 Jun 2013 03:15:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=kp1Fl2sXsdll7+jE+xfHfo2eFkiJRvCVp5fCw3Yw+wA=; b=UnwkooScual9HM5a9MW+nwsJs0o8ra53JvRcjua+nh9xIo7UTEU6hgTNUBWgPER36z SxMIyLXQHkHwVSES23CqIKHdzwolruYK5n79S8fdNsyqg0Oen7un6MRlDhrCdOwu4XzI TFUQwQcK7S9wdjXtS6apm0/5eEZLshRSOKBKD7L/cek1ceooZMWQkQ0t7pp5N0I79MXs 0yBLiqxFu8mXDmsmpS5aJkJiJg/aymekJGRU7AEqfaFg7dlZZcJp3DCpXqCiplmkB0iN hHKXBXIZsrjxImGRJg7bZmbP04egVccgnGNHHnkAzi4yJEPYXIRV0Iig3c4aVZ0MMvYP 3+EQ== MIME-Version: 1.0 X-Received: by 10.112.14.33 with SMTP id m1mr8456757lbc.17.1370945756682; Tue, 11 Jun 2013 03:15:56 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.112.74.114 with HTTP; Tue, 11 Jun 2013 03:15:56 -0700 (PDT) In-Reply-To: References: Date: Tue, 11 Jun 2013 12:15:56 +0200 X-Google-Sender-Auth: X3_tDP7VZLdq8_u0dQ0_MhEF_I4 Message-ID: From: Nikos Mavrogiannopoulos To: "Dang, Quynh" Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] key sizes in 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: Tue, 11 Jun 2013 10:16:00 -0000 On Tue, Jun 11, 2013 at 12:12 PM, Nikos Mavrogiannopoulos wrote: > Which ones do you mean? The ECC-based ciphersuites (with named > curves) have the size of the curve hard-coded so I have noticed no > such issues there. In that aspect they are better than their DH > counterparts. If you mean the ECC ciphersuites with explicit curves I > think you should reconsider their usage [0]. > [0]. https://www.cosic.esat.kuleuven.be/publications/private/article-2216.pdf Sorry, the correct URL is: https://www.cosic.esat.kuleuven.be/publications/article-2216.pdf regards, Nikos From quynh.dang@nist.gov Tue Jun 11 08:17:26 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 3A5E321F99CE for ; Tue, 11 Jun 2013 08:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EORr+WbdpPTs for ; Tue, 11 Jun 2013 08:17:21 -0700 (PDT) Received: from wsget2.nist.gov (wsget2.nist.gov [129.6.13.151]) by ietfa.amsl.com (Postfix) with ESMTP id 8796F21F99C6 for ; Tue, 11 Jun 2013 08:17:21 -0700 (PDT) Received: from WSXGHUB2.xchange.nist.gov (129.6.18.19) by wsget2.nist.gov (129.6.13.151) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 11 Jun 2013 11:17:04 -0400 Received: from MBCLUSTER.xchange.nist.gov ([fe80::d479:3188:aec0:cb66]) by WSXGHUB2.xchange.nist.gov ([129.6.18.19]) with mapi; Tue, 11 Jun 2013 11:17:20 -0400 From: "Dang, Quynh" To: Nikos Mavrogiannopoulos Date: Tue, 11 Jun 2013 11:17:16 -0400 Thread-Topic: [TLS] key sizes in TLS. Thread-Index: Ac5mtsOKc7XGmyEJSt6sCg97y5Q04w== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.4.130416 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] key sizes in 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: Tue, 11 Jun 2013 15:17:26 -0000 For example, proposed ciphersuites in http://tools.ietf.org/html/draft-mcgrew-tls-aes-ccm-ecc-06, it has requirements for client certificate, see the paragraph below. "The server's certificate MUST contain an ECDSA-capable public key, it MUST be signed with ECDSA, and it MUST use SHA-256, SHA-384, or SHA-512. The Signature Algorithms extension (Section 7.4.1.4.1 of [RFC5246] ) MUST be used to indicate support of those signature and hash algorithms. If a client certificate is used, the same conditions apply to it. The acceptable choices of hashes and curves that can be used with each ciphersuite are detailed in Section 2.2". However, in many other ciphersuites' specifications, there is no requirement about what key size(s) (curve(s)) (in ECDSA) to sign the client certificate. Regards, Quynh.=20 On 6/11/13 6:12 AM, "Nikos Mavrogiannopoulos" wrote: >On Mon, Jun 10, 2013 at 4:08 PM, Dang, Quynh wrote: > >> I don=B9t know if it would make sense to specify (1) a method for which >>the >> client can use to let the server know what key size(s) (DSS or RSA and >>DH) >> are acceptable and (2) a method for which the server can let the client >>know >> what key size(s) is/are acceptable to the server for the client's >> authentication. > >You are correct. That is an omission from the DHE key exchange in TLS. >At least in gnutls it caused several connection failure issues once we >required a DH group of more than 768 bits in the client. > >Overall my impression is that the DHE-based ciphersuites are pretty >much neglected. There are also optimizations that could be done (e.g., >the server specifying the size of the generator's subgroup), but >no-one ever bothered to update the protocol. > >> Even with some (or proposed) ECC-based cipher suites, there is similar >>issue >> about key sizes for client=B9s authentication. > >Which ones do you mean? The ECC-based ciphersuites (with named >curves) have the size of the curve hard-coded so I have noticed no >such issues there. In that aspect they are better than their DH >counterparts. If you mean the ECC ciphersuites with explicit curves I >think you should reconsider their usage [0]. > >regards, >Nikos > >[0].=20 >https://www.cosic.esat.kuleuven.be/publications/private/article-2216.pdf From n.mavrogiannopoulos@gmail.com Thu Jun 13 04:54:31 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 0D06C21F9A2C for ; Thu, 13 Jun 2013 04:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bzGh4NAQpvO for ; Thu, 13 Jun 2013 04:54:30 -0700 (PDT) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 8958021F957B for ; Thu, 13 Jun 2013 04:54:30 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id ci6so990232qab.4 for ; Thu, 13 Jun 2013 04:54:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=Ah9au8bLHYuZQFYFO9weDNuQU8nSqVEeUHEMhgxLfMg=; b=IIsSP4D3jAw4jqQ9Pou1dRwGg/yIIMlieUSOLcFMkb65nrPCMDKt7ypoORbFjyg286 ERJ2/8jsmH2TTCy4T5L/9PjDo7xJtfqESDy6iUjkuvexwLPEknpvhOvYz61mdxcLYOin ve5JTNjbmpYVwM3IxuCjTPRXjBAtMPJceLsQDQU9fb/Eoiw+WEl33Cn+1dP3dJCmehoP cwPMsj3x0pr2BgZWbgSbfiTOdlYw6+igdJDSk9KfTDBgHF4frKpOd85sjGdh/PE/tzDc VzGsfXcv8H98bKhFaOaHwzR229pLOffaZPNMu8iE4ViCKKhswtedcT87ntEBIUAeS9Qy BlhA== MIME-Version: 1.0 X-Received: by 10.49.11.168 with SMTP id r8mr687159qeb.34.1371124469945; Thu, 13 Jun 2013 04:54:29 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.13.101 with HTTP; Thu, 13 Jun 2013 04:54:29 -0700 (PDT) In-Reply-To: References: Date: Thu, 13 Jun 2013 13:54:29 +0200 X-Google-Sender-Auth: ZtmZSNRjxUrkM1rCc0Qq6GmZK5Y Message-ID: From: Nikos Mavrogiannopoulos To: "Dang, Quynh" Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] key sizes in 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: Thu, 13 Jun 2013 11:54:31 -0000 On Tue, Jun 11, 2013 at 5:17 PM, Dang, Quynh wrote: > For example, proposed ciphersuites in > http://tools.ietf.org/html/draft-mcgrew-tls-aes-ccm-ecc-06, it has > requirements for client certificate, see the paragraph below. > "The server's certificate MUST contain an ECDSA-capable public key, > it MUST be signed with ECDSA, and it MUST use SHA-256, SHA-384, or > SHA-512. The Signature Algorithms extension (Section 7.4.1.4.1 of > [RFC5246] ) > MUST be used to indicate support of those signature and > hash algorithms. If a client certificate is used, the same > conditions apply to it. The acceptable choices of hashes and > curves that can be used with each ciphersuite are detailed in > Section 2.2". Indeed that looks like an issue of these particular ciphersuites. regards, Nikos From stephen.farrell@cs.tcd.ie Fri Jun 14 05:55:16 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 8440821F9A50 for ; Fri, 14 Jun 2013 05:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 tagged_above=-999 required=5 tests=[AWL=-0.100, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpzRR9ajLBjv for ; Fri, 14 Jun 2013 05:55:12 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 5524121F9A42 for ; Fri, 14 Jun 2013 05:55:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id BD941BECA for ; Fri, 14 Jun 2013 13:54:50 +0100 (IST) 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 BmuJ7AN4jsNQ for ; Fri, 14 Jun 2013 13:54:50 +0100 (IST) Received: from [IPv6:2001:770:10:203:1d5c:b21a:982e:7128] (unknown [IPv6:2001:770:10:203:1d5c:b21a:982e:7128]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id A6EA8BEC9 for ; Fri, 14 Jun 2013 13:54:50 +0100 (IST) Message-ID: <51BB129B.8060103@cs.tcd.ie> Date: Fri, 14 Jun 2013 13:54:51 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: "tls@ietf.org" X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [TLS] Possible BoF in Berlin on profiling DTLS for Constrained Environments 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, 14 Jun 2013 12:55:16 -0000 Hiya, There may be a BoF in Berlin on this topic. Details are at [1], the IESG will decide whether or not to schedule the BoF next week. Please take any discussion to the dtls-iot list [2] Thanks, S. [1] https://trac.tools.ietf.org/bof/trac/wiki#DICE [2] https://www.ietf.org/mailman/listinfo/dtls-iot From wwwrun@rfc-editor.org Thu Jun 13 21:52:23 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 6162721F9B23 for ; Thu, 13 Jun 2013 21:52:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.416 X-Spam-Level: X-Spam-Status: No, score=-102.416 tagged_above=-999 required=5 tests=[AWL=0.184, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8hNe-bqidM8v for ; Thu, 13 Jun 2013 21:52:22 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3C821F9B1B for ; Thu, 13 Jun 2013 21:52:22 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 38DBD62104; Thu, 13 Jun 2013 21:50:28 -0700 (PDT) To: sblakewilson@safenet-inc.com, nelson@bolyard.com, vipul.gupta@sun.com, chris@corriente.net, bodo@openssl.org, stephen.farrell@cs.tcd.ie, turners@ieca.com, ekr@networkresonance.com, jsalowey@cisco.com, ekr@rtfm.com From: RFC Errata System Message-Id: <20130614045028.38DBD62104@rfc-editor.org> Date: Thu, 13 Jun 2013 21:50:28 -0700 (PDT) X-Mailman-Approved-At: Fri, 14 Jun 2013 07:34:24 -0700 Cc: rfc-editor@rfc-editor.org, tls@ietf.org, peter.dettman@bouncycastle.org Subject: [TLS] [Editorial Errata Reported] RFC4492 (3652) 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, 14 Jun 2013 04:52:23 -0000 The following errata report has been submitted for RFC4492, "Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=4492&eid=3652 -------------------------------------- Type: Editorial Reported by: Peter Dettman Section: 5.4 Original Text ------------- ECBasisType basis; select (basis) { case ec_trinomial: opaque k <1..2^8-1>; case ec_pentanomial: opaque k1 <1..2^8-1>; opaque k2 <1..2^8-1>; opaque k3 <1..2^8-1>; }; Corrected Text -------------- ECBasisType basis; select (basis) { case ec_basis_trinomial: opaque k <1..2^8-1>; case ec_basis_pentanomial: opaque k1 <1..2^8-1>; opaque k2 <1..2^8-1>; opaque k3 <1..2^8-1>; }; Notes ----- ECBasisType is earlier introduced as: enum { ec_basis_trinomial, ec_basis_pentanomial } ECBasisType; The cases of the select statement should spell the enum elements correctly. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC4492 (draft-ietf-tls-ecc-12) -------------------------------------- Title : Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS) Publication Date : May 2006 Author(s) : S. Blake-Wilson, N. Bolyard, V. Gupta, C. Hawk, B. Moeller Category : INFORMATIONAL Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From paul.hoffman@vpnc.org Sat Jun 15 05:41:11 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 39FAB21F93D4 for ; Sat, 15 Jun 2013 05:41:11 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b62evMryriBh for ; Sat, 15 Jun 2013 05:41:10 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id CD0E021F8EDF for ; Sat, 15 Jun 2013 05:41:10 -0700 (PDT) Received: from [172.100.103.97] (burl-mse-71-255-129-12.static.ngn.east.myfairpoint.net [71.255.129.12]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5FCf8fx061655 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 15 Jun 2013 05:41:09 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <7807543B-2154-4331-A0EA-D0C4F2A6FC19@vpnc.org> Date: Sat, 15 Jun 2013 08:41:09 -0400 To: "tls@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [TLS] TLS grammar checker? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jun 2013 12:41:11 -0000 Greetings again. The recent errata shows that some of the TLS documents = that use the grammar invented for SSL can have some errors. People have = developed tools for checking ABNF grammar in Internet Drafts and RFCs; = has anyone developed an SSL grammar checker? --Paul Hoffman= From pgut001@cs.auckland.ac.nz Sun Jun 16 22:11:12 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 4E08C21F99DE for ; Sun, 16 Jun 2013 22:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YO3AijgerfPq for ; Sun, 16 Jun 2013 22:11:07 -0700 (PDT) Received: from mx1.auckland.ac.nz (mx1.auckland.ac.nz [130.216.125.243]) by ietfa.amsl.com (Postfix) with ESMTP id 19A4121F942D for ; Sun, 16 Jun 2013 22:11:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1371445867; x=1402981867; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=bLNcHRuDXwGDXIh2vkC2SeCl444N8sW5ojDhH8eFR80=; b=jt2SptL+WATTGYeaARtxGnu7T/cDhphBSjqkOHHC3lwSs/8yFPC/oUNb tTSGxpCVUQhA5j4oii8twew+Mg6AlE0KHmTY3pkkcyQlT58G3laXnlcAl 0l6Z7S9nqnM3qhBE3X7+wzJGgT0HGRdBCFEUVeibIfC+zFy5TPbhdu9v+ 0=; X-IronPort-AV: E=Sophos;i="4.87,878,1363086000"; d="scan'208";a="244918547" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx1-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 17 Jun 2013 17:10:59 +1200 Received: from UXCN10-TDC02.UoA.auckland.ac.nz ([169.254.8.204]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Mon, 17 Jun 2013 17:10:58 +1200 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: [TLS] key sizes in TLS. Thread-Index: Ac5rGQ0NvsDbD4WMQYqIe7lzS6Y9XA== Date: Mon, 17 Jun 2013 05:10:57 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7343D64CB6@uxcn10-tdc02.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] key sizes in 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, 17 Jun 2013 05:11:12 -0000 Nikos Mavrogiannopoulos writes:=0A= =0A= >Overall my impression is that the DHE-based ciphersuites are pretty much= =0A= >neglected. =0A= =0A= They're preferred cipher suites for several browsers, e.g. Firefox and Chro= me:=0A= =0A= http://sim.ivi.co/2011/07/firefox-preference-of-tls-cipher-suites.html=0A= http://sim.ivi.co/2011/07/google-chrome-preference-of-tls-cipher.html =0A= =0A= so they're not only not neglected, they're actively used.=0A= =0A= >There are also optimizations that could be done (e.g., the server specifyi= ng=0A= >the size of the generator's subgroup), but no-one ever bothered to update = the=0A= >protocol.=0A= =0A= That would be very useful, so you could perform DSA-style checks on the key= =0A= parameters.=0A= =0A= Peter.=0A= From pgut001@cs.auckland.ac.nz Sun Jun 16 23:09:51 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 AB0CC21F8605 for ; Sun, 16 Jun 2013 23:09:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMvg8VCD6nk4 for ; Sun, 16 Jun 2013 23:09:46 -0700 (PDT) Received: from mx1.auckland.ac.nz (mx1.auckland.ac.nz [130.216.125.243]) by ietfa.amsl.com (Postfix) with ESMTP id 5771921F9A7E for ; Sun, 16 Jun 2013 23:09:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=pgut001@cs.auckland.ac.nz; q=dns/txt; s=uoa; t=1371449384; x=1402985384; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=r3fesyXD7ztpLlJJ+T6VZLtdIZKeSNnqSF6e4vgjiZQ=; b=KKALyl1XIBWte9hBYH8PIOUmm2zAnUxzd03Vtk9PkHcF4rbxGwv3fYt8 ioZHFbOlwpqQ6O0OXONS5ZQheHciB7uGWl5AF7zPnD8vGHd06riyCc36k 8CriP3o73rnk6guO/PuyOEGVY973EjYvFkGgehG2uS0wAXCuwXmb87972 w=; X-IronPort-AV: E=Sophos;i="4.87,878,1363086000"; d="scan'208";a="244940660" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx1-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 17 Jun 2013 18:09:05 +1200 Received: from UXCN10-TDC02.UoA.auckland.ac.nz ([169.254.8.204]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.02.0318.004; Mon, 17 Jun 2013 18:09:04 +1200 From: Peter Gutmann To: Paul Hoffman , "tls@ietf.org" Thread-Topic: [TLS] TLS grammar checker? Thread-Index: Ac5rISsUDXSD6GYhSGmJg9XjSlyL2g== Date: Mon, 17 Jun 2013 06:09:04 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7343D64D33@uxcn10-tdc02.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] TLS grammar checker? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 06:09:51 -0000 Paul Hoffman writes:=0A= =0A= >Greetings again. The recent errata shows that some of the TLS documents th= at=0A= >use the grammar invented for SSL can have some errors. People have develop= ed=0A= >tools for checking ABNF grammar in Internet Drafts and RFCs; has anyone=0A= >developed an SSL grammar checker?=0A= =0A= The SSL grammar isn't, AFAIK, any kind of machine-parseable formal grammar,= in=0A= published automated analyses the authors had to re-state what was going on = in=0A= their own notation in order to make it amenable to automated analysis, and= =0A= even then could usually only do a subset of the protocol. So you'd need to= =0A= come up with your own grammar that's amenable to automated processing and r= e-=0A= specific TLS in that. I can't really see that happening any time soon.=0A= =0A= (Having said that, I'd like to see it done. The grammar used in the SSL/TL= S=0A= RFCs is pretty confusing in places).=0A= =0A= Peter.=0A= From n.mavrogiannopoulos@gmail.com Mon Jun 17 03:16:44 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 0669521F9ACA for ; Mon, 17 Jun 2013 03:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZOcm734MnhQK for ; Mon, 17 Jun 2013 03:16:38 -0700 (PDT) Received: from mail-qe0-f52.google.com (mail-qe0-f52.google.com [209.85.128.52]) by ietfa.amsl.com (Postfix) with ESMTP id 38E3F21F9BB7 for ; Mon, 17 Jun 2013 03:16:32 -0700 (PDT) Received: by mail-qe0-f52.google.com with SMTP id i11so1561781qej.11 for ; Mon, 17 Jun 2013 03:16:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=KPJKAxjpxT32N6QNNMFnqL4S0wR6OM0uWOhVoL4h6iE=; b=Tbzr0zdMWPEdYY+5kUp24ihFeuhH14WUVfMBGRF1bffTO300Gp/7HTTdjzAVhNIxG3 zkTPOU5AgB5y4H1zz4LDepYyg2hQx0QkiUpexNyRYHlwdnFOBQ6KPj1jwRHFVQe1aU73 GEI2s3TwENEhGaCUJ143yE1dxI2q6qtkW3Atcr+d/2fo3P7gqBelcGuljC/WLB/cOviw hnqhtpHNYpBp5BH0lF6zb6AVdwCnJ3ZidMvr2fYoIgLeZkL6wpkoIWPDU1Za+UJv8kIk WTxqMUi9RDI6nQ9Bz2EZ2aTpqdGAbb0LUsV6gJ4Ptt0CKQLN1GEXZQvoX6gKuv9C26g7 9spg== MIME-Version: 1.0 X-Received: by 10.49.24.13 with SMTP id q13mr19140160qef.49.1371464191563; Mon, 17 Jun 2013 03:16:31 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.151.195 with HTTP; Mon, 17 Jun 2013 03:16:31 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7343D64CB6@uxcn10-tdc02.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C7343D64CB6@uxcn10-tdc02.UoA.auckland.ac.nz> Date: Mon, 17 Jun 2013 12:16:31 +0200 X-Google-Sender-Auth: ntTyaGV3EU5nOHaaOib3JjIIGEY Message-ID: From: Nikos Mavrogiannopoulos To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] key sizes in 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, 17 Jun 2013 10:16:45 -0000 On Mon, Jun 17, 2013 at 7:10 AM, Peter Gutmann wrote: >>Overall my impression is that the DHE-based ciphersuites are pretty much >>neglected. > They're preferred cipher suites for several browsers, e.g. Firefox and Chrome: > http://sim.ivi.co/2011/07/firefox-preference-of-tls-cipher-suites.html > http://sim.ivi.co/2011/07/google-chrome-preference-of-tls-cipher.html > so they're not only not neglected, they're actively used. Actually in the links you post the ECDHE ciphersuites seem to be the preferred choices. Nevertheless, I said that they are neglected, not that they are not used. They are neglected because despite their known issues, they have not been fixed. regards, Nikos From paul.hoffman@vpnc.org Mon Jun 17 06:48:49 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 B8B0B21F9C24 for ; Mon, 17 Jun 2013 06:48:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOrwk+TxmtwR for ; Mon, 17 Jun 2013 06:48:49 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 44B1B21F9C23 for ; Mon, 17 Jun 2013 06:48:49 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5HDmhei032506 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Jun 2013 06:48:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7343D64D33@uxcn10-tdc02.UoA.auckland.ac.nz> Date: Mon, 17 Jun 2013 06:48:44 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <43347F57-8351-4348-AC3C-4EECE6EE3A32@vpnc.org> References: <9A043F3CF02CD34C8E74AC1594475C7343D64D33@uxcn10-tdc02.UoA.auckland.ac.nz> To: Peter Gutmann X-Mailer: Apple Mail (2.1508) Cc: "tls@ietf.org" Subject: Re: [TLS] TLS grammar checker? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 13:48:49 -0000 On Jun 16, 2013, at 11:09 PM, Peter Gutmann = wrote: > Paul Hoffman writes: >=20 >> Greetings again. The recent errata shows that some of the TLS = documents that >> use the grammar invented for SSL can have some errors. People have = developed >> tools for checking ABNF grammar in Internet Drafts and RFCs; has = anyone >> developed an SSL grammar checker? >=20 > The SSL grammar isn't, AFAIK, any kind of machine-parseable formal = grammar, in > published automated analyses the authors had to re-state what was = going on in > their own notation in order to make it amenable to automated analysis, = and > even then could usually only do a subset of the protocol. So you'd = need to > come up with your own grammar that's amenable to automated processing = and re- > specific TLS in that. I can't really see that happening any time = soon. Indeed, so my question was hopeful that it had been done in the past.=20 > (Having said that, I'd like to see it done. The grammar used in the = SSL/TLS > RFCs is pretty confusing in places). It could be / would have been an interesting task for a CS intern or = summer student, or a prof researching widely-used grammars. --Paul Hoffman= From ekr@rtfm.com Mon Jun 17 07:00:28 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 5402121F8D6D for ; Mon, 17 Jun 2013 07:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.035 X-Spam-Level: X-Spam-Status: No, score=-100.035 tagged_above=-999 required=5 tests=[AWL=0.390, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RDNS_NONE=0.1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BIufd57tQucA for ; Mon, 17 Jun 2013 07:00:23 -0700 (PDT) Received: from mail-qa0-x229.google.com (mail-qa0-x229.google.com [IPv6:2607:f8b0:400d:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 706CC21F9374 for ; Mon, 17 Jun 2013 07:00:22 -0700 (PDT) Received: by mail-qa0-f41.google.com with SMTP id f14so1466263qak.14 for ; Mon, 17 Jun 2013 07:00:22 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:x-gm-message-state; bh=RCapfjC9T/qF2+TObBLmDqRieutzNsYyOmh7JcD0ems=; b=VW3BYH6b8JfeS1yAmYnvJQNUs0b4WHBKiERlyPfWxOTsmPLwWNqWWWCaSPShGTWFdl gCmQOVgg0lV3nj/FweQo5b83/94lrBT9k7mzlibP7RN/wbpNh9DBnZsBc/HsmtMVPdCl lIbRYh6UlyOzh7K+br60XCwsfs8lcN5PI8lco4qsez/y3RbL70S8V6kNF55gsSbR30w5 Itd3xOZes9UBhUzPQfuj4zsypMeL+2BUCPiyP3FL1vYhduXzZW3riK52r7kcNS+vI1zL QNpQykLH1oEETbTWyef2CDzpyiUbwOd7yuXVwQ0z538rgyBqlanFxn0QbJ9IXWjQ82Bu TjCg== X-Received: by 10.224.205.8 with SMTP id fo8mr16885264qab.62.1371477621880; Mon, 17 Jun 2013 07:00:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.49.15.40 with HTTP; Mon, 17 Jun 2013 06:59:41 -0700 (PDT) X-Originating-IP: [74.95.2.173] In-Reply-To: <43347F57-8351-4348-AC3C-4EECE6EE3A32@vpnc.org> References: <9A043F3CF02CD34C8E74AC1594475C7343D64D33@uxcn10-tdc02.UoA.auckland.ac.nz> <43347F57-8351-4348-AC3C-4EECE6EE3A32@vpnc.org> From: Eric Rescorla Date: Mon, 17 Jun 2013 06:59:41 -0700 Message-ID: To: Paul Hoffman Content-Type: multipart/alternative; boundary=20cf3005dc0a7848d004df5a0457 X-Gm-Message-State: ALoCoQlNc2+tIzac9T6poaJn1AWDqQWE75O7hDrD67QDhB2EHX9X3vavv17HZoPtfD0X4bMH6GUW Cc: "tls@ietf.org" Subject: Re: [TLS] TLS grammar checker? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 14:00:28 -0000 --20cf3005dc0a7848d004df5a0457 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jun 17, 2013 at 6:48 AM, Paul Hoffman wrote: > On Jun 16, 2013, at 11:09 PM, Peter Gutmann > wrote: > > > Paul Hoffman writes: > > > >> Greetings again. The recent errata shows that some of the TLS documents > that > >> use the grammar invented for SSL can have some errors. People have > developed > >> tools for checking ABNF grammar in Internet Drafts and RFCs; has anyone > >> developed an SSL grammar checker? > > > > The SSL grammar isn't, AFAIK, any kind of machine-parseable formal > grammar, in > > published automated analyses the authors had to re-state what was going > on in > > their own notation in order to make it amenable to automated analysis, > and > > even then could usually only do a subset of the protocol. So you'd need > to > > come up with your own grammar that's amenable to automated processing > and re- > > specific TLS in that. I can't really see that happening any time soon. > > Indeed, so my question was hopeful that it had been done in the past. > > > (Having said that, I'd like to see it done. The grammar used in the > SSL/TLS > > RFCs is pretty confusing in places). > > It could be / would have been an interesting task for a CS intern or > summer student, or a prof researching widely-used grammars. > I've built parsers for subsets of the grammar. I'm not sure anyone has built one for the entire TLS protocol. I think you would probably have to iterate: 1. Build the parser. 2. Try to parse the grammar in the specifications. 3. Look at where it fails and try to decide whether your parser was wrong or the specs were wrong. 4. File errata and/or fix your parser. 5. Rinse, repeat -Ekr --20cf3005dc0a7848d004df5a0457 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Jun 17, 2013 at 6:48 AM, Paul Hoffman <= ;paul.hoffman@vp= nc.org> wrote:
On Jun 16, 2013, at 11:09 = PM, Peter Gutmann <pgut001@= cs.auckland.ac.nz> wrote:

> Paul Hoffman <paul.hoffman= @vpnc.org> writes:
>
>> Greetings again. The recent errata shows that some of the TLS docu= ments that
>> use the grammar invented for SSL can have some errors. People have= developed
>> tools for checking ABNF grammar in Internet Drafts and RFCs; has a= nyone
>> developed an SSL grammar checker?
>
> The SSL grammar isn't, AFAIK, any kind of machine-parseable formal= grammar, in
> published automated analyses the authors had to re-state what was goin= g on in
> their own notation in order to make it amenable to automated analysis,= and
> even then could usually only do a subset of the protocol. =A0So you= 9;d need to
> come up with your own grammar that's amenable to automated process= ing and re-
> specific TLS in that. =A0I can't really see that happening any tim= e soon.

Indeed, so my question was hopeful that it had been done in the past.=

> (Having said that, I'd like to see it done. =A0The grammar used in= the SSL/TLS
> RFCs is pretty confusing in places).

It could be / would have been an interesting task for a CS intern or = summer student, or a prof researching widely-used grammars.

I've built parsers for subsets of the gramma= r. I'm not sure anyone has
built one for the entire TLS protocol. I think you would probabl= y have to
iterate:

1. = Build the parser.
2. Try to parse the grammar in the specif= ications.
3. Look at where it fails and try to decide whether your parser<= /div>
=A0 =A0 was wrong or the specs were wrong.
= 4. File errata and/or fix your parser.
5. Rinse, repeat

-Ekr
=A0
<= /div> --20cf3005dc0a7848d004df5a0457-- From rsalz@akamai.com Tue Jun 18 09:55:41 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 9E5DB21F81FF for ; Tue, 18 Jun 2013 09:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.74 X-Spam-Level: X-Spam-Status: No, score=-0.74 tagged_above=-999 required=5 tests=[BAYES_20=-0.74] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XwMzOzpdMCF for ; Tue, 18 Jun 2013 09:55:33 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [96.6.114.97]) by ietfa.amsl.com (Postfix) with ESMTP id 3803221E80A5 for ; Tue, 18 Jun 2013 09:55:33 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 9D15B1C47D7; Tue, 18 Jun 2013 16:55:32 +0000 (GMT) Received: from prod-mail-relay03.akamai.com (prod-mail-relay03.akamai.com [172.27.8.26]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 923BF1C47D5; Tue, 18 Jun 2013 16:55:32 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay03.akamai.com (Postfix) with ESMTP id 77CD52FD62; Tue, 18 Jun 2013 16:55:32 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.138]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Tue, 18 Jun 2013 12:55:31 -0400 From: "Salz, Rich" To: Paul Hoffman , Peter Gutmann Date: Tue, 18 Jun 2013 12:55:31 -0400 Thread-Topic: [TLS] TLS grammar checker? Thread-Index: Ac5rYWgnE2/wCX2XTOmJZZLk1sVwxgA4yUgg Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711B1CC17EE@USMBX1.msg.corp.akamai.com> References: <9A043F3CF02CD34C8E74AC1594475C7343D64D33@uxcn10-tdc02.UoA.auckland.ac.nz> <43347F57-8351-4348-AC3C-4EECE6EE3A32@vpnc.org> In-Reply-To: <43347F57-8351-4348-AC3C-4EECE6EE3A32@vpnc.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS grammar checker? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 16:55:41 -0000 > (Having said that, I'd like to see it done. The grammar used in the=20 > SSL/TLS RFCs is pretty confusing in places). Any support for using a standard like, say, ASN.1 ? -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From paul.hoffman@vpnc.org Tue Jun 18 10:09:47 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 29E2721F9B7E for ; Tue, 18 Jun 2013 10:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.523 X-Spam-Level: X-Spam-Status: No, score=-102.523 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8jnIvyz6fYh for ; Tue, 18 Jun 2013 10:09:46 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE3521F9B7D for ; Tue, 18 Jun 2013 10:09:46 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5IH9c2K090109 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 18 Jun 2013 10:09:39 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711B1CC17EE@USMBX1.msg.corp.akamai.com> Date: Tue, 18 Jun 2013 10:09:38 -0700 Content-Transfer-Encoding: 7bit Message-Id: References: <9A043F3CF02CD34C8E74AC1594475C7343D64D33@uxcn10-tdc02.UoA.auckland.ac.nz> <43347F57-8351-4348-AC3C-4EECE6EE3A32@vpnc.org> <2A0EFB9C05D0164E98F19BB0AF3708C711B1CC17EE@USMBX1.msg.corp.akamai.com> To: "Salz, Rich" X-Mailer: Apple Mail (2.1508) Cc: tls@ietf.org Subject: Re: [TLS] TLS grammar checker? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 17:09:47 -0000 On Jun 18, 2013, at 9:55 AM, "Salz, Rich" wrote: >> (Having said that, I'd like to see it done. The grammar used in the >> SSL/TLS RFCs is pretty confusing in places). > > Any support for using a standard like, say, ASN.1 ? No. From nico@cryptonector.com Tue Jun 18 10:36:43 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 020EC21F9B1C for ; Tue, 18 Jun 2013 10:36:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.965 X-Spam-Level: X-Spam-Status: No, score=-1.965 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucJzc+qOjH8x for ; Tue, 18 Jun 2013 10:36:38 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (caiajhbdcbbj.dreamhost.com [208.97.132.119]) by ietfa.amsl.com (Postfix) with ESMTP id 0E20221F996F for ; Tue, 18 Jun 2013 10:36:38 -0700 (PDT) Received: from homiemail-a72.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTP id B63216B007B for ; Tue, 18 Jun 2013 10:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=d2OICjBdnevSZUIJ9wJR UyVsTe4=; b=r0HzxAnpz3BtumKiaY4hKVAqm6m9ek6nEzjHhP1ZkA9bj9doebjm WFXtcgWqH9Uv2sUCxNqyw63Xelq40Uls3DPgRM1IGg+xS1GSXLKqjsGilCdGWhFm un8xQKIMBBFn/j4Ls1FL1UsiDG8LJrMjarsgAhgkHdzx76po6bSYPYQ= Received: from mail-we0-f179.google.com (mail-we0-f179.google.com [74.125.82.179]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a72.g.dreamhost.com (Postfix) with ESMTPSA id 5E7D06B0078 for ; Tue, 18 Jun 2013 10:36:37 -0700 (PDT) Received: by mail-we0-f179.google.com with SMTP id w59so3691168wes.10 for ; Tue, 18 Jun 2013 10:36:35 -0700 (PDT) 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; bh=2tEJhSleeN7ujk5opWf/7hjs0nVGjLOXWlRI/thJQw4=; b=bPDPyAbbYlRX52/bC/hx+zp+9Xb3YGJjO25YBgvKohRW3Np6WvL701SDIXLDHzGuep eIvUKmQkm5JfwDtq5jY27cI4xAraKGpthcw7qbhYi9QvWWBPEDsEEhdYkhip65lmA7IH /wAbdwVeC6e0BDQx6z25Pq0xZKeRvX5IEr/zdZx9tuannGSDkMnK5MCLdQD/lJ0amT/n OvHsQ9BuLjI1340UAMpUqQQ0MSuBwf8+SHObSymy8UG4qooxJasZvGYP8aeOuE+20Gv7 SEBd2xtSP0QFiKeLbavPlEStHNu+LmCaM/GpHfzmE2bbcPErCRGGtAh+n+Ni4NASgFtp zlTg== MIME-Version: 1.0 X-Received: by 10.180.74.162 with SMTP id u2mr2536811wiv.36.1371576995031; Tue, 18 Jun 2013 10:36:35 -0700 (PDT) Received: by 10.216.29.5 with HTTP; Tue, 18 Jun 2013 10:36:34 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711B1CC17EE@USMBX1.msg.corp.akamai.com> References: <9A043F3CF02CD34C8E74AC1594475C7343D64D33@uxcn10-tdc02.UoA.auckland.ac.nz> <43347F57-8351-4348-AC3C-4EECE6EE3A32@vpnc.org> <2A0EFB9C05D0164E98F19BB0AF3708C711B1CC17EE@USMBX1.msg.corp.akamai.com> Date: Tue, 18 Jun 2013 12:36:34 -0500 Message-ID: From: Nico Williams To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS grammar checker? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 17:36:43 -0000 On Tue, Jun 18, 2013 at 11:55 AM, Salz, Rich wrote: >> (Having said that, I'd like to see it done. The grammar used in the >> SSL/TLS RFCs is pretty confusing in places). > > Any support for using a standard like, say, ASN.1 ? If you want to use something like XDR or ASN.1 you'll need to provide some open source tooling so that at least content of new TLS-related I-Ds/RFCs can be syntax-validated. Otherwise you'll probably get no consensus. Not that such tooling would be sufficient for consensus either (but I'd support it). Nico PS: I've thought of defining my own ad-hoc ASN.1 encoding rules for various purposes. I'd like a JSON encoding rules for pretty-printing things that will be encoded in or have been decoded from BER/DER/PER/... This would make it possible to use ASN.1 for specifying JSON schemas too, but no one who doesn't already have to use ASN.1 wants to use ASN.1, though I myself like ASN.1 -- I only hate its TLV encodings. From anders.rundgren@telia.com Tue Jun 18 11:31:15 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 1AD6321F9AA2 for ; Tue, 18 Jun 2013 11:31:15 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id paSreXhRh1KF for ; Tue, 18 Jun 2013 11:31:03 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id E6F1D21F995E for ; Tue, 18 Jun 2013 11:31:02 -0700 (PDT) Received: from [192.168.0.203] (213.64.1.89) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 51B4DDE700259CF3 for tls@ietf.org; Tue, 18 Jun 2013 20:31:00 +0200 Message-ID: <51C0A762.9030909@telia.com> Date: Tue, 18 Jun 2013 20:30:58 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "'tls@ietf.org'" X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [TLS] Another [Well-deserved] attack on TLS CCA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 18:31:15 -0000 https://sites.google.com/site/oauthgoog/gnubby Luckily for all users Google didn't select TLS CCA (Client Certificate Authentication) for their coming U2F system; only a moron would base a future consumer authentication system on a scheme that is only suited for VPN tunnels and invisible authentications like as ChannelID. What's missing you may wonder? Well, how about - Compatibility with web sessions including timeout and logout - A working credential filtering system Anders From agl@google.com Tue Jun 18 11:39:08 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 6D96111E80F7 for ; Tue, 18 Jun 2013 11:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XO-vmEEGj88U for ; Tue, 18 Jun 2013 11:39:08 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) by ietfa.amsl.com (Postfix) with ESMTP id D746721E808E for ; Tue, 18 Jun 2013 11:39:05 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id q56so3772788wes.3 for ; Tue, 18 Jun 2013 11:39:05 -0700 (PDT) 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=CwGn7GK8n+6wo5gJDhgpKNAmF+AoUGF5JeF9CibG4QU=; b=OFMMONKMYz3+8y801Aulk/LttABnuW0sov8bypa0nQMh0Lq7Z50woqS5nPnh+wrMfg J7LZLFhgSdpJ1ic3zaDbAU5kNHt63ZHBBSs7HFglsA+IoFI3tOGkHhGK6vkVFcQhUkSk Ep34WKFxOIAB7zeYUAVp29hZl7DkM8/Gpc4tqoAu6bJVHf8kLJ19z+WpCCfQIIzkNZbZ +s4DaZGG7dG6gbr5GymkifrdNR5DQk235eUb1zrqg4/lt4/eitE7pW+9p6GQyivlG+zm OOSShNU2IrnQpmYOISJQaKPaTCRYBNapIFwSMHAlLpBOMvBFp3/5SmPrbMUIQOCKMMkS XfTg== 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=CwGn7GK8n+6wo5gJDhgpKNAmF+AoUGF5JeF9CibG4QU=; b=kA+ralRkjo9Hi78HzPdsVyvJd7pkdG/hifwcAdd6lgs7oON/ce/rtpsD0x/gLqToCI bT+v8MgXXB+rebp3VtPO2HMAbBQu5uXPQG8lmfP/Bgsivi8TqR2/LmwAHpP2i8jWNOGT ieriQTE1PPhwXDXGIxX7tEQSy7LPAdLFHMeQ8Pqi0Yf0nQuI/JTeAi/1wIH4OkQJPfW8 mK/KbaxiGcBc91t2kOAlWValyYU2fARjWK6BFIffdQ7eFkvfNCv+mWjC/UEzzt8Xfe/9 2TSpM/6alj3oZT2BQkuMdTP/fay04kgtq2QUwrpCQgG4730H5NWwS7WtNKaijNCYeEOT WCkg== MIME-Version: 1.0 X-Received: by 10.180.36.209 with SMTP id s17mr1807455wij.62.1371580744989; Tue, 18 Jun 2013 11:39:04 -0700 (PDT) Received: by 10.216.62.73 with HTTP; Tue, 18 Jun 2013 11:39:04 -0700 (PDT) In-Reply-To: <51C0A762.9030909@telia.com> References: <51C0A762.9030909@telia.com> Date: Tue, 18 Jun 2013 14:39:04 -0400 Message-ID: From: Adam Langley To: Anders Rundgren Content-Type: text/plain; charset=UTF-8 X-Gm-Message-State: ALoCoQl9Ug8VYfwtHFWki8iPhp6N8OX1ol3N+Bmg27velo6t0GOXUYhtIOvhEV5ZKRMHt1Ggk1gRHf7e1/Atfrr/ZvQp/kmrT5Zr4aBNo0b4BIj3xvsUiGRBY1HxpUA2IQAbHsuXNr8UaltmzlORlvIIyMrRaO2WoYkm69UMQOnRZlKOc/m/B1F4ikkGw87meS2C4gYM+HWS Cc: "tls@ietf.org" Subject: Re: [TLS] Another [Well-deserved] attack on TLS CCA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 18:39:08 -0000 On Tue, Jun 18, 2013 at 2:30 PM, Anders Rundgren wrote: > Luckily for all users Google didn't select TLS CCA (Client Certificate > Authentication) for their coming U2F system; only a moron would base a > future consumer authentication system on a scheme that is only suited > for VPN tunnels and invisible authentications like as ChannelID. The U2F system originally did use client-side certificates. We changed it to ChannelID, but not for the reasons you suggested, but rather as explained in https://tools.ietf.org/html/draft-balfanz-tls-channelid-00#section-2 Cheers AGL From anders.rundgren@telia.com Tue Jun 18 11:47:18 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 1F04D11E80EE for ; Tue, 18 Jun 2013 11:47:18 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X5o054ZngpMQ for ; Tue, 18 Jun 2013 11:47:13 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id 2F25111E80F7 for ; Tue, 18 Jun 2013 11:47:13 -0700 (PDT) Received: from [192.168.0.203] (213.64.1.89) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 51AC7836005DACDD; Tue, 18 Jun 2013 20:46:19 +0200 Message-ID: <51C0AAFB.6010103@telia.com> Date: Tue, 18 Jun 2013 20:46:19 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Adam Langley References: <51C0A762.9030909@telia.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] Another [Well-deserved] attack on TLS CCA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 18:47:18 -0000 On 2013-06-18 20:39, Adam Langley wrote: > On Tue, Jun 18, 2013 at 2:30 PM, Anders Rundgren > wrote: >> Luckily for all users Google didn't select TLS CCA (Client Certificate >> Authentication) for their coming U2F system; only a moron would base a >> future consumer authentication system on a scheme that is only suited >> for VPN tunnels and invisible authentications like as ChannelID. > > The U2F system originally did use client-side certificates. We changed > it to ChannelID, but not for the reasons you suggested, but rather as > explained in https://tools.ietf.org/html/draft-balfanz-tls-channelid-00#section-2 Not exactly; U2F builds on JSON objects and ChannelID is an optional element in the login protocol. Cheers Anders > > > Cheers > > AGL > From nico@cryptonector.com Tue Jun 18 13:36: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 87D6021F962D for ; Tue, 18 Jun 2013 13:36:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fL8LRGN5jOGk for ; Tue, 18 Jun 2013 13:36:01 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id A7CEF21F9452 for ; Tue, 18 Jun 2013 13:36:01 -0700 (PDT) Received: from homiemail-a73.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTP id 532301F008B for ; Tue, 18 Jun 2013 13:36:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=797k/q4+s6pRGPBd/Tq/ bZqPXY4=; b=anKFzSJFA6gxpQD0LhTobhbxbm41Fu2tg9m/tfbezOlisQFY29Xg lCVP662gDfF4MpOVILRLFjyhq3NMounZLiRZgkGSzBOEULukB6IKK2WlfUZMsybE LP14AaYviM3pQBEfpNd55kyCFbLYO95+/ic62nqOvnyhgTZ1aJaqLjs= Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a73.g.dreamhost.com (Postfix) with ESMTPSA id E091D1F0087 for ; Tue, 18 Jun 2013 13:36:00 -0700 (PDT) Received: by mail-wi0-f175.google.com with SMTP id m6so3891705wiv.2 for ; Tue, 18 Jun 2013 13:35:59 -0700 (PDT) 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; bh=4LLiXXMSz1Ucr4cLezau984yTYCsrcqHOKme/2Et8bQ=; b=fJNNf80qQAC/iWg1znBzmSpx8V3tSyJDIGjBL2yN0MwtMx3wv03yB16j9p+J6Iop4r H2v1nXKQ+JDkgoYuh5Ke9MMbCPKfQt3ljwD1afoEF2cdSoYIndpw5tl/u101Q+Ze8hiM 9iaWIITf2v/OCwMowMayDjffM83WA79Zv/2xGWAq4hTELWrA0ZvuumZqhHwt/+f3Folc G1Yo8POhuRaIazasmxnVGHwVt38q9af8QxcniHchEr73I0YgbmHHF6yWqVsAGGAFyY72 Nwn8JUKDyi7OlsmvKnSZ+wKC7Uf1iD2dt31/3yONSBuNhYv1OVLQtG/jilLImNPw2FD+ w9vQ== MIME-Version: 1.0 X-Received: by 10.194.63.46 with SMTP id d14mr12207519wjs.81.1371587759674; Tue, 18 Jun 2013 13:35:59 -0700 (PDT) Received: by 10.216.29.5 with HTTP; Tue, 18 Jun 2013 13:35:59 -0700 (PDT) In-Reply-To: <51C0A762.9030909@telia.com> References: <51C0A762.9030909@telia.com> Date: Tue, 18 Jun 2013 15:35:59 -0500 Message-ID: From: Nico Williams To: Anders Rundgren Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Another [Well-deserved] attack on TLS CCA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 20:36:06 -0000 BrowserID uses its certificates at the application-layer, not in TLS. I think that's the correct approach. (That still leaves the use of TLS server certs for authenticating servers; that's not going to go away. Ideally mechanisms like BrowserID can do channel binding so that the dependence on the TLS server PKI can be mitigated / eventually removed.) Nico -- From anders.rundgren@telia.com Tue Jun 18 13:45: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 170E621E8097 for ; Tue, 18 Jun 2013 13:45:06 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lwQbaAh42c66 for ; Tue, 18 Jun 2013 13:45:00 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id 2860721E8054 for ; Tue, 18 Jun 2013 13:44:59 -0700 (PDT) Received: from [192.168.0.203] (213.64.1.89) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 51B4DDE700261636; Tue, 18 Jun 2013 22:44:57 +0200 Message-ID: <51C0C6C5.1060701@telia.com> Date: Tue, 18 Jun 2013 22:44:53 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Nico Williams References: <51C0A762.9030909@telia.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org" Subject: Re: [TLS] Another [Well-deserved] attack on TLS CCA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 20:45:06 -0000 On 2013-06-18 22:35, Nico Williams wrote: > BrowserID uses its certificates at the application-layer, not in TLS. > I think that's the correct approach. Yes, so does all usable consumer-auth solutions including Google's U2F. Anders > > (That still leaves the use of TLS server certs for authenticating > servers; that's not going to go away. Ideally mechanisms like > BrowserID can do channel binding so that the dependence on the TLS > server PKI can be mitigated / eventually removed.) > > Nico > -- > From geoffk@geoffk.org Tue Jun 18 14:40: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 CC05321E8099 for ; Tue, 18 Jun 2013 14:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Re8k2jmdhq1p for ; Tue, 18 Jun 2013 14:40:12 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by ietfa.amsl.com (Postfix) with ESMTP id A93EA21E80A6 for ; Tue, 18 Jun 2013 14:40:12 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id D3F2433D0FC; Tue, 18 Jun 2013 21:39:58 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Anders Rundgren References: <51C0A762.9030909@telia.com> From: Geoffrey Keating Date: 18 Jun 2013 14:39:58 -0700 In-Reply-To: <51C0A762.9030909@telia.com> Message-ID: Lines: 38 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "'tls@ietf.org'" Subject: Re: [TLS] Another [Well-deserved] attack on TLS CCA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 21:40:17 -0000 Anders Rundgren writes: > https://sites.google.com/site/oauthgoog/gnubby > > Luckily for all users Google didn't select TLS CCA (Client Certificate > Authentication) for their coming U2F system; only a moron would base a > future consumer authentication system on a scheme that is only suited > for VPN tunnels and invisible authentications like as ChannelID. > > What's missing you may wonder? Well, how about > > - Compatibility with web sessions including timeout and logout Logout is a client-side function, and occurs (typically) when the user logs out of their local session and/or quits their web browser. Timeout occurs when the TLS connection is closed due to inactivity (typically 60 seconds) and the session resumption token is expired, which is up to the server; or, looking at it another way, when the user's screen lock triggers due to inactivity. > - A working credential filtering system I think this is mostly due to lack of demand. I wouldn't say it isn't "working", just that as commonly implemented, it isn't very good. I wouldn't list these as the biggest problems when trying to use client certificate auth, they can be solved with minor fixes. The first major obstacle you'll hit is trying to get users enrolled. Then there are: - Enrolling multiple devices - Key rollover - Lost devices - Shared devices - Public access terminals and all the other things that people don't think about immediately when they say "let's replace passwords!" From anders.rundgren@telia.com Tue Jun 18 15:18:04 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 E9F0911E8106 for ; Tue, 18 Jun 2013 15:18:04 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8BJ9Tueyuq9H for ; Tue, 18 Jun 2013 15:17:59 -0700 (PDT) Received: from smtp-out21.han.skanova.net (smtp-out21.han.skanova.net [195.67.226.208]) by ietfa.amsl.com (Postfix) with ESMTP id A8A1311E8109 for ; Tue, 18 Jun 2013 15:17:56 -0700 (PDT) Received: from [192.168.0.203] (213.64.1.89) by smtp-out21.han.skanova.net (8.5.133) (authenticated as u36408181) id 51AC7836005E8E51; Wed, 19 Jun 2013 00:17:49 +0200 Message-ID: <51C0DC81.3010908@telia.com> Date: Wed, 19 Jun 2013 00:17:37 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Geoffrey Keating References: <51C0A762.9030909@telia.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'tls@ietf.org'" Subject: Re: [TLS] Another [Well-deserved] attack on TLS CCA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 22:18:05 -0000 On 2013-06-18 23:39, Geoffrey Keating wrote: > Anders Rundgren writes: > >> https://sites.google.com/site/oauthgoog/gnubby >> >> Luckily for all users Google didn't select TLS CCA (Client Certificate >> Authentication) for their coming U2F system; only a moron would base a >> future consumer authentication system on a scheme that is only suited >> for VPN tunnels and invisible authentications like as ChannelID. >> >> What's missing you may wonder? Well, how about >> >> - Compatibility with web sessions including timeout and logout > > Logout is a client-side function, and occurs (typically) when the user > logs out of their local session and/or quits their web browser. > Timeout occurs when the TLS connection is closed due to inactivity > (typically 60 seconds) and the session resumption token is expired, > which is up to the server; or, looking at it another way, when the > user's screen lock triggers due to inactivity. Yes, but this is not how most web apps work today for good or for worse. > >> - A working credential filtering system > > I think this is mostly due to lack of demand. I wouldn't say it isn't > "working", just that as commonly implemented, it isn't very good. There is a perceived little demand because many organizations who are big users of consumer-PKI have no voice in the IETF. I believe these guys would be slaughtered by the IETF bunch since they don't have exactly the same "lingo" and probably don't know very much about inner life of TLS. > I wouldn't list these as the biggest problems when trying to use > client certificate auth, they can be solved with minor fixes. Minor fixes? I doubt that given the fact that you probably must do something in both ends. > The first major obstacle you'll hit is trying to get users enrolled. Indeed. Which is why Google made it a part of the U2F plot while the rest of the industry has nothing to offer except insanely useless crap like Mozilla's and Microsoft's CertEnroll. > Then there are: > > - Enrolling multiple devices > - Key rollover > - Lost devices > - Shared devices > - Public access terminals This can be addressed in due time when you have an enrollment solution. Before that nothing can happen. > and all the other things that people don't think about immediately > when they say "let's replace passwords!" Google may very well be the only party on the planet who have a chance making this in reach for the masses. Microsoft, Banks, Governments and last but not least, the Card industry, have showed that they cannot. Anders From frantz@pwpconsult.com Tue Jun 18 15:20:23 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 A498811E8113 for ; Tue, 18 Jun 2013 15:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CU586b8t+4Q7 for ; Tue, 18 Jun 2013 15:20:09 -0700 (PDT) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id 44A6411E8112 for ; Tue, 18 Jun 2013 15:20:09 -0700 (PDT) Received: from [173.75.83.226] (helo=Williams-MacBook-Pro.local) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Up4Fz-00033n-Iq; Tue, 18 Jun 2013 18:20:07 -0400 Date: Tue, 18 Jun 2013 15:20:07 -0700 From: Bill Frantz To: Nico Williams X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79db3ec25924e9f3f09291541c58668128350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.226 Cc: tls@ietf.org Subject: Re: [TLS] TLS grammar checker? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 22:20:23 -0000 On 6/18/13 at 10:36 AM, nico@cryptonector.com (Nico Williams) wrote: >This would make it possible to use ASN.1 for >specifying JSON schemas too, but no one who doesn't already have to >use ASN.1 wants to use ASN.1, though I myself like ASN.1 -- I only >hate its TLV encodings. Given the history of serious security problems due to ASN.1=20 parser bugs, I would feel better with a simpler format. (And=20 yes, I'm one of the people who developed an allergy to ASN.1=20 through use.) Cheers - Bill ----------------------------------------------------------------------- Bill Frantz |The nice thing about standards| Periwinkle (408)356-8506 |is there are so many to choose| 16345=20 Englewood Ave www.pwpconsult.com |from. - Andrew Tanenbaum | Los Gatos,=20 CA 95032 From nico@cryptonector.com Tue Jun 18 15:50:08 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 9648F21E808B for ; Tue, 18 Jun 2013 15:50:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.967 X-Spam-Level: X-Spam-Status: No, score=-1.967 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0wmBFsCPP4F for ; Tue, 18 Jun 2013 15:50:02 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (caiajhbdccah.dreamhost.com [208.97.132.207]) by ietfa.amsl.com (Postfix) with ESMTP id 7EA9111E810D for ; Tue, 18 Jun 2013 15:50:02 -0700 (PDT) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id A9A6BBC034 for ; Tue, 18 Jun 2013 15:50:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=pJWSx4tXtif/vQEautT2 pWWF8Mw=; b=kscCULpOlOSPsCHyteH5B5tk26GuEzJt2i+IdkF44YO8+yHap/oH k4nt1x9O7tdRMhPT0cM9TeCKQo54MEOOg7+u+wCp5MlCpzGaEphDODb+fu3kLex/ X3F/1fgh+VQXCGdzQpKAiEwfB85u3zqyqG6q61uqCTbKV60c2+ZzmyQ= Received: from mail-wg0-f53.google.com (mail-wg0-f53.google.com [74.125.82.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTPSA id 53C12BC032 for ; Tue, 18 Jun 2013 15:50:01 -0700 (PDT) Received: by mail-wg0-f53.google.com with SMTP id y10so4003084wgg.20 for ; Tue, 18 Jun 2013 15:49:59 -0700 (PDT) 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; bh=WvXosQM6SHHfTT/xzemtXGvXUf3SSAMLv/ZdC9DygEc=; b=jvKZM4KHUYkzuDS4/IiP4HJKayE8cFrWUIBMNhA7JchS0w0nJyJPdJd2PTFQDqNmPI vhx6zb5Uml6/9ayfc4LeA5xJ1SYDumYKz4Y5cOdKwaXBJ7soNlKO4wfSM5N3oYgKQpYH IakeC6ZbhPKtmdvsjZGrzaXy8y4A5kDhEtarWk6kYJEcJtbMhDsUxf5P1tMXzauyxyC8 4kPn9DoRH6+F1fWfZ8/zZu1nlJhC83bYNxceW4kUQDwCjelpbbTJ7tx+NwRSb3uMBfdm jZVvxxKZYvKPOr/tem22om5qSkKiiIPPYr513KadMGjHnsMO4SFatnjXIzGla9tl7QPs fyGw== MIME-Version: 1.0 X-Received: by 10.181.12.1 with SMTP id em1mr9111533wid.4.1371595799719; Tue, 18 Jun 2013 15:49:59 -0700 (PDT) Received: by 10.216.29.5 with HTTP; Tue, 18 Jun 2013 15:49:59 -0700 (PDT) In-Reply-To: References: Date: Tue, 18 Jun 2013 17:49:59 -0500 Message-ID: From: Nico Williams To: Bill Frantz Content-Type: text/plain; charset=UTF-8 Cc: tls@ietf.org Subject: Re: [TLS] TLS grammar checker? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 22:50:08 -0000 On Tue, Jun 18, 2013 at 5:20 PM, Bill Frantz wrote: > On 6/18/13 at 10:36 AM, nico@cryptonector.com (Nico Williams) wrote: > >> This would make it possible to use ASN.1 for >> specifying JSON schemas too, but no one who doesn't already have to >> use ASN.1 wants to use ASN.1, though I myself like ASN.1 -- I only >> hate its TLV encodings. > > > Given the history of serious security problems due to ASN.1 parser bugs, I > would feel better with a simpler format. (And yes, I'm one of the people who > developed an allergy to ASN.1 through use.) This tells me that you don't understand what you're talking about, that your reaction is knee-jerk. ASN.1 is just a syntax. The security bugs have been in decoders of some encoding rules of ASN.1, like BER. And there have been security vulnerabilities in *many* encodings not related to ASN.1, such as XDR, NDR, and others. The problem is not exclusive to TLV (tag-length-value) encoding rules of ASN.1 (like BER) nor to ASN.1 encoding rules. It's generic. The syntax itself is fine as far as security goes. It's not terribly easy to parse (so that's one reason not to use it), that's about the only significant problem with the *syntax*. I'd go further and recommend the use of a syntax and encoding rules for which there is suitable tooling available as this allows for more formality in specifications, and fixing of bugs by fixing encoder/decoder libraries, increasing code reuse, ... Nico -- From prvs=98816eb638=uri@ll.mit.edu Tue Jun 18 16:27:08 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 D1D6111E8116 for ; Tue, 18 Jun 2013 16:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.223 X-Spam-Level: X-Spam-Status: No, score=-6.223 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fe3zEAIzhoDi for ; Tue, 18 Jun 2013 16:27:04 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 95B1811E8113 for ; Tue, 18 Jun 2013 16:27:04 -0700 (PDT) Received: from LLE2K7-HUB01.mitll.ad.local (LLE2K7-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r5INR0Ej028147; Tue, 18 Jun 2013 19:27:00 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: "'nico@cryptonector.com'" , "'tls@ietf.org'" , "'frantz@pwpconsult.com'" Date: Tue, 18 Jun 2013 19:26:58 -0400 Thread-Topic: [TLS] TLS grammar checker? Thread-Index: Ac5sdjDj83qZUqS3QKquVsQnCxr2JwABSEAd In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-06-18_09:2013-06-18, 2013-06-18, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1306180250 Message-Id: <20130618232704.95B1811E8113@ietfa.amsl.com> Subject: Re: [TLS] TLS grammar checker? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 23:27:08 -0000 Having written my share of ASN.1 stuff (including parser/encoder with no kn= own vulnerabilities :), I agree with Nico's assessment of ASN.1. TNX! -- Regards, Uri Blumenthal Voice: (781) 981-1638 Cyber Systems and Technology Fax: (781) 981-0186 MIT Lincoln Laboratory Cell: (339) 223-5363 244 Wood Street Email: Lexington, MA 02420-9185 =20 Web: http://www.ll.mit.edu/CST/ =20 MIT LL Root CA:=20 DSN: 478-5980 ask Lincoln ext.1638 ----- Original Message ----- From: Nico Williams [mailto:nico@cryptonector.com] Sent: Tuesday, June 18, 2013 05:49 PM=0A= To: Bill Frantz Cc: tls@ietf.org Subject: Re: [TLS] TLS grammar checker? On Tue, Jun 18, 2013 at 5:20 PM, Bill Frantz wrote: > On 6/18/13 at 10:36 AM, nico@cryptonector.com (Nico Williams) wrote: > >> This would make it possible to use ASN.1 for >> specifying JSON schemas too, but no one who doesn't already have to >> use ASN.1 wants to use ASN.1, though I myself like ASN.1 -- I only >> hate its TLV encodings. > > > Given the history of serious security problems due to ASN.1 parser bugs, = I > would feel better with a simpler format. (And yes, I'm one of the people = who > developed an allergy to ASN.1 through use.) This tells me that you don't understand what you're talking about, that your reaction is knee-jerk. ASN.1 is just a syntax. The security bugs have been in decoders of some encoding rules of ASN.1, like BER. And there have been security vulnerabilities in *many* encodings not related to ASN.1, such as XDR, NDR, and others. The problem is not exclusive to TLV (tag-length-value) encoding rules of ASN.1 (like BER) nor to ASN.1 encoding rules. It's generic. The syntax itself is fine as far as security goes. It's not terribly easy to parse (so that's one reason not to use it), that's about the only significant problem with the *syntax*. I'd go further and recommend the use of a syntax and encoding rules for which there is suitable tooling available as this allows for more formality in specifications, and fixing of bugs by fixing encoder/decoder libraries, increasing code reuse, ... Nico -- _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From geoffk@geoffk.org Tue Jun 18 16:40:30 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 B75B011E8118 for ; Tue, 18 Jun 2013 16:40:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S9ODsBoBF2GF for ; Tue, 18 Jun 2013 16:40:25 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.118.138]) by ietfa.amsl.com (Postfix) with ESMTP id 2214421E80A5 for ; Tue, 18 Jun 2013 16:40:21 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id B6CB733D0FC; Tue, 18 Jun 2013 23:40:17 +0000 (UTC) Sender: geoffk@localhost.localdomain To: Anders Rundgren References: <51C0A762.9030909@telia.com> <51C0DC81.3010908@telia.com> From: Geoffrey Keating Date: 18 Jun 2013 16:40:17 -0700 In-Reply-To: <51C0DC81.3010908@telia.com> Message-ID: Lines: 54 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: "'tls@ietf.org'" Subject: Re: [TLS] Another [Well-deserved] attack on TLS CCA X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 23:40:30 -0000 Anders Rundgren writes: > On 2013-06-18 23:39, Geoffrey Keating wrote: > > Anders Rundgren writes: > > > >> https://sites.google.com/site/oauthgoog/gnubby > >> > >> Luckily for all users Google didn't select TLS CCA (Client Certificate > >> Authentication) for their coming U2F system; only a moron would base a > >> future consumer authentication system on a scheme that is only suited > >> for VPN tunnels and invisible authentications like as ChannelID. > >> > >> What's missing you may wonder? Well, how about > >> > >> - Compatibility with web sessions including timeout and logout > > > > Logout is a client-side function, and occurs (typically) when the user > > logs out of their local session and/or quits their web browser. > > Timeout occurs when the TLS connection is closed due to inactivity > > (typically 60 seconds) and the session resumption token is expired, > > which is up to the server; or, looking at it another way, when the > > user's screen lock triggers due to inactivity. > > Yes, but this is not how most web apps work today for good or for worse. That's because most web apps require the user to type a password, but you can't require the user to type a password on every click, so they only ask the user to enter the password once, and then they have to maintain authentication status information using cookies (or similar). Client certificates avoid this entirely; you don't need cookies, you can authenticate on every request. This can dramatically simplify the design of a web app. At least, that's one way to do it. If you're doing two-factor, you can combine this with a password: you still have a session, with login, logout and timeout, but you also require that every connection be tied to the client certificate. > >> - A working credential filtering system > > > > I think this is mostly due to lack of demand. I wouldn't say it isn't > > "working", just that as commonly implemented, it isn't very good. > > There is a perceived little demand because many organizations who are big > users of consumer-PKI have no voice in the IETF. I believe these guys > would be slaughtered by the IETF bunch since they don't have exactly the > same "lingo" and probably don't know very much about inner life of TLS. Asking at the IETF is definitely the wrong place to start this. At present there's no consensus that any protocol changes are required let alone what these changes might be. These organizations need to ask the OS and/or browser vendors for better support, explaining in detail what they need and why, and those vendors can work with them and then if necessary do any protocol design under the IETF umbrella. From frantz@pwpconsult.com Tue Jun 18 17:05:40 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 40DC421F962D for ; Tue, 18 Jun 2013 17:05:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_00=-2.599, SARE_OBFU_ALL=0.751] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDhfUuzSBd5C for ; Tue, 18 Jun 2013 17:05:35 -0700 (PDT) Received: from elasmtp-mealy.atl.sa.earthlink.net (elasmtp-mealy.atl.sa.earthlink.net [209.86.89.69]) by ietfa.amsl.com (Postfix) with ESMTP id 950FA21F961F for ; Tue, 18 Jun 2013 17:05:35 -0700 (PDT) Received: from [173.75.83.226] (helo=Williams-MacBook-Pro.local) by elasmtp-mealy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Up5u1-0007ZR-W5; Tue, 18 Jun 2013 20:05:34 -0400 Date: Tue, 18 Jun 2013 17:05:33 -0700 From: Bill Frantz To: "Blumenthal, Uri - 0558 - MITLL" X-Priority: 3 In-Reply-To: <201306182327.r5INR5RO007548@mail172c38.carrierzone.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79e79ec159043add086560d3eadacdad1f350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.226 Cc: "'tls@ietf.org'" Subject: Re: [TLS] TLS grammar checker? 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, 19 Jun 2013 00:05:40 -0000 I admire the optimism expressed here. Particularly given the=20 state of computer security today. [More inline] Cheers - Bill On 6/18/13 at 4:26 PM, uri@ll.mit.edu (Blumenthal, Uri - 0558 -=20 MITLL) wrote: >Having written my share of ASN.1 stuff (including=20 >parser/encoder with no known vulnerabilities :), I agree with=20 >Nico's assessment of ASN.1. No known vulnerabilities is a good start. Unfortunately a lot of=20 software is released with no know vulnerabilities but doesn't=20 hold up under attack. It is nice to hear of software that has=20 survived attack with no known vulnerabilities. >TNX! >-- >Regards, >Uri Blumenthal Voice: (781) 981-1638 >Cyber Systems and Technology Fax: (781) 981-0186 >MIT Lincoln Laboratory Cell: (339) 223-5363 >244 Wood Street Email: >Lexington, MA 02420-9185 >Web: http://www.ll.mit.edu/CST/ > > > >MIT LL Root CA: > > > >DSN: 478-5980 ask Lincoln ext.1638 > >----- Original Message ----- >From: Nico Williams [mailto:nico@cryptonector.com] >Sent: Tuesday, June 18, 2013 05:49 PM >To: Bill Frantz >Cc: tls@ietf.org >Subject: Re: [TLS] TLS grammar checker? > >On Tue, Jun 18, 2013 at 5:20 PM, Bill Frantz wrote= : >>On 6/18/13 at 10:36 AM, nico@cryptonector.com (Nico Williams) wrote: >> >>> This would make it possible to use ASN.1 for >>> specifying JSON schemas too, but no one who doesn't already have to >>> use ASN.1 wants to use ASN.1, though I myself like ASN.1 -- I only >>> hate its TLV encodings. >> >> >>Given the history of serious security problems due to ASN.1 parser bugs, = I >>would feel better with a simpler format. (And yes, I'm one of the people = who >>developed an allergy to ASN.1 through use.) > >This tells me that you don't understand what you're talking about, >that your reaction is knee-jerk. > >ASN.1 is just a syntax. The security bugs have been in decoders of >some encoding rules of ASN.1, like BER. > >And there have been security vulnerabilities in *many* encodings not >related to ASN.1, such as XDR, NDR, and others. The problem is not >exclusive to TLV (tag-length-value) encoding rules of ASN.1 (like BER) >nor to ASN.1 encoding rules. It's generic. > >The syntax itself is fine as far as security goes. It's not terribly >easy to parse (so that's one reason not to use it), that's about the >only significant problem with the *syntax*. Here is the reason I worry. The harder things are to do, the=20 more likely mistakes will be made. That is why I prefer simpler formats. While I'm bashing ASN.1, formats that allow infinite length data=20 items are asking for buffer overruns. >I'd go further and recommend the use of a syntax and encoding rules >for which there is suitable tooling available as this allows for more >formality in specifications, and fixing of bugs by fixing >encoder/decoder libraries, increasing code reuse, ... > >Nico >-- >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls > ----------------------------------------------------------------------- Bill Frantz | I don't have high-speed | Periwinkle (408)356-8506 | internet. I have DSL. | 16345=20 Englewood Ave www.pwpconsult.com | | Los Gatos,=20 CA 95032 From nico@cryptonector.com Tue Jun 18 17:16: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 4F0D621E80AD for ; Tue, 18 Jun 2013 17:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.591 X-Spam-Level: X-Spam-Status: No, score=-1.591 tagged_above=-999 required=5 tests=[AWL=-0.365, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, SARE_OBFU_ALL=0.751] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WYXgSi2gnLTW for ; Tue, 18 Jun 2013 17:16:30 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id AD63221F99AF for ; Tue, 18 Jun 2013 17:16:25 -0700 (PDT) Received: from homiemail-a71.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTP id 6691B428072 for ; Tue, 18 Jun 2013 17:16:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=rT6DmbF50RhIZUMmHtHc DPcRsXM=; b=QqiGGmRVjdbcPHDAL8U4iKRfMvGBfkkXPR4lXxNZwPfdO+VvH/Pw JiAH0gqs0MPYbfmmNb5NBHAxxu+PoETs4beyLFFsT9ipl9W2EQ494u4m1GJ8AWVe Qp4nrRp6pS0hk9MynKHxv+WCVE9/jdRhxXdRE0pAUIo/E7OkJrIwFiI= Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a71.g.dreamhost.com (Postfix) with ESMTPSA id 1194D42806E for ; Tue, 18 Jun 2013 17:16:22 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id b12so4010972wgh.19 for ; Tue, 18 Jun 2013 17:16:21 -0700 (PDT) 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; bh=8Jn4hZ9tdpaAYkrg6uObPubjzh2tnI6snetY57x95ic=; b=aCQmN9Zw+ybFDFmjWkTL6iFLyJUnS4MavW2V4MsJUpcO/8R4vPGN9YSIfYtYT9jsG4 UaP0icorXgG38r1m83rffbw8g7DYGwq6Hn2lglS+iP33CE0nAxD7qCfcimZM6K1UMMet krxaparCTS+R8u1mQt3tVGByy2EA0FAvtgHYflfMB0hSFew+Gp6wxUUeioE/bjwE+//T MnBxy6ngMicRxwj2tKJin72ly6srzO4n3mp5/yM2Y0nMborb51KfbakQuOlsGzQaEiN6 zlm/rtf4ELQ4gvf58gFIfq2/p6Qv4+sk1+lQP8Hi/8bbzCy1MGoq5Szb2HXkFfpTU78u r6qA== MIME-Version: 1.0 X-Received: by 10.181.12.1 with SMTP id em1mr9254902wid.4.1371600981468; Tue, 18 Jun 2013 17:16:21 -0700 (PDT) Received: by 10.216.29.5 with HTTP; Tue, 18 Jun 2013 17:16:21 -0700 (PDT) In-Reply-To: References: <201306182327.r5INR5RO007548@mail172c38.carrierzone.com> Date: Tue, 18 Jun 2013 19:16:21 -0500 Message-ID: From: Nico Williams To: Bill Frantz Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS grammar checker? 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, 19 Jun 2013 00:16:35 -0000 On Tue, Jun 18, 2013 at 7:05 PM, Bill Frantz wrote: > On 6/18/13 at 4:26 PM, uri@ll.mit.edu (Blumenthal, Uri - 0558 - MITLL) > wrote: > >> Having written my share of ASN.1 stuff (including parser/encoder with no >> known vulnerabilities :), I agree with Nico's assessment of ASN.1. > > > No known vulnerabilities is a good start. Unfortunately a lot of software is > released with no know vulnerabilities but doesn't hold up under attack. It > is nice to hear of software that has survived attack with no known > vulnerabilities. Automatic tooling is a better start. I.e., ASN.1, XDR, IDL, ... compilers. Ad-hoc syntaxes don't lend themselves to automatic tooling, so they tend to result in lots of error-prone hand-coding. What are you arguing for? (Mind you, this really isn't the right place... that goes for me too) >> The syntax itself is fine as far as security goes. It's not terribly >> easy to parse (so that's one reason not to use it), that's about the >> only significant problem with the *syntax*. > > Here is the reason I worry. The harder things are to do, the more likely > mistakes will be made. That is why I prefer simpler formats. Formats or syntaxes? Let's be clear. And yes, the fact that ASN.1 is relatively difficult to parse (but not that difficult) has been used as an excuse to not use it or not write tooling for it and just hand-code BER/DER coders. But I think in retrospect that it's not really the cause of the problem. More likely the fact that it was a non-free standard for so long meant that many people coded to it without a proper understanding if it, much less access to tools for it. But that's ancient history now. What about the present? Why not use this or that not-ad-hoc syntax? > While I'm bashing ASN.1, formats that allow infinite length data items are > asking for buffer overruns. Like JSON? Parsers/decoders need to impose some reasonable limits. But this is not where the buffer overflows come from. The buffer overflows I think you're thinking of mostly resulted from redundancy in TLV encodings. Nico -- From prvs=9882fcc32e=uri@ll.mit.edu Tue Jun 18 17:22:44 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 1462E21E80A5 for ; Tue, 18 Jun 2013 17:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.035 X-Spam-Level: X-Spam-Status: No, score=-6.035 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C9Vd7ycV-LiI for ; Tue, 18 Jun 2013 17:22:39 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 6912B11E811A for ; Tue, 18 Jun 2013 17:22:34 -0700 (PDT) Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r5J0MWYF009664; Tue, 18 Jun 2013 20:22:32 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: "'frantz@pwpconsult.com'" Date: Tue, 18 Jun 2013 20:22:31 -0400 Thread-Topic: [TLS] TLS grammar checker? Thread-Index: Ac5sgLnolRtlFZhDTJuVj8NrdxGchAAAlppW In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-06-18_09:2013-06-18, 2013-06-18, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1306180266 Message-Id: <20130619002237.6912B11E811A@ietfa.amsl.com> Cc: "'tls@ietf.org'" Subject: Re: [TLS] TLS grammar checker? 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, 19 Jun 2013 00:22:44 -0000 Bill, For the software I was talking about - it is finish now, not the start. It'= s been deployed on multiple platforms since 1995 (testing the code included= procedure currently called "fuzzing" :). And survived unscathed for severa= l years that I tracked it. Decommissioned by now, I suspect, undefeated as = far as I know. So while I admire the skepticism expressed below, it probably could find a = better application. ;). Not all the computer security is born equal. :) -- Regards, Uri Blumenthal Voice: (781) 981-1638 Cyber Systems and Technology Fax: (781) 981-0186 MIT Lincoln Laboratory Cell: (339) 223-5363 244 Wood Street Email: Lexington, MA 02420-9185 =20 Web: http://www.ll.mit.edu/CST/ =20 MIT LL Root CA:=20 DSN: 478-5980 ask Lincoln ext.1638 ----- Original Message ----- From: Bill Frantz [mailto:frantz@pwpconsult.com] Sent: Tuesday, June 18, 2013 07:05 PM=0A= To: Blumenthal, Uri - 0558 - MITLL Cc: 'nico@cryptonector.com' ; 'tls@ietf.org' ; 'frantz@pwpconsult.com' Subject: Re: [TLS] TLS grammar checker? I admire the optimism expressed here. Particularly given the=20 state of computer security today. [More inline] Cheers - Bill On 6/18/13 at 4:26 PM, uri@ll.mit.edu (Blumenthal, Uri - 0558 -=20 MITLL) wrote: >Having written my share of ASN.1 stuff (including=20 >parser/encoder with no known vulnerabilities :), I agree with=20 >Nico's assessment of ASN.1. No known vulnerabilities is a good start. Unfortunately a lot of=20 software is released with no know vulnerabilities but doesn't=20 hold up under attack. It is nice to hear of software that has=20 survived attack with no known vulnerabilities. >TNX! >-- >Regards, >Uri Blumenthal Voice: (781) 981-1638 >Cyber Systems and Technology Fax: (781) 981-0186 >MIT Lincoln Laboratory Cell: (339) 223-5363 >244 Wood Street Email: >Lexington, MA 02420-9185 >Web: http://www.ll.mit.edu/CST/ > > > >MIT LL Root CA: > > > >DSN: 478-5980 ask Lincoln ext.1638 > >----- Original Message ----- >From: Nico Williams [mailto:nico@cryptonector.com] >Sent: Tuesday, June 18, 2013 05:49 PM >To: Bill Frantz >Cc: tls@ietf.org >Subject: Re: [TLS] TLS grammar checker? > >On Tue, Jun 18, 2013 at 5:20 PM, Bill Frantz wrote= : >>On 6/18/13 at 10:36 AM, nico@cryptonector.com (Nico Williams) wrote: >> >>> This would make it possible to use ASN.1 for >>> specifying JSON schemas too, but no one who doesn't already have to >>> use ASN.1 wants to use ASN.1, though I myself like ASN.1 -- I only >>> hate its TLV encodings. >> >> >>Given the history of serious security problems due to ASN.1 parser bugs, = I >>would feel better with a simpler format. (And yes, I'm one of the people = who >>developed an allergy to ASN.1 through use.) > >This tells me that you don't understand what you're talking about, >that your reaction is knee-jerk. > >ASN.1 is just a syntax. The security bugs have been in decoders of >some encoding rules of ASN.1, like BER. > >And there have been security vulnerabilities in *many* encodings not >related to ASN.1, such as XDR, NDR, and others. The problem is not >exclusive to TLV (tag-length-value) encoding rules of ASN.1 (like BER) >nor to ASN.1 encoding rules. It's generic. > >The syntax itself is fine as far as security goes. It's not terribly >easy to parse (so that's one reason not to use it), that's about the >only significant problem with the *syntax*. Here is the reason I worry. The harder things are to do, the=20 more likely mistakes will be made. That is why I prefer simpler formats. While I'm bashing ASN.1, formats that allow infinite length data=20 items are asking for buffer overruns. >I'd go further and recommend the use of a syntax and encoding rules >for which there is suitable tooling available as this allows for more >formality in specifications, and fixing of bugs by fixing >encoder/decoder libraries, increasing code reuse, ... > >Nico >-- >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls > ----------------------------------------------------------------------- Bill Frantz | I don't have high-speed | Periwinkle (408)356-8506 | internet. I have DSL. | 16345=20 Englewood Ave www.pwpconsult.com | | Los Gatos,=20 CA 95032 From frantz@pwpconsult.com Tue Jun 18 19:03: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 5B44721F9952 for ; Tue, 18 Jun 2013 19:03:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.036 X-Spam-Level: X-Spam-Status: No, score=-2.036 tagged_above=-999 required=5 tests=[AWL=-0.188, BAYES_00=-2.599, SARE_OBFU_ALL=0.751] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GSez-WVpjfDP for ; Tue, 18 Jun 2013 19:03:11 -0700 (PDT) Received: from elasmtp-masked.atl.sa.earthlink.net (elasmtp-masked.atl.sa.earthlink.net [209.86.89.68]) by ietfa.amsl.com (Postfix) with ESMTP id 2397521F99A7 for ; Tue, 18 Jun 2013 19:03:08 -0700 (PDT) Received: from [173.75.83.226] (helo=Williams-MacBook-Pro.local) by elasmtp-masked.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1Up7jl-00065Y-1R; Tue, 18 Jun 2013 22:03:05 -0400 Date: Tue, 18 Jun 2013 19:03:04 -0700 From: Bill Frantz To: "Blumenthal, Uri - 0558 - MITLL" , "'nico@cryptonector.com'" X-Priority: 3 In-Reply-To: <201306190022.r5J0Md8g010534@mail136c38.carrierzone.com> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec79f8c45de55d1262dd57a8a62f306048e1350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.226 Cc: "'tls@ietf.org'" Subject: Re: [TLS] TLS grammar checker? 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, 19 Jun 2013 02:03:21 -0000 On 6/18/13 at 5:22 PM, uri@ll.mit.edu (Blumenthal, Uri - 0558 -=20 MITLL) wrote: >For the software I was talking about - it is finish now, not=20 >the start. It's been deployed on multiple platforms since 1995=20 >(testing the code included procedure currently called "fuzzing"=20 >:). And survived unscathed for several years that I tracked it.=20 >Decommissioned by now, I suspect, undefeated as far as I know. I'm glad to hear this. It is nice to know that there are a few=20 things out there that actually work. >So while I admire the skepticism expressed below, it probably=20 >could find a better application. ;). Not all the computer=20 >security is born equal. :) I fear that we should be designing for something closer to the=20 average programmer than for the superior programmer. If I could=20 make it idiot proof, I would, but as the saying goes, they keep=20 making better idiots. On 6/18/13 at 5:16 PM, nico@cryptonector.com (Nico Williams) wrote: >Automatic tooling is a better start. I.e., ASN.1, XDR, IDL, ... compilers= . > >Ad-hoc syntaxes don't lend themselves to automatic tooling, so they >tend to result in lots of error-prone hand-coding. I think this is a good direction. A proof of correctness might=20 help since compilers have been known to generate bad code. >What are you arguing for? (Mind you, this really isn't the right >place... that goes for me too) What I am arguing for in all security is simplicity. "As simple=20 as possible, but no simpler." Complex formats, procedures,=20 dependencies, etc. all make it harder to understand what=20 security is provided and easier to make mistakes in both=20 reasoning and coding. A long time ago a team from the National Computer Security=20 Center (NCSC) came to study KeyKOS, an operating system I was=20 working on. We had a fairly simple system which showed potential=20 for being evaluated at the B2 level. Someone asked, "What about=20 the microcode in the processor and the disk controllers?" The=20 answer was basically, "We ignore that." We are so dependent on so many levels of software and hardware.=20 Reducing those dependencies as much as possible, unless we can=20 show that additional dependencies make things better, seems like=20 a good idea. >Formats or syntaxes? Let's be clear. I not sure what difference you have in mind? >>While I'm bashing ASN.1, formats that allow infinite length data items ar= e >>asking for buffer overruns. > >Like JSON? Parsers/decoders need to impose some reasonable limits. >But this is not where the buffer overflows come from. The buffer >overflows I think you're thinking of mostly resulted from redundancy >in TLV encodings. I thought there were a few cases of getting the length from the=20 ASN.1, doing a malloc and ignoring the failure return and then=20 bad things happened(tm). This problem is somewhat like the=20 pervasive problem in the early C programming books. They showed=20 how simple string processing could be, but left buffer length=20 checking as an exercise for the reader. In any case, practical=20 parsers need to have some limits on length. =46or example, consider RSA keys. 4K keys are the long-normal high=20 security keys these days. If each integer is encoded with a 16=20 bit length field followed by the integer we would have plenty of=20 room for growth without causing memory problems on most platforms. On the other hand, a 512K RSA integer might be a nifty denial of=20 service attack on a server. So we still have to check for=20 something reasonable. --------------------------------------------------------------------------- Bill Frantz |"Web security is like medicine - trying to=20 do good for 408-356-8506 |an evolved body of kludges" - Mark Miller www.pwpconsult.com | From anders.rundgren@telia.com Tue Jun 18 21:56:22 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 C543B21F9D02 for ; Tue, 18 Jun 2013 21:56:22 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8c06kr3NBCFu for ; Tue, 18 Jun 2013 21:56:17 -0700 (PDT) Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id A2DAF21F9CF7 for ; Tue, 18 Jun 2013 21:56:16 -0700 (PDT) Received: from [192.168.0.203] (213.64.1.89) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 51B4DDE7002688E0; Wed, 19 Jun 2013 06:56:11 +0200 Message-ID: <51C139E8.9070206@telia.com> Date: Wed, 19 Jun 2013 06:56:08 +0200 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Geoffrey Keating References: <51C0A762.9030909@telia.com> <51C0DC81.3010908@telia.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "'tls@ietf.org'" Subject: Re: [TLS] Another [Well-deserved] attack on TLS CCA 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, 19 Jun 2013 04:56:22 -0000 On 2013-06-19 01:40, Geoffrey Keating wrote: > Anders Rundgren writes: > >> On 2013-06-18 23:39, Geoffrey Keating wrote: >>> Anders Rundgren writes: >>> >>>> https://sites.google.com/site/oauthgoog/gnubby >>>> >>>> Luckily for all users Google didn't select TLS CCA (Client Certificate >>>> Authentication) for their coming U2F system; only a moron would base a >>>> future consumer authentication system on a scheme that is only suited >>>> for VPN tunnels and invisible authentications like as ChannelID. >>>> >>>> What's missing you may wonder? Well, how about >>>> >>>> - Compatibility with web sessions including timeout and logout >>> >>> Logout is a client-side function, and occurs (typically) when the user >>> logs out of their local session and/or quits their web browser. >>> Timeout occurs when the TLS connection is closed due to inactivity >>> (typically 60 seconds) and the session resumption token is expired, >>> which is up to the server; or, looking at it another way, when the >>> user's screen lock triggers due to inactivity. >> >> Yes, but this is not how most web apps work today for good or for worse. > > That's because most web apps require the user to type a password, but > you can't require the user to type a password on every click, so they > only ask the user to enter the password once, and then they have to > maintain authentication status information using cookies (or similar). > Client certificates avoid this entirely; you don't need cookies, you > can authenticate on every request. This can dramatically simplify the > design of a web app. > > At least, that's one way to do it. If you're doing two-factor, you > can combine this with a password: you still have a session, with > login, logout and timeout, but you also require that every connection be tied > to the client certificate. A fly in the soup is that few if any of the web-server application frameworks out there like Java Servlets have any information or control over the TLS session. You'd probably have to program at "MOD-SSL" level or something like that :-) > >>>> - A working credential filtering system >>> >>> I think this is mostly due to lack of demand. I wouldn't say it isn't >>> "working", just that as commonly implemented, it isn't very good. >> >> There is a perceived little demand because many organizations who are big >> users of consumer-PKI have no voice in the IETF. I believe these guys >> would be slaughtered by the IETF bunch since they don't have exactly the >> same "lingo" and probably don't know very much about inner life of TLS. > > Asking at the IETF is definitely the wrong place to start this. At > present there's no consensus that any protocol changes are required > let alone what these changes might be. These organizations need to > ask the OS and/or browser vendors for better support, explaining in > detail what they need and why, and those vendors can work with them > and then if necessary do any protocol design under the IETF umbrella. Today VISA and MasterCard authorize credit-card transactions on the Internet with a "User ID" (card number + other details) together with a "Password" (CCV) printed in clear (!) on the back of the card. It is pretty obvious that there is a total disconnect between the different parties so we are essentially at the mercy of tech giants like Google who "can think for everybody else". Google have (with U2F) indirectly declared TLS CCA as not useful for consumer-auth and that's about it. Anders > From rsalz@akamai.com Wed Jun 19 04:49:43 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 AD25D21F9BA4 for ; Wed, 19 Jun 2013 04:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0XR0uft6vz8x for ; Wed, 19 Jun 2013 04:49:38 -0700 (PDT) Received: from prod-mail-xrelay01.akamai.com (prod-mail-xrelay01.akamai.com [72.246.2.12]) by ietfa.amsl.com (Postfix) with ESMTP id 71F4521F9B9F for ; Wed, 19 Jun 2013 04:49:38 -0700 (PDT) Received: from prod-mail-xrelay01.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 87937D0DF3 for ; Wed, 19 Jun 2013 11:49:37 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay01.akamai.com (Postfix) with ESMTP id 74415D0DC8 for ; Wed, 19 Jun 2013 11:49:37 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 68655FE069 for ; Wed, 19 Jun 2013 11:49:37 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.138]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Wed, 19 Jun 2013 07:49:37 -0400 From: "Salz, Rich" To: "tls@ietf.org" Date: Wed, 19 Jun 2013 07:49:36 -0400 Thread-Topic: [TLS] TLS grammar checker? Thread-Index: Ac5rISsUDXSD6GYhSGmJg9XjSlyL2gBwN2Lw Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711B20DDB18@USMBX1.msg.corp.akamai.com> References: <9A043F3CF02CD34C8E74AC1594475C7343D64D33@uxcn10-tdc02.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7343D64D33@uxcn10-tdc02.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] TLS grammar checker? 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, 19 Jun 2013 11:49:43 -0000 To quell some other commentary, I wasn't talking about creating any kind of= automatic code generation. Yesterday afternoon I wrote a yacc/lex (er, Bis= on/flex) parser that seems to get the syntax right. It doesn't do any seman= tic checking (e.g., duplicate choices in an enumeration). Not sure if I'll = go any further with it, so if you want it drop me a line. I think there is a great benefit to using a standard language. The knee-jer= k "no" to my ASN.1 suggestion doesn't surprise me. XSD is another possibili= ty, but that seems too ... weird .. for me. Many other IETF security standa= rds use ASN1, the documentation is freely available, it is widely known and= understood, and some tools are available. If I get some free time later in= the summer I might experiment with it. /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From pgut001@cs.auckland.ac.nz Wed Jun 19 05:11: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 1942321F938E for ; Wed, 19 Jun 2013 05:11:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-KDkXHNGzIZ for ; Wed, 19 Jun 2013 05:11:01 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 936AB21F93C4 for ; Wed, 19 Jun 2013 05:11:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1371643861; x=1403179861; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=uYr96mccVLPAbQ6aRNcMmguhRJxHr57hSFVnqZqUrgI=; b=gBzaBQAJ6olLRdelXZHvwDYgkEAgGDqKQjrkOQqxv1ejLWdL8UHhQUpy 1z2q62vUIFvV/2epUxSmyL0NX5+KB+35h+aFzs0wdrlJe/FbwuVax/w+C pDoPBzqTLPphGjxJVxiBdpMhz3gdJsGcBe/JU8v5hbeVWcVTf4qgh38Vl U=; X-IronPort-AV: E=Sophos;i="4.87,896,1363086000"; d="scan'208";a="194827250" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 20 Jun 2013 00:10:59 +1200 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.214]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Thu, 20 Jun 2013 00:10:59 +1200 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: [TLS] TLS grammar checker? Thread-Index: Ac5s5g6kDmm6G/0wSI+J9By9vowifA== Date: Wed, 19 Jun 2013 12:10:58 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7343D68B9A@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] TLS grammar checker? 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, 19 Jun 2013 12:11:11 -0000 Nico Williams writes:=0A= =0A= >Ad-hoc syntaxes don't lend themselves to automatic tooling, so they tend t= o=0A= >result in lots of error-prone hand-coding.=0A= =0A= That's the problem with the SSL/TLS syntax, it looks like it's specified in= a=0A= formal language but it's really more of a specialised notation used to outl= ine=0A= (not always clearly) bits-on-the-wire. SSH and PGP use a very low-level fo= rm=0A= (but still higher-level than TCP's pictorial bit-diagrams), which leads to= =0A= even more awkward hand-coded parsers (SSH makes it especially entertaining = due=0A= to its arbitrary mixing of binary data and comma-delimited string data).=0A= =0A= If I had to do a premortem analysis of my parsing code and arrange it in or= der=0A= of least to most likely to contain exploitable errors I'd have: ASN.1 -> La= rge=0A= gap -> SSL/TLS -> SSH. Not sure where PGP would fit in there, probably=0A= somewhere between SSL/TLS and SSH.=0A= =0A= >What are you arguing for? (Mind you, this really isn't the right place...= =0A= >that goes for me too)=0A= =0A= Yes it is, flamewars over data-description notations are at least as=0A= interesting as vi vs. emacs, or KDE vs Gnome, or Amiga vs. Atari.=0A= =0A= Peter.=0A= From hannes.tschofenig@gmx.net Wed Jun 19 05:29:57 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 5045221F99C3 for ; Wed, 19 Jun 2013 05:29:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.118 X-Spam-Level: X-Spam-Status: No, score=-101.118 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_HTML_ONLY=1.457, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ycKBC-WVYT7q for ; Wed, 19 Jun 2013 05:29:52 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) by ietfa.amsl.com (Postfix) with ESMTP id 625A521F9C0A for ; Wed, 19 Jun 2013 05:29:52 -0700 (PDT) Received: from 3capp-gmx-bs32.server.lan ([172.19.170.84]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0LjfpG-1UI9gp3CQa-00bYsW; Wed, 19 Jun 2013 14:29:47 +0200 Received: from [194.251.119.196] by 3capp-gmx-bs32.server.lan with HTTP; Wed Jun 19 14:29:47 CEST 2013 MIME-Version: 1.0 Message-ID: From: "Hannes Tschofenig" To: "Peter Gutmann" Content-Type: text/html; charset=UTF-8 Date: Wed, 19 Jun 2013 14:29:47 +0200 (CEST) Importance: normal Sensitivity: Normal In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7343D68B9A@uxcn10-2.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C7343D68B9A@uxcn10-2.UoA.auckland.ac.nz> X-UI-Message-Type: mail X-Priority: 3 X-Provags-ID: V03:K0:/zEbMZclOntyehD7oZ/TXRJ1E6KxwaxPrN6hOnoCahZ NOQlFpockebVUVLce7QdeL8W+AJxMC2uqAY8wBqriebRUmYXYN UMoJMhb6wyburcwldHQPE7pjCyM7+l3ieUYnd2aiNemj56e0dU ZqWy8cMws0kuTTFt7n+p5MZISUv3lSfzXjlnIWqFgI0mMSlqOO E7KfSNnz8nKOuvnl8xlIgbrh6StAigDLLVm3DxYvPw0I3Smn3R Ds+Jw7q8OFmzJB1dFG5Nl2m33TMAnhwklvY1NjOk3fcavLYBNM bxCSxg= Cc: "tls@ietf.org" Subject: Re: [TLS] TLS grammar checker? 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, 19 Jun 2013 12:29:57 -0000
To be honest, I never though that the SSL/TLS syntax is particularly helpful for an implementer nor for someone reading the document. 
I wonder whether it would be best to switch to something else in future documents. I don't think that mandating a specific language is particuarly useful either since (as we know from other protocols) there are pros and cons with all of them. 
 
I personally think that a description in natural language is typically best.
 
Gesendet: Mittwoch, 19. Juni 2013 um 14:10 Uhr
Von: "Peter Gutmann" <pgut001@cs.auckland.ac.nz>
An: "tls@ietf.org" <tls@ietf.org>
Betreff: Re: [TLS] TLS grammar checker?
Nico Williams <nico@cryptonector.com> writes:

>Ad-hoc syntaxes don't lend themselves to automatic tooling, so they tend to
>result in lots of error-prone hand-coding.

That's the problem with the SSL/TLS syntax, it looks like it's specified in a
formal language but it's really more of a specialised notation used to outline
(not always clearly) bits-on-the-wire. SSH and PGP use a very low-level form
(but still higher-level than TCP's pictorial bit-diagrams), which leads to
even more awkward hand-coded parsers (SSH makes it especially entertaining due
to its arbitrary mixing of binary data and comma-delimited string data).

If I had to do a premortem analysis of my parsing code and arrange it in order
of least to most likely to contain exploitable errors I'd have: ASN.1 -> Large
gap -> SSL/TLS -> SSH. Not sure where PGP would fit in there, probably
somewhere between SSL/TLS and SSH.

>What are you arguing for? (Mind you, this really isn't the right place...
>that goes for me too)

Yes it is, flamewars over data-description notations are at least as
interesting as vi vs. emacs, or KDE vs Gnome, or Amiga vs. Atari.

Peter.
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
From paul.hoffman@vpnc.org Wed Jun 19 07:12: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 96C2721F9113 for ; Wed, 19 Jun 2013 07:12:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ETPIoTOyPRTZ for ; Wed, 19 Jun 2013 07:12:02 -0700 (PDT) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id E4F6921F8F7B for ; Wed, 19 Jun 2013 07:12:01 -0700 (PDT) Received: from [10.20.30.90] (50-0-66-165.dsl.dynamic.sonic.net [50.0.66.165]) (authenticated bits=0) by hoffman.proper.com (8.14.5/8.14.5) with ESMTP id r5JEBvu3033314 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 19 Jun 2013 07:11:58 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Paul Hoffman In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711B20DDB18@USMBX1.msg.corp.akamai.com> Date: Wed, 19 Jun 2013 07:11:57 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <2CA0263C-4C88-4C1E-B82B-F6B436185F0D@vpnc.org> References: <9A043F3CF02CD34C8E74AC1594475C7343D64D33@uxcn10-tdc02.UoA.auckland.ac.nz> <2A0EFB9C05D0164E98F19BB0AF3708C711B20DDB18@USMBX1.msg.corp.akamai.com> To: "Salz, Rich" X-Mailer: Apple Mail (2.1508) Cc: "tls@ietf.org" Subject: Re: [TLS] TLS grammar checker? 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, 19 Jun 2013 14:12:02 -0000 On Jun 19, 2013, at 4:49 AM, "Salz, Rich" wrote: > To quell some other commentary, I wasn't talking about creating any = kind of automatic code generation. Yesterday afternoon I wrote a = yacc/lex (er, Bison/flex) parser that seems to get the syntax right. It = doesn't do any semantic checking (e.g., duplicate choices in an = enumeration). Not sure if I'll go any further with it, so if you want it = drop me a line. Please do let the list know where the tool can be found. It would be = useful to check current and future extension documents, and the future = 1.3 document. --Paul Hoffman= From rsalz@akamai.com Thu Jun 20 09:08:59 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 6B61521F9DC4 for ; Thu, 20 Jun 2013 09:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.67 X-Spam-Level: X-Spam-Status: No, score=-1.67 tagged_above=-999 required=5 tests=[AWL=0.930, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TF8ad4JKbxrm for ; Thu, 20 Jun 2013 09:08:54 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 410AF21F9DB7 for ; Thu, 20 Jun 2013 09:08:54 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 612DE480D0 for ; Thu, 20 Jun 2013 16:08:53 +0000 (GMT) Received: from prod-mail-relay04.akamai.com (prod-mail-relay04.akamai.com [172.27.8.27]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 55733480CD for ; Thu, 20 Jun 2013 16:08:53 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay04.akamai.com (Postfix) with ESMTP id 3A46347BD2 for ; Thu, 20 Jun 2013 16:08:53 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.138]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Thu, 20 Jun 2013 12:08:52 -0400 From: "Salz, Rich" To: "TLS@ietf.org (tls@ietf.org)" Date: Thu, 20 Jun 2013 12:08:51 -0400 Thread-Topic: [TLS] TLS grammar checker? Thread-Index: Ac5rISsUDXSD6GYhSGmJg9XjSlyL2gBwN2LwADuITfA= Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711B20DE146@USMBX1.msg.corp.akamai.com> References: <9A043F3CF02CD34C8E74AC1594475C7343D64D33@uxcn10-tdc02.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] TLS grammar checker? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 16:08:59 -0000 > To quell some other commentary, I wasn't talking about creating any kind = of automatic code generation. Yesterday afternoon I wrote a yacc/lex (er, B= ison/flex) parser that seems to get the syntax right. It doesn't do any sem= antic checking (e.g., duplicate choices in an enumeration). Not sure if I'l= l go any further with it, so if you want it drop me a line. In case anyone's interested: https://docs.google.com/file/d/0B8YgrWYHqacSND= hCekgtWUVPMW8/edit?usp=3Dsharing It's 210 lines of code in the public domai= n. Hope it's useful. > I think there is a great benefit to using a standard language. The knee-j= erk "no" to my ASN.1 suggestion doesn't surprise me. XSD is another possibi= lity, but that seems too ... weird .. for me. Many other IETF security stan= dards use ASN1, the documentation is freely available, it is widely known a= nd understood, and some tools are available. If I get some free time later = in the summer I might experiment with it. Still true :) /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From mrex@sap.com Thu Jun 20 16:49: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 4C43021F9E0C for ; Thu, 20 Jun 2013 16:49:58 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TtTWqnYdFKNS for ; Thu, 20 Jun 2013 16:49:53 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id DED0921F9DEB for ; Thu, 20 Jun 2013 16:49:51 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r5KNnlVi023667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 Jun 2013 01:49:47 +0200 (MEST) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711B20DE146@USMBX1.msg.corp.akamai.com> To: "Salz, Rich" Date: Fri, 21 Jun 2013 01:49:47 +0200 (CEST) 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: <20130620234947.831A21A83A@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] TLS grammar checker? 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: Thu, 20 Jun 2013 23:49:58 -0000 Salz, Rich wrote: > > Many other IETF security standards use ASN1, the documentation is > freely available, it is widely known and understood, and some tools > are available. ASN.1 ... is ... widely ... known ... and ... understood ? I haven't met anyone who understands ASN.1 so far (which is different from folks who believe they do or folks who use it to write poor specs). -Martin From rsalz@akamai.com Fri Jun 21 03:29:11 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 E9EC611E8115 for ; Fri, 21 Jun 2013 03:29:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSDE3zNvKIz9 for ; Fri, 21 Jun 2013 03:28:59 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [96.6.114.97]) by ietfa.amsl.com (Postfix) with ESMTP id CE92711E8112 for ; Fri, 21 Jun 2013 03:28:59 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 071CC1C47EC; Fri, 21 Jun 2013 10:28:59 +0000 (GMT) Received: from prod-mail-relay03.akamai.com (prod-mail-relay03.akamai.com [172.27.8.26]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id F06C71C47E1; Fri, 21 Jun 2013 10:28:58 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay03.akamai.com (Postfix) with ESMTP id D697D2FD51; Fri, 21 Jun 2013 10:28:58 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.138]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Fri, 21 Jun 2013 06:28:58 -0400 From: "Salz, Rich" To: "mrex@sap.com" Date: Fri, 21 Jun 2013 06:28:57 -0400 Thread-Topic: [TLS] TLS grammar checker? Thread-Index: Ac5uENs5IxjiodmeRAC8eaF0udE5ywAWPMzw Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711B20DE385@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C711B20DE146@USMBX1.msg.corp.akamai.com> <20130620234947.831A21A83A@ld9781.wdf.sap.corp> In-Reply-To: <20130620234947.831A21A83A@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] TLS grammar checker? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 10:29:12 -0000 > ASN.1 ... is ... widely ... known ... and ... understood ? Compared to the alternatives, yes. Look at what data definition languages= are used in RFC's.=20 /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From prvs=9884b7ec51=uri@ll.mit.edu Fri Jun 21 04:21:49 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 543E321F9ABE for ; Fri, 21 Jun 2013 04:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.972 X-Spam-Level: X-Spam-Status: No, score=-5.972 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UTisITlzy+wV for ; Fri, 21 Jun 2013 04:21:45 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 6477A21F9AEB for ; Fri, 21 Jun 2013 04:21:41 -0700 (PDT) Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r5LBLWld024269; Fri, 21 Jun 2013 07:21:32 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: "'rsalz@akamai.com'" , "'mrex@sap.com'" Date: Fri, 21 Jun 2013 07:21:30 -0400 Thread-Topic: [TLS] TLS grammar checker? Thread-Index: Ac5uENs5IxjiodmeRAC8eaF0udE5ywAWPMzwAAHqOik= In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711B20DE385@USMBX1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-06-21_05:2013-06-21, 2013-06-21, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1306210057 Message-Id: <20130621112141.6477A21F9AEB@ietfa.amsl.com> Cc: "'tls@ietf.org'" Subject: Re: [TLS] TLS grammar checker? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 11:21:49 -0000 Couldn't have said it better myself. :-) -- Regards, Uri Blumenthal Voice: (781) 981-1638 Cyber Systems and Technology Fax: (781) 981-0186 MIT Lincoln Laboratory Cell: (339) 223-5363 244 Wood Street Email: Lexington, MA 02420-9185 =20 Web: http://www.ll.mit.edu/CST/ =20 MIT LL Root CA:=20 DSN: 478-5980 ask Lincoln ext.1638 ----- Original Message ----- From: Salz, Rich [mailto:rsalz@akamai.com] Sent: Friday, June 21, 2013 05:28 AM=0A= To: mrex@sap.com Cc: TLS@ietf.org (tls@ietf.org) Subject: Re: [TLS] TLS grammar checker? > ASN.1 ... is ... widely ... known ... and ... understood ? Compared to the alternatives, yes. Look at what data definition languages= are used in RFC's.=20 /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From n.mavrogiannopoulos@gmail.com Fri Jun 21 06:17: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 B3B1221E810B for ; Fri, 21 Jun 2013 06:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6FRtiyNYUJu4 for ; Fri, 21 Jun 2013 06:17:10 -0700 (PDT) Received: from mail-qa0-x22d.google.com (mail-qa0-x22d.google.com [IPv6:2607:f8b0:400d:c00::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 2E81B21F9A3E for ; Fri, 21 Jun 2013 06:17:09 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id ci6so531382qab.18 for ; Fri, 21 Jun 2013 06:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=2QShUYjyc1ApLH5tfevDnqB5J7wTDFAsslhC/bWB7nc=; b=iHwtqPIoV8DMYbNbo8TVXfxq+KvzPSWtwAAWCAHyaWp+lAzNVbLqcD+OgOQvGhVcIW 2JmCtgpVDD1qKX5xhE713wxlamViEh0RmCcZyeZlZz5Dc/d2vwvj+QRKMs4bt2qeAKzl dAZA3YRXh+TT4OBuLvuplApOd2HvjYpjPIfZiUPUUiX1bFUThZ1UlOeCR4voU39atvO0 J4lgBcMTuYFS4Ms/OwfLQwQfS0iGT02mFhZV9C9t+76T28GmDBJrCuiS2hHvh5s2WRcR 8i8oTZnzS2faonHckJqSWPiw1IMjvrfyugGA1fTt/Ovcliwpdj8+2Jbeat6A02iMl9hV xTCA== MIME-Version: 1.0 X-Received: by 10.49.107.201 with SMTP id he9mr5454311qeb.74.1371820629475; Fri, 21 Jun 2013 06:17:09 -0700 (PDT) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.229.151.195 with HTTP; Fri, 21 Jun 2013 06:17:09 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711B20DE385@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C711B20DE146@USMBX1.msg.corp.akamai.com> <20130620234947.831A21A83A@ld9781.wdf.sap.corp> <2A0EFB9C05D0164E98F19BB0AF3708C711B20DE385@USMBX1.msg.corp.akamai.com> Date: Fri, 21 Jun 2013 15:17:09 +0200 X-Google-Sender-Auth: Cn337lqY07JlU30K_sKY10Eae1g Message-ID: From: Nikos Mavrogiannopoulos To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] TLS grammar checker? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 13:17:10 -0000 On Fri, Jun 21, 2013 at 12:28 PM, Salz, Rich wrote: >> ASN.1 ... is ... widely ... known ... and ... understood ? > Compared to the alternatives, yes. Look at what data definition languages are used in RFC's. Actually ASN.1 is the minority in definition languages in RFCs and I believe much more people understand HTTP or SMTP than ASN.1. There was a reason ASN.1 was avoided in the TLS protocol, and that is simplicity(*). I don't think much has changed since then. regards, Nikos (*). See for example the note on the usage of PKCS #6 in RFC2246. From rsalz@akamai.com Fri Jun 21 06:23: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 8878521F9A64 for ; Fri, 21 Jun 2013 06:23:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmfRnKRH8rPW for ; Fri, 21 Jun 2013 06:23:20 -0700 (PDT) Received: from prod-mail-xrelay01.akamai.com (prod-mail-xrelay01.akamai.com [72.246.2.12]) by ietfa.amsl.com (Postfix) with ESMTP id 38F1A21F9FF8 for ; Fri, 21 Jun 2013 06:23:19 -0700 (PDT) Received: from prod-mail-xrelay01.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C853ED1D2B; Fri, 21 Jun 2013 13:23:18 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay01.akamai.com (Postfix) with ESMTP id B3044CFF19; Fri, 21 Jun 2013 13:23:18 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 9ADF1FE066; Fri, 21 Jun 2013 13:23:18 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.138]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Fri, 21 Jun 2013 09:23:18 -0400 From: "Salz, Rich" To: Nikos Mavrogiannopoulos Date: Fri, 21 Jun 2013 09:23:16 -0400 Thread-Topic: [TLS] TLS grammar checker? Thread-Index: Ac5ugaWT2AVcxsRbS+qLK+qVm9OXfgAAJMTQ Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711B20DE42B@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C711B20DE146@USMBX1.msg.corp.akamai.com> <20130620234947.831A21A83A@ld9781.wdf.sap.corp> <2A0EFB9C05D0164E98F19BB0AF3708C711B20DE385@USMBX1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] TLS grammar checker? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 13:23:25 -0000 PiBBY3R1YWxseSBBU04uMSBpcyB0aGUgbWlub3JpdHkgaW4gZGVmaW5pdGlvbiBsYW5ndWFnZXMg aW4gUkZDcyBhbmQgSSBiZWxpZXZlIG11Y2ggbW9yZSBwZW9wbGUgdW5kZXJzdGFuZCBIVFRQIG9y IFNNVFAgdGhhbiBBU04uMS4NCg0KUGVyaGFwcyBJIHdhc24ndCBjbGVhciBieSBkYXRhIGRlZmlu aXRpb24gbGFuZ3VhZ2UuICBJIG1lYW4gdGhpbmdzIGxpa2UgWFNELCBTUUwgc2NoZW1hLCBPTUcg SURMLCBSUEMgTkRSLCBldGMuDQoNClllcywgb2YgY291cnNlIG1hbnkgbW9yZSBmb2xrcyB1bmRl cnN0YW5kIEhUVFAgYW5kIFNNVFAuICBCdXQgY29tcGFyZSBsaWtlIHRvIGxpa2UuDQoNCldoYXQg b3RoZXIgZGF0YSBkZWZpbml0aW9uIGxhbmd1YWdlIGFyZSB0aGVyZSBiZXNpZGVzIFNTTC9UTFMs IEFCTkYsIGFuZCBBU04uMT8NCg0KCS9yJCANCg0KLS0gIA0KUHJpbmNpcGFsIFNlY3VyaXR5IEVu Z2luZWVyDQpBa2FtYWkgVGVjaG5vbG9neQ0KQ2FtYnJpZGdlLCBNQQ0KDQo= From omh1835@g.rit.edu Fri Jun 21 11:35:38 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 A2CFC21E812D for ; Fri, 21 Jun 2013 11:35:38 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5BLf5xPU7r9W for ; Fri, 21 Jun 2013 11:35:34 -0700 (PDT) Received: from sc3app27.rit.edu (sc3app27.rit.edu [129.21.35.56]) by ietfa.amsl.com (Postfix) with ESMTP id 14A2221F9FE4 for ; Fri, 21 Jun 2013 11:35:33 -0700 (PDT) Received: from mail-ie0-f177.google.com (mail-ie0-f177.google.com [209.85.223.177]) by smtp-server.rit.edu (PMDF V6.3-x14 #31420) with ESMTPS id <0MOR006I1AB6HR@smtp-server.rit.edu> for tls@ietf.org; Fri, 21 Jun 2013 14:35:31 -0400 (EDT) Received: by mail-ie0-f177.google.com with SMTP id aq17so18678664iec.8 for ; Fri, 21 Jun 2013 11:35:30 -0700 (PDT) Received: by 10.43.115.3 with HTTP; Fri, 21 Jun 2013 11:35:29 -0700 (PDT) X-Received: by 10.42.95.208 with SMTP id g16mr6495055icn.45.1371839730055; Fri, 21 Jun 2013 11:35:30 -0700 (PDT) X-Received: by 10.42.95.208 with SMTP id g16mr6495048icn.45.1371839729930; Fri, 21 Jun 2013 11:35:29 -0700 (PDT) Date: Fri, 21 Jun 2013 21:35:29 +0300 From: "OMAR HASSAN (RIT Student)" Sender: omh1835@rit.edu To: "tls@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary=20cf303636fbcaa5b704dfae532b X-RIT-Received-From: 209.85.223.177 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:date:x-google-sender-auth:message-id:subject :from:to:content-type:x-gm-message-state; bh=wV3a3TCmNp45jKA4kdOyZXxfx5Ot6MnEck14pb/NZ8U=; b=ZoeS3+WpWF8xqKh1aTcBocpqY4/XHPWcIZZKxF2qNiOfNWDrdGYLBR1s1AcLGl4RZ+ zJj0pLEkCcVwXATFcQFuAcP2qYmNdndPYyVDNfaF3hoE7tF1GTzGc4MWJmJuDNRxRAUa ATisxXhZXTAuKdaPJWAZwmWH6FXGBVXxVBBIAYhuN8/RhgVhAR7srams6+H3volJUfj8 aOwmROBSKHGNIOLpiLGC+I6SSHBa3i1qwqoLzWU6ne43nvDduAGloIiGEy9YsGIF8Bph Bum5rs/i82/qja0yuEkDV5C+wfTm5S+uh3lVOYA3q9bgHG7Pq4H891Sidk2S1hhY3auT NPNA== X-Google-Sender-Auth: QbmtvoKiQANyWQZkR9UI18BVZrA X-Gm-Message-State: ALoCoQlx1tgVS6M/Sg+euUfOhA1purSBGc2NbgmPsUUV1iMP1TP7ZJya/mKioRAfO7cS3Kwl719fmWVZkvvMK25Sb6SF6LO+nlkeh1pVBIzcoxCPZbeJZLeoyGkwXh3Gr/dBI7m7OaUT Subject: [TLS] User Defined Key Pair X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 18:35:38 -0000 --20cf303636fbcaa5b704dfae532b Content-Type: text/plain; charset=ISO-8859-1 Hello All, I have uploaded a new version of the User Defined Key pair protocol that is cleaner and briefer, I will appreciate any comments or suggestions. Just to remind you: http://tools.ietf.org/html/draft-omar-tls-udkp-01 The new protocol is a new way of securing the traffic to websites without being depending on any third party to secure the traffic between the user and the website, so it will be possible for the user to secure his browsing using his credential information, smart card, or a random file on usb. That will make the use of two factor for authentication and traffic security is separated from the application code, the website admin only needs to configure how the users are going to access the website. Additionally there are no passwords required to be transferred any more on the network, which will render the Phishing attack useless. The motivation behind the new protocol is to make the security the responsibility of the two involved parties, because as you know, the security and confidentiality of user browsing in TLS depend upon the number of Certificate Authorities (CAs), major web browsers trust hundreds of different firms to issue certificates. Each of these firms can be compelled by their national government, or being compromised to issue a certificate for any particular website that all web browsers will trust without warning.Thus, users around the world are put in a position where their browser entrusts their private data, indirectly, to a large number of governments, and entities. (http://cryptome.org/ssl-mitm.pdf) Thank You Best Regards --20cf303636fbcaa5b704dfae532b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello All,

I have uploaded a new = version of the User Defined Key pair protocol that is cleaner and briefer, = I will appreciate any comments or suggestions.=A0

=
Just to remind you:


The new protocol is a new way of securing the t= raffic to websites without being depending on any third party to secure the= traffic between the user and the website, so it will be possible for the u= ser to secure his browsing using his credential information, smart card, or= a random file on usb. That will make the use of two factor for authenticat= ion and traffic security is separated from the application code, the websit= e admin=A0only=A0needs to configure how the users are going to access the w= ebsite. Additionally there are no passwords required to be transferred any = more on the network, which will render the Phishing attack useless.<= br>

The = motivation behind the new protocol is to make the security the responsibili= ty of the two involved parties, because as you know, the security and confi= dentiality of user browsing in TLS depend upon the number of Certificate Au= thorities (CAs), major web browsers trust hundreds of different =0Cfirms to= issue certificates. Each of these =0Cfirms can be compelled by their natio= nal government, or being compromised to issue a certificate for any particu= lar website that all web browsers will trust without warning.Thus, users ar= ound the world are put in a position where their browser entrusts their pri= vate data, indirectly, to a large number of governments, and entities. (http://cryptome.org/ssl-mitm.pdf)

=
Thank You
<= div style=3D"font-family:arial,sans-serif;font-size:13px">Best Regards
--20cf303636fbcaa5b704dfae532b-- From mrex@sap.com Fri Jun 21 12:22:05 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 30A3121F9E2A for ; Fri, 21 Jun 2013 12:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.949 X-Spam-Level: X-Spam-Status: No, score=-9.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 96u51ZATJ6Ny for ; Fri, 21 Jun 2013 12:22:01 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id AC98D21F9644 for ; Fri, 21 Jun 2013 12:21:59 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r5LJLtig010755 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 Jun 2013 21:21:55 +0200 (MEST) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C711B20DE385@USMBX1.msg.corp.akamai.com> To: "Salz, Rich" Date: Fri, 21 Jun 2013 21:21:55 +0200 (CEST) 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: <20130621192155.A2C451A840@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] TLS grammar checker? 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, 21 Jun 2013 19:22:05 -0000 Salz, Rich wrote: > > ASN.1 ... is ... widely ... known ... and ... understood ? > > Compared to the alternatives, yes. > Look at what data definition languages are used in RFC's. To illustrate one of my many problems with ASN.1 complexity and lack of clarity, I was recently wondering on OCSP, whether it is permissible or not _on_receipt_ when the "RevodedInfo->revocationTime" element http://tools.ietf.org/html/rfc2560#page-9 or the CRL Extension "CRL References" "CrlID->crlTime" element http://tools.ietf.org/html/rfc2560#section-4.4.2 contains a date&time with only 2-year, where exactly in ASN.1 it is described how the receiver ought to be implemented, and whether support for 2-digit years in GeneralizedTime is a "MAY", "SHOULD NOT" or "MUST NOT". -Martin From DPKemp@missi.ncsc.mil Fri Jun 21 13:42:53 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 07B4D21F9DE3 for ; Fri, 21 Jun 2013 13:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id akC-Kwv9jSNL for ; Fri, 21 Jun 2013 13:42:47 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id BFBFE21F9DE1 for ; Fri, 21 Jun 2013 13:42:47 -0700 (PDT) Received: from clavin.missi.ncsc.mil (squid.missi.ncsc.mil [144.51.60.169]) by stingray.missi.ncsc.mil with ESMTP id r5LKgkbw070497 for ; Fri, 21 Jun 2013 16:42:46 -0400 (EDT) Received: from CLAVIN.missi.ncsc.mil ([169.254.1.133]) by SQUID.missi.ncsc.mil ([fe80::e032:d4c7:c51f:85ec%14]) with mapi id 14.03.0123.003; Fri, 21 Jun 2013 16:42:46 -0400 From: "Kemp, David P." To: "TLS@ietf.org (tls@ietf.org)" Thread-Topic: [TLS] TLS grammar checker? Thread-Index: AQHObrSjPO4G/PGCq0GmSUxJ1/05VplAoO+A Date: Fri, 21 Jun 2013 20:42:45 +0000 Message-ID: <5B1D7E570380A64989D4C069F7D14BC8880726B9@clavin.missi.ncsc.mil> References: <2A0EFB9C05D0164E98F19BB0AF3708C711B20DE385@USMBX1.msg.corp.akamai.com> <20130621192155.A2C451A840@ld9781.wdf.sap.corp> In-Reply-To: <20130621192155.A2C451A840@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.51.56.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] TLS grammar checker? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 20:42:53 -0000 Of all the possible criticisms of ASN.1, this doesn't seem to be among them= . X.680 is unambiguous - the year MUST be 4 digits: 46.3 The type is defined, using ASN.1, as follows: GeneralizedTime ::=3D [UNIVERSAL 24] IMPLICIT VisibleString with the values of the VisibleString restricted to strings of characters which are either: a) a specification of a calendar date followed by a local time, consisting of: 1) a string representing the calendar date, as specified in ISO 8601, 4.1.2.2 - Basic format); followed by: NOTE 1 - This specifies a four-digit representation of the year, a two-digit representation of the month and a two-digit representation of the day, without use of separators. -----Original Message----- From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Marti= n Rex Sent: Friday, June 21, 2013 3:22 PM To: Salz, Rich Cc: TLS@ietf.org (tls@ietf.org) Subject: Re: [TLS] TLS grammar checker? Salz, Rich wrote: > > ASN.1 ... is ... widely ... known ... and ... understood ? >=20 > Compared to the alternatives, yes. > Look at what data definition languages are used in RFC's.=20 To illustrate one of my many problems with ASN.1 complexity and lack of cla= rity, I was recently wondering on OCSP, whether it is permissible or not _o= n_receipt_ when the "RevodedInfo->revocationTime" element http://tools.ietf.org/html/rfc2560#page-9 or the CRL Extension "CRL References" "CrlID->crlTime" element http://tools.ietf.org/html/rfc2560#section-4.4.2 contains a date&time with only 2-year, where exactly in ASN.1 it is describ= ed how the receiver ought to be implemented, and whether support for 2-digi= t years in GeneralizedTime is a "MAY", "SHOULD NOT" or "MUST NOT". =20 -Martin _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From mrex@sap.com Fri Jun 21 13:58:44 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 9E6E821F9E27 for ; Fri, 21 Jun 2013 13:58:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.799 X-Spam-Level: X-Spam-Status: No, score=-9.799 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tCj3-D7UKzhj for ; Fri, 21 Jun 2013 13:58:40 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4143D21F9E24 for ; Fri, 21 Jun 2013 13:58:39 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id r5LKwbWE025160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 Jun 2013 22:58:37 +0200 (MEST) In-Reply-To: <5B1D7E570380A64989D4C069F7D14BC8880726B9@clavin.missi.ncsc.mil> To: "Kemp, David P." Date: Fri, 21 Jun 2013 22:58:37 +0200 (CEST) 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: <20130621205837.3F1741A841@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] TLS grammar checker? 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, 21 Jun 2013 20:58:44 -0000 Kemp, David P. wrote: > Of all the possible criticisms of ASN.1, this doesn't seem to be > among them. X.680 is unambiguous - the year MUST be 4 digits: Your answer is way off the target. I didn't ask about what to send out, but what to accept(!) and why. rfc2560 OSCP is based on X.690-1994: http://tools.ietf.org/html/rfc2560#section-6 [X.690] ITU-T Recommendation X.690 (1994) | ISO/IEC 8825-1:1995, Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER). If you search X.680 from 1994 for GeneralizedTime, it only says that it is a reserved keyword (therefore useless for the question at hand). In order to figure out what to **ACCEPT**, you have to refer to the original specifcation exclusively. Your quote seems to be from X.680 2008. -Martin > > 46.3 The type is defined, using ASN.1, as follows: > GeneralizedTime ::= [UNIVERSAL 24] IMPLICIT VisibleString > with the values of the VisibleString restricted to strings > of characters which are either: > a) a specification of a calendar date followed by a local > time, consisting of: > 1) a string representing the calendar date, as specified > in ISO 8601, 4.1.2.2 - Basic format); followed by: > > NOTE 1 - This specifies a four-digit representation > of the year, a two-digit representation of the month > and a two-digit representation of the day, without > use of separators. > > > > -----Original Message----- > > To illustrate one of my many problems with ASN.1 complexity and lack > of clarity, I was recently wondering on OCSP, whether it is permissible > or not _on_receipt_ when the "RevodedInfo->revocationTime" element > > http://tools.ietf.org/html/rfc2560#page-9 > > or the CRL Extension "CRL References" "CrlID->crlTime" element > > http://tools.ietf.org/html/rfc2560#section-4.4.2 > > contains a date&time with only 2-year, where exactly in ASN.1 it is > described how the receiver ought to be implemented, and whether > support for 2-digit years in GeneralizedTime is a "MAY", "SHOULD NOT" > or "MUST NOT". From nico@cryptonector.com Fri Jun 21 14:06:51 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 A5B1721F9D4F for ; Fri, 21 Jun 2013 14:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xnaTuD3JrGoJ for ; Fri, 21 Jun 2013 14:06:46 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (caiajhbdcbef.dreamhost.com [208.97.132.145]) by ietfa.amsl.com (Postfix) with ESMTP id C485921F9944 for ; Fri, 21 Jun 2013 14:06:46 -0700 (PDT) Received: from homiemail-a65.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTP id 4ECB77E4073 for ; Fri, 21 Jun 2013 14:06:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=/D5N4NAuVMz1pvnViw2l b7cL34c=; b=geTWTtsc4jfHX0925FxxkevKSys964oJQIGHh7WG6RIDAyGsjZof wSSO93RR7SaGRs2pXjG7rlrkL06xIsBG1Bc+UwI6w/PxNy5jUgkcY8RmzBiqGk43 jnnWQQestTfiapC2zNpA6Mnq1Z/UZEhLjRolYUaadbVIvX578x6loK4= Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a65.g.dreamhost.com (Postfix) with ESMTPSA id ECB2F7E4072 for ; Fri, 21 Jun 2013 14:06:45 -0700 (PDT) Received: by mail-wi0-f174.google.com with SMTP id k10so1025918wiv.1 for ; Fri, 21 Jun 2013 14:06:44 -0700 (PDT) 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; bh=UwDF+xusf5ZJt07doYdai9mN9I+4VLyfT5uLU4f2F4s=; b=iQdTgY14ua2KP4Xrhjpy9HsmYQh5XDTF20V8k1krHvtcqQ3ZZZFoQsV3zM8Nx92D38 h9m3GfR6kcGeoG/AqAWTq3Pz8aHLqnamFrCDHyLxdFYMYF4GlynyHfWR4UnKPkKls+G3 bRnKV480JIkrjEqIFov8tgalmI2zrNIjhGaXM1JeS+wSrU8qvrEIqO3CEAtu3IulRNiS beOSUbigylVTe9kp1+ad3ihMEny7SYJzm8nRy8gRpPYbx4wpYhNrxHtIvecGRvT8annW zQnO1BXpqpU1sjEr8K7MucaaZgnrkT3yiprmyBcFBPGxLpYHGgvWRQTEAJuL4id2/bBM /8hw== MIME-Version: 1.0 X-Received: by 10.181.12.1 with SMTP id em1mr68619wid.4.1371848804351; Fri, 21 Jun 2013 14:06:44 -0700 (PDT) Received: by 10.216.29.5 with HTTP; Fri, 21 Jun 2013 14:06:44 -0700 (PDT) In-Reply-To: <20130621205837.3F1741A841@ld9781.wdf.sap.corp> References: <5B1D7E570380A64989D4C069F7D14BC8880726B9@clavin.missi.ncsc.mil> <20130621205837.3F1741A841@ld9781.wdf.sap.corp> Date: Fri, 21 Jun 2013 16:06:44 -0500 Message-ID: From: Nico Williams To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] TLS grammar checker? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 21:06:51 -0000 On Fri, Jun 21, 2013 at 3:58 PM, Martin Rex wrote: > Kemp, David P. wrote: >> Of all the possible criticisms of ASN.1, this doesn't seem to be >> among them. X.680 is unambiguous - the year MUST be 4 digits: Indeed. And x.690 repeats this. Nico -- From DPKemp@missi.ncsc.mil Fri Jun 21 14:28: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 AD65821F9E39 for ; Fri, 21 Jun 2013 14:28:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.224 X-Spam-Level: X-Spam-Status: No, score=-6.224 tagged_above=-999 required=5 tests=[AWL=-0.225, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aZP7jW3tIEvr for ; Fri, 21 Jun 2013 14:28:30 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 652C021F9D9B for ; Fri, 21 Jun 2013 14:28:30 -0700 (PDT) Received: from clavin.missi.ncsc.mil (odysseus.missi.ncsc.mil [144.51.60.172]) by stingray.missi.ncsc.mil with ESMTP id r5LLST7p070784 for ; Fri, 21 Jun 2013 17:28:29 -0400 (EDT) Received: from CLAVIN.missi.ncsc.mil ([169.254.1.133]) by odysseus.missi.ncsc.mil ([144.51.60.172]) with mapi id 14.03.0123.003; Fri, 21 Jun 2013 17:28:29 -0400 From: "Kemp, David P." To: "TLS@ietf.org (tls@ietf.org)" Thread-Topic: [TLS] TLS grammar checker? Thread-Index: AQHObrSjPO4G/PGCq0GmSUxJ1/05VplAoO+AgABI6ID//799EA== Date: Fri, 21 Jun 2013 21:28:28 +0000 Message-ID: <5B1D7E570380A64989D4C069F7D14BC8880726E1@clavin.missi.ncsc.mil> References: <5B1D7E570380A64989D4C069F7D14BC8880726B9@clavin.missi.ncsc.mil> <20130621205837.3F1741A841@ld9781.wdf.sap.corp> In-Reply-To: <20130621205837.3F1741A841@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.51.56.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] TLS grammar checker? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 21:28:35 -0000 My bad for not noticing that a 1999 standard (RFC 2560) referenced the 1994= specification of X.690. However, the fact that the 1994 specification of = ASN.1 is flawed is not a valid criticism of ASN.1 itself. I'm sure HTML 4.= 01 (Dec 1999) fixed some errors and omissions in previous versions, and any= deficiencies of RFC 1866 (HTML 2.0, Nov 1995) would not generally be consi= dered valid flaws of HTML itself. As for making a distinction between senders and receivers, "be liberal in w= hat you accept" is no different for ASN.1 than for ABNF or bits-in-boxes - = if your application wants to accept input that is syntactically invalid, it= is free to do so. The standard for syntax is the same for senders and rec= eivers. -----Original Message----- From: Martin Rex [mailto:mrex@sap.com]=20 Sent: Friday, June 21, 2013 4:59 PM To: Kemp, David P. Cc: TLS@ietf.org (tls@ietf.org) Subject: Re: [TLS] TLS grammar checker? Kemp, David P. wrote: > Of all the possible criticisms of ASN.1, this doesn't seem to be among=20 > them. X.680 is unambiguous - the year MUST be 4 digits: Your answer is way off the target. I didn't ask about what to send out, but what to accept(!) and why. rfc2560 OSCP is based on X.690-1994: http://tools.ietf.org/html/rfc2560#section-6 [X.690] ITU-T Recommendation X.690 (1994) | ISO/IEC 8825-1:1995, Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER). If you search X.680 from 1994 for GeneralizedTime, it only says that it is = a reserved keyword (therefore useless for the question at hand). In order to figure out what to **ACCEPT**, you have to refer to the origina= l specifcation exclusively. Your quote seems to be from X.680 2008. -Martin >=20 > 46.3 The type is defined, using ASN.1, as follows: > GeneralizedTime ::=3D [UNIVERSAL 24] IMPLICIT VisibleString > with the values of the VisibleString restricted to strings > of characters which are either: > a) a specification of a calendar date followed by a local > time, consisting of: > 1) a string representing the calendar date, as specified > in ISO 8601, 4.1.2.2 - Basic format); followed by: >=20 > NOTE 1 - This specifies a four-digit representation > of the year, a two-digit representation of the month > and a two-digit representation of the day, without > use of separators. >=20 >=20 >=20 > -----Original Message----- >=20 > To illustrate one of my many problems with ASN.1 complexity and lack=20 > of clarity, I was recently wondering on OCSP, whether it is=20 > permissible or not _on_receipt_ when the "RevodedInfo->revocationTime"=20 > element >=20 > http://tools.ietf.org/html/rfc2560#page-9 >=20 > or the CRL Extension "CRL References" "CrlID->crlTime" element >=20 > http://tools.ietf.org/html/rfc2560#section-4.4.2 >=20 > contains a date&time with only 2-year, where exactly in ASN.1 it is=20 > described how the receiver ought to be implemented, and whether=20 > support for 2-digit years in GeneralizedTime is a "MAY", "SHOULD NOT" > or "MUST NOT". From mrex@sap.com Fri Jun 21 14:34:04 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 70D9F21F9E0A for ; Fri, 21 Jun 2013 14:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.032 X-Spam-Level: X-Spam-Status: No, score=-9.032 tagged_above=-999 required=5 tests=[AWL=-0.817, BAYES_00=-2.599, FM_ASCII_ART_SPACINGc=0.833, HELO_EQ_DE=0.35, J_CHICKENPOX_19=0.6, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H0Qe+zZOG-nH for ; Fri, 21 Jun 2013 14:34:00 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5F121F9E03 for ; Fri, 21 Jun 2013 14:33:59 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r5LLXwOF003695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 21 Jun 2013 23:33:58 +0200 (MEST) In-Reply-To: <20130621205837.3F1741A841@ld9781.wdf.sap.corp> To: mrex@sap.com Date: Fri, 21 Jun 2013 23:33:57 +0200 (CEST) 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: <20130621213358.0235D1A842@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] TLS grammar checker? 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, 21 Jun 2013 21:34:04 -0000 the most appropriate guidance is probably in X.208-1988 Section 32, but the source of the original confusion is from where the information originally comes from, that OCSP conveys in these fields. When the mentioned OCSP elements originate from X.509 and PKIX CRLs, then from an element that is defined as (e.g. rfc5280 page 17): Time ::= CHOICE { utcTime UTCTime, generalTime GeneralizedTime } and the CRL definition (rfc5280, page 56): CertificateList ::= SEQUENCE { tbsCertList TBSCertList, signatureAlgorithm AlgorithmIdentifier, signatureValue BIT STRING } TBSCertList ::= SEQUENCE { version Version OPTIONAL, -- if present, MUST be v2 signature AlgorithmIdentifier, issuer Name, thisUpdate Time, nextUpdate Time OPTIONAL, revokedCertificates SEQUENCE OF SEQUENCE { userCertificate CertificateSerialNumber, revocationDate Time, crlEntryExtensions Extensions OPTIONAL -- if present, version MUST be v2 } OPTIONAL, crlExtensions [0] EXPLICIT Extensions OPTIONAL -- if present, version MUST be v2 } But the real problem really isn't about whether you can find something intelligible hidden somewhere in some X.something document, but how clear will this be to an average implementor. And on this particular account, ASN.1 is a real nightmare. -Martin Martin Rex wrote: > Kemp, David P. wrote: > > Of all the possible criticisms of ASN.1, this doesn't seem to be > > among them. X.680 is unambiguous - the year MUST be 4 digits: > > Your answer is way off the target. > > I didn't ask about what to send out, but what to accept(!) and why. > > rfc2560 OSCP is based on X.690-1994: > http://tools.ietf.org/html/rfc2560#section-6 > > [X.690] ITU-T Recommendation X.690 (1994) | ISO/IEC 8825-1:1995, > Information Technology - ASN.1 encoding rules: > Specification of Basic Encoding Rules (BER), Canonical > Encoding Rules (CER) and Distinguished Encoding Rules > (DER). > > If you search X.680 from 1994 for GeneralizedTime, it only says that it > is a reserved keyword (therefore useless for the question at hand). > > In order to figure out what to **ACCEPT**, you have to refer to the > original specifcation exclusively. > > > Your quote seems to be from X.680 2008. > > -Martin > > > > > 46.3 The type is defined, using ASN.1, as follows: > > GeneralizedTime ::= [UNIVERSAL 24] IMPLICIT VisibleString > > with the values of the VisibleString restricted to strings > > of characters which are either: > > a) a specification of a calendar date followed by a local > > time, consisting of: > > 1) a string representing the calendar date, as specified > > in ISO 8601, 4.1.2.2 - Basic format); followed by: > > > > NOTE 1 - This specifies a four-digit representation > > of the year, a two-digit representation of the month > > and a two-digit representation of the day, without > > use of separators. > > > > > > > > -----Original Message----- > > > > To illustrate one of my many problems with ASN.1 complexity and lack > > of clarity, I was recently wondering on OCSP, whether it is permissible > > or not _on_receipt_ when the "RevodedInfo->revocationTime" element > > > > http://tools.ietf.org/html/rfc2560#page-9 > > > > or the CRL Extension "CRL References" "CrlID->crlTime" element > > > > http://tools.ietf.org/html/rfc2560#section-4.4.2 > > > > contains a date&time with only 2-year, where exactly in ASN.1 it is > > described how the receiver ought to be implemented, and whether > > support for 2-digit years in GeneralizedTime is a "MAY", "SHOULD NOT" > > or "MUST NOT". > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From carl@redhoundsoftware.com Fri Jun 21 14:38:22 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 BBA7521F9E27 for ; Fri, 21 Jun 2013 14:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.566 X-Spam-Level: X-Spam-Status: No, score=-0.566 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_ASCII_ART_SPACINGc=0.833, J_CHICKENPOX_19=0.6, J_CHICKENPOX_44=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZR0AobDjia3 for ; Fri, 21 Jun 2013 14:38:15 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 80DAA21F9E11 for ; Fri, 21 Jun 2013 14:38:15 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id c10so5059969qcz.14 for ; Fri, 21 Jun 2013 14:38:15 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=references:mime-version:in-reply-to:content-type :content-transfer-encoding:message-id:cc:x-mailer:from:subject:date :to:x-gm-message-state; bh=Il8PSvKLAoSqthF89DQsacshqMTyGVEtUFHzMKClU2g=; b=cOL8N3cBObSrTnjkZCLQZOOHhM/LLdINeUhLTo7u76laDESfJi2RnnTV5Mwlx01pvL R8C1tknsevMcbrkk668b593kXB4tOUp1H2phpGGOapEivT+IPb0w9DOOfjuC+VI2X8Pg qlz5F7E1zlVDirr1HYqKiA5oFLRz2d8t3AJjsiN1QqcvIQgAc2rqt133YgmJ0WfasqpY xr/HvWVs5y15Dgm2bSIwA06qs6AN3b6q+l+9GETWiGPvd/ZEqzlGlD5oLJSRGsFT5uEq ts7rP0NERndEIBvO/G7Zqaa2wVuC3yINAkyuow6tMR/33Aw84pz9Lq0Fpmsvo+FkYuIR phag== X-Received: by 10.49.35.65 with SMTP id f1mr7614262qej.72.1371850694887; Fri, 21 Jun 2013 14:38:14 -0700 (PDT) Received: from [10.226.70.81] (209.sub-174-236-199.myvzw.com. [174.236.199.209]) by mx.google.com with ESMTPSA id 15sm8826428qaa.9.2013.06.21.14.38.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 21 Jun 2013 14:38:14 -0700 (PDT) References: <20130621213358.0235D1A842@ld9781.wdf.sap.corp> Mime-Version: 1.0 (1.0) In-Reply-To: <20130621213358.0235D1A842@ld9781.wdf.sap.corp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <09A2DAED-00A3-4A6C-83F4-1AB80619F691@redhoundsoftware.com> X-Mailer: iPhone Mail (10B146) From: Carl Wallace Date: Fri, 21 Jun 2013 17:38:03 -0400 To: "mrex@sap.com" X-Gm-Message-State: ALoCoQlnl4N2idYaCip6AMZiB5td2bvdePuYIWK5qCtj3hys/XNoAVI5otxN0582FZL7hkjLnPEA Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] TLS grammar checker? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 21:38:24 -0000 See RFC5911 and RFC5912. Those provide a nice collection. On Jun 21, 2013, at 5:33 PM, mrex@sap.com (Martin Rex) wrote: > the most appropriate guidance is probably in X.208-1988 Section 32, > but the source of the original confusion is from where the information > originally comes from, that OCSP conveys in these fields. > > When the mentioned OCSP elements originate from X.509 and PKIX CRLs, > then from an element that is defined as (e.g. rfc5280 page 17): > > Time ::= CHOICE { > utcTime UTCTime, > generalTime GeneralizedTime } > > and the CRL definition (rfc5280, page 56): > > CertificateList ::= SEQUENCE { > tbsCertList TBSCertList, > signatureAlgorithm AlgorithmIdentifier, > signatureValue BIT STRING } > > TBSCertList ::= SEQUENCE { > version Version OPTIONAL, > -- if present, MUST be v2 > signature AlgorithmIdentifier, > issuer Name, > thisUpdate Time, > nextUpdate Time OPTIONAL, > revokedCertificates SEQUENCE OF SEQUENCE { > userCertificate CertificateSerialNumber, > revocationDate Time, > crlEntryExtensions Extensions OPTIONAL > -- if present, version MUST be v2 > } OPTIONAL, > crlExtensions [0] EXPLICIT Extensions OPTIONAL > -- if present, version MUST be v2 > } > > But the real problem really isn't about whether you can find something > intelligible hidden somewhere in some X.something document, but how > clear will this be to an average implementor. And on this particular > account, ASN.1 is a real nightmare. > > > -Martin > > > Martin Rex wrote: >> Kemp, David P. wrote: >>> Of all the possible criticisms of ASN.1, this doesn't seem to be >>> among them. X.680 is unambiguous - the year MUST be 4 digits: >> >> Your answer is way off the target. >> >> I didn't ask about what to send out, but what to accept(!) and why. >> >> rfc2560 OSCP is based on X.690-1994: >> http://tools.ietf.org/html/rfc2560#section-6 >> >> [X.690] ITU-T Recommendation X.690 (1994) | ISO/IEC 8825-1:1995, >> Information Technology - ASN.1 encoding rules: >> Specification of Basic Encoding Rules (BER), Canonical >> Encoding Rules (CER) and Distinguished Encoding Rules >> (DER). >> >> If you search X.680 from 1994 for GeneralizedTime, it only says that it >> is a reserved keyword (therefore useless for the question at hand). >> >> In order to figure out what to **ACCEPT**, you have to refer to the >> original specifcation exclusively. >> >> >> Your quote seems to be from X.680 2008. >> >> -Martin >> >>> >>> 46.3 The type is defined, using ASN.1, as follows: >>> GeneralizedTime ::= [UNIVERSAL 24] IMPLICIT VisibleString >>> with the values of the VisibleString restricted to strings >>> of characters which are either: >>> a) a specification of a calendar date followed by a local >>> time, consisting of: >>> 1) a string representing the calendar date, as specified >>> in ISO 8601, 4.1.2.2 - Basic format); followed by: >>> >>> NOTE 1 - This specifies a four-digit representation >>> of the year, a two-digit representation of the month >>> and a two-digit representation of the day, without >>> use of separators. >>> >>> >>> >>> -----Original Message----- >>> >>> To illustrate one of my many problems with ASN.1 complexity and lack >>> of clarity, I was recently wondering on OCSP, whether it is permissible >>> or not _on_receipt_ when the "RevodedInfo->revocationTime" element >>> >>> http://tools.ietf.org/html/rfc2560#page-9 >>> >>> or the CRL Extension "CRL References" "CrlID->crlTime" element >>> >>> http://tools.ietf.org/html/rfc2560#section-4.4.2 >>> >>> contains a date&time with only 2-year, where exactly in ASN.1 it is >>> described how the receiver ought to be implemented, and whether >>> support for 2-digit years in GeneralizedTime is a "MAY", "SHOULD NOT" >>> or "MUST NOT". >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From mrex@sap.com Fri Jun 21 16:33:37 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 EF82621F9E5C for ; Fri, 21 Jun 2013 16:33:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.469 X-Spam-Level: X-Spam-Status: No, score=-9.469 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8, SARE_OBFU_ALL=0.751] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NNifupzYs8wg for ; Fri, 21 Jun 2013 16:33:34 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 03FB721F9D1E for ; Fri, 21 Jun 2013 16:33:32 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r5LNXQDJ019794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 22 Jun 2013 01:33:26 +0200 (MEST) In-Reply-To: To: Nico Williams Date: Sat, 22 Jun 2013 01:33:25 +0200 (CEST) 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: <20130621233326.03E831A842@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] TLS grammar checker? 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, 21 Jun 2013 23:33:38 -0000 Nico Williams wrote: > On Tue, Jun 18, 2013 at 7:05 PM, Bill Frantz wrote: > > uri@ll.mit.edu (Blumenthal, Uri - 0558 - MITLL) wrote: > >> > >> Having written my share of ASN.1 stuff (including parser/encoder with no > >> known vulnerabilities :), I agree with Nico's assessment of ASN.1. > > > > No known vulnerabilities is a good start. Unfortunately a lot of software is > > released with no know vulnerabilities but doesn't hold up under attack. It > > is nice to hear of software that has survived attack with no known > > vulnerabilities. > > Automatic tooling is a better start. I.e., ASN.1, XDR, IDL, ... compilers. > > Ad-hoc syntaxes don't lend themselves to automatic tooling, so they > tend to result in lots of error-prone hand-coding. Syntax that is so complicated that it needs tooling is a problem by itself. ASN.1 is squarely part of the problem space, not part of the solution space. If you believe you can parse or encode X.509/PKIX just by using an ASN.1 compiler tooling, then you probably have never even looked at X.509/PKIX. The devil is in the comments sprinkeled all over the place where you have to tweak the compiler output in so many ways and so many places that writing everything by yourself becomes quite a viable alternative, and one that is free of hidden eastereggs. While there exist a canonical ASN.1 DER encoding, decoding and re-encoding Certificates and CRLs may often result in digital signature verification failures. Dealing e.g. with the Version field of CRLs in particularly entertaining: TBSCertList ::= SEQUENCE { version Version OPTIONAL, -- if present, MUST be v2 Look at what rfc5280 says about the CRL version field: http://tools.ietf.org/html/rfc5280#section-5.1.2.1 5.1.2.1. Version This optional field describes the version of the encoded CRL. When extensions are used, as required by this profile, this field MUST be present and MUST specify version 2 (the integer value is 1). and then check the real world what today's CRLs look like: o The CRL from the CRL-DP of the Google Internet Authority (the CA that signs Google's Server certs, including https://www.google.com) http://crl.geotrust.com/crls/secureca.crl no Version field (and no CRL extensions) o The CRL from the CRL-DP of the VeriSign Class3 EV SSL SGC CA (the CA that signed https://www.verisign.com/) http://EVSecure-crl.verisign.com/pca3-g5.crl no Version field (and no CRL extensions) o The CRL from the CRL-DP of the Godaddy Secure CA (the CA that signed https://www.godaddy.com/) http://certificates.godaddy.com/repository/gdroot.crl no Version field (and no CRL extensions) Now the question for the implementor what to accept: 1) reject (=soft fail and ignore) all three CRLs above ? 2) reject all CRLs that have an explicit Version v1 (0) ? 3) reject all CRLs that have no Version field, but non-critical CRL extensions (this is explicitly allowed by X.509!!) ASN.1 is more than enough rope to hang yourself, and a number of existing specs that use ASN.1, hang themselves in more than one place. -Martin From pgut001@cs.auckland.ac.nz Fri Jun 21 17:06: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 9DAB421F9EEE for ; Fri, 21 Jun 2013 17:06:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+edUgs5NZGc for ; Fri, 21 Jun 2013 17:06:03 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 90E8F21F9ED2 for ; Fri, 21 Jun 2013 17:06:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1371859563; x=1403395563; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=100k2g/89/bGT37Bo39FHnkAyuo3sXF/WL03tqE70iI=; b=iILYtjQx+opHJSGe6PMFLWhzikUXAeTyYACy4IIx7qhSFmQPQjrV2ULe NW6ZXPuTy+ULew5Te4n14OMXlNnJ/L9AfhAcdUDTjR2K3r97hKsMAxVc4 VlmBLSf916zp5lGJlBjmExEHJoV3jgiR4iZSWA6m7pVn3gn8VCyLfWwdf Y=; X-IronPort-AV: E=Sophos;i="4.87,916,1363086000"; d="scan'208";a="195234269" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.112 - Outgoing - Outgoing Received: from uxchange10-fe1.uoa.auckland.ac.nz ([130.216.4.112]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 22 Jun 2013 12:06:00 +1200 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.214]) by uxchange10-fe1.UoA.auckland.ac.nz ([130.216.4.112]) with mapi id 14.02.0318.004; Sat, 22 Jun 2013 12:05:59 +1200 From: Peter Gutmann To: "TLS@ietf.org (tls@ietf.org)" , Nikos Mavrogiannopoulos Thread-Topic: [TLS] TLS grammar checker? Thread-Index: Ac5u3EYffithVwB1TGK8atcb4Rt3LA== Date: Sat, 22 Jun 2013 00:05:58 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7343D6D8DB@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] TLS grammar checker? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 00:06:10 -0000 Nikos Mavrogiannopoulos writes:=0A= =0A= >There was a reason ASN.1 was avoided in the TLS protocol, and that is=0A= >simplicity(*).=0A= =0A= Since SSL was created close to twenty years ago and I doubt any of the=0A= original authors are available for comment, that's purely speculation. My= =0A= guess would be that they didn't even consider ASN.1, XDR, and whatever else= =0A= was around at the time, or possibly even know they existed, but just invent= ed=0A= their own encoding mechanism from scratch.=0A= =0A= Peter.=0A= From nico@cryptonector.com Fri Jun 21 17:17:28 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 6D40521E809E for ; Fri, 21 Jun 2013 17:17:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.96 X-Spam-Level: X-Spam-Status: No, score=-1.96 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0b1RP9YI3fjK for ; Fri, 21 Jun 2013 17:17:23 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 2BFDE11E80C5 for ; Fri, 21 Jun 2013 17:17:23 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id DDC171DE058 for ; Fri, 21 Jun 2013 17:17:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=CVLkgfnRGtvpmhHa/o5r T33iLjs=; b=YL+37wOkWylQ2WQb5uQZ8aXN4DlCqztDChzGh5F1pU6bBiOZ/PXb TRJYmw/arfFlxXU+5ShRmIgbW5XSu0mrUkZsupDNCCxNXx8oPbLrwh1cs99/WhrQ 2x1cbCtjRsoZCZAa2C62R+skzrg4YFsfdZy4XjdDboh6ziYbfNRsKjs= Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id 8F2F21DE005 for ; Fri, 21 Jun 2013 17:17:22 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id n57so6960386wev.0 for ; Fri, 21 Jun 2013 17:17:21 -0700 (PDT) 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; bh=vvjZSsAeE+Jha9a0UyH+0Jq8mnLueOX/ZMzrJ1Cu3zU=; b=QCcC6DQeuqGMGJmvdAh045FC6RTqLj5H2WJXr1ecjAI56yRxE/fPe8m/oAGRJqGIo7 By5CiITMlU1JC/Sukx+Wrj+uW+yc8i8aYuxyaVSVcqcDYNij6pmTIGN5C0SPVMwuLyXT sQTaYUX4sRhZkrzxoyc6x9FeHowkMwIz0uhDUcWe4q/Tv8MEsuAAI93RTQCBqEbBwq2p Sljs4VEh0+ucznCjFMmN+RvrFeWdn4F5R+R4yB5RyEs/Zoplz9tE70Mwk12RFf/mMW3J hNOkHKjMgbLCTdZS7l1MK/8mU0OS+PdMzKBj4/N4y4oTzp/t7kWLZBp5lyBgG+V2D6sT H+3Q== MIME-Version: 1.0 X-Received: by 10.180.107.163 with SMTP id hd3mr388750wib.13.1371860241073; Fri, 21 Jun 2013 17:17:21 -0700 (PDT) Received: by 10.216.29.5 with HTTP; Fri, 21 Jun 2013 17:17:20 -0700 (PDT) In-Reply-To: <20130621233326.03E831A842@ld9781.wdf.sap.corp> References: <20130621233326.03E831A842@ld9781.wdf.sap.corp> Date: Fri, 21 Jun 2013 19:17:20 -0500 Message-ID: From: Nico Williams To: mrex@sap.com Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS grammar checker? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 00:17:28 -0000 On Fri, Jun 21, 2013 at 6:33 PM, Martin Rex wrote: > Nico Williams wrote: >> Automatic tooling is a better start. I.e., ASN.1, XDR, IDL, ... compilers. >> >> Ad-hoc syntaxes don't lend themselves to automatic tooling, so they >> tend to result in lots of error-prone hand-coding. > > Syntax that is so complicated that it needs tooling is a problem by itself. *All* useful syntax (in this space) is useful because you can you can build tooling around it. By definition, then, it requires tooling. ASN.1 is not easy to parse, but it's not terribly hard either. There's at least three, maybe four open source compilers. And there would have been many more had ASN.1 been *free* back in the 80s. That's ASN.1's biggest sin: it wasn't free. If you say it's mostly unknown, well, that's partly why. ASN.1's next biggest sin: its crappy initial encoding rules (BER, DER, and CER). If I could go back in time and do anything about this it'd be: tell people in the 80s about JSON (with chunked, unescaped string encoding). > ASN.1 is squarely part of the problem space, not part of the solution space. Anything with tooling is in the solution space. Today I prefer JSON (see above). > If you believe you can parse or encode X.509/PKIX just by using an > ASN.1 compiler tooling, then you probably have never even looked > at X.509/PKIX. The devil is in the comments sprinkeled all over the > place where you have to tweak the compiler output in so many ways and > so many places that writing everything by yourself becomes quite a > viable alternative, and one that is free of hidden eastereggs. These are the results of ASN.1 having been non-free. The same applies to Kerberos. > While there exist a canonical ASN.1 DER encoding, decoding and re-encoding > Certificates and CRLs may often result in digital signature verification > failures. The universal consensus seems to be: don't do that [regardless of encoding]. This has come up again and again, in the context of ASN.1, XML, and JSON, and the answer is always: don't bloody do that. Nico -- From pgut001@cs.auckland.ac.nz Fri Jun 21 17:37:07 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 3EC2921E8051 for ; Fri, 21 Jun 2013 17:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_36=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YkbdTvP3NXfa for ; Fri, 21 Jun 2013 17:37:01 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id A14E721E804B for ; Fri, 21 Jun 2013 17:37:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1371861422; x=1403397422; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=SkDFzfRe4PaHbzrmZgz6nixX0EzOedwh+dEjK3AlrMQ=; b=WlxtGOrKy3v8wEeTYWei5I2keP2LapLh0ovB9CEftwVxT6oWqG2izeJA k89J9dMW1IgQtJoJYWqn7jMYissdKKbVbs7K45P7Dg0trYi0EJrbPXjZd XW0qpIbSxQKxXzC99mZXYY+XiPARkG7ps7DVa6ioPWM2nKtVQ1Ioq66+r M=; X-IronPort-AV: E=Sophos;i="4.87,916,1363086000"; d="scan'208";a="195235967" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 22 Jun 2013 12:36:56 +1200 Received: from UXCHANGE10-FE4.UoA.auckland.ac.nz (130.216.4.171) by uxchange10-fe2.UoA.auckland.ac.nz (130.216.4.106) with Microsoft SMTP Server (TLS) id 14.2.318.4; Sat, 22 Jun 2013 12:36:55 +1200 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.214]) by uxchange10-fe4.UoA.auckland.ac.nz ([130.216.4.171]) with mapi id 14.02.0318.004; Sat, 22 Jun 2013 12:36:55 +1200 From: Peter Gutmann To: "TLS@ietf.org (tls@ietf.org)" , Martin Rex Thread-Topic: [TLS] TLS grammar checker? Thread-Index: Ac5u4JhXZLhPy+SESkuJDe9LakAC2Q== Date: Sat, 22 Jun 2013 00:36:54 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7343D6D8F3@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] TLS grammar checker? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 00:37:07 -0000 Martin Rex writes:=0A= =0A= >To illustrate one of my many problems with ASN.1 complexity and lack of=0A= >clarity, I was recently wondering on OCSP [...]=0A= =0A= OCSP is a terrible spec, alongside TSP and CMP they're some of the worst=0A= examples of ASN.1 that I know of.=0A= =0A= OK, not quite, there are telecomms management specs that are even closer to= =0A= gibberish in terms of their ASN.1, the problem with the three above is that= =0A= not only is the ASN.1 a mess - some of the authors didn't actually understa= nd=0A= ASN.1 when they started work on it and just made it up as they went along -= =0A= but the text is awfully confused as well, as are some of the design feature= s,=0A= which were cargo-cult cut&pastes from other specs without the authors=0A= understanding why they were doing it. See for example my analysis of CMP i= n=0A= "Plug-and-Play PKI: A PKI your Mother can Use",=0A= http://www.cs.auckland.ac.nz/~pgut001/pubs/usenix03.pdf, for the specific c= ase=0A= of CMP. I also have comments on the gibberish nature of parts TSP, posted = to=0A= the PKIX list while it was still in the draft stage (nothing was ever fixed= ),=0A= http://www.imc.org/ietf-pkix/old-archive-01/msg02073.html.=0A= =0A= (Apologies for the treasure-hunt URL refs, I'm trying to avoid quoting larg= e=0A= chunks of text for people who don't really care that much).=0A= =0A= OCSP is just as bad. So using these as examples of why ASN.1 sucks is a bi= t=0A= disingenuous, you'd be hard-put to find worse examples of ASN.1 (and protoc= ol=0A= specs in general) than those. If you want an example of well-designed ASN.= 1,=0A= go for something like PKCS #15.=0A= =0A= Now, can we switch to vi vs. emacs? There's a whole lot of things there th= at=0A= haven't been said yet.=0A= =0A= Peter.=0A= From mrex@sap.com Fri Jun 21 18:32:41 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 C9D701F0D3C for ; Fri, 21 Jun 2013 18:32:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.851 X-Spam-Level: X-Spam-Status: No, score=-9.851 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kHDzxwPXk1BV for ; Fri, 21 Jun 2013 18:32:36 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 708AB1F0D38 for ; Fri, 21 Jun 2013 18:32:35 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r5M1WV4T001087 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 22 Jun 2013 03:32:31 +0200 (MEST) In-Reply-To: To: Nico Williams Date: Sat, 22 Jun 2013 03:32:31 +0200 (CEST) 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: <20130622013231.7AE891A842@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: "tls@ietf.org" Subject: Re: [TLS] TLS grammar checker? 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: Sat, 22 Jun 2013 01:32:41 -0000 Nico Williams wrote: > Martin Rex wrote: > > Nico Williams wrote: > >> Automatic tooling is a better start. I.e., ASN.1, XDR, IDL, ... compilers. > >> > >> Ad-hoc syntaxes don't lend themselves to automatic tooling, so they > >> tend to result in lots of error-prone hand-coding. > > > > Syntax that is so complicated that it needs tooling is a problem by itself. > > *All* useful syntax (in this space) is useful because you can you can > build tooling around it. By definition, then, it requires tooling. The beauty of the TLS syntax is, that it can be briefly explained inside the spec and all an implementor ever needs is the protocol spec itself. It's a similar reason why DEK's choice of MIX assembly language for his TAOCP book series is a very reasonable choice of a programming language. Going back to my original question, whether implementations should accept a GeneralizedTime with a 2-digit year -- I just forged myself certs with a lame validity->notafter, and here are the results: (1) "490101120101Z" tagged as UNIVERSAL 24 (aka GeneralizedTime) OpenSSL 0.9.8l, 1.0.0d and 1.0.1c show "Jan 12 01:01:00 4901 GMT" Microsoft CryptoAPI (Win2K3 and Win7) show "Jan 12 01:01:00 4901 GMT" Google Chrome 27 on Win7 accepts it (shows MS-CryptoAPI cert wizard) Firefox 3.6.28 and 21.0 show "Jan 12 01:01:00 4901 GMT" (2) "20510101120101.1Z" tagged as UNIVERSAL 24 (aka GeneralizedTime) OpenSSL 0.9.8l show "Jan 1 12:01:01 2051 GMT" OpenSSL 1.0.0d and 1.0.1c show "Jan 1 12:01:01.1 2051 GMT" Microsoft CryptoAPI (Win2K3 and Win7) show "Jan 1 12:01:01 2051 GMT" Google Chrome 27 on Win7 accepts it (shows MS-CryptoAPI cert wizard) Firefox 3.6.28 and 21.0 reject it "sec_error_invalid_time" (3) "20510101120101Z" tagged as UNIVERSAL 23 (aka UTCTime) OpenSSL 0.9.8l, 1.0.0d and 1.0.1c reject input Microsoft CryptoAPI (Win2K3 and Win7) reject input (1) would hardly interop, so rejecting it entirely seems OK. (2) rejecting it should be OK. I would not have expected so much acceptance. While this doesn't really answer the question for OCSP, the results in (1) hints that this like would have already caused problems if OCSP responders would be straight copying rather than converting the Time values from CRLs into GeneralizedTime values of OCSP responses. -Martin From nico@cryptonector.com Fri Jun 21 19:41:33 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 4CA8121F9929 for ; Fri, 21 Jun 2013 19:41:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.373 X-Spam-Level: X-Spam-Status: No, score=-1.373 tagged_above=-999 required=5 tests=[AWL=-0.570, BAYES_00=-2.599, FB_NO_MORE_ADS=1.174, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y264fAqWHl51 for ; Fri, 21 Jun 2013 19:41:28 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id 62BC621F9425 for ; Fri, 21 Jun 2013 19:41:28 -0700 (PDT) Received: from homiemail-a84.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTP id 1FEC41DE058 for ; Fri, 21 Jun 2013 19:41:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=CKockKFNCWBhPwJFJrqG mAAUBLA=; b=GtLbGQhnDDapRxGhyeyssjjnnOXSBPuMdnu6KAkQwSGfMlfm4lmK Pvgbk2kKp3IJ8UDfVSBs9xbzuhRYO+tLYlR0+nRNztx12aWcbpKNmc9Vb7u4v8UB rdMFDr7G+z/cuuPqUalRZ8xL+p98RTglyCaE/FO4f86T2SaFuE1WZWw= Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a84.g.dreamhost.com (Postfix) with ESMTPSA id BF7B01DE005 for ; Fri, 21 Jun 2013 19:41:27 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id c11so6876527wgh.1 for ; Fri, 21 Jun 2013 19:41:26 -0700 (PDT) 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; bh=OTYvuPJ125JxRjUazs8igwXpBYS4tQoKhb2e0+5S7R8=; b=RuES4WCa6x/O61cSBRkNOJhyDEoDk23B0zjT1/GBbMsuXF5TZ4EVo/U0hTgXVZHoZ1 rhXQd15NXAFJjGjxpmc+doAX/FR09ddQUECqkNn4n+gLz/FsJ19r6ZT3HF2SBJc6elp6 LI22Z4sXN/mU4vcw4J7yDHmeP16f/K8u41kIdkgKpKP7XZOD5P4ZBjhMoIhWNbm8Qiko r178rh0grf7231G6EAveVdQ3Su2ymQnMyuFopuuDQTjbI/+fM0BfrzmCPGAtIVY35TdT rLLovEVloVy2qfb1noZ6kv2a74+Z+ZiYjCPXvzmisvUgZdqoijy3dbT+6R2udG+R0WnA EZSg== MIME-Version: 1.0 X-Received: by 10.194.8.163 with SMTP id s3mr11102486wja.41.1371868886235; Fri, 21 Jun 2013 19:41:26 -0700 (PDT) Received: by 10.216.29.5 with HTTP; Fri, 21 Jun 2013 19:41:26 -0700 (PDT) In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C7343D6D8F3@uxcn10-2.UoA.auckland.ac.nz> References: <9A043F3CF02CD34C8E74AC1594475C7343D6D8F3@uxcn10-2.UoA.auckland.ac.nz> Date: Fri, 21 Jun 2013 21:41:26 -0500 Message-ID: From: Nico Williams To: Peter Gutmann Content-Type: text/plain; charset=UTF-8 Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] TLS grammar checker? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 02:41:33 -0000 On Fri, Jun 21, 2013 at 7:36 PM, Peter Gutmann wrote: > Now, can we switch to vi vs. emacs? There's a whole lot of things there that > haven't been said yet. Neither: VIM, probably the next version, the one that replaces vim's scripting language with Python. Also: Amiga over Atari. I don't care about ASN.1 but don't throw the baby out with the bath water: just no more ad-hoc crap. Martin may love the TLS syntax, but being informal mates it easy to make mistakes and hard to build tooling. If we must have ad-hoc syntaxes I'd rather use SSH's ad-hoc syntax than TLS' (if yer gonna go simple, with be shy, go alll the way). But really, going forward we should use JSON -- a trivial JSON schema language (wherein schemas look as much as possible [without losing too much expressive power] like the data they describe). Nico -- From rsalz@akamai.com Sat Jun 22 07:03:40 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 163EA21F9F7C for ; Sat, 22 Jun 2013 07:03:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g71OxK8g003d for ; Sat, 22 Jun 2013 07:03:35 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 036EC21F9F3D for ; Sat, 22 Jun 2013 07:03:34 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id AEFD4281F4; Sat, 22 Jun 2013 14:03:33 +0000 (GMT) Received: from prod-mail-relay02.akamai.com (prod-mail-relay02.akamai.com [172.17.50.21]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id 9C94F281F2; Sat, 22 Jun 2013 14:03:33 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay02.akamai.com (Postfix) with ESMTP id 8695FFE054; Sat, 22 Jun 2013 14:03:33 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.138]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Sat, 22 Jun 2013 10:03:33 -0400 From: "Salz, Rich" To: "mrex@sap.com" , Nico Williams Date: Sat, 22 Jun 2013 10:03:32 -0400 Thread-Topic: [TLS] TLS grammar checker? Thread-Index: Ac5u6Gak+tJ+MFQGQ+KTwNcQAmTWLgAZ+IYQ Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711B20DE6E4@USMBX1.msg.corp.akamai.com> References: <20130622013231.7AE891A842@ld9781.wdf.sap.corp> In-Reply-To: <20130622013231.7AE891A842@ld9781.wdf.sap.corp> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] TLS grammar checker? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 14:03:40 -0000 > The beauty of the TLS syntax is, that it can be briefly explained inside = the spec and all an implementor ever needs is the protocol spec itself. Really? Can I have a vector of digitally-signed? > Going back to my original question, whether implementations should accept= a GeneralizedTime That's an IETF question, not an ASN.1 question. ASN1 says quite clearly th= at those years are four-digit. Did they get everything right on the first = publication? Certainly not. Heck, even the IETF has errata :) /r$ -- =20 Principal Security Engineer Akamai Technology Cambridge, MA From rsalz@akamai.com Mon Jun 24 08:30:07 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 5427B21E80EE for ; Mon, 24 Jun 2013 08:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.309, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P2ESQP2kK7Hi for ; Mon, 24 Jun 2013 08:30:02 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 1C8A111E815B for ; Mon, 24 Jun 2013 08:30:01 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B0FC91653D6; Mon, 24 Jun 2013 15:30:00 +0000 (GMT) Received: from prod-mail-relay04.akamai.com (prod-mail-relay04.akamai.com [172.27.8.27]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id A34E71653CF; Mon, 24 Jun 2013 15:30:00 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay04.akamai.com (Postfix) with ESMTP id 7C3CD47BD2; Mon, 24 Jun 2013 15:30:00 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.138]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Mon, 24 Jun 2013 11:30:00 -0400 From: "Salz, Rich" To: "OMAR HASSAN (RIT Student)" , "tls@ietf.org" Date: Mon, 24 Jun 2013 11:29:59 -0400 Thread-Topic: [TLS] User Defined Key Pair Thread-Index: Ac5uriPBLh68+NhMT/qx+tJzf7sLSgCQVULw Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711B251EE97@USMBX1.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C711B251EE97USMBX1msgcorp_" MIME-Version: 1.0 Subject: Re: [TLS] User Defined Key Pair 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, 24 Jun 2013 15:30:07 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C711B251EE97USMBX1msgcorp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I didn't see any description of your genKeyPair function; is it described a= nywhere? In particular, it seems to me that it's stateless - that is, it g= enerates the keypair whenever needed, based only on the username, password,= and a security question&answer. Is that true? /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA --_000_2A0EFB9C05D0164E98F19BB0AF3708C711B251EE97USMBX1msgcorp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I didn= 217;t see any description of your genKeyPair function; is it described anyw= here?  In particular, it seems to me that it’s stateless –= that is, it generates the keypair whenever needed, based only on the usern= ame, password, and a security question&answer.  Is that true?=

     =            /r$=

 

-- 

Principal Security Engineer

<= span style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F= 497D'>Akamai Technology

Ca= mbridge, MA

 

= --_000_2A0EFB9C05D0164E98F19BB0AF3708C711B251EE97USMBX1msgcorp_-- From omh1835@g.rit.edu Mon Jun 24 09:26:04 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 D807321E8127 for ; Mon, 24 Jun 2013 09:26:04 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UikluPSu10Mb for ; Mon, 24 Jun 2013 09:25:59 -0700 (PDT) Received: from sc3app27.rit.edu (sc3app27.rit.edu [129.21.35.56]) by ietfa.amsl.com (Postfix) with ESMTP id CC66021E8123 for ; Mon, 24 Jun 2013 09:25:58 -0700 (PDT) Received: from mail-ie0-f179.google.com (mail-ie0-f179.google.com [209.85.223.179]) by smtp-server.rit.edu (PMDF V6.3-x14 #31420) with ESMTPS id <0MOW00AOZOB8BN@smtp-server.rit.edu> for tls@ietf.org; Mon, 24 Jun 2013 12:25:57 -0400 (EDT) Received: by mail-ie0-f179.google.com with SMTP id c10so25529077ieb.10 for ; Mon, 24 Jun 2013 09:25:56 -0700 (PDT) Received: by 10.43.115.3 with HTTP; Mon, 24 Jun 2013 09:25:56 -0700 (PDT) X-Received: by 10.43.139.5 with SMTP id iu5mr8617995icc.107.1372091156819; Mon, 24 Jun 2013 09:25:56 -0700 (PDT) X-Received: by 10.43.139.5 with SMTP id iu5mr8617989icc.107.1372091156722; Mon, 24 Jun 2013 09:25:56 -0700 (PDT) Date: Mon, 24 Jun 2013 19:25:56 +0300 From: "OMAR HASSAN (RIT Student)" In-reply-to: <2A0EFB9C05D0164E98F19BB0AF3708C711B251EE97@USMBX1.msg.corp.akamai.com> Sender: omh1835@rit.edu To: "Salz, Rich" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary=001a11c2e9b8fefe6004dfe8dd21 X-RIT-Received-From: 209.85.223.179 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=uj/dtIZ5Ake7ArQ7W+G8uOkO8Mcx3R8n9ut/p0cyiVE=; b=Pni530q6FAjErzRI25NZF8ZtxU5/aYb4poiZr32Y9+n/Ixb8YmtcQfRvRBN5A0lnDf by0UVoMeUcQLb1Nv2hGqMe7MXnZw5MzdrkJ1p/AsRKdcUFYxm2uAXp4gYW5wYTJN/A3Z CdG4Q688ekFcc8iaO4bK4hvVa98eYxaf+36wM6hmZFT6lSucX/jPEVz+RFWCY4aWBCdc DsLbwlI1ad2F6D81yLOvkXZ6CQt4Wz5qUe6iqUrnXcclS0/1Gb0BLlKSxGbtZxwlxxG2 HTLC4/pFmwuTqEn5fw103g3MNWNFB0rO2gni53nBYuj8zwlCitxy6Dcga2RQMW0lAOOk APyQ== X-Google-Sender-Auth: E5Ms8AED0mmB6iw7ybyI_FdS8hc X-Gm-Message-State: ALoCoQkKLIefBVbD1E43FjSbV0FeUcdQmu9rSlYct3sV3wte2D/3dOXIsWMMrT5inLIMn8LGmLWvbSrypCHD+5Pnl0giSrD3et6Fk+lYPFWG9c5/nD6UVoXH58s2ByTOQNCWmbNws/ga References: <2A0EFB9C05D0164E98F19BB0AF3708C711B251EE97@USMBX1.msg.corp.akamai.com> Cc: "tls@ietf.org" Subject: Re: [TLS] User Defined Key Pair 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, 24 Jun 2013 16:26:05 -0000 --001a11c2e9b8fefe6004dfe8dd21 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Rich, The idea is to separate the generation of the key pair of the server, so the server will be expecting your public key during the enrollment, and a message singed by your private key during the sign in. On the browser level there should be a plugin that has a function to generate the key pair, that function must generate the same key pair for the same input parameters. I didn't include any mathematics details for that function as I was interesting in abstracting the idea, and for the real implementation there must be unified implementation across all browsers to generate the same key pair for the same input parameters in all browsers. There should be three version of the generate key function as the following= : 1) genKeyPair (username, password, security question&answer); So whenever you provide the same username, password, and the security question&answer, the same key pair will be generated for you. 2) genKeyPair (username, password, file); So whenever you provide the same username, password, and the same file from a usb or hard drive, the same key pair will be generated for you. 3) genKeyPair (username, password, smart card or hardware token); So whenever you plugin the hardware token or put your smart card, and provide the same username and password, the same key pair will be generated for you. In my prof of concept implementation, I used a standard java method that will generate the same key pair for the same input string, and I provided a concatenation of the username, password, and security question&answer. On Mon, Jun 24, 2013 at 6:29 PM, Salz, Rich wrote: > I didn=92t see any description of your genKeyPair function; is it describ= ed > anywhere? In particular, it seems to me that it=92s stateless =96 that i= s, it > generates the keypair whenever needed, based only on the username, > password, and a security question&answer. Is that true?**** > > /r$**** > > ** ** > > -- **** > > Principal Security Engineer**** > > Akamai Technology**** > > Cambridge, MA**** > > ** ** > --001a11c2e9b8fefe6004dfe8dd21 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi=A0Rich,

The idea is to separate the generation of the key pair of = the server,=A0so the server will be expec= ting your public key during the enrollment,=A0an= d a message singed by your private key during the sign in.
On the browser level there should be a plugin that has a = function to generate the key pair, that function must generate the=A0same key pair for the same input parameters.
I didn't incl= ude any=A0mathematics=A0details for that function as I was interesting in a= bstracting the idea, and for the real implementation there must be unified = implementation across all browsers to generate the same key pair for the sa= me input parameters in all browsers.
There should be three version of the generate key functio= n as the following:
1) genKeyPair (username, password,=A0security ques= tion&answer);
So whenever you provide the same username, password, and the=A0<= /font>secur= ity question&answer,=A0the same key pair will be generated for you.<= /div>

2) genKeyPair (username, password,= =A0file);So whenever you provide the same username, password, and the same fi= le from a usb or hard drive,=A0the same key pair will be generated for you.=A0
3)=A0genKeyPa= ir (username, password,=A0smart card or hardware token= );
So whenever you plugin the hardware token or put y= our smart card,=A0and provide the same username = and password,=A0the same key pair will be generated for you.=A0

In my prof of concept implementation, I used a=A0standard=A0jav= a method that will=A0generate=A0the same key pair=A0for the same input s= tring, and I provided a concatenation of the=A0username, password,=A0= a= nd=A0security question&answer.


On Mon,= Jun 24, 2013 at 6:29 PM, Salz, Rich <rsalz@akamai.com> wrote= :

I didn=92t see any description of your genKe= yPair function; is it described anywhere?=A0 In particular, it seems to me = that it=92s stateless =96 that is, it generates the keypair whenever needed= , based only on the username, password, and a security question&answer.= =A0 Is that true?<= /u>

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /r$<= /u>

=A0

--=A0

Principal Security Engine= er

Cambridge, MA

=A0


--001a11c2e9b8fefe6004dfe8dd21-- From rsalz@akamai.com Mon Jun 24 09:33:23 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 9401E11E8162 for ; Mon, 24 Jun 2013 09:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.366 X-Spam-Level: X-Spam-Status: No, score=-2.366 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UlbKtTkFjQ7 for ; Mon, 24 Jun 2013 09:33:18 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [96.6.114.97]) by ietfa.amsl.com (Postfix) with ESMTP id 91C6621F9EB1 for ; Mon, 24 Jun 2013 09:33:17 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id DC9381C47DF; Mon, 24 Jun 2013 16:33:14 +0000 (GMT) Received: from prod-mail-relay03.akamai.com (prod-mail-relay03.akamai.com [172.27.8.26]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id CE1451C47DD; Mon, 24 Jun 2013 16:33:14 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay03.akamai.com (Postfix) with ESMTP id B26AF2FD62; Mon, 24 Jun 2013 16:33:14 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.138]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Mon, 24 Jun 2013 12:33:10 -0400 From: "Salz, Rich" To: "omh1835@rit.edu" Date: Mon, 24 Jun 2013 12:33:09 -0400 Thread-Topic: [TLS] User Defined Key Pair Thread-Index: Ac5w94RI99cNQASqTGGyT7nnr47KJwAAIOZQ Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711B251EF0E@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C711B251EE97@USMBX1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C711B251EF0EUSMBX1msgcorp_" MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] User Defined Key Pair 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, 24 Jun 2013 16:33:23 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C711B251EF0EUSMBX1msgcorp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =D8 On the browser level there should be a plugin that has a function to g= enerate the key pair, that function must generate the same key pair for the= same input parameters. That's interesting. This is the first system I've heard of that predictabl= y generating a keypair is not only a feature, but a requirement. I'm sure that I am not the only person who is bothered by the security impl= ications of this. /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA --_000_2A0EFB9C05D0164E98F19BB0AF3708C711B251EF0EUSMBX1msgcorp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

=D8  On the browse= r level there should be a plugin that has a function to generate the key pa= ir, that function must generate the same key pair for the same input p= arameters.

&nb= sp;

That’s interesting.= =A0 This is the first system I’ve heard of that predictably generatin= g a keypair is not only a feature, but a requirement.

=

 

I’m sure that I am not the only person who is bothered by th= e security implications of this.

=  

=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /r$

--=A0

Princip= al Security Engineer

Akam= ai Technology

Cambridge, M= A

= --_000_2A0EFB9C05D0164E98F19BB0AF3708C711B251EF0EUSMBX1msgcorp_-- From DPKemp@missi.ncsc.mil Mon Jun 24 09:37:36 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 D26B721E80FA for ; Mon, 24 Jun 2013 09:37:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Em3+Vlvqatl for ; Mon, 24 Jun 2013 09:37:30 -0700 (PDT) Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by ietfa.amsl.com (Postfix) with ESMTP id 70F4721F9A0A for ; Mon, 24 Jun 2013 09:37:30 -0700 (PDT) Received: from clavin.missi.ncsc.mil (squid.missi.ncsc.mil [144.51.60.169]) by stingray.missi.ncsc.mil with ESMTP id r5OGbTWS089929 for ; Mon, 24 Jun 2013 12:37:29 -0400 (EDT) Received: from CLAVIN.missi.ncsc.mil ([169.254.1.133]) by SQUID.missi.ncsc.mil ([fe80::e032:d4c7:c51f:85ec%14]) with mapi id 14.03.0123.003; Mon, 24 Jun 2013 12:37:29 -0400 From: "Kemp, David P." To: "tls@ietf.org" Thread-Topic: [TLS] TLS grammar checker? Thread-Index: AQHObte5PO4G/PGCq0GmSUxJ1/05VplBIRYAgAPmIkA= Date: Mon, 24 Jun 2013 16:37:28 +0000 Message-ID: <5B1D7E570380A64989D4C069F7D14BC8880727B3@clavin.missi.ncsc.mil> References: <20130621233326.03E831A842@ld9781.wdf.sap.corp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [144.51.56.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] TLS grammar checker? 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, 24 Jun 2013 16:37:37 -0000 From: Nico Williams > ASN.1's next biggest sin: its crappy initial encoding rules (BER, DER, an= d CER). Beauty is in the eye of the beholder. The self-describing properties of TL= V encodings like BER are often useful, providing a middle ground between hi= ghly optimized binary encodings (PER) that cannot be parsed without the dat= a definition and bulky ASCII encodings (JSON) that are readable with a text= editor. >> ASN.1 is squarely part of the problem space, not part of the solution sp= ace. > Anything with tooling is in the solution space. Today I prefer JSON (see= above). +1. Anyone up for defining JER? :-) >> If you believe you can parse or encode X.509/PKIX just by using an >> ASN.1 compiler tooling, then you probably have never even looked at=20 >> X.509/PKIX. The devil is in the comments sprinkeled all over the=20 >> place where you have to tweak the compiler output in so many ways and=20 >> so many places that writing everything by yourself becomes quite a=20 >> viable alternative, and one that is free of hidden eastereggs. > > These are the results of ASN.1 having been non-free. The same > applies to Kerberos. SNMP seems to have done ASN.1 the right way - adopting a simple subset of n= eeded features and eschewing the esoteric. I take the same approach with m= y Sony digital camera - it has zillions of ridiculous picture-taking featur= es including, believe it or not, "food mode". Yet I manage to get by with = just the basic four: P, S, A, and M. ASN.1's extensive feature set deserves at least as much blame as its non-fr= eeness. But spec writers (including myself) deserve the bulk of the critic= ism for not exercising craftsmanship and self-restraint. Just because the = features exist doesn't mean they have to be used. TLS could be written in = SNMP-ASN.1 without requiring compiler tweaking. > Also: Amiga over Atari. You're in the right processor family. 6502 >> 8080. From omh1835@g.rit.edu Mon Jun 24 11:27:23 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 535F011E8173 for ; Mon, 24 Jun 2013 11:27:23 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vnd3yeUGv5aZ for ; Mon, 24 Jun 2013 11:27:17 -0700 (PDT) Received: from sc3app27.rit.edu (sc3app27.rit.edu [129.21.35.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACB311E816F for ; Mon, 24 Jun 2013 11:27:17 -0700 (PDT) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) by smtp-server.rit.edu (PMDF V6.3-x14 #31420) with ESMTPS id <0MOW00F44TXEWM@smtp-server.rit.edu> for tls@ietf.org; Mon, 24 Jun 2013 14:27:15 -0400 (EDT) Received: by mail-ie0-f178.google.com with SMTP id u16so24607665iet.23 for ; Mon, 24 Jun 2013 11:27:13 -0700 (PDT) Received: by 10.43.115.3 with HTTP; Mon, 24 Jun 2013 11:27:13 -0700 (PDT) X-Received: by 10.43.137.65 with SMTP id in1mr9018760icc.103.1372098433949; Mon, 24 Jun 2013 11:27:13 -0700 (PDT) X-Received: by 10.43.137.65 with SMTP id in1mr9018757icc.103.1372098433839; Mon, 24 Jun 2013 11:27:13 -0700 (PDT) Date: Mon, 24 Jun 2013 21:27:13 +0300 From: "OMAR HASSAN (RIT Student)" In-reply-to: <2A0EFB9C05D0164E98F19BB0AF3708C711B251EF0E@USMBX1.msg.corp.akamai.com> Sender: omh1835@rit.edu To: "Salz, Rich" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary=001a11c2456ebf01c904dfea8f7c X-RIT-Received-From: 209.85.223.178 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=zEbpAyKmvz13UxJQKaZ4iF1mLaKmSxGhuHNvne9EWYw=; b=Qr4wfs135fKkdRPzHeGE+96hyWmYtQAD+wj29XuEYhIDPrXczpPGC8jlUMAXvIZS1E 7pJjGvIa/Smse5y+el6WCTBHGJ8ecTm5gE+t2Li+g7GeVkrW83moVoBIGvR08/YaiKWF Qv86cE9CVxPlfFmY4wNxB4Fwt3tOkGP+KuR+HLfVg1MDy7UqW56U72YJA9baELOgCiGJ i1YfEleWPYgTPSlWo81OtKY9qiLpY3sUxTs4tMDnalY6ePCMhhZkmGh5Uw9rFSvGlAbA rpfV9Zz40QgdOnnIAVG5E7aa4jFxV03eEKfLMKZHCggG06yKiVTJzPeYXJxr/lFojMDE BbUw== X-Google-Sender-Auth: Xa6fDqyREwtAQ_SZIqCqJyHL2Yk X-Gm-Message-State: ALoCoQn46+ZumgLFLjgMuE9GD2Uahdyt6dpYPFfq/w2zGFw1phH8+sjjsz0cGRDjTHltf2fzQj9YpmTwUwAUSVUnqmZxoEpfVEraIW/haOfefwiuXGE2+PpShdIsEp40cACBcsjP7vJk References: <2A0EFB9C05D0164E98F19BB0AF3708C711B251EE97@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EF0E@USMBX1.msg.corp.akamai.com> Cc: "tls@ietf.org" Subject: Re: [TLS] User Defined Key Pair 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, 24 Jun 2013 18:27:23 -0000 --001a11c2456ebf01c904dfea8f7c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Rich, The security implications is not in the predictably generation of the key pair, but in the seed length that you will be used to generate the key pair, in other words it's a matter of it's sustainability against the brute force attack. That's why I mentioned three versions of the generate key function, starting from generating the key pair based on the username, password, and security question answer pair, and up to having a smart card, or hardware token that has large enough random seed that will work with the username and the password as a second factor authentication. Even in the first case the password must be complex enough, and the each security question must be follow the best practice of having thousands of answer for each question, and remember that the question is not leaving the browser, so the man in the middle attacker will have to try all questions with all answers. On Mon, Jun 24, 2013 at 7:33 PM, Salz, Rich wrote: > **=D8 **On the browser level there should be a plugin that has a functio= n > to generate the key pair, that function must generate the same key pair f= or > the same input parameters.**** > > ** ** > > That=92s interesting. This is the first system I=92ve heard of that > predictably generating a keypair is not only a feature, but a requirement= . > **** > > ** ** > > I=92m sure that I am not the only person who is bothered by the security > implications of this.**** > > ** ** > > /r$**** > > -- **** > > Principal Security Engineer**** > > Akamai Technology**** > > Cambridge, MA**** > --001a11c2456ebf01c904dfea8f7c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi=A0Rich,

The security implications is not in the=A0pr= edictably generation of the key pair, but in the seed length that you will = be used to generate the key pair, in other words it's a matter of it= 9;s sustainability against the brute force attack.

That's why I mentioned three versions of the genera= te key function, starting from generating the key pair based on the usernam= e, password, and security question answer pair, and up to having a smart ca= rd, or hardware token that has large enough random seed that will work with= the username and the password as a=A0second factor authentication.

Even in the first case the password must be complex eno= ugh, and the each security question must be follow the best practice of hav= ing thousands of answer for each question, and remember that the question i= s not leaving the browser, so the man in the middle attacker will have to t= ry all questions with all answers.



On Mon, Jun 24, 2013 at 7:33 PM, Salz, Rich <<= a href=3D"mailto:rsalz@akamai.com" target=3D"_blank">rsalz@akamai.com&g= t; wrote:

=D8=A0 On the browser = level there should be a plugin that has a function to generate the key pair= , that function must generate the=A0same key pair for the same input parame= ters.

=A0

That=92s interesting.=A0 This is the first= system I=92ve heard of that predictably generating a keypair is not only a= feature, but a requirement.

=A0<= /p>

I=92m sure that I am n= ot the only person who is bothered by the security implications of this.=

= =A0

=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /r$

--=A0

Principal Security = Engineer

Akamai Technology<= u>

Cambridg= e, MA


--001a11c2456ebf01c904dfea8f7c-- From rsalz@akamai.com Mon Jun 24 11:34:41 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 E410D11E817B for ; Mon, 24 Jun 2013 11:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TgNDptnZZY7 for ; Mon, 24 Jun 2013 11:34:36 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 9B78511E815C for ; Mon, 24 Jun 2013 11:34:36 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id D2BA228198; Mon, 24 Jun 2013 18:34:32 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id C1A2628192; Mon, 24 Jun 2013 18:34:32 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id C260A2034; Mon, 24 Jun 2013 18:34:32 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.138]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Mon, 24 Jun 2013 14:34:32 -0400 From: "Salz, Rich" To: "omh1835@rit.edu" Date: Mon, 24 Jun 2013 14:34:32 -0400 Thread-Topic: [TLS] User Defined Key Pair Thread-Index: Ac5xCHW3housAHSuRVeT3luROCvM4AAAKt6Q Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711B251EFFF@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C711B251EE97@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EF0E@USMBX1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C711B251EFFFUSMBX1msgcorp_" MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] User Defined Key Pair 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, 24 Jun 2013 18:34:42 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C711B251EFFFUSMBX1msgcorp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =D8 and up to having a smart card, or hardware token that has large enough= random seed that will work with the username and the password as a second = factor authentication. That doesn't seem to make sense - if you're generating the keypair, predict= ably, from the inputs, how does a random seed enter into it? And what is t= he second factor authentication in this situation? I'm starting to think you're swimming out a little further into the deep en= d then you should. If you are trying to avoid CA's, then why not just use self-signed certific= ates or similar like PGP? /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA --_000_2A0EFB9C05D0164E98F19BB0AF3708C711B251EFFFUSMBX1msgcorp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

=D8  and= up to having a smart card, or hardware token that has large enough random = seed that will work with the username and the password as a second fac= tor authentication.

 

That doesn’t seem= to make sense – if you’re generating the keypair, predictably,= from the inputs, how does a random seed enter into it?=A0 And what is the = second factor authentication in this situation?

 

I’m starting to think you’re swimming out a little further i= nto the deep end then you should.

 

If you are = trying to avoid CA’s, then why not just use self-signed certificates = or similar like PGP?

 

=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0 /r$

 

--=A0

Principal Security Engineer

Akamai Technology

Cambridge, MA

 

= --_000_2A0EFB9C05D0164E98F19BB0AF3708C711B251EFFFUSMBX1msgcorp_-- From omh1835@g.rit.edu Mon Jun 24 14:29:40 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 4F13F11E8198 for ; Mon, 24 Jun 2013 14:29:40 -0700 (PDT) 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=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DRox92Z28UTx for ; Mon, 24 Jun 2013 14:29:34 -0700 (PDT) Received: from sc3app27.rit.edu (sc3app27.rit.edu [129.21.35.56]) by ietfa.amsl.com (Postfix) with ESMTP id B776611E818B for ; Mon, 24 Jun 2013 14:29:33 -0700 (PDT) Received: from mail-ie0-f180.google.com (mail-ie0-f180.google.com [209.85.223.180]) by smtp-server.rit.edu (PMDF V6.3-x14 #31420) with ESMTPS id <0MOX00EOJ2D6JJ@smtp-server.rit.edu> for tls@ietf.org; Mon, 24 Jun 2013 17:29:32 -0400 (EDT) Received: by mail-ie0-f180.google.com with SMTP id f4so24872107iea.25 for ; Mon, 24 Jun 2013 14:29:30 -0700 (PDT) Received: by 10.43.115.3 with HTTP; Mon, 24 Jun 2013 14:29:30 -0700 (PDT) X-Received: by 10.50.36.10 with SMTP id m10mr6827356igj.31.1372109370825; Mon, 24 Jun 2013 14:29:30 -0700 (PDT) X-Received: by 10.50.36.10 with SMTP id m10mr6827351igj.31.1372109370682; Mon, 24 Jun 2013 14:29:30 -0700 (PDT) Date: Tue, 25 Jun 2013 00:29:30 +0300 From: "OMAR HASSAN (RIT Student)" In-reply-to: <2A0EFB9C05D0164E98F19BB0AF3708C711B251EFFF@USMBX1.msg.corp.akamai.com> Sender: omh1835@rit.edu To: "Salz, Rich" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary=089e013c69bca2d4bb04dfed1b22 X-RIT-Received-From: 209.85.223.180 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=FUkzzdK7yZHiPZ2vGpdzDbYdPoG9CdV8RTnD34jHoKY=; b=YcDjqW4pr7IUNCiPyCnKS92nkYeggJhzXvEk0EQKfAUXJKumjdFM2iUQIJPxU/zHAL 1H2BRlDPPQvlQh77kgR4vBKMZWmX7OU6CbYJBqxRno+wdrflHK9b/apnAzXDLdnop9J9 QK/I1YkdL5mzTGU6CgdvpH3EUtCVFyBT+uzgjjYSp9at+OWJvB55sXNrD9MzZVmhWliU FkcSFUFEjhodUBTor7li9SlcI/uvfdC6by4IGmPErpkbiX4BidUhSWVSXMatSfAx8lZq 0xZbgYjfpAYRhxTu9ytdUnKVi4CI0QVZIfZLtv2XsSR6V6B2SNv/ER+OkugOFfPnuRhf zGNg== X-Google-Sender-Auth: 9NTRMzerGOhlmFVHZAgFMtNUyJo X-Gm-Message-State: ALoCoQktCZkda9y6EMGIuQaUU4oXVYn/FYekkH0bYeEvwgRV67otSPIePucBbMZaV9O78FLUsa63k+gUu8MrLcu2ueO1v1PQlkwZaNIqLURzkttvzS0XqbbfVlHl/2IMrH6atfRgL45y References: <2A0EFB9C05D0164E98F19BB0AF3708C711B251EE97@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EF0E@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EFFF@USMBX1.msg.corp.akamai.com> Cc: "tls@ietf.org" Subject: Re: [TLS] User Defined Key Pair 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, 24 Jun 2013 21:29:40 -0000 --089e013c69bca2d4bb04dfed1b22 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hello Rich When the user enrolls into one of those websites, and let's say he will go with the second option of using a usb as a second factor authentication, where the password is something he knows, and the usb is something he has. when he plug the usb into the computer, the browser plugin will create a random data stream and save it into a file in the usb, this file will be passed to the genKeyPair function with the username and the password to generate the key pair. when the user tries to log in later into the website, he will plug the usb into the computer and select that previously created file that will be passed to the genKeyPair function with the username and the password to generate the same key pair. On the server the user public key will be used to encrypt the session key pre-master that will be used by the browser and the server to generate the session keys. Self signed certificate is very dangerous because the user will not have a way to verify the identity of the certificate owner and he could be a victim to a man in the middle attack. On Mon, Jun 24, 2013 at 9:34 PM, Salz, Rich wrote: > **=D8 **and up to having a smart card, or hardware token that has large > enough random seed that will work with the username and the password as > a second factor authentication.**** > > ** ** > > That doesn=92t seem to make sense =96 if you=92re generating the keypair, > predictably, from the inputs, how does a random seed enter into it? And > what is the second factor authentication in this situation?**** > > ** ** > > I=92m starting to think you=92re swimming out a little further into the d= eep > end then you should.**** > > ** ** > > If you are trying to avoid CA=92s, then why not just use self-signed > certificates or similar like PGP?**** > > ** ** > > /r$**** > > ** ** > > -- **** > > Principal Security Engineer**** > > Akamai Technology**** > > Cambridge, MA**** > > ** ** > --089e013c69bca2d4bb04dfed1b22 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hello=A0Rich

When the user enrolls into= one of those websites, and let's say he will go with the second option= of using a usb as a second factor authentication, where the password is so= mething he knows, and the usb is something he has.

when he plug the usb into the computer, the browser plu= gin will create a random data stream and save it into a file in the usb, th= is file will be passed to the genKeyPair function with the username and the= password to generate the key pair.

when the user tries to log in later into the website, h= e will plug the usb into the computer and select that previously created fi= le that will be passed to the genKeyPair function with the username and the= password to generate the same key pair.

On the server the user public key will be used to encry= pt the session key pre-master that will be used by the browser and the serv= er to generate the session keys.

Self signed certi= ficate is very dangerous because the user will not have a way to verify the= identity of the certificate owner and he could be a victim to a man in the= middle attack.


On Mon,= Jun 24, 2013 at 9:34 PM, Salz, Rich <rsalz@akamai.com> wrote= :

=D8=A0 and up to having a smart = card, or hardware token that has large enough random seed that will work wi= th the username and the password as a=A0second factor authentication.

=A0

That doesn=92t seem to make sense =96 if y= ou=92re generating the keypair, predictably, from the inputs, how does a ra= ndom seed enter into it?=A0 And what is the second factor authentication in= this situation?

=A0<= /p>

I=92m starting to thin= k you=92re swimming out a little further into the deep end then you should.=

=A0<= /p>

If you are trying to a= void CA=92s, then why not just use self-signed certificates or similar like= PGP?

= =A0

=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /r$

=A0<= /p>

--=A0

Principal Security Engine= er

Cambridge, MA

=A0


--089e013c69bca2d4bb04dfed1b22-- From rheoli08@gmail.com Mon Jun 24 22:24:22 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 A9C1421F9EFD for ; Mon, 24 Jun 2013 22:24:22 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 098JkhGgk5NK for ; Mon, 24 Jun 2013 22:24:21 -0700 (PDT) Received: from mail-ee0-x235.google.com (mail-ee0-x235.google.com [IPv6:2a00:1450:4013:c00::235]) by ietfa.amsl.com (Postfix) with ESMTP id 5819721F9D98 for ; Mon, 24 Jun 2013 22:24:21 -0700 (PDT) Received: by mail-ee0-f53.google.com with SMTP id c41so6478343eek.40 for ; Mon, 24 Jun 2013 22:24:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:message-id:mime-version:subject:date:references :to:in-reply-to:x-mailer; bh=IjZI86hN5KKKICgBAwzxKZlS/0Tqg7YD7TNJ2P7KrHE=; b=s3Q+QisgLf4/7lx1rmTtQGtx4Z3aKQn+QM+jYg27wcFVW7djTo6Dh1WAf9rPtN31Z5 xO8BYFJdwmCGow48TN/2lvDeCLorty6kkkmxEybMlgFkj1Fn5czIClbuwmzaRsY3m/cu xbe8F+cnUaBRJepOCukE7jFYZ21uQJWxp/2yMVdqr8uMr/vunuZ3+5uDUC6TXFrfEAV6 XvFCWGmQ4N70+657FfnmUeWIl/B59F86ZZVcFMLo9VQJoL2I7Rc4U0smlyYk26sDOL4M ndNWJWkVK1f18EtcdJWgH2kb3b4pXZNiD4w+p2d9zf9y66ESvjjMeTbvqQm+m/4drYYA Gdhg== X-Received: by 10.15.94.11 with SMTP id ba11mr28026836eeb.101.1372137860467; Mon, 24 Jun 2013 22:24:20 -0700 (PDT) Received: from [10.73.8.49] (80-219-144-124.dclient.hispeed.ch. [80.219.144.124]) by mx.google.com with ESMTPSA id n42sm33110044eeh.15.2013.06.24.22.24.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 24 Jun 2013 22:24:19 -0700 (PDT) From: "Stephan T." Content-Type: multipart/alternative; boundary="Apple-Mail=_42080809-60AF-4DF6-9AC5-767E19631621" Message-Id: Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Date: Tue, 25 Jun 2013 07:24:18 +0200 References: To: "OMAR HASSAN (RIT Student)" , tls@ietf.org In-Reply-To: X-Mailer: Apple Mail (2.1508) Subject: Re: [TLS] User Defined Key Pair 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, 25 Jun 2013 05:24:22 -0000 --Apple-Mail=_42080809-60AF-4DF6-9AC5-767E19631621 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, How you made sure that the user (client) is connected with the intended = server? -Stephan Am 21.06.2013 um 20:35 schrieb OMAR HASSAN (RIT Student) = : > Hello All, >=20 > I have uploaded a new version of the User Defined Key pair protocol = that is cleaner and briefer, I will appreciate any comments or = suggestions.=20 >=20 > Just to remind you: >=20 > http://tools.ietf.org/html/draft-omar-tls-udkp-01 >=20 > The new protocol is a new way of securing the traffic to websites = without being depending on any third party to secure the traffic between = the user and the website, so it will be possible for the user to secure = his browsing using his credential information, smart card, or a random = file on usb. That will make the use of two factor for authentication and = traffic security is separated from the application code, the website = admin only needs to configure how the users are going to access the = website. Additionally there are no passwords required to be transferred = any more on the network, which will render the Phishing attack useless. >=20 > The motivation behind the new protocol is to make the security the = responsibility of the two involved parties, because as you know, the = security and confidentiality of user browsing in TLS depend upon the = number of Certificate Authorities (CAs), major web browsers trust = hundreds of different =0Cfirms to issue certificates. Each of these =0C= firms can be compelled by their national government, or being = compromised to issue a certificate for any particular website that all = web browsers will trust without warning.Thus, users around the world are = put in a position where their browser entrusts their private data, = indirectly, to a large number of governments, and entities. = (http://cryptome.org/ssl-mitm.pdf) >=20 > Thank You > Best Regards > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_42080809-60AF-4DF6-9AC5-767E19631621 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 omh1835@rit.edu>:

Hello = All,

I have uploaded a = new version of the User Defined Key pair protocol that is cleaner and = briefer, I will appreciate any comments or = suggestions. 

Just to remind = you:

http://tools.ietf.org/html/dra= ft-omar-tls-udkp-01

The new protocol is a new way of securing = the traffic to websites without being depending on any third party to = secure the traffic between the user and the website, so it will be = possible for the user to secure his browsing using his credential = information, smart card, or a random file on usb. That will make the use = of two factor for authentication and traffic security is separated from = the application code, the website admin only needs to = configure how the users are going to access the website. Additionally = there are no passwords required to be transferred any more on the = network, which will render the Phishing attack useless.

The = motivation behind the new protocol is to make the security the = responsibility of the two involved parties, because as you know, the = security and confidentiality of user browsing in TLS depend upon the = number of Certificate Authorities (CAs), major web browsers trust = hundreds of different =0Cfirms to issue certificates. Each of these =0C= firms can be compelled by their national government, or being = compromised to issue a certificate for any particular website that all = web browsers will trust without warning.Thus, users around the world are = put in a position where their browser entrusts their private data, = indirectly, to a large number of governments, and entities. (http://cryptome.org/ssl-mitm.p= df)

Thank = You
Best = Regards
_______________________________________________
TLS mailing = list
TLS@ietf.org
https://www.ietf.org/mail= man/listinfo/tls

= --Apple-Mail=_42080809-60AF-4DF6-9AC5-767E19631621-- From ynir@checkpoint.com Tue Jun 25 00:32:40 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 50D2021F9E7E for ; Tue, 25 Jun 2013 00:32:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aN3HdgcvRJmg for ; Tue, 25 Jun 2013 00:32:34 -0700 (PDT) Received: from smtp.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9D59221F9A86 for ; Tue, 25 Jun 2013 00:32:33 -0700 (PDT) Received: from IL-EX10.ad.checkpoint.com ([194.29.34.147]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r5P7WV8Z023656 for ; Tue, 25 Jun 2013 10:32:32 +0300 X-CheckPoint: {51C9478F-3-1B221DC2-1FFFF} Received: from DAG-EX10.ad.checkpoint.com ([169.254.3.48]) by IL-EX10.ad.checkpoint.com ([169.254.2.180]) with mapi id 14.02.0342.003; Tue, 25 Jun 2013 10:32:31 +0300 From: Yoav Nir To: "tls@ietf.org list" Thread-Topic: Some comments about draft-ietf-tls-applayerprotoneg-01 Thread-Index: AQHOcXYmoV9GvBkxHECtNVUf6mHhEQ== Date: Tue, 25 Jun 2013 07:32:31 +0000 Message-ID: <279FAAD4-1FF3-4D9D-939A-10D83E0B036E@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [91.90.139.159] x-kse-antivirus-interceptor-info: protection disabled x-cpdlp: 11ede8fb84358d8d905206edc49e8e81725ab68902 Content-Type: text/plain; charset="us-ascii" Content-ID: <14C3605A9A494A49B87D5512DC08EBE3@ad.checkpoint.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [TLS] Some comments about draft-ietf-tls-applayerprotoneg-01 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, 25 Jun 2013 07:32:40 -0000 Hi I have read the draft, and think it is in good shape. There are some quibbl= es, however. Section 3.1 says:=20 "ProtocolNameList" contains the list of protocols advertised by the client, in descending order of preference. But section 3.2 says:=20 It is expected that a server will have a list of protocols that it supports, in preference order, and will only select a protocol if the client supports it. In that case, the server SHOULD select the most highly preferred protocol it supports which is also advertised by the client. It's not clear to me why the order of preference of the client makes any di= fference if the server chooses a protocol based on its own order of prefere= nce. I would remove that last sentence, and leave it up to the implementati= on whether it enforces its own order of preference (select the most preferr= ed protocol that appears anywhere on the client's list) or the clients' (se= lect the first protocol advertised by the client that you also support). Section 3.1 has this rather confusing paragraph: Servers that receive a client hello containing the "application_layer_protocol_negotiation" extension, MAY return a suitable protocol selection response to the client. The server will ignore any protocol name that it does not recognize. A new ServerHello extension type ("application_layer_protocol_negotiation(16)") MAY be returned to the client within the extended ServerHello message. The "extension_data" field of the ("application_layer_protocol_negotiation(16)") extension SHALL be structured the same as described above for the client "extension_data", except that the "ProtocolNameList" MUST contain exactly one "ProtocolName". First, ClientHello and ServerHello extensions are pretty much the same (yes= , I know the formatting sometimes changes), so there's no need to talk abou= t "a new ServerHello extension type". Also, I can't figure out the MAY here= . Not returning a response says that the server does not support this exten= sion. A server compliant with this specification MUST send a response (or e= lse a no_application_protocol alert). How about rewriting this as follows: Compliant servers that receive a client hello containing the "application_layer_protocol_negotiation" extension, MUST return a suitable protocol selection response to the client. The server MUST ignore any protocol name that it does not recognize. A=20 ("application_layer_protocol_negotiation(16)") extension MUST be=20 returned to the client within the ServerHello message. The=20 "extension_data" field of the extension is structured the same as=20 described above for the client "extension_data", except that the=20 "ProtocolNameList" MUST contain exactly one "ProtocolName". Section 3.1 also has this: Experimental protocol names, which are not registered by IANA, will start with the following sequence of bytes: 0x65, 0x78, 0x70 ("exp"). And this is repeated in section 4: A namespace will be assigned for experimental protocols, comprising byte strings which start with the following sequence of bytes: 0x65, 0x78, 0x70 ("exp"). Assignments in this namespace do not need IANA registration. I suggest a somewhat different namespace allocation: * Names that begin with "X-" (0x58,0x2D) are experiments, like "X-spdy/4" * Names that begin with "P-" (0x50,0x2D) are private, and shall have an or= ganizational identifier, plus a protocol, like "P-MSFT-SSTP" or "P-CHKP-SNX= " * Names that begin with "D-" (0x44,0x2D) denote drafts, and the rest of th= e byte string has the draft title minus the "draft" qualifier, for example = "D-ietf-httpbis-http2-03". Since a slash (0x2F) is never part of the docume= nt name, a document that defines >1 protocols may add a slash and an intern= ally-meaningful string, such as "D-ietf-httpbis-http2-03/no-header-compress= ion" * IANA shall not assign any byte strings where the second byte is 0x2D. Su= ch byte strings are reserved. Section 4 says: Finally, by managing protocol selection in the clear as part of the handshake, ALPN avoids introducing false confidence with respect to the the ability to hide the negotiated protocol in advance of establishing the connection. If hiding the protocol is required, then renegotiation after connection establishment, which would provide true TLS security guarantees, would be a preferred methodology. How about making this more explicit. Add a special protocol called "hide", = and have the client propose just that. They could even be using an anon-dh = ciphersuite for that handshake. If "hide" is selected, no application data = is tolerated within it, and the client MUST immediately renegotiate with a = proper list of protocols.=20 If both of my previous suggestions are accepted, I would change the initial= registry to contain just "http/1.1" and "hide" for starters, as the spdy e= xperiment can be accommodated by "X-" prefix, and the draft versions of HTT= P/2.0 can be accommodated by "D-" prefix. Finally, the end of section 3.1 says this: Unlike many other TLS extensions, this extension does not establish properties of the session, only of the connection. When session resumption or session tickets [RFC5077] are used, the previous contents of this extension are irrelevant and only the values in the new handshake messages are considered. This does not mention renegotiation. Suppose we are already running applica= tion data, and the client initiates a renegotiation. Makes no difference if= this is of its own accord or because of a HelloRequest sent by the server.= Does it make any sense at all to include a protocol list in the renegotiat= ion handshake? Yoav From juhovh@iki.fi Tue Jun 25 00:57:12 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 C705D21F99A7 for ; Tue, 25 Jun 2013 00:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.903 X-Spam-Level: X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pewOOSd+5cTM for ; Tue, 25 Jun 2013 00:57:07 -0700 (PDT) Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 97ACB21F8842 for ; Tue, 25 Jun 2013 00:57:06 -0700 (PDT) Received: from [10.48.168.207] (188.238.43.207) by jenni2.inet.fi (8.5.140.03) id 51BB235B00D18A02; Tue, 25 Jun 2013 10:57:03 +0300 References: <2A0EFB9C05D0164E98F19BB0AF3708C711B251EE97@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EF0E@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EFFF@USMBX1.msg.corp.akamai.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: X-Mailer: iPhone Mail (10B329) From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= Date: Tue, 25 Jun 2013 10:56:50 +0300 To: "OMAR HASSAN (RIT Student)" Cc: "tls@ietf.org" Subject: Re: [TLS] User Defined Key Pair 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, 25 Jun 2013 07:57:12 -0000 This discussion forced me to take a look at the draft. The whole security of= the system seems to be dependant on the security of the "browser plugin" an= d its key generation and encryption algorithms, which are not defined in the= draft. I don't see how this could possibly be an interoperable standard as i= t is. On 25.6.2013, at 0.29, "OMAR HASSAN (RIT Student)" wrote: > When the user enrolls into one of those websites, and let's say he will go= with the second option of using a usb as a second factor authentication, wh= ere the password is something he knows, and the usb is something he has. What if someone detects this enrollment and sends a new public key for the u= ser before the user has time to fill all the fields? Sounds like a race cond= ition to me. > Self signed certificate is very dangerous because the user will not have a= way to verify the identity of the certificate owner and he could be a victi= m to a man in the middle attack. But at least the keys are generated using a truly random seed, instead of pa= rt of the seed being predictable (username, password, security question) whi= ch actually sounds worse to me. I don't see how this is different from generating a self signed client cert a= nd verifying it with for example HMAC with username+password+question derive= d secret. If you already need a custom browser plugin to handle the login, y= ou can put all your custom logic there and use standard TLS for the rest. Juho From robert.cragie@gridmerge.com Tue Jun 25 01:25:50 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 EC92621F9412 for ; Tue, 25 Jun 2013 01:25:49 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqUKISyxFywt for ; Tue, 25 Jun 2013 01:25:45 -0700 (PDT) Received: from mail41.extendcp.co.uk (mail41.extendcp.co.uk [79.170.44.41]) by ietfa.amsl.com (Postfix) with ESMTP id B457721F9C31 for ; Tue, 25 Jun 2013 01:25:40 -0700 (PDT) Received: from [94.116.33.115] (helo=[10.38.240.171]) by mail41.extendcp.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80.1) id 1UrOZ8-0003OF-R0 for tls@ietf.org; Tue, 25 Jun 2013 09:25:30 +0100 Message-ID: <51C953FC.7010802@gridmerge.com> Date: Tue, 25 Jun 2013 09:25:32 +0100 From: Robert Cragie Organization: Gridmerge Ltd. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: tls@ietf.org References: <2A0EFB9C05D0164E98F19BB0AF3708C711B251EE97@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EF0E@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EFFF@USMBX1.msg.corp.akamai.com> In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000200070203070800000602" X-Authenticated-As: robert.cragie@gridmerge.com Subject: Re: [TLS] User Defined Key Pair X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: robert.cragie@gridmerge.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, 25 Jun 2013 08:25:50 -0000 This is a cryptographically signed message in MIME format. --------------ms000200070203070800000602 Content-Type: multipart/alternative; boundary="------------080409060809070608020304" This is a multi-part message in MIME format. --------------080409060809070608020304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable +1. It would seem more appropriate to use a self-signed client=20 certificate (which can be generated in a similar way from username and=20 password etc.) in conjunction with a CA-signed server certificate for=20 mutual authentication. Some other points: * As the proposal has no server authentication, it is surely broken in that respect i.e. the client could be lured to any bogus website masquerading as a legitimate one. How would the client know? * Token =3D enc(ServerHello.random, PrivKey) : The concept of encryptin= g using a private key seems pointless. Don't you mean signing? Robert On 25/06/2013 08:56, Juho V=E4h=E4-Herttua wrote: > This discussion forced me to take a look at the draft. The whole securi= ty of the system seems to be dependant on the security of the "browser pl= ugin" and its key generation and encryption algorithms, which are not def= ined in the draft. I don't see how this could possibly be an interoperabl= e standard as it is. > > On 25.6.2013, at 0.29, "OMAR HASSAN (RIT Student)" wr= ote: > >> When the user enrolls into one of those websites, and let's say he wil= l go with the second option of using a usb as a second factor authenticat= ion, where the password is something he knows, and the usb is something h= e has. > What if someone detects this enrollment and sends a new public key for = the user before the user has time to fill all the fields? Sounds like a r= ace condition to me. > >> Self signed certificate is very dangerous because the user will not ha= ve a way to verify the identity of the certificate owner and he could be = a victim to a man in the middle attack. > But at least the keys are generated using a truly random seed, instead = of part of the seed being predictable (username, password, security quest= ion) which actually sounds worse to me. > > I don't see how this is different from generating a self signed client = cert and verifying it with for example HMAC with username+password+questi= on derived secret. If you already need a custom browser plugin to handle = the login, you can put all your custom logic there and use standard TLS f= or the rest. > > > Juho > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --------------080409060809070608020304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1. It would seem more appropriate to use a self-signed client certificate (which can be generated in a similar way from username and password etc.) in conjunction with a CA-signed server certificate for mutual authentication.

Some other points:

  • As the proposal has no server authentication, it is surely broken in that respect i.e. the client could be lured to any bogus website masquerading as a legitimate one. How would the client know?
  • Token =3D enc(ServerHello.random, PrivKey) : The concept of encrypting using a private key seems pointless. Don't you mean signing?

Robert


On 25/06/2013 08:56, Juho Väh&aum= l;-Herttua wrote:
This discussion forced me to take a look at the draf=
t. The whole security of the system seems to be dependant on the security=
 of the "browser plugin" and its key generation and encryption algorithms=
, which are not defined in the draft. I don't see how this could possibly=
 be an interoperable standard as it is.

On 25.6.2013, at 0.29, "OMAR HASSAN (RIT Student)" <omh1835@rit.edu> =
wrote:


When the user enrolls into one of those websites, =
and let's say he will go with the second option of using a usb as a secon=
d factor authentication, where the password is something he knows, and th=
e usb is something he has.

What if someone detects this enrollment and sends a new public key for th=
e user before the user has time to fill all the fields? Sounds like a rac=
e condition to me.


Self signed certificate is very dangerous because =
the user will not have a way to verify the identity of the certificate ow=
ner and he could be a victim to a man in the middle attack.

But at least the keys are generated using a truly random seed, instead of=
 part of the seed being predictable (username, password, security questio=
n) which actually sounds worse to me.

I don't see how this is different from generating a self signed client ce=
rt and verifying it with for example HMAC with username+password+question=
 derived secret. If you already need a custom browser plugin to handle th=
e login, you can put all your custom logic there and use standard TLS for=
 the rest.


Juho


_______________________________________________
TLS mailing list
TLS@ie=
tf.org
https://www.ietf.org/mailman/listinfo/tls

--------------080409060809070608020304-- --------------ms000200070203070800000602 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILUDCC BRowggQCoAMCAQICEG0Z6qcZT2ozIuYiMnqqcd4wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNV BAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3Qu Y29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQg RW1haWwwHhcNMTEwNDI4MDAwMDAwWhcNMjAwNTMwMTA0ODM4WjCBkzELMAkGA1UEBhMCR0Ix GzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9yZDEaMBgGA1UE ChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQgQXV0aGVudGlj YXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBAJKEhFtLV5jUXi+LpOFAyKNTWF9mZfEyTvefMn1V0HhMVbdClOD5J3EHxcZppLkyxPFA GpDMJ1Zifxe1cWmu5SAb5MtjXmDKokH2auGj/7jfH0htZUOMKi4rYzh337EXrMLaggLW1DJq 1GdvIBOPXDX65VSAr9hxCh03CgJQU2yVHakQFLSZlVkSMf8JotJM3FLb3uJAAVtIaN3FSrTg 7SQfOq9xXwfjrL8UO7AlcWg99A/WF1hGFYE8aIuLgw9teiFX5jSw2zJ+40rhpVJyZCaRTqWS D//gsWD9Gm9oUZljjRqLpcxCm5t9ImPTqaD8zp6Q30QZ9FxbNboW86eb/8ECAwEAAaOCAUsw ggFHMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBR6E04AdFvG eGNkJ8Ev4qBbvHnFezAOBgNVHQ8BAf8EBAMCAQYwEgYDVR0TAQH/BAgwBgEB/wIBADARBgNV HSAECjAIMAYGBFUdIAAwWAYDVR0fBFEwTzBNoEugSYZHaHR0cDovL2NybC51c2VydHJ1c3Qu Y29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwdAYI KwYBBQUHAQEEaDBmMD0GCCsGAQUFBzAChjFodHRwOi8vY3J0LnVzZXJ0cnVzdC5jb20vVVRO QWRkVHJ1c3RDbGllbnRfQ0EuY3J0MCUGCCsGAQUFBzABhhlodHRwOi8vb2NzcC51c2VydHJ1 c3QuY29tMA0GCSqGSIb3DQEBBQUAA4IBAQCF1r54V1VtM39EUv5C1QaoAQOAivsNsv1Kv/av QUn1G1rF0q0bc24+6SZ85kyYwTAo38v7QjyhJT4KddbQPTmGZtGhm7VNm2+vKGwdr+XqdFqo 2rHA8XV6L566k3nK/uKRHlZ0sviN0+BDchvtj/1gOSBH+4uvOmVIPJg9pSW/ve9g4EnlFsjr P0OD8ODuDcHTzTNfm9C9YGqzO/761Mk6PB/tm/+bSTO+Qik5g+4zaS6CnUVNqGnagBsePdIa XXxHmaWbCG0SmYbWXVcHG6cwvktJRLiQfsrReTjrtDP6oDpdJlieYVUYtCHVmdXgQ0BCML7q peeU0rD+83X5f27nMIIGLjCCBRagAwIBAgIQXDFQ28QtqMuYch5f2nTvZjANBgkqhkiG9w0B AQUFADCBkzELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENP TU9ETyBDbGllbnQgQXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQTAeFw0xMTA5 MDIwMDAwMDBaFw0xNDA5MDEyMzU5NTlaMIIBNzELMAkGA1UEBhMCR0IxEDAOBgNVBBETB1dG NCA0V0ExFzAVBgNVBAgTDldlc3QgWW9ya3NoaXJlMRIwEAYDVQQHEwlXYWtlZmllbGQxFDAS BgNVBAkTC0dyYW5nZSBNb29yMR8wHQYDVQQJExY4OSBHcmVlbmZpZWxkIENyZXNjZW50MRcw FQYDVQQKEw5HcmlkbWVyZ2UgTHRkLjE0MDIGA1UECxMrSXNzdWVkIHRocm91Z2ggR3JpZG1l cmdlIEx0ZC4gRS1QS0kgTWFuYWdlcjEfMB0GA1UECxMWQ29ycG9yYXRlIFNlY3VyZSBFbWFp bDEWMBQGA1UEAxMNUm9iZXJ0IENyYWdpZTEqMCgGCSqGSIb3DQEJARYbcm9iZXJ0LmNyYWdp ZUBncmlkbWVyZ2UuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArcThqvLe WU1Q1ZJmnb+2UQSwOQKWok3A1Mwk582AdvwaAQyBFliPyJ0kXJqtwNBoZvk+3WJr0QA5ZRr+ J0x3sXVpcxadojP2HNzy1gsgDtIGG8ltoU4vmX1A8BTlOIUT+Pg8p/bSruxV0vz0CR8ho2hs R0Zi5vU+rQKNmbgufbkWhlQnMEYjknemscLQfw1YZz90ta67doNDujFy6+X6I06HpjudgMYx 8bdsNS5xVFFwuBA1eqNQra+xLzhCOeX9PPB/zK68qdNhrni3WPYG9EhSt4Dzk+xIz9hj7wrU ZIVXDTPsY8qbUSBVpwmzI5lCHPgzurH1OK7WwgpDSsl5pwIDAQABo4IB1TCCAdEwHwYDVR0j BBgwFoAUehNOAHRbxnhjZCfBL+KgW7x5xXswHQYDVR0OBBYEFBCOXNH+lDm8U9gy3b3bRvrx vKgrMA4GA1UdDwEB/wQEAwIFoDAMBgNVHRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwME BggrBgEFBQcDAjBGBgNVHSAEPzA9MDsGDCsGAQQBsjEBAgEDBTArMCkGCCsGAQUFBwIBFh1o dHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQUzBXBgNVHR8EUDBOMEygSqBIhkZodHRwOi8v Y3JsLmNvbW9kb2NhLmNvbS9DT01PRE9DbGllbnRBdXRoZW50aWNhdGlvbmFuZFNlY3VyZUVt YWlsQ0EuY3JsMIGIBggrBgEFBQcBAQR8MHowUgYIKwYBBQUHMAKGRmh0dHA6Ly9jcnQuY29t b2RvY2EuY29tL0NPTU9ET0NsaWVudEF1dGhlbnRpY2F0aW9uYW5kU2VjdXJlRW1haWxDQS5j cnQwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmNvbW9kb2NhLmNvbTAmBgNVHREEHzAdgRty b2JlcnQuY3JhZ2llQGdyaWRtZXJnZS5jb20wDQYJKoZIhvcNAQEFBQADggEBAD6b/O0LkPav kR4Znoqxg0Ad7M3duDm4uzfrlX4ecgq56Ccdwd+3Tayz7Ewej30woVMmTKkA/NKRaCd0wVM9 8seF/oZjXKO7o1SH27igRnGSWjCoWXsdwJGfZbYnvcIIhhsxJoCPNbeSR7C0PAFDKsP3xrJy MHMljIJsoRbZu/fnYNyFWh9OXf7fYJOGmKDKAhSabUGfhY7umvU9d/YTqo02Q6YzC7d4zPNG 1a75AuHSEchf6GdKqycG38I5y9jlDaYfXspoS3PlTNCIeZONbOSMZgftnNEVKq+SWytFqyG/ 8+dwpm/a12KMex5J8iHwaUKj++2O2rAFNjDDqXpeEYoxggQZMIIEFQIBATCBqDCBkzELMAkG A1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBxMHU2FsZm9y ZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxOTA3BgNVBAMTMENPTU9ETyBDbGllbnQg QXV0aGVudGljYXRpb24gYW5kIFNlY3VyZSBFbWFpbCBDQQIQXDFQ28QtqMuYch5f2nTvZjAJ BgUrDgMCGgUAoIICRTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEP Fw0xMzA2MjUwODI1MzJaMCMGCSqGSIb3DQEJBDEWBBSWlCkO+nqsoTtrtIeV2N0t71MtuTBs BgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFlAwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcw DgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEo MIG5BgkrBgEEAYI3EAQxgaswgagwgZMxCzAJBgNVBAYTAkdCMRswGQYDVQQIExJHcmVhdGVy IE1hbmNoZXN0ZXIxEDAOBgNVBAcTB1NhbGZvcmQxGjAYBgNVBAoTEUNPTU9ETyBDQSBMaW1p dGVkMTkwNwYDVQQDEzBDT01PRE8gQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBTZWN1cmUg RW1haWwgQ0ECEFwxUNvELajLmHIeX9p072YwgbsGCyqGSIb3DQEJEAILMYGroIGoMIGTMQsw CQYDVQQGEwJHQjEbMBkGA1UECBMSR3JlYXRlciBNYW5jaGVzdGVyMRAwDgYDVQQHEwdTYWxm b3JkMRowGAYDVQQKExFDT01PRE8gQ0EgTGltaXRlZDE5MDcGA1UEAxMwQ09NT0RPIENsaWVu dCBBdXRoZW50aWNhdGlvbiBhbmQgU2VjdXJlIEVtYWlsIENBAhBcMVDbxC2oy5hyHl/adO9m MA0GCSqGSIb3DQEBAQUABIIBAHN1yK8XQlw2oiO/kpKf3h4X5gPKGxAlzBdtvEYCjIdLPSlj 2mLjU4FpEKe0ow2Jhco7NIfEmKjv0+3Lek0/yvBbKC3WLrkurozzNS0Jpw74kpw72b9ddmaN s3IIFeA1xRg1+vwkT+5NYzf63M5q3E7as3FFIjQ/QmFATkTDpP9NjYLMhVw59gCxUXjgY1Al Ep0cPOYzzg8dJ95go13z0nKcrRAGp1NijI+HvfqT10A18hRzDlNrnX7mPM3QVbej7qAnpnN1 l/SXsnTA4+f5oMEvdsAda+oKePn7Fprq7vDnBvv7FddqYOtNqqn54xr5aXac5VEW2gPoHfk0 KNBOoAgAAAAAAAA= --------------ms000200070203070800000602-- From rsalz@akamai.com Tue Jun 25 04:29:43 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 4C62F21F9EEE for ; Tue, 25 Jun 2013 04:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RebvRCFnxhAv for ; Tue, 25 Jun 2013 04:29:29 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [96.6.114.97]) by ietfa.amsl.com (Postfix) with ESMTP id 5F9AF21F9A2A for ; Tue, 25 Jun 2013 04:29:27 -0700 (PDT) Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id F413D1C47D7; Tue, 25 Jun 2013 11:29:18 +0000 (GMT) Received: from prod-mail-relay04.akamai.com (prod-mail-relay04.akamai.com [172.27.8.27]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id E8B5D1C47D5; Tue, 25 Jun 2013 11:29:18 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay04.akamai.com (Postfix) with ESMTP id BCBAB47BD2; Tue, 25 Jun 2013 11:29:18 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.138]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Tue, 25 Jun 2013 07:29:18 -0400 From: "Salz, Rich" To: "omh1835@rit.edu" Date: Tue, 25 Jun 2013 07:29:09 -0400 Thread-Topic: [TLS] User Defined Key Pair Thread-Index: Ac5xIeytIdSaLseqSwepXtKjATB72AAdKUTg Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C711B251F1E5@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C711B251EE97@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EF0E@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EFFF@USMBX1.msg.corp.akamai.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C711B251F1E5USMBX1msgcorp_" MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] User Defined Key Pair 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, 25 Jun 2013 11:29:43 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C711B251F1E5USMBX1msgcorp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =D8 Self signed certificate is very dangerous because the user will not ha= ve a way to verify the identity of the certificate owner and he could be a = victim to a man in the middle attack. I don't see anything in your system that prevents this, either. It seems t= hat replacing your system with self-signed client certificates would be equ= ivalent. It's great that you are trying to improve things; don't get discouraged, bu= t this ain't there yet. And as a first step to replacing all of SSL/TLS? = Nope. /r$ -- Principal Security Engineer Akamai Technology Cambridge, MA --_000_2A0EFB9C05D0164E98F19BB0AF3708C711B251F1E5USMBX1msgcorp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

=D8  Sel= f signed certificate is very dangerous because the user will not have a way= to verify the identity of the certificate owner and he could be a victim t= o a man in the middle attack.

 

I don’t see anyt= hing in your system that prevents this, either.=A0 It seems that replacing = your system with self-signed client certificates would be equivalent.<= /o:p>

 

It’s great that you are trying to improve th= ings; don’t get discouraged, but this ain’t there yet.=A0 And a= s a first step to replacing all of SSL/TLS?=A0 Nope.

<= p class=3DMsoNormal> 

=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /r$=

 

--=A0

Prin= cipal Security Engineer

Ak= amai Technology

Cambridge,= MA

 

= --_000_2A0EFB9C05D0164E98F19BB0AF3708C711B251F1E5USMBX1msgcorp_-- From turners@ieca.com Tue Jun 25 08:59:37 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 975BB11E811F for ; Tue, 25 Jun 2013 08:59:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.666 X-Spam-Level: X-Spam-Status: No, score=-99.666 tagged_above=-999 required=5 tests=[IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8q1Dyc88n6bo for ; Tue, 25 Jun 2013 08:59:31 -0700 (PDT) Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [69.93.179.27]) by ietfa.amsl.com (Postfix) with ESMTP id C8D0D11E810C for ; Tue, 25 Jun 2013 08:59:22 -0700 (PDT) Received: by gateway09.websitewelcome.com (Postfix, from userid 507) id D7FC58B2B2CC0; Tue, 25 Jun 2013 10:58:43 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway09.websitewelcome.com (Postfix) with ESMTP id C6E458B2B2C6A for ; Tue, 25 Jun 2013 10:58:43 -0500 (CDT) Received: from [173.73.135.101] (port=57149 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1UrVeL-0006EH-2X for tls@ietf.org; Tue, 25 Jun 2013 10:59:21 -0500 Message-ID: <51C9BE58.4090208@ieca.com> Date: Tue, 25 Jun 2013 11:59:20 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: tls@ietf.org References: <20130625155822.26223.29007.idtracker@ietfa.amsl.com> In-Reply-To: <20130625155822.26223.29007.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20130625155822.26223.29007.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [173.73.135.101]:57149 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 8 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [TLS] Fwd: Last Call: (ECC Brainpool Curves for Transport Layer Security (TLS)) to Informational 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, 25 Jun 2013 15:59:37 -0000 Some on this list might find this of interest. spt -------- Original Message -------- Subject: Last Call: (ECC Brainpool Curves for Transport Layer Security (TLS)) to Informational RFC Date: Tue, 25 Jun 2013 08:58:22 -0700 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: - 'ECC Brainpool Curves for Transport Layer Security (TLS)' as Informational 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-07-23. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies the use of several ECC Brainpool curves for authentication and key exchange in the Transport Layer Security (TLS) protocol. The file can be obtained via http://datatracker.ietf.org/doc/draft-merkle-tls-brainpool/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-merkle-tls-brainpool/ballot/ No IPR declarations have been submitted directly on this I-D. From omh1835@g.rit.edu Tue Jun 25 09:56:01 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 E398021F972E for ; Tue, 25 Jun 2013 09:55:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.077 X-Spam-Level: X-Spam-Status: No, score=-0.077 tagged_above=-999 required=5 tests=[FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rcWsLsZ7zoGl for ; Tue, 25 Jun 2013 09:55:52 -0700 (PDT) Received: from sc3app27.rit.edu (sc3app27.rit.edu [129.21.35.56]) by ietfa.amsl.com (Postfix) with ESMTP id 23C5C21F91BC for ; Tue, 25 Jun 2013 09:55:51 -0700 (PDT) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by smtp-server.rit.edu (PMDF V6.3-x14 #31420) with ESMTPS id <0MOY00GICKD26Y@smtp-server.rit.edu> for tls@ietf.org; Tue, 25 Jun 2013 12:55:51 -0400 (EDT) Received: by mail-ie0-f175.google.com with SMTP id a13so27236152iee.6 for ; Tue, 25 Jun 2013 09:55:50 -0700 (PDT) Received: by 10.43.115.3 with HTTP; Tue, 25 Jun 2013 09:55:49 -0700 (PDT) X-Received: by 10.42.95.208 with SMTP id g16mr14393471icn.45.1372179350199; Tue, 25 Jun 2013 09:55:50 -0700 (PDT) X-Received: by 10.42.95.208 with SMTP id g16mr14393460icn.45.1372179350068; Tue, 25 Jun 2013 09:55:50 -0700 (PDT) Date: Tue, 25 Jun 2013 19:55:49 +0300 From: "OMAR HASSAN (RIT Student)" In-reply-to: <2A0EFB9C05D0164E98F19BB0AF3708C711B251F1E5@USMBX1.msg.corp.akamai.com> Sender: omh1835@rit.edu To: "Salz, Rich" , =?ISO-8859-1?Q?Juho_V=E4h=E4=2DHerttua?= , "Stephan T." , Paras Shah Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary=20cf303636fbbabf8a04dffd660d X-RIT-Received-From: 209.85.223.175 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=SDhWEPR6xYKbyDmEUfg5sBQe3LRsoMMmoaq0qv1L834=; b=XSeC6GhyWN07sL+jLTNkIyOei5yg+9AjDkyIqqU0i4mnnxNYnWCE+JSH0XfahJSLPr tRe7/vz8xOG+slyZTUUivucM6+T1wFXhZ9PKaDYGACYnaBrHQUyYwxzl0VsWq6T6pWxK SPgGgkQVHoeT36UAB5EdOYR7a+hi9/3xQ1tY76eVHdlp7koprdZ8fzVlk0+5GrbfLKfz t8gWPyupkraCvUeDenw9SKES0GwUd8kXAmZzPbm3tXzVuqrQsozpbGFz9AJOCC82n8nd SGjOaBXppWK7i23c/weRp5o7pwGXdSXUVnoVTXWWRAj6epBmjs/JVucmSIQHnG5DLbLE /SCQ== X-Google-Sender-Auth: 8uxKhvt5yBxiWZ8vXcpZ4OY3BGY X-Gm-Message-State: ALoCoQncpEiMyfJYoHjAg29dnlfMV2CWtls3kBBtzSeLYibmkjWRukXrB/iDLKiK8etKkDamkuVzK+amqqbrNsITRseHBTaiphQj3+R8Y+G0zduOIq5fXUgizB4j9rnbNnBhbKU5K7GQ References: <2A0EFB9C05D0164E98F19BB0AF3708C711B251EE97@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EF0E@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EFFF@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251F1E5@USMBX1.msg.corp.akamai.com> Cc: "tls@ietf.org" Subject: Re: [TLS] User Defined Key Pair 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, 25 Jun 2013 16:56:01 -0000 --20cf303636fbbabf8a04dffd660d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi All >Stephan: >How you made sure that the user (client) is connected with the intended server? >Paras Shah: >That is exactly the question I had. How is Server Authentication done with this approach? >Rich: >I don=92t see anything in your system that prevents this, either. It seem= s that replacing your system with self-signed client >certificates would be equivalent. >Robert: >As the proposal has no server authentication, it is surely broken in that respect i.e. the client could be lured to any bogus >website masquerading as a legitimate one. How would the client know? I would explain How is Server Authentication done with a practical example. Let's name facebook as our website that we need to protect using that new protocol. When I go to facebook, I would receive a browser message telling me: "Please use the UDKP protected access (Tools->UDKP Protected Access)!" the user will go to the plugin interface, and provide the username, password, password confirmation, the plugin will create a file with random data stream in the user's usb, and then the user will click on the register button. At that point the plugin will create the key pair based on the random file, username, and password. The public key will go to the server with the username and a signed message, and the user will be redirected to the facebook registration page to complete his registration. Now the user profile is created on facebook and associated with the user public key. When the user tries to sign in later into facebook, and if he was deceived to sign in into a fake website, the user will go to the browser plugin interface, and provide the username, password, and select the file from his usb. At that point the user will be expecting to see his facebook timeline if he is really signing into the real facebook. Note that the user didn't provide the credential information to the website but to the browser plugin (Tools->UDKP Protected Access). In our case, the fake website will only receive the username, the public key, and the token (ServerHello.random ) signed with user private key, If the attacker delivered this message to the facebook server, the server will try to read and validate the token using the user public key. If it succeeds, it will respond with the session key premaster encrypted by the user public key. Because the user private key did not leave the browser, the attacker will not be able to read the session key and hence will not be able to monitor the traffic. So if the user was successfully able to see his timeline, he would be sure that he is communicating with the real facebook. >Robert: >Token =3D enc(ServerHello.random, PrivKey) : The concept of encrypting usi= ng a private key seems pointless. Don't you mean >signing? Yes Robert, I mean signing not encrypting. Actually someone told me before about that mistake in the previous version, but unfortunately I forgot to correct it in the new version. Hopefully in the next version it will be corrected. Thank You. >Juho V=E4h=E4-Herttua: >The whole security of the system seems to be dependant on the security of the "browser plugin" and its key generation and encryption algorithms I preferred to make the generation of the key pair as a black box, so we can focus our discussion on the idea itself, so the question is if we have a key generation function that can generate key pair securely based on the username, password, and the file selected, would the idea be a good one. >What if someone detects this enrollment and sends a new public key for the user before the user has time to fill all the fields? Sounds like a race condition to me. The key pair generation is done inside the browser plugin interface, not in the website page, so there is no race condition, the communication with the website will start after the creation of the key pair. >I don't see how this is different from generating a self signed client cert and verifying it with for example HMAC with username+password+question derived secret. If you already need a custom >browser >plugin to handle the login, you can put all your custom logic there and use standard TLS for the rest. You can look at the generated key pair as a client certificate, but I preferred to make it as a key pair, so this key pair could be generated based on different approaches: security question, file, smart card, hardware token. Additionally it's not only about custom sign in, it's also about eliminating the dependence on the CA, so the session key must be encrypted with the user public key not encrypted with a key that claims to be the server public key. >Rich: >It=92s great that you are trying to improve things; don=92t get discourage= d, but this ain=92t there yet. And as a first step to replacing all of SSL/TLS? Nope. I am not discouraged at all, but I am still insisting that the security of my traffic to facebook must be the responsibility of me and facebook only, and not anyone else. And I am doing my best to achieve that. The discussion is very useful to me, may be after this discussion we can come out with a new final solution to this issue. On Tue, Jun 25, 2013 at 2:29 PM, Salz, Rich wrote: > **=D8 **Self signed certificate is very dangerous because the user will > not have a way to verify the identity of the certificate owner and he cou= ld > be a victim to a man in the middle attack.**** > > ** ** > > I don=92t see anything in your system that prevents this, either. It see= ms > that replacing your system with self-signed client certificates would be > equivalent.**** > > ** ** > > It=92s great that you are trying to improve things; don=92t get discourag= ed, > but this ain=92t there yet. And as a first step to replacing all of > SSL/TLS? Nope.**** > > ** ** > > /r$**** > > ** ** > > -- **** > > Principal Security Engineer**** > > Akamai Technology**** > > Cambridge, MA**** > > ** ** > --20cf303636fbbabf8a04dffd660d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi All

>Stephan:
>How you made sure that t= he user (client) is connected with the intended server?
>Paras Shah:<= br>>That is exactly the question I had. How is Server Authentication don= e with this approach?
>Rich:
>I don=92t see anything in your system that prevents this, = either. =A0It seems that replacing your system with self-signed client=A0&g= t;certificates would be equivalent.

>Robert:
>As the propos= al has no server authentication, it is surely broken in that respect i.e. t= he client could be lured to any bogus=A0>website masquerading as a legit= imate one. How would the client know?

I would explain=A0How is Server Authentication done=A0with a practical = example. Let's name facebook as our website that we need to protect usi= ng that new protocol.

When I go to facebook, I would receive a brows= er message telling me: "Please use the UDKP protected access (Tools-&g= t;UDKP Protected Access)!"
the user will go to the plugin interface, and provide the username, passwor= d, password confirmation, the plugin will create a file with random data st= ream in the user's usb, and then the user will click on the register bu= tton.

At that point the plugin will create the key pair based on the random f= ile, username, and password. The public key will go to the server with the = username and a signed message, and the user will be redirected to the faceb= ook registration page to complete his registration.

Now the user profile is created on facebook and associated with th= e user public key.

When the user tries to sign in later into = facebook, and if he was deceived to sign in into a fake website, the user w= ill go to the browser plugin interface, and provide the username, password,= and select the file from his usb. At that point the user will be expecting= to see his facebook timeline if he is really signing into the real faceboo= k. Note that the user didn't provide the credential information to the = website but to the browser plugin (Tools->UDKP Protected Access).

In our case, the fake website will only receive the username, the = public key, and the token (ServerHello.random ) signed with user private ke= y,=A0If the attacker delivered this message to the facebook server, the=A0s= erver will try to read and validate the token using the user public key. If= it succeeds, it=A0will respond with the session key premaster encrypted by= the user public key. Because=A0the user private key did not leave the brow= ser, the attacker will not be able to read the=A0session key and hence will= not be able to monitor the traffic.

So if the user was successfully able to see his timeline, he= would be sure that he is communicating with the real facebook.

>= Robert:
>Token =3D enc(ServerHello.random, PrivKey) : The concept of = encrypting using a private key seems pointless. Don't you mean >sign= ing?

Yes Robert, I mean signing not=A0encrypting.=A0Actually someone told me= before about that mistake in the previous version, but unfortunately I for= got to correct it in the new version. Hopefully in the next version it will= be corrected. Thank You.

>Juho V=E4h=E4-Herttua:
>The whole security of the system seem= s to be dependant on the security of the "browser plugin" and its= key generation and encryption algorithms

I preferred to = make the generation of the key pair as a black box, so we can focus our dis= cussion on the idea itself, so the question is if we have a key generation = function that can generate key pair securely based on the username, passwor= d, and the file selected, would the idea be a good one.

>What if someone detects this enrollment and sends a new public= key for the user before the user has time to fill all the fields? Sounds l= ike a race condition to me.

The key pair generation is do= ne inside the browser plugin interface, not in the website page, so there i= s no race condition, the communication with the website will start after th= e creation of the key pair.

>I don't see how this is different from generating a self signed= client cert and verifying it with for example HMAC with username+password+= question derived secret. If you already need a custom >browser=A0
>plugin to handle the login, you can put all your custom logic ther= e and use standard TLS for the rest.

You can look at the = generated key pair as a client certificate, but I preferred to make it as a= key pair, so this key pair could be generated based on different approache= s: security question, file, smart card, hardware token.

Additionally it's not only about custom sign in, it'= s also about eliminating the dependence on the CA, so the session key must = be encrypted with the user public key not encrypted with a key that claims = to be the server public key.

>Rich:
>It=92s great that you are trying to improve things; do= n=92t get discouraged, but this ain=92t there yet.=A0 And as a first step t= o replacing all of SSL/TLS?=A0 Nope.

I am not discouraged at all, bu= t I am still insisting that the security of my traffic to facebook must be = the responsibility of me and facebook only, and not anyone else. And I am d= oing my best to achieve that. The discussion is very useful to me, may be a= fter this discussion we can come out with a new final=A0solution=A0to this = issue.


On Tue,= Jun 25, 2013 at 2:29 PM, Salz, Rich <rsalz@akamai.com> wrote= :

=D8=A0 Self signed certificate i= s very dangerous because the user will not have a way to verify the identit= y of the certificate owner and he could be a victim to a man in the middle = attack.

=A0<= /p>

I don=92t see anything= in your system that prevents this, either.=A0 It seems that replacing your= system with self-signed client certificates would be equivalent.=

=A0<= /p>

It=92s great that you = are trying to improve things; don=92t get discouraged, but this ain=92t the= re yet.=A0 And as a first step to replacing all of SSL/TLS?=A0 Nope.=

= =A0

=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /r$

=A0<= /p>

--=A0

Principal Security Engine= er

Cambridge, MA

=A0


--20cf303636fbbabf8a04dffd660d-- From Paras.Shah@riverbed.com Mon Jun 24 22:25:48 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 D82CE21F9F53 for ; Mon, 24 Jun 2013 22:25:48 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4GzltnwXRNyY for ; Mon, 24 Jun 2013 22:25:44 -0700 (PDT) Received: from smtp1.riverbed.com (eng.riverbed.com [208.70.196.45]) by ietfa.amsl.com (Postfix) with ESMTP id DC21321F9EFD for ; Mon, 24 Jun 2013 22:25:44 -0700 (PDT) Received: from unknown (HELO 365EXCH-HUB-P3.nbttech.com) ([10.16.4.1]) by smtp1.riverbed.com with ESMTP; 24 Jun 2013 22:25:44 -0700 Received: from 365EXCH-MBX-P3.nbttech.com ([fe80::d453:ae2c:3b65:50e5]) by 365EXCH-HUB-P3.nbttech.com ([::1]) with mapi id 14.02.0328.009; Mon, 24 Jun 2013 22:25:44 -0700 From: Paras Shah To: Stephan T. , "OMAR HASSAN (RIT Student)" , "tls@ietf.org" Thread-Topic: [TLS] User Defined Key Pair Thread-Index: AQHObq4khJkyicCAKkOjssuh7VsnkZlGYHcA//+K6OA= Date: Tue, 25 Jun 2013 05:25:44 +0000 Message-ID: <377FB9023E313048955F1A4A54DB21009A5670B6@365EXCH-MBX-P3.nbttech.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.16.205.249] Content-Type: multipart/alternative; boundary="_000_377FB9023E313048955F1A4A54DB21009A5670B6365EXCHMBXP3nbt_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 25 Jun 2013 10:50:59 -0700 Subject: Re: [TLS] User Defined Key Pair 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, 25 Jun 2013 05:26:47 -0000 --_000_377FB9023E313048955F1A4A54DB21009A5670B6365EXCHMBXP3nbt_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable That is exactly the question I had. How is Server Authentication done with = this approach? From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Steph= an T. Sent: Monday, June 24, 2013 10:24 PM To: OMAR HASSAN (RIT Student); tls@ietf.org Subject: Re: [TLS] User Defined Key Pair Hi, How you made sure that the user (client) is connected with the intended ser= ver? -Stephan Am 21.06.2013 um 20:35 schrieb OMAR HASSAN (RIT Student) >: Hello All, I have uploaded a new version of the User Defined Key pair protocol that is= cleaner and briefer, I will appreciate any comments or suggestions. Just to remind you: http://tools.ietf.org/html/draft-omar-tls-udkp-01 The new protocol is a new way of securing the traffic to websites without b= eing depending on any third party to secure the traffic between the user an= d the website, so it will be possible for the user to secure his browsing u= sing his credential information, smart card, or a random file on usb. That = will make the use of two factor for authentication and traffic security is = separated from the application code, the website admin only needs to config= ure how the users are going to access the website. Additionally there are n= o passwords required to be transferred any more on the network, which will = render the Phishing attack useless. The motivation behind the new protocol is to make the security the responsi= bility of the two involved parties, because as you know, the security and c= onfidentiality of user browsing in TLS depend upon the number of Certificat= e Authorities (CAs), major web browsers trust hundreds of different firms to issue certificates. Each of these firms can be compelled by their national government, or being compromised t= o issue a certificate for any particular website that all web browsers will= trust without warning.Thus, users around the world are put in a position w= here their browser entrusts their private data, indirectly, to a large numb= er of governments, and entities. (http://cryptome.org/ssl-mitm.pdf) Thank You Best Regards _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls --_000_377FB9023E313048955F1A4A54DB21009A5670B6365EXCHMBXP3nbt_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

That is exactly the quest= ion I had. How is Server Authentication done with this approach?=

 <= /p>

From: tls-boun= ces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Stephan T.
Sent: Monday, June 24, 2013 10:24 PM
To: OMAR HASSAN (RIT Student); tls@ietf.org
Subject: Re: [TLS] User Defined Key Pair

 

Hi,

 

How you made sure that the user (client) is connecte= d with the intended server?

 

 

-Stephan

 

 

Am 21.06.2013 um 20:35 schrieb OMAR HASSAN (RIT Stud= ent) <omh1835@rit.edu>:



Hello All,

 

I have uploaded a new version of the User= Defined Key pair protocol that is cleaner and briefer, I will appreciate a= ny comments or suggestions. 

 

Just to remind you:

 

 

The new protocol is a new way of securing= the traffic to websites without being depending on any third party to secu= re the traffic between the user and the website, so it will be possible for the user to secure his browsing using his credential infor= mation, smart card, or a random file on usb. That will make the use of two = factor for authentication and traffic security is separated from the applic= ation code, the website admin only needs to configure how the users are going to access the website. Additionally t= here are no passwords required to be transferred any more on the network, w= hich will render the Phishing attack useless.

 

The motivation behind the new protocol is= to make the security the responsibility of the two involved parties, becau= se as you know, the security and confidentiality of user browsing in TLS depend upon the number of Certificate Authorities (CAs), m= ajor web browsers trust hundreds of different
firms to issue certificates. Each of these
firms can be compelled by their national government, or being compromised t= o issue a certificate for any particular website that all web browsers will= trust without warning.Thus, users around the world are put in a position w= here their browser entrusts their private data, indirectly, to a large number of governments, and entities. = (http://cryptome.org/ssl-mitm.pdf)

 

Thank You

Best Regards

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/= mailman/listinfo/tls

 

--_000_377FB9023E313048955F1A4A54DB21009A5670B6365EXCHMBXP3nbt_-- From prvs=9888b28b76=uri@ll.mit.edu Tue Jun 25 11:11:24 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 D457821E80AC for ; Tue, 25 Jun 2013 11:11:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.201 X-Spam-Level: X-Spam-Status: No, score=-5.201 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TFBw8geLz0SS for ; Tue, 25 Jun 2013 11:11:19 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 7EF3811E8127 for ; Tue, 25 Jun 2013 11:11:08 -0700 (PDT) Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r5PIAg3Y031704 for ; Tue, 25 Jun 2013 14:10:42 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: "tls@ietf.org" Date: Tue, 25 Jun 2013 14:10:39 -0400 Thread-Topic: [TLS] User Defined Key Pair Thread-Index: Ac5xz03cWpA1eA+cRGW/uIIR1hNMcQ== Message-ID: In-Reply-To: <377FB9023E313048955F1A4A54DB21009A5670B6@365EXCH-MBX-P3.nbttech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.5.130515 acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="B_3455014239_5335628" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-06-25_07:2013-06-25, 2013-06-25, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1306250145 Subject: Re: [TLS] User Defined Key Pair 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, 25 Jun 2013 18:11:24 -0000 --B_3455014239_5335628 Content-type: multipart/alternative; boundary="B_3455014239_5359220" --B_3455014239_5359220 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable >From the answers provided so far, it looks like there is no server authentication. So if you pretend to be a server, get user name and password, then pretend to be that user to, e.g., Facebook =AD you should get complete access, including the ability to generate your own key pair. :) I'd much prefer dependence on a 3rd party =AD Certificate Authority, to be precise. -- Regards, Uri Blumenthal From: Paras Shah Date: Tuesday, June 25, 2013 1:25 To: "Stephan T." , "OMAR HASSAN (RIT Student)" , "tls@ietf.org" Subject: Re: [TLS] User Defined Key Pair > That is exactly the question I had. How is Server Authentication done wit= h > this approach? > =20 >=20 > From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Ste= phan > T. > Sent: Monday, June 24, 2013 10:24 PM > To: OMAR HASSAN (RIT Student); tls@ietf.org > Subject: Re: [TLS] User Defined Key Pair > =20 >=20 > Hi, >=20 > =20 >=20 > How you made sure that the user (client) is connected with the intended > server? >=20 > =20 >=20 > =20 >=20 > -Stephan >=20 > =20 > =20 >=20 > Am 21.06.2013 um 20:35 schrieb OMAR HASSAN (RIT Student) : >=20 >=20 > Hello All, >=20 > =20 >=20 > I have uploaded a new version of the User Defined Key pair protocol that = is > cleaner and briefer, I will appreciate any comments or suggestions. >=20 > =20 >=20 > Just to remind you: >=20 > =20 >=20 > http://tools.ietf.org/html/draft-omar-tls-udkp-01 > >=20 > =20 > The new protocol is a new way of securing the traffic to websites without > being depending on any third party to secure the traffic between the user= and > the website, so it will be possible for the user to secure his browsing u= sing > his credential information, smart card, or a random file on usb. That wil= l > make the use of two factor for authentication and traffic security is > separated from the application code, the website admin only needs to conf= igure > how the users are going to access the website. Additionally there are no > passwords required to be transferred any more on the network, which will > render the Phishing attack useless. >=20 > =20 >=20 > The motivation behind the new protocol is to make the security the > responsibility of the two involved parties, because as you know, the secu= rity > and confidentiality of user browsing in TLS depend upon the number of > Certificate Authorities (CAs), major web browsers trust hundreds of diffe= rent > firms to issue certificates. Each of these > firms can be compelled by their national government, or being compromised= to > issue a certificate for any particular website that all web browsers will > trust without warning.Thus, users around the world are put in a position = where > their browser entrusts their private data, indirectly, to a large number = of > governments, and entities. (http://cryptome.org/ssl-mitm.pdf > ) >=20 > =20 >=20 > Thank You >=20 > Best Regards > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > =20 --B_3455014239_5359220 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable
From the answers p= rovided so far, it looks like there is no server authentication. So if you p= retend to be a server, get user name and password, then pretend to be that u= ser to, e.g., Facebook – you should get complete access, including the= ability to generate your own key pair. :)

I'd much= prefer dependence on a 3rd party – Certificate Authority, to be preci= se.
--
Regards,<= /font>
Uri Blumenthal

From: Paras Shah <= Paras.Shah@riverbed.com>
= Date: Tuesday, June 25, 2013 1:25 To: "Stephan T." <rheoli08@gmail.com>, "OMAR HASSAN (RIT Student)"= <omh1835@rit.edu>, "tls@ietf.org" <tls@ie= tf.org>
Subject: Re: [TLS] = User Defined Key Pair

That is ex= actly the question I had. How is Server Authentication done with this approa= ch?

 

From: tls-bounces@ietf.org [mailto:= tls-bounces@ietf.org] On Behalf Of Stephan T.
Sent: Monday, June 24, 2013 10:24 = PM
To: OMAR HASSAN (RIT Student); tl= s@ietf.org
Subject: Re: [TLS] User Defined Key Pair=

 

Hi,

 =

How you made sure that the user (c= lient) is connected with the intended server?

 

&n= bsp;

-Stephan

<= div>

 

 

Am 21.06.2013 um 20:35 schr= ieb OMAR HASSAN (RIT Student) <omh1835@r= it.edu>:



=

Hello All,

 

I have uploaded a new ve= rsion of the User Defined Key pair protocol that is cleaner and briefer, I w= ill appreciate any comments or suggestions. 

 

Just to = remind you:

 

 = ;

The new protocol is a new way of securing t= he traffic to websites without being depending on any third party to secure = the traffic between the user and the website, so it will be possible for the user to secure his browsing using his credential infor= mation, smart card, or a random file on usb. That will make the use of two f= actor for authentication and traffic security is separated from the applicat= ion code, the website admin only needs to configure how the users are going to access the website. Additionally t= here are no passwords required to be transferred any more on the network, wh= ich will render the Phishing attack useless.

 

The motivation= behind the new protocol is to make the security the responsibility of the t= wo involved parties, because as you know, the security and confidentiality o= f user browsing in TLS depend upon the number of Certificate Authorities (CAs), m= ajor web browsers trust hundreds of different
firms to issue certificates. Each of these
firms can be compelled by their national government, or being compromised t= o issue a certificate for any particular website that all web browsers will = trust without warning.Thus, users around the world are put in a position whe= re their browser entrusts their private data, indirectly, to a large number of governments, and entities. = (h= ttp://cryptome.org/ssl-mitm.pdf)

 

<= span style=3D"font-size: 10pt; font-family: Arial, sans-serif; ">Thank You

Best Regards

_______________________________________________=
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/= listinfo/tls

 <= /p>

 --B_3455014239_5359220-- --B_3455014239_5335628 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUAAYJKoZIhvcNAQcCoIIT8TCCE+0CAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC EeMwggTLMIIDs6ADAgECAgpmZ8V6AAAAAG/eMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYT AlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzAR BgNVBAMTCk1JVExMIENBLTIwHhcNMTMwNjA1MTc0ODU1WhcNMTQwNjA1MTc0ODU1WjBhMQsw CQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMG UGVvcGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcN AQEBBQADggEPADCCAQoCggEBAPSnGt5QombPdxg5uPBypdpPJQLMDBdN4HsEAEMiikMXTB8I cQCF/eVkJ+1BG2s3qVy+TZ3nfQRJzTSrXVvAWOKJ+lMZVMmjGK6YdWAUidYesQJ5DLQH0FYz heJZjcxe+oWOxAnweapBMaouT37T/j8LIRcSfA2oBY1gDYra4ta4lv9ZKKKbF9wFz+msif45 uwimQOcAIbaNZGQTjUaSVyZpN7FRNB60ZEVV9jCsLvf7gRCzfYgoNWcn5F3b/KrAeCuLSQ3B Hy27/moi7HiPRhUDC5xAXjcyPYuZWHAKofEebiZVUlBAsmRLlkD3DJwrLN7cWbuTqHzXWLuV pgpaLK8CAwEAAaOCAZMwggGPMB0GA1UdDgQWBBTGSturL6AljPoqmVj9VAmKAs27MzAOBgNV HQ8BAf8EBAMCBsAwHwYDVR0jBBgwFoAUjkp9iaFjFxyBiDRXNyZFXhmKfiQwMwYDVR0fBCww KjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9MTENBMjBiBggrBgEFBQcB AQRWMFQwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0by9MTENBMjAj BggrBgEFBQcwAYYXaHR0cDovL29jc3AubGwubWl0LmVkdS8wDAYDVR0TAQH/BAIwADA9Bgkr BgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIB ZAIBBTAiBgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0G CyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MA0GCSqGSIb3DQEBCwUA A4IBAQBSl+lHVJr2cievd1UM4y8ZzGDsbAd1KgIP3EJNd8/GoCTMjdR06bp8s9QTtZ1e1ouy gidYgr+A/a5FM41Q1tRJwfbWJr4nRSNmPm3ZxtT5qR59CR6hthcYCxrUHEgVKNpFCuqgu5mh x5/a63wWMV6JT5iY0fgMAwaq1yDnhirk9N0tXNkom/xnq+wlVxaBv+ks0hnZ0HJvwrnjwD+u NR4lwEv8bLQS95RgkBZNC9sKNnAUV25t+Og8O7aoW6GACECURH9/NNyrltqmNid8Qdn9jHpO aDmFSXnM2Gvp1BjunfJv6SgiJPPuAkJAVz8VlIbF8PhJw9OcIlleEw8U5RtIMIIEtzCCA5+g AwIBAgIBFDANBgkqhkiG9w0BAQsFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExp bmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRMTCBSb290IENB MB4XDTA5MTIxNDEyMDAwMFoXDTE1MTIzMTIzNTk1OVowUTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UEAxMKTUlU TEwgQ0EtMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKcEyyNhSIfsN6AzBwVh Zkzo6SdjNGAQ7mA2A8T0kmdCB8MH6jWjVVMwFZwlg9cgjgLKEuEO9KN8K9M8jgeZEMoinlRf k3YELPC7sEkkzBQkcVpLhEwALue9iHowgSLGmXZpYKmRhfvhvYJ4MNCuIaWpcK/GaDZCE+U2 aTg42kv/zQrH3AoqFX81OF7niwXNnanP1hQRfkMTRrnaEW8DX0TMaG/t9Ry5xSMrLTNc9DvQ tjA5ZcuWnECiUpyDBFWxLr9yx7xgf1/LwgCxcoBeKSBBoWzkQmKAsgMo9Mq1Fp/nnIqw5FKm gOs7Vy+6e0Dk+cgf+oAV8AK8ZFMQrVE0uH0CAwEAAaOCAZUwggGRMBIGA1UdEwEB/wQIMAYB Af8CAQAwHQYDVR0OBBYEFI5KfYmhYxccgYg0VzcmRV4Zin4kMB8GA1UdIwQYMBaAFGeqes/0 Cqa5crWKoNKd8hDDQ+0pMA4GA1UdDwEB/wQEAwIBhjBhBggrBgEFBQcBAQRVMFMwLQYIKwYB BQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0bz9MTFJDQTAiBggrBgEFBQcwAYYW aHR0cDovL29jc3AubGwubWl0LmVkdTAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxs Lm1pdC5lZHUvZ2V0Y3JsP0xMUkNBMIGSBgNVHSAEgYowgYcwDQYLKoZIhvcSAgEDAQYwDQYL KoZIhvcSAgEDAQgwDQYLKoZIhvcSAgEDAQcwDQYLKoZIhvcSAgEDAQkwDQYLKoZIhvcSAgED AQowDQYLKoZIhvcSAgEDAQswDQYLKoZIhvcSAgEDAQ4wDQYLKoZIhvcSAgEDAQ8wDQYLKoZI hvcSAgEDARAwDQYJKoZIhvcNAQELBQADggEBAIh3BqHQ/XH8C6DCL+eEGroOzxBcCqTNItms v4MANaOTodgU2jrjHcGjXlzqhpb8ZxOlkAK3dK09rc6+yACcoK2TzVtDRZXYxov/SqZRjI3d ufU2JatAPxosCyy/1otjl1TKUY47Wvft31vdf5i0XK2DQVEJ+XlqtgBiFTVIMIfBJwPajrsi z+pgFEYwhhwJxvs8flSi0FLCE77VYLEioP5hxG6zIPeQRxzh1bogbfphWHHtoiTDkBSZ4Ufv GXQTVf7QjhD5yYw10yICtjHmtgbfgBkH5/vvR92NY9RSlNPzZqmGKIia61bJCmagRYGyexfe dVNF0cJWL4J/cLHhgNYwggODMIICa6ADAgECAgEBMA0GCSqGSIb3DQEBBQUAMFQxCzAJBgNV BAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kx FjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMDgwOTIzMTIwMDAwWhcNMjkxMjMxMjM1OTU5 WjBUMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECxMDUEtJMRYwFAYDVQQDEw1NSVRMTCBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAxU4pF1iyJrL5rYq/XBAKg93kCTATG7Bw0NGFpEJ1A3Xsr6UIIq9/1VJB OgCwDqrVsAK1lRwy/lkrHzPkobiMr1wzjQ28SR/9sg5kAcmrMqBYbc302qtwCGKZxdNdhAh2 nUOCO10AMpUsCNdpikPY9ukT8lsA+eorM4Q1rc/L0J6AHRptOU7IuDBdZj+tdNb7gv+GKknr 6wj9m2sVGawoaG7AAqhsWvQUM/q4h/H5FpYlwnVAEh2AzhqiG9bwl6uJJIzJ/8uUWldNkVwz 1I5fR/vCaxiLXIW4oUydBuRKTG+ekEoxHGuD73yx5JtsSciS8HQL2oEM8tv+VAC+albqgwID AQABo2AwXjAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBRnqnrP9AqmuXK1iqDSnfIQw0Pt KTAfBgNVHSMEGDAWgBRnqnrP9AqmuXK1iqDSnfIQw0PtKTALBgNVHQ8EBAMCAYYwDQYJKoZI hvcNAQEFBQADggEBAD4bbQVg0Hh42EpYX4/JPkNS3OUAEWR/YgzZUY1QGi9rQZ4pfcjU1/Ta oNT8Y7Yf0RO+e9NiG9+BDhQH/kQiZOQo9rv9NUb8xDtKCYCad7zEQtVsYsWuvK2XLw/Ji1m2 eBvoOB4RS/5LAWfNws7W+DWt2ayzeTCyrLSrx7ZVgBjzNOm0TPIkbfppdwgxuo7FZL8ts+M2 492Al87d3VasevUS1pprRBEupChmPTt1hjtajkQOpT4BQAzP1lVEYrWzlv+O/lbP9iujKpYW cfYqQ3FGf37YCvuDeues4xm+nqmyraNsNeI8Gh3XDIwqfzHnLhy4Y80VyqN/Jj8df3SK9AAw ggTOMIIDtqADAgECAgotG3zZAAAAAGEIMA0GCSqGSIb3DQEBCwUAMFExCzAJBgNVBAYTAlVT MR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNV BAMTCk1JVExMIENBLTIwHhcNMTMwMjI4MTYxNzE0WhcNMTQwMjI4MTYxNzE0WjBhMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEPMA0GA1UECxMGUGVv cGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBAKqBBolHee6vD9MHUabfJF7N5ihzoFeF22f1lOhaMkDTjhfnX1ok EqdbJWkt1OAYyZPW5fjxBCspPpZPpDIio+Wk+pmmr0TH5k8o59uTkmXU/DlKdx4VlBvPUQgy C/Pwlfa+F8yuvoMIOTVghBj4X2jH+JNlOUvBa2GeivoWE0tYLPRGD53kg+tNZ9PNZKfDvWFB vqJjzGau0InmeMYlRTHVnrFDi/bq9K8AYuqD02wAd1oe5CRMITMMjJFn1DN8Dz4G2LewHjTI dJOA5ETUFDXBrn4LDKK0erixJvw05bjW1DQ6cT5Av6tb1qcliRs7MFYe8xtaCjenVDwHzIa5 mWcCAwEAAaOCAZYwggGSMB0GA1UdDgQWBBR1u20OHEJuT+BUv/SBxvcJqBCQdDAOBgNVHQ8B Af8EBAMCBSAwHwYDVR0jBBgwFoAUjkp9iaFjFxyBiDRXNyZFXhmKfiQwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9MTENBMjBiBggrBgEFBQcBAQRW MFQwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0by9MTENBMjAjBggr BgEFBQcwAYYXaHR0cDovL29jc3AubGwubWl0LmVkdS8wDAYDVR0TAQH/BAIwADA9BgkrBgEE AYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2F69Bwg+vtIAIBZAIB BDAlBgNVHSUEHjAcBgRVHSUABggrBgEFBQcDBAYKKwYBBAGCNwoDBDAYBgNVHSAEETAPMA0G CyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MA0GCSqGSIb3DQEBCwUA A4IBAQBYeIF41hjw8gdOyDV/I5fwTc+mc+Iq9HI2lgRDb1lZ+BwRmj04q3J6q57Xi+f63aNZ Gn5ztdC+bLQlRk7xnPdEUV+N7NMt9josIVaW0mhHAZlHKFELRJY4SxHNwUqtgUH9Ll81iNXr 0h31QI1KeVJROv43FtUhzN+z1OVtiy2NqaWV+uaz5ceHMf/F8tDhsHwc53G6eWCyoFTeNLsf uGlp8FtaEvUy3nrzmkBuPWFIBXLht3UmQlJaLs7ozkJrgpGnuXRdJlfoC7mHp6jLwhBoLnG3 FU1JRNZIjrKygfQDPJlQf2dK7eI4z6wxjMoQ2qKOT+nMzu8IMRvz0zhLl9+GMYIB5TCCAeEC AQEwXzBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEM MAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0yAgpmZ8V6AAAAAG/eMAkGBSsOAwIa BQCgXTAjBgkqhkiG9w0BCQQxFgQUCGb+dITBYLS8dS9/Y8RAYXrdzSowGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTMwNjI1MTgxMDM5WjANBgkqhkiG9w0B AQEFAASCAQAUCnwpktqQ6n05DP5Fs29G/sHOSJKgNh8iLGlhfU2m3qVKmzOH5d/Xiq1wYDGN pd52zlxiMNENsj3TVk0X8EsTKBcuGY3khYhZBKKDJB9vOwxBz/LI2FqHsoguMIDliTNBHT6u WxygNjyIWjrhXqxUF+m0/kZJjvm/EcvpC0Ssi2wLYZv744Jyipe5iQjdEaLPM1Z0TSGtV2cR vOkM+4M1RF7gPqmkLbF/Esx4UxNZ43Nvq2VFdH7Ew5hAx6rtbKzIsPbJ6AdiYl4kMWFfjqFv lJ7HzVH1UohWUG1USyc0cKbJmG5Ge9/po/F4jhineSrov66WOpixpnTorto9CtCj --B_3455014239_5335628-- From trevp@trevp.net Tue Jun 25 11:24:57 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 56DDA11E8135 for ; Tue, 25 Jun 2013 11:24:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.48 X-Spam-Level: X-Spam-Status: No, score=0.48 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BByu79DwhUPv for ; Tue, 25 Jun 2013 11:24:53 -0700 (PDT) Received: from mail-wg0-x22b.google.com (mail-wg0-x22b.google.com [IPv6:2a00:1450:400c:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id B9F5421E80C2 for ; Tue, 25 Jun 2013 11:24:16 -0700 (PDT) Received: by mail-wg0-f43.google.com with SMTP id z11so9473195wgg.34 for ; Tue, 25 Jun 2013 11:23:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-originating-ip:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=+mEsZ1BzjyqnTG5UK5MoER3dA0aqR3s13k81ajb+0DQ=; b=B88F5VBcq9cTkfpsSfh9Ph1MnRtWu6i+oMhdhSg3jb9V2+Tx5/8WVF5YPFZUpxcIxo 05fjO7CK/zXYcnM017vy5mTeW0FhQmpJ02Og86PaKU8PGTgDI7w6ZYEvQ+j45aK0lUZi skAvDaBlWltzawo5rhmoA8ZyRW9TWhyP1A59h+l6U3EAaEmujwHUb8tW2mUQyfUyJEaL qJ2N1GW1iuoynbj6816X6cC4fH8d19B+qcDS8vr8P/yga/Ls6Bj3BuDY8eVo/tOorlUe lVYMBu1WGq6WqQs6zZrfE0YJud4xOEdGXVEUPLgqOHZ3TnpySMw7SySeSxZjEnq6n5+i c85A== MIME-Version: 1.0 X-Received: by 10.194.24.40 with SMTP id r8mr261948wjf.7.1372184618199; Tue, 25 Jun 2013 11:23:38 -0700 (PDT) Received: by 10.216.212.9 with HTTP; Tue, 25 Jun 2013 11:23:38 -0700 (PDT) X-Originating-IP: [166.137.212.54] Date: Tue, 25 Jun 2013 11:23:38 -0700 Message-ID: From: Trevor Perrin To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7b5d3528bc002204dffea0f3 X-Gm-Message-State: ALoCoQlIGvqYnaONpBwa7pcqLmYqjIdNNp/J8skKFGrXOF96dPSR3R+fwAtqcj7nxg3/7J5d2ZhE Subject: [TLS] Requesting feedback on TACK draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 18:24:57 -0000 --047d7b5d3528bc002204dffea0f3 Content-Type: text/plain; charset=ISO-8859-1 Hi, The TACK draft [1] has been stable for a while (the last substantive change was draft-01, last September). We're hoping to see some deployment this year, so we may request "early allocation" [2] of a TLS ExtensionType in the next few months. Also, draft-02 will expire in a few weeks, so we may as well make a -03. So! The next couple weeks would be a great time to send us feedback. Anything is appreciated, but we'd particularly like to know if anything is confusing or hard to follow... Trevor [1] http://tools.ietf.org/html/draft-perrin-tls-tack-02 [2] http://www.rfc-editor.org/rfc/rfc4020.txt --047d7b5d3528bc002204dffea0f3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi,

The TACK = draft [1] has been stable for a while (the last substantive change was draf= t-01, last September).

We're hoping to see som= e deployment this year, so we may request "early allocation" [2] = of a TLS ExtensionType in the next few months.

Also, draft-02 will expire in a few weeks, so we may as= well make a -03.

So! =A0The next couple weeks wou= ld be a great time to send us feedback. =A0Anything is appreciated, but we&= #39;d particularly like to know if anything is confusing or hard to follow.= ..


Trevor

--047d7b5d3528bc002204dffea0f3-- From omh1835@g.rit.edu Tue Jun 25 12:07: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 0C5D221F99BC for ; Tue, 25 Jun 2013 12:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.881 X-Spam-Level: X-Spam-Status: No, score=-0.881 tagged_above=-999 required=5 tests=[AWL=0.804, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2oTWTetlbgQY for ; Tue, 25 Jun 2013 12:07:13 -0700 (PDT) Received: from sc3app27.rit.edu (sc3app27.rit.edu [129.21.35.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0263821F9AA9 for ; Tue, 25 Jun 2013 12:07:12 -0700 (PDT) Received: from mail-ie0-f181.google.com (mail-ie0-f181.google.com [209.85.223.181]) by smtp-server.rit.edu (PMDF V6.3-x14 #31420) with ESMTPS id <0MOY00AAXQFX9J@smtp-server.rit.edu> for tls@ietf.org; Tue, 25 Jun 2013 15:07:10 -0400 (EDT) Received: by mail-ie0-f181.google.com with SMTP id x12so27202799ief.26 for ; Tue, 25 Jun 2013 12:07:09 -0700 (PDT) Received: by 10.43.115.3 with HTTP; Tue, 25 Jun 2013 12:07:09 -0700 (PDT) X-Received: by 10.42.95.208 with SMTP id g16mr250890icn.45.1372187229637; Tue, 25 Jun 2013 12:07:09 -0700 (PDT) X-Received: by 10.42.95.208 with SMTP id g16mr250885icn.45.1372187229522; Tue, 25 Jun 2013 12:07:09 -0700 (PDT) Date: Tue, 25 Jun 2013 22:07:09 +0300 From: "OMAR HASSAN (RIT Student)" In-reply-to: Sender: omh1835@rit.edu Cc: "tls@ietf.org" Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary=20cf303636fb61ba3804dfff3c68 X-RIT-Received-From: 209.85.223.181 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:cc:content-type :x-gm-message-state; bh=IYqwxuG2B3ZhiWv5WWy4GQGcyI2vbz3dWoV7KSTJBsU=; b=cWpNSb5F+Fp7Vz3TOW+vcu/kadfYaiE6BoV1sHeICN/AtzTB7UBovPznJol3iz5b/H o6uMH2f85kl5dfISXaZQmLOFMVggXqVlvooq/wUUWLItsHvsvu428Ubpy5z71yO7+Aux 3f2LrcUElZLJMKt/o+oPEIFItugRGV6Vd0khRKrZx7sWpYV+7M7p3eNwV7kUY2HmoH6M W5e9l5bXjwv6lyyO2N2X9T7rOOtrD6l4cM+mdNDAYyUYPQBFINLq2gT5xNoZPYx1/e2N CCSDKOeKE8uQl/fKXFA4PlQfZ5/+RZO5LYqVoytxUMK7a6cbr6ae18tWUN56p7r+JyU1 u1DQ== X-Google-Sender-Auth: pHViRCv_OYbM94IlwX6eGWDzQIE X-Gm-Message-State: ALoCoQn6OMxN6N0VOi4UA1W033joavfG9r6UxpyN/ocuKEGtj28l6WRcxJV/XrERGCjisoNeoQC7WDFejcDYHcmLOvacOcXqrEVotWqelHV82NeQ8+Do+zsNpK9GCr9pCZPzXQbtmK7y References: <2A0EFB9C05D0164E98F19BB0AF3708C711B251EE97@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EF0E@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EFFF@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251F1E5@USMBX1.msg.corp.akamai.com> Subject: Re: [TLS] User Defined Key Pair 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, 25 Jun 2013 19:07:19 -0000 --20cf303636fb61ba3804dfff3c68 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Uri, May be I am still not able to clear my point regarding the man in the middle attack. When the user provides the credential information, he will not provide it to the Facebook log in page, instead he will go to the menu bar in his browser, and run the new plugin which has two tabs: one for log in; and the other for enrollment, and in the plugin interface the user will provide his credential information. The key pair will be generated inside the browser's plugin, and only the signed message, and the username will go to Facebook, no passwords will leave the user's browser. When the server receive the username and the signed message, it will send the session key encrypted with the user's public key. If someone pretended to be Facebook, he will receive a public key and a signed message. The attacker cannot use this information to log into Facebook, because the signed message contains the current server's time stamp, so it's valid only for a few seconds. And even if the attacker sends the signed message and the username to the server, and the server accepted them, the next step is that the server will respond with the session key encrypted with the user's public key. How the attacker will read the public key if he doesn't have the private key, the private key that didn't leave the user's browser. On Tue, Jun 25, 2013 at 7:55 PM, OMAR HASSAN (RIT Student) wrote: > Hi All > > >Stephan: > > >How you made sure that the user (client) is connected with the intended > server? > >Paras Shah: > > >That is exactly the question I had. How is Server Authentication done > with this approach? > >Rich: > > >I don=92t see anything in your system that prevents this, either. It se= ems > that replacing your system with self-signed client >certificates would be > equivalent. > > >Robert: > >As the proposal has no server authentication, it is surely broken in tha= t > respect i.e. the client could be lured to any bogus >website masquerading > as a legitimate one. How would the client know? > > I would explain How is Server Authentication done with a practical > example. Let's name facebook as our website that we need to protect using > that new protocol. > > When I go to facebook, I would receive a browser message telling me: > "Please use the UDKP protected access (Tools->UDKP Protected Access)!" > the user will go to the plugin interface, and provide the username, > password, password confirmation, the plugin will create a file with rando= m > data stream in the user's usb, and then the user will click on the regist= er > button. > > At that point the plugin will create the key pair based on the random > file, username, and password. The public key will go to the server with t= he > username and a signed message, and the user will be redirected to the > facebook registration page to complete his registration. > > Now the user profile is created on facebook and associated with the user > public key. > > When the user tries to sign in later into facebook, and if he was deceive= d > to sign in into a fake website, the user will go to the browser plugin > interface, and provide the username, password, and select the file from h= is > usb. At that point the user will be expecting to see his facebook timelin= e > if he is really signing into the real facebook. Note that the user didn't > provide the credential information to the website but to the browser plug= in > (Tools->UDKP Protected Access). > > In our case, the fake website will only receive the username, the public > key, and the token (ServerHello.random ) signed with user private key, If > the attacker delivered this message to the facebook server, the server wi= ll > try to read and validate the token using the user public key. If it > succeeds, it will respond with the session key premaster encrypted by the > user public key. Because the user private key did not leave the browser, > the attacker will not be able to read the session key and hence will not = be > able to monitor the traffic. > > So if the user was successfully able to see his timeline, he would be sur= e > that he is communicating with the real facebook. > > >Robert: > >Token =3D enc(ServerHello.random, PrivKey) : The concept of encrypting > using a private key seems pointless. Don't you mean >signing? > > Yes Robert, I mean signing not encrypting. Actually someone told me befor= e > about that mistake in the previous version, but unfortunately I forgot to > correct it in the new version. Hopefully in the next version it will be > corrected. Thank You. > > >Juho V=E4h=E4-Herttua: > > >The whole security of the system seems to be dependant on the security o= f > the "browser plugin" and its key generation and encryption algorithms > > I preferred to make the generation of the key pair as a black box, so we > can focus our discussion on the idea itself, so the question is if we hav= e > a key generation function that can generate key pair securely based on th= e > username, password, and the file selected, would the idea be a good one. > > >What if someone detects this enrollment and sends a new public key for > the user before the user has time to fill all the fields? Sounds like a > race condition to me. > > The key pair generation is done inside the browser plugin interface, not > in the website page, so there is no race condition, the communication wit= h > the website will start after the creation of the key pair. > > > >I don't see how this is different from generating a self signed client > cert and verifying it with for example HMAC with username+password+questi= on > derived secret. If you already need a custom >browser > >plugin to handle the login, you can put all your custom logic there and > use standard TLS for the rest. > > You can look at the generated key pair as a client certificate, but I > preferred to make it as a key pair, so this key pair could be generated > based on different approaches: security question, file, smart card, > hardware token. > > Additionally it's not only about custom sign in, it's also about > eliminating the dependence on the CA, so the session key must be encrypte= d > with the user public key not encrypted with a key that claims to be the > server public key. > > >Rich: > > >It=92s great that you are trying to improve things; don=92t get discoura= ged, > but this ain=92t there yet. And as a first step to replacing all of > SSL/TLS? Nope. > > I am not discouraged at all, but I am still insisting that the security o= f > my traffic to facebook must be the responsibility of me and facebook only= , > and not anyone else. And I am doing my best to achieve that. The discussi= on > is very useful to me, may be after this discussion we can come out with a > new final solution to this issue. > > > On Tue, Jun 25, 2013 at 2:29 PM, Salz, Rich wrote: > >> **=D8 **Self signed certificate is very dangerous because the user will >> not have a way to verify the identity of the certificate owner and he co= uld >> be a victim to a man in the middle attack.**** >> >> ** ** >> >> I don=92t see anything in your system that prevents this, either. It se= ems >> that replacing your system with self-signed client certificates would be >> equivalent.**** >> >> ** ** >> >> It=92s great that you are trying to improve things; don=92t get discoura= ged, >> but this ain=92t there yet. And as a first step to replacing all of >> SSL/TLS? Nope.**** >> >> ** ** >> >> /r$**** >> >> ** ** >> >> -- **** >> >> Principal Security Engineer**** >> >> Akamai Technology**** >> >> Cambridge, MA**** >> >> ** ** >> > > --20cf303636fb61ba3804dfff3c68 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi=A0Uri,

May be I am still not able to = clear my point regarding the man in the middle attack.=A0

When the user provides the credential informat= ion, he will not provide it to the Facebook log in page, instead he will go= to the menu bar in his browser, and run the new plugin which has two tabs:= one for log in; and the other for enrollment, and in the plugin interface = the user will provide his credential information.

The key pair will be generated insi= de the browser's plugin, and only the signed message, and the username = will go to Facebook, no passwords will leave the user's browser. When t= he server receive the username and the signed message, it will send the ses= sion key encrypted with the user's public key.

If =A0someone pretended to be Faceb= ook, he will receive a public key and a signed message. The attacker cannot= use this information to log into Facebook, because the signed message cont= ains the current server's time stamp, so it's valid only for a few = seconds.

And even if the attacker sends the = signed message and the username to the server, and the server accepted them= , the next step is that the server will respond with the session key encryp= ted with the user's public key. How the attacker will read the public k= ey if he doesn't have the private key, the private key that didn't = leave the user's browser.


On Tue,= Jun 25, 2013 at 7:55 PM, OMAR HASSAN (RIT Student) <<= a href=3D"mailto:omh1835@rit.edu" target=3D"_blank">omh1835@rit.edu>= wrote:
Hi All

>Stephan:<= div class=3D"im">
>How you made sure that the user (client) is connec= ted with the intended server?
>Paras Shah:

>That is exactly the question= I had. How is Server Authentication done with this approach?
>Rich:

>I don=92t see anything in your system th= at prevents this, either. =A0It seems that replacing your system with self-= signed client=A0>certificates would be equivalent.

>Robe= rt:
>As the proposal has no server authentication, it is surely broken in th= at respect i.e. the client could be lured to any bogus=A0>website masque= rading as a legitimate one. How would the client know?

I would explain=A0How is Server Authentication done=A0with a practical = example. Let's name facebook as our website that we need to protect usi= ng that new protocol.

When I go to facebook, I would receive a brows= er message telling me: "Please use the UDKP protected access (Tools-&g= t;UDKP Protected Access)!"
the user will go to the plugin interface, and provide the username, passwor= d, password confirmation, the plugin will create a file with random data st= ream in the user's usb, and then the user will click on the register bu= tton.

At that point the plugin will create the key pair based on the random f= ile, username, and password. The public key will go to the server with the = username and a signed message, and the user will be redirected to the faceb= ook registration page to complete his registration.

Now the user profile is created on facebook and associated with th= e user public key.

When the user tries to sign in later into = facebook, and if he was deceived to sign in into a fake website, the user w= ill go to the browser plugin interface, and provide the username, password,= and select the file from his usb. At that point the user will be expecting= to see his facebook timeline if he is really signing into the real faceboo= k. Note that the user didn't provide the credential information to the = website but to the browser plugin (Tools->UDKP Protected Access).

In our case, the fake website will only receive the username, the = public key, and the token (ServerHello.random ) signed with user private ke= y,=A0If the attacker delivered this message to the facebook server, the=A0s= erver will try to read and validate the token using the user public key. If= it succeeds, it=A0will respond with the session key premaster encrypted by= the user public key. Because=A0the user private key did not leave the brow= ser, the attacker will not be able to read the=A0session key and hence will= not be able to monitor the traffic.

So if the user was successfully able to see his timeline, he= would be sure that he is communicating with the real facebook.

>= Robert:
>Token =3D enc(ServerHello.random, PrivKey) : The concept of = encrypting using a private key seems pointless. Don't you mean >sign= ing?

Yes Robert, I mean signing not=A0encrypting.=A0Actually someone told me= before about that mistake in the previous version, but unfortunately I for= got to correct it in the new version. Hopefully in the next version it will= be corrected. Thank You.

>Juho V=E4h=E4-Herttua:

>The whole security = of the system seems to be dependant on the security of the "browser pl= ugin" and its key generation and encryption algorithms

I preferred to make the generation of the key pair as a black box, so = we can focus our discussion on the idea itself, so the question is if we ha= ve a key generation function that can generate key pair securely based on t= he username, password, and the file selected, would the idea be a good one.=

>What if someone detects this enrollment and sends a new public= key for the user before the user has time to fill all the fields? Sounds l= ike a race condition to me.

The key pair generation= is done inside the browser plugin interface, not in the website page, so t= here is no race condition, the communication with the website will start af= ter the creation of the key pair.


>I don't see how this is different from generating a self signed= client cert and verifying it with for example HMAC with username+password+= question derived secret. If you already need a custom >browser=A0
>plugin to handle the login, you can put all your custom logic ther= e and use standard TLS for the rest.

You can look a= t the generated key pair as a client certificate, but I preferred to make i= t as a key pair, so this key pair could be generated based on different app= roaches: security question, file, smart card, hardware token.

Additionally it's not only about custom sign in, it'= s also about eliminating the dependence on the CA, so the session key must = be encrypted with the user public key not encrypted with a key that claims = to be the server public key.

>Rich:

>It=92s great that you are trying to = improve things; don=92t get discouraged, but this ain=92t there yet.=A0 And= as a first step to replacing all of SSL/TLS?=A0 Nope.

I am no= t discouraged at all, but I am still insisting that the security of my traf= fic to facebook must be the responsibility of me and facebook only, and not= anyone else. And I am doing my best to achieve that. The discussion is ver= y useful to me, may be after this discussion we can come out with a new fin= al=A0solution=A0to this issue.

On Tue, Jun 25, 2013 at 2:29 PM, Salz, Ric= h <rsalz@akamai.com> wrote:

=D8=A0 Self signed certificate i= s very dangerous because the user will not have a way to verify the identit= y of the certificate owner and he could be a victim to a man in the middle = attack.

=A0<= /p>

I don=92t see anything= in your system that prevents this, either.=A0 It seems that replacing your= system with self-signed client certificates would be equivalent.=

=A0<= /p>

It=92s great that you = are trying to improve things; don=92t get discouraged, but this ain=92t the= re yet.=A0 And as a first step to replacing all of SSL/TLS?=A0 Nope.=

=A0

=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /r$

=A0<= /p>

--=A0

Principal Security Engine= er

Cambridge, MA

=A0



--20cf303636fb61ba3804dfff3c68-- From hannes.tschofenig@gmx.net Tue Jun 25 13:02:12 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 32BC621E804D for ; Tue, 25 Jun 2013 13:02:12 -0700 (PDT) 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D5rQaeabZBoG for ; Tue, 25 Jun 2013 13:02:07 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id 2283411E8130 for ; Tue, 25 Jun 2013 13:02:06 -0700 (PDT) Received: from mailout-de.gmx.net ([10.1.76.16]) by mrigmx.server.lan (mrigmx002) with ESMTP (Nemesis) id 0Lds7x-1URGxi2HEB-00j0W0 for ; Tue, 25 Jun 2013 22:02:05 +0200 Received: (qmail invoked by alias); 25 Jun 2013 20:02:05 -0000 Received: from host-94-101-1-228.igua.fi (EHLO [192.168.4.115]) [94.101.1.228] by mail.gmx.net (mp016) with SMTP; 25 Jun 2013 22:02:05 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX18pHRQoAMIpBZo9ZI1IP1Lxr2dIcPIxHROXm23AVx qJMHp0+zhtE+4P Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=utf-8 From: Hannes Tschofenig In-Reply-To: Date: Tue, 25 Jun 2013 23:02:01 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2A0EFB9C05D0164E98F19BB0AF3708C711B251EE97@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EF0E@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EFFF@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251F1E5@USMBX1.msg.corp.akamai.com> To: "OMAR HASSAN (RIT Student)" X-Pgp-Agent: GPGMail 1.4.1 X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: "tls@ietf.org" Subject: Re: [TLS] User Defined Key Pair 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, 25 Jun 2013 20:02:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Hi Omar,=20 if you think your proposal is a good idea then I would encourage you to = produce a draft. A draft, as a more complete writeup, often helps to = communicate ideas more easily. It also helps to illustrate the bigger = picture. Ciao Hannes PS: A minor remark - Facebook (as used in your example) uses IETF = technology developed in a different working group. Their use case, as = you can imagine, is a bit more complex than a browser talking to a = server.=20 On Jun 25, 2013, at 10:07 PM, OMAR HASSAN (RIT Student) wrote: > Hi Uri, >=20 > May be I am still not able to clear my point regarding the man in the = middle attack.=20 >=20 > When the user provides the credential information, he will not provide = it to the Facebook log in page, instead he will go to the menu bar in = his browser, and run the new plugin which has two tabs: one for log in; = and the other for enrollment, and in the plugin interface the user will = provide his credential information. >=20 > The key pair will be generated inside the browser's plugin, and only = the signed message, and the username will go to Facebook, no passwords = will leave the user's browser. When the server receive the username and = the signed message, it will send the session key encrypted with the = user's public key. >=20 > If someone pretended to be Facebook, he will receive a public key and = a signed message. The attacker cannot use this information to log into = Facebook, because the signed message contains the current server's time = stamp, so it's valid only for a few seconds. >=20 > And even if the attacker sends the signed message and the username to = the server, and the server accepted them, the next step is that the = server will respond with the session key encrypted with the user's = public key. How the attacker will read the public key if he doesn't have = the private key, the private key that didn't leave the user's browser. >=20 >=20 > On Tue, Jun 25, 2013 at 7:55 PM, OMAR HASSAN (RIT Student) = wrote: > Hi All >=20 > >Stephan: >=20 > >How you made sure that the user (client) is connected with the = intended server? > >Paras Shah: >=20 > >That is exactly the question I had. How is Server Authentication done = with this approach? > >Rich: >=20 > >I don=E2=80=99t see anything in your system that prevents this, = either. It seems that replacing your system with self-signed client = >certificates would be equivalent. >=20 > >Robert: > >As the proposal has no server authentication, it is surely broken in = that respect i.e. the client could be lured to any bogus >website = masquerading as a legitimate one. How would the client know? >=20 > I would explain How is Server Authentication done with a practical = example. Let's name facebook as our website that we need to protect = using that new protocol. >=20 > When I go to facebook, I would receive a browser message telling me: = "Please use the UDKP protected access (Tools->UDKP Protected Access)!" > the user will go to the plugin interface, and provide the username, = password, password confirmation, the plugin will create a file with = random data stream in the user's usb, and then the user will click on = the register button. >=20 > At that point the plugin will create the key pair based on the random = file, username, and password. The public key will go to the server with = the username and a signed message, and the user will be redirected to = the facebook registration page to complete his registration. >=20 > Now the user profile is created on facebook and associated with the = user public key. >=20 > When the user tries to sign in later into facebook, and if he was = deceived to sign in into a fake website, the user will go to the browser = plugin interface, and provide the username, password, and select the = file from his usb. At that point the user will be expecting to see his = facebook timeline if he is really signing into the real facebook. Note = that the user didn't provide the credential information to the website = but to the browser plugin (Tools->UDKP Protected Access). >=20 > In our case, the fake website will only receive the username, the = public key, and the token (ServerHello.random ) signed with user private = key, If the attacker delivered this message to the facebook server, the = server will try to read and validate the token using the user public = key. If it succeeds, it will respond with the session key premaster = encrypted by the user public key. Because the user private key did not = leave the browser, the attacker will not be able to read the session key = and hence will not be able to monitor the traffic. >=20 > So if the user was successfully able to see his timeline, he would be = sure that he is communicating with the real facebook. >=20 > >Robert: > >Token =3D enc(ServerHello.random, PrivKey) : The concept of = encrypting using a private key seems pointless. Don't you mean >signing? >=20 > Yes Robert, I mean signing not encrypting. Actually someone told me = before about that mistake in the previous version, but unfortunately I = forgot to correct it in the new version. Hopefully in the next version = it will be corrected. Thank You. >=20 > >Juho V=C3=A4h=C3=A4-Herttua: >=20 > >The whole security of the system seems to be dependant on the = security of the "browser plugin" and its key generation and encryption = algorithms >=20 > I preferred to make the generation of the key pair as a black box, so = we can focus our discussion on the idea itself, so the question is if we = have a key generation function that can generate key pair securely based = on the username, password, and the file selected, would the idea be a = good one. >=20 > >What if someone detects this enrollment and sends a new public key = for the user before the user has time to fill all the fields? Sounds = like a race condition to me. >=20 > The key pair generation is done inside the browser plugin interface, = not in the website page, so there is no race condition, the = communication with the website will start after the creation of the key = pair. >=20 >=20 > >I don't see how this is different from generating a self signed = client cert and verifying it with for example HMAC with = username+password+question derived secret. If you already need a custom = >browser=20 > >plugin to handle the login, you can put all your custom logic there = and use standard TLS for the rest. >=20 > You can look at the generated key pair as a client certificate, but I = preferred to make it as a key pair, so this key pair could be generated = based on different approaches: security question, file, smart card, = hardware token. >=20 > Additionally it's not only about custom sign in, it's also about = eliminating the dependence on the CA, so the session key must be = encrypted with the user public key not encrypted with a key that claims = to be the server public key. >=20 > >Rich: >=20 > >It=E2=80=99s great that you are trying to improve things; don=E2=80=99t= get discouraged, but this ain=E2=80=99t there yet. And as a first step = to replacing all of SSL/TLS? Nope. >=20 > I am not discouraged at all, but I am still insisting that the = security of my traffic to facebook must be the responsibility of me and = facebook only, and not anyone else. And I am doing my best to achieve = that. The discussion is very useful to me, may be after this discussion = we can come out with a new final solution to this issue. >=20 >=20 > On Tue, Jun 25, 2013 at 2:29 PM, Salz, Rich wrote: > =C3=98 Self signed certificate is very dangerous because the user = will not have a way to verify the identity of the certificate owner and = he could be a victim to a man in the middle attack. >=20 > =20 >=20 > I don=E2=80=99t see anything in your system that prevents this, = either. It seems that replacing your system with self-signed client = certificates would be equivalent. >=20 > =20 >=20 > It=E2=80=99s great that you are trying to improve things; don=E2=80=99t = get discouraged, but this ain=E2=80=99t there yet. And as a first step = to replacing all of SSL/TLS? Nope. >=20 > =20 >=20 > /r$ >=20 > =20 >=20 > --=20 >=20 > Principal Security Engineer >=20 > Akamai Technology >=20 > Cambridge, MA >=20 > =20 >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) Comment: GPGTools - http://gpgtools.org iQEcBAEBCgAGBQJRyfc6AAoJEGhJURNOOiAt14IH+wX1gBztEr2vC7PkwKEmcU6Z tbLHVm5dUT1HR2uieVHEbjDviY8K/aM46C4Esxkh/6HyYe1RIJyrhHcqP0xv8ZjA zMlD4G6m4OVB+d5Wgvoj8FwHM9cs/WuNqWvf342LjB9EiHKyLGKKu6HVPYhrkzUr wHpj04n62lxyzQyPJA3nZ7hS/z/IW5zYB7ud+jIe2SpQWyGgPl+MlyxpihwQjCs3 FVjTVPlc4E88DfgIf5rDbbwf8JqM8r0wVNcHn1PQnOeh2k+GHkuHuflhmQisGetz 5x/NyhT8XIHGvf8CJ23PYjgkkYcLRHn5I/OElLCSNK54Widkn5y5GAR2kqZiL4g=3D =3DTTA8 -----END PGP SIGNATURE----- From omh1835@g.rit.edu Tue Jun 25 14:13: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 18F2911E814C for ; Tue, 25 Jun 2013 14:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=1.048, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5ftHjx5yZ+Zf for ; Tue, 25 Jun 2013 14:13:11 -0700 (PDT) Received: from sc3app27.rit.edu (sc3app27.rit.edu [129.21.35.56]) by ietfa.amsl.com (Postfix) with ESMTP id 9930021E80D7 for ; Tue, 25 Jun 2013 14:13:10 -0700 (PDT) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) by smtp-server.rit.edu (PMDF V6.3-x14 #31420) with ESMTPS id <0MOY002SMW9MPB@smtp-server.rit.edu> for tls@ietf.org; Tue, 25 Jun 2013 17:12:59 -0400 (EDT) Received: by mail-ie0-f175.google.com with SMTP id a13so28843770iee.20 for ; Tue, 25 Jun 2013 14:12:58 -0700 (PDT) Received: by 10.43.115.3 with HTTP; Tue, 25 Jun 2013 14:12:58 -0700 (PDT) X-Received: by 10.50.1.37 with SMTP id 5mr9831325igj.29.1372194778501; Tue, 25 Jun 2013 14:12:58 -0700 (PDT) X-Received: by 10.50.1.37 with SMTP id 5mr9831323igj.29.1372194778410; Tue, 25 Jun 2013 14:12:58 -0700 (PDT) Date: Wed, 26 Jun 2013 00:12:58 +0300 From: "OMAR HASSAN (RIT Student)" In-reply-to: <377FB9023E313048955F1A4A54DB21009A5676E9@365EXCH-MBX-P3.nbttech.com> Sender: omh1835@rit.edu To: Paras Shah Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary=e89a8f839e935480c904e000fe90 X-RIT-Received-From: 209.85.223.175 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=U5uxUdKZm5/eH9XaPpmQO5Dx7MW03LSXl65hGx0JXMo=; b=UNXpDu/M7Y3U6oO2NYPW7d5dGlpsqmvw6vEHv6Vjc2kMQ60BsSTJvx2UXrvkzE9ejj j40FllOPHH0Ma1jBi/cCs61D1mkHz6C6kDZLXKXDeGD3fZcgX9tMjWN0KDPzIrAH624Q hGi++bZ3adlcR7siG3URCwYJWOgh6zglKoCdRopL9XO99U1b+2vfJ47+gnuLQ3HkDEb7 aIUKvwMc78MzR5x/K9K3jZdrIiImcOzeRXYxV0mfLJRJA59z7VvyepL0Tt6Q1x/4Qbpo Md6c7YR3j1UpdCEkCB0lBgt4V7hYyJHpnWfZm6wN1viU0oPYKdRdn7UjywlaNRLEO/mx m7qw== X-Google-Sender-Auth: 7_6D232xPmgXWa8VhZAE4Qiujgw X-Gm-Message-State: ALoCoQnNkXrZogAfkZ7nHSS56iJp2eZdq7PLu5tTSqdf4JOkVDHPIm4FU2l+Qed1Tzg2SuE4Y6vRSKL11QrZV3B3eWSJM4Y8I5HKahlNP9YrPbT15x3+lTbrhBFDmlaVsgZRqsvAjAfo References: <2A0EFB9C05D0164E98F19BB0AF3708C711B251EE97@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EF0E@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EFFF@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251F1E5@USMBX1.msg.corp.akamai.com> <377FB9023E313048955F1A4A54DB21009A5676E9@365EXCH-MBX-P3.nbttech.com> Cc: "tls@ietf.org" Subject: Re: [TLS] User Defined Key Pair 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, 25 Jun 2013 21:13:17 -0000 --e89a8f839e935480c904e000fe90 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Paras If the attacker was masquerading as Facebook, he would get the user=92s public key, signed message, username. The attacker, can then choose a session key _*of his choice*_, encrypt with public key of user and send it back. Thereafter, the user is communicating with the attacker instead of the real Facebook server. That's one of the main differences between udkp protocol and TLS, the session key is generated by the server not the by the user, so the attacker cannot chose a session key of his choice and encrypt it with the user's public key. You refer to figure 1, 2 of the draft for the flow of messages between the user and the server. Besides, even the very 1st time, how do you know that the user is communicating with Facebook for real to get the server=92s current timestam= p for example.**** All values that the client received from the server will be hashed at the client, and sent back to the server encrypted with the session key, so the server can validate the hash to make sure that no one manipulate the values. This is done in the "finish" message. On Tue, Jun 25, 2013 at 10:35 PM, Paras Shah wrote= : > >If someone pretended to be Facebook, he will receive a public key and > a signed message. The attacker cannot use this information to log into > Facebook, because the signed message contains the current >server's time > stamp, so it's valid only for a few seconds.**** > > ** ** > > That is the issue right there. If the attacker was masquerading as > Facebook, he would get the user=92s public key, signed message, username.= The > attacker, can then choose a session key _*of his choice*_, encrypt with > public key of user and send it back. Thereafter, the user is communicatin= g > with the attacker instead of the real Facebook server.**** > > ** ** > > Besides, even the very 1st time, how do you know that the user is > communicating with Facebook for real to get the server=92s current timest= amp > for example.**** > > ** ** > > Paras Shah,**** > > SSL Security Engineer, **** > > Riverbed Technology.**** > > ** ** > > *From:* tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] *On Behalf Of = *OMAR > HASSAN (RIT Student) > *Sent:* Tuesday, June 25, 2013 12:07 PM > *Cc:* tls@ietf.org > > *Subject:* Re: [TLS] User Defined Key Pair**** > > ** ** > > Hi Uri,**** > > ** ** > > May be I am still not able to clear my point regarding the man in the > middle attack. **** > > ** ** > > When the user provides the credential information, he will not provide it > to the Facebook log in page, instead he will go to the menu bar in his > browser, and run the new plugin which has two tabs: one for log in; and t= he > other for enrollment, and in the plugin interface the user will provide h= is > credential information.**** > > ** ** > > The key pair will be generated inside the browser's plugin, and only the > signed message, and the username will go to Facebook, no passwords will > leave the user's browser. When the server receive the username and the > signed message, it will send the session key encrypted with the user's > public key.**** > > ** ** > > If someone pretended to be Facebook, he will receive a public key and a > signed message. The attacker cannot use this information to log into > Facebook, because the signed message contains the current server's time > stamp, so it's valid only for a few seconds.**** > > ** ** > > And even if the attacker sends the signed message and the username to the > server, and the server accepted them, the next step is that the server wi= ll > respond with the session key encrypted with the user's public key. How th= e > attacker will read the public key if he doesn't have the private key, the > private key that didn't leave the user's browser.**** > > ** ** > > On Tue, Jun 25, 2013 at 7:55 PM, OMAR HASSAN (RIT Student) < > omh1835@rit.edu> wrote:**** > > Hi All > > >Stephan:**** > > > >How you made sure that the user (client) is connected with the intended > server?**** > > >Paras Shah:**** > > > >That is exactly the question I had. How is Server Authentication done > with this approach?**** > > >Rich:**** > > > >I don=92t see anything in your system that prevents this, either. It se= ems > that replacing your system with self-signed client >certificates would be > equivalent.**** > > >Robert: > >As the proposal has no server authentication, it is surely broken in tha= t > respect i.e. the client could be lured to any bogus >website masquerading > as a legitimate one. How would the client know? > > I would explain How is Server Authentication done with a practical > example. Let's name facebook as our website that we need to protect using > that new protocol. > > When I go to facebook, I would receive a browser message telling me: > "Please use the UDKP protected access (Tools->UDKP Protected Access)!" > the user will go to the plugin interface, and provide the username, > password, password confirmation, the plugin will create a file with rando= m > data stream in the user's usb, and then the user will click on the regist= er > button.**** > > > At that point the plugin will create the key pair based on the random > file, username, and password. The public key will go to the server with t= he > username and a signed message, and the user will be redirected to the > facebook registration page to complete his registration.**** > > > Now the user profile is created on facebook and associated with the user > public key.**** > > > When the user tries to sign in later into facebook, and if he was deceive= d > to sign in into a fake website, the user will go to the browser plugin > interface, and provide the username, password, and select the file from h= is > usb. At that point the user will be expecting to see his facebook timelin= e > if he is really signing into the real facebook. Note that the user didn't > provide the credential information to the website but to the browser plug= in > (Tools->UDKP Protected Access).**** > > > In our case, the fake website will only receive the username, the public > key, and the token (ServerHello.random ) signed with user private key, If > the attacker delivered this message to the facebook server, the server wi= ll > try to read and validate the token using the user public key. If it > succeeds, it will respond with the session key premaster encrypted by the > user public key. Because the user private key did not leave the browser, > the attacker will not be able to read the session key and hence will not = be > able to monitor the traffic.**** > > So if the user was successfully able to see his timeline, he would be sur= e > that he is communicating with the real facebook. > > >Robert: > >Token =3D enc(ServerHello.random, PrivKey) : The concept of encrypting > using a private key seems pointless. Don't you mean >signing? > > Yes Robert, I mean signing not encrypting. Actually someone told me befor= e > about that mistake in the previous version, but unfortunately I forgot to > correct it in the new version. Hopefully in the next version it will be > corrected. Thank You. > > >Juho V=E4h=E4-Herttua:**** > > > >The whole security of the system seems to be dependant on the security o= f > the "browser plugin" and its key generation and encryption algorithms**** > > I preferred to make the generation of the key pair as a black box, so we > can focus our discussion on the idea itself, so the question is if we hav= e > a key generation function that can generate key pair securely based on th= e > username, password, and the file selected, would the idea be a good one.*= * > ** > > > >What if someone detects this enrollment and sends a new public key for > the user before the user has time to fill all the fields? Sounds like a > race condition to me.**** > > The key pair generation is done inside the browser plugin interface, not > in the website page, so there is no race condition, the communication wit= h > the website will start after the creation of the key pair.**** > > > > >I don't see how this is different from generating a self signed client > cert and verifying it with for example HMAC with username+password+questi= on > derived secret. If you already need a custom >browser **** > > >plugin to handle the login, you can put all your custom logic there and > use standard TLS for the rest.**** > > You can look at the generated key pair as a client certificate, but I > preferred to make it as a key pair, so this key pair could be generated > based on different approaches: security question, file, smart card, > hardware token.**** > > Additionally it's not only about custom sign in, it's also about > eliminating the dependence on the CA, so the session key must be encrypte= d > with the user public key not encrypted with a key that claims to be the > server public key. > > >Rich:**** > > > >It=92s great that you are trying to improve things; don=92t get discoura= ged, > but this ain=92t there yet. And as a first step to replacing all of > SSL/TLS? Nope.**** > > I am not discouraged at all, but I am still insisting that the security o= f > my traffic to facebook must be the responsibility of me and facebook only= , > and not anyone else. And I am doing my best to achieve that. The discussi= on > is very useful to me, may be after this discussion we can come out with a > new final solution to this issue.**** > > ** ** > > On Tue, Jun 25, 2013 at 2:29 PM, Salz, Rich wrote:**** > > =D8 Self signed certificate is very dangerous because the user will not > have a way to verify the identity of the certificate owner and he could b= e > a victim to a man in the middle attack.**** > > **** > > I don=92t see anything in your system that prevents this, either. It see= ms > that replacing your system with self-signed client certificates would be > equivalent.**** > > **** > > It=92s great that you are trying to improve things; don=92t get discourag= ed, > but this ain=92t there yet. And as a first step to replacing all of > SSL/TLS? Nope.**** > > **** > > /r$**** > > **** > > -- **** > > Principal Security Engineer**** > > Akamai Technology**** > > Cambridge, MA**** > > **** > > ** ** > > ** ** > --e89a8f839e935480c904e000fe90 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi=A0Paras


If the attacker was masquerading as Facebook, he would g= et the user=92s public key, signed message, username. The attacker, can the= n choose a session key _of his choice_, encrypt wit= h public key of user and send it back. Thereafter, the user is communicatin= g with the attacker instead of the real Facebook server.

That's one of the main differe= nces between udkp protocol and TLS, the session key is generated by the ser= ver not the by the user, so the attacker cannot chose a session key of his = choice and encrypt it with the user's public key. You refer to figure 1= , 2 of the draft for the flow of messages between the user and the server.<= br>

Besides, even the very 1st=A0time, how do you know that the user is communicating with Facebook for = real to get the server=92s current timestamp for example.

All values that the client received from the server will be hash= ed at the client, and sent back to the server encrypted with the session ke= y, so the server can validate the hash to make sure that no one manipulate = the values. This is done in the "finish" message.


O= n Tue, Jun 25, 2013 at 10:35 PM, Paras Shah <Paras.Shah@riverbed.c= om> wrote:

>If =A0someone pretended to be Faceb= ook, he will receive a public key and a signed message. The attacker cannot= use this information to log into Facebook, because the signed message contains the current >server's time stamp, so it= 's valid only for a few seconds.

=A0<= /p>

That is the issue r= ight there. If the attacker was masquerading as Facebook, he would get the = user=92s public key, signed message, username. The attacker, can then choose a session key _of his choice_, encrypt with public key = of user and send it back. Thereafter, the user is communicating with the at= tacker instead of the real Facebook server.

=A0<= /p>

Besides, even the very 1<= sup>st time, how do you know that the user is communicating with Face= book for real to get the server=92s current timestamp for example.

=A0<= /p>

Paras Shah,=

SSL Security Engineer,

Riverbed Technology.

=A0<= /p>

From: tls-bounces@ietf.org= [mailto:tls-boun= ces@ietf.org] On Behalf Of OMAR HASSAN (RIT Student)
Sent: Tuesday, June 25, 2013 12:07 PM
Cc: tls@ietf.org


Subject: Re: [TLS] User Defined Key Pair

=A0

Hi=A0Uri,

=

=A0

May be I am still not able to clear my = point regarding the man in the middle attack.=A0

=A0

When the user provides the credential i= nformation, he will not provide it to the Facebook log in page, instead he = will go to the menu bar in his browser, and run the new plugin which has two tabs: one for log in; and the other for e= nrollment, and in the plugin interface the user will provide his credential= information.

=A0

The key pair will be generated inside t= he browser's plugin, and only the signed message, and the username will= go to Facebook, no passwords will leave the user's browser. When the server receive the username and the signed message, it w= ill send the session key encrypted with the user's public key.

=A0

If =A0someone pretended to be Facebook,= he will receive a public key and a signed message. The attacker cannot use= this information to log into Facebook, because the signed message contains the current server's time stamp, so it'= ;s valid only for a few seconds.

=A0

And even if the attacker sends the sign= ed message and the username to the server, and the server accepted them, th= e next step is that the server will respond with the session key encrypted with the user's public key. How the att= acker will read the public key if he doesn't have the private key, the = private key that didn't leave the user's browser.<= /u>

=A0

On Tue, Jun 25, 2013 at 7:55 PM, OMAR HASSAN (RIT St= udent) <omh1835@rit= .edu> wrote:

Hi All

>Stephan:


>How you made sure that the user (client) is connected with the intended= server?

>Paras Shah:


>That is exactly the question I had. How is Server Authentication done w= ith this approach?

>Rich:


>I don=92t see anything in your system that prevents this, either. =A0It= seems that replacing your system with self-signed client=A0>certificate= s would be equivalent.

>Robert:
>As the proposal has no server authentication, it is surely broken in th= at respect i.e. the client could be lured to any bogus=A0>website masque= rading as a legitimate one. How would the client know?

I would explain=A0How is Server Authentication done=A0with a practical exam= ple. Let's name facebook as our website that we need to protect using t= hat new protocol.

When I go to facebook, I would receive a browser message telling me: "= Please use the UDKP protected access (Tools->UDKP Protected Access)!&quo= t;
the user will go to the plugin interface, and provide the username, passwor= d, password confirmation, the plugin will create a file with random data st= ream in the user's usb, and then the user will click on the register bu= tton.


At that point the plugin will create the key pair based on the random file,= username, and password. The public key will go to the server with the user= name and a signed message, and the user will be redirected to the facebook = registration page to complete his registration.


Now the user profile is created on facebook and associated with the user pu= blic key.


When the user tries to sign in later into facebook, and if he was deceived = to sign in into a fake website, the user will go to the browser plugin inte= rface, and provide the username, password, and select the file from his usb= . At that point the user will be expecting to see his facebook timeline if he is really signing into the re= al facebook. Note that the user didn't provide the credential informati= on to the website but to the browser plugin (Tools->UDKP Protected Acces= s).


In our case, the fake website will only receive the username, the public ke= y, and the token (ServerHello.random ) signed with user private key,=A0If t= he attacker delivered this message to the facebook server, the=A0server wil= l try to read and validate the token using the user public key. If it succeeds, it=A0will respond with the sess= ion key premaster encrypted by the user public key. Because=A0the user priv= ate key did not leave the browser, the attacker will not be able to read th= e=A0session key and hence will not be able to monitor the traffic.

So if the user was successfully able to see his time= line, he would be sure that he is communicating with the real facebook.

>Robert:
>Token =3D enc(ServerHello.random, PrivKey) : The concept of encrypting = using a private key seems pointless. Don't you mean >signing?

Yes Robert, I mean signing not=A0encrypting.=A0Actually someone told me bef= ore about that mistake in the previous version, but unfortunately I forgot = to correct it in the new version. Hopefully in the next version it will be = corrected. Thank You.

>Juho V=E4h=E4-Herttua:


>The whole security of the system seems to be dependant on the security = of the "browser plugin" and its key generation and encryption alg= orithms

I preferred to make the generation of the key pair a= s a black box, so we can focus our discussion on the idea itself, so the qu= estion is if we have a key generation function that can generate key pair s= ecurely based on the username, password, and the file selected, would the idea be a good one.


>What if someone detects this enrollment and sends a new public key for = the user before the user has time to fill all the fields? Sounds like a rac= e condition to me.

The key pair generation is done inside the browser p= lugin interface, not in the website page, so there is no race condition, th= e communication with the website will start after the creation of the key p= air.



>I don't see how this is different from generating a self signed cli= ent cert and verifying it with for example HMAC with username+password+ques= tion derived secret. If you already need a custom >browser=A0<= /u>

>plugin to handle = the login, you can put all your custom logic there and use standard TLS for= the rest.

You can look at the g= enerated key pair as a client certificate, but I preferred to make it as a = key pair, so this key pair could be generated based on different approaches= : security question, file, smart card, hardware token.

Additionally it's not only about custom sign in,= it's also about eliminating the dependence on the CA, so the session k= ey must be encrypted with the user public key not encrypted with a key that= claims to be the server public key.

>Rich:


>It=92s great that you are trying to improve things; don=92t get discour= aged, but this ain=92t there yet.=A0 And as a first step to replacing all o= f SSL/TLS?=A0 Nope.

I am not discouraged at all, but I am still insistin= g that the security of my traffic to facebook must be the responsibility of= me and facebook only, and not anyone else. And I am doing my best to achie= ve that. The discussion is very useful to me, may be after this discussion we can come out with a new final=A0sol= ution=A0to this issue.

=A0

On Tue, Jun 25, 2013 at 2:29 PM, Salz, Rich <rsalz@akamai.com> = wrote:

=D8=A0 Self signed certificate is very dangerous because the user will not have a = way to verify the identity of the certificate owner and he could be a victi= m to a man in the middle attack.

=A0<= /p>

I don=92t see anything in= your system that prevents this, either.=A0 It seems that replacing your sy= stem with self-signed client certificates would be equivalent.=

=A0<= /p>

It=92s great that you are= trying to improve things; don=92t get discouraged, but this ain=92t there = yet.=A0 And as a first step to replacing all of SSL/TLS?=A0 Nope.=

=A0<= /p>

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 /r$

=A0<= /p>

--=A0

Principal Security Engine= er

Akamai Technology<= u>

Cambridge, MA

=A0<= /p>

=A0

=A0


--e89a8f839e935480c904e000fe90-- From omh1835@g.rit.edu Tue Jun 25 14:22:44 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 3364221E80B9 for ; Tue, 25 Jun 2013 14:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.278 X-Spam-Level: X-Spam-Status: No, score=-2.278 tagged_above=-999 required=5 tests=[AWL=0.699, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z90XGshSNfju for ; Tue, 25 Jun 2013 14:22:38 -0700 (PDT) Received: from sc3app27.rit.edu (sc3app27.rit.edu [129.21.35.56]) by ietfa.amsl.com (Postfix) with ESMTP id 38AD911E814F for ; Tue, 25 Jun 2013 14:22:38 -0700 (PDT) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by smtp-server.rit.edu (PMDF V6.3-x14 #31420) with ESMTPS id <0MOY0016UWPOHA@smtp-server.rit.edu> for tls@ietf.org; Tue, 25 Jun 2013 17:22:37 -0400 (EDT) Received: by mail-ie0-f172.google.com with SMTP id 16so29789953iea.3 for ; Tue, 25 Jun 2013 14:22:36 -0700 (PDT) Received: by 10.43.115.3 with HTTP; Tue, 25 Jun 2013 14:22:36 -0700 (PDT) X-Received: by 10.43.137.65 with SMTP id in1mr442526icc.103.1372195356663; Tue, 25 Jun 2013 14:22:36 -0700 (PDT) X-Received: by 10.43.137.65 with SMTP id in1mr442521icc.103.1372195356559; Tue, 25 Jun 2013 14:22:36 -0700 (PDT) Date: Wed, 26 Jun 2013 00:22:36 +0300 From: "OMAR HASSAN (RIT Student)" In-reply-to: Sender: omh1835@rit.edu To: Hannes Tschofenig Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary=001a11c2456eca656f04e00120f6 X-RIT-Received-From: 209.85.223.172 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=eC4ceGH3Ru96eJDlEGvnt8XxA1yAEk87tfrw1wZxYlc=; b=ojWWV/HUQZUdWiNpVpzLSWD/uCc30UeXSiag6I+ugxUyG36GmCaJ8CkVsUQ/q7JVUV CrZY32UO6GbIkk+KjqBUK1W8y/O3F/fp+3vQFnVep9tdNHqE8rk0M9GYCivhRmZuHi1K ZZVG6Xs1u4ENmPIqIz3yHxTgWGkd1js+sDx6IhJYOhZ2YIseOR+kTUjmEryVuDhorrmm 6zCVxSs5SCdXlTMcs+uEFsh7fchdu4Hg89xnnJKYCj/f1MGnMFjhB94LWrcxE4BXs6Bu mNOQ4gWXAyYFCiLqbP0b/bf1kMSS/+eJ+7IDEtjJ2eQA82A3BkbIX+X2Lj8B94yAFdsy kSLA== X-Google-Sender-Auth: eMiA3Ee3W59R8-C1EZIjdCQBQlY X-Gm-Message-State: ALoCoQndwFfeR7+QZHvuMYRsyZI5p54Owm5hP18KQDefDZwAP0cLXaxptTFiT+Tr+DtAt/DUCY2eh0wW8Q5HFKjSUSU+VZTIS+Y3pGh1a+WJUrTXItjP4A5Y7Ew4xH+1PQB8xnfVznZA References: <2A0EFB9C05D0164E98F19BB0AF3708C711B251EE97@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EF0E@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EFFF@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251F1E5@USMBX1.msg.corp.akamai.com> Cc: "tls@ietf.org" Subject: Re: [TLS] User Defined Key Pair 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, 25 Jun 2013 21:22:44 -0000 --001a11c2456eca656f04e00120f6 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Hannes I think you are right the biggest issue that I am facing is the communication of the idea. Currently I am taking notes from this discussion to make use of them in new version of the draft, but I am really interested in the initial thoughts about the idea, and I am doing my best to clarify whatever mysterious. But this version of the draft is very clear compared to the first version, even me when I tried to reread the first version of the draft I couldn't understand it :) Thank You for your advice. On Tue, Jun 25, 2013 at 11:02 PM, Hannes Tschofenig < hannes.tschofenig@gmx.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > Hi Omar, > > if you think your proposal is a good idea then I would encourage you to > produce a draft. A draft, as a more complete writeup, often helps to > communicate ideas more easily. It also helps to illustrate the bigger > picture. > > Ciao > Hannes > > PS: A minor remark - Facebook (as used in your example) uses IETF > technology developed in a different working group. Their use case, as you > can imagine, is a bit more complex than a browser talking to a server. > > On Jun 25, 2013, at 10:07 PM, OMAR HASSAN (RIT Student) wrote: > > > Hi Uri, > > > > May be I am still not able to clear my point regarding the man in the > middle attack. > > > > When the user provides the credential information, he will not provide > it to the Facebook log in page, instead he will go to the menu bar in his > browser, and run the new plugin which has two tabs: one for log in; and t= he > other for enrollment, and in the plugin interface the user will provide h= is > credential information. > > > > The key pair will be generated inside the browser's plugin, and only th= e > signed message, and the username will go to Facebook, no passwords will > leave the user's browser. When the server receive the username and the > signed message, it will send the session key encrypted with the user's > public key. > > > > If someone pretended to be Facebook, he will receive a public key and = a > signed message. The attacker cannot use this information to log into > Facebook, because the signed message contains the current server's time > stamp, so it's valid only for a few seconds. > > > > And even if the attacker sends the signed message and the username to > the server, and the server accepted them, the next step is that the serve= r > will respond with the session key encrypted with the user's public key. H= ow > the attacker will read the public key if he doesn't have the private key, > the private key that didn't leave the user's browser. > > > > > > On Tue, Jun 25, 2013 at 7:55 PM, OMAR HASSAN (RIT Student) < > omh1835@rit.edu> wrote: > > Hi All > > > > >Stephan: > > > > >How you made sure that the user (client) is connected with the intende= d > server? > > >Paras Shah: > > > > >That is exactly the question I had. How is Server Authentication done > with this approach? > > >Rich: > > > > >I don=92t see anything in your system that prevents this, either. It > seems that replacing your system with self-signed client >certificates > would be equivalent. > > > > >Robert: > > >As the proposal has no server authentication, it is surely broken in > that respect i.e. the client could be lured to any bogus >website > masquerading as a legitimate one. How would the client know? > > > > I would explain How is Server Authentication done with a practical > example. Let's name facebook as our website that we need to protect using > that new protocol. > > > > When I go to facebook, I would receive a browser message telling me: > "Please use the UDKP protected access (Tools->UDKP Protected Access)!" > > the user will go to the plugin interface, and provide the username, > password, password confirmation, the plugin will create a file with rando= m > data stream in the user's usb, and then the user will click on the regist= er > button. > > > > At that point the plugin will create the key pair based on the random > file, username, and password. The public key will go to the server with t= he > username and a signed message, and the user will be redirected to the > facebook registration page to complete his registration. > > > > Now the user profile is created on facebook and associated with the use= r > public key. > > > > When the user tries to sign in later into facebook, and if he was > deceived to sign in into a fake website, the user will go to the browser > plugin interface, and provide the username, password, and select the file > from his usb. At that point the user will be expecting to see his faceboo= k > timeline if he is really signing into the real facebook. Note that the us= er > didn't provide the credential information to the website but to the brows= er > plugin (Tools->UDKP Protected Access). > > > > In our case, the fake website will only receive the username, the publi= c > key, and the token (ServerHello.random ) signed with user private key, If > the attacker delivered this message to the facebook server, the server wi= ll > try to read and validate the token using the user public key. If it > succeeds, it will respond with the session key premaster encrypted by the > user public key. Because the user private key did not leave the browser, > the attacker will not be able to read the session key and hence will not = be > able to monitor the traffic. > > > > So if the user was successfully able to see his timeline, he would be > sure that he is communicating with the real facebook. > > > > >Robert: > > >Token =3D enc(ServerHello.random, PrivKey) : The concept of encrypting > using a private key seems pointless. Don't you mean >signing? > > > > Yes Robert, I mean signing not encrypting. Actually someone told me > before about that mistake in the previous version, but unfortunately I > forgot to correct it in the new version. Hopefully in the next version it > will be corrected. Thank You. > > > > >Juho V=E4h=E4-Herttua: > > > > >The whole security of the system seems to be dependant on the security > of the "browser plugin" and its key generation and encryption algorithms > > > > I preferred to make the generation of the key pair as a black box, so w= e > can focus our discussion on the idea itself, so the question is if we hav= e > a key generation function that can generate key pair securely based on th= e > username, password, and the file selected, would the idea be a good one. > > > > >What if someone detects this enrollment and sends a new public key for > the user before the user has time to fill all the fields? Sounds like a > race condition to me. > > > > The key pair generation is done inside the browser plugin interface, no= t > in the website page, so there is no race condition, the communication wit= h > the website will start after the creation of the key pair. > > > > > > >I don't see how this is different from generating a self signed client > cert and verifying it with for example HMAC with username+password+questi= on > derived secret. If you already need a custom >browser > > >plugin to handle the login, you can put all your custom logic there an= d > use standard TLS for the rest. > > > > You can look at the generated key pair as a client certificate, but I > preferred to make it as a key pair, so this key pair could be generated > based on different approaches: security question, file, smart card, > hardware token. > > > > Additionally it's not only about custom sign in, it's also about > eliminating the dependence on the CA, so the session key must be encrypte= d > with the user public key not encrypted with a key that claims to be the > server public key. > > > > >Rich: > > > > >It=92s great that you are trying to improve things; don=92t get > discouraged, but this ain=92t there yet. And as a first step to replacin= g > all of SSL/TLS? Nope. > > > > I am not discouraged at all, but I am still insisting that the security > of my traffic to facebook must be the responsibility of me and facebook > only, and not anyone else. And I am doing my best to achieve that. The > discussion is very useful to me, may be after this discussion we can come > out with a new final solution to this issue. > > > > > > On Tue, Jun 25, 2013 at 2:29 PM, Salz, Rich wrote: > > =D8 Self signed certificate is very dangerous because the user will no= t > have a way to verify the identity of the certificate owner and he could b= e > a victim to a man in the middle attack. > > > > > > > > I don=92t see anything in your system that prevents this, either. It > seems that replacing your system with self-signed client certificates wou= ld > be equivalent. > > > > > > > > It=92s great that you are trying to improve things; don=92t get discour= aged, > but this ain=92t there yet. And as a first step to replacing all of SSL/= TLS? > Nope. > > > > > > > > /r$ > > > > > > > > -- > > > > Principal Security Engineer > > > > Akamai Technology > > > > Cambridge, MA > > > > > > > > > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG/MacGPG2 v2.0.19 (Darwin) > Comment: GPGTools - http://gpgtools.org > > iQEcBAEBCgAGBQJRyfc6AAoJEGhJURNOOiAt14IH+wX1gBztEr2vC7PkwKEmcU6Z > tbLHVm5dUT1HR2uieVHEbjDviY8K/aM46C4Esxkh/6HyYe1RIJyrhHcqP0xv8ZjA > zMlD4G6m4OVB+d5Wgvoj8FwHM9cs/WuNqWvf342LjB9EiHKyLGKKu6HVPYhrkzUr > wHpj04n62lxyzQyPJA3nZ7hS/z/IW5zYB7ud+jIe2SpQWyGgPl+MlyxpihwQjCs3 > FVjTVPlc4E88DfgIf5rDbbwf8JqM8r0wVNcHn1PQnOeh2k+GHkuHuflhmQisGetz > 5x/NyhT8XIHGvf8CJ23PYjgkkYcLRHn5I/OElLCSNK54Widkn5y5GAR2kqZiL4g=3D > =3DTTA8 > -----END PGP SIGNATURE----- > --001a11c2456eca656f04e00120f6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi=A0Hannes

I think you are right= the biggest issue that I am facing is the communication of the idea. Curre= ntly I am taking notes from this discussion to make use of them in new vers= ion of the draft, but I am really interested in the initial thoughts about = the idea, and I am doing my best to clarify whatever mysterious.

But this version of the draft is very clear= compared to the first version, even me when I tried to reread the first ve= rsion of the draft I couldn't understand it :)

Thank You for your advice.


On Tue, Jun 25, 2013 at 11:02 PM,= Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote= :
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi Omar,

if you think your proposal is a good idea then I would encourage you to pro= duce a draft. A draft, as a more complete writeup, often helps to communica= te ideas more easily. It also helps to illustrate the bigger picture.

Ciao
Hannes

PS: A minor remark - Facebook (as used in your example) uses IETF technolog= y developed in a different working group. Their use case, as you can imagin= e, is a bit more complex than a browser talking to a server.

On Jun 25, 2013, at 10:07 PM, OMAR HASSAN (RIT Student) wrote:

> Hi Uri,
>
> May be I am still not able to clear my point regarding the man in the = middle attack.
>
> When the user provides the credential information, he will not provide= it to the Facebook log in page, instead he will go to the menu bar in his = browser, and run the new plugin which has two tabs: one for log in; and the= other for enrollment, and in the plugin interface the user will provide hi= s credential information.
>
> The key pair will be generated inside the browser's plugin, and on= ly the signed message, and the username will go to Facebook, no passwords w= ill leave the user's browser. When the server receive the username and = the signed message, it will send the session key encrypted with the user= 9;s public key.
>
> If =A0someone pretended to be Facebook, he will receive a public key a= nd a signed message. The attacker cannot use this information to log into F= acebook, because the signed message contains the current server's time = stamp, so it's valid only for a few seconds.
>
> And even if the attacker sends the signed message and the username to = the server, and the server accepted them, the next step is that the server = will respond with the session key encrypted with the user's public key.= How the attacker will read the public key if he doesn't have the priva= te key, the private key that didn't leave the user's browser.
>
>
> On Tue, Jun 25, 2013 at 7:55 PM, OMAR HASSAN (RIT Student) <omh1835@rit.edu> wrote:
> Hi All
>
> >Stephan:
>
> >How you made sure that the user (client) is connected with the int= ended server?
> >Paras Shah:
>
> >That is exactly the question I had. How is Server Authentication d= one with this approach?
> >Rich:
>
> >I don=92t see anything in your system that prevents this, either. = =A0It seems that replacing your system with self-signed client >certific= ates would be equivalent.
>
> >Robert:
> >As the proposal has no server authentication, it is surely broken = in that respect i.e. the client could be lured to any bogus >website mas= querading as a legitimate one. How would the client know?
>
> I would explain How is Server Authentication done with a practical exa= mple. Let's name facebook as our website that we need to protect using = that new protocol.
>
> When I go to facebook, I would receive a browser message telling me: &= quot;Please use the UDKP protected access (Tools->UDKP Protected Access)= !"
> the user will go to the plugin interface, and provide the username, pa= ssword, password confirmation, the plugin will create a file with random da= ta stream in the user's usb, and then the user will click on the regist= er button.
>
> At that point the plugin will create the key pair based on the random = file, username, and password. The public key will go to the server with the= username and a signed message, and the user will be redirected to the face= book registration page to complete his registration.
>
> Now the user profile is created on facebook and associated with the us= er public key.
>
> When the user tries to sign in later into facebook, and if he was dece= ived to sign in into a fake website, the user will go to the browser plugin= interface, and provide the username, password, and select the file from hi= s usb. At that point the user will be expecting to see his facebook timelin= e if he is really signing into the real facebook. Note that the user didn&#= 39;t provide the credential information to the website but to the browser p= lugin (Tools->UDKP Protected Access).
>
> In our case, the fake website will only receive the username, the publ= ic key, and the token (ServerHello.random ) signed with user private key, I= f the attacker delivered this message to the facebook server, the server wi= ll try to read and validate the token using the user public key. If it succ= eeds, it will respond with the session key premaster encrypted by the user = public key. Because the user private key did not leave the browser, the att= acker will not be able to read the session key and hence will not be able t= o monitor the traffic.
>
> So if the user was successfully able to see his timeline, he would be = sure that he is communicating with the real facebook.
>
> >Robert:
> >Token =3D enc(ServerHello.random, PrivKey) : The concept of encryp= ting using a private key seems pointless. Don't you mean >signing? >
> Yes Robert, I mean signing not encrypting. Actually someone told me be= fore about that mistake in the previous version, but unfortunately I forgot= to correct it in the new version. Hopefully in the next version it will be= corrected. Thank You.
>
> >Juho V=E4h=E4-Herttua:
>
> >The whole security of the system seems to be dependant on the secu= rity of the "browser plugin" and its key generation and encryptio= n algorithms
>
> I preferred to make the generation of the key pair as a black box, so = we can focus our discussion on the idea itself, so the question is if we ha= ve a key generation function that can generate key pair securely based on t= he username, password, and the file selected, would the idea be a good one.=
>
> >What if someone detects this enrollment and sends a new public key= for the user before the user has time to fill all the fields? Sounds like = a race condition to me.
>
> The key pair generation is done inside the browser plugin interface, n= ot in the website page, so there is no race condition, the communication wi= th the website will start after the creation of the key pair.
>
>
> >I don't see how this is different from generating a self signe= d client cert and verifying it with for example HMAC with username+password= +question derived secret. If you already need a custom >browser
> >plugin to handle the login, you can put all your custom logic ther= e and use standard TLS for the rest.
>
> You can look at the generated key pair as a client certificate, but I = preferred to make it as a key pair, so this key pair could be generated bas= ed on different approaches: security question, file, smart card, hardware t= oken.
>
> Additionally it's not only about custom sign in, it's also abo= ut eliminating the dependence on the CA, so the session key must be encrypt= ed with the user public key not encrypted with a key that claims to be the = server public key.
>
> >Rich:
>
> >It=92s great that you are trying to improve things; don=92t get di= scouraged, but this ain=92t there yet. =A0And as a first step to replacing = all of SSL/TLS? =A0Nope.
>
> I am not discouraged at all, but I am still insisting that the securit= y of my traffic to facebook must be the responsibility of me and facebook o= nly, and not anyone else. And I am doing my best to achieve that. The discu= ssion is very useful to me, may be after this discussion we can come out wi= th a new final solution to this issue.
>
>
> On Tue, Jun 25, 2013 at 2:29 PM, Salz, Rich <rsalz@akamai.com> wrote:
> =D8 =A0Self signed certificate is very dangerous because the user will= not have a way to verify the identity of the certificate owner and he coul= d be a victim to a man in the middle attack.
>
>
>
> I don=92t see anything in your system that prevents this, either. =A0I= t seems that replacing your system with self-signed client certificates wou= ld be equivalent.
>
>
>
> It=92s great that you are trying to improve things; don=92t get discou= raged, but this ain=92t there yet. =A0And as a first step to replacing all = of SSL/TLS? =A0Nope.
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /r$
>
>
>
> --
>
> Principal Security Engineer
>
> Akamai Technology
>
> Cambridge, MA
>
>
>
>
>
> ________________________________________= _______
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http:= //gpgtools.org

iQEcBAEBCgAGBQJRyfc6AAoJEGhJURNOOiAt14IH+wX1gBztEr2vC7PkwKEmcU6Z
tbLHVm5dUT1HR2uieVHEbjDviY8K/aM46C4Esxkh/6HyYe1RIJyrhHcqP0xv8ZjA
zMlD4G6m4OVB+d5Wgvoj8FwHM9cs/WuNqWvf342LjB9EiHKyLGKKu6HVPYhrkzUr
wHpj04n62lxyzQyPJA3nZ7hS/z/IW5zYB7ud+jIe2SpQWyGgPl+MlyxpihwQjCs3
FVjTVPlc4E88DfgIf5rDbbwf8JqM8r0wVNcHn1PQnOeh2k+GHkuHuflhmQisGetz
5x/NyhT8XIHGvf8CJ23PYjgkkYcLRHn5I/OElLCSNK54Widkn5y5GAR2kqZiL4g=3D
=3DTTA8
-----END PGP SIGNATURE-----

--001a11c2456eca656f04e00120f6-- From juhovh@iki.fi Tue Jun 25 14:38: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 F112F21F934C for ; Tue, 25 Jun 2013 14:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.903 X-Spam-Level: X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPScBraQL6fz for ; Tue, 25 Jun 2013 14:38:15 -0700 (PDT) Received: from jenni2.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id 84C5F11E8143 for ; Tue, 25 Jun 2013 14:38:14 -0700 (PDT) Received: from [10.60.82.223] (188.238.211.223) by jenni2.inet.fi (8.5.140.03) id 51BB235B00E27E67; Wed, 26 Jun 2013 00:38:07 +0300 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable References: <2A0EFB9C05D0164E98F19BB0AF3708C711B251EE97@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EF0E@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EFFF@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251F1E5@USMBX1.msg.corp.akamai.com> From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= Mime-Version: 1.0 (1.0) In-Reply-To: Message-Id: Date: Wed, 26 Jun 2013 00:37:38 +0300 To: "OMAR HASSAN (RIT Student)" X-Mailer: iPhone Mail (10B329) Cc: Paras Shah , "tls@ietf.org" Subject: Re: [TLS] User Defined Key Pair 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, 25 Jun 2013 21:38:21 -0000 On 25.6.2013, at 19.55, "OMAR HASSAN (RIT Student)" wrote:= > >Juho V=C3=A4h=C3=A4-Herttua: > >The whole security of the system seems to be dependant on the security of= the "browser plugin" and its key generation and encryption algorithms >=20 > I preferred to make the generation of the key pair as a black box, so we c= an focus our discussion on the idea itself, so the question is if we have a k= ey generation function that can generate key pair securely based on the user= name, password, and the file selected, would the idea be a good one. Personally, I would like to find out if it's possible to do securely (key ge= neration function) before judging if it's a good idea or not. I'm defaulting= to not a good idea. > >What if someone detects this enrollment and sends a new public key for th= e user before the user has time to fill all the fields? Sounds like a race c= ondition to me. >=20 > The key pair generation is done inside the browser plugin interface, not i= n the website page, so there is no race condition, the communication with th= e website will start after the creation of the key pair. Ok. In that case I don't quite understand why the public key is not sent tog= ether with the registration, but beforehand in TLS handshake. It sounds like= a much better idea to simply send public key instead of the password. Also, why don't you simply save the encrypted private key to the USB stick? W= hy is saving random bytes and generating the private key from those more sec= ure? > Additionally it's not only about custom sign in, it's also about eliminati= ng the dependence on the CA, so the session key must be encrypted with the u= ser public key not encrypted with a key that claims to be the server public k= ey. It doesn't matter if the premaster secret is encrypted with a client key or a= server key, what matters is that it is encrypted with a key that is authent= icated one way or another. This doesn't seem to be the case. The fact is that in your system, I could do a MITM in the registration phase= and get you to register my public key with your information, and you wouldn= 't even notice before you access it from somewhere where I cannot MITM. At t= hat point you would have probably already confirmed your email address etc. a= nd effectively given me tools to impersonate as you. Juho From juhovh@iki.fi Tue Jun 25 14:54:07 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 490B721E80E3 for ; Tue, 25 Jun 2013 14:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.903 X-Spam-Level: X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iC5cMr90+dhO for ; Tue, 25 Jun 2013 14:54:01 -0700 (PDT) Received: from kirsi1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id D202F21F9EE1 for ; Tue, 25 Jun 2013 14:54:00 -0700 (PDT) Received: from [10.60.82.223] (188.238.211.223) by kirsi1.inet.fi (8.5.140.03) id 51BB5BE300DE69E0; Wed, 26 Jun 2013 00:53:55 +0300 References: <2A0EFB9C05D0164E98F19BB0AF3708C711B251EE97@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EF0E@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EFFF@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251F1E5@USMBX1.msg.corp.akamai.com> <377FB9023E313048955F1A4A54DB21009A5676E9@365EXCH-MBX-P3.nbttech.com> Mime-Version: 1.0 (1.0) In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-81052F6D-2943-41E7-94E4-4629800FC56D Content-Transfer-Encoding: 7bit Message-Id: <4E48FD1B-FE92-43C4-A497-24DB13A8FC96@iki.fi> X-Mailer: iPhone Mail (10B329) From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= Date: Wed, 26 Jun 2013 00:53:45 +0300 To: "OMAR HASSAN (RIT Student)" Cc: Paras Shah , "tls@ietf.org" Subject: Re: [TLS] User Defined Key Pair 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, 25 Jun 2013 21:54:07 -0000 --Apple-Mail-81052F6D-2943-41E7-94E4-4629800FC56D Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable On 26.6.2013, at 0.12, "OMAR HASSAN (RIT Student)" wrote: > Besides, even the very 1st time, how do you know that the user is communic= ating with Facebook for real to get the server=A1=AFs current timestamp for e= xample. >=20 > All values that the client received from the server will be hashed at the c= lient, and sent back to the server encrypted with the session key, so the se= rver can validate the hash to make sure that no one manipulate the values. T= his is done in the "finish" message. I'm not sure you understand how the man-in-the-middle works here. You as a c= lient send a ClientHello to the server, I as an attacker receive it and open= a new TCP connection to the server and forward your ClientHello there. Then= I get the server random nonce in ServerHello and forward it to you. When you send your public key, I will replace it with my own public key inst= ead. When the server sends the premaster key I will decrypt it with my priva= te key and encrypt it (or some other premaster secret) again with yours. I w= ill modify all Finished messages accordingly so that everyone keeps happy. End result is that your "secure" session is actually with me, but all your d= ata is coming from facebook and going to facebook. You would never know the d= ifference. If you would open a "normal" TLS connection, trust the CA and sen= d your public key there, this problem wouldn't exist. And Facebook still wou= ldn't know your private key. I don't think this is just a problem with you not communicating your solutio= n to others well enough, you also need to listen. We all want to get rid of C= As, and if it would be as easy as you propose, it most likely would've been d= one already. Juho --Apple-Mail-81052F6D-2943-41E7-94E4-4629800FC56D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
On 26.6.2013, at 0.12, "OMAR HASSAN (R= IT Student)" <omh1835@rit.edu> w= rote:
<= p class=3D"" style=3D"font-family:arial,sans-serif;font-size:13px">Be= sides, even the very 1st time, how do you know that the user= is communicating with Facebook for real to get the server=E2=80=99s current= timestamp for example.

All values that the client received from the server will be h= ashed at the client, and sent back to the server encrypted with the session k= ey, so the server can validate the hash to make sure that no one manipulate t= he values. This is done in the "finish" message.

I'm not sure you understand how the man-in-the-= middle works here. You as a client send a ClientHello to the server, I as an= attacker receive it and open a new TCP connection to the server and forward= your ClientHello there. Then I get the server random nonce in ServerHello a= nd forward it to you.

When you send your public key= , I will replace it with my own public key instead. When the server sends th= e premaster key I will decrypt it with my private key and encrypt it (or som= e other premaster secret) again with yours. I will modify all Finished messa= ges accordingly so that everyone keeps happy.

End r= esult is that your "secure" session is actually with me, but all your data i= s coming from facebook and going to facebook. You would never know the diffe= rence. If you would open a "normal" TLS connection, trust the CA and send yo= ur public key there, this problem wouldn't exist. And Facebook still wouldn'= t know your private key.

I don't think this is just= a problem with you not communicating your solution to others well enough, y= ou also need to listen. We all want to get rid of CAs, and if it would be as= easy as you propose, it most likely would've been done already.
<= br>

Juho


= --Apple-Mail-81052F6D-2943-41E7-94E4-4629800FC56D-- From omh1835@g.rit.edu Tue Jun 25 15:50:15 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 56DF821E80A5 for ; Tue, 25 Jun 2013 15:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.302 X-Spam-Level: X-Spam-Status: No, score=-2.302 tagged_above=-999 required=5 tests=[AWL=0.374, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IJkOcsXUo1aq for ; Tue, 25 Jun 2013 15:50:09 -0700 (PDT) Received: from sc3app27.rit.edu (sc3app27.rit.edu [129.21.35.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8A411E8176 for ; Tue, 25 Jun 2013 15:50:09 -0700 (PDT) Received: from mail-ie0-f178.google.com (mail-ie0-f178.google.com [209.85.223.178]) by smtp-server.rit.edu (PMDF V6.3-x14 #31420) with ESMTPS id <0MOZ004850R8GJ@smtp-server.rit.edu> for tls@ietf.org; Tue, 25 Jun 2013 18:49:57 -0400 (EDT) Received: by mail-ie0-f178.google.com with SMTP id u16so30127426iet.9 for ; Tue, 25 Jun 2013 15:49:56 -0700 (PDT) Received: by 10.43.115.3 with HTTP; Tue, 25 Jun 2013 15:49:56 -0700 (PDT) X-Received: by 10.50.134.101 with SMTP id pj5mr9917156igb.31.1372200596538; Tue, 25 Jun 2013 15:49:56 -0700 (PDT) X-Received: by 10.50.134.101 with SMTP id pj5mr9917152igb.31.1372200596460; Tue, 25 Jun 2013 15:49:56 -0700 (PDT) Date: Wed, 26 Jun 2013 01:49:56 +0300 From: "OMAR HASSAN (RIT Student)" In-reply-to: <4E48FD1B-FE92-43C4-A497-24DB13A8FC96@iki.fi> Sender: omh1835@rit.edu To: =?ISO-8859-1?Q?Juho_V=E4h=E4=2DHerttua?= Message-id: MIME-version: 1.0 Content-type: multipart/alternative; boundary=047d7b3a9ad01cf0f204e0025945 X-RIT-Received-From: 209.85.223.178 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-gm-message-state; bh=eB8Dhgz7M17vcUFPG2ksag++Wzjg3lkr836nU54hHVg=; b=fhnqOMsMQvJiRIgGNWw2l6KgFocOXAV4b93x8UlGVwU3P5qJqONPmTn5PgUM+UXau0 tkf8yg6ChdNirTQ4KjaxTc5+G2Fw6XyveIHFM6cLj3YEtWam1MXHM8c+ncRCkHzegUtH kBtgk2hrW9UQVRx4sW5+DYXmwJpP7yZkigsAscWaY/vwCt5EKMH25i6XnLxGRLsncmBl rbs5OZ2id/B846l1dvPl+KQI0HVm7QPJs/lMRUj1OyTyauZJU3md29nKJvOJi+KlInzr u3nBkBA2nW5WKIpMivB7Vp0CMp8noN1zwOmZ953nIIOh9N6+o5U6QqK7mxS3DpQHCW+e 6KCQ== X-Google-Sender-Auth: r5OamkQJWZkuHvpZjprWOHdilB8 X-Gm-Message-State: ALoCoQm39vwTZHtmUL91g4qHrE68ThuJWXY3O4AsNKVhsIfDUH/QfExnrk5T4lVLchzEs21HVWBxedFCqp63Nl2JcnGFhnZ5we67bRJRXQBIcE/3qU0yvra+0Tra8MvSUiuo0w4cUJ25 References: <2A0EFB9C05D0164E98F19BB0AF3708C711B251EE97@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EF0E@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EFFF@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251F1E5@USMBX1.msg.corp.akamai.com> <377FB9023E313048955F1A4A54DB21009A5676E9@365EXCH-MBX-P3.nbttech.com> <4E48FD1B-FE92-43C4-A497-24DB13A8FC96@iki.fi> Cc: Paras Shah , "tls@ietf.org" Subject: Re: [TLS] User Defined Key Pair 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, 25 Jun 2013 22:50:15 -0000 --047d7b3a9ad01cf0f204e0025945 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Yes, man in the middle attack could only happened in the first time registration, and in that case the attack will be detected once I accessed the website from a clean network. I think the only solution in this case will be to open initial TLS connection during the registration or credential change. Once the user's public key is sent to the server, and became associated with the user's profile, TLS connection will not be required anymore. On Wed, Jun 26, 2013 at 12:53 AM, Juho V=E4h=E4-Herttua wro= te: > On 26.6.2013, at 0.12, "OMAR HASSAN (RIT Student)" > wrote: > > Besides, even the very 1st time, how do you know that the user is > communicating with Facebook for real to get the server=92s current timest= amp > for example.**** > All values that the client received from the server will be hashed at the > client, and sent back to the server encrypted with the session key, so th= e > server can validate the hash to make sure that no one manipulate the > values. This is done in the "finish" message. > > > I'm not sure you understand how the man-in-the-middle works here. You as = a > client send a ClientHello to the server, I as an attacker receive it and > open a new TCP connection to the server and forward your ClientHello ther= e. > Then I get the server random nonce in ServerHello and forward it to you. > > When you send your public key, I will replace it with my own public key > instead. When the server sends the premaster key I will decrypt it with m= y > private key and encrypt it (or some other premaster secret) again with > yours. I will modify all Finished messages accordingly so that everyone > keeps happy. > > End result is that your "secure" session is actually with me, but all you= r > data is coming from facebook and going to facebook. You would never know > the difference. If you would open a "normal" TLS connection, trust the CA > and send your public key there, this problem wouldn't exist. And Facebook > still wouldn't know your private key. > > I don't think this is just a problem with you not communicating your > solution to others well enough, you also need to listen. We all want to g= et > rid of CAs, and if it would be as easy as you propose, it most likely > would've been done already. > > > Juho > > > --047d7b3a9ad01cf0f204e0025945 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Hi

Yes, man in the middle attack could = only happened in the first time registration, and in that case the attack w= ill be detected once I accessed the website from a clean network. I think t= he only solution in this case will be to open initial TLS connection during= the registration or credential change. Once the user's public key is s= ent to the server, and became associated with the user's profile, TLS c= onnection will not be required anymore.


On Wed,= Jun 26, 2013 at 12:53 AM, Juho V=E4h=E4-Herttua <juhovh@iki.fi>= wrote:
On = 26.6.2013, at 0.12, "OMAR HASSAN (RIT Student)" <omh1835@rit.edu> wrote:

Besides, even the very 1st<= /sup>=A0time, how do you know that the user is communicating with Facebook = for real to get the server=92s current timestamp for example.=

All values that the client received from the server will be hashed at = the client, and sent back to the server encrypted with the session key, so = the server can validate the hash to make sure that no one manipulate the va= lues. This is done in the "finish" message.

I'm not sure y= ou understand how the man-in-the-middle works here. You as a client send a = ClientHello to the server, I as an attacker receive it and open a new TCP c= onnection to the server and forward your ClientHello there. Then I get the = server random nonce in ServerHello and forward it to you.

When you send your public key, I will replace it with m= y own public key instead. When the server sends the premaster key I will de= crypt it with my private key and encrypt it (or some other premaster secret= ) again with yours. I will modify all Finished messages accordingly so that= everyone keeps happy.

End result is that your "secure" session is a= ctually with me, but all your data is coming from facebook and going to fac= ebook. You would never know the difference. If you would open a "norma= l" TLS connection, trust the CA and send your public key there, this p= roblem wouldn't exist. And Facebook still wouldn't know your privat= e key.

I don't think this is just a problem with you not c= ommunicating your solution to others well enough, you also need to listen. = We all want to get rid of CAs, and if it would be as easy as you propose, i= t most likely would've been done already.


Juho



--047d7b3a9ad01cf0f204e0025945-- From pgut001@cs.auckland.ac.nz Fri Jun 28 20:29:29 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 9156F21F9B0A for ; Fri, 28 Jun 2013 20:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4KnsteH8S6m for ; Fri, 28 Jun 2013 20:29:25 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED9121F9B2D for ; Fri, 28 Jun 2013 20:29:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1372476565; x=1404012565; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=DSkU/hJHvQNQhnN/Z7jZKit2zk0IAsExGnbo9d6y8U4=; b=pVv5kAqHsRSQAke2jhSAN8uA71Yd0GKdUEHVFOZID4MSPtQNkcujmC0K qSo2TWcNghEPCF/fyQ0geQhlcp8E+d6JJhSi1Myd38j6urDQWq4vc+5gw SN112MQOb5UBrCe5zqXPEPRVyOerV6vLf+mEikMcKhAOXxZ3YHWBOUjDy 8=; X-IronPort-AV: E=Sophos;i="4.87,963,1363086000"; d="scan'208";a="196231548" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 29 Jun 2013 15:29:21 +1200 Received: from UXCN10-2.UoA.auckland.ac.nz ([169.254.2.214]) by uxchange10-fe2.UoA.auckland.ac.nz ([130.216.4.106]) with mapi id 14.02.0318.004; Sat, 29 Jun 2013 15:29:20 +1200 From: Peter Gutmann To: "tls@ietf.org" Thread-Topic: [TLS] Requesting feedback on TACK draft Thread-Index: Ac50eNdwP/oxDmJrTs2E1KIaE9cFeQ== Date: Sat, 29 Jun 2013 03:29:20 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C7343D703CE@uxcn10-2.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] Requesting feedback on TACK draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 03:29:29 -0000 Trevor Perrin writes:=0A= =0A= >The TACK draft has been stable for a while (the last substantive change wa= s=0A= >draft-01, last September).=0A= >=0A= >We're hoping to see some deployment this year, so we may request "early=0A= >allocation" of a TLS ExtensionType in the next few months.=0A= =0A= While people are looking at that, there's also the encrypt-then-MAC draft,= =0A= http://www.ietf.org/internet-drafts/draft-gutmann-tls-encrypt-then-mac-03.t= xt,=0A= which has been stable for about as long, has already been deployed by sever= al=0A= vendors, and for which TLS extension 0x10 has been de facto claimed, so it'= d=0A= be good to get this published to legitimise the use (and to document what's= =0A= already being deployed in production). In addition there's the ECC suites = draft,=0A= http://www.ietf.org/internet-drafts/draft-gutmann-tls-eccsuites-05.txt, whi= ch=0A= a number of users and vendors are also waiting on for publication. It's be= en=0A= stable for quite some time as well.=0A= =0A= Peter.=0A= =0A= From balfanz@google.com Sat Jun 29 08:25:34 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 9397E21F9F7C for ; Sat, 29 Jun 2013 08:25:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FwsSlmmIxK10 for ; Sat, 29 Jun 2013 08:25:34 -0700 (PDT) Received: from mail-qa0-x231.google.com (mail-qa0-x231.google.com [IPv6:2607:f8b0:400d:c00::231]) by ietfa.amsl.com (Postfix) with ESMTP id 1479121F9F6D for ; Sat, 29 Jun 2013 08:25:33 -0700 (PDT) Received: by mail-qa0-f49.google.com with SMTP id hu16so1201428qab.8 for ; Sat, 29 Jun 2013 08:25:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=xxiQo5qCJHjZ7TIGynIbGyFLc98OdjDWnriogeDZRBE=; b=gUu8jDCD6nLPqBvMlWqbEdx9a3r5gctaxNabNAh1ECwFgnpiIXjTT/4vanlh6kQxMT am9Eakrf95vs7dNxF8vdO1Y1oadrtd3HPMmH39cwBx2gUqyGRudpjpHoM9HcokG+djkO qCV3XmJ/drZJSC254OTLlc/C7VzLXmLb5OmDAW4Shai3t5kG924QqD271ZZIMcBsdLAE C4rAXt95JmXEObDDwKCcCAKHoFSeKWKryU/mVp2v4bIJyC1yvJ4i3+5XJMnuX8319m9u a7nnzST3W0jEiccuc3vDds48Xcj66TXFqepZS93YrCwGEFiqI00cFF3Zk8TiHpB9l+fp WjoQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=xxiQo5qCJHjZ7TIGynIbGyFLc98OdjDWnriogeDZRBE=; b=iJ7BOsVONApdvQtW4CsFNibc5L+dqYDyLQZ4veTLOCFJarS6rEH9m3kz7uBuFK2W53 qmi220FpN79UQb8pdg9cvY1WhYbQrasTzm7mBG6Iw7zqjVnZaGuR9W2ycK26afXGo4It 7ZGO2F8bP6Ohm7gDs0Tyni49TbwAy00uUhRrhNgwFlwsKD2vYse7GMR6YnHFFZCdJK3X IE8H8Z/Ms9aipyVMZWGCaU9LlDGabk5UFIynIlJY2nY5fFWHc6ItiShBZXNX2fj2YUcC bJ/k/EbTrcy4IoCvCU+qOxmyH5exUQyprtZQKuWrIzclBxh/bIDqt7LpMscana8qEQFm JeAw== MIME-Version: 1.0 X-Received: by 10.49.60.169 with SMTP id i9mr22438695qer.93.1372519531314; Sat, 29 Jun 2013 08:25:31 -0700 (PDT) Received: by 10.229.148.8 with HTTP; Sat, 29 Jun 2013 08:25:31 -0700 (PDT) Date: Sat, 29 Jun 2013 08:25:31 -0700 Message-ID: From: Dirk Balfanz To: IETF TLS WG Content-Type: multipart/alternative; boundary=047d7b6777981ca09904e04c9bc8 X-Gm-Message-State: ALoCoQkgbwXIksgE7OlY1JoxoJI/2XUaUdkppvZNL1gQBANkGTcq+UXZJTkzTSRvXqNPb2K7G3Vf19lOsRxtSF2M1/SMqiRXyrCY40dMOPdT9fRgKETg9Z/1vkkrzpVGxBV035ojBqzmICuc3LfO2taa0Puoj6G7KQq4pD6hrbQdIzB6yY4ybHrXak4RrhKLLzmRUsYf3/X4 Subject: [TLS] Fwd: New Version Notification for draft-balfanz-tls-channelid-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: Sat, 29 Jun 2013 15:25:34 -0000 --047d7b6777981ca09904e04c9bc8 Content-Type: text/plain; charset=ISO-8859-1 Hi guys, I uploaded a new draft of the Channel ID draft ( http://tools.ietf.org/html/draft-balfanz-tls-channelid-01). From the History of Changes: - Some clarifications, mostly around Channel ID and session state. - Added a section on Use Cases. - Expanded the Privacy Considerations sections to include discussion of third-party connections in HTTP user-agents. - Fixed some typos. The detailed diff is here: http://www.ietf.org/rfcdiff?url2=draft-balfanz-tls-channelid-01 I expect that at this point the main point of contention might be the entanglement with the EncryptedExtension stuff. I left that in for now - maybe we can talk about this in Berlin? Dirk. --047d7b6777981ca09904e04c9bc8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi guys,=A0

I uploaded a new draft of the Channel I= D draft (http://tools.ietf.org/html/draft-balfanz-tls-channeli= d-01). From the History of Changes:
  • Some clarifications, mostly around Channel ID and session state.
  • Added a section on Use Cases.
  • Expanded the Privacy Considerat= ions sections to include discussion=A0of third-party connections in HTTP us= er-agents.
  • Fixed some typos.
Th= e detailed diff is here:=A0http://www.ietf.org/rfcdiff= ?url2=3Ddraft-balfanz-tls-channelid-01

I expect th= at at this point the main point of contention might be the entanglement wit= h the EncryptedExtension stuff. I left that in for now - maybe we can talk = about this in Berlin?

Dirk.
=

--047d7b6777981ca09904e04c9bc8--