From pgut001@login01.cs.auckland.ac.nz Wed Nov 2 21:39:02 2011 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 D701011E80E8 for ; Wed, 2 Nov 2011 21:39:02 -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_39=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 wXrbCeiBw+EM for ; Wed, 2 Nov 2011 21:39:02 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id EE33811E8080 for ; Wed, 2 Nov 2011 21:39:01 -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=1320295142; x=1351831142; h=from:to:subject:message-id:date; bh=eqpUhk1Ue6BiKjXS3bMONgC2uB0Nld8yjiuP3brqvtM=; b=YQs8rWllb75AiufzetADwQiTSbvaYCi/mMzJ6Mk1X2NUxwjbs2lBsphg QU4E3Ohg//VBSip9CxCIyag+zfNfubDphFctXuOBPy/16c/jJosFG1Msx Ia2x7mX7/LZroaUqQ00oJwbKe/ymYmZL63akKebaycqL/xmMH6oC65EiN 4=; X-IronPort-AV: E=Sophos;i="4.69,447,1315137600"; d="scan'208";a="88622950" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.34.40 - Outgoing - Outgoing Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 03 Nov 2011 17:39:00 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1RLp4t-0004uz-Kr for tls@ietf.org; Thu, 03 Nov 2011 17:38:59 +1300 From: Peter Gutmann To: tls@ietf.org Message-Id: Date: Thu, 03 Nov 2011 17:38:59 +1300 Subject: [TLS] How many implementations of TLS 1.2 don't use SHA256 for sigs? 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, 03 Nov 2011 04:39:03 -0000 TLS 1.2 allows you to specify the sig.algorithm used for various things, alongside the bizarre choice of MD5 (why is that even in there?) there's an option to use SHA1 alongside the TLS 1.2 default SHA2-256. Are there any implementations of TLS 1.2 that don't do SHA2-256? Since the whole point of TLS 1.2 was to move away from SHA1, I'm considering disabling it in the possible SignatureAndHashAlgorithm options, but due to the practical nonexistence of TLS 1.2 in the real world it's a bit hard to determine what the consequences will be. Would any existing implementations break if I removed all mention of SHA1 from SignatureAndHashAlgorithm, and refused to accept it for things like keyex sigs? What are other implementations doing? Peter. From robert.cragie@gmail.com Wed Nov 2 22:25:23 2011 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 C1D3A11E8086 for ; Wed, 2 Nov 2011 22:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.376 X-Spam-Level: X-Spam-Status: No, score=-2.376 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_39=0.6, 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 AfahGAsV2nxs for ; Wed, 2 Nov 2011 22:25:23 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 20D2A11E808F for ; Wed, 2 Nov 2011 22:25:23 -0700 (PDT) Received: by vws5 with SMTP id 5so952207vws.31 for ; Wed, 02 Nov 2011 22:25:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:reply-to:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=IiVzlXQmlCaXezcb74clfIoIylkk/w8Q3A1+EFTocP8=; b=VNiO8JjrJlGHE3GjrtWKueDMXdPZ9AyeoWsqC/itWJgc245CUSMrMDWiPtTgBZhk3l XjZsE76ZIxjUnJMdUboff08EspBIJaoHFNeB0ubPpVZiUfVj0quxHnqWHceZIWwvHChV ejKVzAYITGvR6keiVZKErDCAHhX8TWDziYMhU= MIME-Version: 1.0 Received: by 10.52.28.141 with SMTP id b13mr7905725vdh.128.1320297916512; Wed, 02 Nov 2011 22:25:16 -0700 (PDT) Sender: robert.cragie@gmail.com Received: by 10.220.198.197 with HTTP; Wed, 2 Nov 2011 22:25:16 -0700 (PDT) In-Reply-To: References: Date: Thu, 3 Nov 2011 05:25:16 +0000 X-Google-Sender-Auth: dubnzdAvkOAeNqdagICEDn4q43s Message-ID: From: Robert Cragie To: Peter Gutmann Content-Type: multipart/alternative; boundary=20cf307ac0af4fb90b04b0cdd098 Cc: tls@ietf.org Subject: Re: [TLS] How many implementations of TLS 1.2 don't use SHA256 for sigs? 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: Thu, 03 Nov 2011 05:25:23 -0000 --20cf307ac0af4fb90b04b0cdd098 Content-Type: text/plain; charset=ISO-8859-1 One real world implementation of TLS 1.2 is in the ZigBee SEP 2.0 and ZigBee IP environment and we don't use SHA-1. Note the swathe of cipher suites in Appendix A.5 and the mandatory cipher suite use SHA-1. Is the proposal to clean that list up? Robert On Thu, Nov 3, 2011 at 4:38 AM, Peter Gutmann wrote: > TLS 1.2 allows you to specify the sig.algorithm used for various things, > alongside the bizarre choice of MD5 (why is that even in there?) there's an > option to use SHA1 alongside the TLS 1.2 default SHA2-256. Are there any > implementations of TLS 1.2 that don't do SHA2-256? Since the whole point > of > TLS 1.2 was to move away from SHA1, I'm considering disabling it in the > possible SignatureAndHashAlgorithm options, but due to the practical > nonexistence of TLS 1.2 in the real world it's a bit hard to determine what > the consequences will be. Would any existing implementations break if I > removed all mention of SHA1 from SignatureAndHashAlgorithm, and refused to > accept it for things like keyex sigs? What are other implementations > doing? > > Peter. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --20cf307ac0af4fb90b04b0cdd098 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable One real world implementation of TLS 1.2 is in the ZigBee SEP 2.0 and ZigBe= e IP environment and we don't use SHA-1.

Note the sw= athe of cipher suites in Appendix A.5 and the mandatory cipher suite use SH= A-1. Is the proposal to clean that list up?

Robert

On Thu, Nov 3,= 2011 at 4:38 AM, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote:
=
TLS 1.2 allows you to specify the sig.algorithm used for various things, alongside the bizarre choice of MD5 (why is that even in there?) there'= s an
option to use SHA1 alongside the TLS 1.2 default SHA2-256. =A0Are there any=
implementations of TLS 1.2 that don't do SHA2-256? =A0Since the whole p= oint of
TLS 1.2 was to move away from SHA1, I'm considering disabling it in the=
possible SignatureAndHashAlgorithm options, but due to the practical
nonexistence of TLS 1.2 in the real world it's a bit hard to determine = what
the consequences will be. =A0Would any existing implementations break if I<= br> removed all mention of SHA1 from SignatureAndHashAlgorithm, and refused to<= br> accept it for things like keyex sigs? =A0What are other implementations doi= ng?

Peter.
_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--20cf307ac0af4fb90b04b0cdd098-- From ynir@checkpoint.com Wed Nov 2 23:27:02 2011 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 37E1C1F0C54 for ; Wed, 2 Nov 2011 23:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[AWL=-0.152, BAYES_00=-2.599, J_CHICKENPOX_39=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 xvQ-HYgli-X9 for ; Wed, 2 Nov 2011 23:27:01 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 54CE21F0C42 for ; Wed, 2 Nov 2011 23:27:01 -0700 (PDT) X-CheckPoint: {4EB233CD-10005-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pA36QkAC026195; Thu, 3 Nov 2011 08:26:47 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 3 Nov 2011 08:26:46 +0200 From: Yoav Nir To: Peter Gutmann , "tls@ietf.org" Date: Thu, 3 Nov 2011 08:26:44 +0200 Thread-Topic: [TLS] How many implementations of TLS 1.2 don't use SHA256 for sigs? Thread-Index: AcyZ8Y9OmsFLtrHUTeigZJjiXxhzRA== 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.13.0.110805 acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [TLS] How many implementations of TLS 1.2 don't use SHA256 for sigs? 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, 03 Nov 2011 06:27:02 -0000 When writing my TLS 1.2 code I tested with all the clients I could find (IE8 with certain checkboxes checked, Opera, and OpenSSL) and none of them would break. On 11/3/11 6:38 AM, "Peter Gutmann" wrote: >TLS 1.2 allows you to specify the sig.algorithm used for various things, >alongside the bizarre choice of MD5 (why is that even in there?) there's >an >option to use SHA1 alongside the TLS 1.2 default SHA2-256. Are there any >implementations of TLS 1.2 that don't do SHA2-256? Since the whole point >of >TLS 1.2 was to move away from SHA1, I'm considering disabling it in the >possible SignatureAndHashAlgorithm options, but due to the practical >nonexistence of TLS 1.2 in the real world it's a bit hard to determine >what >the consequences will be. Would any existing implementations break if I >removed all mention of SHA1 from SignatureAndHashAlgorithm, and refused to >accept it for things like keyex sigs? What are other implementations >doing? > >Peter. >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls > >Scanned by Check Point Total Security Gateway. From pgut001@login01.cs.auckland.ac.nz Thu Nov 3 01:03:59 2011 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 1895211E8097 for ; Thu, 3 Nov 2011 01:03:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 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 HvxdZqhsXQnV for ; Thu, 3 Nov 2011 01:03:58 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id B67DE11E809A for ; Thu, 3 Nov 2011 01:03:56 -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=1320307438; x=1351843438; h=from:to:subject:in-reply-to:message-id:date; bh=T7KqKdK7kDrlx680gGRzZpf6J9IzgViEAjMVj6Ac4Aw=; b=C6r0i+txZJyaIutxqRquf8wOvJP/Z3TLPvhwpTd3P++oMiM1TjwIizzc TVDn0MrXT76pY50H5rilAnNPIRJxvD0hw5IJ4QTXBtewAajqXMu21JTDc R/MwZeNK9VniafgamlCwM+rLZV9fmFjbO983jw/nUqf9qZ0NnSrFsJ+Se I=; X-IronPort-AV: E=Sophos;i="4.69,448,1315137600"; d="scan'208";a="88635793" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.34.40 - Outgoing - Outgoing Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 03 Nov 2011 21:03:49 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1RLsH7-0007aw-3p; Thu, 03 Nov 2011 21:03:49 +1300 From: Peter Gutmann To: pgut001@cs.auckland.ac.nz, tls@ietf.org In-Reply-To: Message-Id: Date: Thu, 03 Nov 2011 21:03:49 +1300 Subject: Re: [TLS] How many implementations of TLS 1.2 don't use SHA256 for sigs? 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, 03 Nov 2011 08:03:59 -0000 Thanks to everyone who replied (on and off-list), in summary it looks like it's safe to run with SHA2-256 only (or at least no SHA-1) in TLS 1.2 mode. This also seems like the most consistent behaviour, since potential use of SHA-1 in the PRF (where it's used as HMAC-SHA1) is safe against any known attack while SHA-1 for sigs is potentially at risk, so using SHA2-256 for the PRF but SHA-1 for sigs seems like a bad idea. Peter. From mrex@sap.com Thu Nov 3 06:55:25 2011 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 1E38A11E8087 for ; Thu, 3 Nov 2011 06:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.126 X-Spam-Level: X-Spam-Status: No, score=-10.126 tagged_above=-999 required=5 tests=[AWL=0.123, 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 8f8p1opy4ktz for ; Thu, 3 Nov 2011 06:55:24 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 064FE11E8127 for ; Thu, 3 Nov 2011 06:55:23 -0700 (PDT) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id pA3DtDjK004725 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 3 Nov 2011 14:55:13 +0100 (MET) From: Martin Rex Message-Id: <201111031355.pA3DtCQu002471@fs4113.wdf.sap.corp> To: pgut001@cs.auckland.ac.nz (Peter Gutmann) Date: Thu, 3 Nov 2011 14:55:12 +0100 (MET) In-Reply-To: from "Peter Gutmann" at Nov 3, 11 09:03:49 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] How many implementations of TLS 1.2 don't use SHA256 for 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, 03 Nov 2011 13:55:25 -0000 Peter Gutmann wrote: > > Thanks to everyone who replied (on and off-list), in summary it looks like > it's safe to run with SHA2-256 only (or at least no SHA-1) in TLS 1.2 mode. > This also seems like the most consistent behaviour, since potential use of > SHA-1 in the PRF (where it's used as HMAC-SHA1) is safe against any known > attack while SHA-1 for sigs is potentially at risk, so using SHA2-256 for the > PRF but SHA-1 for sigs seems like a bad idea. It is actually a exceptionally stupid idea (by the TLSv1.2 spec) to use SHA-1 only(!!) in RSA signatures. Prior protocol versions have been using a stronger RSA signature based on a combination of SHA1 and MD5, so with the guaranteed availability of SHA-256, TLSv1.2 should have done away with SHA-1 entirely. FIPS 186-3 defines how to truncate SHA-256 for use with DSA and ECDSA in case that the key parameter(s) were made to match a 160-bit hash. This change would also have simplified the question about which hash to use for the handshake message hash in a TLSv1.2 handshake. It seems like a stupid waste to require a SHA-256 handshake message hash for the PRF and simultaneously a SHA-1 handshake message hash for the KeyExchange and CertificateVerify handshake messages. -Martin From jsalowey@cisco.com Tue Nov 8 13:54:05 2011 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 7EBC511E80CE for ; Tue, 8 Nov 2011 13:54:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.399 X-Spam-Level: X-Spam-Status: No, score=-106.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 71sshTkJWz7h for ; Tue, 8 Nov 2011 13:54:05 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 9887F11E80CF for ; Tue, 8 Nov 2011 13:54:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=188; q=dns/txt; s=iport; t=1320789244; x=1321998844; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=sIjuRfoUJbFWBf84BGXnJbid4btfrgWPVpaigIl83/I=; b=VDu+zMNdQVQq9402mK6lxVgluNx6CfPeM1cmZ8TQJWpgLcgo1FKSnKU+ ZQfuuP8Xr/9iGSBtb6SzHoohGCp015+yQzYPoExsabcTr95Cc0w2EBB/n WhxcSOcisyGFLLXwVmYKl7Dmw7ihZDUIKEuOFUo8IvRDv9Q5m5+b4PkWN k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkKAPSjuU6rRDoJ/2dsb2JhbABEmmCEAwIBihWBJoEFggsBJ4IZGYdol3CBJgGebIhKYwSIC4wWhTGMXg X-IronPort-AV: E=Sophos;i="4.69,479,1315180800"; d="scan'208";a="13045953" Received: from mtv-core-4.cisco.com ([171.68.58.9]) by mtv-iport-4.cisco.com with ESMTP; 08 Nov 2011 21:54:04 +0000 Received: from [10.33.251.254] ([10.33.251.254]) by mtv-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id pA8Ls2YC023161 for ; Tue, 8 Nov 2011 21:54:03 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Nov 2011 13:54:14 -0800 Message-Id: <115936DF-891D-4BEF-8E69-4CCC60D73F78@cisco.com> To: tls@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [TLS] IETF 82 Agenda 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, 08 Nov 2011 21:54:05 -0000 The IETF 82 Agenda for TLS has been posted in the usual place. Please = let me know if you have any corrections. http://www.ietf.org/proceedings/82/agenda/tls.txt Cheers, Joe= From paul@xelerance.com Tue Nov 8 14:11:52 2011 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 B1D811F0C4A; Tue, 8 Nov 2011 14:11:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.537 X-Spam-Level: X-Spam-Status: No, score=-6.537 tagged_above=-999 required=5 tests=[AWL=0.062, 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 iZ3kPy-Fp36m; Tue, 8 Nov 2011 14:11:52 -0800 (PST) Received: from mx.xelerance.com (mx.xelerance.com [193.110.157.188]) by ietfa.amsl.com (Postfix) with ESMTP id B514521F8B5B; Tue, 8 Nov 2011 14:11:51 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx.xelerance.com (Postfix) with ESMTP id 5EF7E587; Tue, 8 Nov 2011 17:11:49 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xelerance.com; h= content-type:content-type:mime-version:user-agent:references :message-id:in-reply-to:subject:subject:from:from:date:date :received:received:received:received; s=smtp; t=1320790308; x= 1321395108; bh=CPhr9rwmy0k/uIuGQ2Skyu3MMiU7GzfxSRYnWXTpPBc=; b=P /VE1G/8tIoZYb8JJLYQkGf5b1u1biGHnEXg2qbFxGV/FKTJbw6nEFSZR1M43ISud GsEcPk9BQcndsk2FrLWgLG0XO1jXGNGhQkGEnFy+X6PLgP2h8f6P4EfgBVOyX6Jl BhvGpa1V8bTODzQMuU0AmBv76oazEeRH5eneHVA/GQ= Received: from mx.xelerance.com ([127.0.0.1]) by localhost (mx.xelerance.com [127.0.0.1]) (amavisd-new, port 10026) with LMTP id rFMFpbk9J2Wf; Tue, 8 Nov 2011 17:11:48 -0500 (EST) Received: from mail.xelerance.com (mail.xelerance.com [193.110.157.189]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.xelerance.com (Postfix) with ESMTPS id CDE089E; Tue, 8 Nov 2011 17:11:45 -0500 (EST) Received: by mail.xelerance.com (Postfix, from userid 1001) id 0DB1E555; Tue, 8 Nov 2011 17:11:45 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.xelerance.com (Postfix) with ESMTP id 083DD554; Tue, 8 Nov 2011 17:11:45 -0500 (EST) Date: Tue, 8 Nov 2011 17:11:44 -0500 (EST) From: Paul Wouters To: Richard Barnes In-Reply-To: <56F1C4E4-91ED-410C-8D8B-52BDD2B63B3F@bbn.com> Message-ID: References: <055.95ec24e5e3679207360dec78550e2dcb@trac.tools.ietf.org> <070.002a6c7c40d00f53beb16725176b7266@trac.tools.ietf.org> <4EB95472.6020105@sv.cmu.edu> <56F1C4E4-91ED-410C-8D8B-52BDD2B63B3F@bbn.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: Zack Weinberg , tls@ietf.org, dane@ietf.org Subject: Re: [TLS] [dane] #13: Server name check for certificate type 1 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, 08 Nov 2011 22:11:52 -0000 On Tue, 8 Nov 2011, Richard Barnes wrote: > That is the correct behavior. The name matching algorithm is not a TLS-layer issue, but an application-layer one. > " > Some specifications for applications that run under TLS, such as > [RFC2818] for HTTP, require the server's certificate to have a domain > name that matches the host name expected by the client. Some > specifications such at [RFC6125] detail how to match the identify > given in a PKIX certificate with those expected by the user. > " That will require an update anyway for http://tools.ietf.org/html/draft-wouters-tls-oob-pubkey-01 Perhap this update needs to be made explicit in that draft to reflect this change. However, it would be nice if we did not have to force people to use raw pubkeys if they do not want to maintain a subjectAltname= list in their certificates but still want to take advantage of PKIX validation. Paul > > > On Nov 8, 2011, at 11:10 AM, Zack Weinberg wrote: > >> On 2011-11-08 2:39 AM, dane issue tracker wrote: >>> #13: Server name check for certificate type 1 >>> This addressed in draft-ietf-dane-protocol-12 in Sections 2.1, 2.2, 2.3, >>> most of section 4 and Appendix B. >> >> I'm sorry I missed this when you sent out the call for comments. I do not believe this issue has been adequately addressed in -12. In particular, when the end-entity certificate matches a valid TLSA record but does NOT contain embedded name information matching the hostname under which the record was found, client behavior is unspecified. >> >> (It's possible that you think "pass PKIX validation" covers this case, but that term is ill-defined to the point where I think it needs to be eradicated from the spec.) >> >> (I was not able to resolve this issue in my rewrite because I don't know what the client *ought* to do in this circumstance, only that there needs to be a specified behavior.) >> >> zw >> _______________________________________________ >> dane mailing list >> dane@ietf.org >> https://www.ietf.org/mailman/listinfo/dane > > _______________________________________________ > dane mailing list > dane@ietf.org > https://www.ietf.org/mailman/listinfo/dane > From yuhongbao_386@hotmail.com Fri Nov 11 09:11:23 2011 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 9B39B21F8669 for ; Fri, 11 Nov 2011 09:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.855 X-Spam-Level: X-Spam-Status: No, score=-1.855 tagged_above=-999 required=5 tests=[AWL=0.745, 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 xWYKO9BLVBQc for ; Fri, 11 Nov 2011 09:11:23 -0800 (PST) Received: from snt0-omc1-s9.snt0.hotmail.com (snt0-omc1-s9.snt0.hotmail.com [65.55.90.20]) by ietfa.amsl.com (Postfix) with ESMTP id E6EAE21F8A62 for ; Fri, 11 Nov 2011 09:11:22 -0800 (PST) Received: from SNT125-W38 ([65.55.90.8]) by snt0-omc1-s9.snt0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Nov 2011 09:11:22 -0800 Message-ID: X-Originating-IP: [76.178.157.127] From: Yuhong Bao To: Date: Fri, 11 Nov 2011 09:11:22 -0800 Importance: Normal In-Reply-To: <479CAD406474484E8FA0E39E694732C017E56B9F@DF-M14-01.exchange.corp.microsoft.com> References: , <479CAD406474484E8FA0E39E694732C017E56B9F@DF-M14-01.exchange.corp.microsoft.com> Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Nov 2011 17:11:22.0853 (UTC) FILETIME=[EFF84150:01CCA094] Cc: tls@ietf.org Subject: Re: [TLS] A request to the SChannel team 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, 11 Nov 2011 17:11:23 -0000 But the incorrect version checking on the premaster secret is definitely a = bug=2C and I am CCing the TLS mailing list as they were encountering troubl= e with it. Yuhong Bao ________________________________ > From: ericlaw@exchange.microsoft.com=20 > To: yuhongbao_386@hotmail.com=20 > Subject: RE: MSDN Blogs: Contact request: A request to the SChannel team= =20 > Date: Fri=2C 11 Nov 2011 13:52:19 +0000=20 > =20 > =20 > It takes only two clicks to enable TLS1.1 and 1.2=3B or run =20 > http://go.microsoft.com/?linkid=3D9784203=20 > =20 > =20 > =20 > It=92s not quite correct to call TCP RST fallback =93proper=94 since the = =20 > server is misbehaving. But fallback is a WinINET behavior=2C not =20 > SChannel=2C and it=92s something we=92re looking at.=20 > =20 > =20 > =20 > Thanks.=20 > =20 > =20 > =20 > From: Yuhong Bao [mailto:yuhongbao_386@hotmail.com]=20 > Sent: Thursday=2C November 10=2C 2011 11:34 PM=20 > To: Eric Lawrence=20 > Subject: MSDN Blogs: Contact request: A request to the SChannel team=20 > =20 > =20 > =20 > Subject: A request to the SChannel team=20 > =20 > =20 > =20 > Can you ask the Windows SChannel team to push out an update on Windows =20 > Update to Win7/Server2008R2 that fixes the following problems: - =20 > Incorrect version checking on the premaster secret - =20 > http://www.ietf.org/mail-archive/web/tls/current/msg08139.html - Have =20 > the TCP RST response properly cause fallback to TLS 1.0 - =20 > http://blogs.msdn.com/b/ieinternals/archive/2011/03/25/misbehaving-https-= servers-impair-tls-1.1-and-tls-1.2.aspx =20 > And maybe enable TLS 1.1 and 1.2 by default on the server side.=20 > =20 > This contact request was sent from MSDN Blogs by = =20 > Yuhong Bao without sharing your email address.=20 = From mrex@sap.com Fri Nov 11 14:08:07 2011 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 29D4621F8A7D for ; Fri, 11 Nov 2011 14:08:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.113 X-Spam-Level: X-Spam-Status: No, score=-10.113 tagged_above=-999 required=5 tests=[AWL=0.136, 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 JPuvxnTCo1DM for ; Fri, 11 Nov 2011 14:08:06 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0997421F8A7E for ; Fri, 11 Nov 2011 14:08:05 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id pABM7q3J012655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 11 Nov 2011 23:07:52 +0100 (MET) From: Martin Rex Message-Id: <201111112207.pABM7qAQ014491@fs4113.wdf.sap.corp> To: yuhongbao_386@hotmail.com (Yuhong Bao) Date: Fri, 11 Nov 2011 23:07:52 +0100 (MET) In-Reply-To: from "Yuhong Bao" at Nov 11, 11 09:11:22 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org, ericlaw@exchange.microsoft.com Subject: Re: [TLS] A request to the SChannel team X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 Nov 2011 22:08:07 -0000 Yuhong Bao wrote: > > But the incorrect version checking on the premaster secret is definitely > a bug, and I am CCing the TLS mailing list as they were encountering > trouble with it. > > > From: ericlaw@exchange.microsoft.com > > > > It takes only two clicks to enable TLS1.1 and 1.2; or run > > http://go.microsoft.com/?linkid=9784203 > > > > It's not quite correct to call TCP RST fallback "proper" since the > > server is misbehaving. But fallback is a WinINET behavior, not > > SChannel, and it's something we're looking at. Since you brought it up again, I became curious and looked at the handshake with Wireshark to determine the *REAL* situation. There seem to be several Bugs in Win7 SChannel and the WinINET fallback logic. According to my wireshark trace, when I use MSIE on Win7 with TLSv1.1 and TLSv1.2 enabled to connect a Server, Win7 will send a ClientHello with protocol_version { 0x03, 0x03 } at the SSL record layer in addition to { 0x03, 0x03 } in the client_version field of the ClientHello handshake message. Now that is an obviously stupid idea to tag the first TLS Record as a TLSv1.2 PDU, when you desire a negotiation of an earlier TLS version number, because that may preclude a perfectly correct and sensible implementations of earlier an TLS protocol version to even look at the contents (ClientHello) of that TLSv1.2 PDU (TLS Record) and abort with a fatal protocol version alert instead. The only reasonable behaviour for the TLS client, with respect to the *original* SSL/TLS protocol design, is to use the lowest protocol version that the client is willing to use on all of the SSL records that convey the initial ClientHello handshake message of a new connection. (but I should point out that fragmenting TLS handshake messages would likely cause interop problems with a significant fraction of the installed base and is discouraged, so there is typically just one initial SSL record with the entire ClientHello handshake message on a new connection). The TCP RST on the socket is the result of the perfectly valid server behaviour to close the socket of a fatally failed TLS handshake without lingering. That is a pretty normal act of self-defense and resource conservation that every *sensible* server implementation will be using. Unless the connection is in a "good" state, a server can not be expected to linger on it when it disposes associated resources, that would just increase the DoS attack surface by factors at zero value. -Martin From balfanz@google.com Mon Nov 14 10:35:58 2011 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 EFEAF11E81C5 for ; Mon, 14 Nov 2011 10:35:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.976 X-Spam-Level: X-Spam-Status: No, score=-102.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, 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 eA4D3NYVki9H for ; Mon, 14 Nov 2011 10:35:58 -0800 (PST) Received: from mail-qw0-f44.google.com (mail-qw0-f44.google.com [209.85.216.44]) by ietfa.amsl.com (Postfix) with ESMTP id 55DFF11E81B0 for ; Mon, 14 Nov 2011 10:35:58 -0800 (PST) Received: by qadb40 with SMTP id b40so4749654qad.10 for ; Mon, 14 Nov 2011 10:35:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:date:message-id:subject:from:to:cc:content-type :x-system-of-record; bh=zvMX/OwbudHUyPfvGk/9f2Zr4jYPGN4wcJ0xNViMSuk=; b=MymMa3HeSXp4uL8htRNmWq2wgsU1+S8ADulWDzVLNkOIRQaztFLUYZPx/My6jgmqCb EWlamQKNhxuec3SfqRJQ== Received: by 10.224.211.194 with SMTP id gp2mr14836588qab.99.1321294438573; Mon, 14 Nov 2011 10:13:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.224.211.194 with SMTP id gp2mr14836566qab.99.1321294438356; Mon, 14 Nov 2011 10:13:58 -0800 (PST) Received: by 10.229.83.133 with HTTP; Mon, 14 Nov 2011 10:13:58 -0800 (PST) Date: Mon, 14 Nov 2011 10:13:58 -0800 Message-ID: From: Dirk Balfanz To: tls@ietf.org Content-Type: multipart/alternative; boundary=20cf300fb1fba458e504b1b5d5c8 X-System-Of-Record: true Subject: [TLS] new TLS-OBC revision 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, 14 Nov 2011 18:35:59 -0000 --20cf300fb1fba458e504b1b5d5c8 Content-Type: text/plain; charset=ISO-8859-1 Hi guys, I uploaded revision 01 of the TLS-OBC draft. It's available at http://tools.ietf.org/html/draft-balfanz-tls-obc-01. Since the discussion here has been mostly neutral to favorable, there are very few changes: - a couple of editorial changes along the lines of changing a SHOULD to MUST, fixing typos in OIDs, etc. - some more explanation about the web origin that's embedded in the client cert. - fixed the reference to the Encrypted Client Certificates TLS extension - added key length recommendations in security considerations section. The full diff can be seen here: http://tools.ietf.org/rfcdiff?url2=draft-balfanz-tls-obc-01 What didn't change, although it was brought up during the discussion here: - the web origin in the client cert is still a IA5String. This is in line with encoding of URIs in other standards, for example RFC 5280. - I didn't talk about cookie hardening through channel binding in the abstract, since I didn't want to conflate layers in the "normative" part of the spec. (I left it in the security considerations section). As always, comments are welcome! Wan-Teh will be talking about the new revision at IETF 82 on Thursday. Dirk. --20cf300fb1fba458e504b1b5d5c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi guys,=A0

I uploaded revision 01 of the TLS= -OBC draft. It's available at=A0http://tools.ietf.org/html/draft-balfanz-tls-obc-0= 1.

Since the discussion here has been mostly neutral to fa= vorable, there are very few changes:

- a couple of= editorial changes along the lines of changing a SHOULD to MUST, fixing typ= os in OIDs, etc.
- some more explanation about the web origin that's embedded in th= e client cert.
- fixed the reference to the Encrypted Client Cert= ificates TLS extension
- added key length recommendations in secu= rity considerations section.


Wha= t didn't change, although it was brought up during the discussion here:=

- the web origin in the client cert is still a IA5Strin= g. This is in line with encoding of URIs in other standards, for example RF= C 5280.

- I didn't talk about cookie hardening= through channel binding in the abstract, since I didn't want to confla= te layers in the "normative" part of the spec. (I left it in the = security considerations section).

As always, comments are welcome! Wan-Teh will be talkin= g about the new revision at IETF 82 on Thursday.

D= irk.

--20cf300fb1fba458e504b1b5d5c8-- From fabrice.gautier@gmail.com Mon Nov 14 15:56:16 2011 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 291CA21F8B56 for ; Mon, 14 Nov 2011 15:56:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCMG9av5uLAA for ; Mon, 14 Nov 2011 15:56:15 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id A22A421F8B51 for ; Mon, 14 Nov 2011 15:56:15 -0800 (PST) Received: by iaeo4 with SMTP id o4so10072452iae.31 for ; Mon, 14 Nov 2011 15:56:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:from:date:message-id:subject:to:content-type; bh=NLbpIAjLfL7KLzifr7Bqfa83rPAB5c9zbTMcdgsh+ho=; b=EU2XNmhfr/6LOWCPy/12e7ESTi34NpZvsrNoiBAxP4ND6NQbW9scTDgtlPfevzGMHQ LlHj9n4SSYjt1IB0NQLp/dDV2UL39qegAytThNJzQzliBWUuZ3FQY2+yxPzVNXJxIrzK vuftv93r+2UwYxOIXEUcloQ1ahk35z/IYa3qs= Received: by 10.231.48.142 with SMTP id r14mr5836690ibf.5.1321314975194; Mon, 14 Nov 2011 15:56:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.231.14.70 with HTTP; Mon, 14 Nov 2011 15:55:54 -0800 (PST) From: Fabrice Gautier Date: Mon, 14 Nov 2011 15:55:54 -0800 Message-ID: To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [TLS] How does a TLS server indicates which EC curves it supports for client side auth ? 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, 15 Nov 2011 00:05:47 -0000 Hi, A TLS client specifies which curves and point formats it supports in a ClientHello extension. For the ServerHello, RFC 4492 only specifies the point format extension. No supported curves is returned as part of the ServerHello. When it comes to client side cert with ECDSA, TLS 1.2 RFC 5246, section 7.4.6 (Client Certificate) reads: ecdsa_sign ECDSA-capable public key; the certificate MUST allow the key to be used for signing with the hash algorithm that will be employed in the certificate verify message; the public key MUST use a curve and point format supported by the server. I've an issue with the last bit: "the public key MUST use a curve and point format supported by the server." At that point, how does the client know what curves are supported by the server ? In TLS 1.2, the CertificateRequest message specify which Signature and Hash algorithm are supported by the server, but I can't find such information for Curves parameters. Thanks -- Fabrice From pgut001@login01.cs.auckland.ac.nz Mon Nov 14 17:23:11 2011 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 0225D1F0D21 for ; Mon, 14 Nov 2011 17:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 ElDPUyYmDI48 for ; Mon, 14 Nov 2011 17:23:10 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF0D1F0CF6 for ; Mon, 14 Nov 2011 17:23:10 -0800 (PST) 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=1321320190; x=1352856190; h=from:to:subject:in-reply-to:message-id:date; bh=vOx3JGcCrriOXU28UrAKuqFQQHkQJVa2tpH/8JMupZU=; b=AKg5rKwOnYqBZ/5H3IQFbpwRtj4Z0iGesJu+NFBkt1l6iz0AziQX32Je tt9lQ5lrGnKVA759ueMQlJWhFDq6RTxn9dDe0p52mqcgxfS7zGUC20lLG pBxVA8yApLj/WJEcKBVwuqS2GmHNmDqQaJe7dv44CMT1OjWDoXLtM17ey A=; X-IronPort-AV: E=Sophos;i="4.69,512,1315137600"; d="scan'208";a="90324384" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.34.40 - Outgoing - Outgoing Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 15 Nov 2011 14:23:03 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1RQ7jr-0006TK-9Z; Tue, 15 Nov 2011 14:23:03 +1300 From: Peter Gutmann To: fabrice.gautier@gmail.com, tls@ietf.org In-Reply-To: Message-Id: Date: Tue, 15 Nov 2011 14:23:03 +1300 Subject: Re: [TLS] How does a TLS server indicates which EC curves it supports for client side auth ? 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, 15 Nov 2011 01:23:11 -0000 Fabrice Gautier writes: >At that point, how does the client know what curves are supported by the >server ? It's quite a mess. See: http://tools.ietf.org/html/draft-gutmann-tls-eccsuites-01 for a longer discussion of these issues, and a solution. I'm just waiting for the IETF blackout period to end to re-post the draft. And having said that, since it's been out for six months and there have been no major objections to it, it's probably time to move it towards RFC status so that people can actually make use of it. Peter. From ynir@checkpoint.com Mon Nov 14 17:50:47 2011 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 9548511E8153 for ; Mon, 14 Nov 2011 17:50:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.402 X-Spam-Level: X-Spam-Status: No, score=-10.402 tagged_above=-999 required=5 tests=[AWL=0.197, 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 NzsMDy-SWlQn for ; Mon, 14 Nov 2011 17:50:47 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id ACE5711E80CC for ; Mon, 14 Nov 2011 17:50:46 -0800 (PST) X-CheckPoint: {4EC1C532-2-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pAF1oeV1029195; Tue, 15 Nov 2011 03:50:40 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Tue, 15 Nov 2011 03:50:40 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Tue, 15 Nov 2011 03:50:39 +0200 From: Yoav Nir To: Peter Gutmann Date: Tue, 15 Nov 2011 03:50:37 +0200 Thread-Topic: [TLS] How does a TLS server indicates which EC curves it supports for client side auth ? Thread-Index: AcyjOPmGWYkLqnLhSxaKJy0/IYLBtg== Message-ID: <74A3EFD1-B8A9-4624-9432-51BBF7B0AF11@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "tls@ietf.org" Subject: Re: [TLS] How does a TLS server indicates which EC curves it supports for client side auth ? 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, 15 Nov 2011 01:50:47 -0000 On Nov 15, 2011, at 9:23 AM, Peter Gutmann wrote: > Fabrice Gautier writes: >=20 >> At that point, how does the client know what curves are supported by the >> server ? >=20 > It's quite a mess. See: >=20 > http://tools.ietf.org/html/draft-gutmann-tls-eccsuites-01 >=20 > for a longer discussion of these issues, and a solution. I'm just waitin= g for > the IETF blackout period to end to re-post the draft. >=20 > And having said that, since it's been out for six months and there have b= een > no major objections to it, it's probably time to move it towards RFC stat= us so > that people can actually make use of it. Blackout period is over as of yesterday. I think there will be some objections, because what you are proposing can a= lready be done with existing ciphersuites (although with the "chinese menu"= for ECC curves) From n.mavrogiannopoulos@gmail.com Mon Nov 14 23:44:56 2011 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 ECFB511E81E5 for ; Mon, 14 Nov 2011 23:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNaaO8a+l9EZ for ; Mon, 14 Nov 2011 23:44:56 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 30AC711E8096 for ; Mon, 14 Nov 2011 23:44:56 -0800 (PST) Received: by eyg24 with SMTP id 24so6145655eyg.31 for ; Mon, 14 Nov 2011 23:44:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=xpooLA22A9da3SyYnIvj53COGFaZdHvefu335Os5rfo=; b=Sgy4D+QkGEZWoLpIv1lM7RWdhxWnCdP55n1taAAU6K+8jynTCWb2vay96EYG92bjBQ iWBFUioDpoxEvC2j7FuZmS3eas1GsXhl8Q+GKnjfE3548W3lVkowvac+fHpV9yy7UxYQ fve01B7S/bX1qkAkaeeCmhHqawDvjT/FJVyAE= Received: by 10.14.16.66 with SMTP id g42mr1980951eeg.106.1321343095330; Mon, 14 Nov 2011 23:44:55 -0800 (PST) Received: from [10.100.2.14] (d51A49E78.access.telenet.be. [81.164.158.120]) by mx.google.com with ESMTPS id 5sm65835252eev.2.2011.11.14.23.44.54 (version=SSLv3 cipher=OTHER); Mon, 14 Nov 2011 23:44:54 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <4EC218E5.1060203@gnutls.org> Date: Tue, 15 Nov 2011 08:46:45 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Icedove/3.1.15 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] How does a TLS server indicates which EC curves it supports for client side auth ? 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, 15 Nov 2011 07:44:57 -0000 On 11/15/2011 12:55 AM, Fabrice Gautier wrote: > Hi, > > A TLS client specifies which curves and point formats it supports in a > ClientHello extension. For the ServerHello, RFC 4492 only specifies > the point format extension. No supported curves is returned as part of > the ServerHello. > > > When it comes to client side cert with ECDSA, TLS 1.2 RFC 5246, > section 7.4.6 (Client Certificate) reads: > > ecdsa_sign ECDSA-capable public key; the certificate MUST > allow the key to be used for signing with the > hash algorithm that will be employed in the > certificate verify message; the public key > MUST use a curve and point format supported by > the server. > > I've an issue with the last bit: "the public key MUST use a curve and > point format supported by the server." > At that point, how does the client know what curves are supported by > the server ? It does not. RFC5480 however, recommends for interoperability few curves in the security considerations section. Those seem to be the curves used by most implementations. I've taken an alternative approach to Peter and documented those as recommended for TLS as well. http://tools.ietf.org/html/draft-mavrogiannopoulos-tls-dss-01 regards, Nikos From mbadra@gmail.com Wed Nov 16 00:25:20 2011 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 A8D0121F942F for ; Wed, 16 Nov 2011 00:25:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, 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 4mEzg6lW1g9b for ; Wed, 16 Nov 2011 00:25:19 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3841721F9418 for ; Wed, 16 Nov 2011 00:25:19 -0800 (PST) Received: by vcbfl15 with SMTP id fl15so254905vcb.31 for ; Wed, 16 Nov 2011 00:25:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=PmY+UFTxxw7AWzWGSg4SntHyX6mHfEVNGGmx3kMkiKQ=; b=ms+Bqib9tKrW1WZdmUFkOk8liQk0GxR8kZppdP55gl8ASIMV0JgcWwLQ/czzfQa2fh AWj81m/SL60s1VYUNt72QgLpHgApz2o7pW7U2ywa7EmnnGrINuHOj9CY3MS0rGdI8pt9 +iZ7mP5QzPF+2OEVN1iHM2KYBbwcqawWcUE2o= MIME-Version: 1.0 Received: by 10.220.16.207 with SMTP id p15mr3329445vca.234.1321431918803; Wed, 16 Nov 2011 00:25:18 -0800 (PST) Received: by 10.220.201.71 with HTTP; Wed, 16 Nov 2011 00:25:18 -0800 (PST) In-Reply-To: References: Date: Wed, 16 Nov 2011 12:25:18 +0400 Message-ID: From: Badra To: tls@ietf.org Content-Type: multipart/alternative; boundary=000e0cd531001d7b1204b1d5d80d Subject: [TLS] Fwd: Client TLS Identity Protection: draft-hajjeh-tls-identity-protection-09.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 08:25:20 -0000 --000e0cd531001d7b1204b1d5d80d Content-Type: text/plain; charset=ISO-8859-1 Dear TLS WG members, It's been a couple of years since "Client TLS Identity Protection" was discussed on the TLS mailing list. On Dec 21, 2009, the IESG approved the publication of draft draft-hajjeh-tls-identity-protection-09.txt as an Experimental RFC. We proved by a working implementation that the difficulties and side effects on a TLS implementation caused by implementing the draft are not so serious as has been feared by the reviewers and the IESG, and that the complexity of an implementation is clearly limited and manageable. If you support reconsidering that draft with IANA registration for ciphersuite code points in the "specification required" range (before asking for its sign-off in the IESG), kindly please say so on the mailing list, like that I will inform the RFC-Ed to postpone its publication. Best regards, Badra --000e0cd531001d7b1204b1d5d80d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear TLS WG members,

It's been a couple of years since "Client TLS Identity Protecti= on" was discussed on the TLS mailing list.

On= Dec 21, 2009, the IESG approved the publication of draft draft-hajjeh-tls-= identity-protection-09.txt as an Experimental RFC.

We proved by a working implementation that the difficul= ties and side effects on a TLS implementation caused by implementing the dr= aft are not so serious as has been feared by the reviewers and the IESG, an= d that the complexity of an implementation is clearly limited and manageabl= e.

If you support reconsidering that draft with IANA regis= tration for ciphersuite code points in the "specification required&quo= t; range (before asking for its sign-off in the IESG), kindly please say so= on the mailing list, like that I will inform the RFC-Ed to postpone its pu= blication.

Best regards,
Badra
 --000e0cd531001d7b1204b1d5d80d-- From jsalowey@cisco.com Wed Nov 16 01:28:10 2011 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 234DE21F94F0 for ; Wed, 16 Nov 2011 01:28:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAj47sNmtl-p for ; Wed, 16 Nov 2011 01:28:09 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5333221F94EE for ; Wed, 16 Nov 2011 01:28:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=1789; q=dns/txt; s=iport; t=1321435689; x=1322645289; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=ROWyiQir8WJYRwwrtRNelXeYrVV+O1Swj8fYr1SbjPs=; b=Tz+UF7amujcZhqznOmOxVJkWvDm1czEmGirwNWjkrrhJmkMBMCp5c3Yq 1vHMhXCyb9fziHledLzNkvVwKCmxltgrnORlbOmxmKaYDiVE/CBosHGA4 7+PWuL1Rn2ErTgFpauKFYk36b7jCBwAaC7ceIJ6z+aqzeW0GZ4MKgYbq9 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAIKBw05Io8US/2dsb2JhbABDqXOBBYILASc0gX6geIEmAZ5bhwKCMmMEiBSMIJId X-IronPort-AV: E=Sophos;i="4.69,520,1315180800"; d="scan'208";a="121753414" Received: from bgl-core-3.cisco.com ([72.163.197.18]) by ams-iport-1.cisco.com with ESMTP; 16 Nov 2011 09:28:07 +0000 Received: from dhcp-1319.meeting.ietf.org (hkidc-vpn-client-234-6.cisco.com [10.75.234.6]) by bgl-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id pAG9S61u028345 for ; Wed, 16 Nov 2011 09:28:06 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 16 Nov 2011 01:28:04 -0800 Message-Id: To: tls@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [TLS] Process for TLS Extensions 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, 16 Nov 2011 09:28:10 -0000 Below is a statement on the process for TLS extensions that we worked on = with Sean Turner with helpful input from Paul Hoffman. We will have = some discussion on this in the Taipei meeting and on the TLS list. =20 RFC 5246 defines an extensibility mechanism for TLS based on extensions signaled in the ClientHello and ServerHello. With TLS 1.2 and DTLS 1.2 being relatively stable, we are starting to see more proposed extensions, some of which, if used, represent significant changes to the TLS processing model or state machine. RFC 5246 requires IETF consensus for any extension, either through individual submission to an Area Director or to the TLS Working Group (for as long as the WG exists). Any proposed extension can be brought to the Security Area Director as an individual submission for IETF consensus; it can also be brought=20= directly to the TLS WG. In the former case, the Area Director will decide whether he/she believes the extension needs to be processed through the TLS WG or just to process it through IETF Last Call. This decision will be made based on the level of impact the extension would have on TLS. Specifically, any extension which would cause a significant change to the TLS processing model or state machine will be referred to the TLS WG. The Security Area Director may also ask the WG chairs and other active TLS participants ahead of time about whether or not a particular proposal should be processed (if at all) in the TLS WG. The AD may decide not to allow an extension to progress based on feedback from the working group and other sources. In the case of drafts going through IETF Last Call, the TLS WG mailing list will be informed of the IETF Last Call ahead of or concurrently with the Last Call. From agl@google.com Wed Nov 16 07:34:28 2011 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 6E7D821F94D1 for ; Wed, 16 Nov 2011 07:34:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RP52pqQGHkKH for ; Wed, 16 Nov 2011 07:34:27 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id A79BC21F94C9 for ; Wed, 16 Nov 2011 07:34:27 -0800 (PST) Received: by ywt34 with SMTP id 34so8097461ywt.31 for ; Wed, 16 Nov 2011 07:34:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-system-of-record; bh=HK32Qn66fXMfuOfCuUi+A/yQaYj/RdMk855nS7jXOtA=; b=JKc93UpHtPqy5gwesytJ+DiXg5+a4B9An1RE/sFFm/u0ZgDYyZIU0eJp/kWz3/H3eT ycUkVPIHLM1OCWp8FlLw== Received: by 10.50.85.129 with SMTP id h1mr32943754igz.47.1321457667199; Wed, 16 Nov 2011 07:34:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.85.129 with SMTP id h1mr32943743igz.47.1321457667073; Wed, 16 Nov 2011 07:34:27 -0800 (PST) Sender: agl@google.com Received: by 10.231.37.195 with HTTP; Wed, 16 Nov 2011 07:34:27 -0800 (PST) In-Reply-To: References: Date: Wed, 16 Nov 2011 10:34:27 -0500 X-Google-Sender-Auth: h1F1485zyv1b40mkuue5ON766mo Message-ID: From: Adam Langley To: Badra Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: Wan-Teh Chang , tls@ietf.org Subject: Re: [TLS] Fwd: Client TLS Identity Protection: draft-hajjeh-tls-identity-protection-09.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 15:34:28 -0000 On Wed, Nov 16, 2011 at 3:25 AM, Badra wrote: > It's been a couple of years since "Client TLS Identity Protection" was > discussed on the TLS mailing list. My colleague, Wan-Teh, will be presenting something very similar at IETF 82 this week http://tools.ietf.org/html/draft-agl-tls-encryptedclientcerts-00 Cheers AGL From n.mavrogiannopoulos@gmail.com Wed Nov 16 08:36:13 2011 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 4898B21F9471 for ; Wed, 16 Nov 2011 08:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AoeMh-lCyVCt for ; Wed, 16 Nov 2011 08:36:06 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5419821F8B53 for ; Wed, 16 Nov 2011 08:36:06 -0800 (PST) Received: by wyf28 with SMTP id 28so844406wyf.31 for ; Wed, 16 Nov 2011 08:36:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=QHxjqAPB7lH537ZS2cBTEmF7oieGQN11zA+edsmqRpI=; b=VV4wwPvQBKClXQxh04kCJAXp6H9LRcLlJJm5JbuSR4qW4YE7k29u81IFWcTGkhYkm2 Ocw5sh2S8jTeAH0afPsGF140JlvCTJ/DaDPWc230oc7V8Z+4zc8sad/nNl+oxh16Qkob KsWB/NlYuVFa+lMQXYT+7YdsE2efUYbgcVRqc= MIME-Version: 1.0 Received: by 10.180.74.141 with SMTP id t13mr36110468wiv.68.1321461361644; Wed, 16 Nov 2011 08:36:01 -0800 (PST) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.180.24.165 with HTTP; Wed, 16 Nov 2011 08:36:01 -0800 (PST) In-Reply-To: References: Date: Wed, 16 Nov 2011 17:36:01 +0100 X-Google-Sender-Auth: mRBwgG9WMMhHoYqyccuz0QWhbK8 Message-ID: From: Nikos Mavrogiannopoulos To: Adam Langley Content-Type: text/plain; charset=UTF-8 Cc: Wan-Teh Chang , tls@ietf.org Subject: Re: [TLS] Fwd: Client TLS Identity Protection: draft-hajjeh-tls-identity-protection-09.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 16:36:13 -0000 On Wed, Nov 16, 2011 at 4:34 PM, Adam Langley wrote: > On Wed, Nov 16, 2011 at 3:25 AM, Badra wrote: >> It's been a couple of years since "Client TLS Identity Protection" was >> discussed on the TLS mailing list. > My colleague, Wan-Teh, will be presenting something very similar at > IETF 82 this week > http://tools.ietf.org/html/draft-agl-tls-encryptedclientcerts-00 I like that approach, but I don't like that only client certificates are hidden. Whether client and server are actually distinct is application specific, and hiding only one side might not always make sense. Why not move both certificate messages (client and server) after the changecipherspec? That way TLS will operate as IPSec and offer anonymity against passive eavesdroppers. regards, Nikos From mike-list@pobox.com Wed Nov 16 09:13:12 2011 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 91DA821F9290 for ; Wed, 16 Nov 2011 09:13:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APNFkup0pw5b for ; Wed, 16 Nov 2011 09:13:12 -0800 (PST) Received: from smtp.pobox.com (b-pb-sasl-quonix.pobox.com [208.72.237.35]) by ietfa.amsl.com (Postfix) with ESMTP id 0359521F928D for ; Wed, 16 Nov 2011 09:13:10 -0800 (PST) Received: from smtp.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id 80BA04FE4 for ; Wed, 16 Nov 2011 12:13:07 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=mime-version :content-type:content-transfer-encoding:date:from:to:subject :in-reply-to:references:message-id; s=sasl; bh=IIC9wyOTEckOPKC4K k1Uy72Efco=; b=VGQQ9/iI2VqzHFKVCn5RFgoCSXRcvFs+gdVyAn/ye181q7aDd OGj8uaBtyYnwV8xK9MQCOTtS3riCOZKOpYkBorKnp8IuFmcH2cu7VZOVNpMFEw7y iSvlkKl09fpScVEckl5bR5AcD5OzdGJxoVq3oitGqbRtU0j4v+D6d1tOJk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=mime-version :content-type:content-transfer-encoding:date:from:to:subject :in-reply-to:references:message-id; q=dns; s=sasl; b=UET/e0/YEiQ 63Bm9sy5tTgcnENrpjkQR5gqD/7kg1bWIgthNL3n1QdQADI6UGCL3YziV66C9SBx xpzZD6VtnGgK+fdwtF6POEjk2WgueOi16VlaJXU5GLC0hBGy8LWj0cEHx4i+fvHv wR/81AkMHO8YdMt8zqiJwGP1myNzZVdk= Received: from b-pb-sasl-quonix.pobox.com (unknown [127.0.0.1]) by b-sasl-quonix.pobox.com (Postfix) with ESMTP id 75CE74FE2 for ; Wed, 16 Nov 2011 12:13:07 -0500 (EST) Received: from webmail.pobox.com (unknown [208.72.237.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by b-sasl-quonix.pobox.com (Postfix) with ESMTPSA id 4385C4FE0 for ; Wed, 16 Nov 2011 12:13:07 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Date: Wed, 16 Nov 2011 12:13:07 -0500 From: Michael D'Errico To: In-Reply-To: References: Message-ID: <3d51f9e7878dbd581a9c4e9f91973436@pobox.com> X-Sender: mike-list@pobox.com User-Agent: RoundCube Webmail/0.3-RC1 X-Pobox-Relay-ID: 408B3A40-1076-11E1-A2C8-9DB42E706CDE-38729857!b-pb-sasl-quonix.pobox.com Subject: Re: [TLS] Fwd: Client TLS Identity Protection: draft-hajjeh-tls-identity-protection-09.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 17:13:12 -0000 On Wed, 16 Nov 2011 17:36:01 +0100, Nikos Mavrogiannopoulos wrote: > On Wed, Nov 16, 2011 at 4:34 PM, Adam Langley > wrote: >> >> http://tools.ietf.org/html/draft-agl-tls-encryptedclientcerts-00 > > I like that approach, but I don't like that only client certificates > are hidden. Whether client and server are actually distinct is > application specific, and hiding only one side might not always make > sense. Why not move both certificate messages (client and server) > after the changecipherspec? That way TLS will operate as IPSec and > offer anonymity against passive eavesdroppers. I like this idea. Though for RSA key exchange we'd have to utilize the ServerKeyExchange message which is currently forbidden. Additionally, making the server certificate message optional would eliminate the need for server operators to create self-signed certificates. Mike From paul@xelerance.com Wed Nov 16 09:25:21 2011 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 F005321F9424 for ; Wed, 16 Nov 2011 09:25:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.566 X-Spam-Level: X-Spam-Status: No, score=-6.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 nXfa4rh+rLvk for ; Wed, 16 Nov 2011 09:25:20 -0800 (PST) Received: from mx.xelerance.com (mx.xelerance.com [193.110.157.188]) by ietfa.amsl.com (Postfix) with ESMTP id 059DF21F9422 for ; Wed, 16 Nov 2011 09:25:20 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx.xelerance.com (Postfix) with ESMTP id DBBD07F1; Wed, 16 Nov 2011 12:25:17 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xelerance.com; h= content-type:content-type:mime-version:user-agent:references :message-id:in-reply-to:subject:subject:from:from:date:date :received:received:received:received; s=smtp; t=1321464317; x= 1322069117; bh=mqZBRUHNtfsqCYUJt6/i9gOpyY6Zi8lJ5MxEjOpzwNo=; b=W LdlQ75kiggP0SXt+hkaIvTD+jDrE99RaU5627i3uDoFeJlrbti01G/9YEuz4L9yE r1DTI6PubRgfaII/lRHAd/Zw7vef2fvEoH7U3TZp4cc6h6EUvbiXqFrXnDjGlOHm ZFypAax3gf/0EC/KKlDOjUrXT4qwTSeLsdfLGNAHys= Received: from mx.xelerance.com ([127.0.0.1]) by localhost (mx.xelerance.com [127.0.0.1]) (amavisd-new, port 10026) with LMTP id yPsdxeJNbHDD; Wed, 16 Nov 2011 12:25:17 -0500 (EST) Received: from mail.xelerance.com (mail.xelerance.com [193.110.157.189]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.xelerance.com (Postfix) with ESMTPS id 10B1A65; Wed, 16 Nov 2011 12:25:17 -0500 (EST) Received: by mail.xelerance.com (Postfix, from userid 1001) id E1FCE554; Wed, 16 Nov 2011 12:25:16 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.xelerance.com (Postfix) with ESMTP id D944536B; Wed, 16 Nov 2011 12:25:16 -0500 (EST) Date: Wed, 16 Nov 2011 12:25:16 -0500 (EST) From: Paul Wouters To: Michael D'Errico In-Reply-To: <3d51f9e7878dbd581a9c4e9f91973436@pobox.com> Message-ID: References: <3d51f9e7878dbd581a9c4e9f91973436@pobox.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: tls@ietf.org Subject: Re: [TLS] Fwd: Client TLS Identity Protection: draft-hajjeh-tls-identity-protection-09.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 17:25:21 -0000 On Wed, 16 Nov 2011, Michael D'Errico wrote: >>> http://tools.ietf.org/html/draft-agl-tls-encryptedclientcerts-00 >> >> I like that approach, but I don't like that only client certificates >> are hidden. Whether client and server are actually distinct is >> application specific, and hiding only one side might not always make >> sense. Why not move both certificate messages (client and server) >> after the changecipherspec? That way TLS will operate as IPSec and >> offer anonymity against passive eavesdroppers. > > I like this idea. Though for RSA key exchange we'd have to utilize > the ServerKeyExchange message which is currently forbidden. > > Additionally, making the server certificate message optional would > eliminate the need for server operators to create self-signed > certificates. and makes it easier to plugin to DANE. See also http://tools.ietf.org/html/draft-wouters-tls-oob-pubkey-01 that aims at supressing the TLS server from sending PKIX information when the client tells it such information is not required. Paul From agl@google.com Wed Nov 16 09:26:45 2011 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 3CEC821F948A for ; Wed, 16 Nov 2011 09:26:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtjE+OrIk5ah for ; Wed, 16 Nov 2011 09:26:44 -0800 (PST) Received: from mail-pz0-f50.google.com (mail-pz0-f50.google.com [209.85.210.50]) by ietfa.amsl.com (Postfix) with ESMTP id AD02A21F9493 for ; Wed, 16 Nov 2011 09:26:44 -0800 (PST) Received: by pzk5 with SMTP id 5so16513933pzk.9 for ; Wed, 16 Nov 2011 09:26:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :x-system-of-record; bh=F+nCqZc5mbsXfMyDdqQaPBGsHXwBN73L+vajOKkJxag=; b=drXLDqHnFW0q9pLE34yv82EEW9kVDleYf29sFquTRxH4awTR7P5l1ORJnaoWpssdnK A0VhM2COhAHQVbH9AriA== Received: by 10.50.85.129 with SMTP id h1mr33741123igz.47.1321464402915; Wed, 16 Nov 2011 09:26:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.85.129 with SMTP id h1mr33741073igz.47.1321464402369; Wed, 16 Nov 2011 09:26:42 -0800 (PST) Sender: agl@google.com Received: by 10.231.37.195 with HTTP; Wed, 16 Nov 2011 09:26:42 -0800 (PST) In-Reply-To: References: Date: Wed, 16 Nov 2011 12:26:42 -0500 X-Google-Sender-Auth: wnoL0Ht0UXlCXs5R9IaDu9UgNt4 Message-ID: From: Adam Langley To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: Wan-Teh Chang , tls@ietf.org Subject: Re: [TLS] Fwd: Client TLS Identity Protection: draft-hajjeh-tls-identity-protection-09.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 17:26:45 -0000 On Wed, Nov 16, 2011 at 11:36 AM, Nikos Mavrogiannopoulos wrote: > I like that approach, but I don't like that only client certificates > are hidden. Whether client and server are actually distinct is > application specific, and hiding only one side might not always make > sense. Why not move both certificate messages (client and server) > after the changecipherspec? That way TLS will operate as IPSec and > offer anonymity against passive eavesdroppers. The reason that we're concentrating only on the client certificates is that for most situations, the server is well known and, indeed, the client names it in an SNI extension. The clients however, have some privacy to preserve. But I'd support hiding the server certificate too. In general, anything that can be encrypted should be encrypted. Although we would like it to be a separate mechanism because we want to get and verify the server's certificate as soon as possible in order to minimise the number of round trips. (Note that we're sending application data sooner: http://technotes.googlecode.com/git/falsestart.html) Cheers AGL From mrex@sap.com Wed Nov 16 09:28:22 2011 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 DD28521F90C2 for ; Wed, 16 Nov 2011 09:28:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.13 X-Spam-Level: X-Spam-Status: No, score=-10.13 tagged_above=-999 required=5 tests=[AWL=0.119, 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 J6x9tkyz-vrj for ; Wed, 16 Nov 2011 09:28:22 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1099021F90C0 for ; Wed, 16 Nov 2011 09:28:21 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id pAGHSEBS007367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Nov 2011 18:28:19 +0100 (MET) From: Martin Rex Message-Id: <201111161728.pAGHSEN1025695@fs4113.wdf.sap.corp> To: mike-list@pobox.com (Michael D'Errico) Date: Wed, 16 Nov 2011 18:28:14 +0100 (MET) In-Reply-To: <3d51f9e7878dbd581a9c4e9f91973436@pobox.com> from "Michael D'Errico" at Nov 16, 11 12:13:07 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Fwd: Client TLS Identity Protection: 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: Wed, 16 Nov 2011 17:28:23 -0000 Michael D'Errico wrote: > > Nikos Mavrogiannopoulos wrote: > > Adam Langley wrote: > > > > > > http://tools.ietf.org/html/draft-agl-tls-encryptedclientcerts-00 > > > > I like that approach, but I don't like that only client certificates > > are hidden. Whether client and server are actually distinct is > > application specific, and hiding only one side might not always make > > sense. Why not move both certificate messages (client and server) > > after the changecipherspec? That way TLS will operate as IPSec and > > offer anonymity against passive eavesdroppers. > > I like this idea. Though for RSA key exchange we'd have to utilize > the ServerKeyExchange message which is currently forbidden. > > Additionally, making the server certificate message optional would > eliminate the need for server operators to create self-signed > certificates. I fail to understand how moving the ServerCertificate into the encrypted part of the handshake could work for plain RSA ciphersuites. While I do think the proposed solution for client certs is OK, I do not see how to make it work for the server. The original PK(IX) idea is that you perform public key crypto only with public keys that you have verified to trust, i.e. you perform a public key operation only after having verified the certificate that conveyed that public key, and you use an ephemeral public key only after having verified the signature on the ephemeral key after having verified the certificate containing the public key for the signature of the ephemeral key. -Martin From n.mavrogiannopoulos@gmail.com Wed Nov 16 09:33:57 2011 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 6493321F92B6 for ; Wed, 16 Nov 2011 09:33:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dIxHZZRGBudU for ; Wed, 16 Nov 2011 09:33:56 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 98C0A21F92A3 for ; Wed, 16 Nov 2011 09:33:56 -0800 (PST) Received: by eyg24 with SMTP id 24so849957eyg.31 for ; Wed, 16 Nov 2011 09:33:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=J0SqFQKR8WfZ0S5Pl9fthkIog7l2klBu8YtU8UAl1oU=; b=Cm3rF3BTsmzg2S4CuqQfYmwNswrVRP0vhdPfYfySCiqqW3EdxQi26Ca0l9HQwWjuuw A1ttq+ApUotKTt1HJvfaMd1qirmslqbayEHb4Dc/Pvr2WlRtGUusCvIORPdJytzhYpwk uOfPS4QLhVauT89oA8Q7nCIvZCV9ukrqvD8z0= Received: by 10.14.23.8 with SMTP id u8mr2411639eeu.29.1321464835741; Wed, 16 Nov 2011 09:33:55 -0800 (PST) Received: from [10.100.2.14] (d51A49E78.access.telenet.be. [81.164.158.120]) by mx.google.com with ESMTPS id o4sm81582966eeb.0.2011.11.16.09.33.53 (version=SSLv3 cipher=OTHER); Wed, 16 Nov 2011 09:33:54 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <4EC3F475.2040001@gnutls.org> Date: Wed, 16 Nov 2011 18:35:49 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Icedove/3.1.15 MIME-Version: 1.0 To: tls@ietf.org References: <201111161728.pAGHSEN1025695@fs4113.wdf.sap.corp> In-Reply-To: <201111161728.pAGHSEN1025695@fs4113.wdf.sap.corp> X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [TLS] Fwd: Client TLS Identity Protection: 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, 16 Nov 2011 17:33:57 -0000 On 11/16/2011 06:28 PM, Martin Rex wrote: > Michael D'Errico wrote: >> >> Nikos Mavrogiannopoulos wrote: >>> Adam Langley wrote: >>>> >>>> http://tools.ietf.org/html/draft-agl-tls-encryptedclientcerts-00 >>> >>> I like that approach, but I don't like that only client certificates >>> are hidden. Whether client and server are actually distinct is >>> application specific, and hiding only one side might not always make >>> sense. Why not move both certificate messages (client and server) >>> after the changecipherspec? That way TLS will operate as IPSec and >>> offer anonymity against passive eavesdroppers. >> >> I like this idea. Though for RSA key exchange we'd have to utilize >> the ServerKeyExchange message which is currently forbidden. >> >> Additionally, making the server certificate message optional would >> eliminate the need for server operators to create self-signed >> certificates. > I fail to understand how moving the ServerCertificate into the > encrypted part of the handshake could work for plain RSA ciphersuites. It cannot. If it is to be symmetric it has to be restricted to ECDHE and DHE ciphersuites. regards, Nikos From mbadra@gmail.com Wed Nov 16 10:36:28 2011 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 7C8EF21F94D2 for ; Wed, 16 Nov 2011 10:36:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 cf+0hudhNJdJ for ; Wed, 16 Nov 2011 10:36:27 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 9F69F21F94D1 for ; Wed, 16 Nov 2011 10:36:27 -0800 (PST) Received: by vcbfl15 with SMTP id fl15so985913vcb.31 for ; Wed, 16 Nov 2011 10:36:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=WdIwVwmPUK8jPhCrwFM/26CBi+sHyoSx3r2uIsQ8Bjk=; b=AGU3pPRL2lI/HSv4/pTzSBEwoljiqomgdQzziyERyp8XaZ5zEhTgi3bwdJ2bAhUSop H3TCa7ziNXKFZbmSkLYzSG5C9Pal3VOWJ3gVY60nucJ4m0zMzY36CXjeICP/UjBxOheP p/h+qxKQY4CqBBJP0+X2tVY6evBIYPuEtL4Nk= MIME-Version: 1.0 Received: by 10.220.221.15 with SMTP id ia15mr1986031vcb.199.1321468584072; Wed, 16 Nov 2011 10:36:24 -0800 (PST) Received: by 10.220.201.71 with HTTP; Wed, 16 Nov 2011 10:36:23 -0800 (PST) In-Reply-To: <3d51f9e7878dbd581a9c4e9f91973436@pobox.com> References: <3d51f9e7878dbd581a9c4e9f91973436@pobox.com> Date: Wed, 16 Nov 2011 19:36:23 +0100 Message-ID: From: Badra To: tls@ietf.org Content-Type: multipart/alternative; boundary=14dae9cfcd0a89142204b1de61ca Subject: Re: [TLS] Fwd: Client TLS Identity Protection: draft-hajjeh-tls-identity-protection-09.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 18:36:28 -0000 --14dae9cfcd0a89142204b1de61ca Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 16, 2011 at 6:13 PM, Michael D'Errico wrote: > On Wed, 16 Nov 2011 17:36:01 +0100, Nikos Mavrogiannopoulos wrote: > >> On Wed, Nov 16, 2011 at 4:34 PM, Adam Langley wrote: >> >>> >>> http://tools.ietf.org/html/**draft-agl-tls-**encryptedclientcerts-00 >>> >> >> I like that approach, but I don't like that only client certificates >> are hidden. Whether client and server are actually distinct is >> application specific, and hiding only one side might not always make >> sense. Why not move both certificate messages (client and server) >> after the changecipherspec? That way TLS will operate as IPSec and >> offer anonymity against passive eavesdroppers. >> > > I like this idea. Though for RSA key exchange we'd have to utilize > the ServerKeyExchange message which is currently forbidden. > > Additionally, making the server certificate message optional would > eliminate the need for server operators to create self-signed > certificates. > > That idea is not new at all, and had been proposed to the mailing list during August 2000. People objected to that idea because it requires major change to TLS machine state. I also proposed three ways to provide the same service during 2006, the WG didn't adopt my draft because it introduces some chages to TLS (some of them support the same idea today ;-)) and because TLS provides renegotiation. @Nikos, how will you be able to provide server identity protection without renegotiation and DH in the first Handshake? Best regards Badra --14dae9cfcd0a89142204b1de61ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Wed, Nov 16, 2011 at= 6:13 PM, Michael D'Errico <mike-list@pobox.com> wrote:
On Wed, 16 Nov 2011 17:36:01 +0100, Nikos Mavrogiannopoul= os wrote:
On Wed, Nov 16, 2011 at 4:34 PM, Adam Langley <agl@chromium.org> wrote:

http://tools.ietf.org/html/draft-agl-tls-= encryptedclientcerts-00

I like that approach, but I don't like that only client certificates are hidden. Whether client and server are actually distinct is
application specific, and hiding only one side might not always make
sense. Why not move both certificate messages (client and server)
after the changecipherspec? That way TLS will operate as IPSec and
offer anonymity against passive eavesdroppers.

I like this idea. =A0Though for RSA key exchange we'd have to utilize the ServerKeyExchange message which is currently forbidden.

Additionally, making the server certificate message optional would
eliminate the need for server operators to create self-signed
certificates.



That idea is not new at= all, and had been proposed to the mailing list during August 2000.
People objected to that idea because it requires major change to TLS mac= hine state.

I also proposed three ways to provide the same service = during 2006,=A0the WG didn't adopt my draft because it introduces some = chages to TLS (some of them support the same idea today ;-)) and because TL= S provides renegotiation.

@Nikos, how will you be able to provide server identity= protection without renegotiation and DH in the first Handshake?
=
Best regards
Badra=A0
--14dae9cfcd0a89142204b1de61ca-- From ekr@rtfm.com Wed Nov 16 10:39:06 2011 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 56ADF21F94D2 for ; Wed, 16 Nov 2011 10:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.941 X-Spam-Level: X-Spam-Status: No, score=-102.941 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-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 9JVSum5xisUh for ; Wed, 16 Nov 2011 10:39:05 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B434D21F93AE for ; Wed, 16 Nov 2011 10:39:05 -0800 (PST) Received: by vcbfl15 with SMTP id fl15so988624vcb.31 for ; Wed, 16 Nov 2011 10:39:05 -0800 (PST) Received: by 10.220.3.68 with SMTP id 4mr3589659vcm.231.1321468745219; Wed, 16 Nov 2011 10:39:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.220.118.132 with HTTP; Wed, 16 Nov 2011 10:38:23 -0800 (PST) X-Originating-IP: [74.95.2.169] In-Reply-To: References: From: Eric Rescorla Date: Wed, 16 Nov 2011 10:38:23 -0800 Message-ID: To: Adam Langley Content-Type: text/plain; charset=ISO-8859-1 Cc: Wan-Teh Chang , tls@ietf.org Subject: Re: [TLS] Fwd: Client TLS Identity Protection: draft-hajjeh-tls-identity-protection-09.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 18:39:06 -0000 On Wed, Nov 16, 2011 at 9:26 AM, Adam Langley wrote: > On Wed, Nov 16, 2011 at 11:36 AM, Nikos Mavrogiannopoulos > wrote: >> I like that approach, but I don't like that only client certificates >> are hidden. Whether client and server are actually distinct is >> application specific, and hiding only one side might not always make >> sense. Why not move both certificate messages (client and server) >> after the changecipherspec? That way TLS will operate as IPSec and >> offer anonymity against passive eavesdroppers. > > The reason that we're concentrating only on the client certificates is > that for most situations, the server is well known and, indeed, the > client names it in an SNI extension. The clients however, have some > privacy to preserve. I think it's important to be clear on the level of privacy protections that you are attempting to deliver. At an abstract level, the best you can do is to provide anonymity of one side against active attackers. I.e., one side needs to declare their identity first, so the attacker can always force that side to identify. You can clearly deliver anonymity against passive attackers for both identities. With that said, both of these mechanisms provide less good protection against active attack: the server exposes their identity first, but because the existing TLS client authentication modes involve having the client reveal his identity in the clear, the active attacker can just pretend to be a server which does not support encrypted client certificates, thus getting the client's identity. In order to defend against this, the client needs to refuse to use the original TLS client auth modes. (This isn't something new I'm observing... it's in the security considerations in Adam's draft.) Absent some plausible mechanism for mitigating the active attack threat, I'm not that enthusiastic about just suppressing the passive threat. -Ekr From n.mavrogiannopoulos@gmail.com Wed Nov 16 10:51:50 2011 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 AE4441F0C55 for ; Wed, 16 Nov 2011 10:51:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2flKICtqsZaZ for ; Wed, 16 Nov 2011 10:51:45 -0800 (PST) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id 4B3591F0C54 for ; Wed, 16 Nov 2011 10:51:45 -0800 (PST) Received: by wwe3 with SMTP id 3so1772375wwe.1 for ; Wed, 16 Nov 2011 10:51:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=iq+6EXx7qov0YweOAVdJkmqeMUk47U/Ow1VEsHcDFEU=; b=Ee2A6ed/iw6F0WM1FVe0JiGdn74wLOr4L3lSAZ/nG90WgPpaK78BNfmXf4AD9jFDzj SK/xb8StxWHk42tKUu8I/V5MIBa9NAwZ8k02bHTmQTUYAw+aC5GlB6YuSrOaWB55FyjY o88CN6cbD3cE3EPc+M6FBcpKs7UOUV+2kw4h8= MIME-Version: 1.0 Received: by 10.180.3.227 with SMTP id f3mr37056086wif.5.1321469504386; Wed, 16 Nov 2011 10:51:44 -0800 (PST) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.180.24.165 with HTTP; Wed, 16 Nov 2011 10:51:44 -0800 (PST) In-Reply-To: References: <3d51f9e7878dbd581a9c4e9f91973436@pobox.com> Date: Wed, 16 Nov 2011 19:51:44 +0100 X-Google-Sender-Auth: RhJJ_esuT9MOKFsJs9KM6ONcwzE Message-ID: From: Nikos Mavrogiannopoulos To: Badra Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] Fwd: Client TLS Identity Protection: draft-hajjeh-tls-identity-protection-09.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Nov 2011 18:51:50 -0000 On Wed, Nov 16, 2011 at 7:36 PM, Badra wrote: >>> I like that approach, but I don't like that only client certificates >>> are hidden. Whether client and server are actually distinct is >>> application specific, and hiding only one side might not always make >>> sense. Why not move both certificate messages (client and server) >>> after the changecipherspec? That way TLS will operate as IPSec and >>> offer anonymity against passive eavesdroppers. >> I like this idea. =C2=A0Though for RSA key exchange we'd have to utilize >> the ServerKeyExchange message which is currently forbidden. >> Additionally, making the server certificate message optional would >> eliminate the need for server operators to create self-signed >> certificates. > That idea is not new at all, and had been proposed to the mailing list > during August 2000. > People objected to that idea because it requires major change to TLS mach= ine > state. Privacy wasn't really a hot topic in 2000, but it's not the same today. Even security protocols follow the market :) > I also proposed three ways to provide the same service during 2006,=C2=A0= the WG > didn't adopt my draft because it introduces some chages to TLS (some of t= hem > support the same idea today ;-)) If you mean me, If I remember well I had comments on the approach followed, and the handling of different TLS versions but not the idea itself. I'm always pro-privacy :) > and because TLS provides renegotiation. > @Nikos, how will you be able to provide server identity protection withou= t > renegotiation and DH in the first Handshake? Easy. I consider DHE and ECDHE only. regards, Nikos From mrex@sap.com Wed Nov 16 10:57:13 2011 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 B6D1521F9445 for ; Wed, 16 Nov 2011 10:57:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.132 X-Spam-Level: X-Spam-Status: No, score=-10.132 tagged_above=-999 required=5 tests=[AWL=0.117, 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 y8Id-VrA2WbW for ; Wed, 16 Nov 2011 10:57:08 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9F521F9436 for ; Wed, 16 Nov 2011 10:57:08 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id pAGIv5gE007651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Nov 2011 19:57:05 +0100 (MET) From: Martin Rex Message-Id: <201111161857.pAGIv4ta000821@fs4113.wdf.sap.corp> To: ekr@rtfm.com (Eric Rescorla) Date: Wed, 16 Nov 2011 19:57:04 +0100 (MET) In-Reply-To: from "Eric Rescorla" at Nov 16, 11 10:38:23 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: wtc@chromium.org, agl@chromium.org, tls@ietf.org Subject: Re: [TLS] Fwd: Client TLS Identity Protection: 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: Wed, 16 Nov 2011 18:57:13 -0000 Eric Rescorla wrote: > > On Wed, Nov 16, 2011 at 9:26 AM, Adam Langley wrote: > > On Wed, Nov 16, 2011 at 11:36 AM, Nikos Mavrogiannopoulos > > wrote: > >> I like that approach, but I don't like that only client certificates > >> are hidden. Whether client and server are actually distinct is > >> application specific, and hiding only one side might not always make > >> sense. Why not move both certificate messages (client and server) > >> after the changecipherspec? That way TLS will operate as IPSec and > >> offer anonymity against passive eavesdroppers. > > > > The reason that we're concentrating only on the client certificates is > > that for most situations, the server is well known and, indeed, the > > client names it in an SNI extension. The clients however, have some > > privacy to preserve. > > I think it's important to be clear on the level of privacy protections that > you are attempting to deliver. At an abstract level, the best you can do > is to provide anonymity of one side against active attackers. I.e., one > side needs to declare their identity first, so the attacker can always > force that side to identify. You can clearly deliver anonymity against > passive attackers for both identities. > > With that said, both of these mechanisms provide less good > protection against active attack: the server exposes their identity > first, but because the existing TLS client authentication modes > involve having the client reveal his identity in the clear, the active > attacker can just pretend to be a server which does not support > encrypted client certificates, thus getting the client's identity. In > order to defend against this, the client needs to refuse to use the > original TLS client auth modes. (This isn't something new I'm > observing... it's in the security considerations in Adam's draft.) > > Absent some plausible mechanism for mitigating the active > attack threat, I'm not that enthusiastic about just suppressing > the passive threat. Sounds plausible to me. In order to protect against an active attacker being able to force disclosure of the client cert, I assume one would need a confirmation authenticated by the server "credential" that the server supports this extension. An EKU in the server certificate would be conceivable, although I feel quite uncomfortable with hardwiring an new optional TLS protocol feature into a TLS server certificate, resulting in potentially hard to diagnose handshake failures. -Martin From ekr@rtfm.com Wed Nov 16 11:14:35 2011 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 051311F0C69 for ; Wed, 16 Nov 2011 11:14:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.942 X-Spam-Level: X-Spam-Status: No, score=-102.942 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-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 8sMs5u8bQj07 for ; Wed, 16 Nov 2011 11:14:34 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 5313E1F0C54 for ; Wed, 16 Nov 2011 11:14:34 -0800 (PST) Received: by yenq4 with SMTP id q4so41092yen.31 for ; Wed, 16 Nov 2011 11:14:34 -0800 (PST) Received: by 10.236.78.3 with SMTP id f3mr4019022yhe.120.1321470873951; Wed, 16 Nov 2011 11:14:33 -0800 (PST) MIME-Version: 1.0 Received: by 10.146.88.36 with HTTP; Wed, 16 Nov 2011 11:07:34 -0800 (PST) X-Originating-IP: [74.95.2.169] In-Reply-To: <201111161857.pAGIv4ta000821@fs4113.wdf.sap.corp> References: <201111161857.pAGIv4ta000821@fs4113.wdf.sap.corp> From: Eric Rescorla Date: Wed, 16 Nov 2011 11:07:34 -0800 Message-ID: To: mrex@sap.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: wtc@chromium.org, agl@chromium.org, tls@ietf.org Subject: Re: [TLS] Fwd: Client TLS Identity Protection: 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, 16 Nov 2011 19:14:35 -0000 On Wed, Nov 16, 2011 at 10:57 AM, Martin Rex wrote: > Eric Rescorla wrote: >> >> On Wed, Nov 16, 2011 at 9:26 AM, Adam Langley wrote: >> > On Wed, Nov 16, 2011 at 11:36 AM, Nikos Mavrogiannopoulos >> > wrote: >> >> I like that approach, but I don't like that only client certificates >> >> are hidden. Whether client and server are actually distinct is >> >> application specific, and hiding only one side might not always make >> >> sense. Why not move both certificate messages (client and server) >> >> after the changecipherspec? That way TLS will operate as IPSec and >> >> offer anonymity against passive eavesdroppers. >> > >> > The reason that we're concentrating only on the client certificates is >> > that for most situations, the server is well known and, indeed, the >> > client names it in an SNI extension. The clients however, have some >> > privacy to preserve. >> >> I think it's important to be clear on the level of privacy protections t= hat >> you are attempting to deliver. At an abstract level, the best you can do >> is to provide anonymity of one side against active attackers. I.e., one >> side needs to declare their identity first, so the attacker can always >> force that side to identify. You can clearly deliver anonymity against >> passive attackers for both identities. >> >> With that said, both of these mechanisms provide less good >> protection against active attack: the server exposes their identity >> first, but because the existing TLS client authentication modes >> involve having the client reveal his identity in the clear, the active >> attacker can just pretend to be a server which does not support >> encrypted client certificates, thus getting the client's identity. In >> order to defend against this, the client needs to refuse to use the >> original TLS client auth modes. (This isn't something new I'm >> observing... it's in the security considerations in Adam's draft.) >> >> Absent some plausible mechanism for mitigating the active >> attack threat, I'm not that enthusiastic about just suppressing >> the passive threat. > > Sounds plausible to me. > > In order to protect against an active attacker being able to force > disclosure of the client cert, I assume one would need a confirmation > authenticated by the server "credential" that the server supports > this extension. =A0An EKU in the server certificate would be conceivable, > although I feel quite uncomfortable with hardwiring an new optional > TLS protocol feature into a TLS server certificate, resulting in potentia= lly > hard to diagnose handshake failures. Indeed. In the specific case of OBC, one might imagine decorating the OBC request extension with a "only send over encrypted channel" indicator, which gets tagged to the cert at generation time. I know that this sounds like it's subject to active attack, but here's my argument for why not. There are two cases: 1. The client does not have an OBC for this origin. 2. The client does have an OBC for this origin. In case 1, in the non-attack scenario, the server advertises {OBC, encrypted-only}. The client generates the OBC and sends it encrypted, and stores it with the encrypted-only flag. In the attack scenario, the server advertises {OBC, encrypted-only} but the attacker changes it to {OBC, plain}. The client completes the hands= hake and sends the OBC in the clear, but it's a fresh OBC so (almost) no information is leaked, other than the non-presence of an OBC, which is apparent from traffic analy= sis in any case. The handshake then fails (because of the Finished MAC) and the client should delete the OBC at this point. In case 2, the client already has stored the OBC, so even if the attacker tampers with the handshake to remove the encrypted client auth extension, the client won't send the cert in the clear, so the attack fails. I know it's kind of a special case, but... -Ekr From fcorella@pomcor.com Wed Nov 16 11:22:05 2011 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 C461C11E80F2 for ; Wed, 16 Nov 2011 11:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ce14uQKlTpzS for ; Wed, 16 Nov 2011 11:22:05 -0800 (PST) Received: from nm35-vm7.bullet.mail.ne1.yahoo.com (nm35-vm7.bullet.mail.ne1.yahoo.com [98.138.229.103]) by ietfa.amsl.com (Postfix) with SMTP id D008011E809D for ; Wed, 16 Nov 2011 11:22:04 -0800 (PST) Received: from [98.138.90.56] by nm35.bullet.mail.ne1.yahoo.com with NNFMP; 16 Nov 2011 19:22:00 -0000 Received: from [98.138.89.244] by tm9.bullet.mail.ne1.yahoo.com with NNFMP; 16 Nov 2011 19:22:00 -0000 Received: from [127.0.0.1] by omp1058.mail.ne1.yahoo.com with NNFMP; 16 Nov 2011 19:22:00 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 866549.86822.bm@omp1058.mail.ne1.yahoo.com Received: (qmail 6026 invoked by uid 60001); 16 Nov 2011 19:22:00 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1321471320; bh=2jlNCebf3ef+IDmWbUFSLzz2blVg0LJV99tWBLbisIE=; h=X-YMail-OSG:Received:X-RocketYMMF:X-Mailer:References:Message-ID:Date:From:Reply-To:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=R08LjaYMvi2ntUPQoiHqex4Jo8/n6caXwbW5WHpTCp2OREuzjULDw7P6TVjwC9bZIgpKUQ8+pTzgRyGzdd2d9BLu0MVQRn9MWlksRchxHWFu9GdJ0js6fEcIdITcMvIu9RcIZ9NDHaKwmml/AllE/kaHwR1aq7V/XUi+WvsFuMU= X-YMail-OSG: 1wVv.VUVM1mgH2ZgntZ5pPNXy3FOIKzS4rA21svzu.Ku.r3 DnUFuIVdzyvjEc58q.SgeQcf9SDfd.Vd1GbemJzjIaS278XxuuMYYhPJee1k gm6q_OMQO0CBNes3Hi9gTnp31HLneTUzwNexmpMck6JX4boMez_DxIDmW98m EgzRGDIAp1pNdwoT6nbjlkPjPCzqHSIA19.gDPqUYWsYKCMcpykWRdL6VTRi HY.VWmbkxBxOzITOIG2Z5xF70.TVU_kA1LAMEiRe1EySkBMPQLM8W5kfFYiw Oa75UlZRL.C7Q4nmuONXRPTYvUapQLkhJ6bIO2gR3vXe62MEN1NdtaqH8Q_G 1McpGY6J8H2YP3yVg9xie7etcB2NJCNcmiKogrc8KIJ3MQEFeXHMhkbKI50q E4QUmXO_cZ5B8fA3enaoW9kI_9Xt9FbuguJ2dmpq1lMV0F7UyQ0D00Rg3xwl 3G_6UiUX5ywHgreMD Received: from [174.65.117.33] by web125520.mail.ne1.yahoo.com via HTTP; Wed, 16 Nov 2011 11:22:00 PST X-RocketYMMF: francisco_corella X-Mailer: YahooMailWebService/0.8.115.325013 References: <3d51f9e7878dbd581a9c4e9f91973436@pobox.com> Message-ID: <1321471320.2437.YahooMailNeo@web125520.mail.ne1.yahoo.com> Date: Wed, 16 Nov 2011 11:22:00 -0800 (PST) From: Francisco Corella To: Badra , "tls@ietf.org" In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="-739622131-729299493-1321471320=:2437" Subject: Re: [TLS] Fwd: Client TLS Identity Protection: draft-hajjeh-tls-identity-protection-09.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Francisco Corella 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, 16 Nov 2011 19:22:05 -0000 ---739622131-729299493-1321471320=:2437 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable > That idea is not new at all, and had been proposed to the mailing list du= ring August 2000.=0A> People objected to that idea because it requires majo= r change to TLS machine state.=0A=0AYep, I did propose it in the year 2000 = :-)=0A=0AFrancisco=0A=0A=0A=0A>________________________________=0A>From: Ba= dra =0A>To: tls@ietf.org=0A>Sent: Wednesday, November 16,= 2011 10:36 AM=0A>Subject: Re: [TLS] Fwd: Client TLS Identity Protection: d= raft-hajjeh-tls-identity-protection-09.txt=0A>=0A>=0A>=0A>=0A>=0A>On Wed, N= ov 16, 2011 at 6:13 PM, Michael D'Errico wrote:=0A>= =0A>On Wed, 16 Nov 2011 17:36:01 +0100, Nikos Mavrogiannopoulos wrote:=0A>>= =0A>>On Wed, Nov 16, 2011 at 4:34 PM, Adam Langley wrote= :=0A>>>=0A>>>=0A>>>>http://tools.ietf.org/html/draft-agl-tls-encryptedclien= tcerts-00=0A>>>>=0A>>>I like that approach, but I don't like that only clie= nt certificates=0A>>>are hidden. Whether client and server are actually dis= tinct is=0A>>>application specific, and hiding only one side might not alwa= ys make=0A>>>sense. Why not move both certificate messages (client and serv= er)=0A>>>after the changecipherspec? That way TLS will operate as IPSec and= =0A>>>offer anonymity against passive eavesdroppers.=0A>>>=0A>>I like this = idea. =A0Though for RSA key exchange we'd have to utilize=0A>>the ServerKey= Exchange message which is currently forbidden.=0A>>=0A>>Additionally, makin= g the server certificate message optional would=0A>>eliminate the need for = server operators to create self-signed=0A>>certificates.=0A>>=0A>>=0A>=0A>= =0A>=0A>=0A>That idea is not new at all, and had been proposed to the maili= ng list during August 2000.=0A>People objected to that idea because it requ= ires major change to TLS machine state.=0A>=0A>=0A>I also proposed three wa= ys to provide the same service during 2006,=A0the WG didn't adopt my draft = because it introduces some chages to TLS (some of them support the same ide= a today ;-)) and because TLS provides renegotiation.=0A>=0A>=0A>@Nikos, how= will you be able to provide server identity protection without renegotiati= on and DH in the first Handshake?=0A>=0A>=0A>Best regards=0A>Badra=A0=0A>__= _____________________________________________=0A>TLS mailing list=0A>TLS@ie= tf.org=0A>https://www.ietf.org/mailman/listinfo/tls=0A>=0A>=0A> ---739622131-729299493-1321471320=:2437 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
> That idea is not= new at all, and had been proposed to the mailing list during August 2000.<= br>> People objected to that idea because it requires major change to TL= S machine state.

Yep, I did propose it in the year 2000 :-)

F= rancisco

From: Badra <mbadra@gmail.com>
To: tls@ietf.org
Sent: Wednesday, November 16, 2011 10:36 AM
Subject: Re: [TLS] Fwd: Client TLS= Identity Protection: draft-hajjeh-tls-identity-protection-09.txt

=0A


On Wed, Nov 16, 2011 at 6:13 PM, Michael D'Errico <mike-list@pobox.co= m> wrote:
=0A<= div class=3D"yiv281276006im">On Wed, 16 Nov 2011 17:36:01 +0100, Nikos Mavr= ogiannopoulos wrote:
=0A
=0AOn Wed, Nov 16, 2011 at 4:34 PM, Adam La= ngley <agl@chromium.org> wrote:=0A
=0A
=0Ahttp://tools.ietf.org/html/draft-agl-tls-encryptedclien= tcerts-00
=0A
=0A
=0AI like that approach, but I don't li= ke that only client certificates
=0Aare hidden. Whether client and serve= r are actually distinct is
=0Aapplication specific, and hiding only one = side might not always make
=0Asense. Why not move both certificate messa= ges (client and server)
=0Aafter the changecipherspec? That way TLS will= operate as IPSec and
=0Aoffer anonymity against passive eavesdroppers.<= br>=0A
=0A
=0AI like this idea.  Though for RSA k= ey exchange we'd have to utilize
=0Athe ServerKeyExchange message which = is currently forbidden.
=0A
=0AAdditionally, making the server certif= icate message optional would
=0Aeliminate the need for server operators = to create self-signed
=0Acertificates.
=0A

<= /div>

That idea is not new at all, and had been proposed= to the mailing list during August 2000.
People objected to that = idea because it requires major change to TLS machine state.
=0A
I also proposed three ways to provide the same service during = 2006, the WG didn't adopt my draft because it introduces some chages t= o TLS (some of them support the same idea today ;-)) and because TLS provid= es renegotiation.
=0A

@Nikos, how will you be able = to provide server identity protection without renegotiation and DH in the f= irst Handshake?

Best regards
Badra =
=0A

____________________________________________= ___
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls<= /a>


---739622131-729299493-1321471320=:2437-- From mrex@sap.com Wed Nov 16 11:30:49 2011 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 37DF221F90DF for ; Wed, 16 Nov 2011 11:30:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.134 X-Spam-Level: X-Spam-Status: No, score=-10.134 tagged_above=-999 required=5 tests=[AWL=0.115, 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 QWp9uHMNuhXO for ; Wed, 16 Nov 2011 11:30:48 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 7B55E21F90C3 for ; Wed, 16 Nov 2011 11:30:48 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id pAGJUW1w016765 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Nov 2011 20:30:32 +0100 (MET) From: Martin Rex Message-Id: <201111161930.pAGJUVBW002655@fs4113.wdf.sap.corp> To: nmav@gnutls.org (Nikos Mavrogiannopoulos) Date: Wed, 16 Nov 2011 20:30:31 +0100 (MET) In-Reply-To: from "Nikos Mavrogiannopoulos" at Nov 16, 11 05:36:01 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: wtc@chromium.org, agl@chromium.org, tls@ietf.org Subject: Re: [TLS] Fwd: Client TLS Identity Protection: 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: Wed, 16 Nov 2011 19:30:49 -0000 Nikos Mavrogiannopoulos wrote: > > On Wed, Nov 16, 2011 at 4:34 PM, Adam Langley wrote: > > On Wed, Nov 16, 2011 at 3:25 AM, Badra wrote: > >> It's been a couple of years since "Client TLS Identity Protection" was > >> discussed on the TLS mailing list. > > My colleague, Wan-Teh, will be presenting something very similar at > > IETF 82 this week > > http://tools.ietf.org/html/draft-agl-tls-encryptedclientcerts-00 > > I like that approach, but I don't like that only client certificates > are hidden. Whether client and server are actually distinct is > application specific, and hiding only one side might not always make > sense. Why not move both certificate messages (client and server) > after the changecipherspec? That way TLS will operate as IPSec and > offer anonymity against passive eavesdroppers. But think of what it would mean for your server! Typical TLS servers listen on a network socket and will engage in a TLS handshake with an arbitrary client (either directly or after a STARTTLS protocol upgrade). If such a client starts a plain TLSv1.0 handshake, the server will have only two choices: send his server certificate or abort the handshake. There is no need for the "attacker" to perform an active attack (MitM) on some other connection. Only being able to connect to the same server independently. -Martin From marsh@extendedsubset.com Wed Nov 16 11:48:52 2011 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 D45E11F0C3C for ; Wed, 16 Nov 2011 11:48:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rqqTRR3T7xUf for ; Wed, 16 Nov 2011 11:48:47 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 03E501F0C38 for ; Wed, 16 Nov 2011 11:48:47 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1RQlTR-0005TB-Qn; Wed, 16 Nov 2011 19:48:45 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id C5BDC63C4; Wed, 16 Nov 2011 19:48:40 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+bhoEQbxdYqEG5oyVkGFI1xNcQlLePAMY= Message-ID: <4EC41398.8000800@extendedsubset.com> Date: Wed, 16 Nov 2011 13:48:40 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: mrex@sap.com References: <201111161930.pAGJUVBW002655@fs4113.wdf.sap.corp> In-Reply-To: <201111161930.pAGJUVBW002655@fs4113.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: agl@chromium.org, wtc@chromium.org, tls@ietf.org Subject: Re: [TLS] Fwd: Client TLS Identity Protection: 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, 16 Nov 2011 19:48:52 -0000 On 11/16/2011 01:30 PM, Martin Rex wrote: > > Typical TLS servers listen on a network socket and will engage > in a TLS handshake with an arbitrary client (either directly > or after a STARTTLS protocol upgrade). If such a client > starts a plain TLSv1.0 handshake, the server will have only > two choices: send his server certificate or abort the handshake. > > There is no need for the "attacker" to perform an active attack (MitM) > on some other connection. Only being able to connect to the > same server independently. It's obviously a much smaller capability than full MitM, but that counts as an "active attack" in my (unofficial) nomenclature. There do appear to be lots of cases where pure passive eavesdropping happens and an active attack would not. (Though not as many as some people hope!) For example, consider the Google street view car Wifi sniffing incident. Regardless of their intent, they ended up capturing some amount of extra packet data. There are now government investigations and a big public debate about the extent to which that data is personally identifying. Like EKR, I'm not so interested in defenses that are defeated by a simple active probe. But there are still probably plenty of times it would come in handy. But that also has to be weighed against the risk of promoting a false sense of security. Something called "Transport Layer Security Client Identity Protection" should be expected to strongly resist all the standard attacks. - Marsh From n.mavrogiannopoulos@gmail.com Wed Nov 16 11:49:26 2011 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 A156E11E80A2 for ; Wed, 16 Nov 2011 11:49:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbzQLAG8uVul for ; Wed, 16 Nov 2011 11:49:26 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id D88CA11E809A for ; Wed, 16 Nov 2011 11:49:25 -0800 (PST) Received: by eyg24 with SMTP id 24so1022187eyg.31 for ; Wed, 16 Nov 2011 11:49:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:openpgp:content-type :content-transfer-encoding; bh=kOVossgUvfDpRkxoWHqZ8eoc76gmzigRyrZ3V13q27I=; b=CvLGpJvGoc1PGI8D72zxYeKaw7l1q/5ycQcUeVmdddBhyKOsRV37SaEQ9EIs2qJ45E 7pHqNW0lDrpI23a0jo4HamjV9GzaAyFTFPaKJw9wiQ7lcM66Vaeo++b1S5OUrxMCj5Zn J/bTMHMPAvjU9sRaEavyyUQm+bUWUlrvSvn6E= Received: by 10.213.35.145 with SMTP id p17mr372092ebd.77.1321472964888; Wed, 16 Nov 2011 11:49:24 -0800 (PST) Received: from [10.100.2.14] (d51A49E78.access.telenet.be. [81.164.158.120]) by mx.google.com with ESMTPS id 5sm81147728eev.2.2011.11.16.11.49.23 (version=SSLv3 cipher=OTHER); Wed, 16 Nov 2011 11:49:24 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <4EC4143A.6010808@gnutls.org> Date: Wed, 16 Nov 2011 20:51:22 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Icedove/3.1.15 MIME-Version: 1.0 To: mrex@sap.com References: <201111161930.pAGJUVBW002655@fs4113.wdf.sap.corp> In-Reply-To: <201111161930.pAGJUVBW002655@fs4113.wdf.sap.corp> X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: wtc@chromium.org, agl@chromium.org, tls@ietf.org Subject: Re: [TLS] Fwd: Client TLS Identity Protection: 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, 16 Nov 2011 19:49:26 -0000 On 11/16/2011 08:30 PM, Martin Rex wrote: > Nikos Mavrogiannopoulos wrote: >> >> On Wed, Nov 16, 2011 at 4:34 PM, Adam Langley wrote: >>> On Wed, Nov 16, 2011 at 3:25 AM, Badra wrote: >>>> It's been a couple of years since "Client TLS Identity Protection" was >>>> discussed on the TLS mailing list. >>> My colleague, Wan-Teh, will be presenting something very similar at >>> IETF 82 this week >>> http://tools.ietf.org/html/draft-agl-tls-encryptedclientcerts-00 >> >> I like that approach, but I don't like that only client certificates >> are hidden. Whether client and server are actually distinct is >> application specific, and hiding only one side might not always make >> sense. Why not move both certificate messages (client and server) >> after the changecipherspec? That way TLS will operate as IPSec and >> offer anonymity against passive eavesdroppers. > > But think of what it would mean for your server! > Typical TLS servers listen on a network socket and will engage > in a TLS handshake with an arbitrary client (either directly > or after a STARTTLS protocol upgrade). If such a client > starts a plain TLSv1.0 handshake, the server will have only > two choices: send his server certificate or abort the handshake. Why is that dilema? > There is no need for the "attacker" to perform an active attack (MitM) > on some other connection. Only being able to connect to the > same server independently. HTTP servers don't really gain from this protection, but consider a chat client connecting to another using TLS. It doesn't matter which one is the server or the client. Both need their certificates hidden. regards, Nikos From nico@cryptonector.com Wed Nov 16 12:03:01 2011 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 5753421F8BFB for ; Wed, 16 Nov 2011 12:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[AWL=0.071, 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 rqZ9EvOdTAAq for ; Wed, 16 Nov 2011 12:03:00 -0800 (PST) Received: from homiemail-a34.g.dreamhost.com (caiajhbdcahe.dreamhost.com [208.97.132.74]) by ietfa.amsl.com (Postfix) with ESMTP id CDE7021F8BF7 for ; Wed, 16 Nov 2011 12:03:00 -0800 (PST) Received: from homiemail-a34.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTP id E0D8C10079 for ; Wed, 16 Nov 2011 12:02:54 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a34.g.dreamhost.com (Postfix) with ESMTPSA id DF3CE1006E for ; Wed, 16 Nov 2011 12:02:40 -0800 (PST) Received: by ywt34 with SMTP id 34so111230ywt.31 for ; Wed, 16 Nov 2011 12:02:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.161.132 with SMTP id t4mr34161874icx.16.1321473757654; Wed, 16 Nov 2011 12:02:37 -0800 (PST) Received: by 10.68.192.70 with HTTP; Wed, 16 Nov 2011 12:02:37 -0800 (PST) In-Reply-To: <4EC4143A.6010808@gnutls.org> References: <201111161930.pAGJUVBW002655@fs4113.wdf.sap.corp> <4EC4143A.6010808@gnutls.org> Date: Wed, 16 Nov 2011 14:02:37 -0600 Message-ID: From: Nico Williams To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Cc: agl@chromium.org, wtc@chromium.org, tls@ietf.org Subject: Re: [TLS] Fwd: Client TLS Identity Protection: 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, 16 Nov 2011 20:03:01 -0000 On Wed, Nov 16, 2011 at 1:51 PM, Nikos Mavrogiannopoulos wrote: > HTTP servers don't really gain from this protection, but consider a chat > client connecting to another using TLS. It doesn't matter which one is > the server or the client. Both need their certificates hidden. You can't protect both identities from active attack. You can protect one from passive attacks and the other from active (and passive) attacks. If both identities require equal protection, then what? All identities have equal privacy requirements, but some have more equal privacy needs. For peer-to-peer networking you'll just have to allow one identity to be less protected than the other, but since anyone can ask for that node's identity, you've got no real protection for it at all. Peers in p2p might use oob methods for exchanging pseudonymous PSK credentials, or they might use DHE or ephemeral self-signed certs and then confirm the connection in an oob way (not unlike OTR). I think it's best to leave the p2p case out of scope, or to at most specify what material p2p users would have to confirm is the same for a given connection in an oob way. There probably is real value in protecting client identities (and if we client/server role reversal were common, then real value in protecting one of the two identities), but much less in protecting both. Nico -- From ynir@checkpoint.com Wed Nov 16 15:22:52 2011 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 2CD1821F8D1E for ; Wed, 16 Nov 2011 15:22:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.447 X-Spam-Level: X-Spam-Status: No, score=-10.447 tagged_above=-999 required=5 tests=[AWL=0.152, 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 FxdvyGht0l5N for ; Wed, 16 Nov 2011 15:22:51 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 4246821F8C93 for ; Wed, 16 Nov 2011 15:22:50 -0800 (PST) X-CheckPoint: {4EC44573-0-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pAGNML95020558; Thu, 17 Nov 2011 01:22:22 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 17 Nov 2011 01:22:21 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Thu, 17 Nov 2011 01:22:21 +0200 From: Yoav Nir To: Nikos Mavrogiannopoulos Date: Thu, 17 Nov 2011 01:22:18 +0200 Thread-Topic: [TLS] Fwd: Client TLS Identity Protection: Thread-Index: AcyktpbRZYxAK4yOTlqbcyMVSj+MnQ== Message-ID: <6DC4EFFC-AB78-40D5-A085-73780F245EBB@checkpoint.com> References: <201111161930.pAGJUVBW002655@fs4113.wdf.sap.corp> <4EC4143A.6010808@gnutls.org> In-Reply-To: <4EC4143A.6010808@gnutls.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "agl@chromium.org" , "wtc@chromium.org" , "tls@ietf.org" Subject: Re: [TLS] Fwd: Client TLS Identity Protection: 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, 16 Nov 2011 23:22:52 -0000 On Nov 17, 2011, at 3:51 AM, Nikos Mavrogiannopoulos wrote: >=20 >> There is no need for the "attacker" to perform an active attack (MitM) >> on some other connection. Only being able to connect to the >> same server independently. >=20 > HTTP servers don't really gain from this protection, but consider a chat > client connecting to another using TLS. It doesn't matter which one is > the server or the client. Both need their certificates hidden. That's what PSK will get you. PSKs are harder to provision, but both sides = need to know the PSK for the handshake to succeed. With public keys in certificates, no matter how you design the protocol, on= e side is going to disclose their identity first. In TLS that is not the se= rver. In IKE, it's the initiator. From mrex@sap.com Wed Nov 16 15:43:00 2011 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 C1FDE21F8BE8 for ; Wed, 16 Nov 2011 15:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.142 X-Spam-Level: X-Spam-Status: No, score=-10.142 tagged_above=-999 required=5 tests=[AWL=0.107, 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 TnylzGKseLPw for ; Wed, 16 Nov 2011 15:43:00 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 0BB1A21F8BBE for ; Wed, 16 Nov 2011 15:42:59 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id pAGNgjgk023652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Nov 2011 00:42:46 +0100 (MET) From: Martin Rex Message-Id: <201111162342.pAGNgip3017890@fs4113.wdf.sap.corp> To: nmav@gnutls.org (Nikos Mavrogiannopoulos) Date: Thu, 17 Nov 2011 00:42:44 +0100 (MET) In-Reply-To: <4EC4143A.6010808@gnutls.org> from "Nikos Mavrogiannopoulos" at Nov 16, 11 08:51:22 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: wtc@chromium.org, agl@chromium.org, tls@ietf.org Subject: Re: [TLS] Fwd: Client TLS Identity Protection: 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: Wed, 16 Nov 2011 23:43:00 -0000 Nikos Mavrogiannopoulos wrote: > > On 11/16/2011 08:30 PM, Martin Rex wrote: > > > > But think of what it would mean for your server! > > > > Typical TLS servers listen on a network socket and will engage > > in a TLS handshake with an arbitrary client (either directly > > or after a STARTTLS protocol upgrade). If such a client > > starts a plain TLSv1.0 handshake, the server will have only > > two choices: send his server certificate or abort the handshake. > > Why is that dilema? That is a principal characteristic of Public Key technology whenever it is used in combination with signed associations of identity, such as X.509 certs. It does not happen if there is the requirement that keys must be pre-shared and each peer must know in advance who it is talking to. As soon as the peer whose key is used first reveals an identifier for its key, its identity will be recoverable for everyone who also has that (public) key pre-shared or some means to obtain the key. > > There is no need for the "attacker" to perform an active attack (MitM) > > on some other connection. Only being able to connect to the > > same server independently. > > HTTP servers don't really gain from this protection, but consider a chat > client connecting to another using TLS. It doesn't matter which one is > the server or the client. Both need their certificates hidden. I believe that is to be impossible whenever the key that gets used first is identified/distinguished somehow instead of pre-known to the peer and implied. Even when doing anon-DH first and then mutual authentication, any interested party can try the same with the server, succeed the anon-DH handshake and learn the TLS servers certificate, even though that certificate no longer travels over the wire in plaintext. That is an authentication bootstrapping problem. It will not go away, no matter how much code and protocol overhead you throw at it. -Martin From ietf@meetecho.com Wed Nov 16 23:02:01 2011 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 73A4511E809B for ; Wed, 16 Nov 2011 23:02:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.719 X-Spam-Level: X-Spam-Status: No, score=-0.719 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 jm202bcx5rcu for ; Wed, 16 Nov 2011 23:02:00 -0800 (PST) Received: from smtplq01.aruba.it (smtplq-out18.aruba.it [62.149.158.38]) by ietfa.amsl.com (Postfix) with SMTP id 4057711E8083 for ; Wed, 16 Nov 2011 23:02:00 -0800 (PST) Received: (qmail 28318 invoked by uid 89); 17 Nov 2011 06:55:19 -0000 Received: from unknown (HELO smtp2.aruba.it) (62.149.158.222) by smtplq01.aruba.it with SMTP; 17 Nov 2011 06:55:19 -0000 Received: (qmail 20178 invoked by uid 89); 17 Nov 2011 06:55:19 -0000 Received: from unknown (HELO ?130.129.21.177?) (ietf@meetecho.com@130.129.21.177) by smtp2.ad.aruba.it with SMTP; 17 Nov 2011 06:55:19 -0000 Message-ID: <4EC4AFCD.1040102@meetecho.com> Date: Thu, 17 Nov 2011 07:55:09 +0100 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: TLS@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp2.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq01.aruba.it 1.6.2 0/1000/N Subject: [TLS] Meetecho support for TLS WG meeting session 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, 17 Nov 2011 07:02:01 -0000 Hi all, a virtual room has been reserved on the Meetecho system for today's TLS WG meeting session. Access to the on-line session (including audio and video streams) will be available from 5:40pm at: http://www.meetecho.com/ietf82/tls The Meetecho session automatically logs you into the standard IETF jabber room. So, from there, you can have an integrated experience involving all media and allowing you to interact with the room. A tutorial of interactivity features of the tool can be found at: http://www.meetecho.com/ietf82/tutorials For further information you can contact us at ietf-support@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From ekr@rtfm.com Wed Nov 16 23:48:27 2011 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 C02DF1F0CB7 for ; Wed, 16 Nov 2011 23:48:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.943 X-Spam-Level: X-Spam-Status: No, score=-102.943 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-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 WqsVKDFfCPDm for ; Wed, 16 Nov 2011 23:48:27 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id E5AD41F0C82 for ; Wed, 16 Nov 2011 23:48:26 -0800 (PST) Received: by ggnr5 with SMTP id r5so809218ggn.31 for ; Wed, 16 Nov 2011 23:48:26 -0800 (PST) Received: by 10.236.72.132 with SMTP id t4mr7032619yhd.58.1321516106467; Wed, 16 Nov 2011 23:48:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.146.88.36 with HTTP; Wed, 16 Nov 2011 23:47:45 -0800 (PST) X-Originating-IP: [74.95.2.173] In-Reply-To: References: From: Eric Rescorla Date: Wed, 16 Nov 2011 23:47:45 -0800 Message-ID: To: Paul Wouters Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] New Version Notification for draft-wouters-tls-oob-pubkey-01.txt (fwd) 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, 17 Nov 2011 07:48:27 -0000 Extending TLS to support a raw public key seems like a good idea and I support taking it on. Extending it to suppress the public key and instead send a hash from server to the client seems less so; if the server sends the public key, it works if the client knows either (a) the server public key or (b) a digest of the public key. Sending a digest only works if the client already knows the public key, which seems far less likely. If you want to suppress the server sending the key, a better (and more general) solution is to resurrect cached-info. This would work with both raw keys and certificates. -Ekr On Mon, Oct 31, 2011 at 4:21 PM, Paul Wouters wrote: > > This is the new version of the draft incorporating the feedback from Queb= ec > City > and the TLS list since then. It changes the draft from a new TLS extensio= n > to a > new Certificate Type for raw keys. > > It also merges in the unpublished draft material from Hannes Tschofenig > and Tero Kivinen whom had also been working on raw RSA > TLS keys for use with CoAP (eg devices with no real time clock where > PKIX validation cannot work) > > I did not yet change the draft ofrom individual submission to working gro= up > item, > as I was waiting for confirmation on the TLW WG list of the last Quebec C= ity > meeting. > > http://tools.ietf.org/html/draft-wouters-tls-oob-pubkey-01 > > Paul > > ---------- Forwarded message ---------- > Date: Mon, 31 Oct 2011 17:44:35 > From: internet-drafts@ietf.org > Cc: weiler@tislabs.com, hannes.tschofenig@gmx.net, gnu@toad.com, > =A0 =A0paul@xelerance.com, kivinen@iki.fi > To: paul@xelerance.com > Subject: New Version Notification for draft-wouters-tls-oob-pubkey-01.txt > X-Spam-Flag: NO > > A new version of I-D, draft-wouters-tls-oob-pubkey-01.txt has been > successfully submitted by Paul Wouters and posted to the IETF repository. > > Filename: =A0 =A0 =A0 =A0draft-wouters-tls-oob-pubkey > Revision: =A0 =A0 =A0 =A001 > Title: =A0 =A0 =A0 =A0 =A0 TLS out-of-band public key validation > Creation date: =A0 2011-10-31 > WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission > Number of pages: 11 > > Abstract: > =A0 This document specifies a new TLS certificate type for exchanging raw > =A0 public keys or their fingerprints in Transport Layer Security (TLS) > =A0 and Datagram Transport Layer Security (DTLS) for use with out-of-band > =A0 authentication. =A0Currently, TLS authentication can only occur via > =A0 PKIX or OpenPGP certificates. =A0By specifying a minimum resource for > =A0 raw public key exchange, implementations can use alternative > =A0 authentication methods. > > =A0 One such method is using DANE Resource Records secured by DNSSEC, > =A0 Another use case is to provide authentication functionality when used > =A0 with devices in a constrained environment that use whitelists and > =A0 blacklists, as is the case with sensors and other embedded devices > =A0 that are constrained by memory, computational, and communication > =A0 limitations where the usage of PKIX is not feasible. > > =A0 The new certificate type specified can also be used to reduce the > =A0 latency of a TLS client that is already in possession of a validated > =A0 public key of the TLS server before it starts a (non-resumed) TLS > =A0 handshake. > > > > > The IETF Secretariat > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From mbadra@gmail.com Thu Nov 17 01:49:55 2011 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 A3D0921F9A80 for ; Thu, 17 Nov 2011 01:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 WoeARnofHG6Y for ; Thu, 17 Nov 2011 01:49:55 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2A01D21F9AF3 for ; Thu, 17 Nov 2011 01:49:48 -0800 (PST) Received: by vcbfl15 with SMTP id fl15so1869000vcb.31 for ; Thu, 17 Nov 2011 01:49:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; bh=YHmjerHhxmGlqczoomJ3BYZO7MfGJL953jT8Adtjh0s=; b=ioFpkpaMkd/Q+m3LR5XGcqYfp5mr7gWGi07IvrF9cpCzjK0vdsuONdzrNToff52AH4 0WKcPbpdVCJv9NGZ6tmTl+21URWnsFOp0J+RBlOHpqfNuZJy2iJdu6kQya+7o3KFbAl6 7cnZmjFeIWIAGHg4aU0JQ4dFTLHY9l4EQld8g= MIME-Version: 1.0 Received: by 10.52.72.227 with SMTP id g3mr55926238vdv.10.1321523387591; Thu, 17 Nov 2011 01:49:47 -0800 (PST) Received: by 10.220.201.71 with HTTP; Thu, 17 Nov 2011 01:49:47 -0800 (PST) Date: Thu, 17 Nov 2011 10:49:47 +0100 Message-ID: From: Badra To: tls@ietf.org Content-Type: multipart/alternative; boundary=bcaec5016525146aeb04b1eb24c8 Subject: [TLS] TLS identity protection using Signaling Cipher Suite Value 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, 17 Nov 2011 09:49:55 -0000 --bcaec5016525146aeb04b1eb24c8 Content-Type: text/plain; charset=ISO-8859-1 Dear TLS WG, I posted a document that defines a pecial Signaling Cipher Suite Value to enable the negotiation of the client identity protection. This approach had been initially proposed by Francisco Corella, to the TLS mailing list during August 2000. http://www.ietf.org/id/draft-badra-tls-identity-protection-00.txt Best regards Badra --bcaec5016525146aeb04b1eb24c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable --bcaec5016525146aeb04b1eb24c8-- From ondrej.sury@nic.cz Thu Nov 17 02:40:49 2011 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 74E9521F9BE2 for ; Thu, 17 Nov 2011 02:40:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, 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 WmnTYUcE9u2w for ; Thu, 17 Nov 2011 02:40:48 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 7A2FD21F9BE1 for ; Thu, 17 Nov 2011 02:40:48 -0800 (PST) Received: from [IPv6:2001:df8::96:6414:bef:6bde:9d08] (unknown [IPv6:2001:df8:0:96:6414:bef:6bde:9d08]) by mail.nic.cz (Postfix) with ESMTPSA id CE3082A2E19; Thu, 17 Nov 2011 11:40:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1321526447; bh=8W+ojxop5JqVQlul94nWSkiZIxaR8JVdr6ZSDjZ3mvs=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=TjI1xUffjtWaZwXQuLiejLlHmfrWN6gvlDv+KLTtpZrUEEwqtLvbvsyvN3MMvPZ/V WLd455ishk86uu/RYn2+LdYfeHVOLlOlFYWk7T0yjIXfFwL1uvmUreO/aDORA7ptMu qX72buxaGusRRC7b0gRfIoImpmWwftN3jSKRQM2w= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Thu, 17 Nov 2011 18:40:43 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <8766068B-882E-41F9-B908-49088E451F03@nic.cz> References: To: Paul Wouters X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: tls@ietf.org Subject: Re: [TLS] New Version Notification for draft-wouters-tls-oob-pubkey-01.txt (fwd) 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, 17 Nov 2011 10:40:49 -0000 Hi Paul, could you please drop this sentence from your draft? For example, if public keys were obtained using [DANE] it is appropriate to use DNSSEC to authenticate the public keys. I know that it's just an example, but I can see that this could lead to chaos and mayhem if the DANE protocol makes different assertion in the future. So unless DANE protocol blooms into the RFC before your draft, please don't make any assumptions, thanks. And one minor nit, change Some small embedded devices use the UDP based [CoAP], a specialized constrained networks and nodes for machine-to-machine applications. to Some small embedded devices use the UDP based Constrained Application Protocol [CoAP], a specialized web transfer protocol for use with constrained networks and nodes for machine-to-machine applications. or simpler Some small embedded devices use the UDP based Constrained Application Protocol [CoAP] for use with constrained networks and nodes for machine-to-machine applications. for better readability. On 1. 11. 2011, at 7:21, Paul Wouters wrote: >=20 > This is the new version of the draft incorporating the feedback from = Quebec City > and the TLS list since then. It changes the draft from a new TLS = extension to a > new Certificate Type for raw keys. >=20 > It also merges in the unpublished draft material from Hannes = Tschofenig > and Tero Kivinen whom had also been working on raw = RSA > TLS keys for use with CoAP (eg devices with no real time clock where > PKIX validation cannot work) >=20 > I did not yet change the draft ofrom individual submission to working = group item, > as I was waiting for confirmation on the TLW WG list of the last = Quebec City > meeting. >=20 > http://tools.ietf.org/html/draft-wouters-tls-oob-pubkey-01 >=20 > Paul >=20 > ---------- Forwarded message ---------- > Date: Mon, 31 Oct 2011 17:44:35 > From: internet-drafts@ietf.org > Cc: weiler@tislabs.com, hannes.tschofenig@gmx.net, gnu@toad.com, > paul@xelerance.com, kivinen@iki.fi > To: paul@xelerance.com > Subject: New Version Notification for = draft-wouters-tls-oob-pubkey-01.txt > X-Spam-Flag: NO >=20 > A new version of I-D, draft-wouters-tls-oob-pubkey-01.txt has been = successfully submitted by Paul Wouters and posted to the IETF = repository. >=20 > Filename: draft-wouters-tls-oob-pubkey > Revision: 01 > Title: TLS out-of-band public key validation > Creation date: 2011-10-31 > WG ID: Individual Submission > Number of pages: 11 >=20 > Abstract: > This document specifies a new TLS certificate type for exchanging = raw > public keys or their fingerprints in Transport Layer Security (TLS) > and Datagram Transport Layer Security (DTLS) for use with = out-of-band > authentication. Currently, TLS authentication can only occur via > PKIX or OpenPGP certificates. By specifying a minimum resource for > raw public key exchange, implementations can use alternative > authentication methods. >=20 > One such method is using DANE Resource Records secured by DNSSEC, > Another use case is to provide authentication functionality when = used > with devices in a constrained environment that use whitelists and > blacklists, as is the case with sensors and other embedded devices > that are constrained by memory, computational, and communication > limitations where the usage of PKIX is not feasible. >=20 > The new certificate type specified can also be used to reduce the > latency of a TLS client that is already in possession of a validated > public key of the TLS server before it starts a (non-resumed) TLS > handshake. >=20 >=20 >=20 >=20 > The IETF Secretariat > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From Jeff.Hodges@KingsMountain.com Thu Nov 17 03:31:19 2011 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 2858021F9C0B for ; Thu, 17 Nov 2011 03:31:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.193 X-Spam-Level: X-Spam-Status: No, score=-100.193 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, 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 A4v1-tbUAtMX for ; Thu, 17 Nov 2011 03:31:18 -0800 (PST) Received: from oproxy7-pub.bluehost.com (oproxy7.bluehost.com [IPv6:2605:dc00:100:2::a7]) by ietfa.amsl.com (Postfix) with SMTP id DA8B021F9C0A for ; Thu, 17 Nov 2011 03:31:17 -0800 (PST) Received: (qmail 1707 invoked by uid 0); 17 Nov 2011 11:31:17 -0000 Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by oproxy7.bluehost.com with SMTP; 17 Nov 2011 11:31:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Type:Subject:To:MIME-Version:From:Date:Message-ID; bh=K8nsmjkP/MFaiXN6svDcDeE0Df84rJU7uGMtiZkea8k=; b=dmrNM8QavoxzZcGuGuzZ6hT75YLr/hUUHooPDYnyBatneoezgTfB9Lo7yz1sYDD83z1TIKi8bu5r6BzTQAgiGthAVQ04gmXpNW6hDBDyWvaU+bnEEifVjpSTRRfZ8vlO; Received: from dhcp-67bb.meeting.ietf.org ([130.129.103.187]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1RR0BY-00077t-Hg; Thu, 17 Nov 2011 04:31:17 -0700 Message-ID: <4EC4F080.7080100@KingsMountain.com> Date: Thu, 17 Nov 2011 03:31:12 -0800 From: =JeffH User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Eric Rescorla , Joe Salowey , IETF TLS WG Content-Type: multipart/mixed; boundary="------------000702050904050105000109" X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 130.129.103.187 authed with jeff.hodges+kingsmountain.com} Subject: [TLS] raw unofficial minutes: TLS WG: IETF-82 Taipei 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, 17 Nov 2011 11:31:19 -0000 This is a multi-part message in MIME format. --------------000702050904050105000109 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit These could undoubtedly use some cleanup wrt things I missed and/or got wrong wrt what folks said. please consider them to be preliminary and unofficial. HTH, =JeffH ------ --------------000702050904050105000109 Content-Type: text/plain; name="notes-ietf-82-tls--taipei--2011-11-17.txt" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="notes-ietf-82-tls--taipei--2011-11-17.txt" VExTIFdHCklFVEYgODIKCkRUTFMgMS4yIElTIElOIEFVVEg0OCB3YWl0aW5nIGZvciBhdXRo b3IgcmVzcG9uc2UKCkVLUiBzZXogaGUnbGwgZ2V0IGJhY2sgdG8gcmZjLWVkaXRvciBpbiBh IGRheSBvciB0d28uCgoKSm9lIHF1ZXJ5aW5nIGFib3V0IGR0bHMgaGVhcnRiZWF0IHNwZWMs IGFuZCBoYXZpbmcgYSBicmllZiBkaXNjdXNzaW9uIG9uIGxpc3QgaWYgdGhlcmUncyBhbnkg c3VnZ2VzdGlvbnMvY2hhbmdlcyB0byBpdAoKICBiZWxpZXZlcyB0aGVzZSBhcmUgdGhpbmdz IHRoZXkgY2FuIHNvbHZlIGVhc2lseSBhbmQgcmVzdWx0cyB3aWxsICBiZSBzZW50IHRvIGxp c3QKICAKICAKcXVldWVkIGRvY3MKCiAgYWVzLWNjbSBjaXBoZXJzCiAgCiAgc2VhbiB0dXJu ZXI6ICBvbiBpcHIgc3RtdCwgbm90ZXMgdGhhdCBpZXNnIHdhbnRzIHRvIHNlZSB0aGF0IHRo ZXJlJ3MgYSBwcm9wZXIgaXByIGRlY2xhcmF0aW9uIHRyYWlsCiAgClRlcm8gYXNrcyAKCiAg aW4gc3BlYyBpdCdzIGludGVuZGVkIHRvIHJ1biBvbiA4MDIuPyBhbmQgcnVuIG9uIGNjbS1z dGFyICg/KQogIAogIHBhdWwgaG9mZm1hbjogaXByIHN0bXQgYXJlIGRpZmZlcmVudCBmb3Ig dGhpbmdzIGNvbWluZyB0aHJ1IHppZ2J5IHRoYW4gdGhydSBpZXRmLCBzbyB0aGUgdGVjaG5v bG9neSBpcyBmaW5lLCBidXQgdGhlIGlwciBvdWdodCB0byBiZSBjbGFyaWZpZWQKICAKClBy b3Bvc2VkIGV4dGVuc2lvbnMKIGpvZSBwb3N0ZWQgYSBkcmFmdCAiZXh0ZW5zaW9uIHBvbGlj eSIgdG8gdGhlIGxpc3QgdGhlIG90aGVyIGRheQogc28gYWZ0ZXIgdGhpcyBtZWV0aW5nIHdp bGwgaGF2ZSB0byBzZWUgaG93IHRoZSBwb2xpY3kgYXBwbGllcyB0byB0aGUgZXh0ZW5zaW9u IGRyYWZ0cyB0aGF0IGFyZSBvbiB0aGUgZG9ja2V0CiAKUHJvY2VzcyBmb3IgZXh0ZW5zaW9u cwogam9lIHRoaW5rcyB0aGlzIGRyYWZ0IHBvbGljeSBpcyBwcmV0dHkgZ29vZCwgc2hvdWxk IHRha2UgZGlzY3Vzc2lvbiB0byB0aGUgbGlzdCAoaXQgd2FzIHB1YidkIHZlcnkgcmVjZW50 bHkpCiAobm8gY29tbWVudHMgYXQgbWljKQogCgoKZG9yb3RoeSBzdGFubGV5IGFza3M6IGlz IHRoZSBvcmlnaW4gb2YgdGhlIHJlcXVlc3Qgd3J0ICBzbWFydCBlbmVyZ3k/CgpNYXR0ICg/ KSBhbnN3ZXJzICJ5ZXMiCgpkb3JvdGh5IHN0YW5sZXkgLS0gbm90ZXMgdGhhdCBpdCBoYXMg Z3JlYXRlciBhcHBsaWNhYmlsaXR5IHRoYW4ganVzdCA4MDIuPwoKCgpleHRlbnNpb25zIGRp c2N1c3Npb24KLS0tLS0tLS0tLS0tLS0tLS0tLS0tCgp0bHMgb3JpZ2luLWJvdW5kIGNlcnRp ZmljYXRlcyAtLSB3YW4tdGVoIGNoYW5nIChXVEMpIHByZXNlbnRpbmcKCiB3aGVuIGRpc2N1 c3NlZCBPQkMgd2l0aCBtb3ogLS0gdGhleSB3YW50IGVuY3J5cGVkIGNlcnRzCiAKIHNvIHdp bGwgZGlzY3VzcyBlbmNyeXB0ZWQgY2VydHMgZXh0ZW5zaW9uIGZpcnN0CiAKIApUTFMgZW5j cnlwdGVkIGNsaWVudCBjZXJ0cwotLS0tLS0tLS0tLS0tLS0tCgogaW1wbCdkIGZvciBOU1Mg YW5kIE9wZW5TU0wKIAogdGhlIGV4dGVuc2lvbiBqdXN0IGluZGljYXRlcyBzdXBwb3J0IGZv ciBzdWNoIGNlcnRzCiAKIHRoaXMgY2hhbmdlcyB0aGUgc2VucXVlbmNlIG9mIHRoZSBoYW5k c2hha2UgbWVzc2VhZ2VzCiAKIGhhcyB0aHJlZSBrbm93biBpc3N1ZXMuLi4KIAogICBpbmNv bXBhdCB3aXRoIERIIG9yIEVDREggY2VydHMKICAgCiAgIHZ1bG4gdG8gZHdvbmdyYWRlIGF0 dGFja3MKICAgCiAgIHJlb3JkZXJzIGhhbmRzaGFrZSBtZXNzYWdlcyBpZSBzZW5kaW5nIG1z Z3MgYnR3biBDaGFuZ2VDaXBoZXJTcGVjIGFuZCBGaW5pc2hlZAogICAKICAgCmVrcjogY291 cGxlIHRob3VnaHRzCiAxLiBlYXN5IHRvIGNoYW5nZSBzdGF0ZSBtYWNoaW5lLCBidXQgd2hh dCBhcmUgY2hhbmdlcyB0byBzZWMgcHJvcGVydGllcz8KICAgZG9udCcgc2VlIGFueXRoaW5n IG9idmlvdXMgYnV0IHdlJ3JlIHNlZWluZyB0aGF0IFRMUyBpcyBtb3JlIGJyaXR0bGUgdGhh biB3ZSB0aG91Z2h0LgogICBoYXZlIHlvdSBkb25lIGFueSBzZWMgYW5hbHlzaXM/CiAgIAog ICBXVEM6IHdlIHRoaW5rIHRoaXMgaXMgc2ltaWxhciB0byB0aGUgZmFsc2Ugc3RhcnQgZXh0 ZW5zaW9uCgogMi4gdGhpcyBkb3duZ3JhZGUgYXR0YWNrIGlzIHRyb3VibGluZwogCiAgIHd0 YzogbWFrZSBpdCBwYXJ0IG9mIE9CQyAKICAgCmVrcjogZG8gd2Ugb25seSBjYXJlIGFib3V0 IGNsaWVudCBhdXRobiwgb3Igb25seSBhYm90dSBPQkMuIGlmIHRoZSBsYXR0ZXIsIHRoZSBw cm9iIGlzIG1vcmUgc2VyaW91cwoKCiAzLiBoYXZlIHlvdSB0aG91Z2h0IGFib3V0IHRoZSBv dGhlciBwcm9wb3NhbD8KIAogV1RDOiBoYXZlIHJlYWQgdGhhdCBkcmFmdCwgdGhpbmtzIHRo aXMgcHJvcG9zYWwgaXMgbW9yZSBzaW1wbGUKIAogc2VhbjogY2lwaGVyIHN1aXRlIGV4cGFu c2lvbig/KSB3aWxsIGNvbWUgYmFjayB0byBiaXRlIHVzCiAKIHd0YzogYmFkcmEgYWxzbyBw cm9wb3NlcyBzdGF0ZSBtYWNoaW5lIGNoYW5nZSBhcyB3ZWxsIGFzIHRoZSBjaXBoZXJzdWl0 ZSBzdHVmZgoKc2VhbiAoc3QpOiBiYWRyYSBoYXMgSVBSIGluIGhpcyBkcmFmdCB0b28gLS0g bmVlZCB0byBjb25zaWRlciB0aGF0CgpXVEM6IGluIHRoZSBOUE4gZHJhZnQsIGl0IGFsc28g Y2hhbmdlcyB0aGUgc3RhdGUgbWFjaGluZSwgc28gaWYgb3RoZXIgZXh0ZW5zaW9ucyBuZWVk IHRvIGRvIHN1Y2ggd2UgbmVlZCB0byB0aGluayBhYm91dCAoZ2VuZXJhbGl6aW5nPykgdGhp cy4uLgoKSm9lUyAoanMpOiB3YW50cyB0byBnZXQgc2Vuc2UgZnJvbSByb29tIG9mIGhvdyBt YW55IGZvbGtzIHRoaW5rIHRoaXMgaXMgdXNlZnVsLi4uLgoKSmVmZkggYXNrcyBmb3IgY2xh cmlmaWNhdGlvb24gb2YgdGhlIHVzZSBjYXNlIGZvciB0aGlzIAoKV1RDIGNsYXJpZmllcyB0 aGF0IHRoZSAiZWNyeXB0ZWQgY2VydCIgZHJhZnQgYWN0dWFsbHkgbWVhbnMgdGhhdCB0aGUg Y2xpZW50IGNlcnQgaXMgY29udmV5ZWQgdG8gdGhlIHNlcnZlciBhdCBhIHBvaW50IGluIHRo ZSBoYW5kc2hha2Ugd2hlbiB0aGUgY2hhbm5lbCBpcyBlbmNyeXB0ZWQgcmF0aGVyIHRoYW4g KGp1c3QpIHRoZSBjZXJ0IGl0c2VsZiBiZWluZyBlbmNyeXB0ZWQuIGhlbmNlIHRoZSBjaGFu Z2UgaW4gdGhlIGhhbmRzaGFrZSBzdGF0ZSBtYWNoaW5lCgpub3RlIHRoYXQgYmFkcmEncyBw cm9wb3NhbCBoYXMgdGhlIGNlcnQgb2JqZWN0IGl0c2VsZiBlbmNyeXB0ZWQKCgpwYXVsIGhv ZmZtYW4ocGgpOiB0aGUgcHJpYWN5IGlzc3VlIGlzIGEgM2QgcGFydHkgb2JzZXJ2aW5nIHRo ZSBoYW5kc2hha2UgYW5kIHNlZWluZyB0aGUgY2xpZW50IGNlcnQgZ28gYnkuICh3dGM6IHll cykKIHBlcmhhcHMgdGhpcyBzaG91bGQganVzdCBiZSB3b3VuZCBpbnRvIHRoZSBPQkMgcHJv cG9zYWwgaXRzZWxmCiB0aGlua3MgdGhlIHByaXZhY3kgZ2FpbiBoZXJlIGlzIHF1ZXN0aW9u YWJsZQogCnd0YzogT0JDcyBhcmUgdXNlZCBpbiBjb25qdW5jdGlvbiB3aXRoIGxvZ2luIGNv b2tpZXMsIHdoaWNoIGFyZSB0eXBpY2FsbHkgcHJvdGVjdGVkIChpZiBvbmUncyB3ZWIgYXBw IGlzIHByb3Blcmx5IGNvbnN0cnVjdGVkKSwgd2FudCB0aGUgY2xpZW50IGNlcnQgdG8gYmUg YWxzbyBzbyBwcm90ZWN0ZWQuCgoKT3JpZ2luIEJvdW5kIENlcnRpZmljYXRlcwotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQoKdGhpcyBwcm9wb3NhbCBiaW5kcyB0aGUgY29va2llcyB0 byB0aGUgdGxzIGNoYW5uZWwKCnNlZSB3d3cuYnJvd3NlcmF1dGgubmV0IGZvciBjb250ZXh0 CgpPcmlnaW4tYm91bmQgY2VydCBpcyBkeW5hbWljYWxseSBnZW4nZCBhbmQgc2VsZi1zaWdu ZWQKYmluZCBjb29raWVzIHRvIHRoaXMKCi0wMSB2ZXJzaW9uIG9mIGRhcmZ0IHJlY2VudGx5 IHVwbG9hZGVkCiBtb3N0bHkgZWRpdG9yaWFsIGNoYW5nZXMKCmltcGxlbWVudGVkIHRoaXMg ZXh0ZW5zaW9uIGluIGNocm9tZSAxNwoKcGxhbm5pbmcgdG8gcnVuIGV4cGVyaW1lbnRzIG9u IGdvb2dsZSBzZXJ2ZXJzIHNvb24KCgpwaDogZG9udCB1bmRlcnN0YW5kIHdoeSBzZW5kIHRo aXMgY2VydCBvdmVyIHBydGVjdGVkIGNoYW5uZWwKICBpcyAgYSBvdGhlcndpc2UgYW5vbiBj ZXJ0IGl0IHNlZW1zCgp3dGM6IGxvZ2luIGNlcnRzIHNob3VsZCBnZXQgc2FtZSBwcm90ZWN0 aW9ucyBhcyBsb2dpbiBjb29raWVzCgpwaDogcGxlbnR5IG9mIGxvZ2luIGNvb2tpZXMgYXJl IHNlbnQgaW4gY2xlYXIKICBkb2Vzbid0IGJlbGlldmUgdGhpcyBpcyBzdWZmaWNpZW50IHJl YXNvbiB0byBtYWtlIGNoYW5nZXMgdG8gc3RhdGUgbWFjaGluZQogIG90aGVyd2lzZSBsaWtl cyB0aGUgT0JDIHByb3Bvc2FsCiAganVzdCBkb2VzbnQgd2FudCB0byBtYWtlIGNoYW5nZXMg dG8gc3RhdGUgbWFjaGluZQogIApIYW5uZXMgVC4gKGh0KTogaG93IG9mdGVuIGRvIHlvdSBn ZXQgbmV3IE9CQyA/ICBpZSBob3cgb2Z0ZW4gcmUtZ2VuJ2Q/Cgp3dGM6IGEgbW9udGggdG8g eWVhci4uLgoKaHQ6IHNvIGxvbmdlciB0aGFuIGNvb2tpZXMuLi4/CgpzdDogaSBkdW5uby4u LgoKd3RjOiAuLi4uCgpodDogd291bGQgYmUgaW50ZXJlc3RpbmcgdG8ga25vdyBob3cgbG9u ZyBjb29raWVzIG9mdGVuIHBlcnNpc3QuLi4uCgpwaDogdGhlIGNlcnQgaXNuJ3QgdGhlIGFj dHVhbCBpZGVudGlmaWVyLCBhbmQgY29tZXMgd2l0aCBhIGNvb2tpZSwgYW5kIGlzIHRpZWQg dG8gaXQgLS0gd2hlbiBjb29raWUgZXhwaXJlcywgZG8geW91IGRlbGV0ZSBPQkMgdG9vPwoK d3RjOiBub3Qgc3VyZQoKc3Q6IGxvb2tlZCBpbiBoaXMgY29va2llIHN0b3JlIGFuZCBub3Rl cyB0aGF0IGhlIGhhcyBvbmVzIGluIHRoZXJlIHdpdGggbXVsdGkteWVhciBsaWZldGltZXMK Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KTmV4dCBQcm90b2NvbCBOZWdvdGlh dGlvbiAoTlBOKQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCgpnb2FsIGhlcmUg aXMgdG8gc2F2ZSBhIHJvdW5kdHJpcCB3aGVuIGxheWVyaW5nIGFuIGFwcCBwcm90IG92ZXIg dGxzLCBlZyBodHRwL3RscyBvciBzcGR5L3RscwoKc3RhdHVzIGlzIHNwZWMganVzdCBleHBp cmVkLCBidXQgaXMgYSBnb29nbGUgdGVjaCBub3RlCgppcyBpbXBsJ2QgaW4gY2hyb21lLCBp bXBsIHVwY29taW5nIGluIEZpcmVmb3gKCmlzc3VlcyByYWlzZWQgaW4gcmV2aWV3cyBvZiBk cmFmdAoKIHByb3Qgc3RyaW5ncyB2cyBwb3J0ICNzCiAgcHJlZmVyIHByb3Qgc3RyaW5ncwog IGVnIHdhbnQgdG8gYmUgYWJsZSB0byBzaWduYWwgV2ViU29ja2V0cyBvdmVyIHNwZHkKICAK IGVuY3J5cHRlZCBoYW5kc2hha2UgbWVzc2FnZXMgYnR3biBjaGFuZ2VDaXBoZXJTcGVjIGFu ZCBGaW5pc2hlZCAoaWUgaGFuZHNoYWtlIHN0YXRlIG1hY2hpbmUgY2hhbmdlcykKIAogCkpp bVNjaGFhZCAoSlNkKTogdGhlIHNlcnZlciBtYXkgZ2V0IGFjY2VzcyB0byBkaWZmIHByb3Rz IGJhc2VkIG9uIHdobyB0aGUgY2xpZW50IGlzCiAgZWc6IGdvb2dsZSB3b250IGxldCBtZSBy dW4gc210cCB1bmxlc3MgaSBoYXZlIGEgY2VydGFpbiBhY2NvdW50CiAgCnd0YzsgdGhpcyBp c24ndCBhbiBpc3N1ZSBmb3IgdGhlIG1haW4gdXNlIGNhc2UsIGVnIG5lZ290aWF0ZSBkaWZm IHZlcnNpb25zIG9mIGFuIGFwcCBwcm90b2NvbCBvdmVyIFRMUywgYW5kIHNhdmUgYSByb3Vu ZCB0cmlwCgpwaDogTlBOIGNhbiBiZSB1c2Z1bCBmb3Igbm90IGxldHRpbmcgbWlkZGxlIGJv eGVzIGtub3cgd2hhdCBhcHAgcHJvdCBpcyBnb2luZyB0byBnZXQgcnVuIG92ZXIgVExTCgp1 c2UgY2FzZXMKICAxLiBzZXJ2ZXIgZG9lc24ndCB3YW50IHRvIGxldCBvYnNlcnZlciBzZWUg d2hhdCBhcHAgcHJvdHMgaXMgZ29pbmcgdG8gYmUgcnVuIG92ZXIgYSBnaXZlbiBwb3J0CiAg ICBpZSBzbXRwLCBpbWFwLCBwb3AsIGh0dHAsIHdoYXRldmVyCiAgICAKIDIuIHBvcnQgI3Mg YXJlIHNjYXJjZSByZXNvdXJjZSwgZ2V0dGluZyAybmQgcG9ydHMgZm9yICJzZWN1cmUiIHVz ZSBpcyBkaXNjb3VyYWdlZCwgIGhlbHBzIHJldXNlIG9mIHBvcnRzIGluIHNlY3VyZSBmYXNo aW9uCgpla3I6IHRyYWZmaWMgYW5hbHlzaXMgbWFrZXMgZmlndXJpbmcgb3V0IHRoaXMgZWFz eSwgc28gZW5jcnlwIG9mIHByb3QgbmVnb3Rpb25hdGlvbiBpcyB3ZWVrIGFyZ3VtZW50Cgoy LiA/ICB0b28gZmFzdCwgY291bGRuJ3QgaGVhcgogIHRyYW5zcG9ydCBhcmVhIGhhc24ndCBz YWlkIHRoZXkgd29uJ3Qgbm90IGFsbG9jIDJuZCBwb3J0cz8KCmVrcjogd2hhdCBpbSBwdXNo aW5nIGlzIHRoYXQgeW91J3JlIGNoYW5naW5nIHRoZSBoYW5kc2hha2UgbXNnIG9yZGVyaW5n IGluIG9yZGVyIHRvIGV4Y2hhbmdlIHRoZSBuZXh0IHByb3QgbGlzdCBvdmVyIHByb3RlY3Rl ZCBjaGFubmVsCgoKSnM6IGFyZSBmb2xrcyBpbiByb29tIGhlcmUgaW50ZXJlc3RlZCBpbiB0 aGlzPwoKcGg6IGJ1dCBhcmUgeW91IGFza2luZyAiaXMgd2cgd2FudGluZyB0byB0YWtlIHRo aXMgb24/Ij8KCnBzYTogbm8sIGpzdXQgaWYgZm9sa3MgaGVyZSBpbiB0aGlzIHJvb20gYXJl IGZpbmRpbmcgdGhpcyBpbnRlcmVzdGluZy4uLgoKICBhbHNvLCBzcGR5IG1pZ2h0L2NvdWxk IGNvbWUgdG8gYXBwcyBhcmVhLCBzbyB0aGlzIG1pZ2h0IGJlIGludGVyc3RpbmcgZnJvbSB0 aGF0IHBlcnNwZWN0aXZlCiAgCiAgCmpzOiB3aG8gdGhpbmtzIHRoaXMgaXMgaW50ZXJlc3Rp bmc/Cgo8IHNvbWUgaGFuZHMgZ28gdXA+ICAKCmFueW9uZSB0aGluayBpdCdzIGF3ZnVsICAg IDxubyBoYW5kcyBnbyB1cD4KCmVrcjogZG9lc24ndCB0aGluayBpdCBpcyBob3JyaWJsZSwg YnV0IGhhcyBjb25jZXJucy4uLi4KCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQpIYW5uZXMgVC4gOiAgdGxzIG91dC1vZi1iYW5kIHB1Ymxp YyBrZXkgdmFsaWRhdGlvbgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQoKZHJhZnQtd291dGVycy10bHMtb29iLXB1YmtleS0wMQoKVGVybyBh bmQgSGFubmVzIGFyZSBvbiB0aGUgYXV0aG9yIHRlYW0gbm93IHNpbmNlIGlldGYtODEgcXVl YmVjCgoiUmF3UHVibGljS2V5IiAtLSBuZXcgY2VydCB0eXBlIGluIGNsaWVudF9oZWxsbwoK bGV2ZXJhZ2VzIHRoZSBUTFMgQ2VydCB0eXBlcyByZWdpc3RyeSB0aGF0IFJGQyA2MDkxIGRl ZmluZWQKCmNvbnZleSBwdWIga2V5IGluIHN1YmplY3RQdWJsaWNLZXlJbmZvIHN0cnVjdHVy ZSBmcm9tIFguNTA5IGNlcnQgc3RydWN0dXJlcyAoc2VlIGFsc28gcmZjNTI4MCkKCmRvbid0 IG5lZWQgdG8gZGVmaW5lIG5ldyBjaXBoZXJzdWl0ZXMgLS0gYnV0IG5lZWQgdG8gdXNlIGFw cHJvcCBjaXBoZXJzdWl0ZSB3aXRoIHR5cGUgb2YgcHVia2V5IHRoYXQncyBiZWluZyBleGNo YW5nZWQKCmRhbiBoYXJraW5zIChkaCk6IHdoeSBub3QganVzdCBzZW5kIHRoZSByYXcgcHVi IGtleSByYXRoZXIgdGhhbiBzZW5kaW5nIGEgaGFzaCBvZiBpdD8KCnRlcm86IHNlbmQgaGFz aCB0byBrZWVwIGJ5dGVzIG9uIHdpcmUgc21hbGxlcgoKanM6IGl0IG1pZ2h0ICBiZSBhbiBp ZGVhIHRvIHJlc3N1cmVjdCB0aGUgPyB3b3JrIC0tIHRoYXQgbWlnaHQgYWRkcmVzcyB0aGUg aGFzaCB0aGluZwoKZWtyOiB0aGlua3MgcmF3IHB1YiBrZXkgaXMgZ29vZCBpZGVhCiB3b3Vs ZCB1c2UgaXQgaW4gY29yZQogcmVtb3ZlIGhhc2ggdmVyc2lvbiBhbmQgdGFrZSB0aGlzIG9u CiAKcm9iZXJ0IG1vc2tvd2l0eiAocm0pOiBzbWFsbGVyIGlzIGJldHRlcgoKZWtyOiBwdWJr ZXlzIGFyZW4ndCB0aGF0IGJpZwoKcm06IGhhdmUgcmlzayBvZiBmcmFnbWVudGluZyBvbiBj ZXJ0YWluIGxpbmsgbGF5ZXJzIHdpdGggc21hbGwgTVRVcywgZWcgNmxvd3BhbiBvbiBjZXJ0 YWluIG1lZGlhLCB3aWxsIGZyYWcgd2l0aCBiaWcga2V5IC4uLiBzbyB0aGVyZSBpcyB2YWx1 ZSBpbiBzZW5kaW5nIGEgc21hbGxlciBtZXNzYWdlIC4uLi4gbm90IHJlcXVpcmVkIGJ1dCBt aWdodCBiZSBnb29kIGlkZWEKCnN0OiBpZiByZWFsbHkgY29uc3RyYWluZWQsIHVzZSBlbGlw dGljIGZjdXJ2ZSBzbyBrZXlzIGFyZSBzbWFsbGVyCiBzb21lIGNvbW1lbnQgYWJvdXQgaGFz aCBhbGcKIApaYWNoOiB3YW50cyB0byB1c2UgdGhpcyBpbiBDT1JFIAoKanM6IGFza3Mgcm9v bSBhYm91dCBkb2luZyB0aGlzIHdpdGhvdXQgaGFzaGluZyB0aGUga2V5CiAgfjIwIHRoaW5r IHRoYXRzIGZpbmUKICAKSFQ6IHJlc3ViIGRvYyB3L28gaGFzaGVkIHB1YiBrZXkgaW4gaXQ/ CgpqczogeWVzCgotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpEYW4gSGFy a2luczogZHJhZnQtaGFya2lucy10bHMtcHdkCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQoKcHJvcG9zYWwgdG8gZG8gY2VydGlmaWNhdGUtbGVzcyBhdXRobiBpbiBU TFMKCm5vLCB0aGlzIHByb3QgaXMgbm90IHBhdGVudGVkCgp3aHkgbm90IFNSUD8KIEVDIHN1 cHBvcnQKCnVzZSBjYXNlcyBjb21pbmcgZnJvbSBzbWFydC1ncmlkIHdvcmsKIGRldmljZXMg aGF2ZSBsaW1pdGVkIFVJcwogCmNoYW5nZXMgdG8gdGxzLi4uCiB2YXJpb3VzIG5ldyBzdHJ1 Y3R1cmVzIGFyZSBzZW50IGluIGV4aXNpbmcgaGFuZHNoYWtlIG1zZ3MgaW4gb3JkZXIgdG8g ZXhjaGFuZ2UgcmVxdWlzaXRlIHBhcmFtcwogCmVrcjogd2h5J3MgdGhpcyBzZWN1cmUgPwoK ZGg6IHRyaWVkIHRvIGRvIHNvbWUgcHJvb2ZzIGluICJzdGFuZGFyZCBtb2RlbCIgYW5kICJy YW5kbSBvcmFjbGUgbW9kZWwiCgpla3I6IGlzIHRoaXMgcHVibGlzaGVkIGFuYWx5c2lzPwoK ZGg6IHRyeWluZyB0byBnZXQgc29tZSBxdWFsaWZpZWQgYW5hbHlzdHMgdG8gbG9vayBhdCBp dAogYmVlbiB0b2xkIG5vIG9uZSdzIGdvaW5nIHRvIGFuYWx5emUgdGhpcyB1bnRpbCBwdWJs aXNoZWQgLS0gY2F0Y2ggMjIKIGJ1dCBpcyBpbiA4MDIuMTEsIHNvIHNvcnRhIHB1Ymxpc2hl ZAoKc3Q6IHllcywgY2F0Y2gyMgogbGV0cyByZWFjaCBvdXQgc29tZSBtb3JlCiAKZGg6IHRo aXMgaXMgbW9yZSBzZWN1cmUgdGhhbiBwc2sgY2lwaGVyc3VpdGVzLi4uLgoKZWtyOiB0aGVz ZSBwcm90cyBhcmUgaGFyZCB0byBkZXNpZ24KIC4uLi4uLiA8Y29uY2VybmVkIGFib3V0IHBy ZXNlbnQgc3RkIG9mIGNhcmU+CiAKIC4uLi4gdGhlcmUncyBsaWtlIDUwIG90aGVyIHNpbWls YXIgcHJvdHMsIHdoeSBjaG9vc2UgdGhpcyBvbmUgb3ZlciB0aGVtPwogCiAKeW9hdiBuaXI6 ICB0aGlzIGlzIHByZS1zaGFyZWQta2V5ID8gIGNhbid0IGJlIHNhbHRlZD8KCmRoOiBpdHMg c2FsdGVkLgoKeW46IG9rCgpqczogb2ssIHdoYXQncyBsZXZlbCBvZiBpbnRlcnN0IGluIHRo aXMgcGFydGljdWxhciBwcm90b2NvbD8KICBhIGZldyBwZW9wbGUKICAKanM6IGhvdyBtYW55 IGZvciAibm8iID8KICBla3IsIG1heWJlIHNvbWUgb3RoZXJzCiAgCmpzOiBkb24ndCBrbm93 PwogIGEgZmV3ICAKICAKc28gc29ydGEgaW5kZXRlcm1pbmFudAoKanM6IHNvIGEgc2VjdXJp dHkgcmV2aWV3IHdpbGwgcHJvYmFibHkgaGVscCB0aGlzIGVmZm9ydCBnbyBmb3J3YXJkLi4u LgoKZWtyOiBpZiB5b3UgY291bGQgZ2V0IENGUkcgdG8gd2VpZ2ggaW4gb24gdGhpcywgaXQn ZCBiZSBoZWxwZnVsCgpkaDogZGlkIGJyaW5nIHRoaXMgdXAgb24gY2ZyZyBhcyBwYXJ0IG9m IGVhcCBtZXRob2QKIHRoZXkgbG9va2VkIGFuZCBubyBvbiBlIGJhcmZlZAogY2FuIHNlZSBh Z2FpbiB3aGF0IHRoZXkgdGhpbmsKIAoKQURKT1VSTkVECgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCg== --------------000702050904050105000109-- From hannes.tschofenig@gmx.net Thu Nov 17 06:58:05 2011 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 ED7601F0C41 for ; Thu, 17 Nov 2011 06:58:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BlbWzJDE39Vr for ; Thu, 17 Nov 2011 06:58:05 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.23]) by ietfa.amsl.com (Postfix) with SMTP id 81A2C21F9626 for ; Thu, 17 Nov 2011 06:58:04 -0800 (PST) Received: (qmail invoked by alias); 17 Nov 2011 14:58:02 -0000 Received: from 203-69-99-17.HINET-IP.hinet.net (EHLO [172.20.3.142]) [203.69.99.17] by mail.gmx.net (mp021) with SMTP; 17 Nov 2011 15:58:02 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1+uBntVoRCuNvqesWrP3j5Wu+IAprDg4YMgrNUIvl y7DPZz8lNsGKEj From: Hannes Tschofenig Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 17 Nov 2011 22:57:58 +0800 Message-Id: To: tls@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) X-Y-GMX-Trusted: 0 Cc: core Subject: [TLS] draft-wouters-tls-oob-pubkey-02.txt - Raw Public Keys 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, 17 Nov 2011 14:58:06 -0000 Hi all,=20 based on the feedback from the TLS WG session at the IETF#82 an updated = draft version has been submitted:=20 http://www.ietf.org/internet-drafts/draft-wouters-tls-oob-pubkey-02.txt This version only focuses on the support for raw public keys and the = ability to exchange hashes of public keys has been removed.=20 Ciao Hannes From paul@xelerance.com Thu Nov 17 08:20:26 2011 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 E9C5711E8181; Thu, 17 Nov 2011 08:20:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.96 X-Spam-Level: X-Spam-Status: No, score=-5.96 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3, 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 RqxSayw1pRdw; Thu, 17 Nov 2011 08:20:26 -0800 (PST) Received: from mx.xelerance.com (mx.xelerance.com [193.110.157.188]) by ietfa.amsl.com (Postfix) with ESMTP id A660211E817B; Thu, 17 Nov 2011 08:20:25 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx.xelerance.com (Postfix) with ESMTP id 0C61251F; Thu, 17 Nov 2011 11:20:22 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xelerance.com; h= content-transfer-encoding:content-type:content-type:mime-version :user-agent:references:message-id:in-reply-to:subject:subject :from:from:date:date:received:received:received:received; s= smtp; t=1321546818; x=1322151618; bh=7wL9Ksf/8laorqFNRY4ETOtW62Q J7DxgYv3Fwk2/Xbg=; b=L3sInfzTEns5emQLjk1A+3JXHW1iIOh6eFQnxSoexvN koqn2PIhYydfoY5tS6GUxbGb9B7YcXI7KgTeNdthjRJ7azVrRKsb/CubQ3h2kOq1 NllKa7UO9EzB27HfGuyKr0fCDOeiPgQE0d1T4pOYx6kU/WKTNgElYjGQ603Z7Y0E = Received: from mx.xelerance.com ([127.0.0.1]) by localhost (mx.xelerance.com [127.0.0.1]) (amavisd-new, port 10026) with LMTP id oUj++oJkTCbz; Thu, 17 Nov 2011 11:20:18 -0500 (EST) Received: from mail.xelerance.com (mail.xelerance.com [193.110.157.189]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.xelerance.com (Postfix) with ESMTPS id A420D84; Thu, 17 Nov 2011 11:20:18 -0500 (EST) Received: by mail.xelerance.com (Postfix, from userid 1001) id 55A28445; Thu, 17 Nov 2011 11:20:18 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.xelerance.com (Postfix) with ESMTP id 4F2B01F2; Thu, 17 Nov 2011 11:20:18 -0500 (EST) Date: Thu, 17 Nov 2011 11:20:18 -0500 (EST) From: Paul Wouters To: =?ISO-8859-2?Q?Ond=F8ej_Sur=FD?= In-Reply-To: <8766068B-882E-41F9-B908-49088E451F03@nic.cz> Message-ID: References: <8766068B-882E-41F9-B908-49088E451F03@nic.cz> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Cc: tls@ietf.org, dane@ietf.org Subject: Re: [TLS] New Version Notification for draft-wouters-tls-oob-pubkey-01.txt (fwd) 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, 17 Nov 2011 16:20:27 -0000 On Thu, 17 Nov 2011, Ondřej Surý wrote: The -02 draft went out before I could respond to this.... > could you please drop this sentence from your draft? > > For example, if public keys were obtained using [DANE] it > is appropriate to use DNSSEC to authenticate the public keys. > > I know that it's just an example, but I can see that this could > lead to chaos and mayhem if the DANE protocol makes different > assertion in the future. So unless DANE protocol blooms into the > RFC before your draft, please don't make any assumptions, thanks. Though I see your point, I cannot really see any case where a TLS implementation would obtain a public key from DNS without any PKIX information and without any DNSSEC protection. In this case there is not even the PKIX fallback information to go on, so regardless of what DANE decides to do for "validatable PKIX", a TLS client MUST NOT use a TLSA record containing just a public key if it did not authenticate that data with DNSSEC. Perhaps it can be reworded? But I think it is a valid security concern to point out people should not just pluck spoofable TLSA records from DNS and build a TLS trust relationship based on that. Even if DANE decided to always mandata DNSSEC, I think it is a good reminder to make that explicit in the Security Considerations here? > And one minor nit, change > > Some small embedded devices use the UDP based [CoAP], a specialized > constrained networks and nodes for machine-to-machine applications. > > to > > Some small embedded devices use the UDP based Constrained Application > Protocol [CoAP], a specialized web transfer protocol for use with > constrained networks and nodes for machine-to-machine applications. > > or simpler > > Some small embedded devices use the UDP based Constrained Application > Protocol [CoAP] for use with constrained networks and nodes for > machine-to-machine applications. > > for better readability. Thanks. I've made the changes and the will be in the next draft. Paul > On 1. 11. 2011, at 7:21, Paul Wouters wrote: > >> >> This is the new version of the draft incorporating the feedback from Quebec City >> and the TLS list since then. It changes the draft from a new TLS extension to a >> new Certificate Type for raw keys. >> >> It also merges in the unpublished draft material from Hannes Tschofenig >> and Tero Kivinen whom had also been working on raw RSA >> TLS keys for use with CoAP (eg devices with no real time clock where >> PKIX validation cannot work) >> >> I did not yet change the draft ofrom individual submission to working group item, >> as I was waiting for confirmation on the TLW WG list of the last Quebec City >> meeting. >> >> http://tools.ietf.org/html/draft-wouters-tls-oob-pubkey-01 >> >> Paul >> >> ---------- Forwarded message ---------- >> Date: Mon, 31 Oct 2011 17:44:35 >> From: internet-drafts@ietf.org >> Cc: weiler@tislabs.com, hannes.tschofenig@gmx.net, gnu@toad.com, >> paul@xelerance.com, kivinen@iki.fi >> To: paul@xelerance.com >> Subject: New Version Notification for draft-wouters-tls-oob-pubkey-01.txt >> X-Spam-Flag: NO >> >> A new version of I-D, draft-wouters-tls-oob-pubkey-01.txt has been successfully submitted by Paul Wouters and posted to the IETF repository. >> >> Filename: draft-wouters-tls-oob-pubkey >> Revision: 01 >> Title: TLS out-of-band public key validation >> Creation date: 2011-10-31 >> WG ID: Individual Submission >> Number of pages: 11 >> >> Abstract: >> This document specifies a new TLS certificate type for exchanging raw >> public keys or their fingerprints in Transport Layer Security (TLS) >> and Datagram Transport Layer Security (DTLS) for use with out-of-band >> authentication. Currently, TLS authentication can only occur via >> PKIX or OpenPGP certificates. By specifying a minimum resource for >> raw public key exchange, implementations can use alternative >> authentication methods. >> >> One such method is using DANE Resource Records secured by DNSSEC, >> Another use case is to provide authentication functionality when used >> with devices in a constrained environment that use whitelists and >> blacklists, as is the case with sensors and other embedded devices >> that are constrained by memory, computational, and communication >> limitations where the usage of PKIX is not feasible. >> >> The new certificate type specified can also be used to reduce the >> latency of a TLS client that is already in possession of a validated >> public key of the TLS server before it starts a (non-resumed) TLS >> handshake. >> >> >> >> >> The IETF Secretariat >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > > -- > Ondřej Surý > vedoucí výzkumu/Head of R&D department > ------------------------------------------- > CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC > Americka 23, 120 00 Praha 2, Czech Republic > mailto:ondrej.sury@nic.cz http://nic.cz/ > tel:+420.222745110 fax:+420.222745112 > ------------------------------------------- > From paul@xelerance.com Thu Nov 17 08:37:47 2011 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 47A3511E8184 for ; Thu, 17 Nov 2011 08:37:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.399 X-Spam-Level: X-Spam-Status: No, score=-6.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 IdLwvnI7VXtU for ; Thu, 17 Nov 2011 08:37:46 -0800 (PST) Received: from mx.xelerance.com (mx.xelerance.com [193.110.157.188]) by ietfa.amsl.com (Postfix) with ESMTP id 6E97F11E8127 for ; Thu, 17 Nov 2011 08:37:46 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx.xelerance.com (Postfix) with ESMTP id E158251F; Thu, 17 Nov 2011 11:37:44 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xelerance.com; h= content-type:content-type:mime-version:user-agent:references :message-id:in-reply-to:subject:subject:from:from:date:date :received:received:received:received; s=smtp; t=1321547863; x= 1322152663; bh=puxiGrqfTbvaWpT/ls1NBXnu+QDKsclTmx9TTvSTKeE=; b=O uVLL4u02zjE2ull0wb0BDmVVnrfFW9yVTyeZNK2jqvFsWIaJT6YdMyZob6INcZ9x rL3JsbcUXskbLbwImDvMYiHbPiaeTb6IDEmtRdOyrtGTjXQKxRo2+uui760g6vUb ufBPiNVSyKxarEkoMmN5SEcwhQawC21HqDM1BGO0aE= Received: from mx.xelerance.com ([127.0.0.1]) by localhost (mx.xelerance.com [127.0.0.1]) (amavisd-new, port 10026) with LMTP id FzNrMCn1Mhfo; Thu, 17 Nov 2011 11:37:43 -0500 (EST) Received: from mail.xelerance.com (mail.xelerance.com [193.110.157.189]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.xelerance.com (Postfix) with ESMTPS id E7D7484; Thu, 17 Nov 2011 11:37:41 -0500 (EST) Received: by mail.xelerance.com (Postfix, from userid 1001) id A666A3ED; Thu, 17 Nov 2011 11:37:41 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.xelerance.com (Postfix) with ESMTP id A53C53D1; Thu, 17 Nov 2011 11:37:41 -0500 (EST) Date: Thu, 17 Nov 2011 11:37:41 -0500 (EST) From: Paul Wouters To: =JeffH In-Reply-To: <4EC4F080.7080100@KingsMountain.com> Message-ID: References: <4EC4F080.7080100@KingsMountain.com> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: IETF TLS WG Subject: [TLS] oob-pubkey and cached-info 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, 17 Nov 2011 16:37:47 -0000 On Thu, 17 Nov 2011, =JeffH wrote: > Subject: [TLS] raw unofficial minutes: TLS WG: IETF-82 Taipei Thanks Jeff! > -------------------------------------------------- > Hannes T. : tls out-of-band public key validation > -------------------------------------------------- > > draft-wouters-tls-oob-pubkey-01 > > Tero and Hannes are on the author team now since ietf-81 quebec > > "RawPublicKey" -- new cert type in client_hello > > leverages the TLS Cert types registry that RFC 6091 defined > > convey pub key in subjectPublicKeyInfo structure from X.509 cert structures (see also rfc5280) > > don't need to define new ciphersuites -- but need to use approp ciphersuite with type of pubkey that's being exchanged > > dan harkins (dh): why not just send the raw pub key rather than sending a hash of it? > > tero: send hash to keep bytes on wire smaller > > js: it might be an idea to ressurect the ? work -- that might address the hash thing That was refering to: http://tools.ietf.org/html/draft-ietf-tls-cached-info A new extension type (cached_information(TBD)) is defined and used in both the client hello and server hello messages. The extension type is specified as follows. enum { cached_information(TBD), (65535) } ExtensionType; The extension_data field of this extension, when included in the client hello, SHALL contain CachedInformation according to the following structure: enum { certificate_chain(1), trusted_cas(2), (255) } CachedInformationType; Note that the cached-info draft has text that it can only use the hashes computed from previous TLS sessions, and does currently not allow calculatng the cached information based on information from other sources, such as DANE/DNSSEC. I think there might be an interest on these small devices to also avoid sending this information unhashed on their first connection. Perhaps the cached-info draft could allow that? (apologies if I missed previous discussion on this topic) Note also that if within DANE a sha256 hash is used, it might be more convenient for the client to use the same hashing algorithm here to allow for easier strncmp(). However, that does reduce the strength of the public key to the strength of the hashing algorithm, since in that case, no full copy of the public key is going over the wire either in DANE or TLS. Paul From ondrej.sury@nic.cz Thu Nov 17 09:07:11 2011 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 1F93B21F9A06; Thu, 17 Nov 2011 09:07:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] 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 RotQlMHMpD83; Thu, 17 Nov 2011 09:06:59 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id D540721F9A01; Thu, 17 Nov 2011 09:06:58 -0800 (PST) Received: from [192.168.100.100] (61-220-70-183.HINET-IP.hinet.net [61.220.70.183]) by mail.nic.cz (Postfix) with ESMTPSA id BF2442A2B86; Thu, 17 Nov 2011 18:06:55 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1321549617; bh=F9MqqeIRy7vogaW/a9XrXqD5vuigSSEAVvnJAYptl3o=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=pBYYJIlt4LGR7sE+HJjO8/hD96e+jaCh7MN4tBL1WLciIG4d3PWwUrIc4NO6RuU0I I7vxZZoi+gPaNi0I3GvOX6Luc9gODk9hk0rBwSX4NsmxTNy4d8oSK4CyFPRaG8eyLb Fuwkz70FOHg6zCYDo0Xlk+ofSv6dCzdqgo85GSCo= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: Date: Fri, 18 Nov 2011 01:06:52 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8766068B-882E-41F9-B908-49088E451F03@nic.cz> To: Paul Wouters X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: tls@ietf.org, dane@ietf.org Subject: Re: [TLS] New Version Notification for draft-wouters-tls-oob-pubkey-01.txt (fwd) 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, 17 Nov 2011 17:07:11 -0000 On 18. 11. 2011, at 0:20, Paul Wouters wrote: > On Thu, 17 Nov 2011, Ond=C5=99ej Sur=C3=BD wrote: >=20 > The -02 draft went out before I could respond to this.... >=20 >> could you please drop this sentence from your draft? >>=20 >> For example, if public keys were obtained using [DANE] it >> is appropriate to use DNSSEC to authenticate the public keys. >>=20 >> I know that it's just an example, but I can see that this could >> lead to chaos and mayhem if the DANE protocol makes different >> assertion in the future. So unless DANE protocol blooms into the >> RFC before your draft, please don't make any assumptions, thanks. >=20 > Though I see your point, I cannot really see any case where a TLS > implementation would obtain a public key from DNS without any PKIX > information and without any DNSSEC protection. In this case there is > not even the PKIX fallback information to go on, so regardless of what > DANE decides to do for "validatable PKIX", a TLS client MUST NOT use > a TLSA record containing just a public key if it did not authenticate > that data with DNSSEC. I think it's perfectly fine to say, what you are saying in the first part of the paragraph: Depending on exactly how the public keys were obtained, it may be appropriate to use authentication mechanisms tied to the public key transport. but I object to saying what that means in the other (DANE) protocols. Or speak about the protocols which have the security properties already defined (LDAPS?). > Perhaps it can be reworded? But I think it is a valid security concern > to point out people should not just pluck spoofable TLSA records from > DNS and build a TLS trust relationship based on that. I agree with you, but this is not the place to say that. > Even if DANE > decided to always mandata DNSSEC, I think it is a good reminder to > make that explicit in the Security Considerations here? You can reword it to make it more general - less DANE-centric. >> And one minor nit, change >>=20 >> Some small embedded devices use the UDP based [CoAP], a specialized >> constrained networks and nodes for machine-to-machine applications. >>=20 >> to >>=20 >> Some small embedded devices use the UDP based Constrained = Application >> Protocol [CoAP], a specialized web transfer protocol for use with >> constrained networks and nodes for machine-to-machine applications. >>=20 >> or simpler >>=20 >> Some small embedded devices use the UDP based Constrained = Application >> Protocol [CoAP] for use with constrained networks and nodes for >> machine-to-machine applications. >>=20 >> for better readability. >=20 > Thanks. I've made the changes and the will be in the next draft. >=20 > Paul >=20 >> On 1. 11. 2011, at 7:21, Paul Wouters wrote: >>=20 >>>=20 >>> This is the new version of the draft incorporating the feedback from = Quebec City >>> and the TLS list since then. It changes the draft from a new TLS = extension to a >>> new Certificate Type for raw keys. >>>=20 >>> It also merges in the unpublished draft material from Hannes = Tschofenig >>> and Tero Kivinen whom had also been working on raw = RSA >>> TLS keys for use with CoAP (eg devices with no real time clock where >>> PKIX validation cannot work) >>>=20 >>> I did not yet change the draft ofrom individual submission to = working group item, >>> as I was waiting for confirmation on the TLW WG list of the last = Quebec City >>> meeting. >>>=20 >>> http://tools.ietf.org/html/draft-wouters-tls-oob-pubkey-01 >>>=20 >>> Paul >>>=20 >>> ---------- Forwarded message ---------- >>> Date: Mon, 31 Oct 2011 17:44:35 >>> From: internet-drafts@ietf.org >>> Cc: weiler@tislabs.com, hannes.tschofenig@gmx.net, gnu@toad.com, >>> paul@xelerance.com, kivinen@iki.fi >>> To: paul@xelerance.com >>> Subject: New Version Notification for = draft-wouters-tls-oob-pubkey-01.txt >>> X-Spam-Flag: NO >>>=20 >>> A new version of I-D, draft-wouters-tls-oob-pubkey-01.txt has been = successfully submitted by Paul Wouters and posted to the IETF = repository. >>>=20 >>> Filename: draft-wouters-tls-oob-pubkey >>> Revision: 01 >>> Title: TLS out-of-band public key validation >>> Creation date: 2011-10-31 >>> WG ID: Individual Submission >>> Number of pages: 11 >>>=20 >>> Abstract: >>> This document specifies a new TLS certificate type for exchanging = raw >>> public keys or their fingerprints in Transport Layer Security (TLS) >>> and Datagram Transport Layer Security (DTLS) for use with = out-of-band >>> authentication. Currently, TLS authentication can only occur via >>> PKIX or OpenPGP certificates. By specifying a minimum resource for >>> raw public key exchange, implementations can use alternative >>> authentication methods. >>>=20 >>> One such method is using DANE Resource Records secured by DNSSEC, >>> Another use case is to provide authentication functionality when = used >>> with devices in a constrained environment that use whitelists and >>> blacklists, as is the case with sensors and other embedded devices >>> that are constrained by memory, computational, and communication >>> limitations where the usage of PKIX is not feasible. >>>=20 >>> The new certificate type specified can also be used to reduce the >>> latency of a TLS client that is already in possession of a = validated >>> public key of the TLS server before it starts a (non-resumed) TLS >>> handshake. >>>=20 >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>=20 >> -- >> Ond=C5=99ej Sur=C3=BD >> vedouc=C3=AD v=C3=BDzkumu/Head of R&D department >> ------------------------------------------- >> CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC >> Americka 23, 120 00 Praha 2, Czech Republic >> mailto:ondrej.sury@nic.cz http://nic.cz/ >> tel:+420.222745110 fax:+420.222745112 >> ------------------------------------------- >>=20 -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From marsh@extendedsubset.com Thu Nov 17 09:24:16 2011 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 0402A21F9A55 for ; Thu, 17 Nov 2011 09:24:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DuRJ-T7AOLMd for ; Thu, 17 Nov 2011 09:24:15 -0800 (PST) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by ietfa.amsl.com (Postfix) with ESMTP id 1F37621F97C6 for ; Thu, 17 Nov 2011 09:24:15 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1RR5h8-000I2d-Jl; Thu, 17 Nov 2011 17:24:14 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id C230D63C2; Thu, 17 Nov 2011 17:24:12 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18ZFOG7GxqZsI5FkP/7eQ0/hHM6NRZhyQg= Message-ID: <4EC5433C.6070202@extendedsubset.com> Date: Thu, 17 Nov 2011 11:24:12 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Paul Wouters References: <8766068B-882E-41F9-B908-49088E451F03@nic.cz> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] New Version Notification for draft-wouters-tls-oob-pubkey-01.txt (fwd) 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, 17 Nov 2011 17:24:16 -0000 Question. This item: > o A TLS client has connected to the TLS server before and has cached > the TLS server certificate chain or TLS server public key for re-use Is that behavior endorsed by current RFCs, or is server cert caching a new optimization being enabled by this draft (perhaps in conjunction with HSTS pinning)? Seems like that topic could merit a whole nother RFC of its own. Maybe reference that or drop it from here? Clearly this document "specifies a new TLS certificate type for exchanging raw public keys or their fingerprints in TLS and DTLS". But I guess the deeper question is to what extent this draft intends to endorse ad-hoc approaches to TLS authentication when it says "By specifying a minimum resource for raw public key exchange, implementations can use alternative authentication methods." In the Security Considerations there is the statement "A client using this cert_type needs to be confident in the authenticity of the public key it is using." This is obviously correct, but is it worded strongly enough? For example, it's no secret that a great many non-browser TLS client applications do not bother with cert validation or they fail to check that the cert matches the host they requested. Often they allow plain IP addresses in their configuration. Today we can say this is against various RFCs, but if this draft were accepted perhaps such clients would be able to simply request cert type RawPublicKey and say "yep, looks good enough for me therefore I am RFC-compliant!" This is an ongoing discussion that I encounter among users and app developers on a regular basis. For example: > http://www.derkeiler.com/Mailing-Lists/Full-Disclosure/2011-02/msg00650.html On 11/17/2011 10:20 AM, Paul Wouters wrote: > > Though I see your point, I cannot really see any case where a TLS > implementation would obtain a public key from DNS without any PKIX > information and without any DNSSEC protection. In this case there is > not even the PKIX fallback information to go on, so regardless of > what DANE decides to do for "validatable PKIX", a TLS client MUST > NOT use a TLSA record containing just a public key if it did not > authenticate that data with DNSSEC. > > Perhaps it can be reworded? Perhaps you could use a different example such as: * Certs obtained via LDAP (e.g. http://tools.ietf.org/html/rfc4523 ) * IPsec using X.509 certs http://tools.ietf.org/html/rfc4301 * Established SSH RSA keys (if this is actually well-defined) Just some ideas. > But I think it is a valid security concern to point out people > should not just pluck spoofable TLSA records from DNS and build a TLS > trust relationship based on that. Even if DANE decided to always > mandata DNSSEC, I think it is a good reminder to make that explicit > in the Security Considerations here? I agree that it's worth repeating on principle, but I don't think it's necessary to include more of an explanation of the full PKI security model. Just a reference should do. - Marsh From anders.rundgren@telia.com Thu Nov 17 12:15:08 2011 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 3BA6111E80AB for ; Thu, 17 Nov 2011 12:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.499 X-Spam-Level: X-Spam-Status: No, score=-3.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 qiaNRc3QQ+nk for ; Thu, 17 Nov 2011 12:15:07 -0800 (PST) Received: from smtp-out11.han.skanova.net (smtp-out11.han.skanova.net [195.67.226.200]) by ietfa.amsl.com (Postfix) with ESMTP id 4B19E11E8081 for ; Thu, 17 Nov 2011 12:15:07 -0800 (PST) Received: from [192.168.0.204] (81.232.44.37) by smtp-out11.han.skanova.net (8.5.133) (authenticated as u36408181) id 4EC0B688001E147E; Thu, 17 Nov 2011 21:15:04 +0100 Message-ID: <4EC56B3E.3040205@telia.com> Date: Thu, 17 Nov 2011 21:14:54 +0100 From: Anders Rundgren User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: Joe Salowey References: In-Reply-To: X-Enigmail-Version: 1.3.3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Process for TLS Extensions 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, 17 Nov 2011 20:15:08 -0000 On 2011-11-16 10:28, Joe Salowey wrote: > Below is a statement on the process for TLS extensions that we worked > on with Sean Turner with helpful input from Paul Hoffman. > We will have some discussion on this in the Taipei meeting and on the TLS list. It is sort of a cute proposal but it is fairly useless. Google have already implemented their OBC extension so this process will only stop people who already have problems getting through with their stuff. IMO, Google did the right thing. Standards must be tested before they are indeed made "standard" otherwise we only get bad stuff like S/MIME. Anders > > > > RFC 5246 defines an extensibility mechanism for TLS based on > extensions signaled in the ClientHello and ServerHello. With TLS 1.2 > and DTLS 1.2 being relatively stable, we are starting to see more > proposed extensions, some of which, if used, represent significant > changes to the TLS processing model or state machine. RFC 5246 > requires IETF consensus for any extension, either through individual > submission to an Area Director or to the TLS Working Group (for as > long as the WG exists). > > Any proposed extension can be brought to the Security Area Director > as an individual submission for IETF consensus; it can also be brought > directly to the TLS WG. In the former case, the Area > Director will decide whether he/she believes the extension needs to be > processed through the TLS WG or just to process it through IETF Last > Call. This decision will be made based on the level of impact the > extension would have on TLS. Specifically, any extension which would > cause a significant change to the TLS processing model or state > machine will be referred to the TLS WG. The Security Area Director > may also ask the WG chairs and other active TLS participants ahead of > time about whether or not a particular proposal should be processed > (if at all) in the TLS WG. The AD may decide not to allow an extension > to progress based on feedback from the working group and other > sources. > > In the case of drafts going through IETF Last Call, the TLS WG mailing > list will be informed of the IETF Last Call ahead of or concurrently > with the Last Call. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From ynir@checkpoint.com Thu Nov 17 15:12:58 2011 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 441011F0C36 for ; Thu, 17 Nov 2011 15:12:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.425 X-Spam-Level: X-Spam-Status: No, score=-10.425 tagged_above=-999 required=5 tests=[AWL=0.174, 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 GUnzICKc2PJh for ; Thu, 17 Nov 2011 15:12:57 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 555AF21F9543 for ; Thu, 17 Nov 2011 15:12:57 -0800 (PST) X-CheckPoint: {4EC59497-0-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pAHNCqjK007001; Fri, 18 Nov 2011 01:12:52 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Fri, 18 Nov 2011 01:12:52 +0200 From: Yoav Nir To: Anders Rundgren Date: Fri, 18 Nov 2011 01:12:50 +0200 Thread-Topic: [TLS] Process for TLS Extensions Thread-Index: Acylfm4LtM6CIRrqQ3eRsIX+emHPSw== Message-ID: <94CFA2FF-88AE-4D33-8406-B358899F75C5@checkpoint.com> References: <4EC56B3E.3040205@telia.com> In-Reply-To: <4EC56B3E.3040205@telia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] Process for TLS Extensions 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, 17 Nov 2011 23:12:58 -0000 On Nov 18, 2011, at 4:14 AM, Anders Rundgren wrote: > On 2011-11-16 10:28, Joe Salowey wrote: >> Below is a statement on the process for TLS extensions that we worked=20 >> on with Sean Turner with helpful input from Paul Hoffman. >> We will have some discussion on this in the Taipei meeting and on the TL= S list. >=20 > It is sort of a cute proposal but it is fairly useless. >=20 > Google have already implemented their OBC extension so this > process will only stop people who already have problems getting > through with their stuff. >=20 > IMO, Google did the right thing. Standards must be tested > before they are indeed made "standard" otherwise we only get > bad stuff like S/MIME. The flip side of this is that when those things are brought to an IETF work= ing group, there is tremendous pressure not to break compatibility with imp= lementations already deployed in the field. All that remains for the IETF t= o do is to dot the i's, cross the t's and bless the standard with an RFC nu= mber.= From wtc@google.com Thu Nov 17 16:00:03 2011 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 A3A811F0C5D for ; Thu, 17 Nov 2011 16:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rfF5MywjHpmG for ; Thu, 17 Nov 2011 16:00:03 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by ietfa.amsl.com (Postfix) with ESMTP id 1A09921F9247 for ; Thu, 17 Nov 2011 16:00:02 -0800 (PST) Received: by ywt34 with SMTP id 34so2159074ywt.31 for ; Thu, 17 Nov 2011 16:00:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=x188RaspwC2sO1MJrAYTFk7mAtYynjAjXCuKTQFALOw=; b=ya0OjCgzzT0GbQkIN9r/uzZlsGGIWeIiLb6Idqa536jfl2yOQYloSBQ8DYvo93SVrZ +Y/B/S/z92bREiilbGDQ== Received: by 10.50.216.134 with SMTP id oq6mr922119igc.11.1321574402442; Thu, 17 Nov 2011 16:00:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.216.134 with SMTP id oq6mr922112igc.11.1321574402332; Thu, 17 Nov 2011 16:00:02 -0800 (PST) Received: by 10.231.39.198 with HTTP; Thu, 17 Nov 2011 16:00:02 -0800 (PST) In-Reply-To: <94CFA2FF-88AE-4D33-8406-B358899F75C5@checkpoint.com> References: <4EC56B3E.3040205@telia.com> <94CFA2FF-88AE-4D33-8406-B358899F75C5@checkpoint.com> Date: Thu, 17 Nov 2011 16:00:02 -0800 Message-ID: From: Wan-Teh Chang To: Yoav Nir Content-Type: text/plain; charset=ISO-8859-1 X-System-Of-Record: true Cc: "tls@ietf.org" Subject: Re: [TLS] Process for TLS Extensions 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, 18 Nov 2011 00:00:03 -0000 On Thu, Nov 17, 2011 at 3:12 PM, Yoav Nir wrote: > > The flip side of this is that when those things are brought to an IETF working group, > there is tremendous pressure not to break compatibility with implementations already > deployed in the field. All that remains for the IETF to do is to dot the i's, cross the t's > and bless the standard with an RFC number. This is not always true. A counterexample is TLS itself. TLS 1.0 is more than dotting the i's, crossing the t's, and blessing SSL 3.0 with an RFC number. Wan-Teh From ynir@checkpoint.com Thu Nov 17 21:18:06 2011 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 75D5621F91CE for ; Thu, 17 Nov 2011 21:18:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.405 X-Spam-Level: X-Spam-Status: No, score=-10.405 tagged_above=-999 required=5 tests=[AWL=0.194, 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 AyxcrY9abcOt for ; Thu, 17 Nov 2011 21:18:00 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 835A921F916D for ; Thu, 17 Nov 2011 21:17:59 -0800 (PST) X-CheckPoint: {4EC5EA24-0-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pAI5HwCR023002 for ; Fri, 18 Nov 2011 07:17:58 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 18 Nov 2011 07:17:58 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Fri, 18 Nov 2011 07:17:58 +0200 From: Yoav Nir To: "tls@ietf.org List" Date: Fri, 18 Nov 2011 07:17:56 +0200 Thread-Topic: NextProtoNeg concerns Thread-Index: AcylsW8hZhsVyNjQRMSnysc4pAM9ng== Message-ID: <4F26370A-E4DA-4EDF-8D33-D77F2D9C89FB@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Subject: [TLS] NextProtoNeg concerns 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, 18 Nov 2011 05:18:06 -0000 Hi I'm all for the working group accepting this item. I agree with EKR that tr= affic analysis will probably be able to distinguish all protocols, so I don= 't think it matters very much one way or the other whether the NextProtocol= handshake is encrypted or not. I don't even thing that the NextProto hands= hake message is even necessary, as both sides have agreed on the capability= , and can send the selected_protocol as the first few bytes of the applicat= ion data, but again, I don't think this makes much of a difference one way = or another. What I really don't like about this proposal, is this text in section 3: The "extension_data" field in a "ServerHello" and the "NextProtocol" message contain opaque bytes to be used by the application layer to negotiate the application layer protocol. The format of this data is not specified in this draft. If you are defining a new extension/handshake message to carry a new kind o= f data (application type) there is no value to this without a definition of= the format, either in the same document or in a companion document. The examples in the slides show a very specific format: "\x06spdy/2\x08http= /1.1\x08http/1.0". I don't see why this would not be specified in the docum= ent. Of course, you would need to set up a registry for these strings. For = example, I can see how Microsoft would want to register SSTP, and other ven= dors would register their own SSL-VPN protocols as well. With that section added, I support adoption of this document. Yoav From marsh@extendedsubset.com Thu Nov 17 21:36:52 2011 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 4EBDB11E80E4 for ; Thu, 17 Nov 2011 21:36:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 46oL22WlkwTw for ; Thu, 17 Nov 2011 21:36:44 -0800 (PST) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) by ietfa.amsl.com (Postfix) with ESMTP id A85DF11E80DE for ; Thu, 17 Nov 2011 21:36:25 -0800 (PST) Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.72) (envelope-from ) id 1RRH7S-0003oB-CC; Fri, 18 Nov 2011 05:36:10 +0000 Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 0481763C3; Fri, 18 Nov 2011 05:36:08 +0000 (UTC) X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 69.164.193.58 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1/JJowMEGzGy2/8U1kCepkSIGKliSl05z0= Message-ID: <4EC5EEC8.3000903@extendedsubset.com> Date: Thu, 17 Nov 2011 23:36:08 -0600 From: Marsh Ray User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15 MIME-Version: 1.0 To: Yoav Nir References: <4F26370A-E4DA-4EDF-8D33-D77F2D9C89FB@checkpoint.com> In-Reply-To: <4F26370A-E4DA-4EDF-8D33-D77F2D9C89FB@checkpoint.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "tls@ietf.org List" Subject: Re: [TLS] NextProtoNeg concerns 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, 18 Nov 2011 05:36:53 -0000 On 11/17/2011 11:17 PM, Yoav Nir wrote: > > What I really don't like about this proposal, is this text in section > 3: The "extension_data" field in a "ServerHello" and the > "NextProtocol" message contain opaque bytes to be used by the > application layer to negotiate the application layer protocol. The > format of this data is not specified in this draft. > > If you are defining a new extension/handshake message to carry a new > kind of data (application type) there is no value to this without a > definition of the format, either in the same document or in a > companion document. > > The examples in the slides show a very specific format: > "\x06spdy/2\x08http/1.1\x08http/1.0". I don't see why this would not > be specified in the document. Of course, you would need to set up a > registry for these strings. For example, I can see how Microsoft > would want to register SSTP, and other vendors would register their > own SSL-VPN protocols as well. What if you're a small application developer, perhaps with a single application or running only a few servers. Should you be expected to register your format before using it? Would it be expected to follow the same length-value format as the example? Would anyone ever be denied registration? What if their format definition was technically deficient, or they wanted to reserve a bunch of unrelated protocol names? - Marsh From zhou.sujing@zte.com.cn Fri Nov 18 00:59:48 2011 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 405D121F84A1 for ; Fri, 18 Nov 2011 00:59:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.917 X-Spam-Level: X-Spam-Status: No, score=-99.917 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, 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 QbhnbLkKjxpg for ; Fri, 18 Nov 2011 00:59:45 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 2744F21F84A0 for ; Fri, 18 Nov 2011 00:59:44 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 566901626001193; Fri, 18 Nov 2011 16:47:21 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 76252.1626001193; Fri, 18 Nov 2011 16:59:18 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id pAI8xMTP069835 for ; Fri, 18 Nov 2011 16:59:22 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) To: tls@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Fri, 18 Nov 2011 16:59:07 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-11-18 16:59:25, Serialize complete at 2011-11-18 16:59:25 Content-Type: multipart/alternative; boundary="=_alternative 003162E54825794C_=" X-MAIL: mse02.zte.com.cn pAI8xMTP069835 Subject: [TLS] about the PWD Proposal 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, 18 Nov 2011 08:59:48 -0000 This is a multipart message in MIME format. --=_alternative 003162E54825794C_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQogSSBhbSBpbnRlcmVzdGVkIGluIHRoZSBQV0QgcHJvcG9zYWwgYXQgdGhlIG1lZXRpbmcs IGFuZCBydW4gdGhyb3VnaCANCml0KGh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWhh cmtpbnMtdGxzLXB3ZC0wMSNzZWN0aW9uLTMuNCksDQogYW5kIGhhdmUgdGhlIGZvbGxvd2luZyBj b25jZXJuczoNCg0KMS4gSW4gdGhlIGRvY3VtZW50LCBpdCAgc2F5cyBib3RoIENsaWVudCBhbmQg U2VydmVyIHNob3VsZCBiZSBhYmxlIHRvIA0KY29tcHV0ZSBQRSwgd2hpY2ggaXMgZGVyaXZlZCBm cm9tIHVzZXJuYW1lLCBwYXNzd29yZCwgc2FsdCxldGMuDQogICBUaGF0IG1lYW5zIENsaWVudCBv ciB0aGUgdXNlciBzaG91bGQgYWxzbyByZW1lbWJlciB0aGUgc2FsdCB2YWx1ZSwgaW4gDQp0aGF0 IGNhc2UsIHNhbHQgaXMgbWVhbmluZ2xlc3MgYW5kIGNhbiBiZSByZXBsYWNlZCBieSBhIGxvbmdl ciBwYXNzd29yZC4NCiAgIFRoaXMgaXMgcXVpdGUgZGlmZmVyZW50IGZyb20gdGhlIHdpZGVseSBr bm93biB1c2FnZSBvZiBzYWx0LCBlLmcuIGluIA0KVU5JWCBvcGVyYXRpbmcgc3lzdGVtLCBzYWx0 IGlzIG5vdCByZXF1aXJlZCB0byByZW1lbWJlciBieSB0aGUgdXNlciwgYnV0IA0KYnkgc2VydmVy IHRvIGZldGNoIGxvY2FsbHkgYnkgcmVmZXJlbmNlIHRvIHRoZSB1c2VybmFtZS4gDQogIEFuZCBh cyBmYXIgYXMgSSBrbm93LCBJIGFtIHN1cmUgdGhlIGF1dGhvcnMgYWxzbyBrbm93IHRoYXQsIG90 aGVyIA0KcGFzc3dvcmQgYmFzZWQga2V5IGV4Y2hhbmdlcyBwcm90b2NvbHMgZG9uJ3QgaW52b2x2 ZSBzYWx0LCBidXQgc3RvcmUgYSANCmhhc2ggdmFsdWUgb2YgcGFzc3dvcmQgYW1vbmcgb3RoZXIg dGhpbmdzIGxvY2FsbHkuDQoyLiBGcm9tIHRoZSBmaWd1cmUgaW4gdGhlIFBQVCBzaG93biBhdCB0 aGUgbWVldGluZywgSSBjYW5uJ3Qgc2VlIHdoeSB0aGUgDQpwcm90b2NvbCBzaG91bGQgdXNlIGJv dGggInByaXZhdGUiIGFuZCAibWFzayIgdmFsdWVzLCBpbiBteSBvcGluaW9uLCBvbmx5IA0KIm1h c2sgIiB2YWx1ZSBzaGFsbCBiZSBPSy4NCiAgIHByaXZhdGUgdmFsdWUgaXMgcmVkdW5kZW50LCBh bmQgbm90IGhlbHBmdWwgaW4gc2VjdXJpdHkgaW1wcm92ZW1lbnQuDQogICBiZWNhdXNlIHRoZSBj dXJyZW50IGRlcml2ZWQgc2hhcmVkIGtleSBpcyBQRV57cHJpdmF0ZV9hKnByaXZhdGVfYn0gDQph Y2NvcmRpbmcgdG8gdGhpcyBkb2N1bWVudKOsIGFuZA0KICAgYWZ0ZXIgcmVtb3ZpbmcgcHJpdmF0 ZSB2YWx1ZSwgaXQgd2lsbCBiZSAgUEVee21hc2tfYSptYXNrX2J9DQogICBhbmQgcHJpdmF0ZSwg bWFzayB2YWx1ZSBhcmUgYm90aCBnZW5lcmF0ZWQgbG9jYWxseSBhbmQgbm90IHRyYW5zcG9ydGVk IA0Kb24gdGhlIHdpcmUsIHNvIGl0IGRvZXMgbm90IG1ha2UgbXVjaCBkaWZmZXJlbmNlIGV4Y2Vw dCBtYWtpbmcgaXQgbW9yZSANCmNvbXBsZXguDQozLiBOb3cgSSBvbmx5IHRhbGsgYWJvdXQgdGhl IHNlY3VyaXR5IG9mIHRoZSBzaW1wbGlmaWVkIHZlcnNpb24gKGFzIGluIA0KYWJvdmUgcG9pbnQg MikNCiAgIGFmdGVyIHNpbXBsaWZpY2F0aW9uIHRoZSBwcm90b2NvbCBpcyBlYXNpZXIgdG8gYW5h bHlzaXplLCBpdCBpcyBqdXN0IA0KbGlrZSBhbiBvcmRpbmFyeSBESCBleGNoYW5nZSBleGNlcHQg dGhhdCB0aGUgYmFzZSBncm91cCBnZW5lcmF0b3IgaXMgUEUgDQppbnN0ZWFkIG9mIGcuDQogICBT byB0aGUgc2VjdXJpdHkgaXMgcmVkdWNlZCB0byB0aGUgUEUsIGlzIGl0IGEgZ29vZCBncm91cCBn ZW5lcmF0b3IgDQp3aGljaCBoYXMgbGFyZ2Ugb3JkZXI/IGlmIG5vdCB0aGVuIGl0IGlzIGluc2Vj dXJlLg0KICAgVW5mb3J0dW5hdGx5IHRoZSBhdXRob3JzIGZhaWxlZCB0byBhbmFseXNpemUgdGhp cyBjcnVjaWFsIHBvaW50Lg0KDQpUaGFuayB5b3UgZm9yIHlvdXIgcGF0aWVuY2UhDQoNClN1amlu ZyBaaG91IA0KIA0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5m b3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhl IHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlk ZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4g c2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9m IHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMg dHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkg Zm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUg YWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFz ZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNz ZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpU aGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUg QW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 003162E54825794C_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7SSBhbSBpbnRlcmVzdGVkIGluIHRoZSBQ V0QgcHJvcG9zYWwNCmF0IHRoZSBtZWV0aW5nLCBhbmQgcnVuIHRocm91Z2ggaXQoaHR0cDovL3Rv b2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaGFya2lucy10bHMtcHdkLTAxI3NlY3Rpb24tMy40KSw8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwO2FuZCBoYXZl IHRoZSBmb2xsb3dpbmcgY29uY2VybnM6PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj4xLiBJbiB0aGUgZG9jdW1lbnQsIGl0ICZuYnNwO3NheXMgYm90aA0K Q2xpZW50IGFuZCBTZXJ2ZXIgc2hvdWxkIGJlIGFibGUgdG8gY29tcHV0ZSBQRSwgd2hpY2ggaXMg ZGVyaXZlZCBmcm9tIHVzZXJuYW1lLA0KcGFzc3dvcmQsIHNhbHQsZXRjLjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO1RoYXQgbWVhbnMgQ2xp ZW50IG9yIHRoZQ0KdXNlciBzaG91bGQgYWxzbyByZW1lbWJlciB0aGUgc2FsdCB2YWx1ZSwgaW4g dGhhdCBjYXNlLCBzYWx0IGlzIG1lYW5pbmdsZXNzDQphbmQgY2FuIGJlIHJlcGxhY2VkIGJ5IGEg bG9uZ2VyIHBhc3N3b3JkLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+Jm5ic3A7ICZuYnNwO1RoaXMgaXMgcXVpdGUgZGlmZmVyZW50DQpmcm9tIHRoZSB3aWRlbHkg a25vd24gdXNhZ2Ugb2Ygc2FsdCwgZS5nLiBpbiBVTklYIG9wZXJhdGluZyBzeXN0ZW0sIHNhbHQN CmlzIG5vdCByZXF1aXJlZCB0byByZW1lbWJlciBieSB0aGUgdXNlciwgYnV0IGJ5IHNlcnZlciB0 byBmZXRjaCBsb2NhbGx5DQpieSByZWZlcmVuY2UgdG8gdGhlIHVzZXJuYW1lLiA8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyBBbmQgYXMgZmFyIGFzIEkg a25vdywgSSBhbSBzdXJlDQp0aGUgYXV0aG9ycyBhbHNvIGtub3cgdGhhdCwgb3RoZXIgcGFzc3dv cmQgYmFzZWQga2V5IGV4Y2hhbmdlcyBwcm90b2NvbHMNCmRvbid0IGludm9sdmUgc2FsdCwgYnV0 IHN0b3JlIGEgaGFzaCB2YWx1ZSBvZiBwYXNzd29yZCBhbW9uZyBvdGhlciB0aGluZ3MNCmxvY2Fs bHkuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4yLiBGcm9tIHRo ZSBmaWd1cmUgaW4gdGhlIFBQVCBzaG93bg0KYXQgdGhlIG1lZXRpbmcsIEkgY2Fubid0IHNlZSB3 aHkgdGhlIHByb3RvY29sIHNob3VsZCB1c2UgYm90aCAmcXVvdDtwcml2YXRlJnF1b3Q7DQphbmQg JnF1b3Q7bWFzayZxdW90OyB2YWx1ZXMsIGluIG15IG9waW5pb24sIG9ubHkgJnF1b3Q7bWFzayAm cXVvdDsgdmFsdWUNCnNoYWxsIGJlIE9LLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO3ByaXZhdGUgdmFsdWUgaXMgcmVkdW5kZW50LA0KYW5k IG5vdCBoZWxwZnVsIGluIHNlY3VyaXR5IGltcHJvdmVtZW50LjwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO2JlY2F1c2UgdGhlIGN1cnJlbnQg ZGVyaXZlZA0Kc2hhcmVkIGtleSBpcyBQRV57cHJpdmF0ZV9hKnByaXZhdGVfYn0gJm5ic3A7YWNj b3JkaW5nIHRvIHRoaXMgZG9jdW1lbnSjrA0KYW5kPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7YWZ0ZXIgcmVtb3ZpbmcgcHJpdmF0ZQ0KdmFs dWUsIGl0IHdpbGwgYmUgJm5ic3A7UEVee21hc2tfYSptYXNrX2J9PC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7YW5kIHByaXZhdGUsIG1hc2sg dmFsdWUNCmFyZSBib3RoIGdlbmVyYXRlZCBsb2NhbGx5IGFuZCBub3QgdHJhbnNwb3J0ZWQgJm5i c3A7b24gdGhlIHdpcmUsIHNvIGl0DQpkb2VzIG5vdCBtYWtlIG11Y2ggZGlmZmVyZW5jZSBleGNl cHQgbWFraW5nIGl0IG1vcmUgY29tcGxleC48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPjMuIE5vdyBJIG9ubHkgdGFsayBhYm91dCB0aGUgc2VjdXJpdHkNCm9mIHRo ZSBzaW1wbGlmaWVkIHZlcnNpb24gKGFzIGluIGFib3ZlIHBvaW50IDIpPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7YWZ0ZXIgc2ltcGxpZmlj YXRpb24gdGhlDQpwcm90b2NvbCBpcyBlYXNpZXIgdG8gYW5hbHlzaXplLCBpdCBpcyBqdXN0IGxp a2UgYW4gb3JkaW5hcnkgREggZXhjaGFuZ2UNCmV4Y2VwdCB0aGF0IHRoZSBiYXNlIGdyb3VwIGdl bmVyYXRvciBpcyBQRSBpbnN0ZWFkIG9mIGcuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7U28gdGhlIHNlY3VyaXR5IGlzIHJlZHVjZWQNCnRv IHRoZSBQRSwgaXMgaXQgYSBnb29kIGdyb3VwIGdlbmVyYXRvciB3aGljaCBoYXMgbGFyZ2Ugb3Jk ZXI/IGlmIG5vdCB0aGVuDQppdCBpcyBpbnNlY3VyZS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtVbmZvcnR1bmF0bHkgdGhlIGF1dGhvcnMN CmZhaWxlZCB0byBhbmFseXNpemUgdGhpcyBjcnVjaWFsIHBvaW50LjwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmsgeW91IGZvciB5b3VyIHBhdGll bmNlITwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+U3Vq aW5nIFpob3UgJm5ic3A7IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+Jm5ic3A7IDwvZm9udD4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7 U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250 YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJz cDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRp b24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtj b25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDth cmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNw O2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xv c2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmlj YXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNw O2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDth cmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZu YnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVh bCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2Fy ZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZl ZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJz cDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtt ZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0 aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJz cDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJz cDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtT cGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 003162E54825794C_=-- From zhou.sujing@zte.com.cn Fri Nov 18 01:11:10 2011 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 0C22621F85EF for ; Fri, 18 Nov 2011 01:11:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.877 X-Spam-Level: X-Spam-Status: No, score=-100.877 tagged_above=-999 required=5 tests=[AWL=0.961, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_DOUBLE_IP_LOOSE=0.76, 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 1GZhmTRc2FkG for ; Fri, 18 Nov 2011 01:11:09 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id CB41C21F84E5 for ; Fri, 18 Nov 2011 01:10:42 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 566901626001193; Fri, 18 Nov 2011 16:58:51 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.15] with StormMail ESMTP id 20387.1626001193; Fri, 18 Nov 2011 17:10:36 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id pAI9AOiA016414 for ; Fri, 18 Nov 2011 17:10:24 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) To: tls@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Fri, 18 Nov 2011 17:10:08 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-11-18 17:10:25, Serialize complete at 2011-11-18 17:10:25 Content-Type: multipart/alternative; boundary="=_alternative 003265384825794C_=" X-MAIL: mse01.zte.com.cn pAI9AOiA016414 Subject: [TLS] concers about draft-balfanz-tls-obc 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, 18 Nov 2011 09:11:10 -0000 This is a multipart message in MIME format. --=_alternative 003265384825794C_= Content-Type: text/plain; charset="US-ASCII" Hi, I don't think the origin-bound-certificate is meaningful. The reasons are: 1. CA signed client certificate is used to authenticate the client user, now it is replaced by a self-signed certificate, how can a server trust or authenticate a self confirmed user? 2. If client authentication is not required, then there is neither need to send a self-signed certificate. 3. To the goal of bindling cookie with self-signed certificate, the ordinary CA signed certificates also work. Sujing Zhou -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 003265384825794C_= Content-Type: text/html; charset="US-ASCII"
Hi,
   I don't think the origin-bound-certificate is meaningful.
   The reasons are:
   1. CA signed client certificate is used to authenticate the client user, now it is replaced by a self-signed certificate, how can a server trust or authenticate a self confirmed user?
   2. If client authentication is not required, then there is neither need to send a self-signed certificate.
   3. To the goal of bindling cookie with self-signed certificate, the ordinary CA signed certificates also work.


Sujing Zhou
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 003265384825794C_=-- From zhou.sujing@zte.com.cn Fri Nov 18 01:15:57 2011 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 D1F1221F8678 for ; Fri, 18 Nov 2011 01:15:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.321 X-Spam-Level: X-Spam-Status: No, score=-100.321 tagged_above=-999 required=5 tests=[AWL=-0.236, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, 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 y-rovMiusgbX for ; Fri, 18 Nov 2011 01:15:57 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id E59C621F84DA for ; Fri, 18 Nov 2011 01:15:56 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 566901626001193; Fri, 18 Nov 2011 17:04:06 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 76252.1626001193; Fri, 18 Nov 2011 17:15:36 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id pAI9FhlJ025989 for ; Fri, 18 Nov 2011 17:15:43 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) To: tls@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Fri, 18 Nov 2011 17:15:28 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-11-18 17:15:45, Serialize complete at 2011-11-18 17:15:45 Content-Type: multipart/alternative; boundary="=_alternative 0032E2394825794C_=" X-MAIL: mse01.zte.com.cn pAI9FhlJ025989 Subject: [TLS] about draft-agl-tls-encryptedclientcerts 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, 18 Nov 2011 09:15:57 -0000 This is a multipart message in MIME format. --=_alternative 0032E2394825794C_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGmjrA0KICBJIG5vdGUgdGhhdCBDaGFuZyBzYWlkIHRoYXQgobBCYWRyYSdzICBkcmFmdCBhbHNv IGNoYW5nZSBUTFMgc3RhdGUgDQptYWNoaW5lobFpbiBwcmVzZW50aW5nIGRyYWZ0LWFnbC10bHMt ZW5jcnlwdGVkY2xpZW50Y2VydHMsDQogSSBydW4gdGhyb3VnaCBpdCANCiBodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1oYWpqZWgtdGxzLWlkZW50aXR5LXByb3RlY3Rpb24tMDkNCiAN CiAgYW5kIGZvdW5kIHRoYXQgaXMgbm90IHRoZSBjYXNlLg0KDQogSW4gc2VjdGlvbiAyLjQgdGhl cmUgaXMgYSBjbGVhciBmaWcgc2hvd2luZyB0aGUgZmxvdyBpcyBub3QgY2hhbmdlZC4gDQoNCg0K RllJLg0KDQpTdWppbmcgDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBv ZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBj b25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWlu dGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVu dHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBm aWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNv bGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5 IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Ig cGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4 cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRl ci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5 IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 0032E2394825794C_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpo6w8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyBJIG5vdGUgdGhhdCBDaGFuZyBzYWlk IHRoYXQgobBCYWRyYSdzDQombmJzcDtkcmFmdCBhbHNvIGNoYW5nZSBUTFMgc3RhdGUgbWFjaGlu ZaGxaW4gcHJlc2VudGluZyBkcmFmdC1hZ2wtdGxzLWVuY3J5cHRlZGNsaWVudGNlcnRzLDwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7SSBydW4gdGhyb3Vn aCBpdCA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOzwv Zm9udD48YSBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1oYWpqZWgtdGxz LWlkZW50aXR5LXByb3RlY3Rpb24tMDkjc2VjdGlvbi0yIj48Zm9udCBzaXplPTIgY29sb3I9Ymx1 ZSBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjx1Pmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1sL2Ry YWZ0LWhhamplaC10bHMtaWRlbnRpdHktcHJvdGVjdGlvbi0wOTwvdT48L2ZvbnQ+PC9hPg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOyA8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7IGFuZCBmb3VuZCB0aGF0 IGlzIG5vdCB0aGUNCmNhc2UuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJU aW1lcyBOZXcgUm9tYW4iPiZuYnNwO0luIHNlY3Rpb24gMi40IHRoZXJlIGlzIGENCmNsZWFyIGZp ZyBzaG93aW5nIHRoZSBmbG93IGlzIG5vdCBjaGFuZ2VkLiA8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+RllJLjwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5TdWppbmcgPC9mb250Pg0K PGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGlj ZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7 dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2Ym bmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7 bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtS ZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZu YnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7 bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2Nv bnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7 b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJz cDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlh bCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5i c3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRp dHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZu YnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2Vt YWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZu YnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5i c3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5i c3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtz ZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVk Jm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pU RSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 0032E2394825794C_=-- From n.mavrogiannopoulos@gmail.com Fri Nov 18 01:19:23 2011 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 34E7921F8876 for ; Fri, 18 Nov 2011 01:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wrJ0w1tctWHh for ; Fri, 18 Nov 2011 01:19:22 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 704F821F8880 for ; Fri, 18 Nov 2011 01:19:22 -0800 (PST) Received: by wwe5 with SMTP id 5so4008046wwe.13 for ; Fri, 18 Nov 2011 01:19:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=KhHFXF5bRoL+CtOzJy4uraUGkML+rUlRXPKXGcRacXM=; b=uWn38XSLEqM7gdo0qGpVz9CGiJ8ScDyx9cGziOTXAy9IEFpw0kEvVJq9khesq0jklz buRz9D3bl75xJnhU6b3ZDTpOy58vCww0d06hlnMoTFeG+fvmRHC/KC0g7JjA5tnoKy2d dlKiDi8k6FRqr2OAHA7kTHfkYsmmktvMjMNxE= MIME-Version: 1.0 Received: by 10.216.80.88 with SMTP id j66mr217563wee.26.1321607961609; Fri, 18 Nov 2011 01:19:21 -0800 (PST) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.180.24.162 with HTTP; Fri, 18 Nov 2011 01:19:21 -0800 (PST) In-Reply-To: References: Date: Fri, 18 Nov 2011 10:19:21 +0100 X-Google-Sender-Auth: 57MLg3jK16KG8sKhZRF7ayXxUyQ Message-ID: From: Nikos Mavrogiannopoulos To: zhou.sujing@zte.com.cn Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] concers about draft-balfanz-tls-obc 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, 18 Nov 2011 09:19:23 -0000 On Fri, Nov 18, 2011 at 10:10 AM, wrote: > Hi, > =C2=A0 =C2=A0I don't think the origin-bound-certificate is meaningful. > =C2=A0 =C2=A0The reasons are: > =C2=A0 =C2=A01. CA signed client certificate is used to authenticate the = client user, > now it is replaced by a self-signed certificate, how can a server trust o= r > authenticate a self confirmed user? Isn't it the current situation in web sites? Aren't all popular web site's users self confirmed? > =C2=A0 =C2=A02. If client authentication is not required, then there is n= either need > to send a self-signed certificate. I don't think that the draft asks for client to be authenticated when client authentication is not required. > =C2=A0 =C2=A03. To the goal of bindling cookie with self-signed certifica= te, the > ordinary CA signed certificates also work. At a cost that no-one is willing to pay (not only monetary, but also the cost of proving yourself to the CA --or the CA will allow self-confirmation to the users? :). regards, Nikos From zhou.sujing@zte.com.cn Fri Nov 18 01:44:18 2011 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 A037821F8549 for ; Fri, 18 Nov 2011 01:44:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.615 X-Spam-Level: X-Spam-Status: No, score=-96.615 tagged_above=-999 required=5 tests=[AWL=-3.825, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 5fyyWIRl3nCF for ; Fri, 18 Nov 2011 01:44:18 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 9FB9421F850B for ; Fri, 18 Nov 2011 01:44:17 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 566901626001193; Fri, 18 Nov 2011 17:32:11 +0800 (CST) Received: from [10.30.3.20] by [192.168.168.16] with StormMail ESMTP id 76252.3121279582; Fri, 18 Nov 2011 17:43:58 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id pAI9i61c084532; Fri, 18 Nov 2011 17:44:06 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: To: Nikos Mavrogiannopoulos MIME-Version: 1.0 X-KeepSent: 600653FF:BB3D96FD-4825794C:0035462E; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Fri, 18 Nov 2011 17:43:51 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-11-18 17:44:08, Serialize complete at 2011-11-18 17:44:08 Content-Type: multipart/alternative; boundary="=_alternative 00357B584825794C_=" X-MAIL: mse01.zte.com.cn pAI9i61c084532 Cc: n.mavrogiannopoulos@gmail.com, tls@ietf.org Subject: [TLS] =?gb2312?b?tPC4tDogUmU6ICBjb25jZXJzIGFib3V0IGRyYWZ0LWJhbGZh?= =?gb2312?b?bnotdGxzLW9iYw==?= 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, 18 Nov 2011 09:44:18 -0000 This is a multipart message in MIME format. --=_alternative 00357B584825794C_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 bi5tYXZyb2dpYW5ub3BvdWxvc0BnbWFpbC5jb20g0LTT2iAyMDExLTExLTE4IDE3OjE5OjIxOg0K DQo+IE9uIEZyaSwgTm92IDE4LCAyMDExIGF0IDEwOjEwIEFNLCAgPHpob3Uuc3VqaW5nQHp0ZS5j b20uY24+IHdyb3RlOg0KPiA+IEhpLA0KPiA+ICAgIEkgZG9uJ3QgdGhpbmsgdGhlIG9yaWdpbi1i b3VuZC1jZXJ0aWZpY2F0ZSBpcyBtZWFuaW5nZnVsLg0KPiA+ICAgIFRoZSByZWFzb25zIGFyZToN Cj4gPiAgICAxLiBDQSBzaWduZWQgY2xpZW50IGNlcnRpZmljYXRlIGlzIHVzZWQgdG8gYXV0aGVu dGljYXRlIHRoZSBjbGllbnQgDQp1c2VyLA0KPiA+IG5vdyBpdCBpcyByZXBsYWNlZCBieSBhIHNl bGYtc2lnbmVkIGNlcnRpZmljYXRlLCBob3cgY2FuIGEgc2VydmVyIA0KdHJ1c3Qgb3INCj4gPiBh dXRoZW50aWNhdGUgYSBzZWxmIGNvbmZpcm1lZCB1c2VyPw0KPiANCj4gSXNuJ3QgaXQgdGhlIGN1 cnJlbnQgc2l0dWF0aW9uIGluIHdlYiBzaXRlcz8gQXJlbid0IGFsbCBwb3B1bGFyIHdlYg0KPiBz aXRlJ3MgdXNlcnMgc2VsZiBjb25maXJtZWQ/DQoNCk5vdCBpbiB0aGUgY2FzZSBvZiBiYW5rIHdl YnNpdGUuDQp0aGUgY2VydGlmaWNhdGUgbWF5IGJlIHNpZ25lZCBieSB0aGUgYmFuayBidXQgZGVm bnRseSBub3QgYnkgdGhlIGNsaWVudCANCnVzZXIgc2VsZi4NCj4gDQo+ID4gICAgMi4gSWYgY2xp ZW50IGF1dGhlbnRpY2F0aW9uIGlzIG5vdCByZXF1aXJlZCwgdGhlbiB0aGVyZSBpcyBuZWl0aGVy IA0KbmVlZA0KPiA+IHRvIHNlbmQgYSBzZWxmLXNpZ25lZCBjZXJ0aWZpY2F0ZS4NCj4gDQo+IEkg ZG9uJ3QgdGhpbmsgdGhhdCB0aGUgZHJhZnQgYXNrcyBmb3IgY2xpZW50IHRvIGJlIGF1dGhlbnRp Y2F0ZWQgd2hlbg0KPiBjbGllbnQgYXV0aGVudGljYXRpb24gaXMgbm90IHJlcXVpcmVkLg0KPiAN Cj4gPiAgICAzLiBUbyB0aGUgZ29hbCBvZiBiaW5kbGluZyBjb29raWUgd2l0aCBzZWxmLXNpZ25l ZCBjZXJ0aWZpY2F0ZSwgdGhlDQo+ID4gb3JkaW5hcnkgQ0Egc2lnbmVkIGNlcnRpZmljYXRlcyBh bHNvIHdvcmsuDQo+IA0KPiBBdCBhIGNvc3QgdGhhdCBuby1vbmUgaXMgd2lsbGluZyB0byBwYXkg KG5vdCBvbmx5IG1vbmV0YXJ5LCBidXQgYWxzbw0KPiB0aGUgY29zdCBvZiBwcm92aW5nIHlvdXJz ZWxmIHRvIHRoZSBDQSAtLW9yIHRoZSBDQSB3aWxsIGFsbG93DQo+IHNlbGYtY29uZmlybWF0aW9u IHRvIHRoZSB1c2Vycz8gOikuDQo+IA0KPiByZWdhcmRzLA0KPiBOaWtvcw0KPiANCg0KDQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpa VEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVk IGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXph dGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRz IG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5v dCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlv biB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBp dCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhl IGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3Ug aGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdp bmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdl IGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJl ZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4N Cg== --=_alternative 00357B584825794C_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5uLm1hdnJvZ2lhbm5vcG91bG9zQGdtYWlsLmNvbSDlhpnk uo4gMjAxMS0xMS0xOCAxNzoxOToyMTo8YnI+DQo8YnI+DQomZ3Q7IE9uIEZyaSwgTm92IDE4LCAy MDExIGF0IDEwOjEwIEFNLCAmbmJzcDsmbHQ7emhvdS5zdWppbmdAenRlLmNvbS5jbiZndDsNCndy b3RlOjxicj4NCiZndDsgJmd0OyBIaSw8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO0kgZG9u J3QgdGhpbmsgdGhlIG9yaWdpbi1ib3VuZC1jZXJ0aWZpY2F0ZSBpcyBtZWFuaW5nZnVsLjxicj4N CiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7VGhlIHJlYXNvbnMgYXJlOjxicj4NCiZndDsgJmd0OyAm bmJzcDsgJm5ic3A7MS4gQ0Egc2lnbmVkIGNsaWVudCBjZXJ0aWZpY2F0ZSBpcyB1c2VkIHRvIGF1 dGhlbnRpY2F0ZQ0KdGhlIGNsaWVudCB1c2VyLDxicj4NCiZndDsgJmd0OyBub3cgaXQgaXMgcmVw bGFjZWQgYnkgYSBzZWxmLXNpZ25lZCBjZXJ0aWZpY2F0ZSwgaG93IGNhbiBhIHNlcnZlcg0KdHJ1 c3Qgb3I8YnI+DQomZ3Q7ICZndDsgYXV0aGVudGljYXRlIGEgc2VsZiBjb25maXJtZWQgdXNlcj88 YnI+DQomZ3Q7IDxicj4NCiZndDsgSXNuJ3QgaXQgdGhlIGN1cnJlbnQgc2l0dWF0aW9uIGluIHdl YiBzaXRlcz8gQXJlbid0IGFsbCBwb3B1bGFyIHdlYjxicj4NCiZndDsgc2l0ZSdzIHVzZXJzIHNl bGYgY29uZmlybWVkPzwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Tm90 IGluIHRoZSBjYXNlIG9mIGJhbmsgd2Vic2l0ZS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPnRoZSBjZXJ0aWZpY2F0ZSBtYXkgYmUgc2lnbmVkIGJ5IHRoZSBiYW5rIGJ1dCBkZWZu dGx5DQpub3QgYnkgdGhlIGNsaWVudCB1c2VyIHNlbGYuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZn dDsgJm5ic3A7ICZuYnNwOzIuIElmIGNsaWVudCBhdXRoZW50aWNhdGlvbiBpcyBub3QgcmVxdWly ZWQsIHRoZW4NCnRoZXJlIGlzIG5laXRoZXIgbmVlZDxicj4NCiZndDsgJmd0OyB0byBzZW5kIGEg c2VsZi1zaWduZWQgY2VydGlmaWNhdGUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgZG9uJ3QgdGhp bmsgdGhhdCB0aGUgZHJhZnQgYXNrcyBmb3IgY2xpZW50IHRvIGJlIGF1dGhlbnRpY2F0ZWQgd2hl bjxicj4NCiZndDsgY2xpZW50IGF1dGhlbnRpY2F0aW9uIGlzIG5vdCByZXF1aXJlZC48L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAm bmJzcDszLiBUbyB0aGUgZ29hbCBvZiBiaW5kbGluZyBjb29raWUgd2l0aCBzZWxmLXNpZ25lZA0K Y2VydGlmaWNhdGUsIHRoZTxicj4NCiZndDsgJmd0OyBvcmRpbmFyeSBDQSBzaWduZWQgY2VydGlm aWNhdGVzIGFsc28gd29yay48YnI+DQomZ3Q7IDxicj4NCiZndDsgQXQgYSBjb3N0IHRoYXQgbm8t b25lIGlzIHdpbGxpbmcgdG8gcGF5IChub3Qgb25seSBtb25ldGFyeSwgYnV0IGFsc288YnI+DQom Z3Q7IHRoZSBjb3N0IG9mIHByb3ZpbmcgeW91cnNlbGYgdG8gdGhlIENBIC0tb3IgdGhlIENBIHdp bGwgYWxsb3c8YnI+DQomZ3Q7IHNlbGYtY29uZmlybWF0aW9uIHRvIHRoZSB1c2Vycz8gOikuPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IHJlZ2FyZHMsPGJyPg0KJmd0OyBOaWtvczxicj4NCiZndDsgPGJy Pg0KPC9mb250PjwvdHQ+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1Nl Y3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFp bmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7 cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9u LiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29u ZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJl Jm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDth bmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3Nl Jm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0 aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDth bnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJl Jm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJz cDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwm bmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUm bmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQm bmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7 bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVz c2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhp cyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7 aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7 YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3Bh bSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 00357B584825794C_=-- From ynir@checkpoint.com Fri Nov 18 03:38:26 2011 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 0AD0A21F889A for ; Fri, 18 Nov 2011 03:38:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, 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 dvuyLXPaGfnK for ; Fri, 18 Nov 2011 03:38:25 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 07A8E21F89B8 for ; Fri, 18 Nov 2011 03:38:23 -0800 (PST) X-CheckPoint: {4EC6434A-0-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pAIBcKv0014709; Fri, 18 Nov 2011 13:38:20 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 18 Nov 2011 13:38:20 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Fri, 18 Nov 2011 13:38:20 +0200 From: Yoav Nir To: Marsh Ray Date: Fri, 18 Nov 2011 13:38:20 +0200 Thread-Topic: [TLS] NextProtoNeg concerns Thread-Index: Acyl5pIZNPRDAV57R5eDPqoFI6d4+Q== Message-ID: <957E174C-F9A9-488D-86D2-FF0E3E24BF40@checkpoint.com> References: <4F26370A-E4DA-4EDF-8D33-D77F2D9C89FB@checkpoint.com> <4EC5EEC8.3000903@extendedsubset.com> In-Reply-To: <4EC5EEC8.3000903@extendedsubset.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "tls@ietf.org List" Subject: Re: [TLS] NextProtoNeg concerns 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, 18 Nov 2011 11:38:26 -0000 On Nov 18, 2011, at 1:36 PM, Marsh Ray wrote: > On 11/17/2011 11:17 PM, Yoav Nir wrote: >>=20 >> What I really don't like about this proposal, is this text in section >> 3: The "extension_data" field in a "ServerHello" and the >> "NextProtocol" message contain opaque bytes to be used by the >> application layer to negotiate the application layer protocol. The >> format of this data is not specified in this draft. >>=20 >> If you are defining a new extension/handshake message to carry a new >> kind of data (application type) there is no value to this without a >> definition of the format, either in the same document or in a >> companion document. >>=20 >> The examples in the slides show a very specific format: >> "\x06spdy/2\x08http/1.1\x08http/1.0". I don't see why this would not >> be specified in the document. Of course, you would need to set up a >> registry for these strings. For example, I can see how Microsoft >> would want to register SSTP, and other vendors would register their >> own SSL-VPN protocols as well. >=20 > What if you're a small application developer, perhaps with a single=20 > application or running only a few servers. Should you be expected to=20 > register your format before using it? >=20 > Would it be expected to follow the same length-value format as the exampl= e? >=20 > Would anyone ever be denied registration? What if their format=20 > definition was technically deficient, or they wanted to reserve a bunch=20 > of unrelated protocol names? That would be up to the draft to specify. You could do it as FCFS or techni= cal expert review - no need for a draft. And we could reserve some prefixes, like exp- (for experiment) and priv- (f= or private protocol). You could then safely use "exp-marshray-test1" From mbadra@gmail.com Fri Nov 18 04:17:41 2011 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 62FDB21F8A97 for ; Fri, 18 Nov 2011 04:17:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, 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 yygxo6El27uR for ; Fri, 18 Nov 2011 04:17:40 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id C087621F8797 for ; Fri, 18 Nov 2011 04:17:40 -0800 (PST) Received: by vcbfy13 with SMTP id fy13so49844vcb.31 for ; Fri, 18 Nov 2011 04:17:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=LajxdpvCOPpR0WheNXB7AkF+oKJiMOfewinyX71611w=; b=kbeVNBVfC1l4pGCq+7PaGnr7mUWkg2vpJFWIr1W8vZA86lQny9i4+gn6fqa3qx/8l+ dz4P7KeVzsSf0a7E0Ym/AJfnjttRJBwWgenJWl/PCWW+U01pY1zX3r/K+AYJQPwcPQ+j 7xrJv5TI8v+z6cp8PO+1GCnxUqA/6pQCrsCt0= MIME-Version: 1.0 Received: by 10.220.238.198 with SMTP id kt6mr204982vcb.164.1321618660238; Fri, 18 Nov 2011 04:17:40 -0800 (PST) Received: by 10.220.201.71 with HTTP; Fri, 18 Nov 2011 04:17:40 -0800 (PST) In-Reply-To: <4EC4F080.7080100@KingsMountain.com> References: <4EC4F080.7080100@KingsMountain.com> Date: Fri, 18 Nov 2011 13:17:40 +0100 Message-ID: From: Badra To: tls@ietf.org Content-Type: multipart/alternative; boundary=14dae9cfccbac5a3b604b201528b Subject: Re: [TLS] raw unofficial minutes: TLS WG: IETF-82 Taipei 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, 18 Nov 2011 12:17:41 -0000 --14dae9cfccbac5a3b604b201528b Content-Type: text/plain; charset=ISO-8859-1 Thanks Jeff, > wtc: badra also proposes state machine change as well as the ciphersuite stuff If you mean draft-hajjeh-tls-identity-protection-09, the chage are minor with comparison to draft-agl-tls-encryptedclientcerts-00. ciphersuite is more suitable than extensions, especially for SSLv3 and TLS1.0/TLS1.1 implementations. If you mean draft-badra-tls-identity-protection-01, you are right. > sean (st): badra has IPR in his draft too -- need to consider that I am not a lawyer, but I think that draft-agl-tls-encryptedclientcerts-00 and any other document - that proposes encrypting the client's certificate during the initial TLS handshake- are equally relevant to the same IPR. Best regards Badra On Thu, Nov 17, 2011 at 12:31 PM, =JeffH wrote: These could undoubtedly use some cleanup wrt things I missed and/or got wrong wrt what folks said. please consider them to be preliminary and unofficial. HTH, =JeffH ------ --14dae9cfccbac5a3b604b201528b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Jeff,

> = wtc: badra also proposes state machine change as well as the ciphersuite st= uff=A0

If you mean draft-hajjeh-tls-identity-prote= ction-09, the chage are minor with comparison to draft-agl-tls-encryptedcli= entcerts-00.
ciphersuite is more suitable than extensions, especially for SSLv3 and= TLS1.0/TLS1.1 implementations.

If you mean draft-= badra-tls-identity-protection-01, you are right.

> sean (st): badra has IPR in his draft too -- need to consider that

I am not a lawyer, but I think that draft-agl-tls-enc= ryptedclientcerts-00 and any other document - that proposes encrypting the = client's certificate during the initial TLS handshake- are equally=A0re= levant to the same IPR.

Best regards
Badra

O= n Thu, Nov 17, 2011 at 12:31 PM, =3DJeffH <Jeff.Hodges@kingsmountain.com> wrote:
These could undoubtedly use some cleanup wrt things I missed and/or got wro= ng wrt what folks said. please consider them to be preliminary and unoffici= al.

HTH,

=3DJeffH
------
--14dae9cfccbac5a3b604b201528b-- From agl@google.com Fri Nov 18 05:32:06 2011 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 D210121F8A97 for ; Fri, 18 Nov 2011 05:32:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTResCxkVu2A for ; Fri, 18 Nov 2011 05:32:06 -0800 (PST) Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4723E21F8A80 for ; Fri, 18 Nov 2011 05:32:05 -0800 (PST) Received: by iaeo4 with SMTP id o4so4480242iae.31 for ; Fri, 18 Nov 2011 05:32:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-system-of-record; bh=9qm6EXNWfT+wwR8e6JEtXWYSvpQgRPVH1XdL025DeGA=; b=hslBiuvsb5BHu2P5ezIci8pj4WCzpwADDzEKk84Uhsz3TWIiFzIKQQjYmJ8J6s/mYq Cpsam3h0wmMQ5KzUtYmQ== Received: by 10.42.19.195 with SMTP id d3mr964230icb.21.1321623125643; Fri, 18 Nov 2011 05:32:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.42.19.195 with SMTP id d3mr964224icb.21.1321623125541; Fri, 18 Nov 2011 05:32:05 -0800 (PST) Received: by 10.231.37.195 with HTTP; Fri, 18 Nov 2011 05:32:05 -0800 (PST) In-Reply-To: <4F26370A-E4DA-4EDF-8D33-D77F2D9C89FB@checkpoint.com> References: <4F26370A-E4DA-4EDF-8D33-D77F2D9C89FB@checkpoint.com> Date: Fri, 18 Nov 2011 08:32:05 -0500 Message-ID: From: Adam Langley To: Yoav Nir Content-Type: text/plain; charset=UTF-8 X-System-Of-Record: true Cc: "tls@ietf.org List" Subject: Re: [TLS] NextProtoNeg concerns 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, 18 Nov 2011 13:32:06 -0000 On Fri, Nov 18, 2011 at 12:17 AM, Yoav Nir wrote: > If you are defining a new extension/handshake message to carry a new kind of data (application type) there is no value to this without a definition of the format, either in the same document or in a companion document. I agree. The current, sparse form of the draft was simply intended to omit details in order that the more salient points be obvious. I would absolutely expect that any draft would end up specifying the format of the messages; something like: "Protocols are named by opaque, non-empty byte strings and the list of protocols is serialized as a concatenation of 8-bit, length prefixed byte strings. Implementations MUST ensure that the empty string is not included and no byte strings are truncated." "The NextProtocol message has the following format: struct { opaque selected_protocol<0..255>; opaque padding<0..255>; } NextProtocol; The contents of selected_protocol are a protocol but need not have been advertised by the server. The length of padding should be 32 - ((len(selected_protocol) + 2) % 32). Note that len(selected_protocol) does not include its length prefix." Cheers AGL From n.mavrogiannopoulos@gmail.com Fri Nov 18 05:33:24 2011 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 7433021F8AF8 for ; Fri, 18 Nov 2011 05:33:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, 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 eRZYm6wrivfA for ; Fri, 18 Nov 2011 05:33:24 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id BF66221F8AF7 for ; Fri, 18 Nov 2011 05:33:23 -0800 (PST) Received: by wwe5 with SMTP id 5so4306452wwe.13 for ; Fri, 18 Nov 2011 05:33:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; 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=eFwcWqsVKIKG0k5CiGx67keZc3X/MXsTTGNM+cUkWpA=; b=a+tB6H+QkyRJFCfDZn0nTBLJDtU+rq3LhFGRC6KST+N6TQYFBsWZtgZ7uo+HArpCCT Rsbedd4H15itFZjBTtRQbDui88qS0lYJtYuKDoWqfjZBasiQBHQjZQ0jN2ZdvgZgxi4r GXeX3rGacIjYEcItTVCnwdlvWqvQPmWULFQJk= MIME-Version: 1.0 Received: by 10.180.108.47 with SMTP id hh15mr3304092wib.14.1321623202901; Fri, 18 Nov 2011 05:33:22 -0800 (PST) Sender: n.mavrogiannopoulos@gmail.com Received: by 10.180.24.162 with HTTP; Fri, 18 Nov 2011 05:33:22 -0800 (PST) In-Reply-To: References: <4EC4F080.7080100@KingsMountain.com> Date: Fri, 18 Nov 2011 14:33:22 +0100 X-Google-Sender-Auth: VVjqlSxnzI0oTqqMGJn5jDzfCQc Message-ID: From: Nikos Mavrogiannopoulos To: Badra Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] raw unofficial minutes: TLS WG: IETF-82 Taipei 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, 18 Nov 2011 13:33:24 -0000 On Fri, Nov 18, 2011 at 1:17 PM, Badra wrote: >> sean (st): badra has IPR in his draft too -- need to consider that > I am not a lawyer, but I think that draft-agl-tls-encryptedclientcerts-00 > and any other document - that proposes encrypting the client's certificat= e > during the initial TLS handshake- are equally=C2=A0relevant to the same I= PR. I would be very surprised on something like that because client and server certificate encryption was first(*) used in IKEv2 (RFC4306) which predates the disclosed patents. (*) to my knowledge. Protocols using this technique before that, might exis= t. regards, Nikos From mbadra@gmail.com Fri Nov 18 12:02:09 2011 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 033691F0C6A for ; Fri, 18 Nov 2011 12:02:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Bylk0Z8PcGNh for ; Fri, 18 Nov 2011 12:02:08 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id E3E6F1F0C58 for ; Fri, 18 Nov 2011 12:02:07 -0800 (PST) Received: by vbbfc26 with SMTP id fc26so600962vbb.31 for ; Fri, 18 Nov 2011 12:02:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=t6fPIQmfYE0Zvopmj4FLAr3R6gmwx96D/24oXS+Eq5c=; b=MMV+Ee7MKaYcXshve6mWj8xN4OdEKMS7yKYOdMbL6cqj7V4xddaHcGQTsZK73GAJMq 4v5I21RIBSXTnaPb37iLMYBbWm7+tolMxApnvrRc9hOvLPMKAXoWOLTRWcNI8Jb1s0Pw DbbxlcSOkdpB4IcZ/I4fVWIXhq+65z/+xiYMM= MIME-Version: 1.0 Received: by 10.52.73.39 with SMTP id i7mr1443594vdv.44.1321646527133; Fri, 18 Nov 2011 12:02:07 -0800 (PST) Received: by 10.220.201.71 with HTTP; Fri, 18 Nov 2011 12:02:07 -0800 (PST) In-Reply-To: References: Date: Fri, 18 Nov 2011 21:02:07 +0100 Message-ID: From: Badra To: Eric Rescorla Content-Type: multipart/alternative; boundary=bcaec5016115c4b60b04b207cf12 Cc: tls@ietf.org Subject: Re: [TLS] New Version Notification for draft-wouters-tls-oob-pubkey-01.txt (fwd) 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, 18 Nov 2011 20:02:09 -0000 --bcaec5016115c4b60b04b207cf12 Content-Type: text/plain; charset=ISO-8859-1 Hi, What happened to draft-ietf-tls-cached-info-09? And how does draft-wouters-tls-oob-pubkey differ from draft-ietf-tls-cached-info-09? Best regards, Badra On Thu, Nov 17, 2011 at 8:47 AM, Eric Rescorla wrote: > Extending TLS to support a raw public key seems like a good idea and > I support taking it on. > > Extending it to suppress the public key and instead send a hash from server > to the client seems less so; if the server sends the public key, it works > if the client knows either (a) the server public key or (b) a digest of the > public key. Sending a digest only works if the client already knows the > public key, which seems far less likely. If you want to suppress the > server sending the key, a better (and more general) solution is to > resurrect cached-info. This would work with both raw keys and > certificates. > > -Ekr > > > On Mon, Oct 31, 2011 at 4:21 PM, Paul Wouters wrote: > > > > This is the new version of the draft incorporating the feedback from > Quebec > > City > > and the TLS list since then. It changes the draft from a new TLS > extension > > to a > > new Certificate Type for raw keys. > > > > It also merges in the unpublished draft material from Hannes Tschofenig > > and Tero Kivinen whom had also been working on raw RSA > > TLS keys for use with CoAP (eg devices with no real time clock where > > PKIX validation cannot work) > > > > I did not yet change the draft ofrom individual submission to working > group > > item, > > as I was waiting for confirmation on the TLW WG list of the last Quebec > City > > meeting. > > > > http://tools.ietf.org/html/draft-wouters-tls-oob-pubkey-01 > > > > Paul > > > > ---------- Forwarded message ---------- > > Date: Mon, 31 Oct 2011 17:44:35 > > From: internet-drafts@ietf.org > > Cc: weiler@tislabs.com, hannes.tschofenig@gmx.net, gnu@toad.com, > > paul@xelerance.com, kivinen@iki.fi > > To: paul@xelerance.com > > Subject: New Version Notification for draft-wouters-tls-oob-pubkey-01.txt > > X-Spam-Flag: NO > > > > A new version of I-D, draft-wouters-tls-oob-pubkey-01.txt has been > > successfully submitted by Paul Wouters and posted to the IETF repository. > > > > Filename: draft-wouters-tls-oob-pubkey > > Revision: 01 > > Title: TLS out-of-band public key validation > > Creation date: 2011-10-31 > > WG ID: Individual Submission > > Number of pages: 11 > > > > Abstract: > > This document specifies a new TLS certificate type for exchanging raw > > public keys or their fingerprints in Transport Layer Security (TLS) > > and Datagram Transport Layer Security (DTLS) for use with out-of-band > > authentication. Currently, TLS authentication can only occur via > > PKIX or OpenPGP certificates. By specifying a minimum resource for > > raw public key exchange, implementations can use alternative > > authentication methods. > > > > One such method is using DANE Resource Records secured by DNSSEC, > > Another use case is to provide authentication functionality when used > > with devices in a constrained environment that use whitelists and > > blacklists, as is the case with sensors and other embedded devices > > that are constrained by memory, computational, and communication > > limitations where the usage of PKIX is not feasible. > > > > The new certificate type specified can also be used to reduce the > > latency of a TLS client that is already in possession of a validated > > public key of the TLS server before it starts a (non-resumed) TLS > > handshake. > > > > > > > > > > The IETF Secretariat > > _______________________________________________ > > 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 > --bcaec5016115c4b60b04b207cf12 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

What happened to draft-ietf-tls-cac= hed-info-09?

And how does=A0draft-wouters-tls-oob-= pubkey differ from=A0draft-ietf-tls-cached-info-09?

Best regards,
Badra

On Thu, Nov 17, 2011 at 8:47 A= M, Eric Rescorla <ekr@= rtfm.com> wrote:
Extending TLS to support a raw public key seems like a good idea and
I support taking it on.

Extending it to suppress the public key and instead send a hash from server=
to the client seems less so; if the server sends the public key, it works if the client knows either (a) the server public key or (b) a digest of the=
public key. Sending a digest only works if the client already knows the
public key, which seems far less likely. If you want to suppress the
server sending the key, a better (and more general) solution is to
resurrect cached-info. This would work with both raw keys and
certificates.

-Ekr


On Mon, Oct 31, 2011 at 4:21 PM, Paul Wouters <paul@xelerance.com> wrote:
>
> This is the new version of the draft incorporating the feedback from Q= uebec
> City
> and the TLS list since then. It changes the draft from a new TLS exten= sion
> to a
> new Certificate Type for raw keys.
>
> It also merges in the unpublished draft material from Hannes Tschofeni= g
> and Tero Kivinen <kivinen@iki.fi<= /a>> whom had also been working on raw RSA
> TLS keys for use with CoAP (eg devices with no real time clock where > PKIX validation cannot work)
>
> I did not yet change the draft ofrom individual submission to working = group
> item,
> as I was waiting for confirmation on the TLW WG list of the last Quebe= c City
> meeting.
>
> http://tools.ietf.org/html/draft-wouters-tls-oob-pubkey-= 01
>
> Paul
>
> ---------- Forwarded message ----------
> Date: Mon, 31 Oct 2011 17:44:35
> From: internet-drafts@ietf= .org
> Cc: weiler@tislabs.com, hannes.tschofenig@gmx.net, gnu@toad.com,
> =A0 =A0paul@xelerance.com, <= a href=3D"mailto:kivinen@iki.fi">kivinen@iki.fi
> To: paul@xelerance.com
> Subject: New Version Notification for draft-wouters-tls-oob-pubkey-01.= txt
> X-Spam-Flag: NO
>
> A new version of I-D, draft-wouters-tls-oob-pubkey-01.txt has been
> successfully submitted by Paul Wouters and posted to the IETF reposito= ry.
>
> Filename: =A0 =A0 =A0 =A0draft-wouters-tls-oob-pubkey
> Revision: =A0 =A0 =A0 =A001
> Title: =A0 =A0 =A0 =A0 =A0 TLS out-of-band public key validation
> Creation date: =A0 2011-10-31
> WG ID: =A0 =A0 =A0 =A0 =A0 Individual Submission
> Number of pages: 11
>
> Abstract:
> =A0 This document specifies a new TLS certificate type for exchanging = raw
> =A0 public keys or their fingerprints in Transport Layer Security (TLS= )
> =A0 and Datagram Transport Layer Security (DTLS) for use with out-of-b= and
> =A0 authentication. =A0Currently, TLS authentication can only occur vi= a
> =A0 PKIX or OpenPGP certificates. =A0By specifying a minimum resource = for
> =A0 raw public key exchange, implementations can use alternative
> =A0 authentication methods.
>
> =A0 One such method is using DANE Resource Records secured by DNSSEC,<= br> > =A0 Another use case is to provide authentication functionality when u= sed
> =A0 with devices in a constrained environment that use whitelists and<= br> > =A0 blacklists, as is the case with sensors and other embedded devices=
> =A0 that are constrained by memory, computational, and communication > =A0 limitations where the usage of PKIX is not feasible.
>
> =A0 The new certificate type specified can also be used to reduce the<= br> > =A0 latency of a TLS client that is already in possession of a validat= ed
> =A0 public key of the TLS server before it starts a (non-resumed) TLS<= br> > =A0 handshake.
>
>
>
>
> The IETF Secretariat
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--bcaec5016115c4b60b04b207cf12-- From paul@xelerance.com Fri Nov 18 13:06:11 2011 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 A8CD61F0C73 for ; Fri, 18 Nov 2011 13:06:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.421 X-Spam-Level: X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[AWL=0.178, 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 qY+pXHXSAMLj for ; Fri, 18 Nov 2011 13:06:08 -0800 (PST) Received: from mx.xelerance.com (mx.xelerance.com [193.110.157.188]) by ietfa.amsl.com (Postfix) with ESMTP id 2BA7E1F0C40 for ; Fri, 18 Nov 2011 13:06:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx.xelerance.com (Postfix) with ESMTP id 1D7432C2; Fri, 18 Nov 2011 16:06:04 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xelerance.com; h= content-transfer-encoding:content-type:content-type:mime-version :user-agent:references:message-id:in-reply-to:subject:subject :from:from:date:date:received:received:received:received; s= smtp; t=1321650362; x=1322255162; bh=elO8aenjVSLDo/jBXW0jbafFRDl 32/ehyloxUqnLn84=; b=jPecphSS0JCh5ABP5zwUz4VFEedQO2cyKcfbUz8QDM2 J8S6QnFFiQ35JTKAvg7EXAZ9o7/CWVk35Ys7IXBfv8g5HFW0eNA8EcuKe5mF+3eY qMLZPgPkY3gy06jyNZK7i+Nxwwh3cdQgrpy9Hp6qr8oB35hbE5cn8wpnMeTsUikI = Received: from mx.xelerance.com ([127.0.0.1]) by localhost (mx.xelerance.com [127.0.0.1]) (amavisd-new, port 10026) with LMTP id RY6xhUDEml20; Fri, 18 Nov 2011 16:06:02 -0500 (EST) Received: from mail.xelerance.com (mail.xelerance.com [193.110.157.189]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.xelerance.com (Postfix) with ESMTPS id C974D84; Fri, 18 Nov 2011 16:06:02 -0500 (EST) Received: by mail.xelerance.com (Postfix, from userid 1001) id A9748598; Fri, 18 Nov 2011 16:06:02 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.xelerance.com (Postfix) with ESMTP id A38C556B; Fri, 18 Nov 2011 16:06:02 -0500 (EST) Date: Fri, 18 Nov 2011 16:06:02 -0500 (EST) From: Paul Wouters To: Badra In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Cc: tls@ietf.org Subject: Re: [TLS] New Version Notification for draft-wouters-tls-oob-pubkey-01.txt (fwd) 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, 18 Nov 2011 21:06:11 -0000 On Fri, 18 Nov 2011, Badra wrote: > And how does draft-wouters-tls-oob-pubkey differ from draft-ietf-tls-cached-info-09? cached-info still needs PKIX validation on the first run, and then supports caching the authentication. oob-pubkey allows for out of bound public key authentication with tls server suppressing the sending of its (often huge) unneeded PKIX chain. This avoids conflicting information (eg between DANE and PKIX), removes the need for (re)generating bogus PKIX containers with self signed certs and dozens of subjctAltnames and enables CoAP devices with are lacking the resources for PKIX do engage in TLS. Paul > Best regards, > Badra > > On Thu, Nov 17, 2011 at 8:47 AM, Eric Rescorla wrote: > Extending TLS to support a raw public key seems like a good idea and > I support taking it on. > > Extending it to suppress the public key and instead send a hash from server > to the client seems less so; if the server sends the public key, it works > if the client knows either (a) the server public key or (b) a digest of the > public key. Sending a digest only works if the client already knows the > public key, which seems far less likely. If you want to suppress the > server sending the key, a better (and more general) solution is to > resurrect cached-info. This would work with both raw keys and > certificates. > > -Ekr > > > On Mon, Oct 31, 2011 at 4:21 PM, Paul Wouters wrote: > > > > This is the new version of the draft incorporating the feedback from Quebec > > City > > and the TLS list since then. It changes the draft from a new TLS extension > > to a > > new Certificate Type for raw keys. > > > > It also merges in the unpublished draft material from Hannes Tschofenig > > and Tero Kivinen whom had also been working on raw RSA > > TLS keys for use with CoAP (eg devices with no real time clock where > > PKIX validation cannot work) > > > > I did not yet change the draft ofrom individual submission to working group > > item, > > as I was waiting for confirmation on the TLW WG list of the last Quebec City > > meeting. > > > > http://tools.ietf.org/html/draft-wouters-tls-oob-pubkey-01 > > > > Paul > > > > ---------- Forwarded message ---------- > > Date: Mon, 31 Oct 2011 17:44:35 > > From: internet-drafts@ietf.org > > Cc: weiler@tislabs.com, hannes.tschofenig@gmx.net, gnu@toad.com, > >    paul@xelerance.com, kivinen@iki.fi > > To: paul@xelerance.com > > Subject: New Version Notification for draft-wouters-tls-oob-pubkey-01.txt > > X-Spam-Flag: NO > > > > A new version of I-D, draft-wouters-tls-oob-pubkey-01.txt has been > > successfully submitted by Paul Wouters and posted to the IETF repository. > > > > Filename:        draft-wouters-tls-oob-pubkey > > Revision:        01 > > Title:           TLS out-of-band public key validation > > Creation date:   2011-10-31 > > WG ID:           Individual Submission > > Number of pages: 11 > > > > Abstract: > >   This document specifies a new TLS certificate type for exchanging raw > >   public keys or their fingerprints in Transport Layer Security (TLS) > >   and Datagram Transport Layer Security (DTLS) for use with out-of-band > >   authentication.  Currently, TLS authentication can only occur via > >   PKIX or OpenPGP certificates.  By specifying a minimum resource for > >   raw public key exchange, implementations can use alternative > >   authentication methods. > > > >   One such method is using DANE Resource Records secured by DNSSEC, > >   Another use case is to provide authentication functionality when used > >   with devices in a constrained environment that use whitelists and > >   blacklists, as is the case with sensors and other embedded devices > >   that are constrained by memory, computational, and communication > >   limitations where the usage of PKIX is not feasible. > > > >   The new certificate type specified can also be used to reduce the > >   latency of a TLS client that is already in possession of a validated > >   public key of the TLS server before it starts a (non-resumed) TLS > >   handshake. > > > > > > > > > > The IETF Secretariat > > _______________________________________________ > > 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 Nov 18 13:42:05 2011 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 9E3441F0C81 for ; Fri, 18 Nov 2011 13:42:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.131 X-Spam-Level: X-Spam-Status: No, score=-10.131 tagged_above=-999 required=5 tests=[AWL=0.118, 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 hpmSUGUM3JIe for ; Fri, 18 Nov 2011 13:42:05 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id C5D431F0C7D for ; Fri, 18 Nov 2011 13:42:04 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id pAILg1dQ021862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 18 Nov 2011 22:42:01 +0100 (MET) From: Martin Rex Message-Id: <201111182142.pAILg1Hd027980@fs4113.wdf.sap.corp> To: paul@xelerance.com (Paul Wouters) Date: Fri, 18 Nov 2011 22:42:01 +0100 (MET) In-Reply-To: from "Paul Wouters" at Nov 18, 11 04:06:02 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] New Version Notification for 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, 18 Nov 2011 21:42:05 -0000 Paul Wouters wrote: > > Badra wrote: > > > > And how does draft-wouters-tls-oob-pubkey differ from draft-ietf-tls-cached-info-09? > > cached-info still needs PKIX validation on the first run, and then > supports caching the authentication. oob-pubkey allows for out of > bound public key authentication with tls server suppressing the > sending of its (often huge) unneeded PKIX chain. > > This avoids conflicting information (eg between DANE and PKIX), > removes the need for (re)generating bogus PKIX containers with > self signed certs and dozens of subjctAltnames and enables CoAP > devices with are lacking the resources for PKIX do engage in TLS. I do not see this as an appropriate characterization. The use of X.509v1 self-signed certs as public key containers is pretty trivial and pretty common -- and it works with pretty much all of the installed base of TLS. A single X.509v1 self-signed cert means that there is *no* "PKIX Chain" and it also precludes PKIX validation (which is *NOT* required by TLS, btw.). For the servers purpose of sending it in the Certificate handshake message it is a simple blob of a few hundred bytes, so that is the most trivial part of the protocol. Parsing the subject key info from a X.509v1 cert is only marginally more difficult than parsing it from any other public key format, and doable with a pretty small code footprint. You don't need PKIX to do that. The general rule for TLS handshakes should be that a *real* negotiation ought to be performed in a fashion that the handshake will succeed in case there is a chance to make it succeed. Having one peer make optimistic false assumptions, fail the handshake and retry with a different assumption is a defect and should *NOT* be standardized. A TLS extension to the effect Client: "I assume I'm in possession of your key, don't send it" Server: "OK, I won't" would seem pretty strange. It should probably be something like: Client: "I assume your key is . If I'm right, you don't need to send it" which may result in two possible answer: (A1) Server: "You're wrong. I will send you my key." (A2) Server: "You're correct. I will omit it from the handshake." That is basically what the TLS caching extension intends to provide for existing elements of TLS protocol PDUs (e.g. server cert chain in the server's Certificate handshake message, certificate_authorities in the CertificateRequest handshake message). IMO it would be OK for any _new_ TLS extension to include caching in order to save network bandwidth on average. But what I seem to be hearing is "I want to not transfer this information inside the TLS protocol at all, because parsing this data is so notoriously difficult. But you *MUST* have a means to convey (and therefore parse) that data anyway, or it can not possibly work. Why would you want to turn in minuscule trivially solvable problem into a major and entirely undefined problem? -Martin From mbadra@gmail.com Fri Nov 18 14:24:30 2011 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 D5D7621F84DB for ; Fri, 18 Nov 2011 14:24:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 bCAhhpHNeO8B for ; Fri, 18 Nov 2011 14:24:30 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by ietfa.amsl.com (Postfix) with ESMTP id 4825821F84D8 for ; Fri, 18 Nov 2011 14:24:30 -0800 (PST) Received: by vbbfc26 with SMTP id fc26so740699vbb.31 for ; Fri, 18 Nov 2011 14:24:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SmZCRYTxB63j6gkusomFbh2cMTSogvlHz32sMuI3Vc0=; b=nL/0Xd9p0dlnG6D5gyYfc1rshD/AAXIcoqHz3rQ+VO0q4MkGfPAqG/+BZTekptKwPZ 9t9Ezz1l5pWuc9M84RNTmV3qc/CjfApVkxbhC2tmIFQC9aMSDE9ecgFXhRsKOdfz66Y2 FCveYWvOug6+yv+KhPmqhY15tNH1InBpp6ehs= MIME-Version: 1.0 Received: by 10.52.37.36 with SMTP id v4mr5434364vdj.61.1321655068629; Fri, 18 Nov 2011 14:24:28 -0800 (PST) Received: by 10.220.201.71 with HTTP; Fri, 18 Nov 2011 14:24:28 -0800 (PST) In-Reply-To: References: Date: Fri, 18 Nov 2011 23:24:28 +0100 Message-ID: From: Badra To: Paul Wouters Content-Type: multipart/alternative; boundary=20cf307812b2e19b4404b209cc28 Cc: tls@ietf.org Subject: Re: [TLS] New Version Notification for draft-wouters-tls-oob-pubkey-01.txt (fwd) 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, 18 Nov 2011 22:24:30 -0000 --20cf307812b2e19b4404b209cc28 Content-Type: text/plain; charset=ISO-8859-1 On Fri, Nov 18, 2011 at 10:06 PM, Paul Wouters wrote: > On Fri, 18 Nov 2011, Badra wrote: > > And how does draft-wouters-tls-oob-**pubkey differ >> from draft-ietf-tls-cached-**info-09? >> > > cached-info still needs PKIX validation on the first run, and then > supports caching > the authentication. oob-pubkey allows for out of bound public key > authentication > with tls server suppressing the sending of its (often huge) unneeded PKIX > chain. > And how, in your draft, will the client have a copy of server's authenticated key? Currently, the server doesn't need to describe known roots. Does it mean that the server also has a copy of the client's authenticated key? Best regards, Badra --20cf307812b2e19b4404b209cc28 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Fri, Nov 18, 2011 at 10:06 P= M, Paul Wouters <paul@xelerance.com> wrote:
On Fri, 18 Nov 2011, Badra wrote:

And how does=A0draft-wouters-tls-oob-pubkey differ from=A0draft-ietf= -tls-cached-info-09?

cached-info still needs PKIX validation on the first run, and then supports= caching
the authentication. oob-pubkey allows for out of bound public key authentic= ation
with tls server suppressing the sending of its (often huge) unneeded PKIX c= hain.


And how, in your d= raft, will the client have a copy of server's authenticated key?=A0

Currently, the server doesn't need to describe=A0known r= oots. Does it mean that the server also has a copy of the client's auth= enticated key?

Best regards,
Badra
--20cf307812b2e19b4404b209cc28-- From nico@cryptonector.com Fri Nov 18 14:35:31 2011 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 198F321F8AFB for ; Fri, 18 Nov 2011 14:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.192 X-Spam-Level: X-Spam-Status: No, score=-2.192 tagged_above=-999 required=5 tests=[AWL=-0.215, 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 Vx3GswavW9I1 for ; Fri, 18 Nov 2011 14:35:30 -0800 (PST) Received: from homiemail-a31.g.dreamhost.com (caiajhbdcaid.dreamhost.com [208.97.132.83]) by ietfa.amsl.com (Postfix) with ESMTP id 5103921F8AF9 for ; Fri, 18 Nov 2011 14:35:30 -0800 (PST) Received: from homiemail-a31.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTP id E2C6320202C for ; Fri, 18 Nov 2011 14:35:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=fC1vVZEHlgiOnUorJatHSz9aTx6fb/vOzQnkYzoB6WSW 0Ba0AJWF0anVZx99nw/CNwBTIqOsWOvjfutg01ufDV45ShFXb8Q9JpMv99lFfq5L FQH2eE5RfqbkUKDUKnoZkc7xQm0UJ2LPyqOuflZox1b8ck9BWRtl97BKLAkQb5M= 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:content-transfer-encoding; s= cryptonector.com; bh=6aFIFxQe/WBEjiXQRuI6+M4aVuU=; b=FWWHTQ2jgch IZ8r6n+XypFms9kFZgyalZB3UhC+ldb+z9MOeg1mB2bqQvWaiLJ1yK6AxyasaDjh gBmV3Z+toUImBPnmC9X3aZY/h6Aag/fRHu36/TFKOC1yhiV1CON6T1/XS2SZ+v4u F9j7HjMIojSxf9GsFAQx+T9D9CoSthbE= Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a31.g.dreamhost.com (Postfix) with ESMTPSA id DAD49202045 for ; Fri, 18 Nov 2011 14:34:58 -0800 (PST) Received: by ywt34 with SMTP id 34so3602534ywt.31 for ; Fri, 18 Nov 2011 14:34:57 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.10.138 with SMTP id i10mr8213061pbb.92.1321655697273; Fri, 18 Nov 2011 14:34:57 -0800 (PST) Received: by 10.68.192.70 with HTTP; Fri, 18 Nov 2011 14:34:57 -0800 (PST) In-Reply-To: References: Date: Fri, 18 Nov 2011 16:34:57 -0600 Message-ID: From: Nico Williams To: zhou.sujing@zte.com.cn Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: tls@ietf.org Subject: Re: [TLS] concers about draft-balfanz-tls-obc 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, 18 Nov 2011 22:35:31 -0000 On Fri, Nov 18, 2011 at 3:10 AM, wrote: > =C2=A0 =C2=A0I don't think the origin-bound-certificate is meaningful. > =C2=A0 =C2=A0The reasons are: > =C2=A0 =C2=A01. CA signed client certificate is used to authenticate the = client user, > now it is replaced by a self-signed certificate, how can a server trust o= r > authenticate a self confirmed user? It doesn't matter how the user is initially authenticated (password POSTed in forms, user certs, doesn't matter). As for the server, it will only inspect the OBC in order to verify that it is the certificate to which the cookies are bound. > =C2=A0 =C2=A02. If client authentication is not required, then there is n= either need > to send a self-signed certificate. Client authentication is orthogonal to OBC. OBC protects the session cookies from theft. Let's say you steal my session cookies somehow (e.g., via the BEAST attack): but if you don't have my OBCs' private keys then you can't actually make use of my cookies. With OBC cookie theft is not enough. With OBC the attacker must get at the private keys for the OBCs. Also, with OBC you get closer to true logout: destroy ("forget") your OBC private keys and your sessions are as good as dead. Moreover, the user-agent, not the server, is in control of maximum session lifetime, since there's no point in the server setting cookies that will outlive the OBCs. (The server can set cookie lifetimes shorter than OBC lifetimes, of course, but not longer, and that's what's valuable here to the user-agent.) > =C2=A0 =C2=A03. To the goal of bindling cookie with self-signed certifica= te, the > ordinary CA signed certificates also work. True, and the three users with commercial CA-issued certificates will not be affected. The non-snarky answer to this is above, in answer to (1). ******** Now, I've observed before, and will repeat here, that we could have a cookie-to-TLS-session cryptographic binding that doesn't require the use of any user certificates at all. But in the end the effect would be the same as with OBC, and the protocol design trade-offs in the two approaches are are such that OBC is probably the path of least resistance (specifically, binding to TLS sessions would effectively require session resumption without server-side state to be widely deployed). Therefore I am a fan of OBC. I expect OBC to happen, and it will improve web security significantly. Nico -- From paul@xelerance.com Fri Nov 18 15:20:11 2011 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 2E5EF21F8564 for ; Fri, 18 Nov 2011 15:20:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.427 X-Spam-Level: X-Spam-Status: No, score=-6.427 tagged_above=-999 required=5 tests=[AWL=0.172, 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 2oincouPx9zt for ; Fri, 18 Nov 2011 15:20:10 -0800 (PST) Received: from mx.xelerance.com (mx.xelerance.com [193.110.157.188]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3CB21F8562 for ; Fri, 18 Nov 2011 15:20:10 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mx.xelerance.com (Postfix) with ESMTP id B1CA311E; Fri, 18 Nov 2011 18:20:07 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=xelerance.com; h= content-transfer-encoding:content-type:content-type:mime-version :user-agent:references:message-id:in-reply-to:subject:subject :from:from:date:date:received:received:received:received; s= smtp; t=1321658406; x=1322263206; bh=g4O60RnY4+WqMUE+bhmmMmUbbOh TKKwXMt0cP6zy8dQ=; b=VUiLByn4501mJxQyuT8AWnPxUA96FQgCfCovTcM3Nj7 TYvj07eqhj3SyVSQY3H+N8XRUGo25JgRWpajTKdZcWscG5eX6SZ+0+6vAFZxokHm XwnyR5/a6ZqEDZwG6EwLHhOOiz076wofInbeyB9kRQptjEifMkNMZif9QHOUN7pE = Received: from mx.xelerance.com ([127.0.0.1]) by localhost (mx.xelerance.com [127.0.0.1]) (amavisd-new, port 10026) with LMTP id c2WMPe-9INjY; Fri, 18 Nov 2011 18:20:06 -0500 (EST) Received: from mail.xelerance.com (mail.xelerance.com [193.110.157.189]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.xelerance.com (Postfix) with ESMTPS id BC3B384; Fri, 18 Nov 2011 18:20:06 -0500 (EST) Received: by mail.xelerance.com (Postfix, from userid 1001) id A1C6650C; Fri, 18 Nov 2011 18:20:06 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by mail.xelerance.com (Postfix) with ESMTP id A0A35142; Fri, 18 Nov 2011 18:20:06 -0500 (EST) Date: Fri, 18 Nov 2011 18:20:06 -0500 (EST) From: Paul Wouters To: Badra In-Reply-To: Message-ID: References: User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Cc: tls@ietf.org Subject: Re: [TLS] New Version Notification for draft-wouters-tls-oob-pubkey-01.txt (fwd) 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, 18 Nov 2011 23:20:11 -0000 On Fri, 18 Nov 2011, Badra wrote: > And how does draft-wouters-tls-oob-pubkey differ from draft-ietf-tls-cached-info-09? > > cached-info still needs PKIX validation on the first run, and then supports caching > the authentication. oob-pubkey allows for out of bound public key authentication > with tls server suppressing the sending of its (often huge) unneeded PKIX chain. > > > > And how, in your draft, will the client have a copy of server's authenticated key?  The draft is called "out of band" for a reason :) One method is to get it via DANE/DNSSEC, for example: dig -t TYPE65468 _443._tcp.dane.xelerance.com That will give the client an authenticated hash of the public key. During the TLS handshake, the TLS server gives the TLS client its public key in the server certificate of cert_type "RawPublicKey". The DANE draft does not (yet) have a subtype for "raw key" but is expected to get one as soon as TLS defines the cert_type (which this draft would do) > Currently, the server doesn't need to describe known roots. Does it mean that the server also has a copy of the client's authenticated key? If the TLS server wants to authenticate the TLS client, it will also need and out-of-band authentication. The TLS client will send its public key in a certificate of cert_type="RawPublicKey" and the TLS server will have to lookup that key for authentication. (to make that easier on the server, perhaps we can think about the client version of "SNI", but we left that out of this draft not to complicate things at this stage) Paul From ynir@checkpoint.com Fri Nov 18 22:36:56 2011 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 0138421F8BAE for ; Fri, 18 Nov 2011 22:36:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.407 X-Spam-Level: X-Spam-Status: No, score=-10.407 tagged_above=-999 required=5 tests=[AWL=0.192, 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 GNPg0M5jmjTE for ; Fri, 18 Nov 2011 22:36:55 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 17BC721F8BAD for ; Fri, 18 Nov 2011 22:36:54 -0800 (PST) X-CheckPoint: {4EC74E19-0-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pAJ6aK1q013247; Sat, 19 Nov 2011 08:36:20 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 19 Nov 2011 08:36:20 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Sat, 19 Nov 2011 08:36:20 +0200 From: Yoav Nir To: Nikos Mavrogiannopoulos Date: Sat, 19 Nov 2011 08:36:19 +0200 Thread-Topic: [TLS] raw unofficial minutes: TLS WG: IETF-82 Taipei Thread-Index: AcymhYwWxpPb6PKyQrSoqPDwpMHpCg== Message-ID: <35895EB9-40FF-4E17-A579-82A94430334E@checkpoint.com> References: <4EC4F080.7080100@KingsMountain.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "tls@ietf.org" Subject: Re: [TLS] raw unofficial minutes: TLS WG: IETF-82 Taipei 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, 19 Nov 2011 06:36:56 -0000 On Nov 18, 2011, at 2:33 PM, Nikos Mavrogiannopoulos wrote: > On Fri, Nov 18, 2011 at 1:17 PM, Badra wrote: >=20 >>> sean (st): badra has IPR in his draft too -- need to consider that >> I am not a lawyer, but I think that draft-agl-tls-encryptedclientcerts-0= 0 >> and any other document - that proposes encrypting the client's certifica= te >> during the initial TLS handshake- are equally relevant to the same IPR. >=20 > I would be very surprised on something like that because client and > server certificate encryption was first(*) used in IKEv2 (RFC4306) > which predates the disclosed patents. >=20 > (*) to my knowledge. Protocols using this technique before that, might ex= ist. IKEv1 also encrypts the certificates in messages #5 and #6 of Main Mode, so= that takes us to 1998 for publication, and probably several years earlier = for drafts. Yoav From ynir@checkpoint.com Sat Nov 19 02:15:27 2011 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 99B6121F8A55 for ; Sat, 19 Nov 2011 02:15:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.409 X-Spam-Level: X-Spam-Status: No, score=-11.409 tagged_above=-999 required=5 tests=[AWL=1.190, BAYES_00=-2.599, GB_I_LETTER=-2, 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 6FC2zf5hzMyu for ; Sat, 19 Nov 2011 02:15:26 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 67A0521F8591 for ; Sat, 19 Nov 2011 02:15:26 -0800 (PST) X-CheckPoint: {4EC7814E-1-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pAJAFJYQ002023; Sat, 19 Nov 2011 12:15:23 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 19 Nov 2011 12:15:19 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Sat, 19 Nov 2011 12:15:19 +0200 From: Yoav Nir To: Adam Langley Date: Sat, 19 Nov 2011 12:15:17 +0200 Thread-Topic: [TLS] NextProtoNeg concerns Thread-Index: AcympCNFQSBzvpV9QZa1nAJfOx+nVw== Message-ID: References: <4F26370A-E4DA-4EDF-8D33-D77F2D9C89FB@checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "tls@ietf.org List" Subject: Re: [TLS] NextProtoNeg concerns 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, 19 Nov 2011 10:15:27 -0000 On Nov 18, 2011, at 2:32 PM, Adam Langley wrote: > On Fri, Nov 18, 2011 at 12:17 AM, Yoav Nir wrote: >> If you are defining a new extension/handshake message to carry a new kin= d of data (application type) there is no value to this without a definition= of the format, either in the same document or in a companion document. >=20 > I agree. The current, sparse form of the draft was simply intended to > omit details in order that the more salient points be obvious. >=20 > I would absolutely expect that any draft would end up specifying the > format of the messages; something like: >=20 > "Protocols are named by opaque, non-empty byte strings and the list of > protocols is serialized as a concatenation of 8-bit, length prefixed > byte strings. Implementations MUST ensure that the empty string is not > included and no byte strings are truncated." >=20 > "The NextProtocol message has the following format: >=20 > struct { > opaque selected_protocol<0..255>; > opaque padding<0..255>; > } NextProtocol; >=20 > The contents of selected_protocol are a protocol but need not have > been advertised by the server. The length of padding should be 32 - > ((len(selected_protocol) + 2) % 32). Note that len(selected_protocol) > does not include its length prefix." I would strongly prefer that it not say "opaque" but rather point to a regi= stry of strings, similar to the TLS exporter label registry http://www.iana.org/assignments/tls-parameters/tls-parameters.xml#exporter-= labels That does not have to mean that you need to publish an RFC for each label. = The label space is huge, even if we limit in to case-insensitive latin lett= ers plus numbers, slash, point, dash and colon, and up to 12 characters, it= still dwarfs the US national debt expressed in Taiwanese cents (assuming t= here is such a thing as a Taiwanese cent). So a registry like that could be= set up on a fcfs basis, with some reserved prefixes (priv-, exp-, com-comp= anyname-) that could be used without registration. Or maybe require a priv-= or exp- prefix for anything not specified at all, FCFS or expert review fo= r other prefixes, and standards action for things that don't have a prefix = (like "http/1.1", or "SSTP" if Microsoft chooses to document it) Yoav From ynir@checkpoint.com Sat Nov 19 02:46:53 2011 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 9774C21F8B48 for ; Sat, 19 Nov 2011 02:46:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.124 X-Spam-Level: X-Spam-Status: No, score=-10.124 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, J_CHICKENPOX_43=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 a8AymdTxw9Ue for ; Sat, 19 Nov 2011 02:46:53 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 8CB8D21F8B47 for ; Sat, 19 Nov 2011 02:46:52 -0800 (PST) X-CheckPoint: {4EC788AC-1-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pAJAklIt004891; Sat, 19 Nov 2011 12:46:47 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 19 Nov 2011 12:46:47 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Sat, 19 Nov 2011 12:46:47 +0200 From: Yoav Nir To: " " Date: Sat, 19 Nov 2011 12:46:45 +0200 Thread-Topic: [TLS] about the PWD Proposal Thread-Index: AcymqIipJMum0hlQRj23WRuZA3NYMw== Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "tls@ietf.org" Subject: Re: [TLS] about the PWD Proposal 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, 19 Nov 2011 10:46:53 -0000 Hi On Nov 18, 2011, at 9:59 AM, wrote: >=20 > Hi,=20 > I am interested in the PWD proposal at the meeting, and run through it(h= ttp://tools.ietf.org/html/draft-harkins-tls-pwd-01#section-3.4),=20 > and have the following concerns:=20 >=20 > 1. In the document, it says both Client and Server should be able to com= pute PE, which is derived from username, password, salt,etc.=20 > That means Client or the user should also remember the salt value, in = that case, salt is meaningless and can be replaced by a longer password.=20 > This is quite different from the widely known usage of salt, e.g. in U= NIX operating system, salt is not required to remember by the user, but by = server to fetch locally by reference to the username.=20 > And as far as I know, I am sure the authors also know that, other passw= ord based key exchanges protocols don't involve salt, but store a hash valu= e of password among other things locally.=20 I realize that this is very different from the usage in UNIX operating syst= ems, but it is necessary, as the UNIX (or other) operating system running t= he web server has to store the password. Storing the password in the clear = on as an unsalted hash is worse than storing a salted hash (or "base" in th= e draft's terminology), so that is what the TLS server does. The use of bas= e instead of password is not to protect the password during handshake, but = to protect it during storage on the server. Having said that, I think it is now very practical to take a list of the 10= 0,000 most popular passwords on the web, a database of 10,000 salted hashes= (the file described in section 3.4), and find all the matches. That's 1,00= 0,000,000 operations, which would take 15 minutes on a MacBook Air (1.4 GHz= ). I think the days of saying that a database of salted hashes makes theft = of the password file irrelevant should be over. Yes, I know that with unsal= ted hash it would be practical to test the 100,000,000 most popular passwor= ds.=20 >=20 > Sujing Zhou =20 > =20 > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail i= s solely property of the sender's organization. This mail communication is = confidential. Recipients named above are obligated to maintain secrecy and = are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intende= d solely for the use of the individual or entity to whom they are addressed= . If you have received this email in error please notify the originator of = the message. Any views expressed in this message are those of the individua= l sender. One more thing: I realize that the above line was probably inserted either = by your MUA or MTA, but it is not true. Email messages to IETF mailing list= s are considered contributions, and are subject to "Note Well" http://www.i= etf.org/about/note-well.html Yoav From ynir@checkpoint.com Sat Nov 19 03:15:44 2011 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 2026721F893C for ; Sat, 19 Nov 2011 03:15:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.425 X-Spam-Level: X-Spam-Status: No, score=-10.425 tagged_above=-999 required=5 tests=[AWL=0.174, 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 qU--+mNGswrz for ; Sat, 19 Nov 2011 03:15:43 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 32FF321F88B6 for ; Sat, 19 Nov 2011 03:15:42 -0800 (PST) X-CheckPoint: {4EC78F6F-0-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pAJBFYJ0007556; Sat, 19 Nov 2011 13:15:34 +0200 Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.3.213.0; Sat, 19 Nov 2011 13:15:34 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Sat, 19 Nov 2011 13:15:34 +0200 From: Yoav Nir To: Nico Williams Date: Sat, 19 Nov 2011 13:15:32 +0200 Thread-Topic: [TLS] concers about draft-balfanz-tls-obc Thread-Index: AcymrI3JPGVb4KJCQhCVm248ytoGug== Message-ID: <432A7B23-0128-4EAC-B9E3-1A4DB718D8DC@checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-KSE-AntiSpam-Interceptor-Info: protection disabled Cc: "tls@ietf.org" Subject: Re: [TLS] concers about draft-balfanz-tls-obc 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, 19 Nov 2011 11:15:44 -0000 On Nov 18, 2011, at 11:34 PM, Nico Williams wrote: >> 2. If client authentication is not required, then there is neither ne= ed >> to send a self-signed certificate. >=20 > Client authentication is orthogonal to OBC. >=20 > OBC protects the session cookies from theft. Let's say you steal my > session cookies somehow (e.g., via the BEAST attack): but if you don't > have my OBCs' private keys then you can't actually make use of my > cookies. >=20 > With OBC cookie theft is not enough. With OBC the attacker must get > at the private keys for the OBCs. >=20 > Also, with OBC you get closer to true logout: destroy ("forget") your > OBC private keys and your sessions are as good as dead. Moreover, the > user-agent, not the server, is in control of maximum session lifetime, > since there's no point in the server setting cookies that will outlive > the OBCs.=20 I we can find no other use case, we might want to rename it to "Origin Boun= d Cookie". But that would require some interesting interaction between layers.=20 Are all cookies received while using OBC considered (by the client!) bound = to the OBC? If not, the client might use an old cookie after a logout event= , leading to the server falsely detecting an attempt to forge a cookie. May= be we need a new keyword on the cookie header. Where is the "logout" button? If it's part of the website (in the "canvas"= ) how does the HTML/HTTP tell the browser to log out? Probably best to have= it in the Chrome for sites where OBC are supported. From nico@cryptonector.com Sat Nov 19 11:03:27 2011 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 3CF2221F85B1 for ; Sat, 19 Nov 2011 11:03:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=-0.213, 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 Of0wCi4f1tWX for ; Sat, 19 Nov 2011 11:03:26 -0800 (PST) Received: from homiemail-a85.g.dreamhost.com (caiajhbdcaib.dreamhost.com [208.97.132.81]) by ietfa.amsl.com (Postfix) with ESMTP id C72A821F85AE for ; Sat, 19 Nov 2011 11:03:26 -0800 (PST) Received: from homiemail-a85.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a85.g.dreamhost.com (Postfix) with ESMTP id 561D2BC041 for ; Sat, 19 Nov 2011 11:03:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=cryptonector.com; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc :content-type:content-transfer-encoding; q=dns; s= cryptonector.com; b=KS+rEqPvZznuP+EbkcnpMo0pM+yLRxXX9ZeAkWe/y2pK Q/CG3QIZn6jAIVYoAVSf7bFOG6R20pZ45JkHDthYMqe+7VQXNu6e/c8kOWHqGmA6 1bgGBzI1/9FPWHJDC89MrGt8yDPLTO4cLONviDE8fi9ePSXY70IQX13XF9MM84E= 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:content-transfer-encoding; s= cryptonector.com; bh=EyXt07Ekynkdhg7chuXhtFeGoaA=; b=aUjuoJ2T4mZ IueBXSOLmZ9j5QJhu5GneqzQzWYlCsJVFnPTX/vHBw7m4uGrPOtoQ3h/cu9ks9Ti oH/qwuTsCtOSaWKmYt/tzrN7/wU3Mf9480pmNRmRTYqWq9DaLPi0XUffNcSf7tHh tv/EG93UTJSm0H983WsB31KyKA5F3HDU= Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) (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 389B0BC040 for ; Sat, 19 Nov 2011 11:03:26 -0800 (PST) Received: by yenm7 with SMTP id m7so1130742yen.31 for ; Sat, 19 Nov 2011 11:03:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.30.68 with SMTP id q4mr15995171pbh.75.1321729405160; Sat, 19 Nov 2011 11:03:25 -0800 (PST) Received: by 10.68.192.70 with HTTP; Sat, 19 Nov 2011 11:03:25 -0800 (PST) In-Reply-To: <432A7B23-0128-4EAC-B9E3-1A4DB718D8DC@checkpoint.com> References: <432A7B23-0128-4EAC-B9E3-1A4DB718D8DC@checkpoint.com> Date: Sat, 19 Nov 2011 13:03:25 -0600 Message-ID: From: Nico Williams To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "tls@ietf.org" Subject: Re: [TLS] concers about draft-balfanz-tls-obc 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, 19 Nov 2011 19:03:27 -0000 On Sat, Nov 19, 2011 at 5:15 AM, Yoav Nir wrote: > On Nov 18, 2011, at 11:34 PM, Nico Williams wrote: > I we can find no other use case, we might want to rename it to "Origin Bo= und Cookie". The cookies are not bound to origins. They are bound to -effectively- sessions (I don't mean TLS sessions strictly speaking). So if you want to take "certificates" out of the name you'd have to take "origin" out also. > But that would require some interesting interaction between layers. OBC requires interaction between layers: the layer that sets and validates cookies must interact with the TLS layer. > Are all cookies received while using OBC considered (by the > client!) bound to the OBC? If not, the client might use an old The client has no way to verify the cookie bindings. Only the server can do that. The client has the power to make the cookie bindings (when they are bound) impossible to verify. > cookie after a logout event, leading to the server falsely > detecting an attempt to forge a cookie. Maybe we need a > new keyword on the cookie header. We may want -but don't strictly- need a way for servers to tell clients which cookies are bound and which aren't. The client can, of course, apply some heuristics, such as "secure-only cookies where the server supports OBC and we used OBC must be bound" and "all other cookies can't be bound or the binding isn't critical to the server". > Where is the "logout" button? =C2=A0If it's part of the website (in the "= canvas") how does the HTML/HTTP tell the browser to log out? Probably best = to have it in the Chrome for sites where OBC are supported. This needs more elaboration, clearly. What I said was that the client can enforce a logout (well, when the server really wants valid bound cookies). A logout that involves both, the client and the server will require some protocol work, but that wouldn't be strictly necessary (we manage today...). Nico -- From dharkins@lounge.org Sat Nov 19 12:13:27 2011 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 5983B21F84BA for ; Sat, 19 Nov 2011 12:13:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.882 X-Spam-Level: X-Spam-Status: No, score=-5.882 tagged_above=-999 required=5 tests=[AWL=-0.217, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_43=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 OC5mE4ybf87W for ; Sat, 19 Nov 2011 12:13:26 -0800 (PST) Received: from colo.trepanning.net (colo.trepanning.net [69.55.226.174]) by ietfa.amsl.com (Postfix) with ESMTP id 7130621F84B4 for ; Sat, 19 Nov 2011 12:13:26 -0800 (PST) Received: from www.trepanning.net (localhost [127.0.0.1]) by colo.trepanning.net (Postfix) with ESMTP id D201F20054; Sat, 19 Nov 2011 12:13:22 -0800 (PST) Received: from 69.12.173.8 (SquirrelMail authenticated user dharkins@lounge.org) by www.trepanning.net with HTTP; Sat, 19 Nov 2011 12:13:23 -0800 (PST) Message-ID: <1f90702381c4b1eb233430e28fb8fb47.squirrel@www.trepanning.net> In-Reply-To: References: Date: Sat, 19 Nov 2011 12:13:23 -0800 (PST) From: "Dan Harkins" To: zhou.sujing@zte.com.cn User-Agent: SquirrelMail/1.4.14 [SVN] MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: tls@ietf.org Subject: Re: [TLS] about the PWD Proposal 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, 19 Nov 2011 20:13:27 -0000 Hello, On Fri, November 18, 2011 12:59 am, zhou.sujing@zte.com.cn wrote: > Hi, > I am interested in the PWD proposal at the meeting, and run through > it(http://tools.ietf.org/html/draft-harkins-tls-pwd-01#section-3.4), > and have the following concerns: Thank you for your interest. > 1. In the document, it says both Client and Server should be able to > compute PE, which is derived from username, password, salt,etc. > That means Client or the user should also remember the salt value, in > that case, salt is meaningless and can be replaced by a longer password. > This is quite different from the widely known usage of salt, e.g. in > UNIX operating system, salt is not required to remember by the user, but > by server to fetch locally by reference to the username. > And as far as I know, I am sure the authors also know that, other > password based key exchanges protocols don't involve salt, but store a > hash value of password among other things locally. As Yoav mentioned, the salt is used to protect against server compromise. If the salt is chosen randomly by the server (as it should be) then an adversary who obtains possession of the database of salted passwords is required to effectively do an off-line dictionary attack against each entry in the database to recover passwords. The salt is not stored by the client, it is communicated to the client in the ServerKeyExchange. All the client needs to do is remember the password. > 2. From the figure in the PPT shown at the meeting, I cann't see why the > protocol should use both "private" and "mask" values, in my opinion, only > "mask " value shall be OK. > private value is redundent, and not helpful in security improvement. > because the current derived shared key is PE^{private_a*private_b} > according to this document£¬ and > after removing private value, it will be PE^{mask_a*mask_b} > and private, mask value are both generated locally and not transported > on the wire, so it does not make much difference except making it more > complex. The private value is used in the final exponentiation (or, equivalently, point multiplication) to derive the pre-master secret. Each private value is sent to the peer masked by modulo addition (which means that a passive attacker cannot guess the private since there are q different pairs of numbers that sum to any given number less than q and a probability of 1/q is effectively the same as guessing a DH exponential which we all assume is too hard). The mask is removed through modular multiplication (or equivalently, point addition) in a manner that prevents the disclosure of the private value. Private is definitely not redundant! > 3. Now I only talk about the security of the simplified version (as in > above point 2) > after simplification the protocol is easier to analysize, it is just > like an ordinary DH exchange except that the base group generator is PE > instead of g. > So the security is reduced to the PE, is it a good group generator > which has large order? if not then it is insecure. > Unfortunatly the authors failed to analysize this crucial point. An ordinary DH with PE as the generator is the SPEKE exchange. This is decidedly NOT an ordinary DH with PE as the generator. As mentioned above, both mask and private are crucial and such a "masked" exchange is not ordinary, PE as the generator notwithstanding. Please look at the exchange again in more detail. > Thank you for your patience! Thank you, again, for your interest! Perhaps you can implement it. :-) regards, Dan. From zhou.sujing@zte.com.cn Sun Nov 20 17:35:15 2011 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 67DFF21F85C7 for ; Sun, 20 Nov 2011 17:35:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.505 X-Spam-Level: X-Spam-Status: No, score=-94.505 tagged_above=-999 required=5 tests=[AWL=-4.404, BAYES_05=-1.11, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 uQzULzO0Ey7j for ; Sun, 20 Nov 2011 17:35:14 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id AE23621F85B1 for ; Sun, 20 Nov 2011 17:35:13 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 566901626001193; Mon, 21 Nov 2011 09:22:19 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 94152.3139085237; Mon, 21 Nov 2011 09:34:57 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id pAL1YtUr009727; Mon, 21 Nov 2011 09:34:55 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: <4EC6828F.5050301@gmail.com> To: Rene Struik , "Dan Harkins" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Mon, 21 Nov 2011 09:34:55 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-11-21 09:34:57, Serialize complete at 2011-11-21 09:34:57 Content-Type: multipart/alternative; boundary="=_alternative 0008B2734825794F_=" X-MAIL: mse02.zte.com.cn pAL1YtUr009727 Cc: tls@ietf.org Subject: [TLS] =?gb2312?b?tPC4tDogUmU6ICBhYm91dCB0aGUgUFdEIFByb3Bvc2Fs?= 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, 21 Nov 2011 01:35:15 -0000 This is a multipart message in MIME format. --=_alternative 0008B2734825794F_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksIFJlbmUgYW5kIERhbqOsDQoNCg0KUmVuZSBTdHJ1aWsgPHJzdHJ1aWsuZXh0QGdtYWlsLmNv bT4g0LTT2iAyMDExLTExLTE5IDAwOjA2OjM5Og0KDQo+IEhpIFN1amluZzoNCj4gDQo+IEkgZGlk IG5vdCBtYWtlIGl0IHRvIElFVEYtODIsIHNvIGFtIG5vdCBwcml2eSB0byB3aGF0IHdhcyBkaXNj dXNzZWQgDQo+IHdpdGggcmVzcGVjdCB0byB0aGlzIGRyYWZ0IGluIFRhaXBlaC4gRGFuIEhhcmtp bnMgd291bGQgYmUgaW4gdGhlIA0KPiBiZXN0IHBvc2l0aW9uIHRvIGFuc3dlciB5b3UuDQo+IA0K PiBTb21lIHF1aWNrIGFzc2Vzc21lbnQgb2YgbXkgb3duOg0KPiANCj4gIzEpIEluZGVlZCwgYmV0 dGVyIHRvIHNwcmlua2xlIGluIHNvbWUgc2FsdCB0aGF0IGRvZXMgbm90IGhhdmUgdG8gYmUNCj4g c3RvcmVkIChlLmcuLCBwcm90b2NvbC1yZWxhdGVkIG5vbmNlcywgZXRjLikuDQpEYW4gaGFzIG1h a2UgaXQgY2xlYXIgdGhhdCBzYWx0IGlzIHRyYW5zZmVyZWQgdG8gY2xpZW50IGZyb20gc2VydmVy LCBsaWtlIA0KYSAiY29uc3RhbnQiIGNoYWxsZW5nZS4NClRoZW4gbXkgZmlyc3QgcHJldmlvdXMg Y29uY2VybiBpcyBkaXNtaXNzZWQuIFRoYW5rIHlvdSBEYW4uDQoNCj4gDQo+ICMyKSBTb21lIHBl b3BsZSBzdWdnZXN0ZWQgdGhhdCB0aGlzIHBhcnRpY3VsYXIgInR3ZWFrIiB3YXMgbW90aXZhdGVk DQo+IGJ5IHRyeWluZyBhbmQgY2lyY3VtdmVudCBwYXRlbnQgY29uY2VybnMuDQoNClNvLCB0aGUg dHdlYWsgb25lIGlzIHRvIGNpcmN1bXZlbnQgcGF0ZW50PyB0aGVuIEkgY2FuIHVuZGVyc3RhbmQs IA0KYnV0IGluIG15IHBlcnNvbmFsIG9waW5pb24gYSBzdGFuZGFyZC10by1iZSBwcm9wb3NhbCBp cyBiZXR0ZXIgdG8gYmUgDQplbGVnYW50IGFuZCBzaW1wbGUsIGhlaGUgOikNCg0KDQo+IA0KPiAj MykgaWYgRyBpcyBhIGdlbmVyYXRvciBvZiB0aGUgcHJpbWUgb3JkZXIgc3ViZ3JvdXAgb2YgdGhl IGN1cnZlIGFuZA0KPiBHcCBpcyBhbm90aGVyIG9uZSwgdGhlbiBlaXRoZXIgaGFzIHRoZSBzYW1l IHByaW1lIG9yZGVyIHNob3VsZCBiZSANCj4gZmluZSBmb3IgZXhlY3V0aW5nIHRoZSBESCBwcm90 b2NvbC4NClRoYW5rIERhbiBmb3IgaW50cm9kdWNpbmcgU1BFS0UgdG8gbWUsSSBkaWRuJ3Qga25v dyB0aGUgZGV0YWlsIG9mIFNQRUtFLg0KUmVuZSwgeW91IGFyZSByaWdodCBpbiByZWdhcmQgdG8g c2VsZWN0aW5nIGEgZ2VuZXJhdGlyIEcgb3IgR3AgZm9yIA0KZXhlY3V0aW5nIERIIHByb3RvY29s Lg0KSSBub3RpY2UgdGhhdCB0aGVyZSBpcyBzcGVjaWZpY2F0aW9uIG9mIGhvdyAgdG8gZW5zdXJl IHRoZSByZXN1bHRpbmcgUEUgdG8gDQpiZSBhIHN1aXRhYmxlIERIIGJhc2UgaW4gdGhlIGRvY3Vt ZW50Og0KImh1bnRpbmcgYW5kIHBlY2tpbmciIGJ5IHRyeWluZyBkaWZmZXJlbnQgY291bnRlci4N ClNvIG15IHRoaXJkIGNvbmNlcm4gaXMgZ29uZS4gDQpUaGUgb25seSBjb25jZXJuIGxlZnQgaXMg ZWZmaWNpZW5jZSBpbiBwcm9kdWNpbmcgYSBzdWl0YWJsZSBQRS4NCg0KQmVzdCByZWdhcmRzLg0K DQo+IEJlc3QgcmVnYXJkcywgUmVuZQ0KPiANCj4gPT0NCj4gDQo+IDMuIE5vdyBJIG9ubHkgdGFs ayBhYm91dCB0aGUgc2VjdXJpdHkgb2YgdGhlIHNpbXBsaWZpZWQgdmVyc2lvbiAoYXMgDQo+IGlu IGFib3ZlIHBvaW50IDIpIA0KPiAgICBhZnRlciBzaW1wbGlmaWNhdGlvbiB0aGUgcHJvdG9jb2wg aXMgZWFzaWVyIHRvIGFuYWx5c2l6ZSwgaXQgaXMgDQo+IGp1c3QgbGlrZSBhbiBvcmRpbmFyeSBE SCBleGNoYW5nZSBleGNlcHQgdGhhdCB0aGUgYmFzZSBncm91cCANCj4gZ2VuZXJhdG9yIGlzIFBF IGluc3RlYWQgb2YgZy4gDQo+ICAgIFNvIHRoZSBzZWN1cml0eSBpcyByZWR1Y2VkIHRvIHRoZSBQ RSwgaXMgaXQgYSBnb29kIGdyb3VwIA0KPiBnZW5lcmF0b3Igd2hpY2ggaGFzIGxhcmdlIG9yZGVy PyBpZiBub3QgdGhlbiBpdCBpcyBpbnNlY3VyZS4gDQo+ICAgIFVuZm9ydHVuYXRseSB0aGUgYXV0 aG9ycyBmYWlsZWQgdG8gYW5hbHlzaXplIHRoaXMgY3J1Y2lhbCBwb2ludC4gDQo+IA0KPiBPbiAx OC8xMS8yMDExIDM6NTkgQU0sIHpob3Uuc3VqaW5nQHp0ZS5jb20uY24gd3JvdGU6IA0KPiANCj4g SGksIA0KPiAgSSBhbSBpbnRlcmVzdGVkIGluIHRoZSBQV0QgcHJvcG9zYWwgYXQgdGhlIG1lZXRp bmcsIGFuZCBydW4gdGhyb3VnaCBpdCgNCj4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh ZnQtaGFya2lucy10bHMtcHdkLTAxI3NlY3Rpb24tMy40KSwgDQo+ICBhbmQgaGF2ZSB0aGUgZm9s bG93aW5nIGNvbmNlcm5zOiANCj4gDQo+IDEuIEluIHRoZSBkb2N1bWVudCwgaXQgIHNheXMgYm90 aCBDbGllbnQgYW5kIFNlcnZlciBzaG91bGQgYmUgYWJsZSANCj4gdG8gY29tcHV0ZSBQRSwgd2hp Y2ggaXMgZGVyaXZlZCBmcm9tIHVzZXJuYW1lLCBwYXNzd29yZCwgc2FsdCxldGMuIA0KPiAgICBU aGF0IG1lYW5zIENsaWVudCBvciB0aGUgdXNlciBzaG91bGQgYWxzbyByZW1lbWJlciB0aGUgc2Fs dCANCj4gdmFsdWUsIGluIHRoYXQgY2FzZSwgc2FsdCBpcyBtZWFuaW5nbGVzcyBhbmQgY2FuIGJl IHJlcGxhY2VkIGJ5IGEgDQo+IGxvbmdlciBwYXNzd29yZC4gDQo+ICAgIFRoaXMgaXMgcXVpdGUg ZGlmZmVyZW50IGZyb20gdGhlIHdpZGVseSBrbm93biB1c2FnZSBvZiBzYWx0LCBlLmcuDQo+IGlu IFVOSVggb3BlcmF0aW5nIHN5c3RlbSwgc2FsdCBpcyBub3QgcmVxdWlyZWQgdG8gcmVtZW1iZXIg YnkgdGhlIA0KPiB1c2VyLCBidXQgYnkgc2VydmVyIHRvIGZldGNoIGxvY2FsbHkgYnkgcmVmZXJl bmNlIHRvIHRoZSB1c2VybmFtZS4gDQo+ICAgQW5kIGFzIGZhciBhcyBJIGtub3csIEkgYW0gc3Vy ZSB0aGUgYXV0aG9ycyBhbHNvIGtub3cgdGhhdCwgb3RoZXIgDQo+IHBhc3N3b3JkIGJhc2VkIGtl eSBleGNoYW5nZXMgcHJvdG9jb2xzIGRvbid0IGludm9sdmUgc2FsdCwgYnV0IHN0b3JlDQo+IGEg aGFzaCB2YWx1ZSBvZiBwYXNzd29yZCBhbW9uZyBvdGhlciB0aGluZ3MgbG9jYWxseS4gDQo+IDIu IEZyb20gdGhlIGZpZ3VyZSBpbiB0aGUgUFBUIHNob3duIGF0IHRoZSBtZWV0aW5nLCBJIGNhbm4n dCBzZWUgd2h5DQo+IHRoZSBwcm90b2NvbCBzaG91bGQgdXNlIGJvdGggInByaXZhdGUiIGFuZCAi bWFzayIgdmFsdWVzLCBpbiBteSANCj4gb3Bpbmlvbiwgb25seSAibWFzayAiIHZhbHVlIHNoYWxs IGJlIE9LLiANCj4gICAgcHJpdmF0ZSB2YWx1ZSBpcyByZWR1bmRlbnQsIGFuZCBub3QgaGVscGZ1 bCBpbiBzZWN1cml0eSBpbXByb3ZlbWVudC4gDQo+ICAgIGJlY2F1c2UgdGhlIGN1cnJlbnQgZGVy aXZlZCBzaGFyZWQga2V5IGlzIA0KPiBQRV57cHJpdmF0ZV9hKnByaXZhdGVfYn0gIGFjY29yZGlu ZyB0byB0aGlzIGRvY3VtZW50o6wgYW5kIA0KPiAgICBhZnRlciByZW1vdmluZyBwcml2YXRlIHZh bHVlLCBpdCB3aWxsIGJlICBQRV57bWFza19hKm1hc2tfYn0gDQo+ICAgIGFuZCBwcml2YXRlLCBt YXNrIHZhbHVlIGFyZSBib3RoIGdlbmVyYXRlZCBsb2NhbGx5IGFuZCBub3QgDQo+IHRyYW5zcG9y dGVkICBvbiB0aGUgd2lyZSwgc28gaXQgZG9lcyBub3QgbWFrZSBtdWNoIGRpZmZlcmVuY2UgZXhj ZXB0DQo+IG1ha2luZyBpdCBtb3JlIGNvbXBsZXguIA0KPiAzLiBOb3cgSSBvbmx5IHRhbGsgYWJv dXQgdGhlIHNlY3VyaXR5IG9mIHRoZSBzaW1wbGlmaWVkIHZlcnNpb24gKGFzIA0KPiBpbiBhYm92 ZSBwb2ludCAyKSANCj4gICAgYWZ0ZXIgc2ltcGxpZmljYXRpb24gdGhlIHByb3RvY29sIGlzIGVh c2llciB0byBhbmFseXNpemUsIGl0IGlzIA0KPiBqdXN0IGxpa2UgYW4gb3JkaW5hcnkgREggZXhj aGFuZ2UgZXhjZXB0IHRoYXQgdGhlIGJhc2UgZ3JvdXAgDQo+IGdlbmVyYXRvciBpcyBQRSBpbnN0 ZWFkIG9mIGcuIA0KPiAgICBTbyB0aGUgc2VjdXJpdHkgaXMgcmVkdWNlZCB0byB0aGUgUEUsIGlz IGl0IGEgZ29vZCBncm91cCANCj4gZ2VuZXJhdG9yIHdoaWNoIGhhcyBsYXJnZSBvcmRlcj8gaWYg bm90IHRoZW4gaXQgaXMgaW5zZWN1cmUuIA0KPiAgICBVbmZvcnR1bmF0bHkgdGhlIGF1dGhvcnMg ZmFpbGVkIHRvIGFuYWx5c2l6ZSB0aGlzIGNydWNpYWwgcG9pbnQuIA0KPiANCj4gVGhhbmsgeW91 IGZvciB5b3VyIHBhdGllbmNlISANCj4gDQo+IFN1amluZyBaaG91IA0KPiANCj4gLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gWlRFIElu Zm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0 aGlzIA0KPiBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0 aW9uLiBUaGlzIG1haWwgDQo+IGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGll bnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgDQo+IHRvIG1haW50YWluIHNlY3JlY3kgYW5k IGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyANCj4gb2YgdGhpcyBj b21tdW5pY2F0aW9uIHRvIG90aGVycy4NCj4gVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5z bWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgDQo+IGludGVuZGVkIHNvbGVseSBm b3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5DQo+IGFy ZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxl YXNlIA0KPiBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBl eHByZXNzZWQgaW4gdGhpcyANCj4gbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwg c2VuZGVyLg0KPiBUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQg U3BhbSBieSBaVEUgQW50aS1TcGFtIA0Kc3lzdGVtLg0KDQo+IA0KDQo+IF9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFRMUyBtYWlsaW5nIGxpc3QNCj4g VExTQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxz DQoNCj4gDQoNCj4gLS0gDQo+IGVtYWlsOiByc3RydWlrLmV4dEBnbWFpbC5jb20NCj4gU2t5cGU6 IHJzdHJ1aWsNCj4gY2VsbDogKzEgKDY0NykgODY3LTU2NTgNCj4gVVNBIEdvb2dsZSB2b2ljZTog KzEgKDQxNSkgNjkwLTczNjMNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTog VGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5 IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlz IGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1h aW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250 ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55 IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQg c29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRo ZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJv ciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3Mg ZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2Vu ZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0g YnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 0008B2734825794F_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLCBSZW5lIGFuZCBEYW6jrDwv Zm9udD4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPlJlbmUgU3RydWlrICZsdDty c3RydWlrLmV4dEBnbWFpbC5jb20mZ3Q7INC009ogMjAxMS0xMS0xOQ0KMDA6MDY6Mzk6PGJyPg0K PGJyPg0KJmd0OyBIaSBTdWppbmc6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgZGlkIG5vdCBtYWtl IGl0IHRvIElFVEYtODIsIHNvIGFtIG5vdCBwcml2eSB0byB3aGF0IHdhcyBkaXNjdXNzZWQNCjxi cj4NCiZndDsgd2l0aCByZXNwZWN0IHRvIHRoaXMgZHJhZnQgaW4gVGFpcGVoLiBEYW4gSGFya2lu cyB3b3VsZCBiZSBpbiB0aGUNCjxicj4NCiZndDsgYmVzdCBwb3NpdGlvbiB0byBhbnN3ZXIgeW91 Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBTb21lIHF1aWNrIGFzc2Vzc21lbnQgb2YgbXkgb3duOjxi cj4NCiZndDsgPGJyPg0KJmd0OyAjMSkgSW5kZWVkLCBiZXR0ZXIgdG8gc3ByaW5rbGUgaW4gc29t ZSBzYWx0IHRoYXQgZG9lcyBub3QgaGF2ZSB0bw0KYmU8YnI+DQomZ3Q7IHN0b3JlZCAoZS5nLiwg cHJvdG9jb2wtcmVsYXRlZCBub25jZXMsIGV0Yy4pLjxicj4NCkRhbiBoYXMgbWFrZSBpdCBjbGVh ciB0aGF0IHNhbHQgaXMgdHJhbnNmZXJlZCB0byBjbGllbnQgZnJvbSBzZXJ2ZXIsIGxpa2UNCmEg JnF1b3Q7Y29uc3RhbnQmcXVvdDsgY2hhbGxlbmdlLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+VGhlbiBteSBmaXJzdCBwcmV2aW91cyBjb25jZXJuIGlzIGRpc21pc3NlZC4gVGhh bmsNCnlvdSBEYW4uPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7 IDxicj4NCiZndDsgIzIpIFNvbWUgcGVvcGxlIHN1Z2dlc3RlZCB0aGF0IHRoaXMgcGFydGljdWxh ciAmcXVvdDt0d2VhayZxdW90OyB3YXMNCm1vdGl2YXRlZDxicj4NCiZndDsgYnkgdHJ5aW5nIGFu ZCBjaXJjdW12ZW50IHBhdGVudCBjb25jZXJucy48YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPlNvLCB0aGUgdHdlYWsgb25lIGlzIHRvIGNpcmN1bXZlbnQgcGF0ZW50PyB0 aGVuIEkNCmNhbiB1bmRlcnN0YW5kLCA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PmJ1dCBpbiBteSBwZXJzb25hbCBvcGluaW9uIGEgc3RhbmRhcmQtdG8tYmUgcHJvcG9zYWwNCmlz IGJldHRlciB0byBiZSBlbGVnYW50IGFuZCBzaW1wbGUsIGhlaGUgOik8L2ZvbnQ+PC90dD4NCjxi cj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAjMykgaWYgRyBp cyBhIGdlbmVyYXRvciBvZiB0aGUgcHJpbWUgb3JkZXIgc3ViZ3JvdXAgb2YgdGhlIGN1cnZlIGFu ZDxicj4NCiZndDsgR3AgaXMgYW5vdGhlciBvbmUsIHRoZW4gZWl0aGVyIGhhcyB0aGUgc2FtZSBw cmltZSBvcmRlciBzaG91bGQgYmUNCjxicj4NCiZndDsgZmluZSBmb3IgZXhlY3V0aW5nIHRoZSBE SCBwcm90b2NvbC48YnI+DQpUaGFuayBEYW4gZm9yIGludHJvZHVjaW5nIFNQRUtFIHRvIG1lLEkg ZGlkbid0IGtub3cgdGhlIGRldGFpbCBvZiBTUEVLRS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPlJlbmUsIHlvdSBhcmUgcmlnaHQgaW4gcmVnYXJkIHRvIHNlbGVjdGluZyBhIGdl bmVyYXRpcg0KRyBvciBHcCBmb3IgZXhlY3V0aW5nIERIIHByb3RvY29sLjwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+SSBub3RpY2UgdGhhdCB0aGVyZSBpcyBzcGVjaWZpY2F0aW9u IG9mIGhvdyAmbmJzcDt0bw0KZW5zdXJlIHRoZSByZXN1bHRpbmcgUEUgdG8gYmUgYSBzdWl0YWJs ZSBESCBiYXNlIGluIHRoZSBkb2N1bWVudDo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZxdW90O2h1bnRpbmcgYW5kIHBlY2tpbmcmcXVvdDsgYnkgdHJ5aW5nIGRpZmZlcmVudA0K Y291bnRlci48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPlNvIG15IHRoaXJkIGNv bmNlcm4gaXMgZ29uZS4gPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5UaGUgb25s eSBjb25jZXJuIGxlZnQgaXMgZWZmaWNpZW5jZSBpbiBwcm9kdWNpbmcgYQ0Kc3VpdGFibGUgUEUu PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5CZXN0IHJlZ2FyZHMuPC9m b250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IEJlc3QgcmVnYXJkcywg UmVuZTxicj4NCiZndDsgPGJyPg0KJmd0OyA9PTxicj4NCiZndDsgPGJyPg0KJmd0OyAzLiBOb3cg SSBvbmx5IHRhbGsgYWJvdXQgdGhlIHNlY3VyaXR5IG9mIHRoZSBzaW1wbGlmaWVkIHZlcnNpb24g KGFzDQo8YnI+DQomZ3Q7IGluIGFib3ZlIHBvaW50IDIpIDxicj4NCiZndDsgJm5ic3A7ICZuYnNw O2FmdGVyIHNpbXBsaWZpY2F0aW9uIHRoZSBwcm90b2NvbCBpcyBlYXNpZXIgdG8gYW5hbHlzaXpl LA0KaXQgaXMgPGJyPg0KJmd0OyBqdXN0IGxpa2UgYW4gb3JkaW5hcnkgREggZXhjaGFuZ2UgZXhj ZXB0IHRoYXQgdGhlIGJhc2UgZ3JvdXAgPGJyPg0KJmd0OyBnZW5lcmF0b3IgaXMgUEUgaW5zdGVh ZCBvZiBnLiA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtTbyB0aGUgc2VjdXJpdHkgaXMgcmVkdWNl ZCB0byB0aGUgUEUsIGlzIGl0IGEgZ29vZCBncm91cA0KPGJyPg0KJmd0OyBnZW5lcmF0b3Igd2hp Y2ggaGFzIGxhcmdlIG9yZGVyPyBpZiBub3QgdGhlbiBpdCBpcyBpbnNlY3VyZS4gPGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7VW5mb3J0dW5hdGx5IHRoZSBhdXRob3JzIGZhaWxlZCB0byBhbmFseXNp emUgdGhpcyBjcnVjaWFsDQpwb2ludC4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IE9uIDE4LzExLzIw MTEgMzo1OSBBTSwgemhvdS5zdWppbmdAenRlLmNvbS5jbiB3cm90ZTogPC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgSGksIDxicj4NCiZndDsgJm5ic3A7 SSBhbSBpbnRlcmVzdGVkIGluIHRoZSBQV0QgcHJvcG9zYWwgYXQgdGhlIG1lZXRpbmcsIGFuZCBy dW4NCnRocm91Z2ggaXQoPGJyPg0KJmd0OyBodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1oYXJraW5zLXRscy1wd2QtMDEjc2VjdGlvbi0zLjQpLA0KPGJyPg0KJmd0OyAmbmJzcDthbmQg aGF2ZSB0aGUgZm9sbG93aW5nIGNvbmNlcm5zOiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgMS4gSW4g dGhlIGRvY3VtZW50LCBpdCAmbmJzcDtzYXlzIGJvdGggQ2xpZW50IGFuZCBTZXJ2ZXIgc2hvdWxk IGJlDQphYmxlIDxicj4NCiZndDsgdG8gY29tcHV0ZSBQRSwgd2hpY2ggaXMgZGVyaXZlZCBmcm9t IHVzZXJuYW1lLCBwYXNzd29yZCwgc2FsdCxldGMuDQo8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtU aGF0IG1lYW5zIENsaWVudCBvciB0aGUgdXNlciBzaG91bGQgYWxzbyByZW1lbWJlciB0aGUNCnNh bHQgPGJyPg0KJmd0OyB2YWx1ZSwgaW4gdGhhdCBjYXNlLCBzYWx0IGlzIG1lYW5pbmdsZXNzIGFu ZCBjYW4gYmUgcmVwbGFjZWQgYnkgYQ0KPGJyPg0KJmd0OyBsb25nZXIgcGFzc3dvcmQuIDxicj4N CiZndDsgJm5ic3A7ICZuYnNwO1RoaXMgaXMgcXVpdGUgZGlmZmVyZW50IGZyb20gdGhlIHdpZGVs eSBrbm93biB1c2FnZSBvZg0Kc2FsdCwgZS5nLjxicj4NCiZndDsgaW4gVU5JWCBvcGVyYXRpbmcg c3lzdGVtLCBzYWx0IGlzIG5vdCByZXF1aXJlZCB0byByZW1lbWJlciBieSB0aGUNCjxicj4NCiZn dDsgdXNlciwgYnV0IGJ5IHNlcnZlciB0byBmZXRjaCBsb2NhbGx5IGJ5IHJlZmVyZW5jZSB0byB0 aGUgdXNlcm5hbWUuDQo8YnI+DQomZ3Q7ICZuYnNwOyBBbmQgYXMgZmFyIGFzIEkga25vdywgSSBh bSBzdXJlIHRoZSBhdXRob3JzIGFsc28ga25vdyB0aGF0LA0Kb3RoZXIgPGJyPg0KJmd0OyBwYXNz d29yZCBiYXNlZCBrZXkgZXhjaGFuZ2VzIHByb3RvY29scyBkb24ndCBpbnZvbHZlIHNhbHQsIGJ1 dCBzdG9yZTxicj4NCiZndDsgYSBoYXNoIHZhbHVlIG9mIHBhc3N3b3JkIGFtb25nIG90aGVyIHRo aW5ncyBsb2NhbGx5LiA8YnI+DQomZ3Q7IDIuIEZyb20gdGhlIGZpZ3VyZSBpbiB0aGUgUFBUIHNo b3duIGF0IHRoZSBtZWV0aW5nLCBJIGNhbm4ndCBzZWUgd2h5PGJyPg0KJmd0OyB0aGUgcHJvdG9j b2wgc2hvdWxkIHVzZSBib3RoICZxdW90O3ByaXZhdGUmcXVvdDsgYW5kICZxdW90O21hc2smcXVv dDsNCnZhbHVlcywgaW4gbXkgPGJyPg0KJmd0OyBvcGluaW9uLCBvbmx5ICZxdW90O21hc2sgJnF1 b3Q7IHZhbHVlIHNoYWxsIGJlIE9LLiA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtwcml2YXRlIHZh bHVlIGlzIHJlZHVuZGVudCwgYW5kIG5vdCBoZWxwZnVsIGluIHNlY3VyaXR5DQppbXByb3ZlbWVu dC4gPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7YmVjYXVzZSB0aGUgY3VycmVudCBkZXJpdmVkIHNo YXJlZCBrZXkgaXMgPGJyPg0KJmd0OyBQRV57cHJpdmF0ZV9hKnByaXZhdGVfYn0gJm5ic3A7YWNj b3JkaW5nIHRvIHRoaXMgZG9jdW1lbnSjrCBhbmQgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7YWZ0 ZXIgcmVtb3ZpbmcgcHJpdmF0ZSB2YWx1ZSwgaXQgd2lsbCBiZSAmbmJzcDtQRV57bWFza19hKm1h c2tfYn0NCjxicj4NCiZndDsgJm5ic3A7ICZuYnNwO2FuZCBwcml2YXRlLCBtYXNrIHZhbHVlIGFy ZSBib3RoIGdlbmVyYXRlZCBsb2NhbGx5IGFuZA0Kbm90IDxicj4NCiZndDsgdHJhbnNwb3J0ZWQg Jm5ic3A7b24gdGhlIHdpcmUsIHNvIGl0IGRvZXMgbm90IG1ha2UgbXVjaCBkaWZmZXJlbmNlDQpl eGNlcHQ8YnI+DQomZ3Q7IG1ha2luZyBpdCBtb3JlIGNvbXBsZXguIDxicj4NCiZndDsgMy4gTm93 IEkgb25seSB0YWxrIGFib3V0IHRoZSBzZWN1cml0eSBvZiB0aGUgc2ltcGxpZmllZCB2ZXJzaW9u IChhcw0KPGJyPg0KJmd0OyBpbiBhYm92ZSBwb2ludCAyKSA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJz cDthZnRlciBzaW1wbGlmaWNhdGlvbiB0aGUgcHJvdG9jb2wgaXMgZWFzaWVyIHRvIGFuYWx5c2l6 ZSwNCml0IGlzIDxicj4NCiZndDsganVzdCBsaWtlIGFuIG9yZGluYXJ5IERIIGV4Y2hhbmdlIGV4 Y2VwdCB0aGF0IHRoZSBiYXNlIGdyb3VwIDxicj4NCiZndDsgZ2VuZXJhdG9yIGlzIFBFIGluc3Rl YWQgb2YgZy4gPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7U28gdGhlIHNlY3VyaXR5IGlzIHJlZHVj ZWQgdG8gdGhlIFBFLCBpcyBpdCBhIGdvb2QgZ3JvdXANCjxicj4NCiZndDsgZ2VuZXJhdG9yIHdo aWNoIGhhcyBsYXJnZSBvcmRlcj8gaWYgbm90IHRoZW4gaXQgaXMgaW5zZWN1cmUuIDxicj4NCiZn dDsgJm5ic3A7ICZuYnNwO1VuZm9ydHVuYXRseSB0aGUgYXV0aG9ycyBmYWlsZWQgdG8gYW5hbHlz aXplIHRoaXMgY3J1Y2lhbA0KcG9pbnQuIDxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGFuayB5b3Ug Zm9yIHlvdXIgcGF0aWVuY2UhIDxicj4NCiZndDsgPGJyPg0KJmd0OyBTdWppbmcgWmhvdSAmbmJz cDsgPGJyPg0KJmd0OyAmbmJzcDsgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m Z3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tPGJyPg0KJmd0OyBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3Jt YXRpb24gY29udGFpbmVkIGluIHRoaXMNCjxicj4NCiZndDsgbWFpbCBpcyBzb2xlbHkgcHJvcGVy dHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIDxicj4NCiZndDsgY29t bXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9i bGlnYXRlZA0KPGJyPg0KJmd0OyB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1p dHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMNCjxicj4NCiZndDsgb2YgdGhpcyBjb21tdW5p Y2F0aW9uIHRvIG90aGVycy48YnI+DQomZ3Q7IFRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFu c21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kDQo8YnI+DQomZ3Q7IGludGVuZGVk IHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0 aGV5PGJyPg0KJmd0OyBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVt YWlsIGluIGVycm9yIHBsZWFzZSA8YnI+DQomZ3Q7IG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0 aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzDQo8YnI+DQomZ3Q7IG1lc3Nh Z2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci48YnI+DQomZ3Q7IFRoaXMgbWVz c2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNw YW0NCnN5c3RlbS48YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg PGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBUTFMgbWFpbGlu ZyBsaXN0PGJyPg0KJmd0OyBUTFNAaWV0Zi5vcmc8YnI+DQomZ3Q7IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vdGxzPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7IDxicj4NCjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0 OyAtLSA8YnI+DQomZ3Q7IGVtYWlsOiByc3RydWlrLmV4dEBnbWFpbC5jb208YnI+DQomZ3Q7IFNr eXBlOiByc3RydWlrPGJyPg0KJmd0OyBjZWxsOiArMSAoNjQ3KSA4NjctNTY1ODxicj4NCiZndDsg VVNBIEdvb2dsZSB2b2ljZTogKzEgKDQxNSkgNjkwLTczNjM8L2ZvbnQ+PC90dD4NCjxicj48cHJl Pg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7 VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJz cDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhl Jm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJz cDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50 cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZu YnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNw O3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZu YnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4N ClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNt aXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDth bmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZu YnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7 dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZu YnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNw O2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmln aW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdz Jm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZu YnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0K VGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2Zv ciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtB bnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 0008B2734825794F_=-- From yaronf.ietf@gmail.com Mon Nov 21 14:16:12 2011 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 2849D21F8ABD for ; Mon, 21 Nov 2011 14:16:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.999 X-Spam-Level: X-Spam-Status: No, score=-102.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_LOW=-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 GIfTmRQvY5yb for ; Mon, 21 Nov 2011 14:16:08 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id CB74421F8880 for ; Mon, 21 Nov 2011 14:16:07 -0800 (PST) Received: by bkbzv15 with SMTP id zv15so8149578bkb.31 for ; Mon, 21 Nov 2011 14:16:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=HgNQTzaw3j08uFQIOgeEVSzf3ttRwE1rqk2DIwXEtTk=; b=MXuQEznYq4a3/Iz9aCkaA87/IqlbNz34krvks9ZoqHhmtno15Nv1Dc20J7RrWZtITo fdyhpEDjiaqjtVAM+MguggzTSrqPr6c7b/a7+K7XwcqbiSePdXc1x7uN/gFxy0+fSF44 mvjXGKF3g6N3UDyk4lY5TQv/TrpquKCh3ZOBo= Received: by 10.204.149.216 with SMTP id u24mr15896679bkv.73.1321913766768; Mon, 21 Nov 2011 14:16:06 -0800 (PST) Received: from [10.0.0.4] (bzq-79-183-226-89.red.bezeqint.net. [79.183.226.89]) by mx.google.com with ESMTPS id x19sm16836859fag.5.2011.11.21.14.16.05 (version=SSLv3 cipher=OTHER); Mon, 21 Nov 2011 14:16:06 -0800 (PST) Message-ID: <4ECACDA3.4000003@gmail.com> Date: Tue, 22 Nov 2011 00:16:03 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux i686; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1 MIME-Version: 1.0 To: tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [TLS] about the PWD Proposal 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, 21 Nov 2011 22:16:12 -0000 In a somewhat related protocol (IKEv2 with PACE for authentication), we added an appendix on password salting: http://tools.ietf.org/html/draft-kuegler-ipsecme-pace-ikev2-08#appendix-B. The setting there is a little different from tls-pwd, because IKE is normally symmetric (peer to peer vs. client to server). But some of our analysis does apply. In particular, dynamically replacing the short credentials by a long shared secret ( http://tools.ietf.org/html/draft-kuegler-ipsecme-pace-ikev2-08#appendix-B.3) would mitigate much of the risk. Thanks, Yaron ----- Hi, I am interested in the PWD proposal at the meeting, and run through it(http://tools.ietf.org/html/draft-harkins-tls-pwd-01#section-3.4), and have the following concerns: 1. In the document, it says both Client and Server should be able to compute PE, which is derived from username, password, salt,etc. That means Client or the user should also remember the salt value, in that case, salt is meaningless and can be replaced by a longer password. This is quite different from the widely known usage of salt, e.g. in UNIX operating system, salt is not required to remember by the user, but by server to fetch locally by reference to the username. And as far as I know, I am sure the authors also know that, other password based key exchanges protocols don't involve salt, but store a hash value of password among other things locally. > I realize that this is very different from the usage in UNIX operating systems, but it is necessary, as the UNIX (or other) operating system running the web server has to store the password. Storing the password in the clear on as an unsalted hash is worse than storing a salted hash (or "base" in the draft's terminology), so that is what the TLS server does. The use of base instead of password is not to protect the password during handshake, but to protect it during storage on the server. > > Having said that, I think it is now very practical to take a list of the 100,000 most popular passwords on the web, a database of 10,000 salted hashes (the file described in section 3.4), and find all the matches. That's 1,000,000,000 operations, which would take 15 minutes on a MacBook Air (1.4 GHz). I think the days of saying that a database of salted hashes makes theft of the password file irrelevant should be over. Yes, I know that with unsalted hash it would be practical to test the 100,000,000 most popular passwords. > > session cookies somehow (e.g., via the BEAST attack): but if you don't > have my OBCs' private keys then you can't actually make use of my > cookies. > > With OBC cookie theft is not enough. With OBC the attacker must get > at the private keys for the OBCs. > > Also, with OBC you get closer to true logout: destroy ("forget") your > OBC private keys and your sessions are as good as dead. Moreover, the > user-agent, not the server, is in control of maximum session lifetime, > since there's no point in the server setting cookies that will outlive > the OBCs. > I we can find no other use case, we might want to rename it to "Origin Bound Cookie". > > But that would require some interesting interaction between layers. > > Are all cookies received while using OBC considered (by the client!) bound to the OBC? If not, the client might use an old cookie after a logout event, leading to the server falsely detecting an attempt to forge a cookie. Maybe we need a new keyword on the cookie header. > > Where is the "logout" button? If it's part of the website (in the "canvas") how does the HTML/HTTP tell the browser to log out? Probably best to have it in the Chrome for sites where OBC are supported. From agl@google.com Mon Nov 21 14:54:42 2011 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 CBE4711E8125 for ; Mon, 21 Nov 2011 14:54:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.977 X-Spam-Level: X-Spam-Status: No, score=-103.977 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, RCVD_IN_DNSWL_LOW=-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 tCHI16qodov3 for ; Mon, 21 Nov 2011 14:54:38 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 93A7E11E811A for ; Mon, 21 Nov 2011 14:54:38 -0800 (PST) Received: by yenm7 with SMTP id m7so3152801yen.31 for ; Mon, 21 Nov 2011 14:54:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=beta; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding:x-system-of-record; bh=kCbQuG7/Fu7HNIKH56HSkhEQXtW9TdlVjsanryGhoYU=; b=bQOLYmHxpxg9wSFk9a05UP93Dr3Njwq/dmC+8g/EbFvpDsoZawh8s9U20qQJZhe7oI mdzehJGzOBfbNBj7uqow== Received: by 10.50.85.129 with SMTP id h1mr16602872igz.47.1321916077672; Mon, 21 Nov 2011 14:54:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.50.85.129 with SMTP id h1mr16602863igz.47.1321916077605; Mon, 21 Nov 2011 14:54:37 -0800 (PST) Received: by 10.231.37.195 with HTTP; Mon, 21 Nov 2011 14:54:37 -0800 (PST) In-Reply-To: References: <4F26370A-E4DA-4EDF-8D33-D77F2D9C89FB@checkpoint.com> Date: Mon, 21 Nov 2011 17:54:37 -0500 Message-ID: From: Adam Langley To: Yoav Nir Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-System-Of-Record: true Cc: "tls@ietf.org List" Subject: Re: [TLS] NextProtoNeg concerns 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, 21 Nov 2011 22:54:42 -0000 On Sat, Nov 19, 2011 at 5:15 AM, Yoav Nir wrote: > I would strongly prefer that it not say "opaque" but rather point to a re= gistry of strings, similar to the TLS exporter label registry > http://www.iana.org/assignments/tls-parameters/tls-parameters.xml#exporte= r-labels > > That does not have to mean that you need to publish an RFC for each label= . The label space is huge, even if we limit in to case-insensitive latin le= tters plus numbers, slash, point, dash and colon, and up to 12 characters, = it still dwarfs the US national debt expressed in Taiwanese cents (assuming= there is such a thing as a Taiwanese cent). So a registry like that could = be set up on a fcfs basis, with some reserved prefixes (priv-, exp-, com-co= mpanyname-) that could be used without registration. Or maybe require a pri= v- or exp- prefix for anything not specified at all, FCFS or expert review = for other prefixes, and standards action for things that don't have a prefi= x (like "http/1.1", or "SSTP" if Microsoft chooses to document it) I would be happy with a low-friction registry of names. Cheers AGL From ietf@meetecho.com Tue Nov 22 02:32:51 2011 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 2D55D21F8D25 for ; Tue, 22 Nov 2011 02:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.462 X-Spam-Level: X-Spam-Status: No, score=-0.462 tagged_above=-999 required=5 tests=[AWL=0.257, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245] 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 2uEtK8uPM9zr for ; Tue, 22 Nov 2011 02:32:50 -0800 (PST) Received: from smtplq02.aruba.it (smtplq-out17.aruba.it [62.149.158.37]) by ietfa.amsl.com (Postfix) with SMTP id CA11A21F8D84 for ; Tue, 22 Nov 2011 02:32:46 -0800 (PST) Received: (qmail 27997 invoked by uid 89); 22 Nov 2011 10:32:29 -0000 Received: from unknown (HELO smtp3.aruba.it) (62.149.158.223) by smtplq02.aruba.it with SMTP; 22 Nov 2011 10:32:29 -0000 Received: (qmail 23806 invoked by uid 89); 22 Nov 2011 10:32:29 -0000 Received: from unknown (HELO ?143.225.229.189?) (ietf@meetecho.com@143.225.229.189) by smtp3.ad.aruba.it with SMTP; 22 Nov 2011 10:32:29 -0000 Message-ID: <4ECB7A2C.6060303@meetecho.com> Date: Tue, 22 Nov 2011 11:32:12 +0100 From: Meetecho IETF support User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: smtp3.ad.aruba.it 1.6.2 0/1000/N X-Spam-Rating: smtplq02.aruba.it 1.6.2 0/1000/N Subject: [TLS] TLS session recording available 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, 22 Nov 2011 10:32:51 -0000 Dear all, the full recording (synchronized video, audio, slides and jabber room) of TLS session at IETF-82 is available. You can watch it by either clicking the proper link on the remote participation page (http://www.ietf.org/meeting/82/remote-participation.html#Meetecho), or by directly accessing the following URL: http://www.meetecho.com/ietf82/recordings#TLS For the chair(s): please feel free to put the link to the recording in the minutes, if you think this might be useful. In case of problems with the playout, just drop an e-mail to ietf-support@meetecho.com. Cheers, the Meetecho team -- Meetecho s.r.l. Web Conferencing and Collaboration Tools www.meetecho.com From n.mavrogiannopoulos@gmail.com Tue Nov 22 23:16:58 2011 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 D22AF1F0C43 for ; Tue, 22 Nov 2011 23:16:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AVlYYV3K-6h9 for ; Tue, 22 Nov 2011 23:16:58 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 09C751F0C36 for ; Tue, 22 Nov 2011 23:16:57 -0800 (PST) Received: by wwe5 with SMTP id 5so1299700wwe.13 for ; Tue, 22 Nov 2011 23:16:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:openpgp:content-type:content-transfer-encoding; bh=J3Wzd98P7LXFE8FTxOeNg2h5w5L/24LFK8NAhsSorrY=; b=hhe/iOUOpA9S63iUdjHC8r6slNdgtewayfP6zD9iOJ2a8O9dKa+E0Coirg3ehJFSWr j/yIVv09kwF/FfcbcI+wRIRaHLyo+gtFEgmhobtfy99v+rOTd5WAZ2wYJktutocsO61Z YsBL6AA26aRktA6Ra+2Y3bfZqKIkC4wgnzT7w= Received: by 10.227.209.205 with SMTP id gh13mr4031708wbb.5.1322032617106; Tue, 22 Nov 2011 23:16:57 -0800 (PST) Received: from [10.100.2.14] (d51A49E78.access.telenet.be. [81.164.158.120]) by mx.google.com with ESMTPS id dw6sm7789977wib.12.2011.11.22.23.16.56 (version=SSLv3 cipher=OTHER); Tue, 22 Nov 2011 23:16:56 -0800 (PST) Sender: Nikos Mavrogiannopoulos Message-ID: <4ECC9E6F.90309@gnutls.org> Date: Wed, 23 Nov 2011 08:19:11 +0100 From: Nikos Mavrogiannopoulos User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20111010 Icedove/3.1.15 MIME-Version: 1.0 To: "tls@ietf.org" X-Enigmail-Version: 1.1.2 OpenPGP: id=96865171 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [TLS] software supporting arbitrary elliptic curves X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 07:16:59 -0000 Hello, Is there any software client and/or server side that supports the arbitrary_explicit_prime_curves option of RFC4492? regards, Nikos From pgut001@login01.cs.auckland.ac.nz Tue Nov 22 23:18:52 2011 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 2842A21F8B00 for ; Tue, 22 Nov 2011 23:18:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 T6h5qZH2w2kq for ; Tue, 22 Nov 2011 23:18:51 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id BF14321F8AFB for ; Tue, 22 Nov 2011 23:18:49 -0800 (PST) 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=1322032731; x=1353568731; h=from:to:subject:in-reply-to:message-id:date; bh=qwSrkbzH7OtJFw4m+a7JC5ppSVazNal8RKlkTOc6h6w=; b=UdjeCGUrcpWEx9cyTE4Or5YYov4QsGA/K+Z5fjD2671UZEKXHpiNle0l GRwNonvGBQO4DYz99+uVXh1z3R0hIzhA4njsJBoGT3zq0kkwAkfXTHuOJ n+ZzIpCDBSU3uys2QVE9BxjhRgKcwDTgFGOk+PXNmOf7bjUyylfRsCiUT 8=; X-IronPort-AV: E=Sophos;i="4.69,557,1315137600"; d="scan'208";a="91571768" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.34.40 - Outgoing - Outgoing Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 23 Nov 2011 20:18:49 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1RT76W-0007uQ-CA; Wed, 23 Nov 2011 20:18:48 +1300 From: Peter Gutmann To: nmav@gnutls.org, tls@ietf.org In-Reply-To: <4ECC9E6F.90309@gnutls.org> Message-Id: Date: Wed, 23 Nov 2011 20:18:48 +1300 Subject: Re: [TLS] software supporting arbitrary elliptic curves X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Nov 2011 07:18:52 -0000 Nikos Mavrogiannopoulos writes: >Is there any software client and/or server side that supports the >arbitrary_explicit_prime_curves option of RFC4492? For my code, I don't support it and have no intention to. It's a complete mess. Peter. From sm@resistor.net Thu Nov 24 09:00:51 2011 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 7DF8A21F8BBB for ; Thu, 24 Nov 2011 09:00:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 9yJe+O-tO6cA for ; Thu, 24 Nov 2011 09:00:49 -0800 (PST) Received: from mx.ipv6.elandsys.com (mx.ipv6.elandsys.com [IPv6:2001:470:f329:1::1]) by ietfa.amsl.com (Postfix) with ESMTP id CE3FC21F8BA4 for ; Thu, 24 Nov 2011 09:00:49 -0800 (PST) Received: from SUBMAN.resistor.net (IDENT:sm@localhost [127.0.0.1]) by mx.elandsys.com (8.14.4/8.14.5) with ESMTP id pAOGVMDg012664; Thu, 24 Nov 2011 08:31:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=opendkim.org; s=mail2010; t=1322152296; bh=ZFFUCj5WdQgYF4dKkcrLZSfUd8M3blL9Jo1Fdi/1yyE=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=IU73HUhf0On/24K0Qe2jCPklafrf+MrKurlUxKDBRJ0leTm0aggmKbW/cgsOWVFAh N70lIVfy1S2Z9ZOCRfkqCtNeKFDUopyOtzAC/i2GH0pjrK2RqmKP/jLgCjsILZIlyM qC9CnyOdwSCALkMfDX1DgT8++AJR2WXemy1OQigQ= DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=resistor.net; s=mail; t=1322152296; bh=ZFFUCj5WdQgYF4dKkcrLZSfUd8M3blL9Jo1Fdi/1yyE=; h=Message-Id:Date:To:From:Subject:Cc:In-Reply-To:References: Mime-Version:Content-Type; b=1D/mD9uw16RiCV+ACJ+tcc7FwfCdw4elwVymBB8Mtj0ooc7jjgXmADPRoPbGucU0/ qjf31dORzAWhISasAnZcVbmvy60zAC2+XFKndWVYEQgmSCG27y0536QEGr1hMIxCk5 u/0GsTMFaXfXnVqdz4W/A0s9+oFffrDZLMTXSTmU= Message-Id: <6.2.5.6.2.20111124080338.0a3c01a8@resistor.net> X-Mailer: QUALCOMM Windows Eudora Version 6.2.5.6 Date: Thu, 24 Nov 2011 08:10:56 -0800 To: Badra From: SM In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: tls@ietf.org Subject: Re: [TLS] Fwd: Client TLS Identity Protection: draft-hajjeh-tls-identity-protection-09.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: Thu, 24 Nov 2011 17:00:51 -0000 Hi Badra, At 00:25 16-11-2011, Badra wrote: >If you support reconsidering that draft with IANA registration for >ciphersuite code points in the "specification required" range >(before asking for its sign-off in the IESG), kindly please say so >on the mailing list, like that I will inform the RFC-Ed to postpone >its publication. The draft is being published through the Independent Stream (non-IETF). According to the Copyright Notice, the document may not be modified outside the IETF Standards Process. Regards, -sm From mrex@sap.com Wed Nov 30 11:23:10 2011 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 D5EA521F8A71 for ; Wed, 30 Nov 2011 11:23:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.692 X-Spam-Level: X-Spam-Status: No, score=-9.692 tagged_above=-999 required=5 tests=[AWL=0.558, 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 cmleHas84a8l for ; Wed, 30 Nov 2011 11:23:10 -0800 (PST) Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2900421F8AF9 for ; Wed, 30 Nov 2011 11:23:09 -0800 (PST) Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id pAUJN6YQ023908 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Nov 2011 20:23:06 +0100 (MET) From: Martin Rex Message-Id: <201111301923.pAUJN6VR022639@fs4113.wdf.sap.corp> To: mbadra@gmail.com (Badra) Date: Wed, 30 Nov 2011 20:23:06 +0100 (MET) In-Reply-To: from "Badra" at Nov 17, 11 10:49:47 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLS identity protection using Signaling Cipher Suite Value 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: Wed, 30 Nov 2011 19:23:11 -0000 Badra wrote: > > I posted a document that defines a pecial Signaling Cipher Suite Value to > enable the negotiation of the client identity protection. This approach had > been initially proposed by Francisco Corella, to the TLS mailing list > during August 2000. > > http://www.ietf.org/id/draft-badra-tls-identity-protection-00.txt A signaling cipher suite value is certainly *MUCH* better than the other proposal for a cartesian product of common ciphersuites. Although performing negotiation of this capability through ciphersuite values instead of a TLS extension would protect against a very simplistic DoS attack against a TLS handshake between the rightful client and rightful server using TLS extension (but only in case the client is capable and willing to perform a reconnect fallback with an extension-less ClientHello), this approach can *NOT* protect against an active attacker that is determined to learn the client's identity and does not care about causing a failed TLS handshake while doing so. As I previously mentioned, the only reliable protection during the handshake would be an indication from the server that is authenticated by the server credential an can *not* be stripped from the handshake. Basically, it would need to be hardwired into the server's credential, like an additional certificate extension or a new EKU OID. The Finished MAC protection of the handshake contents can only protect the application from using the resulting connection, it can not protect the negotiation and use of protocol features _during_ the TLS handshake because modifications of the handshake by an active MitM can only reliably be detected *after* the handshake when verifying the finished messages. -Martin From jsalowey@cisco.com Wed Nov 30 13:34:56 2011 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 19A2211E80E1 for ; Wed, 30 Nov 2011 13:34:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 9Udr2U7V2Vkw for ; Wed, 30 Nov 2011 13:34:55 -0800 (PST) Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8B011E80C0 for ; Wed, 30 Nov 2011 13:34:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=1082; q=dns/txt; s=iport; t=1322688895; x=1323898495; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=aHFDQKRjVFo2+GuLjuRuXSYUsnyEK0t7KT+rnWAm0Fk=; b=BvPdu49z3dAtykFqHhq/UPJOaG7nejnf5LWANQXIbqwXlpxBf+lcFrk+ e90wxmpzxNt7mJWhGifbjfB9FUcw8asaunrN+0mZLnN9To3x9iGMkSgx/ mn6QH4wNQ3MYZf+f3ATW5DKXsUhoUDXJxslJdu0KfTQvCYtFq9UQgh1PE w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEAB6h1k6rRDoH/2dsb2JhbABEqxKBBYILASeCModtmHCBJgGeLQSIC4IyYwSIKIwvhUOMbg X-IronPort-AV: E=Sophos;i="4.71,273,1320624000"; d="scan'208";a="17018510" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-2.cisco.com with ESMTP; 30 Nov 2011 21:34:54 +0000 Received: from [10.33.248.79] ([10.33.248.79]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAULYsef009571 for ; Wed, 30 Nov 2011 21:34:54 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Nov 2011 13:34:59 -0800 Message-Id: <107EC16E-ACCD-4DC7-A4F1-1EA5434C154C@cisco.com> To: tls@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [TLS] consensus on adopting draft-mcgrew-tls-aes-ccm and draft-mcgrew-tls-aes-ccm-ecc 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, 30 Nov 2011 21:34:56 -0000 The chairs would like to see if there is consensus in the TLS working = group to adopt draft-mcgrew-tls-aes-ccm and draft-mcgrew-tls-aes-ccm-ecc = as working group items. These drafts define AES-CCM cipher suites for = TLS. The Zigbee smart energy group has interest in these drafts. = These drafts only deal with a AES-CCM and not with Zigbee's AES-CCM* = which is a super set of AES-CCM. The authors are requesting standards = track for these ciphers. Please note that there is an IPR declaration = listed for draft-mcgrew-tls-aes-ccm-ecc available here: = https://datatracker.ietf.org/ipr/1443/. This declaration has been = updated from previous declarations. Please respond to the following by = December 14, 2011 : - Do you object to taking these drafts on as working group items? = (Please state the reason for you objection) - Would you contribute time to review and provide text for the documents = when needed? - Do you object to standards track status for these documents?(Please = state the reason for you objection) Cheers, Joe= From jsalowey@cisco.com Wed Nov 30 13:43:46 2011 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 144CE1F0C71 for ; Wed, 30 Nov 2011 13:43:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 jLI1ohRw6Ws3 for ; Wed, 30 Nov 2011 13:43:45 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id A76081F0C61 for ; Wed, 30 Nov 2011 13:43:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jsalowey@cisco.com; l=608; q=dns/txt; s=iport; t=1322689425; x=1323899025; h=from:content-transfer-encoding:subject:date:message-id: to:mime-version; bh=lfdqaWMF5vosqSbaFDCUNfBob72fCnGljR7q6V9kkxo=; b=dvObEhbbXEhRhxuaNWqL5XqEnwtAcpR4XUjzHC8xU4mY3LH+rjdXUjUO nvzw9OQ4qSuUo+EVsShyI6e/98+HS8p5YxH3Sbge7gEq6G0T7hpucU3Lb PW10WBeLL2Ye3So/ZycJiGZKIW2iWURUg8oxyqk6CuK7Ic8slWGsRRvOF E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvwEADuj1k6rRDoH/2dsb2JhbABEqxKBBYILASeCMqBjgSYBnjKIC4IyYwSIKIwvhUOMbg X-IronPort-AV: E=Sophos;i="4.71,273,1320624000"; d="scan'208";a="17099330" Received: from mtv-core-2.cisco.com ([171.68.58.7]) by mtv-iport-4.cisco.com with ESMTP; 30 Nov 2011 21:43:43 +0000 Received: from [10.33.248.79] ([10.33.248.79]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id pAULhhrf014811 for ; Wed, 30 Nov 2011 21:43:43 GMT From: Joe Salowey Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 30 Nov 2011 13:43:48 -0800 Message-Id: <83501846-AB99-4F88-98DB-122C96F2AA39@cisco.com> To: tls@ietf.org Mime-Version: 1.0 (Apple Message framework v1084) X-Mailer: Apple Mail (2.1084) Subject: [TLS] Consensus for adoption of draft-wouters-tls-oob-pubkey-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 21:43:46 -0000 The chairs would like to confirm the consensus of the TLS working group = to adopt draft-wouters-tls-oob-pubkey-02 as a working group item. There = was strong interest in this document at previous IETF meetings and the = controversial options dealing with only providing public key hashes have = been removed. Please respond to the following questions by December = 14, 2011: - Do you object to taking this draft on as working group item? (Please = state the reason for you objection) - Would you contribute time to review and provide text for the document = when needed? Thanks, Joe= From dkg@fifthhorseman.net Wed Nov 30 14:15:54 2011 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 0967721F8B59 for ; Wed, 30 Nov 2011 14:15:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozZ20hLU4Y6e for ; Wed, 30 Nov 2011 14:15:53 -0800 (PST) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6DD8D21F8B12 for ; Wed, 30 Nov 2011 14:15:53 -0800 (PST) Received: from [192.168.23.207] (dsl254-070-154.nyc1.dsl.speakeasy.net [216.254.70.154]) by che.mayfirst.org (Postfix) with ESMTPSA id 5563CF970; Wed, 30 Nov 2011 17:15:48 -0500 (EST) Message-ID: <4ED6AB0D.9070001@fifthhorseman.net> Date: Wed, 30 Nov 2011 17:15:41 -0500 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111120 Icedove/8.0 MIME-Version: 1.0 To: Joe Salowey References: <83501846-AB99-4F88-98DB-122C96F2AA39@cisco.com> In-Reply-To: <83501846-AB99-4F88-98DB-122C96F2AA39@cisco.com> X-Enigmail-Version: 1.3.3 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigDECD85C64C52237C04B49A66" Cc: tls@ietf.org Subject: Re: [TLS] Consensus for adoption of draft-wouters-tls-oob-pubkey-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 22:15:54 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDECD85C64C52237C04B49A66 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 11/30/2011 04:43 PM, Joe Salowey wrote: > - Do you object to taking this draft on as working group item? (Please = state the reason for you objection) I don't object. > - Would you contribute time to review and provide text for the document= when needed? I will commit time to review the document and provide feedback, for whatever my review is worth. I think it's worth consideration as a working group item. Thanks, --dkg --------------enigDECD85C64C52237C04B49A66 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQJ8BAEBCgBmBQJO1qsNXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQwRUU1QkU5NzkyODJEODBCOUY3NTQwRjFD Q0QyRUQ5NEQyMTczOUU5AAoJEMzS7ZTSFznpMTMP/RgMAMlXsrvH4rQe+PQFds0i nyVkprhy7Y1TmXGGOiD1GDuSMHtNBqNBXfb0ezo8DzYPdRL72O7+c4b71K/OzHwf 78WlTxlQJ+SB8GNerD/6MFEl2HPxH6dPvXaUQn993A3dGA54CFsO3MhajQEe4WYM lE6Lprv7cakGw1IasqyX0BNo6QP5oXeqP3tEUMgx8JFt0g0rjTFxT8abcFaszYcZ R7dYRoxFrFvtZRnaKnkjy2ROP2gb1AJwcKbgA8omyEoreWaO/AnydabReNTN3fGs br0X7I9Jd1kDRZbSqZOhLi8pENHyWAkreIR49P9PZdzwxxyIk3CDaNVNRSYVoRG3 5gxEeINyUqGN04S/9UwnYezNu05I15JqFHZ5/PuEhJXp7JwdR9biLWgurbN7Qx9E HNy9qPrVifYBCtBS/+B0M8pEklBoDGs9K51nP5cG/mqOs/KiY02wZ4rAmnrqkkev XIgJH0kFrMpXVXgMX+7utHcpsT9WedAqidUuCpZV5Dz74apQkC8myaPf6W8DAnwO 7HNpyJhsvwe3hytv3rCVEAS6wVswwpK929z7lSPjkVQc25ZnET/8uAzq1PbDUmxb SNRikjQQGc4ceRnjzDQjatcM9tgMo0NH/TAwsXdnImZpiMzEPcRwjSdd7kD6jU+W 9SxonnV47GqyjSgfdjDo =lrWo -----END PGP SIGNATURE----- --------------enigDECD85C64C52237C04B49A66-- From ynir@checkpoint.com Wed Nov 30 14:20:32 2011 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 9984D21F8B86 for ; Wed, 30 Nov 2011 14:20:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.549 X-Spam-Level: X-Spam-Status: No, score=-10.549 tagged_above=-999 required=5 tests=[AWL=0.050, 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 G5E5nL+dHanS for ; Wed, 30 Nov 2011 14:20:32 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 9EB1F21F8B80 for ; Wed, 30 Nov 2011 14:20:31 -0800 (PST) X-CheckPoint: {4ED6AB4D-0-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pAUMKSkr002116; Thu, 1 Dec 2011 00:20:28 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 1 Dec 2011 00:20:27 +0200 From: Yoav Nir To: Joe Salowey Date: Thu, 1 Dec 2011 00:20:26 +0200 Thread-Topic: [TLS] consensus on adopting draft-mcgrew-tls-aes-ccm and draft-mcgrew-tls-aes-ccm-ecc Thread-Index: AcyvrkNHBu/HngqBSWOVQqBwDLRVjA== Message-ID: <668B0197-C0AE-4EC9-87FB-DB08E517886E@checkpoint.com> References: <107EC16E-ACCD-4DC7-A4F1-1EA5434C154C@cisco.com> In-Reply-To: <107EC16E-ACCD-4DC7-A4F1-1EA5434C154C@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] consensus on adopting draft-mcgrew-tls-aes-ccm and draft-mcgrew-tls-aes-ccm-ecc 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, 30 Nov 2011 22:20:32 -0000 On Nov 30, 2011, at 11:34 PM, Joe Salowey wrote: > The chairs would like to see if there is consensus in the TLS working gro= up to adopt draft-mcgrew-tls-aes-ccm and draft-mcgrew-tls-aes-ccm-ecc as wo= rking group items. These drafts define AES-CCM cipher suites for TLS. The= Zigbee smart energy group has interest in these drafts. These drafts onl= y deal with a AES-CCM and not with Zigbee's AES-CCM* which is a super set o= f AES-CCM. The authors are requesting standards track for these ciphers. = Please note that there is an IPR declaration listed for draft-mcgrew-tls-ae= s-ccm-ecc available here: https://datatracker.ietf.org/ipr/1443/. This de= claration has been updated from previous declarations. Please respond to = the following by December 14, 2011 : >=20 > - Do you object to taking these drafts on as working group items? (Please= state the reason for you objection) Sort of. These kinds of documents defining new ciphersuites or algorithms (= "my-favorite-algorithm and its use in TLS, IPsec, SSH") seldom get meaningf= ul review in the working groups. Most of us are not cryptographers, and tho= se who are usually remain silent. Sometimes you get some objections like wh= y waste 8 whole code points for this group of ciphersuites, wouldn't 4 be e= nough, but these objections rarely cause a change. IOW I don't think the wo= rking group would contribute much to such a document. >=20 > - Would you contribute time to review and provide text for the documents = when needed? Probably not. >=20 > - Do you object to standards track status for these documents?(Please sta= te the reason for you objection) No objections at all. From ynir@checkpoint.com Wed Nov 30 14:21:29 2011 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 9C5B621F8BE5 for ; Wed, 30 Nov 2011 14:21:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 zwzUIJIRKaXP for ; Wed, 30 Nov 2011 14:21:27 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by ietfa.amsl.com (Postfix) with ESMTP id 20A3121F8BDE for ; Wed, 30 Nov 2011 14:21:25 -0800 (PST) X-CheckPoint: {4ED6AB83-1-1B221DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id pAUMLN0S002327; Thu, 1 Dec 2011 00:21:23 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 1 Dec 2011 00:21:22 +0200 From: Yoav Nir To: Joe Salowey Date: Thu, 1 Dec 2011 00:21:13 +0200 Thread-Topic: [TLS] Consensus for adoption of draft-wouters-tls-oob-pubkey-02 Thread-Index: AcyvrmPSXubISKPPRBuXySW5W0XuhA== Message-ID: <11EFDE88-6957-4B9F-A30C-4CFB68ED7E03@checkpoint.com> References: <83501846-AB99-4F88-98DB-122C96F2AA39@cisco.com> In-Reply-To: <83501846-AB99-4F88-98DB-122C96F2AA39@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-kse-antivirus-interceptor-info: scan successful x-kse-antivirus-info: Clean Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "tls@ietf.org" Subject: Re: [TLS] Consensus for adoption of draft-wouters-tls-oob-pubkey-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 22:21:29 -0000 On Nov 30, 2011, at 11:43 PM, Joe Salowey wrote: > The chairs would like to confirm the consensus of the TLS working group t= o adopt draft-wouters-tls-oob-pubkey-02 as a working group item. There was= strong interest in this document at previous IETF meetings and the controv= ersial options dealing with only providing public key hashes have been remo= ved. Please respond to the following questions by December 14, 2011: >=20 > - Do you object to taking this draft on as working group item? (Please st= ate the reason for you objection) No objection. >=20 > - Would you contribute time to review and provide text for the document w= hen needed? Yes. From d.sturek@att.net Wed Nov 30 14:32:08 2011 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 2269111E80C5 for ; Wed, 30 Nov 2011 14:32:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 726x-68xa2sR for ; Wed, 30 Nov 2011 14:32:07 -0800 (PST) Received: from nm6.access.bullet.mail.mud.yahoo.com (nm6.access.bullet.mail.mud.yahoo.com [66.94.237.207]) by ietfa.amsl.com (Postfix) with SMTP id 9428A11E809D for ; Wed, 30 Nov 2011 14:32:07 -0800 (PST) Received: from [66.94.237.127] by nm6.access.bullet.mail.mud.yahoo.com with NNFMP; 30 Nov 2011 22:32:03 -0000 Received: from [66.94.237.108] by tm2.access.bullet.mail.mud.yahoo.com with NNFMP; 30 Nov 2011 22:32:03 -0000 Received: from [127.0.0.1] by omp1013.access.mail.mud.yahoo.com with NNFMP; 30 Nov 2011 22:32:02 -0000 X-Yahoo-Newman-Id: 998309.69605.bm@omp1013.access.mail.mud.yahoo.com Received: (qmail 67816 invoked from network); 30 Nov 2011 22:32:02 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1322692322; bh=w0gOlISl/oVD6Bldk0pJLFtbupyGTiMTeMMw+wzMPVo=; h=X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:Received:User-Agent:Date:Subject:From:To:Message-ID:Thread-Topic:In-Reply-To:Mime-version:Content-type:Content-transfer-encoding; b=3YxYtTU5Lgu3FT8ghIgdcGbmdRJ5WtaMWpeo1mg0Cgxd5ui/n3vZZMxAlWASjFXeJx68zZjsVZMkmVWThc/I6pue9JMR/1RFI5Adaihkvp5oroyDO8XqqIk79A0VW7cMl1yqPmXa8aE309VrIV59HBKl4Fb/SVWGBiEL/AKJd1o= X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Tj6cp_AVM1l0LRonnR0XHjc9z2DbaQ.jIge38Y0s4qROtTD a5H3kXDTVYEbPKuNpOLyj6UviKK0EUh4dr0ilvEraIp_JIMn4_C54SdE2xJU ACLhyobz0BhgNfPpf4Gl6zPjc5RCCzGAVRKxiT8S4B9czJCpY0s8wJxfFw2j .B8N3s0b5rJeezbbSUPJjyQC2X4zBO_A6ggd2Z4gZHd4BBhEnPCTwbbLkD.L j5zUI78c_5EJX0ybH2zhEKWIMfp4SBVFCYKz8UjPTZTBVH58Ut.f8xoK_iFR E46QW6pTYBjwLTTJB.ZJOwMpJRLn9aWkQngUS8SkNxVaPGY8pbrHCmgj0q5T Lyt2IMN.4SYOCVxZLVRuyfaxbs0x9hHfxS9uj.YA8IWS.tw9JxDOLqbxyZMz geRUTn66FH5GUh9UHtXw- X-Yahoo-SMTP: fvjol_aswBAraSJvMLe2r1XTzhBhbFxY8q8c3jo- Received: from [10.1.1.121] (d.sturek@174.78.56.227 with login) by smtp102.sbc.mail.ne1.yahoo.com with SMTP; 30 Nov 2011 14:32:00 -0800 PST User-Agent: Microsoft-MacOutlook/14.13.0.110805 Date: Wed, 30 Nov 2011 14:31:42 -0800 From: Don Sturek To: Joe Salowey , Message-ID: Thread-Topic: [TLS] consensus on adopting draft-mcgrew-tls-aes-ccm and draft-mcgrew-tls-aes-ccm-ecc In-Reply-To: <107EC16E-ACCD-4DC7-A4F1-1EA5434C154C@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [TLS] consensus on adopting draft-mcgrew-tls-aes-ccm and draft-mcgrew-tls-aes-ccm-ecc 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, 30 Nov 2011 22:32:08 -0000 Hi Joe, Some comments on your questions below (inline): On 11/30/11 1:34 PM, "Joe Salowey" wrote: >The chairs would like to see if there is consensus in the TLS working >group to adopt draft-mcgrew-tls-aes-ccm and draft-mcgrew-tls-aes-ccm-ecc >as working group items. These drafts define AES-CCM cipher suites for >TLS. The Zigbee smart energy group has interest in these drafts. These >drafts only deal with a AES-CCM and not with Zigbee's AES-CCM* which is a >super set of AES-CCM. The authors are requesting standards track for >these ciphers. Please note that there is an IPR declaration listed for >draft-mcgrew-tls-aes-ccm-ecc available here: >https://datatracker.ietf.org/ipr/1443/. This declaration has been >updated from previous declarations. Please respond to the following by >December 14, 2011 : > >- Do you object to taking these drafts on as working group items? (Please >state the reason for you objection) I believe these drafts should be working group items so, no, I don't object. > >- Would you contribute time to review and provide text for the documents >when needed? Yes, I will help David and the draft authors as needed. > >- Do you object to standards track status for these documents?(Please >state the reason for you objection) I believe these drafts should be standards track so, no, I don't object. The reason for making these standards track is that IEEE 802.15.4 uses AES-CCM and this will allow existing hardware implementations in IEEE 802.15.4 devices to natively support a TLS cipher suite. > > >Cheers, > >Joe >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls From ondrej.sury@nic.cz Wed Nov 30 14:43:41 2011 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 29E891F0C4E for ; Wed, 30 Nov 2011 14:43:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_8BIT_HEADER=0.3] 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 ArsPuen+B7sg for ; Wed, 30 Nov 2011 14:43:40 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 7C37C1F0C35 for ; Wed, 30 Nov 2011 14:43:40 -0800 (PST) Received: from [10.0.0.12] (173.5.broadband15.iol.cz [90.182.5.173]) by mail.nic.cz (Postfix) with ESMTPSA id A9B132A0A78; Wed, 30 Nov 2011 23:43:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1322693019; bh=sqkoclK9v0mlbZSYuKaDAfkOSq2ZU2AHZshAuqznP/E=; h=Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=TURHaUEGmwpr5kV8VVDNitqBifEB8TBNYQTyEDIraB2ZesKCER9auD4hvu+sRh4ea tc2IP+3eAaqpU2ppicQcVtHWFZYyJHGiZwQipMJsbP0MKJgn0YKmzIry7Slu18VPfI o2yERF+0xp5EDG6bjSkFKWtp5fzDZDbzJ60yRAw4= Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=utf-8 From: =?utf-8?Q?Ond=C5=99ej_Sur=C3=BD?= In-Reply-To: <83501846-AB99-4F88-98DB-122C96F2AA39@cisco.com> Date: Wed, 30 Nov 2011 23:43:39 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <83501846-AB99-4F88-98DB-122C96F2AA39@cisco.com> To: Joe Salowey X-Mailer: Apple Mail (2.1251.1) X-Virus-Scanned: clamav-milter 0.96.5 at mail X-Virus-Status: Clean Cc: tls@ietf.org Subject: Re: [TLS] Consensus for adoption of draft-wouters-tls-oob-pubkey-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Nov 2011 22:43:41 -0000 On 30. 11. 2011, at 22:43, Joe Salowey wrote: > The chairs would like to confirm the consensus of the TLS working = group to adopt draft-wouters-tls-oob-pubkey-02 as a working group item. = There was strong interest in this document at previous IETF meetings and = the controversial options dealing with only providing public key hashes = have been removed. Please respond to the following questions by = December 14, 2011: >=20 > - Do you object to taking this draft on as working group item? (Please = state the reason for you objection) I don't. > - Would you contribute time to review and provide text for the = document when needed? I would. [Disclaimer: I chair DANE WG and this draft is of interest to our WG.] -- Ond=C5=99ej Sur=C3=BD vedouc=C3=AD v=C3=BDzkumu/Head of R&D department ------------------------------------------- CZ.NIC, z.s.p.o. -- Laborato=C5=99e CZ.NIC Americka 23, 120 00 Praha 2, Czech Republic mailto:ondrej.sury@nic.cz http://nic.cz/ tel:+420.222745110 fax:+420.222745112 ------------------------------------------- From mbadra@gmail.com Wed Nov 30 15:01:44 2011 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 7D99621F8BEB for ; Wed, 30 Nov 2011 15:01:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, 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 vPOpeq6vkedT for ; Wed, 30 Nov 2011 15:01:43 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 4EB1321F8ACC for ; Wed, 30 Nov 2011 15:01:43 -0800 (PST) Received: by vcbfy13 with SMTP id fy13so1075693vcb.31 for ; Wed, 30 Nov 2011 15:01:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=tXsh254V5L4eEEaDEcsoxiSidjD7fPXzu8kUnOZBCoU=; b=xacV0OQLPLiBfYeVZzNvpZTt9MJQbjfrgqxaEcIlWOH5lleE1FU83r2akHlYL2QN3z GoULgORLnYFCTV4nO49vT4GllJMeFZBlR7z7LIy6mfAjrBFEIDtS8UamLjQQbnbGjSS/ qx+kcp/p1WoZFrbtg118yL33O+qjtOPs2jZsE= MIME-Version: 1.0 Received: by 10.52.94.227 with SMTP id df3mr4140186vdb.51.1322694102728; Wed, 30 Nov 2011 15:01:42 -0800 (PST) Received: by 10.220.191.13 with HTTP; Wed, 30 Nov 2011 15:01:42 -0800 (PST) In-Reply-To: <201111301923.pAUJN6VR022639@fs4113.wdf.sap.corp> References: <201111301923.pAUJN6VR022639@fs4113.wdf.sap.corp> Date: Thu, 1 Dec 2011 00:01:42 +0100 Message-ID: From: Badra To: mrex@sap.com Content-Type: multipart/alternative; boundary=20cf307d048e23c1cd04b2fbb81e Cc: tls@ietf.org Subject: Re: [TLS] TLS identity protection using Signaling Cipher Suite Value 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, 30 Nov 2011 23:01:44 -0000 --20cf307d048e23c1cd04b2fbb81e Content-Type: text/plain; charset=ISO-8859-1 On Wed, Nov 30, 2011 at 8:23 PM, Martin Rex wrote: > > A signaling cipher suite value is certainly *MUCH* better than > the other proposal for a cartesian product of common ciphersuites. > > Although performing negotiation of this capability through ciphersuite > values instead of a TLS extension would protect against a very simplistic > DoS attack against a TLS handshake between the rightful client and > rightful server using TLS extension (but only in case the client is > capable and willing to perform a reconnect fallback with an > extension-less ClientHello), > this approach can *NOT* protect against an active attacker that > is determined to learn the client's identity and does not > care about causing a failed TLS handshake while doing so. > > As I previously mentioned, the only reliable protection during the > handshake would be an indication from the server that is authenticated > by the server credential an can *not* be stripped from the handshake. > Basically, it would need to be hardwired into the server's credential, > like an additional certificate extension or a new EKU OID. > > As you previously mentioned too, hardwiring an new optional TLS protocol feature into a TLS server certificate, resulting in potentially hard to diagnose handshake failures. Can in this case extend the ServerKeyExchange structure as follow: struct { select (KeyExchangeAlgorithm) { case rsa: struct { } ; case rsa_scsv: // message is NOT omitted when SCSV is received struct { digitally-signed struct { opaque handshake_messages[handshake_messages_length]; } } ; }; } ServerKeyExchange; handshake_messages refers to all handshake messages sent or received, starting at client hello and up to, but not including, this message. If the client doesn't receive such a message from the server, it must stop the TLS handshake It may be costly for the serer to sign this message for each handshake. The server can, for every one day, sign the concatenation of SCSV code and the day's date and send the result during every handshake that may happen during that day. > The Finished MAC protection of the handshake contents can only protect > the application from using the resulting connection, it can not > protect the negotiation and use of protocol features _during_ > the TLS handshake because modifications of the handshake by an > active MitM can only reliably be detected *after* the handshake when > verifying the finished messages. > True, and this is applied to any feature supported by TLS Best regards, Badra --20cf307d048e23c1cd04b2fbb81e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On Wed, Nov 30, 2011 at 8:23 PM= , Martin Rex <mrex@sap.com> wrote:

A signaling cipher suite value is certainly *MUCH* better than<= br> the other proposal for a cartesian product of common ciphersuites.

Although performing negotiation of this capability through ciphersuite
values instead of a TLS extension would protect against a very simplistic DoS attack against a TLS handshake between the rightful client and
rightful server using TLS extension (but only in case the client is
capable and willing to perform a reconnect fallback with an
extension-less ClientHello),
this approach can *NOT* protect against an active attacker that
is determined to learn the client's identity and does not
care about causing a failed TLS handshake while doing so.

As I previously mentioned, the only reliable protection during the
handshake would be an indication from the server that is authenticated
by the server credential an can *not* be stripped from the handshake.
Basically, it would need to be hardwired into the server's credential,<= br> like an additional certificate extension or a new EKU OID.



As you previously = mentioned too, hardwiring an new optional TLS protocol=A0
feature= into a TLS server certificate, resulting in potentially hard to=A0
diagnose handshake failures.

Can in this case exte= nd the ServerKeyExchange structure as follow:

stru= ct {
=A0 =A0 select (KeyExchangeAlgorithm) {=A0
=A0 =A0= =A0 =A0 =A0case rsa:
=A0 =A0 =A0 =A0 =A0 =A0 =A0struct { } ;=A0
=A0 =A0 =A0 =A0 = =A0case rsa_scsv: // message is NOT omitted when SCSV is received=A0
<= div>=A0 =A0 =A0 =A0 =A0 =A0 =A0struct {
=A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0digitally-signed struct {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0opaque handshake_messages[handshake_messages_length];
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
=A0 =A0 =A0 =A0 =A0 =A0= =A0} ;=A0
=A0 =A0 };=A0
} ServerKeyExchange;

handshake_messages refers to all handshake messages sent or= received,=A0
starting at client hello and up to, but not includi= ng, this message.

If the client doesn't receive such a message from t= he server, it must=A0
stop the TLS handshake

=
It may be costly for the serer to sign this message for each handshake= .=A0
The server can, for every one day, sign the concatenation of SCSV code= =A0
and the day's date and send the result during every hands= hake that may
happen during that day.

=A0
The Finished MAC protection of the handshake contents can only protect
the application from using the resulting connection, it can not
protect the negotiation and use of protocol features _during_
the TLS handshake because modifications of the handshake by an
active MitM can only reliably be detected *after* the handshake when
verifying the finished messages.


True, and this is = applied to any feature supported by TLS

Best regar= ds,
Badra
--20cf307d048e23c1cd04b2fbb81e-- From mrex@sap.com Wed Nov 30 15:41:23 2011 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 0E90D21F8548 for ; Wed, 30 Nov 2011 15:41:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.372 X-Spam-Level: X-Spam-Status: No, score=-9.372 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, 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 zdtRLY6ywxrF for ; Wed, 30 Nov 2011 15:41:22 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 3FF9521F8573 for ; Wed, 30 Nov 2011 15:41:21 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id pAUNfKPJ012817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Dec 2011 00:41:20 +0100 (MET) From: Martin Rex Message-Id: <201111302341.pAUNfJDa008028@fs4113.wdf.sap.corp> To: mbadra@gmail.com (Badra) Date: Thu, 1 Dec 2011 00:41:19 +2500 (MET) In-Reply-To: from "Badra" at Dec 1, 11 00:01:42 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] TLS identity protection using Signaling Cipher Suite Value 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: Wed, 30 Nov 2011 23:41:23 -0000 Badra wrote: > > Martin Rex wrote: > > > > As I previously mentioned, the only reliable protection during the > > handshake would be an indication from the server that is authenticated > > by the server credential an can *not* be stripped from the handshake. > > Basically, it would need to be hardwired into the server's credential, > > like an additional certificate extension or a new EKU OID. > > As you previously mentioned too, hardwiring an new optional TLS protocol > feature into a TLS server certificate, resulting in potentially hard to > diagnose handshake failures. This "hard to diagnose handshake failures" refers only to client implementations that would check for this server certificate attribute and not sensible report to the user why the client implementation aborted the handshake. "old" clients who do not check the feature would not abort. Typical user reaction "but it works with Browser X!". > > If the client doesn't receive such a message from the server, it must > stop the TLS handshake Of course, you could implement it as a client-side credential attribute which says "never send in the clear", instead of negotiating the protocol feature with the server. That is not so much different from the server conveying the info through a certificate attribute, just that it is entirely up to the client whether an when it is being "enforced", and the server has no say in that. If the user tries to use such a feature before the server has even implemented it, the user will face a failure (and switch it off). Who is going to reenable it when the server adds the feature, then? If the server could steer this with a certificate attribute, this would provide a certain level of synchronization and negotiation whether the feature is available and can (or should) be used. But in the longer run this might lead to multiple distinct client credentials for different purposes in order to accomodate different servers/services feature upgrade strategies, and at that point the client may become identifiable for an MITM attacker that requests the "low-protection" credential rather than the "high-protection" credential, so you're back at square one... > > > The Finished MAC protection of the handshake contents can only protect > > the application from using the resulting connection, it can not > > protect the negotiation and use of protocol features _during_ > > the TLS handshake because modifications of the handshake by an > > active MitM can only reliably be detected *after* the handshake when > > verifying the finished messages. > > True, and this is applied to any feature supported by TLS Correct. This poses a certain risk to proposed features like "TLS false start", where data may get sent prior to verification of the server's finished handshake message on a full TLS handshake so that it may be protected only by the lowest protection offered by the client that an active MITM was able to force on the client. -Martin From paul.hoffman@vpnc.org Wed Nov 30 16:23:58 2011 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 7CEE61F0C57 for ; Wed, 30 Nov 2011 16:23:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.439 X-Spam-Level: X-Spam-Status: No, score=-102.439 tagged_above=-999 required=5 tests=[AWL=0.160, 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 VLxvVX5L1eJf for ; Wed, 30 Nov 2011 16:23:58 -0800 (PST) Received: from hoffman.proper.com (IPv6.Hoffman.Proper.COM [IPv6:2605:8e00:100:41::81]) by ietfa.amsl.com (Postfix) with ESMTP id 091CB1F0C56 for ; Wed, 30 Nov 2011 16:23:57 -0800 (PST) Received: from [10.20.30.100] (50-0-66-4.dsl.dynamic.fusionbroadband.com [50.0.66.4]) (authenticated bits=0) by hoffman.proper.com (8.14.4/8.14.3) with ESMTP id pB10Nu3Y094788 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 30 Nov 2011 17:23:56 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 (Apple Message framework v1251.1) Content-Type: text/plain; charset=us-ascii From: Paul Hoffman In-Reply-To: <83501846-AB99-4F88-98DB-122C96F2AA39@cisco.com> Date: Wed, 30 Nov 2011 16:23:55 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <83501846-AB99-4F88-98DB-122C96F2AA39@cisco.com> To: Joe Salowey X-Mailer: Apple Mail (2.1251.1) Cc: tls@ietf.org Subject: Re: [TLS] Consensus for adoption of draft-wouters-tls-oob-pubkey-02 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Dec 2011 00:23:58 -0000 On Nov 30, 2011, at 1:43 PM, Joe Salowey wrote: > The chairs would like to confirm the consensus of the TLS working = group to adopt draft-wouters-tls-oob-pubkey-02 as a working group item. = There was strong interest in this document at previous IETF meetings and = the controversial options dealing with only providing public key hashes = have been removed. Please respond to the following questions by = December 14, 2011: >=20 > - Do you object to taking this draft on as working group item? (Please = state the reason for you objection) No objection; in fact, support. > - Would you contribute time to review and provide text for the = document when needed? Yes, definitely. --Paul Hoffman From mrex@sap.com Wed Nov 30 16:29:21 2011 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 3BE4921F8BBD for ; Wed, 30 Nov 2011 16:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.939 X-Spam-Level: X-Spam-Status: No, score=-9.939 tagged_above=-999 required=5 tests=[AWL=0.311, 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 W1xmQT3sdN8f for ; Wed, 30 Nov 2011 16:29:20 -0800 (PST) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3F511E8081 for ; Wed, 30 Nov 2011 16:29:19 -0800 (PST) Received: from mail.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id pB10TGHV019123 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 1 Dec 2011 01:29:16 +0100 (MET) From: Martin Rex Message-Id: <201112010029.pB10TG1I010854@fs4113.wdf.sap.corp> To: jsalowey@cisco.com (Joe Salowey) Date: Thu, 1 Dec 2011 01:29:16 +0100 (MET) In-Reply-To: <83501846-AB99-4F88-98DB-122C96F2AA39@cisco.com> from "Joe Salowey" at Nov 30, 11 01:43:48 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] Consensus for adoption of draft-wouters-tls-oob-pubkey-02 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, 01 Dec 2011 00:29:21 -0000 Joe Salowey wrote: > > The chairs would like to confirm the consensus of the TLS working group > to adopt draft-wouters-tls-oob-pubkey-02 as a working group item. > > - Do you object to taking this draft on as working group item? > (Please state the reason for you objection) No objection. > > - Would you contribute time to review yes (some). > > and provide text for the document when needed? a little. -Martin From pgut001@login01.cs.auckland.ac.nz Wed Nov 30 19:52:43 2011 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 E8A7B21F87D9 for ; Wed, 30 Nov 2011 19:52:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTUJfcF+IEYs for ; Wed, 30 Nov 2011 19:52:43 -0800 (PST) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.12.44]) by ietfa.amsl.com (Postfix) with ESMTP id 20AC621F8753 for ; Wed, 30 Nov 2011 19:52:42 -0800 (PST) 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=1322711563; x=1354247563; h=from:to:subject:in-reply-to:message-id:date; bh=Y4eHxVEk3xrPu5A3fqL6207YRn3+u/6zzbRRNMG7A6Y=; b=j03Re9ENgBS0hk41wavxhuUk4xJfshMhzGTF6PD0yG/2p32spgldfyhT We2GR9tOl/jstFtbA9eGBK7L2Flg0ZITkHfk2aDbv2DYEvFPxaMQxYPSg WsL8ZneksqZttwhvdeCTfIrzGemfUBScJXHLSTrRK6zJtZ7ijzFgZJzTr 8=; X-IronPort-AV: E=Sophos;i="4.71,276,1320577200"; d="scan'208";a="92699558" X-Ironport-HAT: UNIVERSITY - $RELAY-THROTTLE X-Ironport-Source: 130.216.34.40 - Outgoing - Outgoing Received: from login01.fos.auckland.ac.nz ([130.216.34.40]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES256-SHA; 01 Dec 2011 16:52:29 +1300 Received: from pgut001 by login01.fos.auckland.ac.nz with local (Exim 4.69) (envelope-from ) id 1RVxhF-0001nB-3M; Thu, 01 Dec 2011 16:52:29 +1300 From: Peter Gutmann To: jsalowey@cisco.com, tls@ietf.org In-Reply-To: <107EC16E-ACCD-4DC7-A4F1-1EA5434C154C@cisco.com> Message-Id: Date: Thu, 01 Dec 2011 16:52:29 +1300 Subject: Re: [TLS] consensus on adopting draft-mcgrew-tls-aes-ccm and draft-mcgrew-tls-aes-ccm-ecc 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, 01 Dec 2011 03:52:44 -0000 Joe Salowey writes: >The chairs would like to see if there is consensus in the TLS working group >to adopt draft-mcgrew-tls-aes-ccm and draft-mcgrew-tls-aes-ccm-ecc as working >group items. These drafts define AES-CCM cipher suites for TLS. Oh, and while that's being done can I add a third one, draft-gutmann-tls- eccsuites-02.txt, available at http://tools.ietf.org/html/draft-gutmann-tls-eccsuites-02? This has already been discussed on the list in the past, there are interoperable implementations, it just needs to be moved to the RFC stage to get the necessary code points allocated. Peter. From zhou.sujing@zte.com.cn Wed Nov 30 23:16:35 2011 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 E6D6F11E80C1; Wed, 30 Nov 2011 23:16:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.79 X-Spam-Level: X-Spam-Status: No, score=-92.79 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 znslXo9Xj4aW; Wed, 30 Nov 2011 23:16:35 -0800 (PST) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 568DC11E80C0; Wed, 30 Nov 2011 23:16:34 -0800 (PST) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 417131745333492; Thu, 1 Dec 2011 15:10:14 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.15] with StormMail ESMTP id 12571.3095176024; Thu, 1 Dec 2011 15:16:20 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id pB17GAtm095546; Thu, 1 Dec 2011 15:16:10 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: <107EC16E-ACCD-4DC7-A4F1-1EA5434C154C@cisco.com> To: Joe Salowey MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Thu, 1 Dec 2011 15:16:00 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-12-01 15:16:12, Serialize complete at 2011-12-01 15:16:12 Content-Type: multipart/alternative; boundary="=_alternative 0027E24748257959_=" X-MAIL: mse02.zte.com.cn pB17GAtm095546 Cc: tls-bounces@ietf.org, tls@ietf.org Subject: [TLS] =?gb2312?b?tPC4tDogIGNvbnNlbnN1cyBvbiBhZG9wdGluZyBkcmFmdC1t?= =?gb2312?b?Y2dyZXctdGxzLWFlcy1jY20gYW5kCWRyYWZ0LW1jZ3Jldy10bHMtYWVzLWNj?= =?gb2312?b?bS1lY2M=?= 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, 01 Dec 2011 07:16:36 -0000 This is a multipart message in MIME format. --=_alternative 0027E24748257959_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 dGxzLWJvdW5jZXNAaWV0Zi5vcmcg0LTT2iAyMDExLTEyLTAxIDA1OjM0OjU5Og0KDQo+IFRoZSBj aGFpcnMgd291bGQgbGlrZSB0byBzZWUgaWYgdGhlcmUgaXMgY29uc2Vuc3VzIGluIHRoZSBUTFMg DQo+IHdvcmtpbmcgZ3JvdXAgdG8gYWRvcHQgZHJhZnQtbWNncmV3LXRscy1hZXMtY2NtIGFuZCBk cmFmdC1tY2dyZXctDQo+IHRscy1hZXMtY2NtLWVjYyBhcyB3b3JraW5nIGdyb3VwIGl0ZW1zLiAg VGhlc2UgZHJhZnRzIGRlZmluZSBBRVMtQ0NNDQo+IGNpcGhlciBzdWl0ZXMgZm9yIFRMUy4gIFRo ZSBaaWdiZWUgc21hcnQgZW5lcmd5IGdyb3VwIGhhcyBpbnRlcmVzdCANCj4gaW4gdGhlc2UgZHJh ZnRzLiAgIFRoZXNlIGRyYWZ0cyBvbmx5IGRlYWwgd2l0aCBhIEFFUy1DQ00gYW5kIG5vdCANCj4g d2l0aCBaaWdiZWUncyBBRVMtQ0NNKiB3aGljaCBpcyBhIHN1cGVyIHNldCBvZiBBRVMtQ0NNLiAg VGhlIGF1dGhvcnMNCj4gYXJlIHJlcXVlc3Rpbmcgc3RhbmRhcmRzIHRyYWNrIGZvciB0aGVzZSBj aXBoZXJzLiAgUGxlYXNlIG5vdGUgdGhhdCANCj4gdGhlcmUgaXMgYW4gSVBSIGRlY2xhcmF0aW9u IGxpc3RlZCBmb3IgZHJhZnQtbWNncmV3LXRscy1hZXMtY2NtLWVjYyANCj4gYXZhaWxhYmxlIGhl cmU6ICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8xNDQzLy4gIFRoaXMgDQo+IGRl Y2xhcmF0aW9uIGhhcyBiZWVuIHVwZGF0ZWQgZnJvbSBwcmV2aW91cyBkZWNsYXJhdGlvbnMuICAg UGxlYXNlIA0KPiByZXNwb25kIHRvIHRoZSBmb2xsb3dpbmcgYnkgRGVjZW1iZXIgMTQsIDIwMTEg Og0KPiANCj4gLSBEbyB5b3Ugb2JqZWN0IHRvIHRha2luZyB0aGVzZSBkcmFmdHMgb24gYXMgd29y a2luZyBncm91cCBpdGVtcz8gDQo+IChQbGVhc2Ugc3RhdGUgdGhlIHJlYXNvbiBmb3IgeW91IG9i amVjdGlvbikNCg0KTm8uDQoNCj4gDQo+IC0gV291bGQgeW91IGNvbnRyaWJ1dGUgdGltZSB0byBy ZXZpZXcgYW5kIHByb3ZpZGUgdGV4dCBmb3IgdGhlIA0KPiBkb2N1bWVudHMgd2hlbiBuZWVkZWQ/ DQoNClllcywgcGxlYXN1cmUuDQoNCj4gDQo+IC0gRG8geW91IG9iamVjdCB0byBzdGFuZGFyZHMg dHJhY2sgc3RhdHVzIGZvciB0aGVzZSBkb2N1bWVudHM/DQo+IChQbGVhc2Ugc3RhdGUgdGhlIHJl YXNvbiBmb3IgeW91IG9iamVjdGlvbikNCg0KTm8uDQoNCi1TdWppbmcgDQoNCj4gDQo+IA0KPiBD aGVlcnMsDQo+IA0KPiBKb2UNCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gVExTIG1haWxpbmcgbGlzdA0KPiBUTFNAaWV0Zi5vcmcNCj4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby90bHMNCj4gDQoNCg0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9y bWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlz IG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRo aXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBh Ym92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0 dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3Ro ZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNv bmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlk dWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVj ZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9m IHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhv c2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5u ZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 0027E24748257959_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PHR0Pjxmb250IHNpemU9Mj50bHMtYm91bmNlc0BpZXRmLm9yZyDQtNPaIDIwMTEtMTIt MDEgMDU6MzQ6NTk6PGJyPg0KPGJyPg0KJmd0OyBUaGUgY2hhaXJzIHdvdWxkIGxpa2UgdG8gc2Vl IGlmIHRoZXJlIGlzIGNvbnNlbnN1cyBpbiB0aGUgVExTIDxicj4NCiZndDsgd29ya2luZyBncm91 cCB0byBhZG9wdCBkcmFmdC1tY2dyZXctdGxzLWFlcy1jY20gYW5kIGRyYWZ0LW1jZ3Jldy08YnI+ DQomZ3Q7IHRscy1hZXMtY2NtLWVjYyBhcyB3b3JraW5nIGdyb3VwIGl0ZW1zLiAmbmJzcDtUaGVz ZSBkcmFmdHMgZGVmaW5lDQpBRVMtQ0NNPGJyPg0KJmd0OyBjaXBoZXIgc3VpdGVzIGZvciBUTFMu ICZuYnNwO1RoZSBaaWdiZWUgc21hcnQgZW5lcmd5IGdyb3VwIGhhcyBpbnRlcmVzdA0KPGJyPg0K Jmd0OyBpbiB0aGVzZSBkcmFmdHMuICZuYnNwOyBUaGVzZSBkcmFmdHMgb25seSBkZWFsIHdpdGgg YSBBRVMtQ0NNIGFuZA0Kbm90IDxicj4NCiZndDsgd2l0aCBaaWdiZWUncyBBRVMtQ0NNKiB3aGlj aCBpcyBhIHN1cGVyIHNldCBvZiBBRVMtQ0NNLiAmbmJzcDtUaGUNCmF1dGhvcnM8YnI+DQomZ3Q7 IGFyZSByZXF1ZXN0aW5nIHN0YW5kYXJkcyB0cmFjayBmb3IgdGhlc2UgY2lwaGVycy4gJm5ic3A7 UGxlYXNlIG5vdGUNCnRoYXQgPGJyPg0KJmd0OyB0aGVyZSBpcyBhbiBJUFIgZGVjbGFyYXRpb24g bGlzdGVkIGZvciBkcmFmdC1tY2dyZXctdGxzLWFlcy1jY20tZWNjDQo8YnI+DQomZ3Q7IGF2YWls YWJsZSBoZXJlOiAmbmJzcDtodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2lwci8xNDQzLy4g Jm5ic3A7VGhpcw0KPGJyPg0KJmd0OyBkZWNsYXJhdGlvbiBoYXMgYmVlbiB1cGRhdGVkIGZyb20g cHJldmlvdXMgZGVjbGFyYXRpb25zLiAmbmJzcDsgUGxlYXNlDQo8YnI+DQomZ3Q7IHJlc3BvbmQg dG8gdGhlIGZvbGxvd2luZyBieSBEZWNlbWJlciAxNCwgMjAxMSA6PGJyPg0KJmd0OyA8YnI+DQom Z3Q7IC0gRG8geW91IG9iamVjdCB0byB0YWtpbmcgdGhlc2UgZHJhZnRzIG9uIGFzIHdvcmtpbmcg Z3JvdXAgaXRlbXM/DQo8YnI+DQomZ3Q7IChQbGVhc2Ugc3RhdGUgdGhlIHJlYXNvbiBmb3IgeW91 IG9iamVjdGlvbik8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPk5vLjwv Zm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IC0g V291bGQgeW91IGNvbnRyaWJ1dGUgdGltZSB0byByZXZpZXcgYW5kIHByb3ZpZGUgdGV4dCBmb3Ig dGhlIDxicj4NCiZndDsgZG9jdW1lbnRzIHdoZW4gbmVlZGVkPzxicj4NCjwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+WWVzLCBwbGVhc3VyZS48L2ZvbnQ+PC90dD4NCjxicj4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyAtIERvIHlvdSBvYmplY3QgdG8gc3Rh bmRhcmRzIHRyYWNrIHN0YXR1cyBmb3IgdGhlc2UgZG9jdW1lbnRzPzxicj4NCiZndDsgKFBsZWFz ZSBzdGF0ZSB0aGUgcmVhc29uIGZvciB5b3Ugb2JqZWN0aW9uKTxicj4NCjwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Tm8uPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4tU3VqaW5nIDwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgQ2hlZXJzLDxicj4NCiZndDsgPGJyPg0KJmd0OyBK b2U8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KJmd0OyBUTFMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBUTFNAaWV0Zi5vcmc8YnI+ DQomZ3Q7IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vdGxzPGJyPg0KJmd0 OyA8YnI+DQo8L2ZvbnQ+PC90dD4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5i c3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtj b250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkm bmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6 YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJz cDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJz cDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZu YnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlz Y2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11 bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZu YnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJz cDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVs eSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZp ZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNw O2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNl aXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2Um bmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJz cDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJz cDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUm bmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMm bmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJz cDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3By ZT4= --=_alternative 0027E24748257959_=-- From zhou.sujing@zte.com.cn Wed Nov 30 23:29:05 2011 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 84CC711E8080; Wed, 30 Nov 2011 23:29:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.993 X-Spam-Level: X-Spam-Status: No, score=-96.993 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 S8Pl1IMfWs8O; Wed, 30 Nov 2011 23:29:04 -0800 (PST) Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 9AF2E21F84DF; Wed, 30 Nov 2011 23:29:03 -0800 (PST) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 566901745333492; Thu, 1 Dec 2011 15:14:40 +0800 (CST) Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 10892.3095176024; Thu, 1 Dec 2011 15:28:44 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id pB17SoVv014875; Thu, 1 Dec 2011 15:28:50 +0800 (GMT-8) (envelope-from zhou.sujing@zte.com.cn) In-Reply-To: <83501846-AB99-4F88-98DB-122C96F2AA39@cisco.com> To: Joe Salowey MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.6 March 06, 2007 Message-ID: From: zhou.sujing@zte.com.cn Date: Thu, 1 Dec 2011 15:28:35 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-12-01 15:28:52, Serialize complete at 2011-12-01 15:28:52 Content-Type: multipart/alternative; boundary="=_alternative 002916E848257959_=" X-MAIL: mse02.zte.com.cn pB17SoVv014875 Cc: tls-bounces@ietf.org, tls@ietf.org Subject: [TLS] =?gb2312?b?tPC4tDogIENvbnNlbnN1cyBmb3IgYWRvcHRpb24gb2YgZHJh?= =?gb2312?b?ZnQtd291dGVycy10bHMtb29iLXB1YmtleS0wMg==?= 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, 01 Dec 2011 07:29:05 -0000 This is a multipart message in MIME format. --=_alternative 002916E848257959_= Content-Type: text/plain; charset="US-ASCII" > The chairs would like to confirm the consensus of the TLS working > group to adopt draft-wouters-tls-oob-pubkey-02 as a working group > item. There was strong interest in this document at previous IETF > meetings and the controversial options dealing with only providing > public key hashes have been removed. Please respond to the > following questions by December 14, 2011: > > - Do you object to taking this draft on as working group item? > (Please state the reason for you objection) No. > > - Would you contribute time to review and provide text for the > document when needed? Yes. And currently there are two unclear descriptions to me: 1. Will client also send rawpublic key to server? although the aim of OOB is to reduce the size of transported server certificate, client will have to be affected according to this solution unless otherwise defined. 2. What will client do on receiving certificaterequest? Comparing received rawpublic key and stored public key bit by bit? But nomatterhow, definitly not " identical to the TLS specification" as described in this document. Regards. -Sujing > > Thanks, > > Joe > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 002916E848257959_= Content-Type: text/html; charset="US-ASCII"

> The chairs would like to confirm the consensus of the TLS working
> group to adopt draft-wouters-tls-oob-pubkey-02 as a working group
> item.  There was strong interest in this document at previous IETF
> meetings and the controversial options dealing with only providing
> public key hashes have been removed.   Please respond to the
> following questions by December 14, 2011:
>
> - Do you object to taking this draft on as working group item?
> (Please state the reason for you objection)
No.
>
> - Would you contribute time to review and provide text for the
> document when needed?
Yes.  

And currently there are two  unclear descriptions to me:
 1. Will client also send rawpublic key to server?
   although the aim of OOB is to reduce the size of transported server certificate, client will have to be affected according to this solution unless otherwise defined.
   
 2. What will client do on receiving  certificaterequest?
    Comparing received rawpublic key and stored public key bit by bit? But nomatterhow, definitly not " identical to the TLS specification" as described in this document.
Regards.


-Sujing

>
> Thanks,
>
> Joe
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
> 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 002916E848257959_=--