From tls-bounces@lists.ietf.org Sat Jul 01 01:36:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwY96-0000xM-R5; Sat, 01 Jul 2006 01:35:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwY96-0000xH-Bx for tls@ietf.org; Sat, 01 Jul 2006 01:35:56 -0400 Received: from web60924.mail.yahoo.com ([209.73.178.252]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FwY90-0008Ay-S6 for tls@ietf.org; Sat, 01 Jul 2006 01:35:56 -0400 Received: (qmail 61309 invoked by uid 60001); 1 Jul 2006 05:35:50 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=0oY2UE0kYmj/6i/s4OvtEfNMqASNUah8qdf1k7PfvFO1q/iWaZm3BngPnktsXwBFKo2Wq7sn9BaStL17uteVHfvmeg4KUVnEjuR1kIh5kD+iFyIYajNGa6GVjKwSKECajuYpT7uETJU7JvcXWQ37HYyomwHJidZHKRAli/HtE6Y= ; Message-ID: <20060701053550.61307.qmail@web60924.mail.yahoo.com> Received: from [208.110.21.131] by web60924.mail.yahoo.com via HTTP; Fri, 30 Jun 2006 22:35:50 PDT Date: Fri, 30 Jun 2006 22:35:50 -0700 (PDT) From: Ferianto siregar To: tls@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: Subject: [TLS] I got error message : [tls/tls_init.o] Error 1....Please help me..please X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Content-Type: multipart/mixed; boundary="===============2078993919==" Errors-To: tls-bounces@lists.ietf.org --===============2078993919== Content-Type: multipart/alternative; boundary="0-1837639505-1151732150=:59519" Content-Transfer-Encoding: 8bit --0-1837639505-1151732150=:59519 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Dear all, When i try to compile again TLS ( I have disabled Kerberos) by using Command ,TLS=1 make install, I got an error message. It is the error message : make: *** [tls/tls_init.o] Error 1 What should i do else? I am very confused. This is my first time to build TLS. Please help me..Please….. Note: Below is the message shown when i compile TLS support gcc -g -O9 -funroll-loops -Wcast-align -Wall -minline-all-stringops -malign-double - falign-loops -mcpu=athlon -DNAME='"openser"' -DVERSION='"1.0.1-tls"' -DARCH='"i386"' -DOS='"linux"' -DCOMPILER='"gcc 3.2.2"' -D__CPU_i386 -D__OS_linux -DCFG_DIR='"/usr/local/etc/openser/"' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DDNS_IP_HACK -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DF_MALLOC -DOPENSSL_NO_KRB5 -DUSE_TLS -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN -DHAVE_SCHED_YIELD -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL -DHAVE_ALLOCA_H -I/usr/local/ssl/include -c tls/tls_init.c -o tls/tls_init.o tls/tls_init.c:373:25: directives may not be used inside a macro argument tls/tls_init.c:372:56: unterminated argument list invoking macro "SSL_CTX_set_options" tls/tls_init.c: In function `init_ssl_ctx_behavior': tls/tls_init.c:376: `SSL_CTX_set_options' undeclared (first use in this function) tls/tls_init.c:376: (Each undeclared identifier is reported only once tls/tls_init.c:376: for each function it appears in.) tls/tls_init.c:376: parse error before ')' token make: *** [tls/tls_init.o] Error 1 Thank you very much. If I make any mistake...Please forgive me..Thanks Regards, Ferianto --------------------------------- Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1˘/min. --0-1837639505-1151732150=:59519 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Dear all,
 
When i try to compile again  TLS ( I have disabled Kerberos) by using Command ,TLS=1 make install, I got an error message.
It is the error message :
 
make: *** [tls/tls_init.o] Error 1
 
 What should i do else? I am very confused. This is my first time to build TLS. Please help me..Please…..
 
Note: Below is the message shown when i compile TLS support
 gcc -g -O9 -funroll-loops  -Wcast-align  -Wall   -minline-all-stringops -malign-double -         falign-loops -mcpu=athlon      -DNAME='"openser"' -DVERSION='"1.0.1-tls"' -DARCH='"i386"' -DOS='"linux"' -DCOMPILER='"gcc 3.2.2"' -D__CPU_i386 -D__OS_linux -DCFG_DIR='"/usr/local/etc/openser/"' -DPKG_MALLOC -DSHM_MEM  -DSHM_MMAP -DDNS_IP_HACK -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DF_MALLOC -DOPENSSL_NO_KRB5  -DUSE_TLS -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024  -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN -DHAVE_SCHED_YIELD -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL -DHAVE_ALLOCA_H -I/usr/local/ssl/include -c tls/tls_init.c -o tls/tls_init.o
tls/tls_init.c:373:25: directives may not be used inside a macro argument
tls/tls_init.c:372:56: unterminated argument list invoking macro "SSL_CTX_set_options"
tls/tls_init.c: In function `init_ssl_ctx_behavior':
tls/tls_init.c:376: `SSL_CTX_set_options' undeclared (first use in this function)
tls/tls_init.c:376: (Each undeclared identifier is reported only once
tls/tls_init.c:376: for each function it appears in.)
tls/tls_init.c:376: parse error before ')' token
make: *** [tls/tls_init.o] Error 1
 
Thank you very much. If I make any mistake...Please forgive me..Thanks
 Regards,
 
Ferianto

Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1˘/min. --0-1837639505-1151732150=:59519-- --===============2078993919== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============2078993919==-- From tls-bounces@lists.ietf.org Sat Jul 01 02:28:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwYyB-0006KX-DO; Sat, 01 Jul 2006 02:28:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwYy9-0006Jr-Cj for tls@ietf.org; Sat, 01 Jul 2006 02:28:41 -0400 Received: from nf-out-0910.google.com ([64.233.182.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwYsp-00036t-ED for tls@ietf.org; Sat, 01 Jul 2006 02:23:12 -0400 Received: by nf-out-0910.google.com with SMTP id g2so399129nfe for ; Fri, 30 Jun 2006 23:23:10 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gaAGoIgJdaTgkiQW5NhpiNjezgwNo1AV2uuX2jnuG4mm7TYKyy9tgvtozLPMN8KF4scSSnWxLSkOofVEH1fQI/C2LRQZneeXBkQmZoc8VYF6svg6j4BWpyZxb192Rd/7VtzRAoRmkrbNU5iB9ZEYKl30Y25uJXc2E0SozRVItdA= Received: by 10.48.217.16 with SMTP id p16mr821356nfg; Fri, 30 Jun 2006 23:23:10 -0700 (PDT) Received: by 10.48.164.3 with HTTP; Fri, 30 Jun 2006 23:23:10 -0700 (PDT) Message-ID: <6b9359640606302323s65b2a08dld707d222f1c3730d@mail.gmail.com> Date: Fri, 30 Jun 2006 23:23:10 -0700 From: "Kyle Hamilton" To: "Ferianto siregar" Subject: Re: [TLS] I got error message : [tls/tls_init.o] Error 1....Please help me..please In-Reply-To: <20060701053550.61307.qmail@web60924.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20060701053550.61307.qmail@web60924.mail.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org This is not a support mailing list. Please do not send requests for help with any given implementation here. This list is for the discussion of the underlying network protocol called TLS. Please obtain support from the software vendor, or software author's designated support mechanism. We cannot help you, here. -Kyle H On 6/30/06, Ferianto siregar wrote: > > Dear all, > > When i try to compile again TLS ( I have disabled Kerberos) by using > Command ,TLS=3D1 make install, I got an error message. > It is the error message : > > make: *** [tls/tls_init.o] Error 1 > > What should i do else? I am very confused. This is my first time to buil= d > TLS. Please help me..Please=85.. > > Note: Below is the message shown when i compile TLS support > gcc -g -O9 -funroll-loops -Wcast-align -Wall -minline-all-stringops > -malign-double - falign-loops -mcpu=3Dathlon -DNAME=3D'"open= ser"' > -DVERSION=3D'"1.0.1-tls"' -DARCH=3D'"i386"' -DOS=3D'"linux"' -DCOMPILER= =3D'"gcc > 3.2.2"' -D__CPU_i386 -D__OS_linux > -DCFG_DIR=3D'"/usr/local/etc/openser/"' -DPKG_MALLOC > -DSHM_MEM -DSHM_MMAP -DDNS_IP_HACK -DUSE_IPV6 -DUSE_MCAST -DUSE_TCP > -DDISABLE_NAGLE -DHAVE_RESOLV_RES -DF_MALLOC -DOPENSSL_NO_KRB5 -DUSE_TLS > -DFAST_LOCK -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=3D1024 > -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN -DHAVE_SCHED_YIELD > -DHAVE_MSG_NOSIGNAL -DHAVE_MSGHDR_MSG_CONTROL -DHAVE_ALLOCA_H > -I/usr/local/ssl/include -c tls/tls_init.c -o tls/tls_init.o > tls/tls_init.c:373:25: directives may not be used inside a macro argument > tls/tls_init.c:372:56: unterminated argument list invoking macro > "SSL_CTX_set_options" > tls/tls_init.c: In function `init_ssl_ctx_behavior': > tls/tls_init.c:376: `SSL_CTX_set_options' undeclared (first use in this > function) > tls/tls_init.c:376: (Each undeclared identifier is reported only once > tls/tls_init.c:376: for each function it appears in.) > tls/tls_init.c:376: parse error before ')' token > make: *** [tls/tls_init.o] Error 1 > > Thank you very much. If I make any mistake...Please forgive me..Thanks > > Regards, > > > Ferianto > > > ________________________________ > Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rate= s > starting at 1=A2/min. > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > > > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jul 01 03:18:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwZkI-0002oa-EW; Sat, 01 Jul 2006 03:18:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwZkH-0002lJ-1E for tls@lists.ietf.org; Sat, 01 Jul 2006 03:18:25 -0400 Received: from ug-out-1314.google.com ([66.249.92.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwZkF-00076R-Ls for tls@lists.ietf.org; Sat, 01 Jul 2006 03:18:25 -0400 Received: by ug-out-1314.google.com with SMTP id m3so1102502uge for ; Sat, 01 Jul 2006 00:18:23 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:cc:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=Gavi0aPDfkDWeY3ocd0IkRhP4OjKf1tIw56FcffhZPb5PZizdGx09QEBN3z3Liyz52nTwsI7CM1Nd3TL81f7YwJVjd3dFlxfZfJ9E2w5D0x4+t7N0+SRUVICbJnBdZQNdq+NDkPmHWb+LPWkUMuX5jQByRXG/Z+1jWm83YzkU7w= Received: by 10.67.101.10 with SMTP id d10mr3816221ugm; Sat, 01 Jul 2006 00:18:22 -0700 (PDT) Received: from ?172.16.1.227? ( [81.175.93.238]) by mx.gmail.com with ESMTP id w40sm1216240ugc.2006.07.01.00.18.22; Sat, 01 Jul 2006 00:18:22 -0700 (PDT) From: Nikos Mavrogiannopoulos To: Stephen Kent Date: Sat, 1 Jul 2006 09:18:20 +0200 User-Agent: KMail/1.9.1 References: <20060626203923.59F81222426@laser.networkresonance.com> <200606290020.10111.nmav@gnutls.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607010918.21080.nmav@gnutls.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: tls@lists.ietf.org Subject: [TLS] Re: Russ Housley: Fwd: problems with draft-ietf-tls-openpgp-keys-10.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Thu 29 Jun 2006 15:43, Stephen Kent wrote: > >> Each relying party is allowed to select the CAs that it views as > >> trust anchors. As a result, different RPs may have differing > >> views of the same PKI. Because a CA may have its key cross > >> certified by multiple other CAs, it is possible to create cert > >> paths that terminate at different trust anchors, depending on what > >> TAs a given relying party selects. All of these observations say > >> that X.509 and PKIX are NOT strictly hierarchic. > >Ok I see your point. I also noticed that hierarchical is used in > > several RFCs, to specify a specific form of hierarchy. So since > > this term is already common for this, would something like the > > following change address your concerns? > > At the time of writing, TLS [TLS] uses the PKIX [PKIX] > > infrastructure, to provide certificate services. Currently the > > PKIX protocols are limited to a structured certification model > > where only specific participants, the Certificate Authorities, are > > allowed to express trust. As a result, applications which follow > > more complex trust models, such as the web of trust, could not be > > benefited by TLS. > > That's better, but it still is pejorative and technically inaccurate > in its characterization of X.509/PKIX. Let me say why. > - a CA is a Certification Authority, not a Certificate > Authority, as per all the X.509 and PKIX standards. Corrected, thanks . > - anyone can be a CA, as my Windows XP example shows, so it > is unfair to suggest that the ability to ba a CA is somehow limited. > Thus the situation in X.509/PKIX is more or less the same as in OPGP, > i.e., if you can get other folks to "trust" you as a signer of certs, > then you can be a CA, period. The fact that the major, highly > visible, commercial CAs have established themselves as > widely-accepted trust anchors is not an intrinsic feature of > X.509/PKIX PKI standards. Anyone is free to configure any set of TAs > they want, as a purely local decision, just as OPGP users are free to > decide who they trust and to what extent. There a lots of practical issues that make the PKIX certificates unusable in "web of trust" implementations, and this is my point. Some of them are: * there is only one issuer per certificate * revocation is a capability of the issuer only and could be even more (given that X.509 was designed to support a hierarchically structured directory). Thus even if could be possible to implement web of trust with X.509 certificates, I'd need to send everytime n certificates (the number of the signers of my key), and I would not be able to revoke my key unless all of my signers agreed (discarding the fact that they'd need to publish a crl periodically :) This I believe makes the scheme impractical to use as a basis for a decentralized system such as the web of trust. (and I would consider it an abuse rather than a normal use of PKIX) Maybe in the future there are extensions to the PKIX to allow for the web of trust. But I'm describing the current situation. > considerations section. In particular, you should note that use of > PGP certs with an application will require a document analogous to > 2818 to explain how to use the certs being transported. Maybe the wording wasn't clear. Would an update to the security considerations text like the one below be more clear to you? Security considerations about the use of the web of trust or the key verification procedure are outside the scope of this document and are considered issues to be handled by the application layer protocols. regards, Nikos _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jul 01 07:49:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fwdym-0000lh-3H; Sat, 01 Jul 2006 07:49:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fwdyl-0000lP-Ff for tls@ietf.org; Sat, 01 Jul 2006 07:49:39 -0400 Received: from nf-out-0910.google.com ([64.233.182.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwdmB-00089H-Nv for tls@ietf.org; Sat, 01 Jul 2006 07:36:42 -0400 Received: by nf-out-0910.google.com with SMTP id g2so425477nfe for ; Sat, 01 Jul 2006 04:36:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PX7G3MRVfbbCNSkCSwlzIPI5IXuMGNQyJ2q+YG7Lc2ZAQ6QY/S5BLjgEUCznEU9LJoaI32MvQ5SMMCV/U8HJWukD2pBcdq7EiGlehOzFnfgzYlcKpsbxtJqnIZzu45K6w8idf2Yepeg8EXDrrJBjxOxJwPOF3P2eTW1TNa7EcR4= Received: by 10.48.43.11 with SMTP id q11mr943008nfq; Sat, 01 Jul 2006 04:36:38 -0700 (PDT) Received: by 10.48.164.3 with HTTP; Sat, 1 Jul 2006 04:36:38 -0700 (PDT) Message-ID: <6b9359640607010436l4728792qdfd988762d804fe2@mail.gmail.com> Date: Sat, 1 Jul 2006 04:36:38 -0700 From: "Kyle Hamilton" To: "Nikos Mavrogiannopoulos" , tls@ietf.org Subject: Re: [TLS] Re: Russ Housley: Fwd: problems with draft-ietf-tls-openpgp-keys-10.txt In-Reply-To: <200607010918.21080.nmav@gnutls.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060626203923.59F81222426@laser.networkresonance.com> <200606290020.10111.nmav@gnutls.org> <200607010918.21080.nmav@gnutls.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On 7/1/06, Nikos Mavrogiannopoulos wrote: > > Maybe the wording wasn't clear. Would an update to the security > considerations text like the one below be more clear to you? > > Security considerations about the use of the web of trust or > the key verification procedure are outside the scope of this > document and are considered issues to be handled by the > application layer protocols. Security considerations that have anything to do with identity key verification and entity mapping (pre-shared keys, PKIX, web-of-trust), and the corresponding authorization to use the application being protected, are outside the scope of this document. These are considered issues to be handled by the application layer protocols, or at the very least by the TLS implementation in accordance with key-interpretation protocols that are separately described. The use of cryptographic keys, and the cryptographic keys so used, can be exposed through a kernel or process memory dump or process debugging feature of many operating systems. This means that any entity who has access to kernel memory, process debugging, or perhaps even process-listing facilities may be able to subvert the entity identification procedures, and may be able to decrypt the data within any TLS session identified and authenticated with that private key if it is captured through such mechanisms. In addition, identity key processing and storage may be compromised through insecure backup procedures, insecure passing of identity key decryption information to processes, non-reset (i.e., non-zeroed) contents of memory blocks being allocated to other processes, privileged or physical access to the machine that the TLS implementation is running on, and other ways. These are issues which are implementation-specific, and only very basic suggestions can be given. For example, not all operating systems properly clear memory (or paging files) which is paged out or upon release of memory by a process back to the system. This suggests that identity key and session information could be kept in memory or on disk indefinitely. Because of this, applications and implementations should take care to clear or completely randomize any memory which contains key information when it is no longer needed, and to prevent paging of the key information if at all possible. If session information is cached (for example, to a database of some kind which can be used by other processes), it may be cached in a place where the implementation cannot exert complete control over the storage used. It is likely best in these situations to encrypt session data with a locally-known symmetric key [or perhaps a hybrid approach utilizing the public key corresponding to the private key used for identity] before writing it to the cache. This is particularly important with network-based caching systems, as database implementations may not adequately encrypt the data for transport and the network should be viewed as "insecure" as practically possible. As well, once sessions expire their data should be removed from the cache as soon as possible, in a manner designed to overwrite that data as destructively as possible. (For example, one could use an autocommited UPDATE command in SQL, and only then issue an autocommitted DELETE FROM command. This will not work with databases that have recovery capabilities, though, and application administrators are encouraged to look for means of forcing full commission and data backup from such databases' log files to the main database so that those log files may be removed as soon as practical.) At any time, specific algorithms may be discovered to have flaws. (At the time of this writing, the MD5 hash function is known to have serious weaknesses which permit an attacker to create hash collisions in a matter of seconds, and the same methods used to discover this attack are being utilized against other hashing algorithms.) Implementors and application administrators are encouraged to keep an eye on the cryptographic state of the art, and regularly review the security policies implemented within their software and on their hosts. Implementations with poor random number generation capabilities are known to have much more vulnerability, as the random numbers generated could have many fewer possible values than implementations with better random number generators. It is generally recommended to use a physical source of entropy (geiger-counted emissions, aerodynamic and thermodynamic properties of devices which produce unpredictable results, ambient room noise, and many others) when at all possible. It is VITAL that implementations NEVER REUSE ANY GIVEN ENTROPY, to make symmetric key-guessing and asymmetric private key calculation at least as difficult as the number of bits held within the key. Certain algorithms have "weak keys", and implementations of those algorithms should check generated keys against them and reject them as candidates for usage. The RSA asymmetric encryption system is known to be vulnerable to advances in factoring large numbers. In particular, the General Number Field Seive is being advanced slowly but inexorably. It is recommended that implementations move away from RSA for identity keys. Certain jurisdictions require the use of a limited set of algorithms (for example, the US Federal Government requires the use of AES for symmetric key operations, and a specific PNRG for random number generation). Implementations should allow the application administrator to remove supported cipher suites or to add only a specific list of known-good cipher suites for use, and to specify how entropy is generated for the algorithms used. ... Any thoughts on anything to add? -Kyle H _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jul 01 11:13:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwhAJ-0004K4-9s; Sat, 01 Jul 2006 11:13:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwhAI-0004Jz-9u for tls@ietf.org; Sat, 01 Jul 2006 11:13:46 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwhAH-00080z-Kz for tls@ietf.org; Sat, 01 Jul 2006 11:13:46 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 42E7C1E8C1C; Sat, 1 Jul 2006 08:13:44 -0700 (PDT) To: "Kyle Hamilton" Subject: Re: [TLS] Re: Russ Housley: Fwd: problems with draft-ietf-tls-openpgp-keys-10.txt References: <20060626203923.59F81222426@laser.networkresonance.com> <200606290020.10111.nmav@gnutls.org> <200607010918.21080.nmav@gnutls.org> <6b9359640607010436l4728792qdfd988762d804fe2@mail.gmail.com> From: Eric Rescorla Date: Sat, 01 Jul 2006 08:13:44 -0700 In-Reply-To: <6b9359640607010436l4728792qdfd988762d804fe2@mail.gmail.com> (Kyle Hamilton's message of "Sat, 1 Jul 2006 04:36:38 -0700") Message-ID: <86wtaxmk7r.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR 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: , Errors-To: tls-bounces@lists.ietf.org "Kyle Hamilton" writes: > On 7/1/06, Nikos Mavrogiannopoulos wrote: >> >> Maybe the wording wasn't clear. Would an update to the security >> considerations text like the one below be more clear to you? >> >> Security considerations about the use of the web of trust or >> the key verification procedure are outside the scope of this >> document and are considered issues to be handled by the >> application layer protocols. > > Security considerations that have anything to do with identity key > verification and entity mapping (pre-shared keys, PKIX, web-of-trust), > and the corresponding authorization to use the application being > protected, are outside the scope of this document. These are > considered issues to be handled by the application layer protocols, or > at the very least by the TLS implementation in accordance with > key-interpretation protocols that are separately described. I don't think any of the below material is really relevant here. It's just boilerplate that applies to any crypto protocol > The use of cryptographic keys, and the cryptographic keys so used, can > be exposed through a kernel or process memory dump or process > debugging feature of many operating systems. This means that any > entity who has access to kernel memory, process debugging, or perhaps > even process-listing facilities may be able to subvert the entity > identification procedures, and may be able to decrypt the data within > any TLS session identified and authenticated with that private key if > it is captured through such mechanisms. In addition, identity key > processing and storage may be compromised through insecure backup > procedures, insecure passing of identity key decryption information to > processes, non-reset (i.e., non-zeroed) contents of memory blocks > being allocated to other processes, privileged or physical access to > the machine that the TLS implementation is running on, and other ways. > These are issues which are implementation-specific, and only very > basic suggestions can be given. > > For example, not all operating systems properly clear memory (or > paging files) which is paged out or upon release of memory by a > process back to the system. This suggests that identity key and > session information could be kept in memory or on disk indefinitely. > Because of this, applications and implementations should take care to > clear or completely randomize any memory which contains key > information when it is no longer needed, and to prevent paging of the > key information if at all possible. If session information is cached > (for example, to a database of some kind which can be used by other > processes), it may be cached in a place where the implementation > cannot exert complete control over the storage used. It is likely > best in these situations to encrypt session data with a locally-known > symmetric key [or perhaps a hybrid approach utilizing the public key > corresponding to the private key used for identity] before writing it > to the cache. This is particularly important with network-based > caching systems, as database implementations may not adequately > encrypt the data for transport and the network should be viewed as > "insecure" as practically possible. > > As well, once sessions expire their data should be removed from the > cache as soon as possible, in a manner designed to overwrite that data > as destructively as possible. (For example, one could use an > autocommited UPDATE command in SQL, and only then issue an > autocommitted DELETE FROM command. This will not work with databases > that have recovery capabilities, though, and application > administrators are encouraged to look for means of forcing full > commission and data backup from such databases' log files to the main > database so that those log files may be removed as soon as practical.) > > At any time, specific algorithms may be discovered to have flaws. (At > the time of this writing, the MD5 hash function is known to have > serious weaknesses which permit an attacker to create hash collisions > in a matter of seconds, and the same methods used to discover this > attack are being utilized against other hashing algorithms.) > Implementors and application administrators are encouraged to keep an > eye on the cryptographic state of the art, and regularly review the > security policies implemented within their software and on their > hosts. > > Implementations with poor random number generation capabilities are > known to have much more vulnerability, as the random numbers generated > could have many fewer possible values than implementations with better > random number generators. It is generally recommended to use a > physical source of entropy (geiger-counted emissions, aerodynamic and > thermodynamic properties of devices which produce unpredictable > results, ambient room noise, and many others) when at all possible. > It is VITAL that implementations NEVER REUSE ANY GIVEN ENTROPY, to > make symmetric key-guessing and asymmetric private key calculation at > least as difficult as the number of bits held within the key. This is duplicative of RFC 1984. > Certain algorithms have "weak keys", and implementations of those > algorithms should check generated keys against them and reject them as > candidates for usage. In particular, this advice does not match with current TLS practice, which is NOT to check for weak keys. > The RSA asymmetric encryption system is known to be vulnerable to > advances in factoring large numbers. In particular, the General > Number Field Seive is being advanced slowly but inexorably. It is > recommended that implementations move away from RSA for identity keys. I don't agree with this recommendation. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jul 01 18:09:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fwnej-0004UX-Gm; Sat, 01 Jul 2006 18:09:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fwnei-0004UR-Un for tls@ietf.org; Sat, 01 Jul 2006 18:09:36 -0400 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fwneh-00015p-Li for tls@ietf.org; Sat, 01 Jul 2006 18:09:36 -0400 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id E32F4222426; Sat, 1 Jul 2006 15:17:44 -0700 (PDT) To: Pasi.Eronen@nokia.com Subject: Re: [TLS] Agenda time In-reply-to: Your message of "Wed, 21 Jun 2006 11:01:29 +0300." X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 19) Date: Sat, 01 Jul 2006 15:09:34 -0700 From: Eric Rescorla Message-Id: <20060701221744.E32F4222426@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org > TLS WG is scheduled to meet in Montreal (current slot: Tuesday > 1300-1500). > If you'd like to present something, drop a note to Eric and me. Here's what I have so far: Eric Rescorla draft-ietf-tls-rfc4346-bis-01.txt Nagendra Modadugu draft-ietf-tls-ctr-01.txt Andrea Doherty draft-linn-otp-tls-00.txt Yngve N. Petterson draft-pettersen-tls-interop-experience-00.txt Anyone else want a slot? -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jul 01 20:17:20 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fwpe6-0003Ny-Cu; Sat, 01 Jul 2006 20:17:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fwpe4-0003Nt-RX for tls@ietf.org; Sat, 01 Jul 2006 20:17:04 -0400 Received: from nf-out-0910.google.com ([64.233.182.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fwpe2-0008RV-9z for tls@ietf.org; Sat, 01 Jul 2006 20:17:04 -0400 Received: by nf-out-0910.google.com with SMTP id g2so496696nfe for ; Sat, 01 Jul 2006 17:17:01 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BGvBaYLuI47OFinGdK/QxgVlMU7XIQ+im8SuV2UczAUZQCAgdhxCc8bP6KSOFQtlhw9gfCAuQlP5UCLHhRTRGX7zy09QUs1sRbNdzVFzlp4w0xbKvL319GLIM3gAonGFEfMPGG92rg536Fdb58DKxMLMB0diWuJKS5oH1cwyYhk= Received: by 10.48.249.6 with SMTP id w6mr1291872nfh; Sat, 01 Jul 2006 17:17:01 -0700 (PDT) Received: by 10.48.12.19 with HTTP; Sat, 1 Jul 2006 17:17:01 -0700 (PDT) Message-ID: <6b9359640607011717m38702cdbi1d451b83409168ea@mail.gmail.com> Date: Sat, 1 Jul 2006 17:17:01 -0700 From: "Kyle Hamilton" To: EKR Subject: Re: [TLS] Re: Russ Housley: Fwd: problems with draft-ietf-tls-openpgp-keys-10.txt In-Reply-To: <86wtaxmk7r.fsf@raman.networkresonance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060626203923.59F81222426@laser.networkresonance.com> <200606290020.10111.nmav@gnutls.org> <200607010918.21080.nmav@gnutls.org> <6b9359640607010436l4728792qdfd988762d804fe2@mail.gmail.com> <86wtaxmk7r.fsf@raman.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On 7/1/06, Eric Rescorla wrote: > "Kyle Hamilton" writes: > > > On 7/1/06, Nikos Mavrogiannopoulos wrote: > >> > >> Maybe the wording wasn't clear. Would an update to the security > >> considerations text like the one below be more clear to you? > >> > >> Security considerations about the use of the web of trust or > >> the key verification procedure are outside the scope of this > >> document and are considered issues to be handled by the > >> application layer protocols. > > > > Security considerations that have anything to do with identity key > > verification and entity mapping (pre-shared keys, PKIX, web-of-trust), > > and the corresponding authorization to use the application being > > protected, are outside the scope of this document. These are > > considered issues to be handled by the application layer protocols, or > > at the very least by the TLS implementation in accordance with > > key-interpretation protocols that are separately described. > > I don't think any of the below material is really relevant > here. It's just boilerplate that applies to any crypto > protocol > > [...snip...] > > This is duplicative of RFC 1984. Then reference RFC 1984 in the Security Considerations section. I don't particularly care where they're written, but these are considerations which need to be taken into account by every TLS implementor and administrator -- and just because you already know about it does not mean that everyone else does. If someone decides to read up on how the TLS protocol works by reading the document (even if they're not implementing the protocol per se but even using it) it would be a good idea to put it in. > > Certain algorithms have "weak keys", and implementations of those > > algorithms should check generated keys against them and reject them as > > candidates for usage. > > In particular, this advice does not match with current TLS practice, > which is NOT to check for weak keys. It is a security consideration, and I present it for consideration as such. Let's consider the (admittedly unlikely, but also admittedly possible) case of DES with an all-zero key, or 3DES with an all-zero key. Surprise! Identity operation! Would you want /your/ medical or financial data protected over a network that had implementations that could possibly not encrypt it at all? Regardless of whether it meshes with current TLS practice, these are issues that need to be pointed out. I think it's absolutely barbaric that TLS is a security protocol, yet legitimate security concerns are being whitewashed because it doesn't mesh with "current practice". > > The RSA asymmetric encryption system is known to be vulnerable to > > advances in factoring large numbers. In particular, the General > > Number Field Seive is being advanced slowly but inexorably. It is > > recommended that implementations move away from RSA for identity keys. > > I don't agree with this recommendation. Would you care to express why? I've been looking at the research that's been put into the GNFS up to now, and measured its progress against Moore's Law. The results are... scary. If advancements in mathematics continue apace, we'll have problems very soon. Quoting from the abstract of http://scholar.lib.vt.edu/theses/available/etd-32298-93111/unrestricted/etd.pdf : [...]One of the most prominent systems for securing electronic information, known as RSA, relies upon the fact that it is computationally difficult to factor a "large" integer into its component prime integers. If an efficient algorithm is developed that can factor any arbitrarily large integer in a "reasonable" amount of time, the security value of the RSA system would be nullified. The General Number Field Sieve algorithm is the fastest known method for factoring large integers. Research and development of this algorithm within the past five years has facilitated factorizations of integers that were once speculated to require thousands of years of supercomputer time to accomplish. While this method has many unexplored features that merit further research, the complexity of the algorithm prevents almost anyone but an expert from investigating its behavior. We address this concern by first pulling together much of the background information necessary to understand the concepts that are central in the General Number Field Sieve. These concepts are woven together into a cohesive presentation that details each theory while clearly describing how a particular theory fits into the algorithm. Formal proofs from existing literature are recast and illuminated to clarify their inner-workings and the role they play in the whole process. We also present a complete, detailed example of a factorization achieved with the General Number Field Sieve in order to concretize the concepts that are outlined. [end quote] Let's figure out the number of digits in any given keysize: 8 bit = 3 (max value "256") 16 bit = 5 (max value "16535") 32 bit = 10 (max value = "4294967296") 64 bit = 20 (max value = "18446744073709551616") 128 bit = 39 256 bit = 78 384 bit = 116 512 bit = 155 768 bit = 232 1024 bit = 309 2048 bit = 617 4096 bit = 1234 The largest RSA composite number ever known to be factored was 200 digits long. (Source: http://www.crypto-world.com/FactorAnnouncements.html ) This was announced in May 2005, and took from "shortly before Christmas 2003" to October 2004 (about 10 months), plus December 2004 to May 2005 (about 6 months). This took about 170 Pentium 1GHz CPU-years, and approximately (with their clusters) 80 machines working for those 16 months. This means that 768 bit general RSA is in sight (if Moore's Law continues to hold and advances in factoring mathematics continue unabated, it should be less than 3 years from now before a 768-bit RSA composite is factored). The largest number ever factored by the special number sieve was 274 digits long. This is larger than 768-bit RSA, and suggests that 1024-bit RSA composites that are of the special form could be factorable at this point or in the fairly near future. This is why I recommend exploring options other than RSA for identity keys. Why do you disagree with this recommendation? -Kyle H _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jul 01 20:50:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwqAE-0002gC-8B; Sat, 01 Jul 2006 20:50:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwqAD-0002g7-2Y for tls@ietf.org; Sat, 01 Jul 2006 20:50:17 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwqAA-00037s-Cl for tls@ietf.org; Sat, 01 Jul 2006 20:50:17 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 55A451E8C1C; Sat, 1 Jul 2006 17:50:13 -0700 (PDT) To: "Kyle Hamilton" Subject: Re: [TLS] Re: Russ Housley: Fwd: problems with draft-ietf-tls-openpgp-keys-10.txt References: <20060626203923.59F81222426@laser.networkresonance.com> <200606290020.10111.nmav@gnutls.org> <200607010918.21080.nmav@gnutls.org> <6b9359640607010436l4728792qdfd988762d804fe2@mail.gmail.com> <86wtaxmk7r.fsf@raman.networkresonance.com> <6b9359640607011717m38702cdbi1d451b83409168ea@mail.gmail.com> From: Eric Rescorla Date: Sat, 01 Jul 2006 17:50:13 -0700 In-Reply-To: <6b9359640607011717m38702cdbi1d451b83409168ea@mail.gmail.com> (Kyle Hamilton's message of "Sat, 1 Jul 2006 17:17:01 -0700") Message-ID: <86psgoj0e2.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR 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: , Errors-To: tls-bounces@lists.ietf.org "Kyle Hamilton" writes: > On 7/1/06, Eric Rescorla wrote: >> "Kyle Hamilton" writes: >> >> > On 7/1/06, Nikos Mavrogiannopoulos wrote: >> >> >> >> Maybe the wording wasn't clear. Would an update to the security >> >> considerations text like the one below be more clear to you? >> >> >> >> Security considerations about the use of the web of trust or >> >> the key verification procedure are outside the scope of this >> >> document and are considered issues to be handled by the >> >> application layer protocols. >> > >> > Security considerations that have anything to do with identity key >> > verification and entity mapping (pre-shared keys, PKIX, web-of-trust), >> > and the corresponding authorization to use the application being >> > protected, are outside the scope of this document. These are >> > considered issues to be handled by the application layer protocols, or >> > at the very least by the TLS implementation in accordance with >> > key-interpretation protocols that are separately described. >> >> I don't think any of the below material is really relevant >> here. It's just boilerplate that applies to any crypto >> protocol >> >> [...snip...] >> >> This is duplicative of RFC 1984. > > Then reference RFC 1984 in the Security Considerations section. I > don't particularly care where they're written, but these are > considerations which need to be taken into account by every TLS > implementor and administrator -- and just because you already know > about it does not mean that everyone else does. If someone decides to > read up on how the TLS protocol works by reading the document (even if > they're not implementing the protocol per se but even using it) it > would be a good idea to put it in. No. RFC 4346 already has a reference to RFC 4096 (the current randomness requirements RFC). Implementors of this document would clearly need to read RFC 4346 and the security considerations section of that document is included by reference. The security considerations section of this document only needs to cover issues which are different from those in 4346. >> > Certain algorithms have "weak keys", and implementations of those >> > algorithms should check generated keys against them and reject them as >> > candidates for usage. >> >> In particular, this advice does not match with current TLS practice, >> which is NOT to check for weak keys. > > It is a security consideration, and I present it for consideration as > such. Let's consider the (admittedly unlikely, but also admittedly > possible) case of DES with an all-zero key, or 3DES with an all-zero > key. Surprise! Identity operation! Would you want /your/ medical or > financial data protected over a network that had implementations that > could possibly not encrypt it at all? Yes, I'm quite familiar with the issue. And yes, I'm quite comfortable with the current situation. > Regardless of whether it meshes with current TLS practice, these are > issues that need to be pointed out. I think it's absolutely barbaric > that TLS is a security protocol, yet legitimate security concerns are > being whitewashed because it doesn't mesh with "current practice". The concerns aren't being "whitewashed". The debate over whether one should do weak key detection in protocols has a very long history which I don't intend to reprise here other than to note that the discussion usually focuses on the extremely low probability of a random key being weak balanced against the complexity of weak key checks. See this message on IPsec if you're interested in the flavor of the debate: http://www.sandelman.ca/ipsec/2000/01/msg00113.html TLS embodies a deliberate design choice not to check for weak keys. You may not happen to agree with that, but it's not something that's likely to change and certainly not appropriate to change it in the security considerations of a new TLS ciphersuite advancing outside the standards track. I'd certainly be happy to include some text explaining the weak key issue and TLS's choice not to check for them in 4346bis, however. >> > The RSA asymmetric encryption system is known to be vulnerable to >> > advances in factoring large numbers. In particular, the General >> > Number Field Seive is being advanced slowly but inexorably. It is >> > recommended that implementations move away from RSA for identity keys. >> >> I don't agree with this recommendation. > [comments about GNFS deleted] > The largest number ever factored by the special number sieve was 274 > digits long. This is larger than 768-bit RSA, and suggests that > 1024-bit RSA composites that are of the special form could be > factorable at this point or in the fairly near future. > > This is why I recommend exploring options other than RSA for identity > keys. Why do you disagree with this recommendation? You didn't recommend "exploring" it. You recommended that implementations move away from it, which isn't the same thing at all. Yes, 768 bit keys are almost certainly not safe for long-term use, but that doesn't mean that RSA isn't safe, just that you need longer key sizes (the Lenstra recommendation [0] is 1568 bits for security through 2020). I'd have no problem with a recommendation that people study the Lenstra recommendations (or other well-sourced recommendations and choose key lengths appropriately, but a blanket statment that they should move away from RSA is not appropriate. That said, I consider the focus on key length to be generally misguided, as it's far from the easiest way to recover the private key. Remotely compromising the server in question and recovering the private key directly is generally easier, and given the amounts of money involved in mounting a credible attack on even a modest-length key (e.g., 1024 bits), it would generally be far more cost effective to simply mount a social engineering or physical attack on the server in question. Yes, it's important to have a strong key, but for nearly all commercial uses it's not plausible that an NSA-scale attacker is going to spend 2 years trying to factor your RSA modulus. -Ekr [0] http://www.keylength.com/ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Jul 01 21:09:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwqTB-0005wR-UQ; Sat, 01 Jul 2006 21:09:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwqTB-0005wM-Be for tls@ietf.org; Sat, 01 Jul 2006 21:09:53 -0400 Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwqT8-0003S7-UU for tls@ietf.org; Sat, 01 Jul 2006 21:09:53 -0400 Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 26B61FB2D6; Sun, 2 Jul 2006 01:09:50 +0000 (UTC) Received: by berkshire.machshav.com (Postfix, from userid 54047) id 775333C049B; Sat, 1 Jul 2006 21:09:48 -0400 (EDT) Date: Sat, 1 Jul 2006 21:09:48 -0400 From: "Steven M. Bellovin" To: "Kyle Hamilton" Subject: Re: [TLS] Re: Russ Housley: Fwd: problems with draft-ietf-tls-openpgp-keys-10.txt Message-Id: <20060701210948.e41c5c5b.smb@cs.columbia.edu> In-Reply-To: <6b9359640607011717m38702cdbi1d451b83409168ea@mail.gmail.com> References: <20060626203923.59F81222426@laser.networkresonance.com> <200606290020.10111.nmav@gnutls.org> <200607010918.21080.nmav@gnutls.org> <6b9359640607010436l4728792qdfd988762d804fe2@mail.gmail.com> <86wtaxmk7r.fsf@raman.networkresonance.com> <6b9359640607011717m38702cdbi1d451b83409168ea@mail.gmail.com> Organization: Columbia University X-Mailer: Sylpheed version 2.2.6 (GTK+ 2.8.19; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Sat, 1 Jul 2006 17:17:01 -0700, "Kyle Hamilton" wrote: > > The largest RSA composite number ever known to be factored was 200 > digits long. (Source: > http://www.crypto-world.com/FactorAnnouncements.html ) This was > announced in May 2005, and took from "shortly before Christmas 2003" > to October 2004 (about 10 months), plus December 2004 to May 2005 > (about 6 months). This took about 170 Pentium 1GHz CPU-years, and > approximately (with their clusters) 80 machines working for those 16 > months. This means that 768 bit general RSA is in sight (if Moore's > Law continues to hold and advances in factoring mathematics continue > unabated, it should be less than 3 years from now before a 768-bit RSA > composite is factored). > > The largest number ever factored by the special number sieve was 274 > digits long. This is larger than 768-bit RSA, and suggests that > 1024-bit RSA composites that are of the special form could be > factorable at this point or in the fairly near future. > > This is why I recommend exploring options other than RSA for identity > keys. Why do you disagree with this recommendation? > The effort with GNFS is not linear in modulus length; furthermore, a lot of memory is needed for the row reduction. Have a look at sections 2.4 and 2.5 of RFC 3766. Also see table 5, and note that an 8719-bit modulus is roughly equivalent to a 200-bit symmetric key, which NSA rates as suitable for Top Secret data. That said, I agree that 1024-bit RSA is not suitable for protecting long-lived secrets. 2048-bit or 3072-bit RSA seems *way* out of reach, barring a major theoretical breakthrough in factoring algorithsm. I won't even engage in guessing games about when Moore's Law will break down, but I think we can agree that transistors smaller than a single atom are, shall we say, unlikely, and that puts an upper bound on density no matter what we do. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Jul 02 12:39:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fx4ye-0008Ph-Kr; Sun, 02 Jul 2006 12:39:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fx4yc-0008JT-SR for tls@ietf.org; Sun, 02 Jul 2006 12:39:18 -0400 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fx4yb-000134-II for tls@ietf.org; Sun, 02 Jul 2006 12:39:18 -0400 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id DE385222425 for ; Sun, 2 Jul 2006 09:47:26 -0700 (PDT) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 19) Date: Sun, 02 Jul 2006 09:39:17 -0700 From: Eric Rescorla Message-Id: <20060702164726.DE385222425@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Subject: [TLS] Comments on draft-linn-otp-tls-00 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org I've given this document a quick read. Comments follow. 1. Calling this an OTP mechanism is kind of confusing because the IETF already has a standard for OTP (RFC 2289) based on S/Key. Because the RFC 2289 scheme relies on the server storing the output of a digest and the client providing the preimage, it cannot be used with the mechanism in this draft. At minimum, you need to have a section explaining that only systems in which both client and server can generate the same password sequence can be used here and preferably a name change would be appropriate. 2. I'm very uncomfortable with retroactively changing the meaning of psk_identity--without any external signalling as far as I can tell. That doesn't seem like a good plan at all. 3. The new PSK identity encoding should be expressed using standard TLS structures, not an ASCII encoding. This comment applies both to how to pack the structures and how to represent the time, which should be a 32-bit integer in accordance with TLS standard practice. 4. In S 3.3.2, what happens if I want to offer multiple otp_algorithms? Impossible. 5. In S 3.3.3, making iteration_count a uint16 seems unwise. Better to future proof and make it a uint32. 6. I'm very uncomfortable with creating all these alerts. Note that the TLS alert space is only 8 bits wide. Note also that per RFC 4346 Alerts can only be created by Standards action. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jul 03 10:20:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxPHy-0003xX-A7; Mon, 03 Jul 2006 10:20:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxPHx-0003xS-LM for tls@ietf.org; Mon, 03 Jul 2006 10:20:37 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxPHw-00009J-9e for tls@ietf.org; Mon, 03 Jul 2006 10:20:37 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id QAA04787; Mon, 3 Jul 2006 16:20:28 +0200 (MESZ) From: Martin Rex Message-Id: <200607031420.QAA06616@uw1048.wdf.sap.corp> Subject: Re: [TLS] Re: Russ Housley: Fwd: problems with To: ekr@networkresonance.com Date: Mon, 3 Jul 2006 16:20:21 +0200 (MET DST) In-Reply-To: <86psgoj0e2.fsf@raman.networkresonance.com> from "Eric Rescorla" at Jul 1, 6 05:50:13 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@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: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla wrote: > > >> In particular, this advice does not match with current TLS practice, > >> which is NOT to check for weak keys. > > > > It is a security consideration, and I present it for consideration as > > such. Let's consider the (admittedly unlikely, but also admittedly > > possible) case of DES with an all-zero key, or 3DES with an all-zero > > key. Surprise! Identity operation! Would you want /your/ medical or > > financial data protected over a network that had implementations that > > could possibly not encrypt it at all? > > Yes, I'm quite familiar with the issue. And yes, I'm quite comfortable > with the current situation. Although the existing SSL/TLS specs do not define how to synchronously skip/drop weak keys during key generation upfront and synchronously, wouldn't it be possible for either side (when the particular implementations feels such a need) to detect a weak key and force the peer directly through a renegotiate -- even old peers? -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jul 03 10:33:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxPUQ-000583-Uz; Mon, 03 Jul 2006 10:33:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxPUO-00054z-K0 for tls@ietf.org; Mon, 03 Jul 2006 10:33:28 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxPUN-0000Te-A0 for tls@ietf.org; Mon, 03 Jul 2006 10:33:28 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id ABCA81E8C1C; Mon, 3 Jul 2006 07:33:26 -0700 (PDT) To: martin.rex@sap.com Subject: Re: [TLS] Re: Russ Housley: Fwd: problems with References: <200607031420.QAA06616@uw1048.wdf.sap.corp> From: Eric Rescorla Date: Mon, 03 Jul 2006 07:33:26 -0700 In-Reply-To: <200607031420.QAA06616@uw1048.wdf.sap.corp> (Martin Rex's message of "Mon, 3 Jul 2006 16:20:21 +0200 (MET DST)") Message-ID: <86hd1ybvwp.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR 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: , Errors-To: tls-bounces@lists.ietf.org Martin Rex writes: > Eric Rescorla wrote: >> >> >> In particular, this advice does not match with current TLS practice, >> >> which is NOT to check for weak keys. >> > >> > It is a security consideration, and I present it for consideration as >> > such. Let's consider the (admittedly unlikely, but also admittedly >> > possible) case of DES with an all-zero key, or 3DES with an all-zero >> > key. Surprise! Identity operation! Would you want /your/ medical or >> > financial data protected over a network that had implementations that >> > could possibly not encrypt it at all? >> >> Yes, I'm quite familiar with the issue. And yes, I'm quite comfortable >> with the current situation. > > Although the existing SSL/TLS specs do not define how to synchronously > skip/drop weak keys during key generation upfront and synchronously, > wouldn't it be possible for either side (when the particular implementations > feels such a need) to detect a weak key and force the peer directly > through a renegotiate -- even old peers? Sure. Except that the other side can refuse to renegotiate and that there are deadlock conditions if you try to renegotiate at the wrong time.... -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jul 03 11:23:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxQH1-0000tq-Qo; Mon, 03 Jul 2006 11:23:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxQH0-0000ti-HT for tls@ietf.org; Mon, 03 Jul 2006 11:23:42 -0400 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxQGz-0005L8-4t for tls@ietf.org; Mon, 03 Jul 2006 11:23:42 -0400 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id RAA25871 for ; Mon, 3 Jul 2006 17:23:39 +0200 (MESZ) From: Martin Rex Message-Id: <200607031523.RAA09074@uw1048.wdf.sap.corp> Orig-To: tls@ietf.org To: tls@ietf.org Date: Tue, 27 Jun 2006 22:39:10 +0200 (MET DST) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-Spam-Score: 1.1 (+) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Subject: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@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: , Errors-To: tls-bounces@lists.ietf.org While privately discussing I-D draft-pettersen-tls-interop-experience-00.txt I came across what I consider a potential ambiguity in TLS v1.0 (rfc2246) and TLS v1.1 (rfc4346): Appendix E "Backward Compatibility With SSL" 2nd paragraph says this: TLS versions 1.1, 1.0, and SSL 3.0 are very similar; thus, supporting both is easy. TLS clients who wish to negotiate with such older servers SHOULD send client hello messages using the SSL 3.0 record format and client hello structure, sending {3, 2} for the version field to note that they support TLS 1.1. If the server supports only TLS 1.0 or SSL 3.0, it will respond with a downrev 3.0 server hello; if it supports TLS 1.1 it will respond with a TLS 1.1 server hello. The negotiation then proceeds as appropriate for the negotiated protocol. It should read instead ... servers SHOULD send client hello messages using the SSL 3.0 record format and client hello structure, sending {3, 2} for the client_version ^^^^^^^ because it ought to refer to the Protocol version field in the ClientHello message, and *NOT* the version field in the record layer. The comment in the OpenSSL code suggests that the Netscape 6.0 browser was the first defective SSL client to incorrectly use a {3, 1} version tag on the record protocol for the initial client hello, but it could be that others have copied this bug. Microsoft appears to be shipping a new variant of the bug with IIS, which erroneously sends the {3,1} tag in the record protocol when forcing an SSLv3 client through renegotiation in order to ask for an SSL client certificate _after_ reading the HTTP request over an anonymous SSL-client connection--which is kind of odd since the session is fully established as 3.0 and the Server Hello correctly contains 3.0... Btw. all previous TLS documents increased the TLS protocol version in Appendix A.1.1 / A.1, draft-ietf-tls-rfc4346-bis-01.txt hasn't yet done so. The ProtocolVersion tag on the SSL/TLS record protocol defines the encoding of the PDU, and therefore older implementations ought not even try to parse PDUs which they can not be expected to understand/recognize. Regards, -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jul 03 12:14:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxR4K-0001fB-5O; Mon, 03 Jul 2006 12:14:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxR4I-0001ev-Mh for tls@ietf.org; Mon, 03 Jul 2006 12:14:38 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxR4I-0000fp-5t for tls@ietf.org; Mon, 03 Jul 2006 12:14:38 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k63GEZB1021150; Mon, 3 Jul 2006 19:14:37 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Jul 2006 19:14:19 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Jul 2006 19:14:18 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt Date: Mon, 3 Jul 2006 19:14:15 +0300 Message-ID: In-Reply-To: <200607031523.RAA09074@uw1048.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt Thread-Index: AcaetMoHc3D/fCTQTwK+uYQnnNSJjAABMZ2Q From: To: , X-OriginalArrivalTime: 03 Jul 2006 16:14:18.0529 (UTC) FILETIME=[BC812110:01C69EBB] X-Spam-Score: 0.2 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Hi Martin, I agree that the spec is ambiguous in this respect, but I'm not so sure about what the correct interpretation should be. In=20 other words, when a TLS client supports more than one of (SSLv3, TLSv10, TLSv11), should the record layer version number contain the lowest supported protocol, or the same value as handshake layer ClientHello? A quick and totally unscientific survey of what some widely used SSL/TLS implementations do: - OpenSSL (0.9.8) - When configured in "both SSLv3 and TLSv10 allowed" mode, sends V2 ClientHello. - When configured in "TLS10 only" mode, sends {03,01} in both fields - Mozilla Firefox 1.5 - Seems to send V2 ClientHello no matter what the settings?? - MS Internet Explorer 6.0 - When configured in "both SSLv3 and TLSv1.0 allowed" mode, sends V3 ClientHello with {03,01} in both fields - SunJSSE (JDK 1.4.2) - When configured in "both SSLv3 and TLSv1.0 allowed" mode, sends V3 ClientHello with {03,01} in both fields - GnuTLS (10.0.20) - When configured in "both SSLv3 and TLSv1.0 allowed" mode, sends V3 ClientHello with {03,01} in both fields - When configured in "SSLv3, TLSv1.0 and TLSv1.1 allowed" mode, sends V3 ClientHello with {03,02} in both fields In other words: All these implementation seem to follow the rule that TLSPlaintext.version=3D=3DClientHello.client_version, or use V2 ClientHellos... Given that Yngve's interoperability draft suggests that some servers incorrectly use the record layer version number for negotiation, I think the safest clarification would be to=20 say that the two version numbers must be equal. Best regards, Pasi > -----Original Message----- > From: ext Martin Rex [mailto:martin.rex@sap.com]=20 > Sent: 27 June, 2006 23:39 > To: tls@ietf.org > Subject: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt >=20 >=20 > While privately discussing I-D=20 > draft-pettersen-tls-interop-experience-00.txt > I came across what I consider a potential ambiguity in TLS=20 > v1.0 (rfc2246) > and TLS v1.1 (rfc4346): >=20 >=20 > Appendix E "Backward Compatibility With SSL" 2nd paragraph says this: >=20 > TLS versions 1.1, 1.0, and SSL 3.0 are very similar; thus,=20 > supporting > both is easy. TLS clients who wish to negotiate with such older > servers SHOULD send client hello messages using the SSL 3.0 record > format and client hello structure, sending {3, 2} for the version > field to note that they support TLS 1.1. If the server=20 > supports only > TLS 1.0 or SSL 3.0, it will respond with a downrev 3.0=20 > server hello; > if it supports TLS 1.1 it will respond with a TLS 1.1 server hello. > The negotiation then proceeds as appropriate for the negotiated > protocol. >=20 > It should read instead >=20 > ... > servers SHOULD send client hello messages using the SSL 3.0 record > format and client hello structure, sending {3, 2} for the=20 > client_version > ^^^^^^^ >=20 > because it ought to refer to the Protocol version field in the > ClientHello message, and *NOT* the version field in the record layer. >=20 > The comment in the OpenSSL code suggests that the Netscape 6.0 browser > was the first defective SSL client to incorrectly use a {3, 1} > version tag on the record protocol for the initial client hello, > but it could be that others have copied this bug. >=20 > Microsoft appears to be shipping a new variant of the bug with IIS, > which erroneously sends the {3,1} tag in the record protocol when > forcing an SSLv3 client through renegotiation in order to ask for > an SSL client certificate _after_ reading the HTTP request over > an anonymous SSL-client connection--which is kind of odd since > the session is fully established as 3.0 and the Server Hello > correctly contains 3.0... >=20 >=20 > Btw. all previous TLS documents increased the TLS protocol version > in Appendix A.1.1 / A.1, draft-ietf-tls-rfc4346-bis-01.txt hasn't > yet done so. >=20 >=20 > The ProtocolVersion tag on the SSL/TLS record protocol defines > the encoding of the PDU, and therefore older implementations > ought not even try to parse PDUs which they can not be expected to > understand/recognize. >=20 >=20 > Regards, > -Martin > =20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls >=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jul 03 13:09:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxRva-0000oz-Ul; Mon, 03 Jul 2006 13:09:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxRvZ-0000ou-MO for tls@ietf.org; Mon, 03 Jul 2006 13:09:41 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxRvZ-0003m1-8z for tls@ietf.org; Mon, 03 Jul 2006 13:09:41 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id TAA08910; Mon, 3 Jul 2006 19:09:37 +0200 (MESZ) From: Martin Rex Message-Id: <200607031708.TAA13289@uw1048.wdf.sap.corp> Subject: Re: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt To: Pasi.Eronen@nokia.com Date: Mon, 3 Jul 2006 19:08:59 +0200 (MET DST) In-Reply-To: from "Pasi.Eronen@nokia.com" at Jul 3, 6 07:14:15 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@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: , Errors-To: tls-bounces@lists.ietf.org Pasi.Eronen@nokia.com wrote: > > I agree that the spec is ambiguous in this respect, but I'm not > so sure about what the correct interpretation should be. In > other words, when a TLS client supports more than one of (SSLv3, > TLSv10, TLSv11), should the record layer version number contain > the lowest supported protocol, or the same value as handshake > layer ClientHello? It SHOULD contain the lowest protocol version that the client is willing to negotiate. Anything else is going to cause interoperability problems. The most interesing question: what does the installed base do today when it receives a client hello with a 3.2 or even 3.3 or 3.4 version the "version" field of the SSL/TLS record protocol AND in the client_version of the ClientHello message. I expect some servers to choke heavily (and rightfully). The potential ambiguity is only for the casual reader, there definitely never was an abiguity for the careful protocol implementor. The SSLv3 spec (which somewhat happened after the fact) does not contain any ambiguity either, because it doesn't define anything other than {3, 0} PDUs and version numbers. The root of any ambiguity is that the spec fails to clearly seperare version tags for the purpose of negotation (client_version, server_version) and version tags (version) that indicates a particular PDU encoding. The description of the PDUs in the appendix of SSL/TLS specs contains the protocol version in exactly three distinct variants: version client_version (only in ClientHello and PreMasterSecret) server_version (only in ServerHello) All existing specs were NOT ambiguous in that exactly one field was supposed to contain the negotiated version number. And from the description of the individual PDUs in Appendix A, it should have been obvious to implementors which version field should have been meant, and which one should not have been meant. There are very few error-free specs, and this particular error (and the correct wording) are fairly easy to figure, IMHO. > > A quick and totally unscientific survey of what some widely used > SSL/TLS implementations do: > > - OpenSSL (0.9.8) > - When configured in "both SSLv3 and TLSv10 allowed" mode, > sends V2 ClientHello. fine. > - When configured in "TLS10 only" mode, sends {03,01} in both fields fine. > - Mozilla Firefox 1.5 > - Seems to send V2 ClientHello no matter what the settings?? fine. > - MS Internet Explorer 6.0 > - When configured in "both SSLv3 and TLSv1.0 allowed" mode, > sends V3 ClientHello with {03,01} in both fields broken. > - SunJSSE (JDK 1.4.2) > - When configured in "both SSLv3 and TLSv1.0 allowed" mode, > sends V3 ClientHello with {03,01} in both fields broken. > - GnuTLS (10.0.20) > - When configured in "both SSLv3 and TLSv1.0 allowed" mode, > sends V3 ClientHello with {03,01} in both fields broken. > - When configured in "SSLv3, TLSv1.0 and TLSv1.1 allowed" mode, > sends V3 ClientHello with {03,02} in both fields broken. > > In other words: All these implementation seem to follow the > rule that TLSPlaintext.version==ClientHello.client_version, or > use V2 ClientHellos... Didn't you just say that OpenSSL and Mozilla used a correct behaviour on the client side? The more interesting question is what SSL/TLS servers do upon receipt, and in particular what they do upon receipt of a high up version number, like {03,03} or {03,04}. > > Given that Yngve's interoperability draft suggests that some > servers incorrectly use the record layer version number for > negotiation, I think the safest clarification would be to > say that the two version numbers must be equal. The clarification should say that there's an awfully large installed base that is broken and that the server will likely have to entirely ignore the version number in the record protocol when processing a ClientHello message, and upons sending, should send the lowest version number that they're willing to use. This makes protocol layering not as independent as it should be. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jul 03 13:16:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxS2U-00027C-6r; Mon, 03 Jul 2006 13:16:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxS2S-000276-Ho for tls@ietf.org; Mon, 03 Jul 2006 13:16:48 -0400 Received: from smtp-out4.blueyonder.co.uk ([195.188.213.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxS2R-0003wx-5Z for tls@ietf.org; Mon, 03 Jul 2006 13:16:48 -0400 Received: from [172.23.170.138] (helo=anti-virus01-09) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1FxS2Q-0000t8-Dv for tls@ietf.org; Mon, 03 Jul 2006 18:16:46 +0100 Received: from 82-42-16-20.cable.ubr01.knor.blueyonder.co.uk ([82.42.16.20] helo=[127.0.0.1]) by asmtp-out3.blueyonder.co.uk with esmtp (Exim 4.52) id 1FxS2P-0007wF-UA for tls@ietf.org; Mon, 03 Jul 2006 18:16:46 +0100 Message-ID: <44A950EE.90504@blueyonder.co.uk> Date: Mon, 03 Jul 2006 18:16:30 +0100 From: David Hopwood User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: david.nospam.hopwood@blueyonder.co.uk 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: , Errors-To: tls-bounces@lists.ietf.org Pasi.Eronen@nokia.com wrote: > Hi Martin, > > I agree that the spec is ambiguous in this respect, but I'm not > so sure about what the correct interpretation should be. In > other words, when a TLS client supports more than one of (SSLv3, > TLSv10, TLSv11), should the record layer version number contain > the lowest supported protocol, or the same value as handshake > layer ClientHello? > > A quick and totally unscientific survey of what some widely used > SSL/TLS implementations do: > > - OpenSSL (0.9.8) > - When configured in "both SSLv3 and TLSv10 allowed" mode, > sends V2 ClientHello. > - When configured in "TLS10 only" mode, sends {03,01} in both fields > - Mozilla Firefox 1.5 > - Seems to send V2 ClientHello no matter what the settings?? > - MS Internet Explorer 6.0 > - When configured in "both SSLv3 and TLSv1.0 allowed" mode, > sends V3 ClientHello with {03,01} in both fields > - SunJSSE (JDK 1.4.2) > - When configured in "both SSLv3 and TLSv1.0 allowed" mode, > sends V3 ClientHello with {03,01} in both fields > - GnuTLS (10.0.20) > - When configured in "both SSLv3 and TLSv1.0 allowed" mode, > sends V3 ClientHello with {03,01} in both fields > - When configured in "SSLv3, TLSv1.0 and TLSv1.1 allowed" mode, > sends V3 ClientHello with {03,02} in both fields > > In other words: All these implementation seem to follow the > rule that TLSPlaintext.version==ClientHello.client_version, or > use V2 ClientHellos... > > Given that Yngve's interoperability draft suggests that some > servers incorrectly use the record layer version number for > negotiation, I think the safest clarification would be to > say that the two version numbers must be equal. Rather, that clients MUST send ClientHello records with the two version numbers equal. Saying just that they "MUST be equal" would allow servers to reject records where they are not equal, which would be incorrect. -- David Hopwood _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jul 04 05:43:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxhRA-00014l-Qh; Tue, 04 Jul 2006 05:43:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FxhR9-00014d-Pc for tls@ietf.org; Tue, 04 Jul 2006 05:43:19 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FxhR9-0008Ag-O4 for tls@ietf.org; Tue, 04 Jul 2006 05:43:19 -0400 Received: from moutng.kundenserver.de ([212.227.126.188]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FxhP6-0002y2-Ga for tls@ietf.org; Tue, 04 Jul 2006 05:41:14 -0400 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1FxhP204NO-00064z; Tue, 04 Jul 2006 11:41:08 +0200 Received: by tau.invalid (Postfix, from userid 1000) id 2007C18961; Tue, 4 Jul 2006 11:41:06 +0200 (CEST) Date: Tue, 4 Jul 2006 11:41:06 +0200 From: Bodo Moeller To: Pasi.Eronen@nokia.com Subject: Re: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt Message-ID: <20060704094106.GA22002@iota.site> References: <200607031523.RAA09074@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: -2.6 (--) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Mon, Jul 03, 2006 at 07:14:15PM +0300, Pasi.Eronen@nokia.com wrote: > A quick and totally unscientific survey of what some widely used > SSL/TLS implementations do: > > - OpenSSL (0.9.8) > - When configured in "both SSLv3 and TLSv10 allowed" mode, > sends V2 ClientHello. This is the behavior of OpenSSL versions up to 0.9.7g. Versions 0.9.7h and later, including 0.9.8, will actually send a TLS/SSL3 format Client Hello message with version number {03,01} in both fields. How did you run the test? If you really used OpenSSL 0.9.8 and really disabled SSL 2.0, then the library shouldn't have used the V2 Client Hello message format. The code used by OpenSSL to create the TLS/SSL3 record header for the Client Hello message is as follows: /* fill in 5-byte record header */ d=buf; *(d++) = SSL3_RT_HANDSHAKE; *(d++) = version_major; *(d++) = version_minor; /* arguably we should send the *lowest* suported version here * (indicating, e.g., TLS 1.0 in "SSL 3.0 format") */ s2n((int)l,d); The specification specifically demands the "SSL 3.0 record format and client hello structure", which is essentially the same as the TLS 1.0 record format and client hello structure, with the notable exception of the version number field. So it's quite clear that you should put {03,00} into the record header version field, since this is the only way you can actually avoid the "TLS 1.0 record format" and use the "SSL 3.0 record format". On the other hand, this could trigger some bugs in thoughtlessly done server implementations, which are avoided by sending {03,01} in the record version field. In contrast, sending too large a minor version number (such as {03,01} for a record supposed to be in "SSL 3.0 record format") can be expected to work well with thoughfully done server implementations: If a server obtains a {03,xx} format Client Hello where the version number specified by the client is larger than the highest protocol version supported by the server ({03,yy}, say), then the best the server can do is try its highest protocol version, and send an according Server Hello message. Either this will work since the client does support {03,yy}, too; or otherwise the protocol mismatch is unavoidable, and will be detected by the client. So if a TLS 1.0 or TLS 1.1 server receives a Client Hello contained in a record of protocol version number {03,2A} or whatever, it should just try to parse this in its own native format, and negotiate the protocol version accordingly. Things can't get worse than triggering a protocol_version alert from the client, and this is not very likely to happen. (If the *major* protocol version number is unknown, such as {04,00}, then it certainly makes sense to abort the handshake immediately.) > - When configured in "TLS10 only" mode, sends {03,01} in both fields > - Mozilla Firefox 1.5 > - Seems to send V2 ClientHello no matter what the settings?? > - MS Internet Explorer 6.0 > - When configured in "both SSLv3 and TLSv1.0 allowed" mode, > sends V3 ClientHello with {03,01} in both fields > - SunJSSE (JDK 1.4.2) > - When configured in "both SSLv3 and TLSv1.0 allowed" mode, > sends V3 ClientHello with {03,01} in both fields > - GnuTLS (10.0.20) > - When configured in "both SSLv3 and TLSv1.0 allowed" mode, > sends V3 ClientHello with {03,01} in both fields > - When configured in "SSLv3, TLSv1.0 and TLSv1.1 allowed" mode, > sends V3 ClientHello with {03,02} in both fields > > In other words: All these implementation seem to follow the > rule that TLSPlaintext.version==ClientHello.client_version, or > use V2 ClientHellos... > > Given that Yngve's interoperability draft suggests that some > servers incorrectly use the record layer version number for > negotiation, I think the safest clarification would be to > say that the two version numbers must be equal. The experiment that we'd really have to run is to test various servers out there with Client Hello messages where the record protocol version and the Client Hello protocol version differ, to see what protocol version the servers will negotiate: - Send a Client Hello with a client_version of {03,2A} (say) in a record with version {03,00} and see if the server picks SSL 3.0 ({03,00}) or some version of TLS. - Then, unless the server picked the highest protocol number defined at this time, try again using a uniform-version Client Hello naming a protocol version higher than the one from the first experiment. (E.g., if the server picked SSL 3.0 in the first test, check if it does support TLS 1.0 after all.) - Finally, send a Client Hello with both version field set to {03,2A} (say) to see if the server handles unknown protocol versions properly and gracefully falls back to an existing protocol version. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 05 07:16:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy5MF-0005ZX-7B; Wed, 05 Jul 2006 07:15:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy5ME-0005WR-6E for tls@ietf.org; Wed, 05 Jul 2006 07:15:50 -0400 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy5MD-0002X5-Js for tls@ietf.org; Wed, 05 Jul 2006 07:15:50 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k65BFita009825; Wed, 5 Jul 2006 14:15:45 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Jul 2006 14:15:38 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Jul 2006 14:15:38 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt Date: Wed, 5 Jul 2006 14:15:37 +0300 Message-ID: In-Reply-To: <20060704094106.GA22002@iota.site> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt Thread-Index: AcafTlF4iji2uzmBQgWFMr/FjKjq0wA0YzQQ From: To: X-OriginalArrivalTime: 05 Jul 2006 11:15:38.0296 (UTC) FILETIME=[580A1380:01C6A024] X-Spam-Score: 0.2 (/) X-Scan-Signature: 2beba50d0fcdeee5f091c59f204d4365 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Bodo Moeller wrote: > > - OpenSSL (0.9.8) > > - When configured in "both SSLv3 and TLSv10 allowed" mode, > > sends V2 ClientHello. >=20 > This is the behavior of OpenSSL versions up to 0.9.7g. Versions > 0.9.7h and later, including 0.9.8, will actually send a TLS/SSL3 > format Client Hello message with version number {03,01} in both > fields. How did you run the test? If you really used OpenSSL 0.9.8 > and really disabled SSL 2.0, then the library shouldn't have used > the V2 Client Hello message format. Hmm... I rechecked everything, and it turns out that I had accidentally used an older version of OpenSSL installed from RPM instead of the latest version I compiled myself. When I re-ran the test using the latest version, it does indeed behave the way you described. Two additional data points: The Mozilla NSS library also sends TLS/SSL3 format ClientHello with {03,01} in both fields if you set the "SSL_V2_COMPATIBLE_HELLO" option to FALSE, and allow both SSLv3 and TLSv10 (but apparently in Firefox this flag is TRUE even when you disable SSL2 from the GUI). PureTLS 0.9b5 also sends TLS/SSL3 format ClientHello with {03,01} in both fields (when configured in "both SSLv3 and TLSv10 allowed" mode). > The code used by OpenSSL to create the TLS/SSL3 record header > for the Client Hello message is as follows: >=20 > /* fill in 5-byte record header */ > d=3Dbuf; > *(d++) =3D SSL3_RT_HANDSHAKE; > *(d++) =3D version_major; > *(d++) =3D version_minor; /* arguably we=20 > should send the *lowest* suported version here > * (indicating,=20 > e.g., TLS 1.0 in "SSL 3.0 format") */ > s2n((int)l,d); >=20 > The specification specifically demands the "SSL 3.0 record > format and client hello structure", which is essentially the > same as the TLS 1.0 record format and client hello structure, > with the notable exception of the version number field. So it's > quite clear that you should put {03,00} into the record header > version field, since this is the only way you can actually avoid > the "TLS 1.0 record format" and use the "SSL 3.0 record format". > On the other hand, this could trigger some bugs in thoughtlessly > done server implementations, which are avoided by sending > {03,01} in the record version field. Yes; it seems that most other implementations also do this (and thus servers also work with this, at least when the version is 03,01). > In contrast, sending too large a minor version number (such as {03,01} > for a record supposed to be in "SSL 3.0 record format") can be > expected to work well with thoughfully done server implementations: > If a server obtains a {03,xx} format Client Hello where the version > number specified by the client is larger than the highest protocol > version supported by the server ({03,yy}, say), then the best the > server can do is try its highest protocol version, and send an > according Server Hello message. Either this will work since the > client does support {03,yy}, too; or otherwise the protocol mismatch > is unavoidable, and will be detected by the client. Yes; and also it's quite likely that the format of ClientHello will remain backwards-compatible in future versions of TLS, since otherwise we'd lose the ability to gracefully negotiate older versions.=20 >=20 > So if a TLS 1.0 or TLS 1.1 server receives a Client Hello contained in > a record of protocol version number {03,2A} or whatever, it should > just try to parse this in its own native format, and negotiate the > protocol version accordingly. Things can't get worse than triggering > a protocol_version alert from the client, and this is not very likely > to happen. (If the *major* protocol version number is unknown, such > as {04,00}, then it certainly makes sense to abort the handshake > immediately.) The TLS specification does not actually say what meaning the "major" and "minor" version numbers have. But your intepretation -- that an implementation should attempt to parse ClientHellos with the same major version it supports, but not with different major versions -- certainly sounds reasonable.=20 > > Given that Yngve's interoperability draft suggests that some > > servers incorrectly use the record layer version number for > > negotiation, I think the safest clarification would be to=20 > > say that the two version numbers must be equal. >=20 > The experiment that we'd really have to run is to test various servers > out there with Client Hello messages where the record protocol version > and the Client Hello protocol version differ, to see what protocol > version the servers will negotiate: >=20 > - Send a Client Hello with a client_version of {03,2A} (say) in a > record with version {03,00} and see if the server picks SSL 3.0 > ({03,00}) or some version of TLS. >=20 > - Then, unless the server picked the highest protocol number defined > at this time, try again using a uniform-version Client Hello naming > a protocol version higher than the one from the first experiment. > (E.g., if the server picked SSL 3.0 in the first test, check if it > does support TLS 1.0 after all.) >=20 > - Finally, send a Client Hello with both version field set to > {03,2A} (say) to see if the server handles unknown protocol versions > properly and gracefully falls back to an existing protocol version. I've been working on a testing tool what would allow running tests exactly like this. It's not quite finished yet, but some preliminary data points: - OpenSSL 0.9.8:=20 - With ClientHello version {03,01}, succesfully negotiates TLS1.0 as long as the record version is {03,something}. Closes connection if record version is not {03,something}. - GnuTLS 1.0.20: - With ClientHello version {03,01}, succesfully negotiates TLS1.0 no matter what the record version is (i.e., record version seems to be ignored) More data will come once I get SSL3 and TLS1.1 handshakes implemented, and get time to set up more servers for testing... Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 05 07:33:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy5d4-0008FI-7e; Wed, 05 Jul 2006 07:33:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy5d2-0008Cy-Sp for tls@ietf.org; Wed, 05 Jul 2006 07:33:12 -0400 Received: from [66.48.18.194] (helo=mail.ca.certicom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy5d0-00039E-I8 for tls@ietf.org; Wed, 05 Jul 2006 07:33:12 -0400 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 34A8B10027FF3; Wed, 5 Jul 2006 07:32:53 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18611-78; Wed, 5 Jul 2006 07:32:51 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 50A2410027FF1; Wed, 5 Jul 2006 07:32:51 -0400 (EDT) In-Reply-To: <20060704094106.GA22002@iota.site> To: Bodo Moeller Subject: Re: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Rob Dugal Date: Wed, 5 Jul 2006 07:32:09 -0400 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 07/05/2006 07:32:19 AM, Serialize complete at 07/05/2006 07:32:19 AM X-Spam-Score: 0.5 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Content-Type: multipart/mixed; boundary="===============0309096121==" Errors-To: tls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============0309096121== Content-Type: multipart/alternative; boundary="=_alternative 003F9468852571A2_=" This is a multipart message in MIME format. --=_alternative 003F9468852571A2_= Content-Type: text/plain; charset="US-ASCII" Bodo Moeller wrote on 07/04/2006 05:41:06 AM: > On Mon, Jul 03, 2006 at 07:14:15PM +0300, Pasi.Eronen@nokia.com wrote: > > > A quick and totally unscientific survey of what some widely used > > SSL/TLS implementations do: > > > > - OpenSSL (0.9.8) > > - When configured in "both SSLv3 and TLSv10 allowed" mode, > > sends V2 ClientHello. > > This is the behavior of OpenSSL versions up to 0.9.7g. Versions > 0.9.7h and later, including 0.9.8, will actually send a TLS/SSL3 > format Client Hello message with version number {03,01} in both > fields. The 0.9.8 behavior doesn't make sense to me. I think the correct behaviour would be to encode the minimum protocol {03,00} in the record's protocol field and the highest protocol {03,01} in the client_hello message's protocol field. A server that understands only SSLv3 could reject a client hello message that uses a record protocol of TLSv1. To negotiate with an SSLv2 server the client must send an SSLv2 client hello so why would the situation be any different for SSLv3/TLSv1? ----------------------------------------------- Robert Dugal Member of Development Group Certicom Corp. EMAIL: rdugal@certicom.com PHONE: (905) 501-3848 FAX : (905) 507-4230 WEBSITE: www.certicom.com --=_alternative 003F9468852571A2_= Content-Type: text/html; charset="US-ASCII"
Bodo Moeller <bmoeller@acm.org> wrote on 07/04/2006 05:41:06 AM:

> On Mon, Jul 03, 2006 at 07:14:15PM +0300, Pasi.Eronen@nokia.com wrote:
>
> > A quick and totally unscientific survey of what some widely used
> > SSL/TLS implementations do:
> >
> > - OpenSSL (0.9.8)
> >   - When configured in "both SSLv3 and TLSv10 allowed" mode,
> >     sends V2 ClientHello.
>
> This is the behavior of OpenSSL versions up to 0.9.7g.  Versions
> 0.9.7h and later, including 0.9.8, will actually send a TLS/SSL3
> format Client Hello message with version number {03,01} in both
> fields.  

The 0.9.8 behavior doesn't make sense to me. I think the correct behaviour would be to encode the minimum protocol {03,00} in the record's protocol field and the highest protocol {03,01} in the client_hello message's protocol field. A server that understands only SSLv3 could reject a client hello message that uses a record protocol of TLSv1. To negotiate with an SSLv2 server the client must send an SSLv2 client hello so why would the situation be any different for SSLv3/TLSv1?






-----------------------------------------------
Robert Dugal
Member of Development Group
Certicom Corp.
EMAIL: rdugal@certicom.com
PHONE: (905) 501-3848
FAX  : (905) 507-4230
WEBSITE: www.certicom.com
--=_alternative 003F9468852571A2_=-- --===============0309096121== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============0309096121==-- From tls-bounces@lists.ietf.org Wed Jul 05 07:33:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy5dg-0001mK-Oo; Wed, 05 Jul 2006 07:33:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy5df-0001ir-OI for tls@ietf.org; Wed, 05 Jul 2006 07:33:51 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy5df-0003BJ-6j for tls@ietf.org; Wed, 05 Jul 2006 07:33:51 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k65BXlLf002491; Wed, 5 Jul 2006 14:33:50 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Jul 2006 14:33:49 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Jul 2006 14:33:49 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt Date: Wed, 5 Jul 2006 14:33:49 +0300 Message-ID: In-Reply-To: <200607031708.TAA13289@uw1048.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt Thread-Index: Acaew30S9Vxi8nr+RnGNXOt/Hz2GrwBYN+Jg From: To: X-OriginalArrivalTime: 05 Jul 2006 11:33:49.0502 (UTC) FILETIME=[E272E5E0:01C6A026] X-Spam-Score: 0.2 (/) X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Martin, While your interpretation of the spec does make sense in general, it is exactly the opposite of what most implementations seem to use. After some additional work with OpenSSL and Mozilla NSS (see my reply to Bodo earlier today), *all* the implementations mentioned so far (OpenSSL, Mozilla NSS, Microsoft IE, SunJSSE, GnuTLS, PureTLS) seem to send 03,01 in both fields (when V2 hellos are disabled, and both SSL3 and TLS1.0 are enabled), and *none* of them seems to ever send different values in these fields. Since the goal of the specification is to help interoperability, the right clarification to this ambiguity should not be based solely on a "protocol lawyer reading" of the spec (and declaring most current implementations "broken"), but also on what existing widely used implementations do. But as you and Bodo pointed out, while knowing what existing clients=20 do is useful, it's not sufficient: what existing servers do also matters. This requires some further investigation... (I do agree that for servers, the best guidance seems to be that "when receiving ClientHello, ignore the record version (or at least the minor version) and try to parse it anyway"). Best regards, Pasi > -----Original Message----- > From: ext Martin Rex [mailto:martin.rex@sap.com]=20 > Sent: 03 July, 2006 20:09 > To: Eronen Pasi (Nokia-NRC/Helsinki) > Cc: martin.rex@sap.com; tls@ietf.org > Subject: Re: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt >=20 > Pasi.Eronen@nokia.com wrote: > >=20 > > I agree that the spec is ambiguous in this respect, but I'm not > > so sure about what the correct interpretation should be. In=20 > > other words, when a TLS client supports more than one of (SSLv3, > > TLSv10, TLSv11), should the record layer version number contain > > the lowest supported protocol, or the same value as handshake > > layer ClientHello? >=20 > It SHOULD contain the lowest protocol version that the client is > willing to negotiate. Anything else is going to cause > interoperability problems. The most interesing question: what does > the installed base do today when it receives a client hello with a > 3.2 or even 3.3 or 3.4 version the "version" field of the SSL/TLS > record protocol AND in the client_version of the ClientHello > message. I expect some servers to choke heavily (and rightfully). >=20 > The potential ambiguity is only for the casual reader, there > definitely never was an abiguity for the careful protocol > implementor. The SSLv3 spec (which somewhat happened after the > fact) does not contain any ambiguity either, because it doesn't > define anything other than {3, 0} PDUs and version numbers. >=20 > The root of any ambiguity is that the spec fails to clearly seperare > version tags for the purpose of negotation (client_version, > server_version) and version tags (version) that indicates a > particular PDU encoding. >=20 > The description of the PDUs in the appendix of SSL/TLS specs contains > the protocol version in exactly three distinct variants: >=20 > version > client_version (only in ClientHello and PreMasterSecret) > server_version (only in ServerHello) >=20 > All existing specs were NOT ambiguous in that exactly one field was > supposed to contain the negotiated version number. And from the > description of the individual PDUs in Appendix A, it should have > been obvious to implementors which version field should have been > meant, and which one should not have been meant. >=20 > There are very few error-free specs, and this particular error (and > the correct wording) are fairly easy to figure, IMHO. >=20 >=20 > >=20 > > A quick and totally unscientific survey of what some widely used > > SSL/TLS implementations do: > >=20 > > - OpenSSL (0.9.8) > > - When configured in "both SSLv3 and TLSv10 allowed" mode, > > sends V2 ClientHello. >=20 > fine. >=20 > > - When configured in "TLS10 only" mode, sends {03,01} in=20 > > both fields >=20 > fine. >=20 > > - Mozilla Firefox 1.5 > > - Seems to send V2 ClientHello no matter what the settings?? >=20 > fine. >=20 > > - MS Internet Explorer 6.0 > > - When configured in "both SSLv3 and TLSv1.0 allowed" mode, > > sends V3 ClientHello with {03,01} in both fields >=20 > broken. >=20 > > - SunJSSE (JDK 1.4.2) > > - When configured in "both SSLv3 and TLSv1.0 allowed" mode, > > sends V3 ClientHello with {03,01} in both fields >=20 > broken. >=20 > > - GnuTLS (10.0.20) > > - When configured in "both SSLv3 and TLSv1.0 allowed" mode, > > sends V3 ClientHello with {03,01} in both fields >=20 > broken. >=20 > > - When configured in "SSLv3, TLSv1.0 and TLSv1.1 allowed" mode, > > sends V3 ClientHello with {03,02} in both fields >=20 > broken. >=20 > >=20 > > In other words: All these implementation seem to follow the > > rule that TLSPlaintext.version=3D=3DClientHello.client_version, or > > use V2 ClientHellos... >=20 > Didn't you just say that OpenSSL and Mozilla used a correct behaviour > on the client side? >=20 > The more interesting question is what SSL/TLS servers do upon receipt, > and in particular what they do upon receipt of a high up=20 > version number, like {03,03} or {03,04}. >=20 > >=20 > > Given that Yngve's interoperability draft suggests that some > > servers incorrectly use the record layer version number for > > negotiation, I think the safest clarification would be to=20 > > say that the two version numbers must be equal. >=20 > The clarification should say that there's an awfully large installed > base that is broken and that the server will likely have to entirely > ignore the version number in the record protocol when processing > a ClientHello message, and upons sending, should send the lowest > version number that they're willing to use. > This makes protocol layering not as independent as it should be. >=20 >=20 > -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 05 08:28:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy6UC-0007aw-NF; Wed, 05 Jul 2006 08:28:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy6UB-0007ar-FN for tls@ietf.org; Wed, 05 Jul 2006 08:28:07 -0400 Received: from moutng.kundenserver.de ([212.227.126.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy6UA-0000Tq-0A for tls@ietf.org; Wed, 05 Jul 2006 08:28:07 -0400 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1Fy6TX1dvD-0003Nm; Wed, 05 Jul 2006 14:27:32 +0200 Received: by tau.invalid (Postfix, from userid 1000) id 6C8A919527; Wed, 5 Jul 2006 14:27:26 +0200 (CEST) Date: Wed, 5 Jul 2006 14:27:26 +0200 From: Bodo Moeller To: Rob Dugal Subject: Re: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt Message-ID: <20060705122726.GA30023@iota.site> References: <20060704094106.GA22002@iota.site> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Wed, Jul 05, 2006 at 07:32:09AM -0400, Rob Dugal wrote: > Bodo Moeller wrote on 07/04/2006 05:41:06 AM: >> On Mon, Jul 03, 2006 at 07:14:15PM +0300, Pasi.Eronen@nokia.com wrote: >>> A quick and totally unscientific survey of what some widely used >>> SSL/TLS implementations do: >>> >>> - OpenSSL (0.9.8) >>> - When configured in "both SSLv3 and TLSv10 allowed" mode, >>> sends V2 ClientHello. >> This is the behavior of OpenSSL versions up to 0.9.7g. Versions >> 0.9.7h and later, including 0.9.8, will actually send a TLS/SSL3 >> format Client Hello message with version number {03,01} in both >> fields. > The 0.9.8 behavior doesn't make sense to me. I think the correct behaviour > would be to encode the minimum protocol {03,00} in the record's protocol > field and the highest protocol {03,01} in the client_hello message's > protocol field. A server that understands only SSLv3 could reject a client > hello message that uses a record protocol of TLSv1. To negotiate with an > SSLv2 server the client must send an SSLv2 client hello so why would the > situation be any different for SSLv3/TLSv1? Using {03,00} for the record protocol field certainly would make the most sense, when you're trying to follow the protocol specification. However, the RFCs aren't totally clear about the situation: RFC 2246 only requests that "a TLS server which wishes to interoperate with SSL 3.0 clients should accept SSL 3.0 client hello messages", but it does not demand that TLS-1.0-*only* servers (with no intention to interoperate with SSL 3.0 clients) tolerate a {03,00} version in the record header. On the other hand, RFC 2246 only says that "TLS clients who wish to negotiate with SSL 3.0 servers should send client hello messages using the SSL 3.0 record format and client hello structure" and does not makes this a "must". The language in RFC 4346 (with another minor protocol version to take into account) does not clear this up, in fact if you try to take it literally it makes matters worse since the backwards compatibility section only mentions SSL 2.0 and SSL 3.0 client hello messages, but no TLS 1.0 client hello messages (which would make a lot of sense for the TLS1.0 + TLS1.1 case). Essentially, OpenSSL 0.9.7h is following a trend set by other client implementations. If everyone was using {03,00} version records to encapsulate TLS 1.0 Client Hellos, then OpenSSL probably would do this too. But there are plenty of broken servers out there, and the experience is that some of these will mistakenly use {03,00} as the client's maximum protocol version, even if this really is higher (and correctly sent in the actual content of the Client Hello message). This means that an obsolete protocol version will be negotiated (SSL 3.0 when both parties actually do support TLS 1.0 or later), and in the case of an RSA key exchange, it may lead to an aborted handshake (since client_version is duplicated in the encrypted premaster secret). Heuristically, sending {03,01} in the record header appears to be less problematic since typical SSL 3.0-only servers will accept this Client Hello without complaining. (Some very broken SSL 3.0 servers used to of problems even with this, but we can't accommodate everything.) I'm not saying that SSL3.0 + TLS1.0 clients *should* use {03,01} for the record protocol field, though. They are absolutely welcome to use {03,00}, and similarly, it is perfect for TLS1.0 + TLS1.1 clients to use {03,01} (TLS 1.0) rather than {03,02} (TLS 1.1), and for future TLS1.1 + TLS 1.2 clients to use {03,02} rather than {03,03}. Sending any value {03,xx} where the respective protocol version is supported by the client looks OK to me, and should be tolerated by servers, even if the server does not know about said protocol version. (If the handshake attempt fails since the server has to downgrade from a protocol {03,xx} supported by the client to {03,yy}, yy < xx, where {03,yy} is not supported by the client, then at least the client will learn about the highest version supported by the server, providing for an informative error message.) This, of course, assumes that the Client Hello format is not actually changed between minor protocol versions. If there were actual significant differences (apart from hello extensions, which rely on a forward compatilibity provision in the original SSL 3.0 and TLS 1.0 specifications), there was bound to be chaos. However, given the current state and the unclear language in RFC 2246 and RFC 4346, we can conclude that it would be utter madness to ever change the Client Hello structure in an incompatible way without changing the major protocol version: If such a change was ever considered necessary, then we'd again have a situation like the current SSL2.0 / SSL3.0+TLS1.x interoperability situation on a higher level, i.e. the Client Hello message would be sent in SSL3.0+TLS1.x format (using the current structure definition) and the Client Hello message would name some version {04,xx}, without being able to use any new features requiring the new native Client Hello format (like we currently can't use Client Hello extensions in SSL 2.0 backwards compatible mode). _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 05 09:51:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy7n3-0003qp-Gb; Wed, 05 Jul 2006 09:51:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy7n2-0003qk-Q2 for tls@ietf.org; Wed, 05 Jul 2006 09:51:40 -0400 Received: from tholian.rsasecurity.com ([216.162.240.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy7n1-0003JM-Gp for tls@ietf.org; Wed, 05 Jul 2006 09:51:40 -0400 Received: from hyperion.rsasecurity.com by tholian.rsasecurity.com via smtpd (for ietf-mx.ietf.org [156.154.16.150]) with ESMTP; Wed, 5 Jul 2006 09:50:36 -0400 Received: from sdtihq24.securid.com (sdtihq24.na.rsa.net [10.100.8.152]) by hyperion.na.rsa.net (MOS 3.7.4b-GA) with ESMTP id CPY53845; Wed, 5 Jul 2006 09:55:03 +0500 (GMT-5) Received: from rsana-ex-hq2.NA.RSA.NET (rsana-ex-hq2.na.rsa.net [10.100.8.51]) by sdtihq24.securid.com (8.12.10/8.12.9) with ESMTP id k65DpYDU019046; Wed, 5 Jul 2006 09:51:34 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Comments on draft-linn-otp-tls-00 Date: Wed, 5 Jul 2006 09:51:34 -0400 Message-ID: In-Reply-To: <20060702164726.DE385222425@laser.networkresonance.com> Thread-Topic: [TLS] Comments on draft-linn-otp-tls-00 Thread-Index: Acad9iE9wihiyIijQoS/sfLPSQei9QCPsQAQ From: "Linn, John" To: "Eric Rescorla" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: =?iso-8859-1?Q?Nystr=F6m=2C_Magnus?= X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Thanks, Eric, for the review and comments. Our thoughts embedded, with = [JL] prefixes.=20 -----Original Message----- From: Eric Rescorla [mailto:ekr@networkresonance.com]=20 Sent: Sunday, July 02, 2006 12:39 PM To: tls@ietf.org Subject: [TLS] Comments on draft-linn-otp-tls-00 I've given this document a quick read. Comments follow. 1. Calling this an OTP mechanism is kind of confusing because the IETF already has a standard for OTP (RFC 2289) based on S/Key.=20 [JL] Any confusion here was unintended. A number of methods are = commonly known and described as one-time passwords; the draft is = intended to be able to support a range of choices. RFC-2289's title, = e.g., is "A One-Time Password System"; it's a particular method, rather = than defining the entire class. To resolve the name conflict against = RFC-2289, we could coin a new phrase for this draft, perhaps Single-Use = Passwords (SUPs), but this would lack familiarity for readers. Because the RFC 2289 scheme relies on the server storing the output of a digest and the client providing the preimage, it cannot be used with the mechanism in this draft. At minimum, you need to have a section=20 explaining that only systems in which both client and server can generate the same password sequence can be used here and preferably a name change would be appropriate. [JL] Good observation. The approach as described in the draft indeed = requires that both client and server be capable of generating a common = OTP/SUP value independently. We'll make this explicit in a subsequent = revision. 2. I'm very uncomfortable with retroactively changing the=20 meaning of psk_identity--without any external signalling as far as I can tell. That doesn't seem like a good plan at all. [JL] As RFC-4279 states, "This document does not mandate the use of any = particular type of identity...". We've tried to remain consistent with = the encoding conventions that RFC-4279 prescribes, but it appeared that = the content of psk_identity was not fully constrained. Potentially, it = could be possible to maintain the existing interpretation of = psk_identity (basically, what the current draft prefixes with "UI=3D"), = and to accompany it with OTP-specific qualifiers only if signaled = through use of an extension. Would additional qualifiers within = psk_identity seem acceptable in such a context? 3. The new PSK identity encoding should be expressed using standard TLS structures, not an ASCII encoding. This=20 comment applies both to how to pack the structures and how to represent the time, which should be a 32-bit integer in accordance with TLS standard practice. [JL] This would be appropriate within the context of a new TLS key = exchange method definition. The current draft sought to represent this = data within RFC-4279's overall character string encoding conventions for = psk_identity. 4. In S 3.3.2, what happens if I want to offer multiple=20 otp_algorithms? Impossible. [JL] Good point. We'll investigate this in the context of a new = extension, as suggested above.=20 5. In S 3.3.3, making iteration_count a uint16 seems unwise. Better to future proof and make it a uint32. [JL] Agreed.=20 6. I'm very uncomfortable with creating all these alerts. Note that the TLS alert space is only 8 bits wide. Note also that per RFC 4346 Alerts can only be created by Standards action. [JL] Is there existing guidance and precedent to qualify definition of = alerts that are specific to particular methods or ciphersuites? I = respect the need to conserve the alert space, and compression relative = to the current proposal would be possible, but would like to identify a = means to provide sufficiently descriptive indicators as to disambiguate = failure cases.=20 -Ekr [JL] --jl _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 05 09:56:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy7rc-0004Z3-BS; Wed, 05 Jul 2006 09:56:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy7rb-0004Yy-Ga for tls@ietf.org; Wed, 05 Jul 2006 09:56:23 -0400 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy7ra-00040H-7e for tls@ietf.org; Wed, 05 Jul 2006 09:56:23 -0400 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id B4687222425 for ; Wed, 5 Jul 2006 07:04:25 -0700 (PDT) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 19) Date: Wed, 05 Jul 2006 06:56:16 -0700 From: Eric Rescorla Message-Id: <20060705140425.B4687222425@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [TLS] Expanding the alert space X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org I've noticed lately that people seem to want to define a lot of new TLS alerts. What would people think about expanding the alert space in 1.2? 16 bits enough? I've considered a few times having a freeform string field as well that could be used to report errors in detail for debugging, but maybe that's too clever. Thoughts? -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 05 12:02:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy9pO-0006SZ-W4; Wed, 05 Jul 2006 12:02:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fy9pN-0006SU-I1 for tls@ietf.org; Wed, 05 Jul 2006 12:02:13 -0400 Received: from [66.48.18.194] (helo=mail.ca.certicom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy9pM-0007Wn-Pb for tls@ietf.org; Wed, 05 Jul 2006 12:02:13 -0400 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 6E306100233CB; Wed, 5 Jul 2006 12:02:09 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22484-25; Wed, 5 Jul 2006 12:02:07 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 4A01310027FF0; Wed, 5 Jul 2006 12:02:07 -0400 (EDT) In-Reply-To: To: Subject: RE: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Rob Dugal Date: Wed, 5 Jul 2006 12:01:24 -0400 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 07/05/2006 12:01:35 PM, Serialize complete at 07/05/2006 12:01:35 PM X-Spam-Score: 0.5 (/) X-Scan-Signature: b5216aa5b0df24d46eaed76d4f65aa31 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Content-Type: multipart/mixed; boundary="===============1493826214==" Errors-To: tls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============1493826214== Content-Type: multipart/alternative; boundary="=_alternative 00583B2C852571A2_=" This is a multipart message in MIME format. --=_alternative 00583B2C852571A2_= Content-Type: text/plain; charset="US-ASCII" FYI - Opera 9 will sometimes send a client hello with SSLv3 as the record version and TLSv1 as the client version. In my tests with SSLv3 & TLSv1 enabled it first sends a client hello with TLSv1as the record version and TLSv1 as the client version. If this handshake fails it retries using SSLv3/TLS1. ----------------------------------------------- Robert Dugal Member of Development Group Certicom Corp. EMAIL: rdugal@certicom.com PHONE: (905) 501-3848 FAX : (905) 507-4230 WEBSITE: www.certicom.com wrote on 07/05/2006 07:33:49 AM: > Martin, > > While your interpretation of the spec does make sense in general, it > is exactly the opposite of what most implementations seem to use. > > After some additional work with OpenSSL and Mozilla NSS (see my > reply to Bodo earlier today), *all* the implementations mentioned so > far (OpenSSL, Mozilla NSS, Microsoft IE, SunJSSE, GnuTLS, PureTLS) > seem to send 03,01 in both fields (when V2 hellos are disabled, and > both SSL3 and TLS1.0 are enabled), and *none* of them seems to ever > send different values in these fields. > > Since the goal of the specification is to help interoperability, the > right clarification to this ambiguity should not be based solely on a > "protocol lawyer reading" of the spec (and declaring most current > implementations "broken"), but also on what existing widely used > implementations do. > > But as you and Bodo pointed out, while knowing what existing clients > do is useful, it's not sufficient: what existing servers do also > matters. This requires some further investigation... > > (I do agree that for servers, the best guidance seems to be that > "when receiving ClientHello, ignore the record version (or at least > the minor version) and try to parse it anyway"). > > Best regards, > Pasi > > > -----Original Message----- > > From: ext Martin Rex [mailto:martin.rex@sap.com] > > Sent: 03 July, 2006 20:09 > > To: Eronen Pasi (Nokia-NRC/Helsinki) > > Cc: martin.rex@sap.com; tls@ietf.org > > Subject: Re: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt > > > > Pasi.Eronen@nokia.com wrote: > > > > > > I agree that the spec is ambiguous in this respect, but I'm not > > > so sure about what the correct interpretation should be. In > > > other words, when a TLS client supports more than one of (SSLv3, > > > TLSv10, TLSv11), should the record layer version number contain > > > the lowest supported protocol, or the same value as handshake > > > layer ClientHello? > > > > It SHOULD contain the lowest protocol version that the client is > > willing to negotiate. Anything else is going to cause > > interoperability problems. The most interesing question: what does > > the installed base do today when it receives a client hello with a > > 3.2 or even 3.3 or 3.4 version the "version" field of the SSL/TLS > > record protocol AND in the client_version of the ClientHello > > message. I expect some servers to choke heavily (and rightfully). > > > > The potential ambiguity is only for the casual reader, there > > definitely never was an abiguity for the careful protocol > > implementor. The SSLv3 spec (which somewhat happened after the > > fact) does not contain any ambiguity either, because it doesn't > > define anything other than {3, 0} PDUs and version numbers. > > > > The root of any ambiguity is that the spec fails to clearly seperare > > version tags for the purpose of negotation (client_version, > > server_version) and version tags (version) that indicates a > > particular PDU encoding. > > > > The description of the PDUs in the appendix of SSL/TLS specs contains > > the protocol version in exactly three distinct variants: > > > > version > > client_version (only in ClientHello and PreMasterSecret) > > server_version (only in ServerHello) > > > > All existing specs were NOT ambiguous in that exactly one field was > > supposed to contain the negotiated version number. And from the > > description of the individual PDUs in Appendix A, it should have > > been obvious to implementors which version field should have been > > meant, and which one should not have been meant. > > > > There are very few error-free specs, and this particular error (and > > the correct wording) are fairly easy to figure, IMHO. > > > > > > > > > > A quick and totally unscientific survey of what some widely used > > > SSL/TLS implementations do: > > > > > > - OpenSSL (0.9.8) > > > - When configured in "both SSLv3 and TLSv10 allowed" mode, > > > sends V2 ClientHello. > > > > fine. > > > > > - When configured in "TLS10 only" mode, sends {03,01} in > > > both fields > > > > fine. > > > > > - Mozilla Firefox 1.5 > > > - Seems to send V2 ClientHello no matter what the settings?? > > > > fine. > > > > > - MS Internet Explorer 6.0 > > > - When configured in "both SSLv3 and TLSv1.0 allowed" mode, > > > sends V3 ClientHello with {03,01} in both fields > > > > broken. > > > > > - SunJSSE (JDK 1.4.2) > > > - When configured in "both SSLv3 and TLSv1.0 allowed" mode, > > > sends V3 ClientHello with {03,01} in both fields > > > > broken. > > > > > - GnuTLS (10.0.20) > > > - When configured in "both SSLv3 and TLSv1.0 allowed" mode, > > > sends V3 ClientHello with {03,01} in both fields > > > > broken. > > > > > - When configured in "SSLv3, TLSv1.0 and TLSv1.1 allowed" mode, > > > sends V3 ClientHello with {03,02} in both fields > > > > broken. > > > > > > > > In other words: All these implementation seem to follow the > > > rule that TLSPlaintext.version==ClientHello.client_version, or > > > use V2 ClientHellos... > > > > Didn't you just say that OpenSSL and Mozilla used a correct behaviour > > on the client side? > > > > The more interesting question is what SSL/TLS servers do upon receipt, > > and in particular what they do upon receipt of a high up > > version number, like {03,03} or {03,04}. > > > > > > > > Given that Yngve's interoperability draft suggests that some > > > servers incorrectly use the record layer version number for > > > negotiation, I think the safest clarification would be to > > > say that the two version numbers must be equal. > > > > The clarification should say that there's an awfully large installed > > base that is broken and that the server will likely have to entirely > > ignore the version number in the record protocol when processing > > a ClientHello message, and upons sending, should send the lowest > > version number that they're willing to use. > > This makes protocol layering not as independent as it should be. > > > > > > -Martin > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls --=_alternative 00583B2C852571A2_= Content-Type: text/html; charset="US-ASCII"
FYI - Opera 9 will sometimes send a client hello with SSLv3 as the record version and TLSv1 as the client version.
In my tests with SSLv3 & TLSv1 enabled it first sends a client hello with TLSv1as the record version and TLSv1 as the client version.
If this handshake fails it retries using SSLv3/TLS1.

-----------------------------------------------
Robert Dugal
Member of Development Group
Certicom Corp.
EMAIL: rdugal@certicom.com
PHONE: (905) 501-3848
FAX  : (905) 507-4230
WEBSITE: www.certicom.com

<Pasi.Eronen@nokia.com> wrote on 07/05/2006 07:33:49 AM:

> Martin,
>
> While your interpretation of the spec does make sense in general, it
> is exactly the opposite of what most implementations seem to use.
>
> After some additional work with OpenSSL and Mozilla NSS (see my
> reply to Bodo earlier today), *all* the implementations mentioned so
> far (OpenSSL, Mozilla NSS, Microsoft IE, SunJSSE, GnuTLS, PureTLS)
> seem to send 03,01 in both fields (when V2 hellos are disabled, and
> both SSL3 and TLS1.0 are enabled), and *none* of them seems to ever
> send different values in these fields.
>
> Since the goal of the specification is to help interoperability, the
> right clarification to this ambiguity should not be based solely on a
> "protocol lawyer reading" of the spec (and declaring most current
> implementations "broken"), but also on what existing widely used
> implementations do.
>
> But as you and Bodo pointed out, while knowing what existing clients
> do is useful, it's not sufficient: what existing servers do also
> matters. This requires some further investigation...
>
> (I do agree that for servers, the best guidance seems to be that
> "when receiving ClientHello, ignore the record version (or at least
> the minor version) and try to parse it anyway").
>
> Best regards,
> Pasi
>
> > -----Original Message-----
> > From: ext Martin Rex [mailto:martin.rex@sap.com]
> > Sent: 03 July, 2006 20:09
> > To: Eronen Pasi (Nokia-NRC/Helsinki)
> > Cc: martin.rex@sap.com; tls@ietf.org
> > Subject: Re: [TLS] Re: draft-ietf-tls-rfc4346-bis-01.txt
> >
> > Pasi.Eronen@nokia.com wrote:
> > >
> > > I agree that the spec is ambiguous in this respect, but I'm not
> > > so sure about what the correct interpretation should be. In
> > > other words, when a TLS client supports more than one of (SSLv3,
> > > TLSv10, TLSv11), should the record layer version number contain
> > > the lowest supported protocol, or the same value as handshake
> > > layer ClientHello?
> >
> > It SHOULD contain the lowest protocol version that the client is
> > willing to negotiate.  Anything else is going to cause
> > interoperability problems.  The most interesing question: what does
> > the installed base do today when it receives a client hello with a
> > 3.2 or even 3.3 or 3.4 version the "version" field of the SSL/TLS
> > record protocol AND in the client_version of the ClientHello
> > message.  I expect some servers to choke heavily (and rightfully).
> >
> > The potential ambiguity is only for the casual reader, there
> > definitely never was an abiguity for the careful protocol
> > implementor.  The SSLv3 spec (which somewhat happened after the
> > fact) does not contain any ambiguity either, because it doesn't
> > define anything other than {3, 0} PDUs and version numbers.
> >
> > The root of any ambiguity is that the spec fails to clearly seperare
> > version tags for the purpose of negotation (client_version,
> > server_version) and version tags (version) that indicates a
> > particular PDU encoding.
> >
> > The description of the PDUs in the appendix of SSL/TLS specs contains
> > the protocol version in exactly three distinct variants:
> >
> >     version
> >     client_version (only in ClientHello and PreMasterSecret)
> >     server_version (only in ServerHello)
> >
> > All existing specs were NOT ambiguous in that exactly one field was
> > supposed to contain the negotiated version number.  And from the
> > description of the individual PDUs in Appendix A, it should have
> > been obvious to implementors which version field should have been
> > meant, and which one should not have been meant.
> >
> > There are very few error-free specs, and this particular error (and
> > the correct wording) are fairly easy to figure, IMHO.
> >
> >
> > >
> > > A quick and totally unscientific survey of what some widely used
> > > SSL/TLS implementations do:
> > >
> > > - OpenSSL (0.9.8)
> > >   - When configured in "both SSLv3 and TLSv10 allowed" mode,
> > >     sends V2 ClientHello.
> >
> > fine.
> >
> > >   - When configured in "TLS10 only" mode, sends {03,01} in
> > >     both fields
> >
> > fine.
> >
> > > - Mozilla Firefox 1.5
> > >   - Seems to send V2 ClientHello no matter what the settings??
> >
> > fine.
> >
> > > - MS Internet Explorer 6.0
> > >   - When configured in "both SSLv3 and TLSv1.0 allowed" mode,
> > >     sends V3 ClientHello with {03,01} in both fields
> >
> > broken.
> >
> > > - SunJSSE (JDK 1.4.2)
> > >   - When configured in "both SSLv3 and TLSv1.0 allowed" mode,
> > >     sends V3 ClientHello with {03,01} in both fields
> >
> > broken.
> >
> > > - GnuTLS (10.0.20)
> > >   - When configured in "both SSLv3 and TLSv1.0 allowed" mode,
> > >     sends V3 ClientHello with {03,01} in both fields
> >
> > broken.
> >
> > >   - When configured in "SSLv3, TLSv1.0 and TLSv1.1 allowed" mode,
> > >     sends V3 ClientHello with {03,02} in both fields
> >
> > broken.
> >
> > >
> > > In other words: All these implementation seem to follow the
> > > rule that TLSPlaintext.version==ClientHello.client_version, or
> > > use V2 ClientHellos...
> >
> > Didn't you just say that OpenSSL and Mozilla used a correct behaviour
> > on the client side?
> >
> > The more interesting question is what SSL/TLS servers do upon receipt,
> > and in particular what they do upon receipt of a high up
> > version number, like {03,03} or {03,04}.
> >
> > >
> > > Given that Yngve's interoperability draft suggests that some
> > > servers incorrectly use the record layer version number for
> > > negotiation, I think the safest clarification would be to
> > > say that the two version numbers must be equal.
> >
> > The clarification should say that there's an awfully large installed
> > base that is broken and that the server will likely have to entirely
> > ignore the version number in the record protocol when processing
> > a ClientHello message, and upons sending, should send the lowest
> > version number that they're willing to use.
> > This makes protocol layering not as independent as it should be.
> >
> >
> > -Martin
>
> _______________________________________________
> TLS mailing list
> TLS@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls
 --=_alternative 00583B2C852571A2_=-- --===============1493826214== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============1493826214==-- From tls-bounces@lists.ietf.org Wed Jul 05 13:20:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyB2o-0001xW-0P; Wed, 05 Jul 2006 13:20:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyB2k-0001uA-OF for tls@ietf.org; Wed, 05 Jul 2006 13:20:06 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fy8xi-0002nj-MP for tls@ietf.org; Wed, 05 Jul 2006 11:06:46 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fy8mJ-0002d4-9j for tls@ietf.org; Wed, 05 Jul 2006 10:54:59 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k65EsvDC029591; Wed, 5 Jul 2006 17:54:57 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Jul 2006 17:54:55 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 5 Jul 2006 17:54:55 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Expanding the alert space Date: Wed, 5 Jul 2006 17:54:59 +0300 Message-ID: In-Reply-To: <20060705140425.B4687222425@laser.networkresonance.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Expanding the alert space Thread-Index: AcagO2QxG+L4MXzPR96IKhMrS5MIxgABq/RQ From: To: , X-OriginalArrivalTime: 05 Jul 2006 14:54:55.0174 (UTC) FILETIME=[FA265660:01C6A042] X-Spam-Score: -1.8 (-) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla wrote: > I've noticed lately that people seem to want to define a lot of new > TLS alerts. What would people think about expanding the alert space > in 1.2? 16 bits enough? I've considered a few times having a > freeform string field as well that could be used to report errors in > detail for debugging, but maybe that's too clever. >=20 > Thoughts? Some statistics: in the 10+ years from SSL 3.0 to today, all approved documents together have used a total of 30 alert numbers (of 256). Currently active Internet-Drafts use 5. So I don't think there's any immediate danger of running out of them. And providing too detailed debugging information to the other party is not necessarily a good idea (e.g. bad_record_mac/decryption_failed and the CBC attacks resulting from it). Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jul 06 08:45:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyTEZ-0004W0-Fz; Thu, 06 Jul 2006 08:45:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyTEY-0004Vv-V0 for tls@ietf.org; Thu, 06 Jul 2006 08:45:30 -0400 Received: from tholian.rsasecurity.com ([216.162.240.129]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyTEX-0005TX-LW for tls@ietf.org; Thu, 06 Jul 2006 08:45:30 -0400 Received: from hyperion.rsasecurity.com by tholian.rsasecurity.com via smtpd (for ietf-mx.ietf.org [156.154.16.150]) with ESMTP; Thu, 6 Jul 2006 08:44:26 -0400 Received: from sdtihq24.securid.com (sdtihq24.na.rsa.net [10.100.8.152]) by hyperion.na.rsa.net (MOS 3.7.4b-GA) with ESMTP id CPZ16027; Thu, 6 Jul 2006 08:49:00 +0500 (GMT-5) Received: from rsana-ex-hq2.NA.RSA.NET (rsana-ex-hq2.na.rsa.net [10.100.8.51]) by sdtihq24.securid.com (8.12.10/8.12.9) with ESMTP id k66CjPDU020876; Thu, 6 Jul 2006 08:45:25 -0400 (EDT) x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Expanding the alert space Date: Thu, 6 Jul 2006 08:45:24 -0400 Message-ID: In-Reply-To: Thread-Topic: [TLS] Expanding the alert space Thread-Index: AcagO2QxG+L4MXzPR96IKhMrS5MIxgABq/RQACv02zA= From: "Linn, John" To: , , X-Spam-Score: 0.1 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org It's true that there are cases where more specific error reporting can provide useful information for attackers. I believe, though, that this fact argues more for selective reporting in particular sensitive cases than for an architectural constraint that limits definition and use of alerts generally. =20 Though relatively available for allocation today, an 8-bit flat space seems small to describe a set of choices that continues to grow as new methods are defined. A 16-bit space would allow more flexibility. Alternately, to reduce the extent to which the overall TLS-wide alert set will need to expand in response to new methods, it could be useful to allow a means to annotate a smaller number of top-level alerts with more detailed status data that may be method-specific. Eric's freeform string suggestion is one possibility in this area. Another option might be to introduce a subcode field, which would have registered values that could be used (optionally) to provide more detailed status indications in conjunction with a particular alert.=20 --jl -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]=20 Sent: Wednesday, July 05, 2006 10:55 AM To: ekr@networkresonance.com; tls@ietf.org Subject: RE: [TLS] Expanding the alert space Eric Rescorla wrote: > I've noticed lately that people seem to want to define a lot of new > TLS alerts. What would people think about expanding the alert space > in 1.2? 16 bits enough? I've considered a few times having a > freeform string field as well that could be used to report errors in > detail for debugging, but maybe that's too clever. >=20 > Thoughts? Some statistics: in the 10+ years from SSL 3.0 to today, all approved documents together have used a total of 30 alert numbers (of 256). Currently active Internet-Drafts use 5. So I don't think there's any immediate danger of running out of them. And providing too detailed debugging information to the other party is not necessarily a good idea (e.g. bad_record_mac/decryption_failed and the CBC attacks resulting from it). Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jul 06 09:20:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyTml-00068R-AX; Thu, 06 Jul 2006 09:20:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyTmj-00068K-Nu for tls@lists.ietf.org; Thu, 06 Jul 2006 09:20:49 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyTmi-0004N6-F0 for tls@lists.ietf.org; Thu, 06 Jul 2006 09:20:49 -0400 Received: by ug-out-1314.google.com with SMTP id m3so288864uge for ; Thu, 06 Jul 2006 06:20:47 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:user-agent:references:in-reply-to:mime-version:content-disposition:date:content-type:content-transfer-encoding:message-id:sender; b=R8xKIQozUqQzbH8ghhgzIF4ujJTd+7hCBKKTG2khVonhed89iDTWk5u4DHw7UvCipxQ2FGo6xQlWSRE5tFL/HTI0rGHgCYfaQuiM53mESP0wMxczswGLsiwgyftgRuSIjSoAwLRMz/tpSu+fAd7KaTFUVJGnxGg2jBypnzgsY5c= Received: by 10.67.89.5 with SMTP id r5mr702709ugl; Thu, 06 Jul 2006 06:20:47 -0700 (PDT) Received: from ?172.16.1.196? ( [81.175.93.238]) by mx.gmail.com with ESMTP id y1sm729841uge.2006.07.06.06.20.46; Thu, 06 Jul 2006 06:20:47 -0700 (PDT) From: Nikos Mavrogiannopoulos To: tls@lists.ietf.org Subject: Re: [TLS] Expanding the alert space User-Agent: KMail/1.9.1 References: <20060705140425.B4687222425@laser.networkresonance.com> In-Reply-To: <20060705140425.B4687222425@laser.networkresonance.com> MIME-Version: 1.0 Content-Disposition: inline Date: Thu, 6 Jul 2006 15:20:45 +0200 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Message-Id: <200607061520.45640.nmav@gnutls.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Wed 05 Jul 2006 15:56, Eric Rescorla wrote: > I've noticed lately that people seem to want to define a lot of new > TLS alerts. What would people think about expanding the alert space > in 1.2? 16 bits enough? I've considered a few times having a freeform > string field as well that could be used to report errors in detail > for debugging, but maybe that's too clever. I am scared of a freeform string, because in the end it would need to handle internationalization (because somebody will think it's usefull information to print to the user) etc etc... thus we might later need a TLS extension to specify the language, encodings and so on. It might be too much for such a protocol! About the extension to 16bit... I'm not totally against, but unless TLS 1.2 is significantly different[0] than 1.1, I wouldn't go for it. [0]. In the sense that if there too many incompatible changes, one more doesn't harm :) regards, Nikos _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jul 06 09:50:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyUF6-0006iV-OV; Thu, 06 Jul 2006 09:50:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyUF5-0006iN-Dh for tls@ietf.org; Thu, 06 Jul 2006 09:50:07 -0400 Received: from [66.48.18.194] (helo=mail.ca.certicom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyUF3-0005SS-0O for tls@ietf.org; Thu, 06 Jul 2006 09:50:07 -0400 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 99D0B100233C4; Thu, 6 Jul 2006 09:50:01 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31320-18; Thu, 6 Jul 2006 09:49:58 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id AC6CF100233DF; Thu, 6 Jul 2006 09:49:58 -0400 (EDT) In-Reply-To: <20060625170241.E4704222425@laser.networkresonance.com> To: Eric Rescorla Subject: Re: [TLS] Updated TLS 1.2 I-D MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Rob Dugal Date: Thu, 6 Jul 2006 09:49:23 -0400 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 07/06/2006 09:49:25 AM, Serialize complete at 07/06/2006 09:49:25 AM X-Spam-Score: 0.1 (/) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Content-Type: multipart/mixed; boundary="===============1157457464==" Errors-To: tls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============1157457464== Content-Type: multipart/alternative; boundary="=_alternative 004C08D9852571A3_=" This is a multipart message in MIME format. --=_alternative 004C08D9852571A3_= Content-Type: text/plain; charset="US-ASCII" 7.4.3. Server key exchange message If the SignatureAlgorithm being used to sign the ServerKeyExchange message is DSA, the hash function used MUST be SHA-1. If the SignatureAlgorithm it must be the same hash function used in the signature of the server's certificate (found in the Certificate) message. This algorithm is denoted Hash below. Hash.length is the length of the output of that algorithm. Something is missing in this sentence "If the SignatureAlgorithm it must be the " ----------------------------------------------- Robert Dugal Member of Development Group Certicom Corp. EMAIL: rdugal@certicom.com PHONE: (905) 501-3848 FAX : (905) 507-4230 WEBSITE: www.certicom.com Eric Rescorla wrote on 06/25/2006 12:54:30 PM: > I've submitted an update TLS 1.2 I-D an in the meantime > you can find it at: > > http://scm.sipfoundry.org/rep/ietf-drafts/ekr/tls/tls.txt > > The big thing I know is misisng is replaceable PRFs, which > I wanted to discuss on the mailing list before I put in. > As people will recall, there was a consensus on replaceable > PRFs/KDFs in Dallas but we didn't discuss exactly how to do > them. > > My proposal is as follows: > > - All PRFs must have the same "API" as the existing TLS > PRFs. > - New cipher suites MAY have as part of their specification > a new PRF. > - There is no way to separately negotiate a new PRF for > an existing cipher suite. > > The major alternative is some kind of extension, which makes > me uncomfortable. > > Thoughts? Issues? > -Ekr > > > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls --=_alternative 004C08D9852571A3_= Content-Type: text/html; charset="US-ASCII"
7.4.3. Server key exchange message

<snip>

   If the SignatureAlgorithm being used to sign the ServerKeyExchange
   message is DSA, the hash function used MUST be SHA-1. If the
   SignatureAlgorithm it must be the same hash function used in the
   signature of the server's certificate (found in the Certificate)
   message. This algorithm is denoted Hash below. Hash.length is the
   length of the output of that algorithm.

Something is missing in this sentence  "If the SignatureAlgorithm it must be the "

-----------------------------------------------
Robert Dugal
Member of Development Group
Certicom Corp.
EMAIL: rdugal@certicom.com
PHONE: (905) 501-3848
FAX  : (905) 507-4230
WEBSITE: www.certicom.com

Eric Rescorla <ekr@networkresonance.com> wrote on 06/25/2006 12:54:30 PM:

> I've submitted an update TLS 1.2 I-D an in the meantime
> you can find it at:
>
> http://scm.sipfoundry.org/rep/ietf-drafts/ekr/tls/tls.txt
>
> The big thing I know is misisng is replaceable PRFs, which
> I wanted to discuss on the mailing list before I put in.
> As people will recall, there was a consensus on replaceable
> PRFs/KDFs in Dallas but we didn't discuss exactly how to do
> them.
>
> My proposal is as follows:
>
> - All PRFs must have the same "API" as the existing TLS
>   PRFs.
> - New cipher suites MAY have as part of their specification
>   a new PRF.
> - There is no way to separately negotiate a new PRF for
>   an existing cipher suite.
>
> The major alternative is some kind of extension, which makes
> me uncomfortable.
>
> Thoughts? Issues?
> -Ekr
>
>
>
>
> _______________________________________________
> TLS mailing list
> TLS@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls
 --=_alternative 004C08D9852571A3_=-- --===============1157457464== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============1157457464==-- From tls-bounces@lists.ietf.org Thu Jul 06 13:08:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyXKN-0002AD-7J; Thu, 06 Jul 2006 13:07:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyXKM-0002A5-2E for tls@ietf.org; Thu, 06 Jul 2006 13:07:46 -0400 Received: from nf-out-0910.google.com ([64.233.182.185]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyXKK-0005Xn-P2 for tls@ietf.org; Thu, 06 Jul 2006 13:07:46 -0400 Received: by nf-out-0910.google.com with SMTP id y38so221506nfb for ; Thu, 06 Jul 2006 10:07:43 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=qVu26rc+VR23+D7OMm65VDgCzOl5WXlbUgaldjbM7t7P1EAQWnExgdL6qHj7G5CX2JWyC9XA2zzk/azqUp2x2YlbSZXIBrnSBirtnDP0avO1thrDsZN1b9zGdMd7nJMdXQttfXy2J0GoyX0TyNZVbTC4ZXyBIWA/bzyV9Iddlao= Received: by 10.49.43.12 with SMTP id v12mr621693nfj; Thu, 06 Jul 2006 10:07:43 -0700 (PDT) Received: by 10.48.12.19 with HTTP; Thu, 6 Jul 2006 10:07:43 -0700 (PDT) Message-ID: <6b9359640607061007q5d2a5d24ha55ecc6c06f871c1@mail.gmail.com> Date: Thu, 6 Jul 2006 10:07:43 -0700 From: "Kyle Hamilton" To: tls@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Subject: [TLS] KH comment (tls 1.2 draft) X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Comments on protocol and TLS 1.2 draft: AMBIGUITY: Section 6.0 The draft states "If a TLS implementation receives a record type it does not understand, it SHOULD just ignore it." Does this mean that the implementation does NOT update its read_sequence_number when it receives it? Or should the application attempt to decrypt it with the current state and verify that its MAC at least matches the updated sequence number? (Ignorance in this fashion allows TCP injection against unmatched servers and clients, and possibly-vulnerable implementations that do not properly check the record type it received against the record types defined in a particular version of the protocol -- i.e., a newer version of the protocol may define new record types, and on a communication with an older client might act as though it "knows" about the record type that was sent and attempt to process the record any case, thus forcing a bad_record_mac error.) So, what is the correct handling? Ignore completely, or decode and update the sequence number? ASSUMPTION: Entire Document It is universally assumed that this protocol will only be used over a sequenced network. It is advantageous in certain circumstances to use this protocol over other types of transports, such as packet radio or dial-up serial EDI. In both of these cases, "line noise" (the bane of SLIP, since that protocol didn't update the IP checksum properly) can cause data packets to fail to decode properly. It should be stated exactly what the assumed network parameters are: Error detecting/correcting (to prevent errors between the two systems communicating with this protocol), reliability (the TLS implementation will have unequivocal knowledge of what data has been successfully received by the remote implementation, as far as signalling will allow), and sequencing (data packets will not be presented to the TLS implementation out-of-sequence). -Kyle H _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jul 06 15:23:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyZRN-0007R3-6z; Thu, 06 Jul 2006 15:23:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FyZRL-0007Qc-P3 for tls@ietf.org; Thu, 06 Jul 2006 15:23:07 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FyZRK-0007Qg-Dt for tls@ietf.org; Thu, 06 Jul 2006 15:23:07 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id F04AE1E8C21; Thu, 6 Jul 2006 12:23:05 -0700 (PDT) To: "Kyle Hamilton" Subject: Re: [TLS] KH comment (tls 1.2 draft) References: <6b9359640607061007q5d2a5d24ha55ecc6c06f871c1@mail.gmail.com> From: Eric Rescorla Date: Thu, 06 Jul 2006 12:23:05 -0700 In-Reply-To: <6b9359640607061007q5d2a5d24ha55ecc6c06f871c1@mail.gmail.com> (Kyle Hamilton's message of "Thu, 6 Jul 2006 10:07:43 -0700") Message-ID: <86slley1uu.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR 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: , Errors-To: tls-bounces@lists.ietf.org "Kyle Hamilton" writes: > Comments on protocol and TLS 1.2 draft: > > AMBIGUITY: Section 6.0 > The draft states "If a TLS implementation receives a record type it > does not understand, it SHOULD just ignore it." Does this mean that > the implementation does NOT update its read_sequence_number when it > receives it? Or should the application attempt to decrypt it with the > current state and verify that its MAC at least matches the updated > sequence number? (Ignorance in this fashion allows TCP injection > against unmatched servers and clients, and possibly-vulnerable > implementations that do not properly check the record type it received > against the record types defined in a particular version of the > protocol -- i.e., a newer version of the protocol may define new > record types, and on a communication with an older client might act as > though it "knows" about the record type that was sent and attempt to > process the record any case, thus forcing a bad_record_mac error.) Well, there are lots of ways to force a bad_record_mac error... > So, what is the correct handling? Ignore completely, or decode and > update the sequence number? The latter. > ASSUMPTION: Entire Document > It is universally assumed that this protocol will only be used over a > sequenced network. It is advantageous in certain circumstances to use > this protocol over other types of transports, such as packet radio or > dial-up serial EDI. In both of these cases, "line noise" (the bane of > SLIP, since that protocol didn't update the IP checksum properly) can > cause data packets to fail to decode properly. See RFC 4347 (Datagram TLS). > It should be stated > exactly what the assumed network parameters are: Error > detecting/correcting (to prevent errors between the two systems > communicating with this protocol), reliability (the TLS implementation > will have unequivocal knowledge of what data has been successfully > received by the remote implementation, as far as signalling will > allow), and sequencing (data packets will not be presented to the TLS > implementation out-of-sequence). This is what "reliable transport protocol" is generally taken to mean in the IETF. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jul 06 20:18:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fye3N-0004Jp-L3; Thu, 06 Jul 2006 20:18:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fye3M-0004JZ-Bl; Thu, 06 Jul 2006 20:18:40 -0400 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fye3L-0007ye-0g; Thu, 06 Jul 2006 20:18:40 -0400 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id E8147222426; Thu, 6 Jul 2006 17:26:46 -0700 (PDT) To: mmusic@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.0.4; XEmacs 21.4 (patch 19) Date: Thu, 06 Jul 2006 17:18:38 -0700 From: Eric Rescorla Message-Id: <20060707002646.E8147222426@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Cc: tls@ietf.org Subject: [TLS] Comments on draft-ietf-mmusic-rfc2326bis-13 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org At the Dallas IETF, Magnus asked for a review by the TLS WG of draft-ietf-mmusic-rfc2326bis. I've read the document, focusing on S 18. Comments follow: S 3.3: I think more guidance is needed about session identifiers. They need to be chosen not just randomly but cryptographically randomly, right? A citation to RFC 4086 seems appropriate here. S 9.3, 9.4: Is there some rationale available for 10 seconds, 5 seconds, etc.? 11.3: server. This allows the client to enumerate in priority order the transport mechanisms and parameters acceptable to it, while the server can select the most appropriate. It is expected that the I'm not sure what "priority order" means here. Descending order of preference? 11.7-11.8: I'm confused about the parameters format. I don't really understand how it can be undefined. Can this be explained better? 14.10: It should be noted that no-cache isn't a DRM-type measure, since caches can cheat--there's no security measure stopping it.... S 18: Security and Proxies The basic theory behind RTSPS's interaction with non-transparent proxies is that the client gives the proxy instructions in the RTSP Headers about what TLS policies to follow. It can use any of three policies: 1. Any (Accept any peer certificate) 2. Proxy (Do whatever you think is appropriate) 3. User (Accept the following certificates and prompt me for any others) I've got several concerns about this design. 1. There doesn't seem to be any way to communicate your cipher suite preferences. 2. I don't see how certificate-based client authentication works. Is it supposed to? 3. You need to provide the entire cert chain in Connection-Credentials, not just the certifcate. Minor comments. section any reference to proxy will be to a non-transparent proxy, which requires to inspect/manipulate the RTSP messages. s/requires/needs/ the end server. Note that, when the client checks the server Remove the comma after "that" -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Jul 10 16:36:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G02Ug-0002HQ-S4; Mon, 10 Jul 2006 16:36:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G02Ue-0002Ge-R9 for tls@ietf.org; Mon, 10 Jul 2006 16:36:36 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G00Qi-0004u6-5Z for tls@ietf.org; Mon, 10 Jul 2006 14:24:24 -0400 Received: from [132.219.15.238] (helo=delta.rtfm.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G00Qg-00060o-Go for tls@ietf.org; Mon, 10 Jul 2006 14:24:24 -0400 Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 5B0B61CC22 for ; Mon, 10 Jul 2006 11:23:22 -0700 (PDT) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19) Date: Mon, 10 Jul 2006 11:23:22 -0700 From: EKR Message-Id: <20060710182322.5B0B61CC22@delta.rtfm.com> X-Spam-Score: -1.1 (-) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Cc: Subject: [TLS] Slides X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Can people please send Pasi and I copies of your slides before noon tomorrow? Thanks, -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jul 11 12:14:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0KsO-0001V1-ES; Tue, 11 Jul 2006 12:14:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0KsN-0001Uu-Ef for tls@ietf.org; Tue, 11 Jul 2006 12:14:19 -0400 Received: from moutng.kundenserver.de ([212.227.126.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0KsM-0004Dj-2B for tls@ietf.org; Tue, 11 Jul 2006 12:14:19 -0400 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1G0KsJ1XAJ-0003D7; Tue, 11 Jul 2006 18:14:16 +0200 Received: by tau.invalid (Postfix, from userid 1000) id 2432719456; Tue, 11 Jul 2006 18:14:13 +0200 (CEST) Date: Tue, 11 Jul 2006 18:14:13 +0200 From: Bodo Moeller To: "Linn, John" Subject: Re: [TLS] Comments on draft-linn-otp-tls-00 Message-ID: <20060711161413.GA28064@iota.site> References: <20060702164726.DE385222425@laser.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: =?iso-8859-1?Q?Nystr=F6m=2C?= Magnus , tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Wed, Jul 05, 2006 at 09:51:34AM -0400, Linn, John wrote: > 6. I'm very uncomfortable with creating all these alerts. Note > that the TLS alert space is only 8 bits wide. Note also > that per RFC 4346 Alerts can only be created by Standards > action. > [JL] Is there existing guidance and precedent to qualify definition > of alerts that are specific to particular methods or ciphersuites? > I respect the need to conserve the alert space, and compression > relative to the current proposal would be possible, but would like > to identify a means to provide sufficiently descriptive indicators > as to disambiguate failure cases. Consider client authentication using just plain old X.509 certificates. When the server does not accept the client's certificate chain, there generally are two possible ways to handle this: 1. Send a fatal alert. 2. Continue with the TLS connection, but don't consider the client authenticated. Depending on the application that is running over TLS, the error can be described on a higher level (i.e., as part of a higher-level protocol error message, or simply as text in a way that suits the application). Shouldn't this work for one-time passwords as well to convey detailed error information? For the case that an alert is sent, you might consider overloading some existing alerts. Some new alerts may be warranted, such as "unsupported_otp_algorithm"; but how about, for example, using "certificate_expired" where your draft has "otp_key_expired"? (Then in the case that a client uses *both* a certificate and a one-time password, the alert loses some information since the client may not be able to tell if it refers to the certificate or the password. But then, "certificate_expired" doesn't give all the details anyway -- it could refer to any certificate in the client's certification chain. For a more complete error report with details and explanations, you often can use option #2 with application-level error reporting.) _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jul 13 07:53:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0zkT-00054e-12; Thu, 13 Jul 2006 07:52:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0zkR-00054Z-Po for tls@ietf.org; Thu, 13 Jul 2006 07:52:51 -0400 Received: from [132.219.5.135] (helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0zkQ-0008O7-JI for tls@ietf.org; Thu, 13 Jul 2006 07:52:51 -0400 Received: from networkresonance.com (localhost.rtfm.com [127.0.0.1]) by delta.rtfm.com (Postfix) with ESMTP id 9A79D1CC22; Thu, 13 Jul 2006 04:51:54 -0700 (PDT) To: tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19) Date: Thu, 13 Jul 2006 04:51:54 -0700 From: EKR Message-Id: <20060713115154.9A79D1CC22@delta.rtfm.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: hartmans-ietf@mit.edu Subject: [TLS] TLS WG Summary X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org The TLS WG WG met at 3:20 on Tuesday. The major topic of discussion was TLS 1.2. There were no major comments on the current status of the document. We discussed a bunch of options on negotiating PRFs and backward compatibility and expect to meet our milestones. TLS Counter Mode is basically done and the chairs will be taking it to WG Last Call immediately after IETF. Andrea Doherty presented OTP for PSK for IETF. Group read was that this wasn't secure enough in its current form to take on. Uri Blumenthal presented on TLS-PSK NULL encryption mode. The WG agreed this was a good idea and Pasi and Joe Salowey agreed to review it Yngve Pettersen presented his work on TLS interop. This was considered good and the TLS WG agreed to take it on. Ben Laurie and Stefan Santesson are going to provide more examples of interoperability. Michael Tuexen presented on running DTLS over SCTP. The issue is that SCTP has a partially reliable mode and they need to protect against packet drops. SCTP AUTH does this but needs keying material. They want to extract it from DTLS, but this has layering issues. Michael Tuexen to post about this to the DTLS mailing list. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 14 02:20:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1H1Z-00051B-CR; Fri, 14 Jul 2006 02:19:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1H1Y-000516-MG for tls@ietf.org; Fri, 14 Jul 2006 02:19:40 -0400 Received: from py-out-1112.google.com ([64.233.166.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1H1X-00033C-Eo for tls@ietf.org; Fri, 14 Jul 2006 02:19:40 -0400 Received: by py-out-1112.google.com with SMTP id t32so543191pyc for ; Thu, 13 Jul 2006 23:19:39 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=FLJxU6E0A9tQp4D0Fsj1odRjJMaRuT09+anlF7obhDJXO+UC+vfNJ6RxLddJqDCh87v0wKdoPHNQgiYCCxIOQC3C49fZrJGP98WNq9x2e//to6jkm1waKDBUgUQYNiMTQSXGyGBJfYrAjfK7vlKBHuhyDuk4AiFrW9MpB1thNVk= Received: by 10.35.37.18 with SMTP id p18mr1588798pyj; Thu, 13 Jul 2006 23:19:39 -0700 (PDT) Received: by 10.35.37.3 with HTTP; Thu, 13 Jul 2006 23:19:38 -0700 (PDT) Message-ID: <4717c1330607132319g57470479l4892d842302b7ea0@mail.gmail.com> Date: Fri, 14 Jul 2006 10:19:38 +0400 From: "Gregory Chudov" To: "Eric Rescorla" Subject: Re: [TLS] Updated TLS 1.2 I-D In-Reply-To: <20060625170241.E4704222425@laser.networkresonance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20060625170241.E4704222425@laser.networkresonance.com> X-Spam-Score: 1.9 (+) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Concerning Certificate Verify message: > If the SignatureAlgorithm > is DSA, then the sha_hash value must be used. If it is RSA, > the same function (denoted Hash) must be used as was used to > create the signature for the client's certificate. This doesn't look reasonable. Aside from general "bad feeling" about this, i have at least three examples in which this causes trouble: 1) First situation is a constrained client, which uses client_certificate_url extension, and doesn't have to know it's own certificate, only it's own private key. The heuristic that you propose forces this client to also know the hash algorithm used by CA. 2) The second situation is a simple client implementation which supports only one hash function. This paragraph forces it to support also the hash functions, which were used by CA to sign his certificates. 3) The third situation is this: a client posesses a certificate, issued by a CA with a good hash function, which is not yet supported by TLS HashType enum (e.g. SHA384). Certificate Request message, which now contains a list of supported hash types, cannot contain such a value, so the client is forced not to use such a certificate. My proposition is: 1) Change the structure of the CertificateVerify message to reflect the change to CertificateRequest: struct { HashType hash_type; Signature signature; } CertificateVerify; Change the text to following: The Signature type is defined in 7.4.3. Client chooses a hash function (denoted Hash) from the list, contained in the CertificateRequest.certificate_hash to create the signature for the client's certificate, and specifies it's type in the CertificateVerify.hash_type field. CertificateVerify.signature.hash Hash(handshake_messages); 2) I think, the role of the CertificateRequest.certificate_hash list must be clearly stated in the draft. I see 3 possible choices: a) it is provided to the client as a guidance b) the server MUST verify that the CertificateVerify message uses one of the hash_types that it proposed c) the server MUST verify that the CertificateVerify message AND the client certificate chain uses only the proposed set of hashes I would strongly prefer the "b" case, because the "a" case can lead to the sitiuation where the server cannot verify client's signature, and the "c" case forces us to specify HashTypes for all the hash functions supported by PKIX (see the 3d situation above). The only alternative i see to this set of changes is to omit the certificate_hash list from CertificateRequest completely, and state that the Hash function is chosen by the cipher suite. Regards, Greg Chudov _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 14 06:04:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1KXJ-0005AG-Hl; Fri, 14 Jul 2006 06:04:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G1KXI-0005AA-2e for tls@ietf.org; Fri, 14 Jul 2006 06:04:40 -0400 Received: from moutng.kundenserver.de ([212.227.126.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G1KXF-0002Eq-Ih for tls@ietf.org; Fri, 14 Jul 2006 06:04:39 -0400 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis), id 0MKxQS-1G1KXC0AXr-0002iN; Fri, 14 Jul 2006 12:04:34 +0200 Received: by tau.invalid (Postfix, from userid 1000) id 63B5517D45; Fri, 14 Jul 2006 12:04:32 +0200 (CEST) Date: Fri, 14 Jul 2006 12:04:32 +0200 From: Bodo Moeller To: Gregory Chudov Subject: Re: [TLS] Updated TLS 1.2 I-D Message-ID: <20060714100431.GA9599@iota.site> References: <20060625170241.E4704222425@laser.networkresonance.com> <4717c1330607132319g57470479l4892d842302b7ea0@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4717c1330607132319g57470479l4892d842302b7ea0@mail.gmail.com> User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Fri, Jul 14, 2006 at 10:19:38AM +0400, Gregory Chudov wrote: > Concerning Certificate Verify message: >> If the SignatureAlgorithm >> is DSA, then the sha_hash value must be used. If it is RSA, >> the same function (denoted Hash) must be used as was used to >> create the signature for the client's certificate. > This doesn't look reasonable. > > Aside from general "bad feeling" about this, i have at least three > examples in which this causes trouble: [...] Also, sha_hash is a SHA-1 hash, but the FIPS 186-3 (Digital Signature Standard) draft also provides for use of the longer SHAs from FIPS 180-2 for prime moduli over 1024 bits. (The subgroup size determines the recommended SHA variant, although it can be agreed to use stronger hash functions with truncation.) > My proposition is: > > 1) Change the structure of the CertificateVerify message to reflect > the change to CertificateRequest: [...] My suggestion is different: Don't change the definition of CertificateRequest in the first place, i.e. don't introduce HashType in the first place. Keep the definitions of the rsa_sign and dss_sign client authentication methods as in current TLS versions, but define new client authentication methods where the hashing is done differently. There could be something like dsa_sign_fips_186_3 where hashing is done as recommended in FIPS 186-3 (here I'm hoping that this actually gets standardized within a reasonable timeframe). There are only aesthetical reasons to get rid of the current MD5/SHA-1 concatenation in RSA client authentication. Authentication can only broken if the attack succeeds in real time (and this requires a second preimage, not just a collision!). As long as we have the current Finished message (which involves MD5 anyway, so no implementation can do without it), not much speaks against leaving RSA signing as it is now. However, here too we could add a FIPS 186-3 variant, meaning that depending on the modulus size a wider SHA can be used, adopting the "security strength" for RSA moduli from NIST SP 800-57 to obtain the appropriate SHA variant. (I.e., SHA-1 up to 1024 bits, SHA-224 up to 2048 bits, SHA-256 up to 3072 bits, SHA-384 up to 7680 bits, SHA-512 up to 15360 bits.) _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jul 18 03:02:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2jbN-0008R8-Ox; Tue, 18 Jul 2006 03:02:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2jbM-0008R2-FR for tls@lists.ietf.org; Tue, 18 Jul 2006 03:02:40 -0400 Received: from ug-out-1314.google.com ([66.249.92.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2jbL-0001Nf-5r for tls@lists.ietf.org; Tue, 18 Jul 2006 03:02:40 -0400 Received: by ug-out-1314.google.com with SMTP id m2so1257534uge for ; Tue, 18 Jul 2006 00:02:38 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id:sender; b=rCsFRy6zKWbouuOrecRyYEztYvbydb7ayf3mVgVjb3v5tIZjPBWP1czj5M1R4UFG5utdlRBAKI1Wl/+cdZdfX9TcdRqiZLvzXJ/DwUwzLzWjJ7GRWPit/iWKAm9OaipuOuWVyBtw2bJ7uJKi49z12sUJ6L/vE1oKaxrpMJxNJ9Q= Received: by 10.67.93.7 with SMTP id v7mr3303638ugl; Tue, 18 Jul 2006 00:02:38 -0700 (PDT) Received: from ?172.16.1.196? ( [81.175.93.238]) by mx.gmail.com with ESMTP id s1sm313331uge.2006.07.18.00.02.36; Tue, 18 Jul 2006 00:02:36 -0700 (PDT) From: Nikos Mavrogiannopoulos To: tls@lists.ietf.org Subject: Re: [TLS] TLS WG Summary Date: Tue, 18 Jul 2006 09:02:33 +0200 User-Agent: KMail/1.9.1 References: <20060713115154.9A79D1CC22@delta.rtfm.com> In-Reply-To: <20060713115154.9A79D1CC22@delta.rtfm.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-7" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200607180902.34794.nmav@gnutls.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Thu 13 Jul 2006 13:51, EKR wrote: > TLS Counter Mode is basically done and the chairs will be taking > it to WG Last Call immediately after IETF. I have a question on the design of ctr. According to the text: 3.1.3. Counter Block Construction To construct the counter block, the leftmost 48-bits of the counter block are set to the rightmost 48-bits of the client_write_IV (for the half-duplex stream originated by the client) or the rightmost 48- bits of the server_write_IV (for the half-duplex stream originated by [...] This would mean that say for AES an 128-bit IV is generated just to use the 48 rightmost bits. Why is this done? Wouldn't it be simpler to say that the IV is 48 bits in CTR mode? regards, Nikos _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jul 18 06:01:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2mOf-0000XN-U6; Tue, 18 Jul 2006 06:01:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2mOf-0000XI-9E for tls@ietf.org; Tue, 18 Jul 2006 06:01:45 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2mOd-000300-RH for tls@ietf.org; Tue, 18 Jul 2006 06:01:45 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6IA1gZZ007219 for ; Tue, 18 Jul 2006 13:01:42 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Jul 2006 13:01:20 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 18 Jul 2006 13:01:20 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 18 Jul 2006 13:01:19 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Authentication-only ciphersuites for TLS-PSK? Thread-Index: AcaqUR2e1NMw2d7AS3+rkUBZI8Xk6g== From: To: X-OriginalArrivalTime: 18 Jul 2006 10:01:20.0902 (UTC) FILETIME=[1E987A60:01C6AA51] X-Spam-Score: 0.2 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [TLS] Authentication-only ciphersuites for TLS-PSK? X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Hi everyone, At the TLS meeting in Montreal last week, Uri Blumenthal gave a presentation about adding "authentication-only" PSK ciphersuites (i.e., NULL encryption): http://www3.ietf.org/proceedings/06jul/slides/tls-2.pdf=20 This has not been submitted as an Internet-Draft yet, but I'd assume the document-to-be should be quite simple (maybe a page of content plus couple of pages of boilerplate). However, even though it's simple, it would be good to get people to review the document to ensure that nothing serious is missed, and the security considerations are accurately described. Taking this as a TLS WG item would be one way to encourage such reviews. Are there any objections to accepting this as a WG item? Best regards, Pasi & Eric _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 21 05:39:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3rTz-0004dO-Pc; Fri, 21 Jul 2006 05:39:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3rTy-0004dJ-S7 for tls@ietf.org; Fri, 21 Jul 2006 05:39:42 -0400 Received: from moutng.kundenserver.de ([212.227.126.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3rTx-0001Ha-Ei for tls@ietf.org; Fri, 21 Jul 2006 05:39:42 -0400 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1G3rTv3rPL-00048b; Fri, 21 Jul 2006 11:39:40 +0200 Received: by tau.invalid (Postfix, from userid 1000) id E004517D41; Fri, 21 Jul 2006 11:39:38 +0200 (CEST) Date: Fri, 21 Jul 2006 11:39:38 +0200 From: Bodo Moeller To: tls@ietf.org Subject: Re: [TLS] I-D ACTION:draft-ietf-tls-psk-null-00.txt Message-ID: <20060721093938.GA21125@iota.site> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Thu, Jul 20, 2006 at 06:50:01PM -0400, Internet-Drafts@ietf.org wrote: > Title : Pre-Shared Key Cipher Suite with NULL Encryption for Transport Layer Security > Author(s) : U. Blumenthal, P. Goel > Filename : draft-ietf-tls-psk-null-00.txt > Pages : 5 > Date : 2006-7-20 > > This document specifies authentication-only cipher suites for the > Pre-Shared Key based [TLS-PSK] Transport Layer Security (TLS) [TLS] > protocol to support null encryption. These cipher suites are useful > for countries and places with cryptography-related restrictions. > http://www.ietf.org/internet-drafts/draft-ietf-tls-psk-null-00.txt The new I-D contains three ciphersuites: TLS_PSK_WITH_NULL_SHA TLS_DHE_PSK_WITH_NULL_SHA TLS_RSA_PSK_WITH_NULL_SHA Is there a good case for definining a DHE_PSK ciphersuite with NULL encryption? RSA_PSK involves server certificates, so it does not solely rely on pre-shared keys for authentication. DHE_PSK, however, uses ephemeral Diffie-Hellman without certificate-based authentication. This is very useful when the key exchange is used to obtain keys for symmetric encryption. However, in these NULL encryption ciphersuites, the key exchange is only used to derive authentication keys, so there is only a very limited need for forward security. (DHE_DSK, when using NULL encryption, provides protection against exposure of a pre-shared key if use of said key has been stopped, but TLS session based on the key remain active.) If we are going to allocate additional ciphersuite numbers for new PSK ciphersuites, other key exchange mechanisms for use with symmetric encryption would appear more useful to me than DHE_PSK for NULL encryption: RFC 4247 does not have any DHE_RSA_PSK and EDH_DSS_PSK methods, which would combine ephemeral Diffie-Hellman with RSA or DSA certificates -- thus providing both forward security and certificate-based server authentication. I don't know if this variant is really needed (probably so rarely that combining multiple different key exchange methods via renegotiation is a more reasonable technique than specifying another set of specific ciphersuites), but it certainly looks more useful to me than TLS_DHE_PSK_WITH_NULL_SHA! So currently I think we should cut down the I-D to only two ciphersuites, TLS_PSK_WITH_NULL_SHA and TLS_RSA_PSK_WITH_NULL_SHA. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 21 08:04:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3tjh-00062t-9j; Fri, 21 Jul 2006 08:04:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3tjg-00062Y-M7 for tls@ietf.org; Fri, 21 Jul 2006 08:04:04 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3tVK-0004Vp-L5 for tls@ietf.org; Fri, 21 Jul 2006 07:49:16 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k6LBn603012917; Fri, 21 Jul 2006 14:49:10 +0300 Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 21 Jul 2006 14:49:05 +0300 Received: from 4FIL09356 ([172.21.41.214]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 21 Jul 2006 14:49:05 +0300 From: "Pasi Eronen" To: "'ext Bodo Moeller'" , Subject: RE: [TLS] I-D ACTION:draft-ietf-tls-psk-null-00.txt Date: Fri, 21 Jul 2006 14:49:06 +0300 Message-ID: <000101c6acbb$ab8d64f0$d62915ac@NOE.Nokia.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcasqeGSFIQMnPbsRCynbVOqS3RLYQAEJJyA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <20060721093938.GA21125@iota.site> X-OriginalArrivalTime: 21 Jul 2006 11:49:05.0279 (UTC) FILETIME=[AAE760F0:01C6ACBB] X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Bodo Moeller wrote: > Is there a good case for definining a DHE_PSK ciphersuite with NULL > encryption? RSA_PSK involves server certificates, so it does not > solely rely on pre-shared keys for authentication. DHE_PSK, however, > uses ephemeral Diffie-Hellman without certificate-based > authentication. This is very useful when the key exchange is used to > obtain keys for symmetric encryption. However, in these NULL > encryption ciphersuites, the key exchange is only used to derive > authentication keys, so there is only a very limited need for forward > security. (DHE_DSK, when using NULL encryption, provides protection > against exposure of a pre-shared key if use of said key has been > stopped, but TLS session based on the key remain active.) With DHE_PSK, a passive eavesdropper doesn't get the information required for a dictionary attack against the PSK. So it might be useful even with NULL encryption in some environments (where active MitM is not considered a significant threat, and the PSK is not guaranteed to be "strong enough"). I'm not sure how common those environments would be, but then again, I didn't think that anyone would want NULL encryption either... Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 21 08:23:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3u2G-0003EI-QE; Fri, 21 Jul 2006 08:23:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3u2F-0003DL-Hd for tls@ietf.org; Fri, 21 Jul 2006 08:23:15 -0400 Received: from moutng.kundenserver.de ([212.227.126.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3tuu-0007cG-SO for tls@ietf.org; Fri, 21 Jul 2006 08:15:42 -0400 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1G3tut2h77-0003z3; Fri, 21 Jul 2006 14:15:39 +0200 Received: by tau.invalid (Postfix, from userid 1000) id 5DDED17D1B; Fri, 21 Jul 2006 14:15:37 +0200 (CEST) Date: Fri, 21 Jul 2006 14:15:37 +0200 From: Bodo Moeller To: Pasi Eronen Subject: Re: [TLS] I-D ACTION:draft-ietf-tls-psk-null-00.txt Message-ID: <20060721121537.GA30405@iota.site> References: <20060721093938.GA21125@iota.site> <000101c6acbb$ab8d64f0$d62915ac@NOE.Nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <000101c6acbb$ab8d64f0$d62915ac@NOE.Nokia.com> User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Fri, Jul 21, 2006 at 02:49:06PM +0300, Pasi Eronen wrote: > Bodo Moeller wrote: >> Is there a good case for definining a DHE_PSK ciphersuite with NULL >> encryption? RSA_PSK involves server certificates, so it does not >> solely rely on pre-shared keys for authentication. DHE_PSK, however, >> uses ephemeral Diffie-Hellman without certificate-based >> authentication. This is very useful when the key exchange is used to >> obtain keys for symmetric encryption. However, in these NULL >> encryption ciphersuites, the key exchange is only used to derive >> authentication keys, so there is only a very limited need for forward >> security. (DHE_DSK, when using NULL encryption, provides protection >> against exposure of a pre-shared key if use of said key has been >> stopped, but TLS session based on the key remain active.) > With DHE_PSK, a passive eavesdropper doesn't get the information > required for a dictionary attack against the PSK. > > So it might be useful even with NULL encryption in some environments > (where active MitM is not considered a significant threat, and the PSK > is not guaranteed to be "strong enough"). I'm not sure how common > those environments would be, but then again, I didn't think that > anyone would want NULL encryption either... OK, DHE_PSK can help for low-entropy passwords -- which you shouldn't use, but which we shouldn't rely on not being used, I guess. This makes sense, but warrants explanation in the Security Considerations section. The Security Considerations ought to point out that - DHE_PSK helps only if RSA_PSK and plain PSK ciphersuites are disabled (otherwise the adversary needs only a single connection attempt from a client to a rogue server to get data for a dictionary attack), and - small subgroup attack countermeasures are required even though there is no DH key reuse. RFC 4346 mentions small-subgroup attacks, but only says that the need to be prevented when "the same DH keypair is to be used to prevent small subgroup attacks". This makes sense for DH as used in the usual TLS ciphersuites, but the DHE ciphersuites from RFC 4279 have stronger requirements if they are to be used as a dictionary attack countermeasure. If the client does not check for small subgroups, then a single connection attempt to a rogue server can provide the server with the data needed for a dictionary attack, essentially like in plain PSK ciphersuites. This (at least the latter) is actually a bug report for RFC 4279, not just for the new I-D. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 21 11:01:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3wUt-0006H8-TD; Fri, 21 Jul 2006 11:00:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3wUt-0006H3-8s for tls@ietf.org; Fri, 21 Jul 2006 11:00:59 -0400 Received: from moutng.kundenserver.de ([212.227.126.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3wUr-0003CP-Kq for tls@ietf.org; Fri, 21 Jul 2006 11:00:59 -0400 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1G3wUp3zs8-0000sG; Fri, 21 Jul 2006 17:00:56 +0200 Received: by tau.invalid (Postfix, from userid 1000) id 122D81895D; Fri, 21 Jul 2006 17:00:54 +0200 (CEST) Date: Fri, 21 Jul 2006 17:00:54 +0200 From: Bodo Moeller To: Eric Rescorla Subject: Re: [TLS] I-D ACTION:draft-ietf-tls-psk-null-00.txt Message-ID: <20060721150054.GA15450@iota.site> References: <20060721093938.GA21125@iota.site> <000101c6acbb$ab8d64f0$d62915ac@NOE.Nokia.com> <20060721121537.GA30405@iota.site> <86u05b10us.fsf@raman.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86u05b10us.fsf@raman.networkresonance.com> User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Pasi Eronen , tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Fri, Jul 21, 2006 at 07:36:27AM -0700, Eric Rescorla wrote: > Bodo Moeller writes: >> RFC 4346 mentions small-subgroup attacks, but only says that the >> need to be prevented when "the same DH keypair is to be used to >> prevent small subgroup attacks". This makes sense for DH as used in >> the usual TLS ciphersuites, but the DHE ciphersuites from RFC 4279 >> have stronger requirements if they are to be used as a dictionary >> attack countermeasure. If the client does not check for small >> subgroups, then a single connection attempt to a rogue server can >> provide the server with the data needed for a dictionary attack, >> essentially like in plain PSK ciphersuites. > I just woke up so I may be kind of slow, but I'm not sure I > understand why small subgroups make this problem any worse. > If the client connects to a rogue server, the server uses > a DH pair of his choice and so gets the client to give > him a value that's a function of ZZ (known) and the > PSK. Why is this any easier with a small subgroup? > It's true that with a small subgroup the server can force > ZZ to a specific value, but since the PSK calculation > gets salted with the randoms, I'm not sure why that > matters. With a low-entropy pre-shared key and without DH, there is plenty of randomness in the calculations, but most of this is openly transmitted. Only the PSK is hidden, which is why plain PSK ciphersuites allow for offline dictionary attacks. Enter DH. This allows us to have a lot more randomness in the protocol that is not openly transmitted, thus providing protection against passive dictionary attacks. However, if the server can arrange the DH result ZZ to be a specific value (such as 1 or p-1) by using small subgroups, that hidden randomness in the DH exchange no longer affects the final key exchange result. Only the openly transmitted randomness and the PSK remain effective, so the server can try different guesses for the PSK in an offline dictionary attack after having received the client's "Finished" from this handshake. So there's the dictionary attack again, almost as if DH wasn't even in the protocol. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 21 11:17:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3wkm-0001Qq-TM; Fri, 21 Jul 2006 11:17:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3wkl-0001Qa-C2 for tls@ietf.org; Fri, 21 Jul 2006 11:17:23 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3whz-0004w0-Ft for tls@ietf.org; Fri, 21 Jul 2006 11:14:32 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id D676B1E8C34; Fri, 21 Jul 2006 08:14:30 -0700 (PDT) To: Bodo Moeller Subject: Re: [TLS] I-D ACTION:draft-ietf-tls-psk-null-00.txt References: <20060721093938.GA21125@iota.site> <000101c6acbb$ab8d64f0$d62915ac@NOE.Nokia.com> <20060721121537.GA30405@iota.site> <86u05b10us.fsf@raman.networkresonance.com> <20060721150054.GA15450@iota.site> From: Eric Rescorla Date: Fri, 21 Jul 2006 08:14:30 -0700 In-Reply-To: <20060721150054.GA15450@iota.site> (Bodo Moeller's message of "Fri, 21 Jul 2006 17:00:54 +0200") Message-ID: <86psfz0z3d.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: Pasi Eronen , tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR 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: , Errors-To: tls-bounces@lists.ietf.org Bodo Moeller writes: > On Fri, Jul 21, 2006 at 07:36:27AM -0700, Eric Rescorla wrote: > With a low-entropy pre-shared key and without DH, there is plenty of > randomness in the calculations, but most of this is openly > transmitted. Only the PSK is hidden, which is why plain PSK > ciphersuites allow for offline dictionary attacks. > > Enter DH. This allows us to have a lot more randomness in the > protocol that is not openly transmitted, thus providing protection > against passive dictionary attacks. > > However, if the server can arrange the DH result ZZ to be a specific > value (such as 1 or p-1) by using small subgroups, that hidden > randomness in the DH exchange no longer affects the final key exchange > result. Only the openly transmitted randomness and the PSK remain > effective, so the server can try different guesses for the PSK in an > offline dictionary attack after having received the client's > "Finished" from this handshake. So there's the dictionary attack > again, almost as if DH wasn't even in the protocol. But in order for the server to do this, it needs to be part of the protocol, which means that it would have access to the hidden randomness anyway. The attack you describe is a single active attack + offline computation, just as in the ordinary DH case. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 21 11:43:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3x9y-00061T-H8; Fri, 21 Jul 2006 11:43:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G3x9w-0005zY-If for tls@ietf.org; Fri, 21 Jul 2006 11:43:24 -0400 Received: from moutng.kundenserver.de ([212.227.126.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G3ww9-0006fg-Ai for tls@ietf.org; Fri, 21 Jul 2006 11:29:10 -0400 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1G3ww62j7d-0005Zi; Fri, 21 Jul 2006 17:29:07 +0200 Received: by tau.invalid (Postfix, from userid 1000) id 9B1D410DC1; Fri, 21 Jul 2006 17:29:05 +0200 (CEST) Date: Fri, 21 Jul 2006 17:29:05 +0200 From: Bodo Moeller To: Eric Rescorla Subject: Re: [TLS] I-D ACTION:draft-ietf-tls-psk-null-00.txt Message-ID: <20060721152905.GA18386@iota.site> References: <20060721093938.GA21125@iota.site> <000101c6acbb$ab8d64f0$d62915ac@NOE.Nokia.com> <20060721121537.GA30405@iota.site> <86u05b10us.fsf@raman.networkresonance.com> <20060721150054.GA15450@iota.site> <86psfz0z3d.fsf@raman.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86psfz0z3d.fsf@raman.networkresonance.com> User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Pasi Eronen , tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Fri, Jul 21, 2006 at 08:14:30AM -0700, Eric Rescorla wrote: > Bodo Moeller writes: >> With a low-entropy pre-shared key and without DH, there is plenty of >> randomness in the calculations, but most of this is openly >> transmitted. Only the PSK is hidden, which is why plain PSK >> ciphersuites allow for offline dictionary attacks. >> >> Enter DH. This allows us to have a lot more randomness in the >> protocol that is not openly transmitted, thus providing protection >> against passive dictionary attacks. >> >> However, if the server can arrange the DH result ZZ to be a specific >> value (such as 1 or p-1) by using small subgroups, that hidden >> randomness in the DH exchange no longer affects the final key exchange >> result. Only the openly transmitted randomness and the PSK remain >> effective, so the server can try different guesses for the PSK in an >> offline dictionary attack after having received the client's >> "Finished" from this handshake. So there's the dictionary attack >> again, almost as if DH wasn't even in the protocol. > But in order for the server to do this, it needs to be part > of the protocol, which means that it would have access > to the hidden randomness anyway. The attack you describe > is a single active attack + offline computation, just as > in the ordinary DH case. Oops, yes, you are right. DHE_PSK can only provide protection against dictionary attacks if no client ever uses the pre-shared key in a connection to an adversarial server. With an active attacker, all bets are off anyway. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 21 19:43:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G44eh-0008G2-LK; Fri, 21 Jul 2006 19:43:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G44eg-0008Fw-0t for tls@ietf.org; Fri, 21 Jul 2006 19:43:38 -0400 Received: from smtpout10-04.prod.mesa1.secureserver.net ([64.202.165.238]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G44ed-0007x1-KJ for tls@ietf.org; Fri, 21 Jul 2006 19:43:37 -0400 Received: (qmail 6692 invoked from network); 21 Jul 2006 23:43:34 -0000 Received: from unknown (69.174.163.252) by smtpout10-04.prod.mesa1.secureserver.net (64.202.165.238) with ESMTP; 21 Jul 2006 23:43:34 -0000 From: "Ron Teitelbaum" To: Date: Fri, 21 Jul 2006 19:43:34 -0400 Organization: US Medical Records Specialists Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: <20060721152905.GA18386@iota.site> Thread-Index: Acas3G9+n6fgk4cUSBCYSK3fnHdSQwAQGJJQ X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: [TLS] Suggestion for TLS Developer List X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ron@USMedRec.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: , Errors-To: tls-bounces@lists.ietf.org Hi All, Sorry about the OT spam. I'm having some trouble with a server hello, it looks properly formed but when I send it back to a browser it errors out. Can anyone suggest a TLS Developers list I could ask questions on or any other reading I should do about the actual format or examples of the TCP that is sent back in the server hello. Suggestions about other tools that would help to debug the problem on a windows environment would also be very much appreciated. Thank you, Ron Teitelbaum President / Principal Software Developer US Medical Record Specialists Ron@USMedRec.com My ServerHello: a ByteArray(22 3 1 0 75 2 0 0 71 3 1 32 1 133 226 6 25 8 52 139 232 174 232 214 178 59 212 53 40 179 41 3 198 102 25 120 169 92 56 219 169 27 54 52 32 107 191 163 205 21 34 82 15 149 50 249 200 178 121 78 219 88 43 135 114 222 238 60 227 43 11 54 168 168 59 53 241 0 10 0) hex: '160301004B020000470301200185E2061908348BE8AEE8D6B23BD43528B32903C6661978A95 C38DBA91B3634206BBFA3CD1522520F9532F9C8B2794EDB582B8772DEEE3CE32B0B36A8A83B3 5F1000A00' _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 21 20:28:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G45M2-00039R-CT; Fri, 21 Jul 2006 20:28:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G45M0-00039M-W3 for tls@ietf.org; Fri, 21 Jul 2006 20:28:24 -0400 Received: from smtpout10-04.prod.mesa1.secureserver.net ([64.202.165.238]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G45Lz-0004Xv-Kn for tls@ietf.org; Fri, 21 Jul 2006 20:28:24 -0400 Received: (qmail 7458 invoked from network); 22 Jul 2006 00:28:22 -0000 Received: from unknown (69.174.163.252) by smtpout10-04.prod.mesa1.secureserver.net (64.202.165.238) with ESMTP; 22 Jul 2006 00:28:22 -0000 From: "Ron Teitelbaum" To: "'Yngve N. Pettersen \(Developer Opera Software ASA\)'" Subject: RE: [TLS] Suggestion for TLS Developer List Date: Fri, 21 Jul 2006 20:28:22 -0400 Organization: US Medical Records Specialists Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: Thread-Index: AcatI9XbX+xUOk+pRcSehDNnlwFvywAATG6g X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ron@USMedRec.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: , Errors-To: tls-bounces@lists.ietf.org Thank you very much for your response; that was indeed the problem! Now that I've seen that it works I will be much more careful to validate that I've done things properly, and assume first that it's me not Internet Explorer that is the problem. Thanks again! Ron > -----Original Message----- > From: Yngve N. Pettersen (Developer Opera Software ASA) > [mailto:yngve@opera.com] > Sent: Friday, July 21, 2006 8:14 PM > To: Ron@usmedrec.com > Subject: Re: [TLS] Suggestion for TLS Developer List > > Hello Ron, > > On Sat, 22 Jul 2006 01:43:34 +0200, Ron Teitelbaum > wrote: > > > Hi All, > > > > Sorry about the OT spam. I'm having some trouble with a server hello, > it > > looks properly formed but when I send it back to a browser it errors > out. > > > My ServerHello: > > > 16 03 01 00 4B 02 00 00 47 03 01>20<01 85 E2 06 > 19 08 34 8B E8 AE E8 D6 B2 3B D4 35 28 B3 29 03 > C6 66 19 78 A9 5C 38 DB A9 1B 36 34 20 6B BF A3 > CD 15 22 52 0F 95 32 F9 C8 B2 79 4E DB 58 2B 87 > 72 DE EE 3C E3 2B 0B 36 A8 A8 3B 35 F1 00 0A 00 > > I am afraid that the problem is that you are sending a length field > (marked with ><) for the random field, but this field is a fixed size 32 > byte structure. > > My guess is that client either stops at the incorrect session id length, > or at the cipher suite/compression fields which most likely will not match > its expectations. > > Please see RFC 2246 sec. 4.3, 7.4.1.2 and 7.4.1.3 for more information. > > -- > Sincerely, > Yngve N. Pettersen > > ******************************************************************** > Senior Developer Email: yngve@opera.com > Opera Software ASA http://www.opera.com/ > Phone: +47 24 16 42 60 Fax: +47 24 16 40 01 > ******************************************************************** _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Jul 25 20:33:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5XL6-0001DK-KB; Tue, 25 Jul 2006 20:33:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5XL5-0001D6-CB for tls@ietf.org; Tue, 25 Jul 2006 20:33:27 -0400 Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5XL4-0006FY-4V for tls@ietf.org; Tue, 25 Jul 2006 20:33:27 -0400 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k6Q0XPde010100 for ; Tue, 25 Jul 2006 20:33:25 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k6Q0XP4O007080 for ; Tue, 25 Jul 2006 20:33:25 -0400 Received: from [127.0.0.1] (dhcp-172-16-25-208.sfbay.redhat.com [172.16.25.208]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id k6Q0XMcm022656 for ; Tue, 25 Jul 2006 20:33:24 -0400 Message-ID: <44C6B8C1.3040500@redhat.com> Date: Tue, 25 Jul 2006 17:35:13 -0700 From: Wan-Teh Chang User-Agent: Thunderbird 2.0a1 (Windows/20060724) MIME-Version: 1.0 To: tls@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: Subject: [TLS] Suite B compliance of TLS 1.2 X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Content-Type: multipart/mixed; boundary="===============1002661092==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1002661092== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010600040401020309030208" This is a cryptographically signed message in MIME format. --------------ms010600040401020309030208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit At the 2005 RSA Conference, the US National Security Agency (NSA) announced Suite B Crytography (http://www.nsa.gov/ia/industry/crypto_suite_b.cfm). This suite of cryptographic algorithms includes AES, ECDSA, ECDH, ECMQV, and SHA-256/SHA-384. I'm interested in the Suite B compliance of TLS 1.2. Simply put, it means the ability to do TLS 1.2 using only Suite B algorithms. The primary goal of TLS 1.2, to remove the protocol's dependency on the MD5 and SHA-1 digest algorithms, is in line with Suite B compliance. I'd like to start the discussion by proposing additional goals: - merge in or reference RFC 4492 - add sha384 to the enumerated HashType - define cipher suites whose MAC algorithm is Suite B compliant. Since Suite B doesn't include any MAC algorithms and the recent collision attack on SHA-1 doesn't extend to HMAC-SHA-1, this goal may be controversial. Wan-Teh Chang --------------ms010600040401020309030208 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKWDCC BSgwggQQoAMCAQICECPc+9+WtsOZqiiOT1eYr6cwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMR0wGwYDVQQLExRBZGRUcnVzdCBUVFAgTmV0 d29yazEhMB8GA1UEAxMYQWRkVHJ1c3QgQ2xhc3MgMSBDQSBSb290MB4XDTA1MTIyMzAwMDAw MFoXDTA2MTIyMzIzNTk1OVowgdsxNTAzBgNVBAsTLENvbW9kbyBUcnVzdCBOZXR3b3JrIC0g UEVSU09OQSBOT1QgVkFMSURBVEVEMUYwRAYDVQQLEz1UZXJtcyBhbmQgQ29uZGl0aW9ucyBv ZiB1c2U6IGh0dHA6Ly93d3cuY29tb2RvLm5ldC9yZXBvc2l0b3J5MR8wHQYDVQQLExYoYyky MDAzIENvbW9kbyBMaW1pdGVkMRYwFAYDVQQDEw1XYW4tVGVoIENoYW5nMSEwHwYJKoZIhvcN AQkBFhJ3dGNoYW5nQHJlZGhhdC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJZ3 pYgLLfB2IU5Rdd4B/1Z7p391Z+vjH2pCEeQMWxK966ptunHqLmA8Iz/8Tiy5KN9LKRkV9Q2c zvWjapJeyiutrictOZCY2qkRMG6eTbDDT8Tz6qO7iRnUK7JkXs2cZtlk442Xgky+xcLr1cCC RJ8w3d/ul4HKdGZwtsYFLkLpAgMBAAGjggHfMIIB2zAdBgNVHQ4EFgQUAsOMfMcFVfub10xu 3ycfUWaYHO4wDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYB BQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsG AQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQ UzB3BgNVHR8EcDBuMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRUcnVzdENs YXNzMUNBUm9vdC5jcmwwNKAyoDCGLmh0dHA6Ly9jcmwuY29tb2RvLm5ldC9BZGRUcnVzdENs YXNzMUNBUm9vdC5jcmwwgYYGCCsGAQUFBwEBBHoweDA7BggrBgEFBQcwAoYvaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQWRkVHJ1c3RVVE5DbGllbnRDQS5jcnQwOQYIKwYBBQUHMAKGLWh0 dHA6Ly9jcnQuY29tb2RvLm5ldC9BZGRUcnVzdFVUTkNsaWVudENBLmNydDAdBgNVHREEFjAU gRJ3dGNoYW5nQHJlZGhhdC5jb20wDQYJKoZIhvcNAQEFBQADggEBAGpDustBazwJLV/u3OHE gGKhU5QxPPnhJcAs4hPn6oG2de85pKS9/mioaEhf1Huvu8cBaEMIe0dQoGQuqOIiM38WFXRI N4m0SoTu2pw4MXIy9t20kNiqq0ISf/O+kLJ6QrIsRurqw7WexkGkv8S4Z+hgls1wFXTBFsnu vZsgqqtDc2s6EHMh9Wqk4WWCMsr8WExtsst5pnLWHV7BbiquqHrbFZhwRLiWjVrBNDrVT+ym lmZilFt8GHjdrJs3aLvuptP+yzDqIE0jFtlVNn5gLzYSKMMx8twn9yJTHCC2AwAbfmGNf75o yPCS8MqAqupN2B+oST9MqdF6ZpVcxVdR61QwggUoMIIEEKADAgECAhAj3PvflrbDmaoojk9X mK+nMA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBB QjEdMBsGA1UECxMUQWRkVHJ1c3QgVFRQIE5ldHdvcmsxITAfBgNVBAMTGEFkZFRydXN0IENs YXNzIDEgQ0EgUm9vdDAeFw0wNTEyMjMwMDAwMDBaFw0wNjEyMjMyMzU5NTlaMIHbMTUwMwYD VQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQG A1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UE AxMNV2FuLVRlaCBDaGFuZzEhMB8GCSqGSIb3DQEJARYSd3RjaGFuZ0ByZWRoYXQuY29tMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCWd6WICy3wdiFOUXXeAf9We6d/dWfr4x9qQhHk DFsSveuqbbpx6i5gPCM//E4suSjfSykZFfUNnM71o2qSXsorra4nLTmQmNqpETBunk2ww0/E 8+qju4kZ1CuyZF7NnGbZZOONl4JMvsXC69XAgkSfMN3f7peBynRmcLbGBS5C6QIDAQABo4IB 3zCCAdswHQYDVR0OBBYEFALDjHzHBVX7m9dMbt8nH1FmmBzuMA4GA1UdDwEB/wQEAwIFoDAM BgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYd aHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwdwYDVR0fBHAwbjA2oDSgMoYwaHR0cDov L2NybC5jb21vZG9jYS5jb20vQWRkVHJ1c3RDbGFzczFDQVJvb3QuY3JsMDSgMqAwhi5odHRw Oi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1c3RDbGFzczFDQVJvb3QuY3JsMIGGBggrBgEFBQcB AQR6MHgwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0FkZFRydXN0VVRO Q2xpZW50Q0EuY3J0MDkGCCsGAQUFBzAChi1odHRwOi8vY3J0LmNvbW9kby5uZXQvQWRkVHJ1 c3RVVE5DbGllbnRDQS5jcnQwHQYDVR0RBBYwFIESd3RjaGFuZ0ByZWRoYXQuY29tMA0GCSqG SIb3DQEBBQUAA4IBAQBqQ7rLQWs8CS1f7tzhxIBioVOUMTz54SXALOIT5+qBtnXvOaSkvf5o qGhIX9R7r7vHAWhDCHtHUKBkLqjiIjN/FhV0SDeJtEqE7tqcODFyMvbdtJDYqqtCEn/zvpCy ekKyLEbq6sO1nsZBpL/EuGfoYJbNcBV0wRbJ7r2bIKqrQ3NrOhBzIfVqpOFlgjLK/FhMbbLL eaZy1h1ewW4qrqh62xWYcES4lo1awTQ61U/sppZmYpRbfBh43aybN2i77qbT/ssw6iBNIxbZ VTZ+YC82EijDMfLcJ/ciUxwgtgMAG35hjX++aMjwkvDKgKrqTdgfqEk/TKnRemaVXMVXUetU MYIC7DCCAugCAQEweTBlMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxHTAb BgNVBAsTFEFkZFRydXN0IFRUUCBOZXR3b3JrMSEwHwYDVQQDExhBZGRUcnVzdCBDbGFzcyAx IENBIFJvb3QCECPc+9+WtsOZqiiOT1eYr6cwCQYFKw4DAhoFAKCCAckwGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwNzI2MDAzNTEzWjAjBgkqhkiG9w0B CQQxFgQU+0SNm/ZjDTaPd6a/kKqWJBTOdS0wUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0 IEFCMR0wGwYDVQQLExRBZGRUcnVzdCBUVFAgTmV0d29yazEhMB8GA1UEAxMYQWRkVHJ1c3Qg Q2xhc3MgMSBDQSBSb290AhAj3PvflrbDmaoojk9XmK+nMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMR0wGwYDVQQLExRBZGRUcnVz dCBUVFAgTmV0d29yazEhMB8GA1UEAxMYQWRkVHJ1c3QgQ2xhc3MgMSBDQSBSb290AhAj3Pvf lrbDmaoojk9XmK+nMA0GCSqGSIb3DQEBAQUABIGABChaeQfYlK0gPHqzjm0Ib4v7avMvqGNu PZ1Zpj9o7uYxHt7PCjSoAiCEka9WFPVaICQkVmxMdDHL6IFRp4NoTBvALfQil7H7uLBvd89m JrCW5EVL9xup4PFu85XRGcZSlRu5qZdcDGMVrsLBBcE/ztzytUEf76sikbxV6GTPj+IAAAAA AAA= --------------ms010600040401020309030208-- --===============1002661092== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============1002661092==-- From tls-bounces@lists.ietf.org Wed Jul 26 00:32:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5b4R-0000mW-Ka; Wed, 26 Jul 2006 00:32:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5b4R-0000mR-2X for tls@ietf.org; Wed, 26 Jul 2006 00:32:31 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5b4P-0005Vh-OC for tls@ietf.org; Wed, 26 Jul 2006 00:32:31 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id BA6F21E8C1C; Tue, 25 Jul 2006 21:32:28 -0700 (PDT) To: Wan-Teh Chang Subject: Re: [TLS] Suite B compliance of TLS 1.2 References: <44C6B8C1.3040500@redhat.com> From: Eric Rescorla Date: Tue, 25 Jul 2006 21:32:28 -0700 In-Reply-To: <44C6B8C1.3040500@redhat.com> (Wan-Teh Chang's message of "Tue, 25 Jul 2006 17:35:13 -0700") Message-ID: <86fygpyoir.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR 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: , Errors-To: tls-bounces@lists.ietf.org Wan-Teh Chang writes: > At the 2005 RSA Conference, the US National > Security Agency (NSA) announced Suite B Crytography > (http://www.nsa.gov/ia/industry/crypto_suite_b.cfm). > This suite of cryptographic algorithms includes AES, > ECDSA, ECDH, ECMQV, and SHA-256/SHA-384. > > I'm interested in the Suite B compliance of TLS 1.2. > Simply put, it means the ability to do TLS 1.2 using > only Suite B algorithms. > > The primary goal of TLS 1.2, to remove the protocol's > dependency on the MD5 and SHA-1 digest algorithms, is > in line with Suite B compliance. I'd like to start > the discussion by proposing additional goals: > - merge in or reference RFC 4492 Well, I don't mind having an Informative reference to RFC 4492, but merging it in really isn't appropriate, since it's at Informational status and TLS 1.2 is of course Standards Track. > - add sha384 to the enumerated HashType This was already decided on at IETF. > - define cipher suites whose MAC algorithm is Suite B > compliant. Since Suite B doesn't include any MAC > algorithms and the recent collision attack on SHA-1 > doesn't extend to HMAC-SHA-1, this goal may be > controversial. I'm not that familiar with Suite B, but if it, as you say, it doesn't include a MAC algorithm, I'm not sure what you're suggesting for message integrity. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 26 09:38:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5jaI-0002CA-As; Wed, 26 Jul 2006 09:37:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5jaG-0002C1-V9 for tls@ietf.org; Wed, 26 Jul 2006 09:37:56 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5jaF-0004kd-I9 for tls@ietf.org; Wed, 26 Jul 2006 09:37:56 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id PAA26759; Wed, 26 Jul 2006 15:37:34 +0200 (MESZ) From: Martin Rex Message-Id: <200607261337.PAA14335@uw1048.wdf.sap.corp> Subject: Re: [TLS] Suite B compliance of TLS 1.2 To: ekr@networkresonance.com Date: Wed, 26 Jul 2006 15:37:28 +0200 (MET DST) In-Reply-To: <86fygpyoir.fsf@raman.networkresonance.com> from "Eric Rescorla" at Jul 25, 6 09:32:28 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@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: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla wrote: > > Wan-Teh Chang writes: > > At the 2005 RSA Conference, the US National > > Security Agency (NSA) announced Suite B Crytography > > (http://www.nsa.gov/ia/industry/crypto_suite_b.cfm). > > This suite of cryptographic algorithms includes AES, > > ECDSA, ECDH, ECMQV, and SHA-256/SHA-384. > > > > I'm interested in the Suite B compliance of TLS 1.2. > > Simply put, it means the ability to do TLS 1.2 using > > only Suite B algorithms. > > > > The primary goal of TLS 1.2, to remove the protocol's > > dependency on the MD5 and SHA-1 digest algorithms, is > > in line with Suite B compliance. I'd like to start > > the discussion by proposing additional goals: > > - merge in or reference RFC 4492 AFAIK, the dependency on the combination of SHA-1 and MD5 is hardwired into the protection of the SSL handshake, and independent of the ciphersuite that is negotiated. So in order to remove the dependency, one does not only need new TLS ciphersuite, but also a significant change in the handshake protocol (hashing of the handshake messages and the creation/verification of the finished message). Hashing the handshakes messages with both, old and new hash algorithms and deciding later in the handshake which results go into creation/verification of the finished message when it has been determined/negotiated which algorithms to use should be doable, and just moderately more expensive. I'm slightly worried about the potential "market pressure" which this might cause. I certainly don't mind adoption/offering of strong cryptographic protocols/technologies, but right now I do NOT consider TLS fundamentally broken or weak, and I would prefer if people focus on the acutal weaknesses within the technology, rather than replacing the (currently) strongest link in a weak chain with a much stronger one. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 26 10:43:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5kau-0001Gl-Sk; Wed, 26 Jul 2006 10:42:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5kau-0001Gg-5G for tls@ietf.org; Wed, 26 Jul 2006 10:42:40 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5kar-00072w-P4 for tls@ietf.org; Wed, 26 Jul 2006 10:42:40 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id DFB1E1E8C1F; Wed, 26 Jul 2006 07:42:36 -0700 (PDT) To: martin.rex@sap.com Subject: Re: [TLS] Suite B compliance of TLS 1.2 References: <200607261337.PAA14335@uw1048.wdf.sap.corp> From: Eric Rescorla Date: Wed, 26 Jul 2006 07:42:36 -0700 In-Reply-To: <200607261337.PAA14335@uw1048.wdf.sap.corp> (Martin Rex's message of "Wed, 26 Jul 2006 15:37:28 +0200 (MET DST)") Message-ID: <868xmgzaub.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR 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: , Errors-To: tls-bounces@lists.ietf.org Martin Rex writes: > Eric Rescorla wrote: >> >> Wan-Teh Chang writes: >> > At the 2005 RSA Conference, the US National >> > Security Agency (NSA) announced Suite B Crytography >> > (http://www.nsa.gov/ia/industry/crypto_suite_b.cfm). >> > This suite of cryptographic algorithms includes AES, >> > ECDSA, ECDH, ECMQV, and SHA-256/SHA-384. >> > >> > I'm interested in the Suite B compliance of TLS 1.2. >> > Simply put, it means the ability to do TLS 1.2 using >> > only Suite B algorithms. >> > >> > The primary goal of TLS 1.2, to remove the protocol's >> > dependency on the MD5 and SHA-1 digest algorithms, is >> > in line with Suite B compliance. I'd like to start >> > the discussion by proposing additional goals: >> > - merge in or reference RFC 4492 > > AFAIK, the dependency on the combination of SHA-1 and MD5 is > hardwired into the protection of the SSL handshake, > and independent of the ciphersuite that is negotiated. It is in 1.1, but not in 1.2. > So in order to remove the dependency, one does not only need > new TLS ciphersuite, but also a significant change in the > handshake protocol (hashing of the handshake messages > and the creation/verification of the finished message). Yep. Those changes are already being made > Hashing the handshakes messages with both, old and new hash > algorithms and deciding later in the handshake which results > go into creation/verification of the finished message when > it has been determined/negotiated which algorithms to use > should be doable, and just moderately more expensive. > > > I'm slightly worried about the potential "market pressure" > which this might cause. I certainly don't mind adoption/offering > of strong cryptographic protocols/technologies, but right > now I do NOT consider TLS fundamentally broken or weak, > and I would prefer if people focus on the acutal weaknesses > within the technology, rather than replacing the > (currently) strongest link in a weak chain with a much > stronger one. I'm sensitive to what you're saying and I have the same doubts. On the other hand, I also worry about the attacks on MD5 and SHA-1 getting much worse and then having to explain why we didn't do anything about it -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 26 10:54:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5km4-0007gF-Eo; Wed, 26 Jul 2006 10:54:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5km3-0007g9-Fu for tls@ietf.org; Wed, 26 Jul 2006 10:54:11 -0400 Received: from mga02.intel.com ([134.134.136.20] helo=orsmga101-1.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5km2-0008Dq-30 for tls@ietf.org; Wed, 26 Jul 2006 10:54:11 -0400 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga101-1.jf.intel.com with ESMTP; 26 Jul 2006 07:54:06 -0700 Received: from fmsmsx333.fm.intel.com (HELO fmsmsx333.amr.corp.intel.com) ([132.233.42.2]) by fmsmga001.fm.intel.com with ESMTP; 26 Jul 2006 07:54:06 -0700 X-IronPort-AV: i="4.07,185,1151910000"; d="scan'208"; a="104924582:sNHT22202005" Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 07:54:05 -0700 Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 07:53:55 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Suite B compliance of TLS 1.2 Date: Wed, 26 Jul 2006 10:53:53 -0400 Message-ID: <279DDDAFA85EC74C9300A0598E7040565DBF61@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Suite B compliance of TLS 1.2 Thread-Index: AcawwdP5zwPHpVCMQ7ay8fQmlaIJpAAAPJvw From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 26 Jul 2006 14:53:55.0049 (UTC) FILETIME=[50FCBD90:01C6B0C3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org >> So in order to remove the dependency, one does not only need >> new TLS ciphersuite, but also a significant change in the >> handshake protocol (hashing of the handshake messages >> and the creation/verification of the finished message). > >Yep. Those changes are already being made :-) >> Hashing the handshakes messages with both, old and new hash >> algorithms and deciding later in the handshake which results >> go into creation/verification of the finished message when >> it has been determined/negotiated which algorithms to use >> should be doable, and just moderately more expensive. I think the preferred direction is to hash with the new negotiated hash. What would be the purpose of hashing with the old one? >> I'm slightly worried about the potential "market pressure" >> which this might cause. I certainly don't mind adoption/offering >> of strong cryptographic protocols/technologies, but right >> now I do NOT consider TLS fundamentally broken or weak, >> and I would prefer if people focus on the acutal weaknesses >> within the technology, rather than replacing the >> (currently) strongest link in a weak chain with a much >> stronger one. > >I'm sensitive to what you're saying and I have the same doubts. >On the other hand, I also worry about the attacks on MD5 and SHA-1 >getting much worse and then having to explain why we didn't >do anything about it Exactly.=20 But I'm confused wrt. what Martin calls "strongest link". Clearly it's not RSA or SHA-1 (and hopefully not MD5 :-)? _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 26 12:35:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5mLt-0006fg-QD; Wed, 26 Jul 2006 12:35:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5mLs-0006fW-MD for tls@ietf.org; Wed, 26 Jul 2006 12:35:16 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5mLr-0000Cc-97 for tls@ietf.org; Wed, 26 Jul 2006 12:35:16 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id SAA14696; Wed, 26 Jul 2006 18:35:08 +0200 (MESZ) From: Martin Rex Message-Id: <200607261635.SAA18707@uw1048.wdf.sap.corp> Subject: Re: [TLS] Suite B compliance of TLS 1.2 To: uri.blumenthal@intel.com (Blumenthal, Uri) Date: Wed, 26 Jul 2006 18:35:08 +0200 (MET DST) In-Reply-To: <279DDDAFA85EC74C9300A0598E7040565DBF61@hdsmsx412.amr.corp.intel.com> from "Blumenthal, Uri" at Jul 26, 6 10:53:53 am MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@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: , Errors-To: tls-bounces@lists.ietf.org Blumenthal, Uri wrote: > > >> Hashing the handshakes messages with both, old and new hash > >> algorithms and deciding later in the handshake which results > >> go into creation/verification of the finished message when > >> it has been determined/negotiated which algorithms to use > >> should be doable, and just moderately more expensive. > > I think the preferred direction is to hash with the new negotiated hash. > What would be the purpose of hashing with the old one? Aren't the client hello and server hello included in the hash? So the client doesn't know which one has been negotiated until after interpreting the ServerHello message (unless the client is determined from the beginning to not interoperate with older servers). > > >> I'm slightly worried about the potential "market pressure" > >> which this might cause. I certainly don't mind adoption/offering > >> of strong cryptographic protocols/technologies, but right > >> now I do NOT consider TLS fundamentally broken or weak, > >> and I would prefer if people focus on the acutal weaknesses > >> within the technology, rather than replacing the > >> (currently) strongest link in a weak chain with a much > >> stronger one. > > > >I'm sensitive to what you're saying and I have the same doubts. > >On the other hand, I also worry about the attacks on MD5 and SHA-1 > >getting much worse and then having to explain why we didn't > >do anything about it > > Exactly. > > But I'm confused wrt. what Martin calls "strongest link". Clearly it's > not RSA or SHA-1 (and hopefully not MD5 :-)? Except for the weakness in the random number generator of the Netscape Navigator browser over 10 years back I haven't heard about attacks against SSL sessions (ignoring the export ciphersuites here). However there have been and still are attacks against users that were under the impression that their browser would protect them through the use of SSL. Most weaknesses were implementation flaws (XSS, use of frames giving false impressions, incorrect certificate path validation), but there were also design issues involved (the magic how an awfully large number of questionable trust anchors are created/initialized, CAs inappropriately issuing certificates, IDNs and how they interact with HTTPS endpoint identification) I do agree that MD5 should no longer be used for integrity protection because of the known weaknesses. But when used together with SHA-1 in the SSL/TLS handshake fashion, it is NOT utterly useless. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 26 13:09:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5msa-0002UA-JW; Wed, 26 Jul 2006 13:09:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5msZ-0002Ts-Ja for tls@ietf.org; Wed, 26 Jul 2006 13:09:03 -0400 Received: from mga02.intel.com ([134.134.136.20] helo=orsmga101-1.jf.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5msW-0003D8-Qi for tls@ietf.org; Wed, 26 Jul 2006 13:09:03 -0400 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga101-1.jf.intel.com with ESMTP; 26 Jul 2006 10:08:35 -0700 Received: from fmsmsx332.fm.intel.com (HELO fmsmsx332.amr.corp.intel.com) ([132.233.42.148]) by fmsmga001.fm.intel.com with ESMTP; 26 Jul 2006 10:08:19 -0700 X-IronPort-AV: i="4.07,185,1151910000"; d="scan'208"; a="105048941:sNHT2503702866" Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx332.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 10:08:18 -0700 Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 10:08:18 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Suite B compliance of TLS 1.2 Date: Wed, 26 Jul 2006 13:08:14 -0400 Message-ID: <279DDDAFA85EC74C9300A0598E7040565DC103@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Suite B compliance of TLS 1.2 Thread-Index: Acaw0cKLGih/+QRlQ/K95A/txnyXTwAAyiCQ From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 26 Jul 2006 17:08:18.0451 (UTC) FILETIME=[17263E30:01C6B0D6] X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org >> I think the preferred direction is to hash with the new negotiated hash. >> What would be the purpose of hashing with the old one? > >Aren't the client hello and server hello included in the hash? >So the client doesn't know which one has been negotiated until >after interpreting the ServerHello message (unless the client >is determined from the beginning to not interoperate with older servers). So? The authentication decision (with all the computations) is made in the end of the exchange anyway. It might be more convenient to be able to hash messages as they come and forget them - but it may have to wait until it is clear what hash to use. Isn't security worth a bit of inconvenience? :-) >> But I'm confused wrt. what Martin calls "strongest link". Clearly it's >> not RSA or SHA-1 (and hopefully not MD5 :-)? > >Except for the weakness in the random number generator of the >Netscape Navigator browser over 10 years back I haven't heard about >attacks against SSL sessions (ignoring the export ciphersuites here). >Most weaknesses were implementation flaws (XSS, use of frames >giving false impressions, incorrect certificate path validation), >but there were also design issues involved (the magic how an >awfully large number of questionable trust anchors are >created/initialized, CAs inappropriately issuing certificates, >IDNs and how they interact with HTTPS endpoint identification)=20 I.e. you're arguing that cryptography is the strongest link in the Navigator and similar products, and therefore efforts should be made in addressing the weaknesses, not improving what's already "strong"? Then I sympathize, but... To this my answer would be: we as TLS WG have no power over implementation bugs. However we have the power to make sure that the specified cryptography is not only "Navigator's strongest link" but is strong according to the today's cryptologic science and technology. >I do agree that MD5 should no longer be used for integrity >protection because of the known weaknesses. But when used >together with SHA-1 in the SSL/TLS handshake fashion, it is >NOT utterly useless. It is useless enough to be done with it and not spend any more cycles of the participants on discussing it.=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 26 14:14:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ntg-0004Ap-4b; Wed, 26 Jul 2006 14:14:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5nte-0004AU-UK for tls@ietf.org; Wed, 26 Jul 2006 14:14:14 -0400 Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5ntb-0000ah-Kz for tls@ietf.org; Wed, 26 Jul 2006 14:14:14 -0400 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k6QIEBrX010648 for ; Wed, 26 Jul 2006 14:14:11 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k6QIE5BZ017395 for ; Wed, 26 Jul 2006 14:14:06 -0400 Received: from [127.0.0.1] (dhcp-172-16-25-208.sfbay.redhat.com [172.16.25.208]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id k6QIE1cm010730 for ; Wed, 26 Jul 2006 14:14:03 -0400 Message-ID: <44C7B157.70505@redhat.com> Date: Wed, 26 Jul 2006 11:15:51 -0700 From: Wan-Teh Chang User-Agent: Thunderbird 2.0a1 (Windows/20060725) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Suite B compliance of TLS 1.2 References: <44C6B8C1.3040500@redhat.com> <86fygpyoir.fsf@raman.networkresonance.com> In-Reply-To: <86fygpyoir.fsf@raman.networkresonance.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Eric Rescorla wrote: > > I'm not that familiar with Suite B, but if it, as you > say, it doesn't include a MAC algorithm, I'm not sure > what you're suggesting for message integrity. I'm not a cryptographer, so I am struggling with these questions. Option 1: investigate whether HMAC-SHA-1 is still secure and consider HMAC-SHA-256 and HMAC-SHA-384. In NIST Special Publication (SP) 800-57 Part 1 (http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdf), Table 3 (in Section 5.6.1 on page 64) lists the security strengths of HMAC with various hash functions. It shows that HMAC-SHA-1 may only be used for <= 128 bits of security, and HMAC-SHA-256 may be used for <= 256 bits of security. This would imply that the AES_128 TLS cipher suites may continue to use HMAC-SHA-1 but the AES_256 TLS cipher suites should use HMAC-SHA-256. In his talk "NIST Cryptographic Standards Status Report" at this year's PKI R&D Workshop, Bill Burr of NIST provided some information that helps interpret Table 3 in SP 800-57 Part 1. (http://middleware.internet2.edu/pki06/proceedings/burr-nist_crypto_standards.ppt) Slide 20 says: Federal users [...] may continue to use SHA-1 after 2010 for: - HMAC - Key derivation - Random number generation Slide 30 explains why Suite B uses AES 256 (rather than AES 192) for applications that require 192 bits of security. So in Table 3 we only need to look at the rows for 128 and 192 bits of security for Suite B compliance. Option 2: consider Galois/Counter Mode (GCM) of AES. (http://csrc.nist.gov/publications/drafts.html#sp800-38D) This mode of operation provides message integrity and doesn't use any (general purpose) cryptographic hash function. So GCM seems to avoid the hash function issue altogether, although GCM still uses a keyed hash function called GHASH. TLS could use GCM for both encryption and message integrity (note: the ordering of encryption and MAC'ing is different between GCM and current versions of TLS) or just for message integrity (called GMAC). The TLS working group's web page says: The TLS WG will also work on new authenticated encryption modes for TLS, including modes based on counter mode encryption (CTR) and combined encryption/authentication modes, and may define major new cipher suites for TLS for this purpose. Is GCM the new authenticated encryption mode? Wan-Teh _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 26 14:31:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5oAO-0004f8-H2; Wed, 26 Jul 2006 14:31:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5oAM-0004f3-W3 for tls@ietf.org; Wed, 26 Jul 2006 14:31:30 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5oAL-0001rj-Mv for tls@ietf.org; Wed, 26 Jul 2006 14:31:30 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id C8E451E8C1C; Wed, 26 Jul 2006 11:31:28 -0700 (PDT) To: Wan-Teh Chang Subject: Re: [TLS] Suite B compliance of TLS 1.2 References: <44C6B8C1.3040500@redhat.com> <86fygpyoir.fsf@raman.networkresonance.com> <44C7B157.70505@redhat.com> From: Eric Rescorla Date: Wed, 26 Jul 2006 11:31:28 -0700 In-Reply-To: <44C7B157.70505@redhat.com> (Wan-Teh Chang's message of "Wed, 26 Jul 2006 11:15:51 -0700") Message-ID: <8664hkw73z.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR 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: , Errors-To: tls-bounces@lists.ietf.org Wan-Teh Chang writes: > > The TLS working group's web page says: > > The TLS WG will also work on new authenticated > encryption modes for TLS, including modes based on counter mode > encryption (CTR) and combined encryption/authentication modes, > and may define major new cipher suites for TLS for this purpose. > > Is GCM the new authenticated encryption mode? We don't have one in process yet, but it's an obvious candidate. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 26 14:47:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5oPR-0004lf-O8; Wed, 26 Jul 2006 14:47:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5oPR-0004lV-6Y for tls@ietf.org; Wed, 26 Jul 2006 14:47:05 -0400 Received: from nat194.certicom.com ([66.48.18.194] helo=mail.ca.certicom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5oPO-0003Ex-UT for tls@ietf.org; Wed, 26 Jul 2006 14:47:05 -0400 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 9EE61100233D5 for ; Wed, 26 Jul 2006 14:46:59 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11981-12 for ; Wed, 26 Jul 2006 14:46:54 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 27E9A100233C9 for ; Wed, 26 Jul 2006 14:46:54 -0400 (EDT) Received: from ce00182.certicom.com ([10.0.2.59]) by certicom1.certicom.com (Lotus Domino Release 6.5.4) with ESMTP id 2006072614460782-2997 ; Wed, 26 Jul 2006 14:46:07 -0400 Received: from ce00182.certicom.com (localhost.certicom.com [127.0.0.1]) by ce00182.certicom.com (8.13.3/8.13.3) with ESMTP id k6QIkqpV015724 for ; Wed, 26 Jul 2006 14:46:52 -0400 (EDT) (envelope-from bminard@ce00182.certicom.com) Received: (from bminard@localhost) by ce00182.certicom.com (8.13.3/8.13.3/Submit) id k6QIkmQ1015723 for tls@ietf.org; Wed, 26 Jul 2006 14:46:48 -0400 (EDT) (envelope-from bminard) Date: Wed, 26 Jul 2006 14:46:48 -0400 From: Brian Minard To: tls@ietf.org Subject: Re: [TLS] Suite B compliance of TLS 1.2 Message-ID: <20060726184648.GE14789@certicom.com> References: <44C6B8C1.3040500@redhat.com> <86fygpyoir.fsf@raman.networkresonance.com> MIME-Version: 1.0 In-Reply-To: <86fygpyoir.fsf@raman.networkresonance.com> User-Agent: mutt-ng/devel-r804 (FreeBSD) X-MIMETrack: Itemize by SMTP Server on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 07/26/2006 02:46:07 PM, Serialize by Router on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 07/26/2006 02:46:09 PM, Serialize complete at 07/26/2006 02:46:09 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Tue, Jul 25, 2006 at 09:32:28PM -0700, Eric Rescorla wrote: > Wan-Teh Chang writes: > > > - define cipher suites whose MAC algorithm is Suite B > > compliant. Since Suite B doesn't include any MAC algorithms > > and the recent collision attack on SHA-1 doesn't extend to > > HMAC-SHA-1, this goal may be controversial. > > I'm not that familiar with Suite B, but if it, as you say, > it doesn't include a MAC algorithm, I'm not sure what you're > suggesting for message integrity. I don't entirely understand these statements. Is there a reason why new cipher suites supporting SHA-256, -384, or -512, couldn't be defined using the existing HMAC? Why doesn't this solve the message integrity issue? _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 26 15:18:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5otp-0005t6-Eq; Wed, 26 Jul 2006 15:18:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5oto-0005t1-4t for tls@ietf.org; Wed, 26 Jul 2006 15:18:28 -0400 Received: from nat194.certicom.com ([66.48.18.194] helo=mail.ca.certicom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5otm-0006mL-Sh for tls@ietf.org; Wed, 26 Jul 2006 15:18:28 -0400 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 9C200100233D5 for ; Wed, 26 Jul 2006 15:18:23 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11981-23 for ; Wed, 26 Jul 2006 15:18:21 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id F1EF3100233C9 for ; Wed, 26 Jul 2006 15:18:20 -0400 (EDT) Received: from ce00182.certicom.com ([10.0.2.59]) by certicom1.certicom.com (Lotus Domino Release 6.5.4) with ESMTP id 2006072615173513-3077 ; Wed, 26 Jul 2006 15:17:35 -0400 Received: from ce00182.certicom.com (localhost.certicom.com [127.0.0.1]) by ce00182.certicom.com (8.13.3/8.13.3) with ESMTP id k6QJIJ5Q015911 for ; Wed, 26 Jul 2006 15:18:19 -0400 (EDT) (envelope-from bminard@ce00182.certicom.com) Received: (from bminard@localhost) by ce00182.certicom.com (8.13.3/8.13.3/Submit) id k6QJIJ2A015910 for tls@ietf.org; Wed, 26 Jul 2006 15:18:19 -0400 (EDT) (envelope-from bminard) Date: Wed, 26 Jul 2006 15:18:19 -0400 From: Brian Minard To: tls@ietf.org Subject: Re: [TLS] Suite B compliance of TLS 1.2 Message-ID: <20060726191819.GF14789@certicom.com> References: <44C6B8C1.3040500@redhat.com> <86fygpyoir.fsf@raman.networkresonance.com> <20060726184648.GE14789@certicom.com> <861ws8w697.fsf@raman.networkresonance.com> MIME-Version: 1.0 In-Reply-To: <861ws8w697.fsf@raman.networkresonance.com> User-Agent: mutt-ng/devel-r804 (FreeBSD) X-MIMETrack: Itemize by SMTP Server on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 07/26/2006 03:17:35 PM, Serialize by Router on Certicom1/Certicom(Release 6.5.4|March 27, 2005) at 07/26/2006 03:17:36 PM, Serialize complete at 07/26/2006 03:17:36 PM Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org On Wed, Jul 26, 2006 at 11:49:56AM -0700, Eric Rescorla wrote: > Brian Minard writes: > > > I don't entirely understand these statements. Is there a > > reason why new cipher suites supporting SHA-256, -384, or > > -512, couldn't be defined using the existing HMAC? > > > > Why doesn't this solve the message integrity issue? > > I was wondering the same thing... I.e., why Wan-Teh called the > issue "controversial". Anyway, I was expecting that there would > eventually be HMAC-XXX cipher suites. Ok. It was my understanding that new cipher suites supporting HMAC-XXX was within the scope of your proposal in Montreal: How to negotiate a new PRF--http://www3.ietf.org/proceedings/06jul/slides/tls-1.pdf, page 7. Was this proposal was accepted? _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 26 16:14:17 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5plm-0000zU-BN; Wed, 26 Jul 2006 16:14:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5plk-0000zO-Dm for tls@ietf.org; Wed, 26 Jul 2006 16:14:12 -0400 Received: from smtp-out4.blueyonder.co.uk ([195.188.213.7]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5plj-00051z-2g for tls@ietf.org; Wed, 26 Jul 2006 16:14:12 -0400 Received: from [172.23.170.141] (helo=anti-virus02-08) by smtp-out4.blueyonder.co.uk with smtp (Exim 4.52) id 1G5ple-0006RQ-Ox for tls@ietf.org; Wed, 26 Jul 2006 21:14:09 +0100 Received: from 82-42-16-20.cable.ubr01.knor.blueyonder.co.uk ([82.42.16.20] helo=[127.0.0.1]) by asmtp-out3.blueyonder.co.uk with esmtp (Exim 4.52) id 1G5plc-0000sT-6K for tls@ietf.org; Wed, 26 Jul 2006 21:14:04 +0100 Message-ID: <44C7BB74.5060902@blueyonder.co.uk> Date: Wed, 26 Jul 2006 19:59:00 +0100 From: David Hopwood User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Suite B compliance of TLS 1.2 References: <44C6B8C1.3040500@redhat.com> <86fygpyoir.fsf@raman.networkresonance.com> <44C7B157.70505@redhat.com> In-Reply-To: <44C7B157.70505@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: david.nospam.hopwood@blueyonder.co.uk 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: , Errors-To: tls-bounces@lists.ietf.org Wan-Teh Chang wrote: > Eric Rescorla wrote: > >> I'm not that familiar with Suite B, but if it, as you >> say, it doesn't include a MAC algorithm, I'm not sure >> what you're suggesting for message integrity. > > I'm not a cryptographer, so I am struggling with these > questions. > > Option 1: investigate whether HMAC-SHA-1 is still secure > and consider HMAC-SHA-256 and HMAC-SHA-384. > > In NIST Special Publication (SP) 800-57 Part 1 > (http://csrc.nist.gov/publications/nistpubs/800-57/SP800-57-Part1.pdf), > Table 3 (in Section 5.6.1 on page 64) lists the security > strengths of HMAC with various hash functions. It shows > that HMAC-SHA-1 may only be used for <= 128 bits of security, > and HMAC-SHA-256 may be used for <= 256 bits of security. As pointed out in the Security Considerations for the truncated_hmac option in RFC 4366: Note that the output length of a MAC need not be as long as the length of a symmetric cipher key, since forging of MAC values cannot be done off-line: in TLS, a single failed MAC guess will cause the immediate termination of the TLS session. As a result, HMAC is not a weak point in TLS for any ciphersuite. -- David Hopwood _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 26 16:22:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ptP-0003lQ-6U; Wed, 26 Jul 2006 16:22:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5ptN-0003k4-TZ for tls@ietf.org; Wed, 26 Jul 2006 16:22:05 -0400 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5ptM-0005ga-GJ for tls@ietf.org; Wed, 26 Jul 2006 16:22:05 -0400 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id WAA25080; Wed, 26 Jul 2006 22:20:05 +0200 (MESZ) From: Martin Rex Message-Id: <200607262020.WAA25245@uw1048.wdf.sap.corp> Subject: Re: [TLS] Suite B compliance of TLS 1.2 To: uri.blumenthal@intel.com (Blumenthal Uri) Date: Wed, 26 Jul 2006 22:20:05 +0200 (MET DST) In-Reply-To: <279DDDAFA85EC74C9300A0598E7040565DC103@hdsmsx412.amr.corp.intel.com> from "Blumenthal, Uri" at Jul 26, 6 01:08:14 pm MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-SAP: out X-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: martin.rex@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: , Errors-To: tls-bounces@lists.ietf.org Blumenthal, Uri wrote: > > I.e. you're arguing that cryptography is the strongest link in the > Navigator and similar products, and therefore efforts should be made in > addressing the weaknesses, not improving what's already "strong"? Then I > sympathize, but... > > To this my answer would be: we as TLS WG have no power over > implementation bugs. However we have the power to make sure that the > specified cryptography is not only "Navigator's strongest link" but is > strong according to the today's cryptologic science and technology. I was thinking in a more general fashion, and I'm getting off-topic. This is more geared towards "where do we as the IETF" should we put our efforts. Within the IETF we have been having a problem of insufficient "cross-pollination" between the security area and the other areas, because we security geeks are constantly busy improving our own stuff and making it ever more complex. We do not spent sufficient time to help the non-security guys to use the existing standards and protocols, even those that are already pretty good. Within Software development (in particular when one is not a niche-only provider of just a particular middleware component), there are limits to the available resources, what one can buy (if it is OEM) or what one can do (if you're implementing it yourself). I want to slightly caution about feature creep. There was a discussion at the IETF plenary about why so few documents/protocol advance on the standards track, and feature creep is the predominant reason. For the integrity protection, TLS is about protecting online communication and therefore must provide integrity protection against real-time attacks. The encryption algorithms, on the other hand, should be strong enough to provide confidentiality for many years. Digital signatures on archived documents is the area that has to focus on updating their hash algorithms. The "smaller" an iteration of the base spec is, the more likely it will be implemented/adopted widely, and the more likely there will be interoperability on newer features, because of the lower cost to implement/adopt it. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 26 16:44:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5qF5-00038r-Pd; Wed, 26 Jul 2006 16:44:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5qF4-00038G-IA for tls@ietf.org; Wed, 26 Jul 2006 16:44:30 -0400 Received: from mga01.intel.com ([192.55.52.88] helo=fmsmga101-1.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5qF3-00022C-3C for tls@ietf.org; Wed, 26 Jul 2006 16:44:30 -0400 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101-1.fm.intel.com with ESMTP; 26 Jul 2006 13:37:13 -0700 Received: from fmsmsx333.fm.intel.com (HELO fmsmsx333.amr.corp.intel.com) ([132.233.42.2]) by fmsmga001.fm.intel.com with ESMTP; 26 Jul 2006 13:37:00 -0700 X-IronPort-AV: i="4.07,185,1151910000"; d="scan'208"; a="105235211:sNHT4764088042" Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 13:36:59 -0700 Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 13:36:41 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Suite B compliance of TLS 1.2 Date: Wed, 26 Jul 2006 16:36:37 -0400 Message-ID: <279DDDAFA85EC74C9300A0598E7040565DC343@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Suite B compliance of TLS 1.2 Thread-Index: Acaw8XnYJ30mjGzfR36ySRk6fBtNdwAAQ9+g From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 26 Jul 2006 20:36:41.0164 (UTC) FILETIME=[3358D8C0:01C6B0F3] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org I think that (a) specifying a reliable hash-function, and (b) defining self-consistent ciphersuites is a requirement that we must satisfy - and NOT a "feature-creep". The smallest iteration on base spec is to keep SSLv3. And it is already deployed. -----Original Message----- From: Martin Rex [mailto:martin.rex@sap.com]=20 Sent: Wednesday, July 26, 2006 4:20 PM To: Blumenthal, Uri Cc: martin.rex@sap.com; tls@ietf.org Subject: Re: [TLS] Suite B compliance of TLS 1.2 Blumenthal, Uri wrote: >=20 > I.e. you're arguing that cryptography is the strongest link in the > Navigator and similar products, and therefore efforts should be made in > addressing the weaknesses, not improving what's already "strong"? Then I > sympathize, but... >=20 > To this my answer would be: we as TLS WG have no power over > implementation bugs. However we have the power to make sure that the > specified cryptography is not only "Navigator's strongest link" but is > strong according to the today's cryptologic science and technology. I was thinking in a more general fashion, and I'm getting off-topic. This is more geared towards "where do we as the IETF" should we put our efforts. Within the IETF we have been having a problem of insufficient "cross-pollination" between the security area and the other areas, because we security geeks are constantly busy improving our own stuff and making it ever more complex. We do not spent sufficient time to help the non-security guys to use the existing standards and protocols, even those that are already pretty good. Within Software development (in particular when one is not a niche-only provider of just a particular middleware component), there are limits to the available resources, what one can buy (if it is OEM) or what one can do (if you're implementing it yourself). I want to slightly caution about feature creep. There was a discussion at the IETF plenary about why so few documents/protocol advance on the standards track, and feature creep is the predominant reason. For the integrity protection, TLS is about protecting online communication and therefore must provide integrity protection against real-time attacks. The encryption algorithms, on the other hand, should be strong enough to provide confidentiality for many years. Digital signatures on archived documents is the area that has to focus on updating their hash algorithms. The "smaller" an iteration of the base spec is, the more likely it will be implemented/adopted widely, and the more likely there will be interoperability on newer features, because of the lower cost to implement/adopt it. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 26 19:45:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5t4Q-00069G-4a; Wed, 26 Jul 2006 19:45:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5t4O-00069B-Ki for tls@ietf.org; Wed, 26 Jul 2006 19:45:40 -0400 Received: from mga01.intel.com ([192.55.52.88] helo=fmsmga101-1.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5t4N-00073O-4f for tls@ietf.org; Wed, 26 Jul 2006 19:45:40 -0400 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101-1.fm.intel.com with ESMTP; 26 Jul 2006 16:43:27 -0700 Received: from fmsmsx333.fm.intel.com (HELO fmsmsx333.amr.corp.intel.com) ([132.233.42.2]) by fmsmga001.fm.intel.com with ESMTP; 26 Jul 2006 16:43:26 -0700 X-IronPort-AV: i="4.07,185,1151910000"; d="scan'208"; a="105398125:sNHT20020042" Received: from fmsmsx312.amr.corp.intel.com ([132.233.42.227]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 16:43:26 -0700 Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx312.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 26 Jul 2006 16:43:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Suite B compliance of TLS 1.2 Date: Wed, 26 Jul 2006 19:43:02 -0400 Message-ID: <279DDDAFA85EC74C9300A0598E7040565DC3F6@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Suite B compliance of TLS 1.2 Thread-Index: AcaxBlaseKnswC6JTpWmPh5Zh0bTZgAAE0dg From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 26 Jul 2006 23:43:05.0432 (UTC) FILETIME=[3DB0B580:01C6B10D] X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org Both from my personal opinion as a cryptographer and from a political point of view - one may argue about whether all the OTHER ciphersuites are worth the effort that you so succintly described. Suite B is beyond contest. Protocols WILL migrate to it, like it or not. One might add that Suite B beats other defined ciphersuites and is comparable in strength to the current Russian crypto standard - and I have deep respect for the later. I think enough has been said on this subject. Except that yes there are real benefits - but you need to look deeply at the algorithms to understand it. -----Original Message----- From: Martin Rex [mailto:martin.rex@sap.com]=20 Sent: Wednesday, July 26, 2006 6:38 PM To: Blumenthal, Uri Subject: Re: [TLS] Suite B compliance of TLS 1.2 Blumenthal, Uri wrote: >=20 > >To me "Suite B compliance of TLS 1.2" sounds like adding several new > >algorithms to the base spec with at least "RECOMMENDED" status, > >and not like "we already have all hooks for proprietary extensions, > >go and write an informational draft if you care". >=20 > In the future it may well be that Suite B ends up being the only > mandatory-to-implement ciphersuite. >=20 > Regardless, I don't understand your comment. New crypto algorithms cause a lot of resources to be burnt, so one should not do it just for the fun of it. Things that come to mind: - export approvals that some governments require - import approvals that some governments require - usage approvals that customers in some countries require - module re-evaluation/re-certification in some cases - implementation&test, interoperability tests - legal dep. will require another risk assessment because of IP issues etc. So if there is no real benefit we should be wary to put it into the base standard because of all the resources that implementors and vendors (incl. OEM vendors) will have to spend on it. The resources that gets spent here will be missing in other areas, where improving the security might be magnitudes more important -- or it will not be adopted by a significant number of installations. As a standars body, all IETF working groups should have an interest in broad adoption of their standards and smooth interoperability. Complexity and feature-creep (to cater niches) are part of the problem trying to reach that goal, not part of the solution. Regards, -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 26 20:13:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5tVE-0008Ae-TF; Wed, 26 Jul 2006 20:13:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5tVE-0008AV-Bb for tls@ietf.org; Wed, 26 Jul 2006 20:13:24 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G5ocx-0004fQ-Cc for tls@ietf.org; Wed, 26 Jul 2006 15:01:03 -0400 Received: from raman.networkresonance.com ([198.144.196.3]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1G5oSL-0007Jc-J0 for tls@ietf.org; Wed, 26 Jul 2006 14:50:07 -0400 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 678FC1E8C1C; Wed, 26 Jul 2006 11:49:56 -0700 (PDT) To: Brian Minard Subject: Re: [TLS] Suite B compliance of TLS 1.2 References: <44C6B8C1.3040500@redhat.com> <86fygpyoir.fsf@raman.networkresonance.com> <20060726184648.GE14789@certicom.com> From: Eric Rescorla Date: Wed, 26 Jul 2006 11:49:56 -0700 In-Reply-To: <20060726184648.GE14789@certicom.com> (Brian Minard's message of "Wed, 26 Jul 2006 14:46:48 -0400") Message-ID: <861ws8w697.fsf@raman.networkresonance.com> User-Agent: Gnus/5.1007 (Gnus v5.10.7) XEmacs/21.4.19 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: -2.4 (--) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: EKR 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: , Errors-To: tls-bounces@lists.ietf.org Brian Minard writes: > On Tue, Jul 25, 2006 at 09:32:28PM -0700, Eric Rescorla wrote: > >> Wan-Teh Chang writes: >> >> > - define cipher suites whose MAC algorithm is Suite B >> > compliant. Since Suite B doesn't include any MAC algorithms >> > and the recent collision attack on SHA-1 doesn't extend to >> > HMAC-SHA-1, this goal may be controversial. >> >> I'm not that familiar with Suite B, but if it, as you say, >> it doesn't include a MAC algorithm, I'm not sure what you're >> suggesting for message integrity. > > I don't entirely understand these statements. Is there a reason > why new cipher suites supporting SHA-256, -384, or -512, couldn't > be defined using the existing HMAC? > > Why doesn't this solve the message integrity issue? I was wondering the same thing... I.e., why Wan-Teh called the issue "controversial". Anyway, I was expecting that there would eventually be HMAC-XXX cipher suites. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Jul 26 22:52:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5vyh-00036i-DE; Wed, 26 Jul 2006 22:51:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G5vyg-00036d-9L for tls@ietf.org; Wed, 26 Jul 2006 22:51:58 -0400 Received: from smtpout07-01.prod.mesa1.secureserver.net ([64.202.165.230] helo=smtpout07-04.prod.mesa1.secureserver.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G5vye-0001o5-Sl for tls@ietf.org; Wed, 26 Jul 2006 22:51:58 -0400 Received: (qmail 16295 invoked from network); 27 Jul 2006 02:51:55 -0000 Received: from unknown (69.174.163.252) by smtpout07-04.prod.mesa1.secureserver.net (64.202.165.233) with ESMTP; 27 Jul 2006 02:51:55 -0000 From: "Ron Teitelbaum" To: Date: Wed, 26 Jul 2006 22:51:54 -0400 Organization: US Medical Records Specialists Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 In-Reply-To: thread-index: AcatJo4JdIhpeynsR3qMgC6GkgG23gD/uixQ X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Subject: [TLS] Looking for Test cases or Documents with Byte Samples X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ron@USMedRec.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: , Errors-To: tls-bounces@lists.ietf.org All, I have Yngve Pettersen document but I've been looking for other test cases. Are test cases being collected anywhere, or are there other documents with sample bytes that someone can point me too? Specifically right now I'm looking to test my parsing of the hello extensions. There were some good examples in Yngve's document of server name and status request OCSP PKIX extensions that were very useful for testing. Thank you for your help and any suggestions. Ron Teitelbaum President / Principal Software Engineer US Medical Record Specialists Ron@USMedRec.com > -----Original Message----- > From: Yngve N. Pettersen > Sent: Friday, July 21, 2006 8:34 PM > > > You might also want to check this Internet-Draft that I recently > published: > > http://www.ietf.org/internet-drafts/draft-pettersen-tls-interop- > experience-00.txt > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jul 27 09:01:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G65UM-0004rs-Kp; Thu, 27 Jul 2006 09:01:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G65UL-0004rn-Dj for tls@ietf.org; Thu, 27 Jul 2006 09:01:17 -0400 Received: from mga01.intel.com ([192.55.52.88] helo=fmsmga101-1.fm.intel.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G65UK-0005Ft-1c for tls@ietf.org; Thu, 27 Jul 2006 09:01:17 -0400 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101-1.fm.intel.com with ESMTP; 27 Jul 2006 06:01:15 -0700 Received: from fmsmsx333.fm.intel.com (HELO fmsmsx333.amr.corp.intel.com) ([132.233.42.2]) by fmsmga001.fm.intel.com with ESMTP; 27 Jul 2006 06:01:15 -0700 X-IronPort-AV: i="4.07,187,1151910000"; d="scan'208"; a="105827545:sNHT14390558" Received: from fmsmsx311.amr.corp.intel.com ([132.233.42.214]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 06:01:09 -0700 Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx311.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 27 Jul 2006 06:01:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] Suite B compliance of TLS 1.2 Date: Thu, 27 Jul 2006 09:01:01 -0400 Message-ID: <279DDDAFA85EC74C9300A0598E704056618F7E@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Suite B compliance of TLS 1.2 Thread-Index: AcaxEYWaUuj/xcJwRA2ibfCyv74SIQAamsgg From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 27 Jul 2006 13:01:05.0934 (UTC) FILETIME=[B8B182E0:01C6B17C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org >> I don't entirely understand these statements. Is there a reason >> why new cipher suites supporting SHA-256, -384, or -512, couldn't >> be defined using the existing HMAC?=20 >> >> Why doesn't this solve the message integrity issue? > > I was wondering the same thing... I.e., why Wan-Teh called > the issue "controversial". Anyway, I was expecting that > there would eventually be HMAC-XXX cipher suites. A. There will be ciphersuite(s) with combined encryption-authentication AES mode. No issue here. B. For ciphersuites with no-encryption or AES in encryption-only mode, HMAC. Suite B specs fail to say what to do, even though the course is rather obvious. C. NSA should spell it out explicitly. So perhaps a comment or two to would do good. D. [I personally wonder why they stopped short of specifying MAC for data stream integrity protection. They specified everything else.] _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Jul 27 21:22:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6H3p-0002Da-JH; Thu, 27 Jul 2006 21:22:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6H3o-0002DN-Cw for tls@ietf.org; Thu, 27 Jul 2006 21:22:40 -0400 Received: from mx1.redhat.com ([66.187.233.31]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6H3n-00024l-6M for tls@ietf.org; Thu, 27 Jul 2006 21:22:40 -0400 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k6S1Md6g016045 for ; Thu, 27 Jul 2006 21:22:39 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.12.11.20060308/8.12.11) with ESMTP id k6S1McKH030656 for ; Thu, 27 Jul 2006 21:22:38 -0400 Received: from [127.0.0.1] (dhcp-172-16-25-208.sfbay.redhat.com [172.16.25.208]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id k6S1MZ5Q016048 for ; Thu, 27 Jul 2006 21:22:37 -0400 Message-ID: <44C96749.4040604@redhat.com> Date: Thu, 27 Jul 2006 18:24:25 -0700 From: Wan-Teh Chang User-Agent: Thunderbird 2.0a1 (Windows/20060725) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Suite B compliance of TLS 1.2 References: <279DDDAFA85EC74C9300A0598E704056618F7E@hdsmsx412.amr.corp.intel.com> In-Reply-To: <279DDDAFA85EC74C9300A0598E704056618F7E@hdsmsx412.amr.corp.intel.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Content-Type: multipart/mixed; boundary="===============0175478044==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============0175478044== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010707080301030808060701" This is a cryptographically signed message in MIME format. --------------ms010707080301030808060701 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'd like to explain why I said it may be controversial to define new cipher suites whose MAC algorithm is Suite B compliant. HMAC-SHA-1 is still considered secure in spite of the recent collision attack against SHA-1. So I suspect that some people may object to defining new HMAC-SHA-256 and HMAC-SHA-384 cipher suites simply because HMAC-SHA-1, or rather SHA-1, is not in Suite B. Wan-Teh Chang --------------ms010707080301030808060701 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIKWDCC BSgwggQQoAMCAQICECPc+9+WtsOZqiiOT1eYr6cwDQYJKoZIhvcNAQEFBQAwZTELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMR0wGwYDVQQLExRBZGRUcnVzdCBUVFAgTmV0 d29yazEhMB8GA1UEAxMYQWRkVHJ1c3QgQ2xhc3MgMSBDQSBSb290MB4XDTA1MTIyMzAwMDAw MFoXDTA2MTIyMzIzNTk1OVowgdsxNTAzBgNVBAsTLENvbW9kbyBUcnVzdCBOZXR3b3JrIC0g UEVSU09OQSBOT1QgVkFMSURBVEVEMUYwRAYDVQQLEz1UZXJtcyBhbmQgQ29uZGl0aW9ucyBv ZiB1c2U6IGh0dHA6Ly93d3cuY29tb2RvLm5ldC9yZXBvc2l0b3J5MR8wHQYDVQQLExYoYyky MDAzIENvbW9kbyBMaW1pdGVkMRYwFAYDVQQDEw1XYW4tVGVoIENoYW5nMSEwHwYJKoZIhvcN AQkBFhJ3dGNoYW5nQHJlZGhhdC5jb20wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAJZ3 pYgLLfB2IU5Rdd4B/1Z7p391Z+vjH2pCEeQMWxK966ptunHqLmA8Iz/8Tiy5KN9LKRkV9Q2c zvWjapJeyiutrictOZCY2qkRMG6eTbDDT8Tz6qO7iRnUK7JkXs2cZtlk442Xgky+xcLr1cCC RJ8w3d/ul4HKdGZwtsYFLkLpAgMBAAGjggHfMIIB2zAdBgNVHQ4EFgQUAsOMfMcFVfub10xu 3ycfUWaYHO4wDgYDVR0PAQH/BAQDAgWgMAwGA1UdEwEB/wQCMAAwIAYDVR0lBBkwFwYIKwYB BQUHAwQGCysGAQQBsjEBAwUCMBEGCWCGSAGG+EIBAQQEAwIFIDBGBgNVHSAEPzA9MDsGDCsG AQQBsjEBAgEBATArMCkGCCsGAQUFBwIBFh1odHRwczovL3NlY3VyZS5jb21vZG8ubmV0L0NQ UzB3BgNVHR8EcDBuMDagNKAyhjBodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRUcnVzdENs YXNzMUNBUm9vdC5jcmwwNKAyoDCGLmh0dHA6Ly9jcmwuY29tb2RvLm5ldC9BZGRUcnVzdENs YXNzMUNBUm9vdC5jcmwwgYYGCCsGAQUFBwEBBHoweDA7BggrBgEFBQcwAoYvaHR0cDovL2Ny dC5jb21vZG9jYS5jb20vQWRkVHJ1c3RVVE5DbGllbnRDQS5jcnQwOQYIKwYBBQUHMAKGLWh0 dHA6Ly9jcnQuY29tb2RvLm5ldC9BZGRUcnVzdFVUTkNsaWVudENBLmNydDAdBgNVHREEFjAU gRJ3dGNoYW5nQHJlZGhhdC5jb20wDQYJKoZIhvcNAQEFBQADggEBAGpDustBazwJLV/u3OHE gGKhU5QxPPnhJcAs4hPn6oG2de85pKS9/mioaEhf1Huvu8cBaEMIe0dQoGQuqOIiM38WFXRI N4m0SoTu2pw4MXIy9t20kNiqq0ISf/O+kLJ6QrIsRurqw7WexkGkv8S4Z+hgls1wFXTBFsnu vZsgqqtDc2s6EHMh9Wqk4WWCMsr8WExtsst5pnLWHV7BbiquqHrbFZhwRLiWjVrBNDrVT+ym lmZilFt8GHjdrJs3aLvuptP+yzDqIE0jFtlVNn5gLzYSKMMx8twn9yJTHCC2AwAbfmGNf75o yPCS8MqAqupN2B+oST9MqdF6ZpVcxVdR61QwggUoMIIEEKADAgECAhAj3PvflrbDmaoojk9X mK+nMA0GCSqGSIb3DQEBBQUAMGUxCzAJBgNVBAYTAlNFMRQwEgYDVQQKEwtBZGRUcnVzdCBB QjEdMBsGA1UECxMUQWRkVHJ1c3QgVFRQIE5ldHdvcmsxITAfBgNVBAMTGEFkZFRydXN0IENs YXNzIDEgQ0EgUm9vdDAeFw0wNTEyMjMwMDAwMDBaFw0wNjEyMjMyMzU5NTlaMIHbMTUwMwYD VQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBFUlNPTkEgTk9UIFZBTElEQVRFRDFGMEQG A1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2YgdXNlOiBodHRwOi8vd3d3LmNvbW9kby5u ZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAwMyBDb21vZG8gTGltaXRlZDEWMBQGA1UE AxMNV2FuLVRlaCBDaGFuZzEhMB8GCSqGSIb3DQEJARYSd3RjaGFuZ0ByZWRoYXQuY29tMIGf MA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCWd6WICy3wdiFOUXXeAf9We6d/dWfr4x9qQhHk DFsSveuqbbpx6i5gPCM//E4suSjfSykZFfUNnM71o2qSXsorra4nLTmQmNqpETBunk2ww0/E 8+qju4kZ1CuyZF7NnGbZZOONl4JMvsXC69XAgkSfMN3f7peBynRmcLbGBS5C6QIDAQABo4IB 3zCCAdswHQYDVR0OBBYEFALDjHzHBVX7m9dMbt8nH1FmmBzuMA4GA1UdDwEB/wQEAwIFoDAM BgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYd aHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwdwYDVR0fBHAwbjA2oDSgMoYwaHR0cDov L2NybC5jb21vZG9jYS5jb20vQWRkVHJ1c3RDbGFzczFDQVJvb3QuY3JsMDSgMqAwhi5odHRw Oi8vY3JsLmNvbW9kby5uZXQvQWRkVHJ1c3RDbGFzczFDQVJvb3QuY3JsMIGGBggrBgEFBQcB AQR6MHgwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL0FkZFRydXN0VVRO Q2xpZW50Q0EuY3J0MDkGCCsGAQUFBzAChi1odHRwOi8vY3J0LmNvbW9kby5uZXQvQWRkVHJ1 c3RVVE5DbGllbnRDQS5jcnQwHQYDVR0RBBYwFIESd3RjaGFuZ0ByZWRoYXQuY29tMA0GCSqG SIb3DQEBBQUAA4IBAQBqQ7rLQWs8CS1f7tzhxIBioVOUMTz54SXALOIT5+qBtnXvOaSkvf5o qGhIX9R7r7vHAWhDCHtHUKBkLqjiIjN/FhV0SDeJtEqE7tqcODFyMvbdtJDYqqtCEn/zvpCy ekKyLEbq6sO1nsZBpL/EuGfoYJbNcBV0wRbJ7r2bIKqrQ3NrOhBzIfVqpOFlgjLK/FhMbbLL eaZy1h1ewW4qrqh62xWYcES4lo1awTQ61U/sppZmYpRbfBh43aybN2i77qbT/ssw6iBNIxbZ VTZ+YC82EijDMfLcJ/ciUxwgtgMAG35hjX++aMjwkvDKgKrqTdgfqEk/TKnRemaVXMVXUetU MYIC7DCCAugCAQEweTBlMQswCQYDVQQGEwJTRTEUMBIGA1UEChMLQWRkVHJ1c3QgQUIxHTAb BgNVBAsTFEFkZFRydXN0IFRUUCBOZXR3b3JrMSEwHwYDVQQDExhBZGRUcnVzdCBDbGFzcyAx IENBIFJvb3QCECPc+9+WtsOZqiiOT1eYr6cwCQYFKw4DAhoFAKCCAckwGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYwNzI4MDEyNDI1WjAjBgkqhkiG9w0B CQQxFgQUkdc4Mh/fYT9Z0LgW8ckxes0byYkwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwgYgGCSsGAQQBgjcQBDF7MHkwZTELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0 IEFCMR0wGwYDVQQLExRBZGRUcnVzdCBUVFAgTmV0d29yazEhMB8GA1UEAxMYQWRkVHJ1c3Qg Q2xhc3MgMSBDQSBSb290AhAj3PvflrbDmaoojk9XmK+nMIGKBgsqhkiG9w0BCRACCzF7oHkw ZTELMAkGA1UEBhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMR0wGwYDVQQLExRBZGRUcnVz dCBUVFAgTmV0d29yazEhMB8GA1UEAxMYQWRkVHJ1c3QgQ2xhc3MgMSBDQSBSb290AhAj3Pvf lrbDmaoojk9XmK+nMA0GCSqGSIb3DQEBAQUABIGAlIxGeDYCvlfobPLge31VvD9336ZJ1yDI 4Nb6Vm0YDsRQ0XT5WEd5XWknfref1G7zEUJPpO2k/tsT39O2M8KlfFquQT+dKCr1xwQrdlzM V9wdI4KbvgUTx3YTXPTg/WBsfSbLg0GfstANTm2vYrsJL8isEtOD0J9liygMxmFSn8kAAAAA AAA= --------------ms010707080301030808060701-- --===============0175478044== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls --===============0175478044==-- From tls-bounces@lists.ietf.org Thu Jul 27 21:35:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6HGa-0007JO-Cg; Thu, 27 Jul 2006 21:35:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6HGZ-0007JG-6s for tls@ietf.org; Thu, 27 Jul 2006 21:35:51 -0400 Received: from dyn50.sunlabs.com ([204.153.12.50] helo=mail-mta.sunlabs.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G6HGW-0006Pb-Sz for tls@ietf.org; Thu, 27 Jul 2006 21:35:51 -0400 Received: from mail.sunlabs.com ([152.70.2.186]) by dps.sfvic.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTP id <0J3300K5HB3LF910@dps.sfvic.sunlabs.com> for tls@ietf.org; Thu, 27 Jul 2006 18:35:45 -0700 (PDT) Received: from [152.70.69.99] by mail.sunlabs.com (Sun Java System Messaging Server 6.1 HotFix 0.02 (built Aug 25 2004)) with ESMTPSA id <0J33001YAB3G9R00@mail.sunlabs.com> for tls@ietf.org; Thu, 27 Jul 2006 18:35:45 -0700 (PDT) Date: Thu, 27 Jul 2006 18:36:16 -0700 From: Vipul Gupta Subject: Re: [TLS] Suite B compliance of TLS 1.2 In-reply-to: <44C96749.4040604@redhat.com> To: Wan-Teh Chang Message-id: <493A9E16-3A3F-4A46-9B2A-8CBA52F51CE6@sun.com> MIME-version: 1.0 X-Mailer: Apple Mail (2.750) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <279DDDAFA85EC74C9300A0598E704056618F7E@hdsmsx412.amr.corp.intel.com> <44C96749.4040604@redhat.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Vipul Gupta , tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 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: , Errors-To: tls-bounces@lists.ietf.org In RFC 4231 (standards track), we already have a precedence for the IETF embracing HMAC-SHA-256 etc so there might not be any controversy after all. vipul On Jul 27, 2006, at 6:24 PM, Wan-Teh Chang wrote: > I'd like to explain why I said it may be controversial > to define new cipher suites whose MAC algorithm is Suite > B compliant. > > HMAC-SHA-1 is still considered secure in spite of the > recent collision attack against SHA-1. So I suspect > that some people may object to defining new HMAC-SHA-256 > and HMAC-SHA-384 cipher suites simply because HMAC-SHA-1, > or rather SHA-1, is not in Suite B. > > Wan-Teh Chang _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Jul 28 12:08:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Ut6-0001LH-2p; Fri, 28 Jul 2006 12:08:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G6Ut4-0001LC-8g for tls@ietf.org; Fri, 28 Jul 2006 12:08:30 -0400 Received: from smtpout09-04.prod.mesa1.secureserver.net ([64.202.165.17]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1G6Ut0-000298-QD for tls@ietf.org; Fri, 28 Jul 2006 12:08:30 -0400 Received: (qmail 23112 invoked from network); 28 Jul 2006 16:08:25 -0000 Received: from unknown (69.174.163.252) by smtpout09-04.prod.mesa1.secureserver.net (64.202.165.17) with ESMTP; 28 Jul 2006 16:08:24 -0000 From: "Ron Teitelbaum" To: "'Brian Minard'" Subject: RE: [TLS] Looking for Test cases or Documents with Byte Samples Date: Fri, 28 Jul 2006 12:08:23 -0400 Organization: US Medical Records Specialists Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <20060728012825.GB18577@certicom.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2869 Thread-Index: Acax5Sc0c2K4fzv5TeOE1b0BnYqH1AAekDTQ X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Ron@USMedRec.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: , Errors-To: tls-bounces@lists.ietf.org Brian, Thank you for your suggestion I will contact your sales team to inquire about special pricing for open source projects. Ron Teitelbaum Squeak Cryptography Team Leader www.squeak.org President / Principal Software Engineer US Medical Record Specialists Ron@USMedRec.com > -----Original Message----- > From: Brian Minard > Sent: Thursday, July 27, 2006 9:28 PM > > I had a discussion with Yngve on making test servers publicly > available--he doesn't have anything presently, but had some > ideas on what might need to be built. Yngve tells me that > Pasi.Eronen@nokia.com is working on something--unclear if it's > publicly available. > > If you have cash, you might look at Codenomicon's TLS Test tool > (http://www.codenomicon.com/). It doesn't cover Yngve's draft but > it's a step in the same direction. > > -- > Brian Minard (bminard@certicom.com) > Engineering Manager, Connection Security Team, Certicom Corp. > cel: 416-579-4637 > tel: 905-501-3858 > http://www.certicom.com _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls