From tls-bounces@lists.ietf.org Wed Nov 01 09:21:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfGx3-0002aG-B5; Wed, 01 Nov 2006 09:20:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfGx2-0002a6-76 for tls@lists.ietf.org; Wed, 01 Nov 2006 09:20:20 -0500 Received: from rimp2.nist.gov ([129.6.16.227] helo=smtp.nist.gov) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfGwx-000832-8M for tls@lists.ietf.org; Wed, 01 Nov 2006 09:20:20 -0500 Received: from magneto.nist.gov ([129.6.54.159]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id kA1EK3pD007025 for ; Wed, 1 Nov 2006 09:20:03 -0500 Message-Id: <7.0.1.0.2.20061101091038.0208f420@nist.gov> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 01 Nov 2006 09:19:52 -0500 To: tls@lists.ietf.org From: Ray Perlner Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: ray.perlner@nist.gov X-Spam-Score: 0.0 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Subject: [TLS] NIST TLS recomendations 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 As many of you are aware, publication of NIST SP=20 800-56A establishes new requirements for federal=20 agencies, including KDFs recommended for use with=20 certain key establishment algorithms. Since=20 current protocols do not use the KDFs specified=20 in 800-56A, NIST has approved certain KDFs for=20 use in particular contexts until the 800-56A KDFs=20 become more widely accepted. The TLS KDF has been=20 approved for use by government agencies in the=20 context of the TLS protocol through the end of=20 2010. One of the security ADs requested that=20 NIST review that decision to determine under what=20 circumstances we can extend that approval indefinitely. Upon our review of the TLS protocol (as specified=20 in draft-ietf-tls-rfc4346-bis-01), we noted that=20 the IETF has up to this point made the design=20 decision not to use the key derivation function=20 specified by NIST SP 800-56a. This KDF provides=20 certain guarantees as to the security of schemes=20 that use it. We therefore have evaluated whether=20 those same guarantees are provided within the=20 currently specified TLS v1.2 protocol. This=20 process led us to recommend the following=20 modifications to TLS v1.2 addressing both the=20 security issues that would be resolved by using=20 our KDF, and other security issues that arise in=20 the context of the TLS protocol: Page 20-21: Section 6.2.3.2 under IV The document specifies that the IV SHOULD be=20 generated by method (1) or (2) and MAY be=20 generated by an alternate method. There is,=20 however, no language forbidding the generation of=20 IVs by a fourth unlisted method. If a fourth=20 method is used, the protocol will not fail but=20 may be insecure. Therefore we recommend adding=20 language forbidding the use of an unlisted method for IV generation. Page 22: Section 6.2.3.2 under implementation note: This section suggests but does not mandate a=20 measure to protect against timing attacks. We=20 recommend that this measure be mandated. Page 27: Section 7.2.2 While it is required that certain alerts must be=20 fatal, it is not currently required that said=20 alerts are sent in the first place. For example,=20 if the client certificate is not of the=20 negotiated type, but the server is capable of=20 parsing the certificate, we believe that a=20 compliant implementation of TLS should reject the=20 certificate and send a fatal error=20 (unexpected_message most likely,) however the=20 document does not currently seem to mandate this.=20 We recommend that the conditions under which any=20 fatal alerts are mandated be added. We also recommend that the following alerts, not=20 currently listed as fatal, be made automatically=20 fatal: bad_certificate, unsupported_certificate,=20 and certificate_revoked. Ideally, we would=20 recommend that expired_certificate be made=20 automatically fatal as well, but we understand=20 that expired certificates are currently=20 sufficiently pervasive that this may not be a viable option. The document allows compliant implementations of=20 TLS 1.2 to send the decryption_failed alert. The=20 inclusion of this alert has known security flaws=20 [CBCATT]. We recommend that compliant=20 implementations of TLS 1.2 MUST NOT generate this=20 alert but SHOULD be able to parse such an alert. Page 45: Section 7.4.1.4.3 This section does not explicitly forbid a client=20 from sending certificate URLs when the server and=20 client have not explicitly agreed to support this=20 option. In order to address this ambiguity, we=20 suggest changing the current wording from: =93In order to negotiate to send certificate URLs=20 to a server, clients MAY include an extension of=20 type "client_certificate_url" in the (extended) client hello=85 =93Servers that receive an extended client hello=20 containing a "client_certificate_url" extension,=20 MAY indicate that they are willing to accept=20 certificate URLs by including an extension of=20 type "client_certificate_url" in the (extended) server hello=85=94 to: =93Clients MAY negotiate to send certificate URLs=20 to a server. In order to do this, clients MUST=20 include an extension of type=20 "client_certificate_url" in the (extended) client hello=85 =93Servers that receive an extended client hello=20 containing a "client_certificate_url" extension=20 MAY indicate that they are willing to accept=20 certificate URLs. In order to do this, servers=20 MUST include an extension of type=20 "client_certificate_url" in the (extended) server hello=85=94 This mandates that the client and server signal=20 their intentions. The current wording could be misinterpreted. Page 47: Section 7.4.1.4.5 (Truncated HMAC) This section has the same MAY/MUST wording issue as section 7.4.1.4.3 Page 57: Section 7.4.8 If the optional hash is not included with the=20 client certificate URL, the server has no way to=20 verify the name under which the private key in=20 the certificate was used, since the certificate=20 will not appear in the generation of the finished=20 message. We therefore recommend that the certificate hash be mandatory. Furthermore, we do not want the client to be able=20 to claim, after the fact, that a certificate with=20 a different name was used. The collision=20 resistance of the hash function is therefore=20 crucial. The algorithm mandates the use of SHA1=20 for the certificate hash. While practical SHA1=20 collision attacks have not yet been applied, we=20 should be prepared to face such attacks. We=20 therefore recommend that algorithm agility and=20 support for a stronger hash function, such as SHA=20 256 or SHA 384 (for suite B compatibility) be=20 added to this stage of the protocol. Page 62: Section 7.4.9.1 under Note: This section suggests a procedure to prevent the=20 Bleichenbacher attack on PKCS#1 v1.5 encrypted=20 messages (specifically the pre-master secret.)=20 This procedure is not listed as mandatory. We=20 recommend that either this procedure be made=20 mandatory, or that all RSA encrypted messages be=20 required to use the OAEP padding scheme specified=20 in PKCS#1 v2. In the latter scenario, the=20 overwhelming majority of PKCS#1 v1.5 formatted=20 messages would need to be rejected by any compliant implementation. There is ANOTHER note later in this section (at=20 the very end, after the implementation notes)=20 that discusses a variant of the Bleichenbacher=20 attack (by Klima, Pokorny, and Rosa =96 see=20 [KPR03]) that depends on the server reporting on=20 errors found in the version number included in=20 the RSA-decrypted premaster-secret message.=20 Therefore, the draft=92s weak statement to the=20 effect that servers shouldn=92t generate an alert=20 if there is such a problem should also be=20 strengthened to a MUST NOT. In fact, it should be=20 a general rule that decryption problems with PKCS=20 #1.5-formatted messages MUST NOT trigger actions=20 that are observably different than the actions=20 that would be taken if there were no problems. Page 62-63 Section 7.4.9.1 under the second implementation note: This section states that RSA operations SHOULD be=20 done in such a way as to prevent timing attacks.=20 We recommend changing this to MUST. We further=20 recommend that precautions against timing attacks=20 be made for other key exchange techniques, such=20 as those based on permanent Diffie-Hellman parameters. Page 67 Section 8.1.2 We recommend that the leading zeroes of a=20 Diffie-Hellman-generated Z be RETAINED when it is=20 used as a pre_master_secret, so that the input to=20 the master_secret computation will have predetermined length. Page 81 Section A5. This section deprecates anonymous DH, which=20 hopefully means that no compliant version of TLS=20 1.2 will support this mode, (or any other=20 completely anonymous mode.) The rest of the=20 document, however, is written with the=20 implication that anonymous modes exist and are=20 allowed, albeit strongly discouraged, and server=20 authentication is only explicitly required in=20 section F.1.1.1 under warning (which is in the=20 implementation recommendations section, so it is=20 not clear that this is actually a requirement),=20 and then only under certain poorly defined=20 circumstances. It is important to note that as=20 long as the client supports anonymous key=20 exchange, the server=92s policies regarding=20 anonymous key exchange (and any other crypto=20 parameters) become irrelevant, because any party=20 claiming to be the server can arbitrarily select=20 from the parameters offered by the client. We=20 recommend that all references to anonymous key=20 exchange that do not explicitly indicate that=20 anonymous key exchange MUST NOT be supported be=20 removed from the document or modified in such a=20 way that they do explicitly forbid anonymous key exchange. The following comments are not security related,=20 but we did notice a few editorial mistakes and nitpicks. Page 5: Section 1.1 is listed twice. Page 24: Section 6.2.2 Implementation note The first sentence reads =93the currently defined=20 which requires the most material is=20 AES_256_CBC_SHA=85=94 This is ungrammatical. It=20 should most likely read, =93the currently defined=20 CIPHERSUITE which requires the most material=85=94 Page 33: Section 7.3 The statement =93If the client has sent a certificate with=20 signing ability, a digitally-signed certificate=20 verify message is sent to explicitly verify the certificate,=94 is incorrect and misleading. If anything, this=20 message verifies the client=92s possession of a=20 particular private key, and demonstrates (to the=20 server) the client=92s knowledge of the form of the=20 handshake messages that have been exchanged up to=20 this point in the protocol. A certificate is=20 =93verified=94 by checking the CA=92s signature on the certificate, etc. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 01 09:56:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfHUR-0004WG-Fi; Wed, 01 Nov 2006 09:54:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfHUP-0004WA-Gr for tls@lists.ietf.org; Wed, 01 Nov 2006 09:54:49 -0500 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfHUL-00079F-0o for tls@lists.ietf.org; Wed, 01 Nov 2006 09:54:49 -0500 Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id kA1EsVQg025154 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 1 Nov 2006 15:54:32 +0100 From: Simon Josefsson To: Ray Perlner References: <7.0.1.0.2.20061101091038.0208f420@nist.gov> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:061101:ray.perlner@nist.gov::ZjUci2KWw91c3s4H:H2k X-Hashcash: 1:22:061101:tls@lists.ietf.org::kBqNPAHLjEo/01R2:FuoE Date: Wed, 01 Nov 2006 15:54:31 +0100 In-Reply-To: <7.0.1.0.2.20061101091038.0208f420@nist.gov> (Ray Perlner's message of "Wed\, 01 Nov 2006 09\:19\:52 -0500") Message-ID: <87ejsnz07s.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: tls@lists.ietf.org Subject: [TLS] Re: NIST TLS recomendations 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 Ray Perlner writes: > Page 81 Section A5. > This section deprecates anonymous DH, which hopefully means that no > compliant version of TLS 1.2 will support this mode, (or any other > completely anonymous mode.) I don't read A5 that way. Section A5 suggests (but no MUST NOT) that DH_anon for RC4/DES/3DES is deprecated, which I'd agree to. However, section A5 appear to permit DH_anon with AES128/AES256. I believe fully anonymous ciphers are a useful feature of TLS, and that they should stay. Client/server authentication can and do happen via other protocols than TLS, and those protocols can use TLS channel bindings to protect against man in the middle attacks, if necessary. /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 01 10:03:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfHcR-0001im-TO; Wed, 01 Nov 2006 10:03:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfHcQ-0001fO-HE for tls@lists.ietf.org; Wed, 01 Nov 2006 10:03:06 -0500 Received: from mailhost.auckland.ac.nz ([130.216.190.12] helo=chico.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfHcD-0000GD-Q2 for tls@lists.ietf.org; Wed, 01 Nov 2006 10:03:06 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by chico.itss.auckland.ac.nz (Postfix) with ESMTP id CA0DA35E2B; Thu, 2 Nov 2006 04:02:49 +1300 (NZDT) Received: from chico.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 18914-21; Thu, 2 Nov 2006 04:02:49 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by chico.itss.auckland.ac.nz (Postfix) with ESMTP id 7AF1C349D9; Thu, 2 Nov 2006 04:02:48 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 95FED37742; Thu, 2 Nov 2006 04:02:47 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1GfHcH-0004t2-00; Thu, 02 Nov 2006 04:02:57 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: jas@extundo.com, ray.perlner@nist.gov Subject: Re: [TLS] Re: NIST TLS recomendations In-Reply-To: <87ejsnz07s.fsf@latte.josefsson.org> Message-Id: Date: Thu, 02 Nov 2006 04:02:57 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.5 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: tls@lists.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 Simon Josefsson writes: >I believe fully anonymous ciphers are a useful feature of TLS, and that they >should stay. Client/server authentication can and do happen via other >protocols than TLS, and those protocols can use TLS channel bindings to >protect against man in the middle attacks, if necessary. DH_anon is very widely used for opportunistic encryption in systems supporting STARTTLS/STLS/AUTH TLS and similar mechanisms. (Actually that's not 100% accurate, what's used is something like DHE with a self-signed cert that typically isn't checked, so it's a mechanism that acts like DH_anon without actually being DH_anon. So I don't know if deprecating DH_anon will have much effect when the situations where it would be needed are using other mechanisms in the manner of DH_anon. This is an interesting question, are you trying to deprecate the thing labelled DH_anon, or to deprecate the practice of making unauthenticated connections?). Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 01 11:26:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfIu8-0003Lo-8Q; Wed, 01 Nov 2006 11:25:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfIu6-0003Jl-JB for tls@lists.ietf.org; Wed, 01 Nov 2006 11:25:26 -0500 Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfInD-0005wE-NS for tls@lists.ietf.org; Wed, 01 Nov 2006 11:18:26 -0500 Received: from gto.missi.ncsc.mil (goodman.missi.ncsc.mil [144.51.60.3]) by stingray.missi.ncsc.mil with ESMTP id kA1GR2Ew015441; Wed, 1 Nov 2006 11:27:03 -0500 (EST) Received: from EXCH.missi.ncsc.mil ([144.51.60.21]) by gto.missi.ncsc.mil with Microsoft SMTPSVC(5.0.2195.6713); Wed, 1 Nov 2006 11:17:42 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [TLS] Re: NIST TLS recomendations Date: Wed, 1 Nov 2006 11:17:41 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Re: NIST TLS recomendations Thread-Index: Acb9xueOooDlE0J+QMOmMn8R7m79XwAAcNRg From: "Kemp David P." To: "Peter Gutmann" , , X-OriginalArrivalTime: 01 Nov 2006 16:17:42.0671 (UTC) FILETIME=[422A79F0:01C6FDD1] X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: tls@lists.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 "Opportunistic encryption" sounds like a much more accurate characterization of anonymous/ephemeral sessions than does "protect against MITM attacks", the latter being precisely what unauthenticated encryption does NOT provide. ------- I believe the purpose of Mr. Perlner's request was to gain a sense of the working group's opinion on the role of IETF security standards --=20 should the TLS spec focus on interoperability and permit a wide spectrum in the protocol assurance of compliant implementations, with NIST Special Publications or FIPS profiling the higher end of the spectrum for Government applications, or should the higher assurance wire options become mandatory for TLS compliance? My sense is that the AD's expectation is unrealistic and that NIST will need to profile a subset of TLS for FIPS compliance after 2010, but I'd be happy to be proven wrong. Dave -----Original Message----- From: Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz]=20 Sent: Wednesday, November 01, 2006 10:03 AM To: jas@extundo.com; ray.perlner@nist.gov Cc: tls@lists.ietf.org Subject: Re: [TLS] Re: NIST TLS recomendations Simon Josefsson writes: >I believe fully anonymous ciphers are a useful feature of TLS, and that they >should stay. Client/server authentication can and do happen via other >protocols than TLS, and those protocols can use TLS channel bindings to >protect against man in the middle attacks, if necessary. DH_anon is very widely used for opportunistic encryption in systems supporting STARTTLS/STLS/AUTH TLS and similar mechanisms. (Actually that's not 100% accurate, what's used is something like DHE with a self-signed cert that typically isn't checked, so it's a mechanism that acts like DH_anon without actually being DH_anon. So I don't know if deprecating DH_anon will have much effect when the situations where it would be needed are using other mechanisms in the manner of DH_anon. This is an interesting question, are you trying to deprecate the thing labelled DH_anon, or to deprecate the practice of making unauthenticated connections?). Peter. _______________________________________________ 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 Nov 02 02:22:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfWsM-0008Ii-LJ; Thu, 02 Nov 2006 02:20:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfWsL-0008FI-NC for tls@lists.ietf.org; Thu, 02 Nov 2006 02:20:33 -0500 Received: from moutng.kundenserver.de ([212.227.126.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfWsJ-0002qY-J5 for tls@lists.ietf.org; Thu, 02 Nov 2006 02:20:32 -0500 Received: from [80.142.173.218] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1GfWsD0Gtz-0006wJ; Thu, 02 Nov 2006 08:20:26 +0100 Received: by tau.invalid (Postfix, from userid 1000) id 79FF84E39; Thu, 2 Nov 2006 08:20:27 +0100 (CET) Date: Thu, 2 Nov 2006 08:20:27 +0100 From: Bodo Moeller To: Ray Perlner Subject: Re: [TLS] NIST TLS recomendations Message-ID: <20061102072027.GA1607@tau.invalid> References: <7.0.1.0.2.20061101091038.0208f420@nist.gov> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7.0.1.0.2.20061101091038.0208f420@nist.gov> User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: tls@lists.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, Nov 01, 2006 at 09:19:52AM -0500, Ray Perlner wrote: [...] > Upon our review of the TLS protocol (as specified > in draft-ietf-tls-rfc4346-bis-01), we noted that > the IETF has up to this point made the design > decision not to use the key derivation function > specified by NIST SP 800-56a. This KDF provides > certain guarantees as to the security of schemes > that use it. We therefore have evaluated whether > those same guarantees are provided within the > currently specified TLS v1.2 protocol. This > process led us to recommend the following > modifications to TLS v1.2 addressing both the > security issues that would be resolved by using > our KDF, and other security issues that arise in > the context of the TLS protocol: Thank you for contributing the list of proposed modifications. Just some brief comments at this time: [...] > Page 27: Section 7.2.2 > While it is required that certain alerts must be > fatal, it is not currently required that said > alerts are sent in the first place. For example, > if the client certificate is not of the > negotiated type, but the server is capable of > parsing the certificate, we believe that a > compliant implementation of TLS should reject the > certificate and send a fatal error > (unexpected_message most likely,) however the > document does not currently seem to mandate this. I don't think that this particular change is warranted. In many situations, servers request client authentication via a certificate, but can tolerate unauthenticated clients as well. In a scenario where unauthenticated clients are welcome, authenticated clients may be given the privilege to access services that are not available to unauthenticated clients. (E.g., for the case of an SMTP server, any client can send e-mail to addresses that are local to the server; only certain authenticated clients can send e-mail to remote addresses.) There is no compelling reason to have the TLS handshake fail if a client that tries to authenticate itself by presenting a certificate presents a certificate that the server cannot handle: In this case the client may simply end up as an unauthenticated client, which may very sell sufficient for whatever services the client actually needs to use. If you think that the current wording is not strict enough, then the change that should be done is not to force these alerts to become fatal. Possibly the specification should more clearly point out that, in the situations where such alerts have to be sent by the server since the are problems about verifying the client certificate, the contents of the client certificate cannot be trusted in any way and must be ignored. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 02 02:40:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfXAV-0000TV-Mt; Thu, 02 Nov 2006 02:39:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfXAT-0000Qz-W8 for tls@lists.ietf.org; Thu, 02 Nov 2006 02:39:18 -0500 Received: from moutng.kundenserver.de ([212.227.126.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfX8a-00057L-DM for tls@lists.ietf.org; Thu, 02 Nov 2006 02:37:21 -0500 Received: from [80.142.173.218] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu1) with ESMTP (Nemesis), id 0MKwpI-1GfX8Z1XJH-0000rb; Thu, 02 Nov 2006 08:37:19 +0100 Received: by tau.invalid (Postfix, from userid 1000) id DC6504E39; Thu, 2 Nov 2006 08:37:21 +0100 (CET) Date: Thu, 2 Nov 2006 08:37:21 +0100 From: Bodo Moeller To: Ray Perlner Subject: Re: [TLS] NIST TLS recomendations Message-ID: <20061102073721.GA2380@tau.invalid> References: <7.0.1.0.2.20061101091038.0208f420@nist.gov> <20061102072027.GA1607@tau.invalid> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061102072027.GA1607@tau.invalid> User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: tls@lists.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 Thu, Nov 02, 2006 at 08:20:27AM +0100, Bodo Moeller wrote: [...] > There is no compelling reason to have the TLS handshake fail if a > client that tries to authenticate itself by presenting a certificate > presents a certificate that the server cannot handle: In this case the > client may simply end up as an unauthenticated client, which may very > sell sufficient for whatever services the client actually needs to > use. Oops -- this should read: "..., which may very well be sufficient for whatever services the client actually needs to use." Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 02 02:46:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfXGz-0003ER-Jv; Thu, 02 Nov 2006 02:46:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfXAe-0000ZM-OU for tls@lists.ietf.org; Thu, 02 Nov 2006 02:39:28 -0500 Received: from moutng.kundenserver.de ([212.227.126.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfX5k-0004pK-N3 for tls@lists.ietf.org; Thu, 02 Nov 2006 02:34:26 -0500 Received: from [80.142.173.218] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1GfX5g1uiV-00084W; Thu, 02 Nov 2006 08:34:24 +0100 Received: by tau.invalid (Postfix, from userid 1000) id D09064E39; Thu, 2 Nov 2006 08:34:22 +0100 (CET) Date: Thu, 2 Nov 2006 08:34:22 +0100 From: Bodo Moeller To: Simon Josefsson Subject: Re: [TLS] Re: NIST TLS recomendations Message-ID: <20061102073422.GB1607@tau.invalid> References: <7.0.1.0.2.20061101091038.0208f420@nist.gov> <87ejsnz07s.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ejsnz07s.fsf@latte.josefsson.org> User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: tls@lists.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, Nov 01, 2006 at 03:54:31PM +0100, Simon Josefsson wrote: > Ray Perlner writes: >> Page 81 Section A5. >> This section deprecates anonymous DH, which hopefully means that no >> compliant version of TLS 1.2 will support this mode, (or any other >> completely anonymous mode.) > I don't read A5 that way. > > Section A5 suggests (but no MUST NOT) that DH_anon for RC4/DES/3DES is > deprecated, which I'd agree to. > > However, section A5 appear to permit DH_anon with AES128/AES256. This is true, but if you look at the rationale given in A.5 for deprecating these three DH_anon cipersuites, it is quite clear that the two AES DH_anon ciphersuites should have been deprecated too: The following cipher suites are used for completely anonymous Diffie- ^^^^^^^^^^^^^^^^^ Hellman communications in which neither party is authenticated. Note ^^^^^^^ that this mode is vulnerable to man-in-the-middle attacks and is ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ therefore deprecated. ^^^^^^^^^^^^^^^^^^^^ Probably this inconsistency was introduced when the specification of the AES ciphersuites was merged into the main TLS specification. Having said that, I agree that DH_anon ciphersuites should not be deprecated! In particular, anonymous key exchange course should not be explicitly forbidden (as per the NIST recommendation). > I believe fully anonymous ciphers are a useful feature of TLS, and > that they should stay. Client/server authentication can and do happen > via other protocols than TLS, and those protocols can use TLS channel > bindings to protect against man in the middle attacks, if necessary. This is exactly right, however it certainly is reasonable to add some language to the specification that points out that these ciphersuites should *usually* not be enabled. Here is a proposal for A.5. The following cipher suites are used for completely anonymous Diffie- Hellman communications in which neither party is authenticated. Note that this mode is vulnerable to man-in-the-middle attacks. Using this mode therefore is deprecated: These ciphersuites MUST NOT be used by TLS 1.1 implementations unless the application layer has specifically requested to allow anonymous key exchange. (Anonymous key exchange may sometimes be acceptable, for example, to support opportunistic encryption when no set-up for authentication is in place, or when TLS is used as part of more complex security protocols that have other means to ensure authentication.) CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00, 0x18 }; CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00, 0x1A }; CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x1B }; CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x34 }; CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x3A }; Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 02 02:53:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfXNA-00071U-2V; Thu, 02 Nov 2006 02:52:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfXN8-0006z5-Mu for tls@lists.ietf.org; Thu, 02 Nov 2006 02:52:22 -0500 Received: from mailhost.auckland.ac.nz ([130.216.190.14] helo=zeppo.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfXN6-0007Ro-9L for tls@lists.ietf.org; Thu, 02 Nov 2006 02:52:22 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id C296034887; Thu, 2 Nov 2006 20:52:18 +1300 (NZDT) Received: from zeppo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07450-34; Thu, 2 Nov 2006 20:52:18 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id 70B5E34416; Thu, 2 Nov 2006 20:52:18 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 35E1337742; Thu, 2 Nov 2006 20:52:18 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1GfXNB-000464-00; Thu, 02 Nov 2006 20:52:25 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: bmoeller@acm.org, ray.perlner@nist.gov Subject: Re: [TLS] NIST TLS recomendations In-Reply-To: <20061102072027.GA1607@tau.invalid> Message-Id: Date: Thu, 02 Nov 2006 20:52:25 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.5 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: tls@lists.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 writes: >In many situations, servers request client authentication via a certificate, >but can tolerate unauthenticated clients as well. Actually it's even more lopsided than that, in almost every case in which my code's encountered a cert request from a public server (I put in a debug check for this so I'd get feedback, see the footnote below), the server operator, when contacted, didn't care about client authentication, and in many cases both didn't know that their server was asking for client certs and had no idea how to disable it when it was. So silently failing/continuing is probably essential to allow continued operation. (My code originally bailed out with an error when a server requested a client cert and none was available, but I got lots of complaints that every other SSL implementation just continued without providing the cert, so the standard and expected behaviour seems to be to just carry on without client auth when the server asks for a cert). Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 02 03:16:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfXjO-0005Lu-CU; Thu, 02 Nov 2006 03:15:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfXjN-0005Js-HT for tls@lists.ietf.org; Thu, 02 Nov 2006 03:15:21 -0500 Received: from harpo.itss.auckland.ac.nz ([130.216.190.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfXjM-00028G-43 for tls@lists.ietf.org; Thu, 02 Nov 2006 03:15:21 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id ABCFF346DD; Thu, 2 Nov 2006 21:15:15 +1300 (NZDT) Received: from harpo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32336-11; Thu, 2 Nov 2006 21:15:15 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id 29CC43483D; Thu, 2 Nov 2006 21:15:14 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 979ED37742; Thu, 2 Nov 2006 21:15:12 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1GfXjL-0004WT-00; Thu, 02 Nov 2006 21:15:19 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: bmoeller@acm.org, jas@extundo.com Subject: Re: [TLS] Re: NIST TLS recomendations In-Reply-To: <20061102073422.GB1607@tau.invalid> Message-Id: Date: Thu, 02 Nov 2006 21:15:19 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.5 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: tls@lists.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 writes: >This is exactly right, however it certainly is reasonable to add some >language to the specification that points out that these ciphersuites should >*usually* not be enabled. Here is a proposal for A.5. Isn't this just posturing though? Since people are currently doing DH_anon via DHE, it's not going to make much difference whether DH_anon is enabled or not. Or should the text include a note to say that current practice is to do DH_anon via DHE, so enabling DH_anon isn't worth the bother and you may as well leave it disabled? (I'm not terribly fussed about this, people are going to program FORTRAN no matter what language you give them, but it'd be nice if the spec at least acknowledged current practice in order to guide both implementors and users). Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 02 03:30:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfXwl-0004hP-OZ; Thu, 02 Nov 2006 03:29:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfXwk-0004hK-L7 for tls@ietf.org; Thu, 02 Nov 2006 03:29:10 -0500 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfXwj-0004SP-7K for tls@ietf.org; Thu, 02 Nov 2006 03:29:10 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA28T70L013862 for ; Thu, 2 Nov 2006 10:29:08 +0200 Received: from esebh002.NOE.Nokia.com ([172.21.138.77]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 10:29:07 +0200 Received: from 4FIL09356 ([172.21.42.147]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 2 Nov 2006 10:29:07 +0200 From: "Pasi Eronen" To: Date: Thu, 2 Nov 2006 10:29:07 +0200 Message-ID: <000001c6fe58$f6a2a830$932a15ac@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: Acb+WPZFvz8QR3xRQhulXE1CANT5zw== X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-OriginalArrivalTime: 02 Nov 2006 08:29:08.0074 (UTC) FILETIME=[F6F92CA0:01C6FE58] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061102102908-34354BB0-5CD3A70C/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: Subject: [TLS] Extension number conflicts 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 Folks, We'd like to draw your attention to recently published RFC 4681 (TLS User Mapping Extension), which defines TLS extension number 6. Extension number 6 has been used in several Internet-Drafts over the years: we're aware of at least draft-ietf-tls-srp, early versions of draft-ietf-tls-ecc (but not RFC 4492), draft-shacham-tls-fast-track, and draft-ietf-tls-pathsec. If you have implemented any of these, we encourage you to make sure your implementation behaves nicely when contacted by RFC 4681 clients, as it's quite likely that RFC 4681 will be deployed widely. According to RFC 4366, TLS extension numbers are assigned to RFCs approved by the IESG (not Internet-Drafts that might or might not some day be approved by the IESG). There are procedures for avoiding conflicts (e.g., RFC 4020), and ad hoc techniques for making them unlikely (e.g., picking a random number). Using the next unallocated number is most likely to cause problems later on. Best regards, Pasi & Eric _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 02 03:49:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfYFL-00064k-5B; Thu, 02 Nov 2006 03:48:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfYFK-00064V-C5 for tls@lists.ietf.org; Thu, 02 Nov 2006 03:48:22 -0500 Received: from moutng.kundenserver.de ([212.227.126.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfYFH-0007cM-U4 for tls@lists.ietf.org; Thu, 02 Nov 2006 03:48:22 -0500 Received: from [80.142.173.218] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1GfYEx32LC-0006zi; Thu, 02 Nov 2006 09:48:01 +0100 Received: by tau.invalid (Postfix, from userid 1000) id 2EEFD4E39; Thu, 2 Nov 2006 09:48:02 +0100 (CET) Date: Thu, 2 Nov 2006 09:48:02 +0100 From: Bodo Moeller To: Peter Gutmann Subject: Re: [TLS] Re: NIST TLS recomendations Message-ID: <20061102084802.GA3760@tau.invalid> References: <20061102073422.GB1607@tau.invalid> 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: 52f7a77164458f8c7b36b66787c853da Cc: tls@lists.ietf.org, jas@extundo.com 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, Nov 02, 2006 at 09:15:19PM +1300, Peter Gutmann wrote: > Bodo Moeller writes: >> This is exactly right, however it certainly is reasonable to add some >> language to the specification that points out that these ciphersuites should >> *usually* not be enabled. Here is a proposal for A.5. > Isn't this just posturing though? Since people are currently doing DH_anon > via DHE, it's not going to make much difference whether DH_anon is enabled or > not. Or should the text include a note to say that current practice is to do > DH_anon via DHE, so enabling DH_anon isn't worth the bother and you may as > well leave it disabled? > > (I'm not terribly fussed about this, people are going to program FORTRAN no > matter what language you give them, but it'd be nice if the spec at least > acknowledged current practice in order to guide both implementors and users). Certainly doing "DH_anon" via DHE is currently the most frequent case of an unauthenticated handshake found in practice, and it is has some advantages over actual anonymous DH since clients can cache server certificates in sort-of SSH style. (If the client software doesn't do this automatically, you should still be able configure your preferred SMTP server's self-signed certificate into your TLS-aware SMTP client, for example.) There is some use of the actual DH_anon ciphersuites in protocols that use other means for authentication, though. Of course, those who implement these specific protocols know very well which ciphersuites they need, so they don't depend on the TLS specification explaining these issues -- it would just be weird if the TLS specification stricty forbade using these ciphersuites. Here's a new text proposal for A.5. (One additional correction here is that I replaced "TLS 1.1", which was left in place from RFC 4346, by "TLS 1.2", which is what draft-ietf-tls-rfc4346-bis-##.txt is actually about.) The following cipher suites are used for completely anonymous Diffie- Hellman communications in which neither party is authenticated. Note that this mode is vulnerable to man-in-the-middle attacks. Using this mode therefore is deprecated for most purposes: These ciphersuites MUST NOT be used by TLS 1.2 implementations unless the application layer has specifically requested to allow anonymous key exchange. (Anonymous key exchange may sometimes be acceptable, for example, to support opportunistic encryption when no set-up for authentication is in place, or when TLS is used as part of more complex security protocols that have other means to ensure authentication.) CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00, 0x18 }; CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00, 0x1A }; CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x1B }; CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x34 }; CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x3A }; Note that using non-anonymous key exchange but not verifying the certificate is essentially equivalent to anonymous key exchange, and the same precautions apply. While non-anonymous key exchange will generally involve a higher computational and communicational cost than anonymous key exchange, it may be in the interest of interoperability not to disable non-anonymous key exchange when the application layer is allowing anonymous key exchange. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 02 04:28:37 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfYno-0005px-77; Thu, 02 Nov 2006 04:24:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfYnh-0005kE-7s for tls@ietf.org; Thu, 02 Nov 2006 04:23:53 -0500 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfYhB-0005h2-O9 for tls@ietf.org; Thu, 02 Nov 2006 04:17:11 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA29H0O0002112; Thu, 2 Nov 2006 11:17:05 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 11:17:02 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 11:17:00 +0200 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: NIST TLS recomendations Date: Thu, 2 Nov 2006 11:17:01 +0200 Message-ID: In-Reply-To: <20061102073422.GB1607@tau.invalid> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Re: NIST TLS recomendations Thread-Index: Acb+U5l/RVa41OIKSz6tG4JYiSJuogACwN1Q From: To: , X-OriginalArrivalTime: 02 Nov 2006 09:17:00.0814 (UTC) FILETIME=[A74282E0:01C6FE5F] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061102111705-023EDBB0-6E2096D7/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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: > This is exactly right, however it certainly is reasonable to add some > language to the specification that points out that these ciphersuites > should *usually* not be enabled. Here is a proposal for A.5. >=20 > The following cipher suites are used for completely anonymous > Diffie- Hellman communications in which neither party is > authenticated. Note that this mode is vulnerable to > man-in-the-middle attacks. Using this mode therefore is > deprecated: These ciphersuites MUST NOT be used by TLS 1.1 > implementations unless the application layer has specifically > requested to allow anonymous key exchange. (Anonymous key > exchange may sometimes be acceptable, for example, to support > opportunistic encryption when no set-up for authentication is in > place, or when TLS is used as part of more complex security > protocols that have other means to ensure authentication.) I'm not sure if "deprecated" is the right word to use; at least to me it suggests that the feature is obsolete, and users should not expect it to be supported in the future. This is not the case here: DH_anon ciphersuites are just a feature with very special and limited use cases (that are quite different=20 from all the other ciphersuites). Thus, the requirement "MUST NOT be used ... unless the application layer has specifically requested to allow anonymous key exchange" sounds right to me. (But it should be "TLS 1.2 implementations", not 1.1 :-) Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 02 04:47:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfZ9C-00023b-28; Thu, 02 Nov 2006 04:46:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfZ9A-00022O-I6 for tls@ietf.org; Thu, 02 Nov 2006 04:46:04 -0500 Received: from moutng.kundenserver.de ([212.227.126.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfZ99-0002mf-5z for tls@ietf.org; Thu, 02 Nov 2006 04:46:04 -0500 Received: from [80.142.173.218] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1GfZ973dDV-0006up; Thu, 02 Nov 2006 10:46:02 +0100 Received: by tau.invalid (Postfix, from userid 1000) id BCA6E4E39; Thu, 2 Nov 2006 10:46:03 +0100 (CET) Date: Thu, 2 Nov 2006 10:46:03 +0100 From: Bodo Moeller To: Pasi.Eronen@nokia.com Subject: Re: [TLS] Re: NIST TLS recomendations Message-ID: <20061102094603.GA5672@tau.invalid> References: <20061102073422.GB1607@tau.invalid> 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: 9182cfff02fae4f1b6e9349e01d62f32 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 Thu, Nov 02, 2006 at 11:17:01AM +0200, Pasi.Eronen@nokia.com wrote: >> This is exactly right, however it certainly is reasonable to add some >> language to the specification that points out that these ciphersuites >> should *usually* not be enabled. Here is a proposal for A.5. >> >> The following cipher suites are used for completely anonymous >> Diffie- Hellman communications in which neither party is >> authenticated. Note that this mode is vulnerable to >> man-in-the-middle attacks. Using this mode therefore is >> deprecated: These ciphersuites MUST NOT be used by TLS 1.1 >> implementations unless the application layer has specifically >> requested to allow anonymous key exchange. [...] > I'm not sure if "deprecated" is the right word to use; at least to me > it suggests that the feature is obsolete, and users should not expect > it to be supported in the future. > > This is not the case here: DH_anon ciphersuites are just a feature > with very special and limited use cases [...] True. "Using this mode therefore is of limited use: These ciphersuites MUST NOT be used by TLS 1.2 implementations unless ..."? Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 02 04:56:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfZIx-0007Ps-Of; Thu, 02 Nov 2006 04:56:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfZIw-0007Ph-Gt for tls@lists.ietf.org; Thu, 02 Nov 2006 04:56:10 -0500 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfZIv-0004cf-2F for tls@lists.ietf.org; Thu, 02 Nov 2006 04:56:10 -0500 Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id kA29tp9j007882 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 2 Nov 2006 10:55:52 +0100 From: Simon Josefsson To: Bodo Moeller References: <7.0.1.0.2.20061101091038.0208f420@nist.gov> <87ejsnz07s.fsf@latte.josefsson.org> <20061102073422.GB1607@tau.invalid> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:061102:tls@lists.ietf.org::dWVN3ZmJyStVy85n:3tCA X-Hashcash: 1:22:061102:bmoeller@acm.org::vF1hxy6I4d2LzSER:5qIH Date: Thu, 02 Nov 2006 10:55:51 +0100 In-Reply-To: <20061102073422.GB1607@tau.invalid> (Bodo Moeller's message of "Thu\, 2 Nov 2006 08\:34\:22 +0100") Message-ID: <878xiudvfc.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: tls@lists.ietf.org Subject: [TLS] Re: NIST TLS recomendations 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 writes: >> I believe fully anonymous ciphers are a useful feature of TLS, and >> that they should stay. Client/server authentication can and do happen >> via other protocols than TLS, and those protocols can use TLS channel >> bindings to protect against man in the middle attacks, if necessary. > > This is exactly right, however it certainly is reasonable to add some > language to the specification that points out that these ciphersuites > should *usually* not be enabled. Here is a proposal for A.5. > > The following cipher suites are used for completely anonymous Diffie- > Hellman communications in which neither party is authenticated. Note > that this mode is vulnerable to man-in-the-middle attacks. Using > this mode therefore is deprecated: These ciphersuites MUST NOT be > used by TLS 1.1 implementations unless the application layer has > specifically requested to allow anonymous key exchange. (Anonymous > key exchange may sometimes be acceptable, for example, to support > opportunistic encryption when no set-up for authentication is in > place, or when TLS is used as part of more complex security > protocols that have other means to ensure authentication.) > > CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00, 0x18 }; > CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00, 0x1A }; > CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x1B }; > CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x34 }; > CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x3A }; Nice! I like the text. I think we should avoid using the word "deprecated" though. I believe there are good enough use cases to provide full support for DH_anon; opportunistic encryption is one of them. (And yes, I know that SMTP/etc typically use DHE and not DH_anon, and that is fine by me. There are other protocols than SMTP, some may need DH_anon.) I believe we should interpret "deprecated" in RFC 4346 as a "MUST NOT ... unless specifically requested", and clarify that in RFC 4346bis. The DH_anon ciphersuites have one known weakness, that is how they were designed. That is similar to NULL encryption. Both ciphersuites allows applications to use TLS to gain many of its advantages, but one feature (authentication and encryption, respectively) is disabled due to policy reasons. Neither DH_anon or NULL should be used generally, unless specifically requested by the application. How about this text: The following cipher suites are used for completely anonymous Diffie-Hellman communications in which neither party is authenticated. Note that this mode is vulnerable to man-in-the-middle attacks. These ciphersuites MUST NOT be used by TLS 1.1 implementations unless the application layer has specifically requested to allow anonymous key exchange. (Anonymous key exchange may sometimes be acceptable, for example, to support opportunistic encryption when no set-up for authentication is in place, or when TLS is used as part of more complex security protocols that have other means to ensure authentication, or when the architecture demands a fully anonymous channel.) CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00, 0x18 }; CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00, 0x1A }; CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x1B }; CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x34 }; CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x3A }; Thanks, Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 02 04:57:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfZJn-0007me-5e; Thu, 02 Nov 2006 04:57:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfZJl-0007lO-LE for tls@lists.ietf.org; Thu, 02 Nov 2006 04:57:01 -0500 Received: from mailhost.auckland.ac.nz ([130.216.190.11] helo=groucho.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfZJk-0004n2-0W for tls@lists.ietf.org; Thu, 02 Nov 2006 04:57:01 -0500 Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by groucho.itss.auckland.ac.nz (Postfix) with ESMTP id 81DF93671E; Thu, 2 Nov 2006 22:56:56 +1300 (NZDT) Received: from groucho.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07305-31; Thu, 2 Nov 2006 22:56:56 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by groucho.itss.auckland.ac.nz (Postfix) with ESMTP id 6F5683668A; Thu, 2 Nov 2006 22:56:54 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 6238D37742; Thu, 2 Nov 2006 22:56:53 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1GfZJl-0006FB-00; Thu, 02 Nov 2006 22:57:01 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: bmoeller@acm.org, pgut001@cs.auckland.ac.nz Subject: Re: [TLS] Re: NIST TLS recomendations In-Reply-To: <20061102084802.GA3760@tau.invalid> Message-Id: Date: Thu, 02 Nov 2006 22:57:01 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.5 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: tls@lists.ietf.org, jas@extundo.com 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 writes: > Note that using non-anonymous key exchange but not verifying the > certificate is essentially equivalent to anonymous key exchange, > and the same precautions apply. While non-anonymous key exchange > will generally involve a higher computational and communicational > cost than anonymous key exchange, it may be in the interest of > interoperability not to disable non-anonymous key exchange when the > application layer is allowing anonymous key exchange. OK, that gets my grunt of approval :-). However, I've just thought of another issue, is it worth noting the special case of a potential DH_anon with TLS- PSK? Currently there are no DH_anon_PSK suites defined, but it would seem that one of the goals of TLS-PSK (operation on low-powered devices) would be met by DH_anon_PSK, since the PSK avoids the need for the unnecessary cert verification. So maybe the text could include an additional note, something like "In some cases additional authentication mechanisms like TLS-PSK may obviate the need for conventional authenticated DH, since mutual authentication is being provided by the use of TLS-PSK alongside the DH exchange. In other words even though a DH_anon_PSK suite would contain the term 'anon', it's not really anonymous DH" (the same obviously goes for other auth.mechanisms added to "anonymous" DH like SRP). Alternatively, maybe DH_anon needs a special name when used with TLS-PSK, something like "DH_PSK" without the "anon" bit. This follows the pattern set by TLS-SRP, which uses "TLS_SRP_..." even though, in conventional TLS terms, what it's doing is TLS_DH_anon for those SRP suites that don't use server certs. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 02 05:30:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfZpf-00049M-2N; Thu, 02 Nov 2006 05:29:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfZpe-00048t-0H for tls@lists.ietf.org; Thu, 02 Nov 2006 05:29:58 -0500 Received: from moutng.kundenserver.de ([212.227.126.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfZpc-0002XH-KJ for tls@lists.ietf.org; Thu, 02 Nov 2006 05:29:57 -0500 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1GfZpZ1UpE-0006wH; Thu, 02 Nov 2006 11:29:55 +0100 Received: by tau.invalid (Postfix, from userid 1000) id D273A4DEB; Thu, 2 Nov 2006 11:29:52 +0100 (CET) Date: Thu, 2 Nov 2006 11:29:52 +0100 From: Bodo Moeller To: Peter Gutmann Subject: Re: [TLS] Re: NIST TLS recomendations Message-ID: <20061102102951.GA9539@tau.invalid> References: <20061102084802.GA3760@tau.invalid> 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: 93238566e09e6e262849b4f805833007 Cc: tls@lists.ietf.org, jas@extundo.com 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, Nov 02, 2006 at 10:57:01PM +1300, Peter Gutmann wrote: > Bodo Moeller writes: >> Note that using non-anonymous key exchange but not verifying the >> certificate is essentially equivalent to anonymous key exchange, >> and the same precautions apply. While non-anonymous key exchange >> will generally involve a higher computational and communicational >> cost than anonymous key exchange, it may be in the interest of >> interoperability not to disable non-anonymous key exchange when the >> application layer is allowing anonymous key exchange. > OK, that gets my grunt of approval :-). However, I've just thought of another > issue, is it worth noting the special case of a potential DH_anon with TLS- > PSK? Currently there are no DH_anon_PSK suites defined, but it would seem > that one of the goals of TLS-PSK (operation on low-powered devices) would be > met by DH_anon_PSK, since the PSK avoids the need for the unnecessary cert > verification. [...] Hm, aren't you just describing the DHE_PSK ciphersuites from RFC 4279? If they are different from what you are thinking of, what is the difference? Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 02 05:34:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfZta-0005Fh-7u; Thu, 02 Nov 2006 05:34:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GfZtZ-0005FY-7i for tls@ietf.org; Thu, 02 Nov 2006 05:34:01 -0500 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GfZtX-0003Jb-Qc for tls@ietf.org; Thu, 02 Nov 2006 05:34:01 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kA2AXkoq003383; Thu, 2 Nov 2006 12:33:53 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 12:33:52 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Nov 2006 12:33:52 +0200 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: NIST TLS recomendations Date: Thu, 2 Nov 2006 12:33:54 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Re: NIST TLS recomendations Thread-Index: Acb+ZYph991LwMm+T7ih/q7JT40K8QABH92A From: To: , X-OriginalArrivalTime: 02 Nov 2006 10:33:52.0463 (UTC) FILETIME=[64044DF0:01C6FE6A] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 Peter Gutmann wrote: > However, I've just thought of another issue, is it worth noting the > special case of a potential DH_anon with TLS- PSK? Currently there > are no DH_anon_PSK suites defined, but it would seem that one of the > goals of TLS-PSK (operation on low-powered devices) would be met by > DH_anon_PSK, since the PSK avoids the need for the unnecessary cert > verification. RFC 4279 does have "DHE_PSK" suites (Diffie-Hellman authenticated=20 with a PSK; nothing anonymous there). Is this what you meant by DH_anon_PSK, or something else? Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Nov 03 15:28:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg5bl-0006Xz-Sa; Fri, 03 Nov 2006 15:25:45 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg5bk-0006XN-9h; Fri, 03 Nov 2006 15:25:44 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg5bh-0005AG-SI; Fri, 03 Nov 2006 15:25:44 -0500 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id VAA11519; Fri, 3 Nov 2006 21:25:38 +0100 (MEZ) From: Martin Rex Message-Id: <200611032025.VAA17840@uw1048.wdf.sap.corp> Subject: Re: [TLS] DTLS and GSS-API To: hartmans-ietf@mit.edu (Sam Hartman) Date: Fri, 3 Nov 2006 21:25:38 +0100 (MET) In-Reply-To: from "Sam Hartman" at Oct 31, 6 12:08:25 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: 082a9cbf4d599f360ac7f815372a6a15 Cc: tls@ietf.org, spkm@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 Sam Hartman wrote: > > Monday morning at IETF 67 there is a really important BOF: SPKM. > > The purpose of this BOF is to decide how we will get a standards track > solution for NFSV4 to use PKI credentials. Two modes are important: a > mode where both parties have credentials and a mode where the server > has a certificate and the client has a password. > > The current proposal is based off draft-adamson-rfc2847-01.txt. > Several reviewers including Eric Rescorla and myself have expressed > concerns about this draft. I noticed Erics comments about the crypto algorithms, how they're enumerated and combined. Without checking the details, I believe this stuff is more-or-less a straight copy from the original SPKM spec (rfc-2025), not a conscious selection of the current document author, and a result of trying to remain backwards compatible as much as possible, and not because it is any useful. > > > An alternate proposal for solving this problem was discussed in the > past: construct a GSS-API mechanism based on DTLS. Advantages of this > solution include reuse of code and specification between GSS-API and > TLS implementations. When new ciphers are specified for TLS they > would be available for NFS. We would not need to keep updating a GSS > mechanism as public-key algorithms evolve and problems are found. > > There are two main drawbacks I've heard to the DTLS proposal. First, > we don't have a draft. Second, it would not be interoperable with > SPKM-3 deployments. There is a substantial difference between GSS-API and TLS which should not be ignored: In the GSS-API architecture, context level tokens (which exchange cryptographic material and perform the authentication) can only be exchanged at the beginning. After a security context has been established, the message flow depends entirely on the communication characteristics of the application, and may be entirey uni-directional and may preclude even alien attempts of a gssapi mechanism to piggy-back context-token on protected message tokens. With TLS, on the other hand, each of the communication peers may request a renegotiation of context parameters at (almost) any time during the communication. A GSS-API mechanism built on TLS should not attempt to piggy-back any additional information on protected message tokens (and make assumptions about the communcation characteritics of the application caller). Some applications will break when the message protection token size (get_mic) or the message size increase (wrap) increases considerably in order to accomodate piggy-backed context-update. Some GSS-API applications may not be able to cope with it -- the message protection overhead is expected to be fairly low in GSS-API, and applications have been encouraged to squeeze tighltly with the introduction of "gss_wrap_size_limit()" in GSS-API v2. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Nov 03 19:23:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg9IN-0004BP-MT; Fri, 03 Nov 2006 19:21:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gg9IN-0004Am-2t for tls@ietf.org; Fri, 03 Nov 2006 19:21:59 -0500 Received: from mailhost.auckland.ac.nz ([130.216.190.12] helo=chico.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gg9IL-0001tD-Ly for tls@ietf.org; Fri, 03 Nov 2006 19:21:59 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by chico.itss.auckland.ac.nz (Postfix) with ESMTP id BC2E1355B9; Sat, 4 Nov 2006 13:21:52 +1300 (NZDT) Received: from chico.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29672-23; Sat, 4 Nov 2006 13:21:52 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by chico.itss.auckland.ac.nz (Postfix) with ESMTP id 6B8CA35447; Sat, 4 Nov 2006 13:21:52 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id CD2C737742; Sat, 4 Nov 2006 13:21:51 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1Gg9IJ-0003hr-00; Sat, 04 Nov 2006 13:21:55 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Pasi.Eronen@nokia.com, pgut001@cs.auckland.ac.nz, tls@ietf.org Subject: RE: [TLS] Re: NIST TLS recomendations In-Reply-To: Message-Id: Date: Sat, 04 Nov 2006 13:21:55 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.5 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 writes: >RFC 4279 does have "DHE_PSK" suites (Diffie-Hellman authenticated with a PSK; >nothing anonymous there). Is this what you meant by DH_anon_PSK, or something >else? Sort of. It's a naming problem, the main TLS spec uses 'DH_anon' to mean 'key exchange without certificates', while the TLS-PSK spec uses 'DHE_PSK' to mean 'key exchange without certificates (but with mutual authentication via PSK)' (re-reading my earlier posting, I was pretty unclear on this :-). My concern was that phrasing the authentication check purely as "verifying the certificate" (as in, for example, Bodo's suggested text) would cause problems if that were taken to apply to the PSK suites (and SRP and others) where there's no certificate to verify. Perhaps the "verifying the certificate" could be generalised to something like "authenticating the key exchange, for example by verifying the certificate". As the text currently only applies to DH_anon it's not a problem, but if there's ever any scope creep (the text gets applied elsewhere, copied into the security considerations section, ...) it's going to conflict with SRP, PSK, and other non-certificate based authentication mechanisms. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Nov 04 02:04:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgFYr-0000so-CA; Sat, 04 Nov 2006 02:03:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgFYq-0000sg-AO for tls@ietf.org; Sat, 04 Nov 2006 02:03:24 -0500 Received: from moutng.kundenserver.de ([212.227.126.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgFYo-0007HF-Tc for tls@ietf.org; Sat, 04 Nov 2006 02:03:24 -0500 Received: from [80.142.131.106] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis), id 0MKxQS-1GgFYm0utL-0004Z2; Sat, 04 Nov 2006 08:03:21 +0100 Received: by tau.invalid (Postfix, from userid 1000) id A13354DFF; Sat, 4 Nov 2006 08:03:18 +0100 (CET) Date: Sat, 4 Nov 2006 08:03:18 +0100 From: Bodo Moeller To: Peter Gutmann Subject: Re: [TLS] Re: NIST TLS recomendations Message-ID: <20061104070318.GA26795@tau.invalid> 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: cab78e1e39c4b328567edb48482b6a69 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, Nov 04, 2006 at 01:21:55PM +1300, Peter Gutmann wrote: > writes: >> RFC 4279 does have "DHE_PSK" suites (Diffie-Hellman authenticated with a PSK; >> nothing anonymous there). Is this what you meant by DH_anon_PSK, or something >> else? > Sort of. It's a naming problem, the main TLS spec uses 'DH_anon' to mean 'key > exchange without certificates', while the TLS-PSK spec uses 'DHE_PSK' to mean > 'key exchange without certificates (but with mutual authentication via PSK)' > (re-reading my earlier posting, I was pretty unclear on this :-). My concern > was that phrasing the authentication check purely as "verifying the > certificate" (as in, for example, Bodo's suggested text) would cause problems > if that were taken to apply to the PSK suites (and SRP and others) where > there's no certificate to verify. [...] So here's an updated proposal. This avoids the word "deprecated" (as by Pasi's and Simon's earlier remarks), and avoids the word "certificate": The following cipher suites are used for completely anonymous Diffie- Hellman communications in which neither party is authenticated. Note that this mode is vulnerable to man-in-the-middle attacks. Using this mode therefore is of limited use: These ciphersuites MUST NOT be used by TLS 1.2 implementations unless the application layer has specifically requested to allow anonymous key exchange. (Anonymous key exchange may sometimes be acceptable, for example, to support opportunistic encryption when no set-up for authentication is in place, or when TLS is used as part of more complex security protocols that have other means to ensure authentication.) CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00, 0x18 }; CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00, 0x1A }; CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x1B }; CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x34 }; CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x3A }; Note that using non-anonymous key exchange without actually verifying the key exchange is essentially equivalent to anonymous key exchange, and the same precautions apply. While non-anonymous key exchange will generally involve a higher computational and communicational cost than anonymous key exchange, it may be in the interest of interoperability not to disable non-anonymous key exchange when the application layer is allowing anonymous key exchange. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Nov 04 04:26:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgHkn-0005V1-L2; Sat, 04 Nov 2006 04:23:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgHkm-0005Uv-S8 for tls@ietf.org; Sat, 04 Nov 2006 04:23:52 -0500 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgHkl-00056O-EI for tls@ietf.org; Sat, 04 Nov 2006 04:23:52 -0500 Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id kA49NSfa029459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 4 Nov 2006 10:23:29 +0100 From: Simon Josefsson To: Bodo Moeller References: <20061104070318.GA26795@tau.invalid> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:061104:pgut001@cs.auckland.ac.nz::WVPdVt+ucsrtyeXl:6GJJ X-Hashcash: 1:22:061104:bmoeller@acm.org::lHBozDWrn/quSAya:SHkM X-Hashcash: 1:22:061104:tls@ietf.org::4O7aBsUfzCPaxyUZ:ib4f Date: Sat, 04 Nov 2006 10:23:28 +0100 In-Reply-To: <20061104070318.GA26795@tau.invalid> (Bodo Moeller's message of "Sat\, 4 Nov 2006 08\:03\:18 +0100") Message-ID: <87u01fimzz.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.4 required=4.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: tls@ietf.org Subject: [TLS] Re: NIST TLS recomendations 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 writes: > So here's an updated proposal. This avoids the word "deprecated" (as by > Pasi's and Simon's earlier remarks), and avoids the word "certificate": > > The following cipher suites are used for completely anonymous Diffie- > Hellman communications in which neither party is authenticated. Note > that this mode is vulnerable to man-in-the-middle attacks. Using > this mode therefore is of limited use: These ciphersuites MUST NOT be > used by TLS 1.2 implementations unless the application layer has > specifically requested to allow anonymous key exchange. (Anonymous > key exchange may sometimes be acceptable, for example, to support > opportunistic encryption when no set-up for authentication is in > place, or when TLS is used as part of more complex security protocols > that have other means to ensure authentication.) > > CipherSuite TLS_DH_anon_WITH_RC4_128_MD5 = { 0x00, 0x18 }; > CipherSuite TLS_DH_anon_WITH_DES_CBC_SHA = { 0x00, 0x1A }; > CipherSuite TLS_DH_anon_WITH_3DES_EDE_CBC_SHA = { 0x00, 0x1B }; > CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x34 }; > CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x3A }; > > Note that using non-anonymous key exchange without actually verifying > the key exchange is essentially equivalent to anonymous key exchange, > and the same precautions apply. While non-anonymous key exchange > will generally involve a higher computational and communicational > cost than anonymous key exchange, it may be in the interest of > interoperability not to disable non-anonymous key exchange when the > application layer is allowing anonymous key exchange. This looks fine! Thanks, Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Nov 05 05:53:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggfad-0000bJ-KU; Sun, 05 Nov 2006 05:50:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggfac-0000ae-TE for tls@ietf.org; Sun, 05 Nov 2006 05:50:58 -0500 Received: from mailhost.auckland.ac.nz ([130.216.190.12] helo=chico.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgfXL-000234-IQ for tls@ietf.org; Sun, 05 Nov 2006 05:47:36 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by chico.itss.auckland.ac.nz (Postfix) with ESMTP id A1AE835D2A; Sun, 5 Nov 2006 23:47:30 +1300 (NZDT) Received: from chico.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpb.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 28737-17; Sun, 5 Nov 2006 23:47:30 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by chico.itss.auckland.ac.nz (Postfix) with ESMTP id 22A8835CB5; Sun, 5 Nov 2006 23:47:29 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 5B1C337742; Sun, 5 Nov 2006 23:47:29 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1GgfXN-0004v6-00; Sun, 05 Nov 2006 23:47:37 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: bmoeller@acm.org, pgut001@cs.auckland.ac.nz Subject: Re: [TLS] Re: NIST TLS recomendations In-Reply-To: <20061104070318.GA26795@tau.invalid> Message-Id: Date: Sun, 05 Nov 2006 23:47:37 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.5 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed 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 writes: >So here's an updated proposal. Looks fine. I'll shut up now :-). Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Nov 05 14:44:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ggnsa-0007vI-Ai; Sun, 05 Nov 2006 14:42:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GgnsY-0007v0-Ld; Sun, 05 Nov 2006 14:42:02 -0500 Received: from [130.129.68.116] (helo=carter-zimmerman.mit.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GgnsX-0006r9-BZ; Sun, 05 Nov 2006 14:42:02 -0500 Received: by carter-zimmerman.mit.edu (Postfix, from userid 8042) id 20EE6E0038; Sun, 5 Nov 2006 14:41:53 -0500 (EST) From: Sam Hartman To: martin.rex@sap.com Subject: Re: [SPKM] Re: [TLS] DTLS and GSS-API References: <200611032025.VAA17840@uw1048.wdf.sap.corp> Date: Sun, 05 Nov 2006 14:41:53 -0500 In-Reply-To: <200611032025.VAA17840@uw1048.wdf.sap.corp> (Martin Rex's message of "Fri, 3 Nov 2006 21:25:38 +0100 (MET)") Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: tls@ietf.org, spkm@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" == Martin Rex writes: >> >> An alternate proposal for solving this problem was discussed in >> the past: construct a GSS-API mechanism based on DTLS. >> Advantages of this solution include reuse of code and >> specification between GSS-API and TLS implementations. When >> new ciphers are specified for TLS they would be available for >> NFS. We would not need to keep updating a GSS mechanism as >> public-key algorithms evolve and problems are found. >> >> There are two main drawbacks I've heard to the DTLS proposal. >> First, we don't have a draft. Second, it would not be >> interoperable with SPKM-3 deployments. Martin> There is a substantial difference between GSS-API and TLS Martin> which should not be ignored: In the GSS-API architecture, Martin> context level tokens (which exchange cryptographic Martin> material and perform the authentication) can only be Martin> exchanged at the beginning. Martin> After a security context has been established, the message Martin> flow depends entirely on the communication characteristics Martin> of the application, and may be entirey uni-directional and Martin> may preclude even alien attempts of a gssapi mechanism to Martin> piggy-back context-token on protected message tokens. Martin> With TLS, on the other hand, each of the communication Martin> peers may request a renegotiation of context parameters at Martin> (almost) any time during the communication. I talked to Eric about this in another context. He claimed that as a practical matter it does not work if animplementation does a new handshake without the cooperation of the upper-layer application. You are correct though that a DTLS GSS-API mechanism could only be specified on the standards track if this issue were dealt with in some manner that preserved the GSS-API model. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 06 03:54:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh0DC-0001DR-MK; Mon, 06 Nov 2006 03:52:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh0D7-00019b-3F for tls@ietf.org; Mon, 06 Nov 2006 03:52:05 -0500 Received: from mail-eur1.microsoft.com ([213.199.128.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh0C8-0006pp-5w for tls@ietf.org; Mon, 06 Nov 2006 03:51:05 -0500 Received: from EUR-MSG-11.europe.corp.microsoft.com ([65.53.193.197]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 08:51:03 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 6 Nov 2006 08:51:03 -0000 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: SPNEGO over TLS - proposed new work item Thread-Index: Acb0NfY2VZEG8LSATlWaMk+pSbI75wNEo2MQ References: <000001c6f37f$bece5ff0$932a15ac@NOE.Nokia.com> From: "Stefan Santesson" To: "tls mailing list" X-OriginalArrivalTime: 06 Nov 2006 08:51:03.0237 (UTC) FILETIME=[B0861F50:01C70180] X-Spam-Score: 0.0 (/) X-Scan-Signature: f9c0d585568a86447c98453afdf94aa0 Cc: Subject: [TLS] SPNEGO over TLS - proposed new work item 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="===============1879248861==" Errors-To: tls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1879248861== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C70180.B06BFBF6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C70180.B06BFBF6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 I would like the TLS group to consider a new work to provide a framework for GSS-API based authentication and key establishing methods. I have requested a spot at the TLS meeting to discuss this. =20 In Microsoft we have investigated many ways to use Kerberos as means of client authentication and key establishment over TLS but the task offers several challenges that current specification does not solve. =20 The most important challenge is to allow a full Kerberos negotiation including initial AS-request to the KDC server when the client resides outside the local network of the KDC server.=20 =20 The proposal is to provide a generic and transparent solution by enabling SPNEGO (RFC 4178) within a TLS handshake.=20 =20 The advantage of allowing SPNEGO under TLS is that it provides a lot of flexibility as new mechanisms can be added under SPNEGO (e.g., WS security), given the reliance on the SPNEGO for auth package negotiation, without further amendments to TLS. =20 Deliverables and highlights: - Define new ciphersuites that use SPNEGO for key exchange=20 - Define new TLS client/server extension for agreement upon which SPNEGO mechanism to use (e.g. Kerberos)=20 - The server always sends its certificate=20 - The server never sends certificate request message=20 - The client never sends its certificate=20 - ClientKeyExchange message: After GSS initialize Security context call is done, the client calls GSS encrypt message to encrypt the premaster secret. NOTE: the ClientKeyExchange is always protected under the public key obtained from the Server cert.=20 - Ideally use Supplementary data messages to carry gss payloads =20 =20 Outline: =20 Client Server =20 ClientHello /* CipherSuite: SPNEGO_AES_SHA256,... Extensions SPNEGO (Kerb,WS-Sec,NTLM,..) */ -----> =20 ServerHello /* CipherSuite: SPNEGO_AES_SHA256 Extensions SPNEGO (Kerb) */ Certificate <-------- ServerHelloDone =20 <--------- SupplementalData --------> /* multiple iterations with SPNEGO payload */ =20 ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data =20 Challenges: =20 The SPNEGO negotiation does not have a predefined number of iterations. This exchange of messages has to be allowed go on until finished. Conventions need to be defined for how to detect completion as well as success and failure of this negotiation. =20 Ideally we would use the Supplemental data handshake message to carry the SPNEGO payloads. However, it must be determined that it is allowed. =20 =20 Alternative solutions considered: =20 As alternative solutions to this proposal we have considered defining Kerberos specific payloads for transport in TLS extensions and handshake messages as well as basing a solution on TLS PSK.=20 =20 The name field in TLS PSK could contain a Kerberos ticket, but it would not provide the necessary means to provide an initial AS-request. The AS-request has a need for protection which has to be provided by the TLS handshake, possibly through double handshake. Such solution is not very generic and double handshake is not always usable in environments where this could be used, especially in high latency networks. =20 In the end, no alternatives considered have in our view been able to provide a clean and generic solution. =20 =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards ------_=_NextPart_001_01C70180.B06BFBF6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

I would like the TLS group to consider a new work to provide a framework = for GSS-API based authentication and key establishing methods. I have = requested a spot at the TLS meeting to discuss this.

 

In Microsoft we have investigated many ways to use Kerberos as means of = client authentication and key establishment over TLS but the task offers = several challenges that current specification does not = solve.

 

The most important challenge is to allow a full Kerberos negotiation = including initial AS-request to the KDC server when the client resides outside the = local network of the KDC server.

 

The proposal is to provide a generic and transparent solution by enabling = SPNEGO (RFC 4178) within a TLS handshake.

 

The advantage of allowing SPNEGO under TLS is that it provides a lot of = flexibility as new mechanisms can be added under SPNEGO (e.g., WS security), given = the reliance on the SPNEGO for auth package negotiation, without further = amendments to TLS.

 

Deliverables and highlights:

  - Define new ciphersuites that use SPNEGO for key exchange =

  - Define new TLS client/server extension for agreement = upon

    which SPNEGO mechanism to use (e.g. Kerberos)

  - The server always sends its certificate

  - The server never sends certificate request message =

  - The client never sends its certificate

  - ClientKeyExchange message: After GSS initialize Security

    context call is done, the client calls GSS encrypt = message

    to encrypt the premaster secret. NOTE: the = ClientKeyExchange

    is always protected under the public key obtained from = the

    Server cert.

  - Ideally use Supplementary data messages to carry gss = payloads

 

 

Outline:

 

   Client            =             &= nbsp;           &n= bsp;          Server

 

      ClientHello

       /* CipherSuite: SPNEGO_AES_SHA256,...

          Extensions SPNEGO (Kerb,WS-Sec,NTLM,..) */ = ----->

 

           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      ServerHello

           &= nbsp;                    /* CipherSuite: SPNEGO_AES_SHA256

           &= nbsp;           &n= bsp;           &nb= sp;  Extensions SPNEGO (Kerb) */

           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      Certificate

           &= nbsp;           &n= bsp;           &nb= sp; <--------    ServerHelloDone

 

            <---------   SupplementalData  = -------->

          /* multiple iterations with SPNEGO payload = */

 

      ClientKeyExchange

      CertificateVerify*

      [ChangeCipherSpec]

      Finished           = ;          -------->

           &= nbsp;           &n= bsp;           &nb= sp;           [ChangeCipherSpec]

           &= nbsp;           &n= bsp;           <--------          &= nbsp;  Finished

      Application Data           &nb= sp; <------->     Application = Data

 

Challenges:

 

The SPNEGO negotiation does not have a predefined number of iterations. This exchange of messages has to be allowed go on until finished. Conventions = need to be defined for how to detect completion as well as success and = failure of this negotiation.

 

Ideally we would use the Supplemental data handshake message to carry the SPNEGO payloads. However, it must be determined that it is = allowed.

 

 

Alternative solutions considered:

 

As alternative solutions to this proposal we have considered defining = Kerberos specific payloads for transport in TLS extensions and handshake messages = as well as basing a solution on TLS PSK.

 

The name field in TLS PSK could contain a Kerberos ticket, but it would not = provide the necessary means to provide an initial AS-request. The AS-request has = a need for protection which has to be provided by the TLS handshake, possibly = through double handshake. Such solution is not very generic and double handshake = is not always usable in environments where this could be used, especially in = high latency networks.

 

In the end, no alternatives considered have in our view been able to = provide a clean and generic solution.

 

 

 

Stefan Santesson

Senior Program Manager

Windows Security, = Standards

------_=_NextPart_001_01C70180.B06BFBF6-- --===============1879248861== 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 --===============1879248861==-- From tls-bounces@lists.ietf.org Mon Nov 06 10:09:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh64P-0007hW-1R; Mon, 06 Nov 2006 10:07:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh64M-0007fh-RK for tls@ietf.org; Mon, 06 Nov 2006 10:07:26 -0500 Received: from edelweb.fr ([212.234.46.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh64D-00052v-Tp for tls@ietf.org; Mon, 06 Nov 2006 10:07:26 -0500 Received: from [193.51.14.5] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id kA6F7A523706 for ; Mon, 6 Nov 2006 16:07:10 +0100 (MET) Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by edelweb.fr (nospam/2.4); Mon, 6 Nov 2006 16:07:10 +0100 (MET) Message-ID: <454F4F29.1030601@edelweb.fr> Date: Mon, 06 Nov 2006 16:05:13 +0100 From: Peter Sylvester User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: tls@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 Cc: Subject: [TLS] TLS and SRP 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="===============1402538473==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============1402538473== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms080509000308070503020209" This is a cryptographically signed message in MIME format. --------------ms080509000308070503020209 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Hi, What is actual status of treating the SRP-TLS specification in this working group? As far as I remember, several implementers have requested that the text gets treated by the working group. I don't recall any reaction of the chairman. Thanks in advance for consideration. -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. --------------ms080509000308070503020209 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8 1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5 V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9 F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+ udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2 mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4 88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8 oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMTA2MTUwNTEzWjAjBgkqhkiG9w0B CQQxFgQU3o7byyQ3ZP1MJKqPTX/sHkpf1AgwUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAXfLVFVlO12DlWEOb gOesNC84/CCWLvbCsy7HM2Dz/1ltO2FSYUldkc2Gl16hSEtyIGSbat0iRQ1Wf8BthTz72XlI ujnKhp419GrEhLdaoeUWmOQhhG/jg9kNhv5f5+eBsUooFEigN7ofzGvQTbn7tUIE+8WJ8cH9 uMwSADRVpRcAAAAAAAA= --------------ms080509000308070503020209-- --===============1402538473== 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 --===============1402538473==-- From tls-bounces@lists.ietf.org Mon Nov 06 10:19:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh6Er-00036L-Br; Mon, 06 Nov 2006 10:18:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh6Eq-000363-Gh for tls@ietf.org; Mon, 06 Nov 2006 10:18:16 -0500 Received: from dhcp67-127.ietf67.org ([130.129.67.127] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh6Ee-0006QE-Ct for tls@ietf.org; Mon, 06 Nov 2006 10:18:16 -0500 Received: by delta.rtfm.com (Postfix, from userid 1001) id C3DD41CC61; Mon, 6 Nov 2006 07:17:48 -0800 (PST) To: Peter Sylvester Subject: Re: [TLS] TLS and SRP References: <454F4F29.1030601@edelweb.fr> From: EKR Date: Mon, 06 Nov 2006 07:17:48 -0800 In-Reply-To: <454F4F29.1030601@edelweb.fr> (Peter Sylvester's message of "Mon, 06 Nov 2006 16:05:13 +0100") Message-ID: <86d580li3n.fsf@delta.rtfm.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.1 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 Peter Sylvester writes: > Hi, > > What is actual status of treating the SRP-TLS specification in this > working group? > As far as I remember, several implementers have requested that the > text gets treated > by the working group. I don't recall any reaction of the chairman. > > Thanks in advance for consideration. The chairs have sent a number of commentsto the authors about the architectural approach taken in the draft. As far as I know they're still thinking about it. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 06 10:43:21 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh6cT-0001Cl-RW; Mon, 06 Nov 2006 10:42:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh6cS-0001CW-Kf for tls@ietf.org; Mon, 06 Nov 2006 10:42:40 -0500 Received: from bay0-omc3-s29.bay0.hotmail.com ([65.54.246.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh6cH-0001lJ-Lq for tls@ietf.org; Mon, 06 Nov 2006 10:42:40 -0500 Received: from BAY103-W3 ([65.54.174.103]) by bay0-omc3-s29.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 07:42:29 -0800 X-Originating-IP: [69.229.212.40] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Stefan Santesson , tls mailing list Subject: RE: [TLS] SPNEGO over TLS - proposed new work item Date: Mon, 6 Nov 2006 07:42:29 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 06 Nov 2006 15:42:29.0423 (UTC) FILETIME=[2AA32BF0:01C701BA] X-Spam-Score: 2.1 (++) X-Scan-Signature: 00134749b78ab2213964fc53d03de937 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="===============0822152688==" Errors-To: tls-bounces@lists.ietf.org --===============0822152688== Content-Type: multipart/alternative; boundary="_3623806d-8ce2-4a21-95a3-5c63f60ff54c_" --_3623806d-8ce2-4a21-95a3-5c63f60ff54c_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don't thing this is the right architecture for the worldwide internet: pu= tting the ws-security (i.e. ws-conversation) handshakes (a SPNEGO profile) = into the TLS message handling layer. The right place for ws-conversation is= in the http redirect/post handlers, where one can hook arbitrary levels of= security protocol engines above the http messaging layer (as SAML2 has sho= wn the world, so effectively, standardizing over 11 security state machines= that accomplish everything the SSL ever did). Id agree that most of the ha= ndshake mechanisms that TLS 1.x standardizes can then simply be re-written = as ws-conversation flows, and that is the proper architectural relationship= between we-security and TLS. WS-conversation flows can of course add more = security semantics than TLS can ever accomplish by its linkage to TCP/IP, b= eing able to orchestrate store-and forward security protocols.One can easil= y imagine now an httpws:// that properly orchestrates what role a reliable = transport channel such as TLS plays when supporting ws-conversation flows a= t the http layer, much like https orchestrated how hypermedia multiplexing,= certificates and website naming at the http layer interplayed with SSL pro= tocol engines. SO, it should be SPNEGO OVER TLS, not SPNEGO in TLS. Date: Mon, 6 Nov 2006 08:51:03 +0000From: stefans@microsoft.comTo: tls@ietf= .orgCC: Subject: [TLS] SPNEGO over TLS - proposed new work item =20 I would like the TLS group to consider a new work to provide a framework fo= r GSS-API based authentication and key establishing methods. I have request= ed a spot at the TLS meeting to discuss this. =20 In Microsoft we have investigated many ways to use Kerberos as means of cli= ent authentication and key establishment over TLS but the task offers sever= al challenges that current specification does not solve. =20 The most important challenge is to allow a full Kerberos negotiation includ= ing initial AS-request to the KDC server when the client resides outside th= e local network of the KDC server.=20 =20 The proposal is to provide a generic and transparent solution by enabling S= PNEGO (RFC 4178) within a TLS handshake.=20 =20 The advantage of allowing SPNEGO under TLS is that it provides a lot of fle= xibility as new mechanisms can be added under SPNEGO (e.g., WS security), g= iven the reliance on the SPNEGO for auth package negotiation, without furth= er amendments to TLS. =20 Deliverables and highlights: - Define new ciphersuites that use SPNEGO for key exchange=20 - Define new TLS client/server extension for agreement upon which SPNEGO mechanism to use (e.g. Kerberos)=20 - The server always sends its certificate=20 - The server never sends certificate request message=20 - The client never sends its certificate=20 - ClientKeyExchange message: After GSS initialize Security context call is done, the client calls GSS encrypt message to encrypt the premaster secret. NOTE: the ClientKeyExchange is always protected under the public key obtained from the Server cert.=20 - Ideally use Supplementary data messages to carry gss payloads =20 =20 Outline: =20 Client Server =20 ClientHello /* CipherSuite: SPNEGO_AES_SHA256,... Extensions SPNEGO (Kerb,WS-Sec,NTLM,..) */ -----> =20 ServerHello /* CipherSuite: SPNEGO_AES_SHA256 Extensions SPNEGO (Kerb) */ Certificate <-------- ServerHelloDone =20 <--------- SupplementalData --------> /* multiple iterations with SPNEGO payload */ =20 ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data =20 Challenges: =20 The SPNEGO negotiation does not have a predefined number of iterations. Thi= s exchange of messages has to be allowed go on until finished. Conventions = need to be defined for how to detect completion as well as success and fail= ure of this negotiation. =20 Ideally we would use the Supplemental data handshake message to carry the S= PNEGO payloads. However, it must be determined that it is allowed. =20 =20 Alternative solutions considered: =20 As alternative solutions to this proposal we have considered defining Kerbe= ros specific payloads for transport in TLS extensions and handshake message= s as well as basing a solution on TLS PSK.=20 =20 The name field in TLS PSK could contain a Kerberos ticket, but it would not= provide the necessary means to provide an initial AS-request. The AS-reque= st has a need for protection which has to be provided by the TLS handshake,= possibly through double handshake. Such solution is not very generic and d= ouble handshake is not always usable in environments where this could be us= ed, especially in high latency networks. =20 In the end, no alternatives considered have in our view been able to provid= e a clean and generic solution. =20 =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards _________________________________________________________________ Check the weather nationwide with MSN Search: Try it now! http://search.msn.com/results.aspx?q=3Dweather&FORM=3DWLMTAG= --_3623806d-8ce2-4a21-95a3-5c63f60ff54c_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don't thing this is the right architecture for the worldwide intern= et: putting the ws-security (i.e. ws-conversation) handshakes (a SPNEGO pro= file) into the TLS message handling layer. The right place for ws-conversat= ion is in the http redirect/post handlers, where one can hook arbitrary lev= els of security protocol engines above the http messaging layer (as SAML2 h= as shown the world, so effectively, standardizing over 11 security state ma= chines that accomplish everything the SSL ever did). Id agree that most of = the handshake mechanisms that TLS 1.x standardizes can then simply be re-wr= itten as ws-conversation flows, and that is the proper architectural relati= onship between we-security and TLS. WS-conversation flows can of course add= more security semantics than TLS can ever accomplish by its linkage to TCP= /IP, being able to orchestrate store-and forward security protocols.
One can easily imagine now an httpws:// that properly orchestrates what ro= le a reliable transport channel such as TLS plays when supporting ws-conver= sation flows at the http layer, much like https orchestrated how hypermedia= multiplexing, certificates and website naming at the http layer interplaye= d with SSL protocol engines.

SO, it should be SPNEGO OVER TLS, not SPNEGO in TLS.

Date: Mon, 6 Nov 2006 08:51:03 +0000
From: stefans@microsoft.com
To: = tls@ietf.org
CC:
Subject: [TLS] SPNEGO over TLS - proposed new work = item

 =

I would like the TLS group to consider a new work to = provide a framework for GSS-API based authentication and key establishing m= ethods. I have requested a spot at the TLS meeting to discuss this.<= /P>

 

In Microsoft we have investigated many ways to use Ke= rberos as means of client authentication and key establishment over TLS but= the task offers several challenges that current specification does not sol= ve.

 

The most important challenge is to allow a full Kerbe= ros negotiation including initial AS-request to the KDC server when the cli= ent resides outside the local network of the KDC server.

 

The proposal is to provide a generic and transparent = solution by enabling SPNEGO (RFC 4178) within a TLS handshake.

 

The advantage of allowing SPNEGO under TLS is that it= provides a lot of flexibility as new mechanisms can be added under SPNEGO = (e.g., WS security), given the reliance on the SPNEGO for auth package nego= tiation, without further amendments to TLS.

 

Deliverables and highlights:

  - Define new ciphersuites that use SPNEGO for = key exchange

  - Define new TLS client/server extension for a= greement upon

    which SPNEGO mechanism to use (e.g= . Kerberos)

  - The server always sends its certificate

  - The server never sends certificate request m= essage

  - The client never sends its certificate

  - ClientKeyExchange message: Aft= er GSS initialize Security

    context call is done, the client c= alls GSS encrypt message

    to encrypt the premaster secret. N= OTE: the ClientKeyExchange

    is always protected under the publ= ic key obtained from the

    Server cert.

  - Ideally use Supplementary data messages to c= arry gss payloads

 

 

Outline:

 

   Client     &nbs= p;             =             &nb= sp;            =    Server

 

      ClientHello

       /* CipherSuite: = SPNEGO_AES_SHA256,...

         = ; Extensions SPNEGO (Kerb,WS-Sec,NTLM,..) */ ----->

 

         = ;            &n= bsp;            = ;            &n= bsp;       ServerHello

         = ;            &n= bsp;          /* CipherSuite: = SPNEGO_AES_SHA256

         = ;            &n= bsp;            = ;    Extensions SPNEGO (Kerb) */

         = ;            &n= bsp;            = ;            &n= bsp;       Certificate

         = ;            &n= bsp;            = ;   <--------    ServerHelloDone

 

         = ;   <---------   SupplementalData  -------->=

         &nbs= p;/* multiple iterations with SPNEGO payload */

 

      ClientKeyExchange

      CertificateVerify*

      [ChangeCipherSpec]

      Finished  &n= bsp;            = ;      -------->

         = ;            &n= bsp;            = ;             [= ChangeCipherSpec]

         = ;            &n= bsp;            = ; <--------          &= nbsp;  Finished

      Application Data =             <----= --->     Application Data

 

Challenges:

 

The SPNEGO negotiation does not have a predefined num= ber of iterations. This exchange of messages has to be allowed go on until = finished. Conventions need to be defined for how to detect completion as we= ll as success and failure of this negotiation.

 

Ideally we would use the Supplemental data handshake = message to carry the SPNEGO payloads. However, it must be determined that i= t is allowed.

 

 

Alternative solutions considered:

 

As alternative solutions to this proposal we have con= sidered defining Kerberos specific payloads for transport in TLS extensions= and handshake messages as well as basing a solution on TLS PSK.

 

The name field in TLS PSK could contain a Kerberos ti= cket, but it would not provide the necessary means to provide an initial AS= -request. The AS-request has a need for protection which has to be provided= by the TLS handshake, possibly through double handshake. Such solution is = not very generic and double handshake is not always usable in environments = where this could be used, especially in high latency networks.

 

In the end, no alternatives considered have in our vi= ew been able to provide a clean and generic solution.

 

 

 

Stefan Santesson<= SPAN lang=3DEN-GB style=3D"COLOR: #1f497d">

Senior Program Manager<= SPAN lang=3DEN-GB style=3D"COLOR: navy">

Windows Security, Standards=


Try the next generation of search with Windows LiveT Search today! Try it now! = --_3623806d-8ce2-4a21-95a3-5c63f60ff54c_-- --===============0822152688== 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 --===============0822152688==-- From tls-bounces@lists.ietf.org Mon Nov 06 11:27:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh7J6-0001F0-T8; Mon, 06 Nov 2006 11:26:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gh7J5-0001Ev-IX for tls@ietf.org; Mon, 06 Nov 2006 11:26:43 -0500 Received: from maila.microsoft.com ([131.107.115.212] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gh7Iv-0007rT-B8 for tls@ietf.org; Mon, 06 Nov 2006 11:26:43 -0500 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server id 8.0.685.10; Mon, 6 Nov 2006 08:26:32 -0800 Received: from IGT-HUB-01.redmond.corp.microsoft.com ([157.54.69.148]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Nov 2006 08:25:43 -0800 Received: from tk5-exhub-c103.redmond.corp.microsoft.com ([157.54.70.186]) by IGT-HUB-01.redmond.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2786); Mon, 6 Nov 2006 08:25:43 -0800 Received: from win-imc-01.wingroup.windeploy.ntdev.microsoft.com (157.54.0.39) by tk5-exhub-c103.redmond.corp.microsoft.com (157.54.70.186) with Microsoft SMTP Server id 8.0.685.5; Mon, 6 Nov 2006 08:25:42 -0800 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-01.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Mon, 6 Nov 2006 08:25:42 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [TLS] SPNEGO over TLS - proposed new work item Date: Mon, 6 Nov 2006 08:25:41 -0800 Message-ID: <802A881C87166D4597F9EEFC3F04F4F86B8E87@WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] SPNEGO over TLS - proposed new work item Thread-Index: AccBuoKp6wGpRXyaRLGKwUQCls8kgwABOQyz References: From: Ari Medvinsky To: Peter Williams , Stefan Santesson , tls mailing list X-OriginalArrivalTime: 06 Nov 2006 16:25:42.0797 (UTC) FILETIME=[3468A3D0:01C701C0] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a3b79fd9d7bf2ef1762376a62c51ec4 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="===============2028693855==" Errors-To: tls-bounces@lists.ietf.org --===============2028693855== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C701C0.33C076C9" ------_=_NextPart_001_01C701C0.33C076C9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Peter, the point of Stefan's proposal is not about WS security - the = primary motivation is to solve the shortcomings of RFC2712 (krb under = tls) - RFC2712 assumes that the TLS client has connectivity to the KDC = (this is a problem for most corp. deployments). doing SPNEGO in TLS = will solve this problem (via forwarding of AS_REQ to the server). ________________________________ From: Peter Williams [mailto:home_pw@msn.com] Sent: Mon 11/6/2006 7:42 AM To: Stefan Santesson; tls mailing list Subject: RE: [TLS] SPNEGO over TLS - proposed new work item I don't thing this is the right architecture for the worldwide internet: = putting the ws-security (i.e. ws-conversation) handshakes (a SPNEGO = profile) into the TLS message handling layer. The right place for = ws-conversation is in the http redirect/post handlers, where one can = hook arbitrary levels of security protocol engines above the http = messaging layer (as SAML2 has shown the world, so effectively, = standardizing over 11 security state machines that accomplish everything = the SSL ever did). Id agree that most of the handshake mechanisms that = TLS 1.x standardizes can then simply be re-written as ws-conversation = flows, and that is the proper architectural relationship between = we-security and TLS. WS-conversation flows can of course add more = security semantics than TLS can ever accomplish by its linkage to = TCP/IP, being able to orchestrate store-and forward security protocols. One can easily imagine now an httpws:// that properly orchestrates what = role a reliable transport channel such as TLS plays when supporting = ws-conversation flows at the http layer, much like https orchestrated = how hypermedia multiplexing, certificates and website naming at the http = layer interplayed with SSL protocol engines. SO, it should be SPNEGO OVER TLS, not SPNEGO in TLS. ________________________________ Date: Mon, 6 Nov 2006 08:51:03 +0000 From: stefans@microsoft.com To: tls@ietf.org CC:=20 Subject: [TLS] SPNEGO over TLS - proposed new work item =09 =09 =20 I would like the TLS group to consider a new work to provide a = framework for GSS-API based authentication and key establishing methods. = I have requested a spot at the TLS meeting to discuss this. =20 In Microsoft we have investigated many ways to use Kerberos as means of = client authentication and key establishment over TLS but the task offers = several challenges that current specification does not solve. =20 The most important challenge is to allow a full Kerberos negotiation = including initial AS-request to the KDC server when the client resides = outside the local network of the KDC server.=20 =20 The proposal is to provide a generic and transparent solution by = enabling SPNEGO (RFC 4178) within a TLS handshake.=20 =20 The advantage of allowing SPNEGO under TLS is that it provides a lot of = flexibility as new mechanisms can be added under SPNEGO (e.g., WS = security), given the reliance on the SPNEGO for auth package = negotiation, without further amendments to TLS. =20 Deliverables and highlights: - Define new ciphersuites that use SPNEGO for key exchange=20 - Define new TLS client/server extension for agreement upon which SPNEGO mechanism to use (e.g. Kerberos)=20 - The server always sends its certificate=20 - The server never sends certificate request message=20 - The client never sends its certificate=20 - ClientKeyExchange message: After GSS initialize Security context call is done, the client calls GSS encrypt message to encrypt the premaster secret. NOTE: the ClientKeyExchange is always protected under the public key obtained from the Server cert.=20 - Ideally use Supplementary data messages to carry gss payloads =20 =20 Outline: =20 Client Server =20 ClientHello /* CipherSuite: SPNEGO_AES_SHA256,... Extensions SPNEGO (Kerb,WS-Sec,NTLM,..) */ -----> =20 ServerHello /* CipherSuite: SPNEGO_AES_SHA256 Extensions SPNEGO (Kerb) */ Certificate <-------- ServerHelloDone =20 <--------- SupplementalData --------> /* multiple iterations with SPNEGO payload */ =20 ClientKeyExchange CertificateVerify* [ChangeCipherSpec] Finished --------> [ChangeCipherSpec] <-------- Finished Application Data <-------> Application Data =20 Challenges: =20 The SPNEGO negotiation does not have a predefined number of iterations. = This exchange of messages has to be allowed go on until finished. = Conventions need to be defined for how to detect completion as well as = success and failure of this negotiation. =20 Ideally we would use the Supplemental data handshake message to carry = the SPNEGO payloads. However, it must be determined that it is allowed. =20 =20 Alternative solutions considered: =20 As alternative solutions to this proposal we have considered defining = Kerberos specific payloads for transport in TLS extensions and handshake = messages as well as basing a solution on TLS PSK.=20 =20 The name field in TLS PSK could contain a Kerberos ticket, but it would = not provide the necessary means to provide an initial AS-request. The = AS-request has a need for protection which has to be provided by the TLS = handshake, possibly through double handshake. Such solution is not very = generic and double handshake is not always usable in environments where = this could be used, especially in high latency networks. =20 In the end, no alternatives considered have in our view been able to = provide a clean and generic solution. =20 =20 =20 Stefan Santesson Senior Program Manager Windows Security, Standards ________________________________ Try the next generation of search with Windows LiveT Search today! Try = it now! =20 ------_=_NextPart_001_01C701C0.33C076C9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A=
=0A=
Peter, the = point of Stefan's proposal is not about WS security - the primary = motivation is to solve the shortcomings of RFC2712 (krb under tls) - = RFC2712 assumes that the TLS client has connectivity to the KDC (this is = a problem for most corp. deployments).  doing SPNEGO in TLS will = solve this problem (via forwarding of AS_REQ to the server).
=0A=
=0A= From: Peter Williams = [mailto:home_pw@msn.com]
Sent: Mon 11/6/2006 7:42 = AM
To: Stefan Santesson; tls mailing list
Subject: = RE: [TLS] SPNEGO over TLS - proposed new work = item

=0A=
I don't thing this is the right architecture for the worldwide = internet: putting the ws-security (i.e. ws-conversation) handshakes (a = SPNEGO profile) into the TLS message handling layer. The right place for = ws-conversation is in the http redirect/post handlers, where one can = hook arbitrary levels of security protocol engines above the http = messaging layer (as SAML2 has shown the world, so effectively, = standardizing over 11 security state machines that accomplish everything = the SSL ever did). Id agree that most of the handshake mechanisms that = TLS 1.x standardizes can then simply be re-written as ws-conversation = flows, and that is the proper architectural relationship between = we-security and TLS. WS-conversation flows can of course add more = security semantics than TLS can ever accomplish by its linkage to = TCP/IP, being able to orchestrate store-and forward security = protocols.

One can easily imagine now an httpws:// that properly = orchestrates what role a reliable transport channel such as TLS plays = when supporting ws-conversation flows at the http layer, much like https = orchestrated how hypermedia multiplexing, certificates and website = naming at the http layer interplayed with SSL protocol = engines.

SO, it should be SPNEGO OVER TLS, not SPNEGO in = TLS.

=0A=
=0A=
=0A= Date: Mon, 6 Nov 2006 08:51:03 +0000
From: = stefans@microsoft.com
To: tls@ietf.org
CC:
Subject: [TLS] = SPNEGO over TLS - proposed new work item

=0A= =0A= =0A=
=0A=

 

=0A=

I would like the TLS group to consider a new = work to provide a framework for GSS-API based authentication and key = establishing methods. I have requested a spot at the TLS meeting to = discuss this.

=0A=

 

=0A=

In Microsoft we have investigated many ways = to use Kerberos as means of client authentication and key establishment = over TLS but the task offers several challenges that current = specification does not solve.

=0A=

 

=0A=

The most important challenge is to allow a = full Kerberos negotiation including initial AS-request to the KDC server = when the client resides outside the local network of the KDC server. =

=0A=

 

=0A=

The proposal is to provide a generic and = transparent solution by enabling SPNEGO (RFC 4178) within a TLS = handshake.

=0A=

 

=0A=

The advantage of allowing SPNEGO under TLS = is that it provides a lot of flexibility as new mechanisms can be added = under SPNEGO (e.g., WS security), given the reliance on the SPNEGO for = auth package negotiation, without further amendments to TLS.

=0A=

 

=0A=

Deliverables and highlights:

=0A=

  - Define new ciphersuites that use = SPNEGO for key exchange

=0A=

  - Define new TLS client/server = extension for agreement upon

=0A=

    which SPNEGO mechanism to = use (e.g. Kerberos)

=0A=

  - The server always sends its = certificate

=0A=

  - The server never sends certificate = request message

=0A=

  - The client never sends its = certificate

=0A=

  - ClientKeyExchange message: After GSS initialize Security

=0A=

    context call is done, the = client calls GSS encrypt message

=0A=

    to encrypt the premaster = secret. NOTE: the ClientKeyExchange

=0A=

    is always protected under = the public key obtained from the

=0A=

    Server cert.

=0A=

  - Ideally use Supplementary data = messages to carry gss payloads

=0A=

 

=0A=

 

=0A=

Outline:

=0A=

 

=0A=

   = Client            =             &= nbsp;           &n= bsp;          Server

=0A=

 

=0A=

      = ClientHello

=0A=

       /* = CipherSuite: SPNEGO_AES_SHA256,...

=0A=

          Extensions = SPNEGO (Kerb,WS-Sec,NTLM,..) */ ----->

=0A=

 

=0A=

           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      ServerHello

=0A=

           &= nbsp;           =          /* CipherSuite: = SPNEGO_AES_SHA256

=0A=

           &= nbsp;           &n= bsp;           &nb= sp;  Extensions SPNEGO (Kerb) */

=0A=

           &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;      Certificate

=0A=

           &= nbsp;           &n= bsp;           &nb= sp; <--------    ServerHelloDone

=0A=

 

=0A=

            = <---------   SupplementalData  -------->

=0A=

          /* multiple = iterations with SPNEGO payload */

=0A=

 

=0A=

      = ClientKeyExchange

=0A=

      = CertificateVerify*

=0A=

      = [ChangeCipherSpec]

=0A=

      = Finished           = ;          = -------->

=0A=

           &= nbsp;           &n= bsp;           &nb= sp;           = [ChangeCipherSpec]

=0A=

           &= nbsp;           &n= bsp;           = <--------          &= nbsp;  Finished

=0A=

      Application = Data           &nb= sp; <------->     Application Data

=0A=

 

=0A=

Challenges:

=0A=

 

=0A=

The SPNEGO negotiation does not have a = predefined number of iterations. This exchange of messages has to be = allowed go on until finished. Conventions need to be defined for how to = detect completion as well as success and failure of this = negotiation.

=0A=

 

=0A=

Ideally we would use the Supplemental data = handshake message to carry the SPNEGO payloads. However, it must be = determined that it is allowed.

=0A=

 

=0A=

 

=0A=

Alternative solutions considered:

=0A=

 

=0A=

As alternative solutions to this proposal we = have considered defining Kerberos specific payloads for transport in TLS = extensions and handshake messages as well as basing a solution on TLS = PSK.

=0A=

 

=0A=

The name field in TLS PSK could contain a = Kerberos ticket, but it would not provide the necessary means to provide = an initial AS-request. The AS-request has a need for protection which = has to be provided by the TLS handshake, possibly through double = handshake. Such solution is not very generic and double handshake is not = always usable in environments where this could be used, especially in = high latency networks.

=0A=

 

=0A=

In the end, no alternatives considered have = in our view been able to provide a clean and generic solution.

=0A=

 

=0A=

 

=0A=

 

=0A=

Stefan = Santesson

=0A=

Senior Program = Manager

=0A=

Windows Security, = Standards


=0A=
=0A= Try the next generation of search with Windows LiveT Search today! Try it now! =
------_=_NextPart_001_01C701C0.33C076C9-- --===============2028693855== 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 --===============2028693855==-- From tls-bounces@lists.ietf.org Mon Nov 06 15:35:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhB9P-0006rB-1i; Mon, 06 Nov 2006 15:32:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhB9M-0006nR-Rh for tls@ietf.org; Mon, 06 Nov 2006 15:32:56 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhB9J-0003t6-NQ for tls@ietf.org; Mon, 06 Nov 2006 15:32:56 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id VAA29754; Mon, 6 Nov 2006 21:32:33 +0100 (MEZ) From: Martin Rex Message-Id: <200611062032.VAA28540@uw1048.wdf.sap.corp> Subject: Re: [TLS] SPNEGO over TLS - proposed new work item To: stefans@microsoft.com (Stefan Santesson) Date: Mon, 6 Nov 2006 21:32:32 +0100 (MET) In-Reply-To: from "Stefan Santesson" at Nov 6, 6 08:51:03 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: 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 Stefan Santesson wrote: > > The proposal is to provide a generic and transparent solution by > enabling SPNEGO (RFC 4178) within a TLS handshake. > > The advantage of allowing SPNEGO under TLS is that it provides a lot of > flexibility as new mechanisms can be added under SPNEGO (e.g., WS > security), given the reliance on the SPNEGO for auth package > negotiation, without further amendments to TLS. > > > > Deliverables and highlights: > > - Define new ciphersuites that use SPNEGO for key exchange > > - Define new TLS client/server extension for agreement upon > which SPNEGO mechanism to use (e.g. Kerberos) > > - The server always sends its certificate > > - The server never sends certificate request message > > - The client never sends its certificate > > - ClientKeyExchange message: After GSS initialize Security > context call is done, the client calls GSS encrypt message > to encrypt the premaster secret. NOTE: the ClientKeyExchange > is always protected under the public key obtained from the > Server cert. What do you mean by "GSS encrypt" -- gss_wrap? I don't quite understand what you're proposing, but there might a problem with this: At the gss-api level, when SPNEGO is used, then message protection facilities are *NOT* available until after the security context establishment has completed successfully, i.e. GSS_C_FLAG_PROT_READY is incompatible with the use of SPNEGO. One of the reasons why GSS_C_FLAG_PROT_READY is incompatible with SPNEGO is the sequencing protection of protected messages in GSS-API. SPNEGO uses a regular "gss_getmic()" call to create a MIC for the handshake. The use of message protection facilities before the handshake is complete would interfere with SPNEGOs use for the very same facilities to protect the handshake. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 07 01:05:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhK3Z-0005TK-Qt; Tue, 07 Nov 2006 01:03:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhK3X-0005T6-LS for tls@ietf.org; Tue, 07 Nov 2006 01:03:31 -0500 Received: from mail-gw-old.ygnition.net ([66.135.144.21] helo=darthmail.iqcicom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhK3V-00083a-Bz for tls@ietf.org; Tue, 07 Nov 2006 01:03:31 -0500 Received: from [192.168.1.2] (ip10.post-street-towers.sfo.ygnition.net [66.199.92.10]) by darthmail.iqcicom.com (Vircom SMTPRS 4.35.480.0) with ESMTP id ; Mon, 6 Nov 2006 22:03:23 -0800 X-Modus-ReverseDNS: OK X-Modus-BlackList: 66.199.92.10=OK;trevp@trevp.net=OK X-Modus-RBL: 66.199.92.10=Excluded X-Modus-Trusted: 66.199.92.10=NO Message-ID: <455022E8.1030401@trevp.net> Date: Mon, 06 Nov 2006 22:08:40 -0800 From: Trevor Perrin User-Agent: Thunderbird 1.5.0.7 (X11/20060925) MIME-Version: 1.0 To: EKR Subject: Re: [TLS] TLS and SRP References: <454F4F29.1030601@edelweb.fr> <86d580li3n.fsf@delta.rtfm.com> In-Reply-To: <86d580li3n.fsf@delta.rtfm.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 EKR wrote: > Peter Sylvester writes: > >> Hi, >> >> What is actual status of treating the SRP-TLS specification in this >> working group? [...] > The chairs have sent a number of comments to the authors about the > architectural approach taken in the draft. As far as I know > they're still thinking about it. Eric, Peter, Yes, the chairs' comments were helpful. We'll try to produce a new draft within the month. Trevor _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 07 05:11:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhNtl-0005Ye-B9; Tue, 07 Nov 2006 05:09:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhNtk-0005YY-1w for tls@ietf.org; Tue, 07 Nov 2006 05:09:40 -0500 Received: from edelweb.fr ([212.234.46.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhNti-0002wT-KW for tls@ietf.org; Tue, 07 Nov 2006 05:09:40 -0500 Received: from [193.51.14.5] (localhost [127.0.0.1]) by edelweb.fr (8.11.7p1+Sun/8.11.7) with ESMTP id kA7A9V514755; Tue, 7 Nov 2006 11:09:31 +0100 (MET) Received: from [193.51.14.5] (emeriau.edelweb.fr [193.51.14.5]) by edelweb.fr (nospam/2.4); Tue, 7 Nov 2006 11:09:31 +0100 (MET) Message-ID: <45505AE6.1020109@edelweb.fr> Date: Tue, 07 Nov 2006 11:07:34 +0100 From: Peter Sylvester User-Agent: Thunderbird 1.5 (X11/20051025) MIME-Version: 1.0 To: Trevor Perrin Subject: Re: [TLS] TLS and SRP References: <454F4F29.1030601@edelweb.fr> <86d580li3n.fsf@delta.rtfm.com> <455022E8.1030401@trevp.net> In-Reply-To: <455022E8.1030401@trevp.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 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="===============2011467524==" Errors-To: tls-bounces@lists.ietf.org This is a cryptographically signed message in MIME format. --===============2011467524== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms010105090108000606070009" This is a cryptographically signed message in MIME format. --------------ms010105090108000606070009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Thanks for the info. Trevor Perrin wrote: > EKR wrote: >> Peter Sylvester writes: >> >>> Hi, >>> >>> What is actual status of treating the SRP-TLS specification in this >>> working group? > [...] >> The chairs have sent a number of comments to the authors about the >> architectural approach taken in the draft. As far as I know >> they're still thinking about it. > > Eric, Peter, > > Yes, the chairs' comments were helpful. We'll try to produce a new > draft within the month. > > Trevor > > -- To verify the signature, see http://edelpki.edelweb.fr/ Cela vous permet de charger le certificat de l'autorité; die Liste mit zurückgerufenen Zertifikaten finden Sie da auch. --------------ms010105090108000606070009 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 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOpDCC BHIwggLfoAMCAQICBgoMz+gAPzANBgkqhkiG9w0BAQUFADBbMQswCQYDVQQGEwJGUjEQMA4G A1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVs UEtJIEVkZWxXZWIgUGVyc0dFTjAeFw0wNTAxMDYxMjI3MTlaFw0wNzAzMTcxMjI3MTlaMHAx CzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQLDA9TZXJ2aWNlIEVkZWxQ S0kxNTAzBgNVBAMMLFBldGVyIFNZTFZFU1RFUiA8UGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIu ZnI+MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDn/izyem7Z1pUP/gpQDSzeGA/ZP4vo VaCxcPWyssTYTAl6csAql2IIcYNVb6funaMNOY1q5oSNtlguFpOK3atQElBIMsfSh0CTuvUq q2QDz1nHWOB96aU8G81+ZmC+iQOCAdG3qKWvMOzC0SzxKGbhTqDsjBvfYYk1Jk/Rb5TK0wID AQABo4IBLjCCASowYgYDVR0RBFswWYEaUGV0ZXIuU3lsdmVzdGVyQGVkZWx3ZWIuZnKkOzA5 MQswCQYDVQQGEwJGUjEQMA4GA1UECgwHRWRlbFdlYjEYMBYGA1UEAwwPUGV0ZXIgU1lMVkVT VEVSMA4GA1UdDwEB/wQEAwIF4DAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYD VR0fBEMwQTA/oD2gO4Y5aHR0cDovL2VkZWxwa2kuZWRlbHdlYi5mci9jcmwvRWRlbFBLSS1F ZGVsV2ViLVBlcnNHRU4uY3JsMB0GA1UdDgQWBBSSHP6djxj58tIi5VvjJbMZMXC/fDAfBgNV HSMEGDAWgBSe5Q/BFJVJHN1aXV6crs0Bby+UeTAJBgNVHRMEAjAAMA0GCSqGSIb3DQEBBQUA A4IBfAANZYiEkyDqsT43U83wHLSYMGcEfmisT+WQrAAoHdlcIsnlHnufGnfmdpg5yvCQpl2U TI7/w3LdaItoWq5oMZitqdoPW8Z+jy2pkd/DqYG1MkpEyZ0PA37Zn5yigQXAk4Nox7Lgiom8 1WDNgPesNRX7PRNa+RkQcD8MasfbHcZ2ycs1SxUxiCy6BUzhgSB8cNb2t9LVWWynvWuK1Wa5 V2ZCd3PlbKsrbWH8pafpFWUQm0S2BfKUWLDG9cje5bL7p5EpV4a8gFpbD5dq+PPJglT0Dvs9 F0EcrfL2l3JxGIkZmW7sfiUoefB9hTS9m3/TGvXcne4RYpVpEHFV5TathMuHfKAti6PhSely LCqdPq/T9DHLJekBY0EA2yiVcKQnRZk7/pz0HImCPADOHSOWffJtc9b+Ak6HSDD1PlOSDfT+ udnrqwSAiuNN3hx1olPNxzVDu3jgiTSJFf2XJ1TnmGMT4pJmx7vkJkdE9sZvpiZwdVws37Nr LqhH5fMZMIIEcjCCAt+gAwIBAgIGCgzP6AA/MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOMB4XDTA1MDEwNjEyMjcxOVoXDTA3MDMxNzEy MjcxOVowcDELMAkGA1UEBhMCRlIxEDAOBgNVBAoMB0VkZWxXZWIxGDAWBgNVBAsMD1NlcnZp Y2UgRWRlbFBLSTE1MDMGA1UEAwwsUGV0ZXIgU1lMVkVTVEVSIDxQZXRlci5TeWx2ZXN0ZXJA ZWRlbHdlYi5mcj4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOf+LPJ6btnWlQ/+ClAN LN4YD9k/i+hVoLFw9bKyxNhMCXpywCqXYghxg1Vvp+6dow05jWrmhI22WC4Wk4rdq1ASUEgy x9KHQJO69SqrZAPPWcdY4H3ppTwbzX5mYL6JA4IB0beopa8w7MLRLPEoZuFOoOyMG99hiTUm T9FvlMrTAgMBAAGjggEuMIIBKjBiBgNVHREEWzBZgRpQZXRlci5TeWx2ZXN0ZXJAZWRlbHdl Yi5mcqQ7MDkxCzAJBgNVBAYTAkZSMRAwDgYDVQQKDAdFZGVsV2ViMRgwFgYDVQQDDA9QZXRl ciBTWUxWRVNURVIwDgYDVR0PAQH/BAQDAgXgMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEF BQcDAjBKBgNVHR8EQzBBMD+gPaA7hjlodHRwOi8vZWRlbHBraS5lZGVsd2ViLmZyL2NybC9F ZGVsUEtJLUVkZWxXZWItUGVyc0dFTi5jcmwwHQYDVR0OBBYEFJIc/p2PGPny0iLlW+Mlsxkx cL98MB8GA1UdIwQYMBaAFJ7lD8EUlUkc3VpdXpyuzQFvL5R5MAkGA1UdEwQCMAAwDQYJKoZI hvcNAQEFBQADggF8AA1liISTIOqxPjdTzfActJgwZwR+aKxP5ZCsACgd2VwiyeUee58ad+Z2 mDnK8JCmXZRMjv/Dct1oi2harmgxmK2p2g9bxn6PLamR38OpgbUySkTJnQ8DftmfnKKBBcCT g2jHsuCKibzVYM2A96w1Ffs9E1r5GRBwPwxqx9sdxnbJyzVLFTGILLoFTOGBIHxw1va30tVZ bKe9a4rVZrlXZkJ3c+VsqyttYfylp+kVZRCbRLYF8pRYsMb1yN7lsvunkSlXhryAWlsPl2r4 88mCVPQO+z0XQRyt8vaXcnEYiRmZbux+JSh58H2FNL2bf9Ma9dyd7hFilWkQcVXlNq2Ey4d8 oC2Lo+FJ6XIsKp0+r9P0Mcsl6QFjQQDbKJVwpCdFmTv+nPQciYI8AM4dI5Z98m1z1v4CTodI MPU+U5IN9P652eurBICK403eHHWiU83HNUO7eOCJNIkV/ZcnVOeYYxPikmbHu+QmR0T2xm+m JnB1XCzfs2suqEfl8xkwggW0MIIDT6ADAgECAgYJ+oiVOzEwDQYJKoZIhvcNAQEFBQAwUjEL MAkGA1UEBhMCRlIxEDAOBgNVBAoTB0VkZWxXZWIxGDAWBgNVBAsTD1NlcnZpY2UgRWRlbFBL STEXMBUGA1UEAxMOUmFjaW5lIEVkZWxQS0kwHhcNMDQxMDA3MTU0MzMwWhcNMTEwODEyMTU0 MzMwWjBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEYMBYGA1UECxMPU2Vydmlj ZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVyc0dFTjCCAZwwDQYJKoZI hvcNAQEBBQADggGJADCCAYQCggF7FyeP4kRrFG9y51CeWmJIxBSMD2bcrJKIlnAPn6eH8V1M ORWTPivMNQYq32XcEi9xrxjyREvvnhABrVcW+1VLyLH8WgRY6n5A5JfuDjU6Aq0RzmjqTWDe 1+ecbgAtN8FYjVk35vdQbgfYzpGHPT0NuxiHi8NB8lNFi8rG0t2hP7WLwHLA+sIKFzA/CCRt qeGPvQkB1pRamU2IAActykfzJb6Qc50uRobWUBJtVjEBy/lgIXU0rMnQNHeCgbUvebvAT9Hd UGIPbEiX7dKHxL5/AxzHK/rA5siMzNPk8nSckDeLvpf8c/gqQRpPqufy4DazzXfZosKeJATH pyONnairmwfzMTi63PvNovrbTgzUiyH+g5zvcNoci9cke0RiLQc1pI38psgnVLtPPITgOZrS cV9zs4+sD7x7vjRco7a9H2ErfAU+8/Ui2OkR1X0z8DpyBHD/fcaDXTD+EiISL7aJHQcJRoNB CdCFgZeomsXULIYoFTa1hH//TN0z9wIDAQABo4G/MIG8MDoGA1UdHwQzMDEwL6AtoCuGKWh0 dHA6Ly9lZGVscGtpLmVkZWx3ZWIuZnIvY3JsL0VkZWxQS0kuY3JsMA8GA1UdEwQIMAYBAf8C AQAwDgYDVR0PAQH/BAQDAgEGMB0GA1UdJQQWMBQGCCsGAQUFBwMEBggrBgEFBQcDAjAdBgNV HQ4EFgQUnuUPwRSVSRzdWl1enK7NAW8vlHkwHwYDVR0jBBgwFoAUqNkrj9SwZ7q9SVy8M/x3 UhG5Z50wDQYJKoZIhvcNAQEFBQADggJOAFZV+1m/H+Qud9iUQJnvZR8R/adID02c2B3aOUUy 4/4dxBb4UU1kW8DTUpD57Pjuocfvdg4AfQi7zgSQ8/NUGxNU4CPxtADZVrZtmrpKCjBh1tNz QbNbdP91KtP+Di0BpidqNwG00CC9j2EnBY88AsqKE28Rmw4eQ9/M/q/GbXsAfEsHV0IQjM7u US+usowZwm3Mwa5oF+6gmShSc/Wz8iIURxg4lTQto3AoBsiLJelq83I4XRQ0goXYGcM8xXYj PDioidvY5pSfT4qBR1Bx/vh+xD2evWyFbpuB99iuuewoELX8db7P74QEHhw6Bv1yxLYXGamq Uxo60WT/UCFjVSy3C/dLrraUZA4gh7Q5G+3/Fal62Qx+1rUEC2YbogEKggonklzUXA+sUbCf Ad5nZQ0eSszwKt8jmYoHfQ6rUMde0ZJD08n5HAot9hpl9R65j9fdPz9uTeANcRocftHfgM7Y rQyruWuFxgMUV80fD4RC9ej5KbLyO8jtgESjOCGXeJ95kXXP8vmW73xCYkJ9Pg7Op30o43l6 PV7vej3gdmSQISY+s+J3arz+bccljJCrKHBad3918/LjJ55sRtSb7mfQGti2UcxtJAa2NmUL d+BIv0MUuC6+k2yIIQKcLbDuuk8lLJmwWuYt1OLHEskZxOm7D7nRwe7ZNlTIZvR/VFWxlY18 k488tH9qcusIw8+7uXeHOZHyFUOHMINJZO9mq9HwGMC4v1xiPwoAJkzFtHf3D9VAholjhEFg d28aJSs6qN15PXDgDjptAl34eoUxggKuMIICqgIBATBlMFsxCzAJBgNVBAYTAkZSMRAwDgYD VQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNVBAMTF0VkZWxQ S0kgRWRlbFdlYiBQZXJzR0VOAgYKDM/oAD8wCQYFKw4DAhoFAKCCAZ8wGAYJKoZIhvcNAQkD MQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDYxMTA3MTAwNzM0WjAjBgkqhkiG9w0B CQQxFgQU5RuqUrJgpqDNGHcOTnEPPD0FiTswUgYJKoZIhvcNAQkPMUUwQzAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwIC ASgwdAYJKwYBBAGCNxAEMWcwZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UEChMHRWRlbFdlYjEY MBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJIEVkZWxXZWIgUGVy c0dFTgIGCgzP6AA/MHYGCyqGSIb3DQEJEAILMWegZTBbMQswCQYDVQQGEwJGUjEQMA4GA1UE ChMHRWRlbFdlYjEYMBYGA1UECxMPU2VydmljZSBFZGVsUEtJMSAwHgYDVQQDExdFZGVsUEtJ IEVkZWxXZWIgUGVyc0dFTgIGCgzP6AA/MA0GCSqGSIb3DQEBAQUABIGAefJH9ONIUcuXJ6IN CX7pkKqBaM8OtvuSr4wYP8I37gIMrVQZuxS8IWK18Se3kjEDGqHiPhn6PVxW81qNWe0ECohv 2/u7XB5L7nL3VvMuz8eo9HBsqmvDK30RohOi1axII0mzOXbF68FeC9QynklWx6td3lgbu7fI qAdLHDkaT+0AAAAAAAA= --------------ms010105090108000606070009-- --===============2011467524== 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 --===============2011467524==-- From tls-bounces@lists.ietf.org Wed Nov 08 16:52:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhvIF-0004Ov-EB; Wed, 08 Nov 2006 16:49:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhvIE-0004LH-G9 for tls@ietf.org; Wed, 08 Nov 2006 16:49:10 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhvID-0002tm-1j for tls@ietf.org; Wed, 08 Nov 2006 16:49:10 -0500 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id VAA15252; Wed, 8 Nov 2006 21:54:19 +0100 (MEZ) Received: from uw1048.wdf.sap.corp (uw1048.wdf.sap.corp [10.18.112.41]) by sap.corp (8.8.8/8.8.8) with ESMTP id VAA01422; Wed, 8 Nov 2006 21:54:20 +0100 (MET) Received: (from d019080@localhost) by uw1048.wdf.sap.corp (8.8.8+Sun/8.8.8) id VAA17433; Wed, 8 Nov 2006 21:54:19 +0100 (MET) From: Martin Rex Message-Id: <200611082054.VAA17433@uw1048.wdf.sap.corp> Subject: Re: [TLS] SPNEGO over TLS - proposed new work item To: lzhu@windows.microsoft.com (Liqiang) Date: Wed, 8 Nov 2006 21:54:19 +0100 (MET) In-Reply-To: from "Liqiang" at Nov 8, 6 11:59:34 am 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: 082a9cbf4d599f360ac7f815372a6a15 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 Liqiang wrote: > > In the proposal below encrypt() means Gss_Wrap(), the client generates a > random quality and uses GSS_Wrap() to encrypt that random quality and > send it to the server, that is the basis of the SPNEGO key exchange > algorithm. Note this does not changes anything in the TLS record layer, > the output of GSS_Wrap() is embedded in a TLS key exchange message. > > We understand SPNEGO does not support PROT_READY and we expect that > GSS_Wrap() won't be invoked until the context has been fully > established. OK. My confusion might be caused by the wording of the proposal, which talks about one single API call instead of an entire (GSS/SPNEGO) handshake with multiple message exchanges: > > > > - ClientKeyExchange message: After GSS initialize Security > > context call is done, the client calls GSS encrypt message > > to encrypt the premaster secret. NOTE: the ClientKeyExchange > > is always protected under the public key obtained from the > > Server cert. was this supposed to mean something like this: - ClientKeyExchange message: the client uses the message protection services from the directly preceding successfully completed GSS/SPNEGO handshake to additionally encrypt the premaster secret, i.e. using gss_wrap(conf=true) to cryptographically link the gssapi authentication into the TLS handshake. > > We have received significant positive feedbacks so far. For example, we > will be able to save a message by using GSS_PRF() instead of GSS_Wrap(). gss_prf() is a fairly new optinal extension, and whether it is available is implementation defined. You should probably use distinct tls ciphersuite ids to identify which api call is used in order to provide interoperability with gssapi mechanisms that don't have gss_prf(). But what I'm wondering is the following: I keeps coming up everywhere--the decision of the client which authentication method to use might be far from simple/straightforward, and a rather simple ciphersuite id or mechanism OID might be insufficient for an adequate decision/selection. The existing client credential negotiation scheme in SSL/TLS is more flexible: the server sends an entire list of trusted CAs to the client, and the client uses it to determine whether it is in the posession of a suitable credential. Extending this scheme to SPNEGO would likely be benefical, but also quite challenging, i.e. dealing with mechanism-specific (lists of) hints providing guidance to the client for selection of the most adequate client credential (and gss-api mechanism)... -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 08 19:40:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhxwP-0004fD-14; Wed, 08 Nov 2006 19:38:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhxwN-0004et-Hj for tls@ietf.org; Wed, 08 Nov 2006 19:38:47 -0500 Received: from mail2.microsoft.com ([131.107.115.215] helo=smtp.microsoft.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhxwJ-0008Tp-Pe for tls@ietf.org; Wed, 08 Nov 2006 19:38:47 -0500 Received: from mailout6.microsoft.com (157.54.69.150) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server id 8.0.685.15; Wed, 8 Nov 2006 16:38:43 -0800 Received: from IGT-HUB-02.redmond.corp.microsoft.com ([157.54.69.153]) by mailout6.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 16:38:41 -0800 Received: from tk5-exhub-c104.redmond.corp.microsoft.com ([157.54.70.185]) by IGT-HUB-02.redmond.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Nov 2006 16:38:41 -0800 Received: from win-imc-02.wingroup.windeploy.ntdev.microsoft.com (157.54.69.169) by tk5-exhub-c104.redmond.corp.microsoft.com (157.54.70.185) with Microsoft SMTP Server id 8.0.685.15; Wed, 8 Nov 2006 16:38:39 -0800 Received: from WIN-MSG-20.wingroup.windeploy.ntdev.microsoft.com ([157.54.62.24]) by win-imc-02.wingroup.windeploy.ntdev.microsoft.com with Microsoft SMTPSVC(6.0.3790.2786); Wed, 8 Nov 2006 16:38:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-Class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [TLS] SPNEGO over TLS - proposed new work item Date: Wed, 8 Nov 2006 16:38:20 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] SPNEGO over TLS - proposed new work item Thread-Index: AccDeEPij2LTMC2DT6qsywk5ahJCWgAHYh22 References: <200611082054.VAA17433@uw1048.wdf.sap.corp> From: "Liqiang(Larry) Zhu" To: X-OriginalArrivalTime: 09 Nov 2006 00:38:39.0055 (UTC) FILETIME=[660EF5F0:01C70397] X-Spam-Score: 0.5 (/) X-Scan-Signature: bfe538a859d88717fa3c8a6377d62f90 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="===============1611789557==" Errors-To: tls-bounces@lists.ietf.org --===============1611789557== Content-Class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C70397.5B2F00D9" ------_=_NextPart_001_01C70397.5B2F00D9 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Martin Rex wrote: > was this supposed to mean something like this: > - ClientKeyExchange message: the client uses the message > protection services from the directly preceding > successfully completed GSS/SPNEGO handshake > to additionally encrypt the premaster secret, i.e. using > gss_wrap(conf=3Dtrue) to cryptographically link the > gssapi authentication into the TLS handshake. =20 yes, this is what the initial proposal meant. =20 > gss_prf() is a fairly new optinal extension, and whether it is = available > is implementation defined. You should probably use distinct tls > ciphersuite ids to identify which api call is used in order to provide > interoperability with gssapi mechanisms that don't have gss_prf(). it should be fairly straightforward to implement PRF(), but we may also = define another set of cipher suites where the key exchange does NOT use PRF(), = rather just use GSS_Wrap(). > I keeps coming up everywhere--the decision of the client which > authentication method to use might be far from simple/straightforward, > and a rather simple ciphersuite id or mechanism OID might be > insufficient for an adequate decision/selection. =20 this is an excellent point. Folks here do realize the same issue here. = the two negotiation layers (SPNEGO and TLS) should be coordinated in = some way, or do we need both negotiations? these are kinds of issues = that must be addressed when we have a draft. > The existing client credential negotiation scheme in SSL/TLS is more > flexible: the server sends an entire list of trusted CAs to the = client, > and the client uses it to determine whether it is in the posession > of a suitable credential. =20 this argues for using TLS negotiation mechanisms and removal of SPNEGO, = if I understand this correctly. Either way, I can clearly see your = points. =20 > Extending this scheme to SPNEGO would likely be benefical, but also > quite challenging, i.e. dealing with mechanism-specific (lists of) = hints > providing guidance to the client for selection of the most adequate > client credential (and gss-api mechanism)... I agree. this has prompted to the thinking of how to solve this in the = most efficient and generic way, and I am pondering ... =20 -- Larry ________________________________ From: Martin Rex [mailto:martin.rex@sap.com] Sent: Wed 11/8/2006 12:54 PM To: Liqiang(Larry) Zhu Cc: martin.rex@sap.com; Stefan Santesson; tls@ietf.org Subject: Re: [TLS] SPNEGO over TLS - proposed new work item Liqiang wrote: > > In the proposal below encrypt() means Gss_Wrap(), the client generates = a > random quality and uses GSS_Wrap() to encrypt that random quality and > send it to the server, that is the basis of the SPNEGO key exchange > algorithm. Note this does not changes anything in the TLS record = layer, > the output of GSS_Wrap() is embedded in a TLS key exchange message. > > We understand SPNEGO does not support PROT_READY and we expect that > GSS_Wrap() won't be invoked until the context has been fully > established. OK. My confusion might be caused by the wording of the proposal, which talks about one single API call instead of an entire (GSS/SPNEGO) handshake with multiple message exchanges: > > > > - ClientKeyExchange message: After GSS initialize Security > > context call is done, the client calls GSS encrypt message > > to encrypt the premaster secret. NOTE: the ClientKeyExchange > > is always protected under the public key obtained from the > > Server cert. was this supposed to mean something like this: - ClientKeyExchange message: the client uses the message protection services from the directly preceding successfully completed GSS/SPNEGO handshake to additionally encrypt the premaster secret, i.e. using gss_wrap(conf=3Dtrue) to cryptographically link the gssapi authentication into the TLS handshake. =20 > > We have received significant positive feedbacks so far. For example, = we > will be able to save a message by using GSS_PRF() instead of = GSS_Wrap(). gss_prf() is a fairly new optinal extension, and whether it is available is implementation defined. You should probably use distinct tls ciphersuite ids to identify which api call is used in order to provide interoperability with gssapi mechanisms that don't have gss_prf(). But what I'm wondering is the following: I keeps coming up everywhere--the decision of the client which authentication method to use might be far from simple/straightforward, and a rather simple ciphersuite id or mechanism OID might be insufficient for an adequate decision/selection. The existing client credential negotiation scheme in SSL/TLS is more flexible: the server sends an entire list of trusted CAs to the client, and the client uses it to determine whether it is in the posession of a suitable credential. Extending this scheme to SPNEGO would likely be benefical, but also quite challenging, i.e. dealing with mechanism-specific (lists of) hints providing guidance to the client for selection of the most adequate client credential (and gss-api mechanism)... -Martin ------_=_NextPart_001_01C70397.5B2F00D9 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [TLS] SPNEGO over TLS - proposed new = work item=0A= =0A= =0A= =0A=
=0A=
 Martin Rex = wrote:
=0A=
>  was this = supposed to mean something like = this:

 >     - ClientKeyExchange = message: the client uses the = message
>        protection = services from the directly = preceding
 >       successfully = completed GSS/SPNEGO = handshake
  >      to = additionally encrypt the premaster secret, i.e. = using
 >     gss_wrap(conf=3Dtrue) to = cryptographically link the
 >      = gssapi authentication into the TLS handshake.
=0A=
 
=0A=
yes, this is what the initial proposal meant.
=0A=
 
=0A=
> gss_prf() is a fairly new optinal = extension, and whether it is available
> is implementation = defined.  You should probably use distinct tls
> ciphersuite = ids to identify which api call is used in order to provide
> = interoperability with gssapi mechanisms that don't have = gss_prf().
=0A=
it should be fairly straightforward to implement PRF(), = but we may also define
=0A=
another set of cipher suites where the key = exchange does NOT use PRF(), rather just = use GSS_Wrap().
=0A=

> I keeps coming up everywhere--the = decision of the client which
> authentication method to use might = be far from simple/straightforward,
> and a rather simple = ciphersuite id or mechanism OID might be
> insufficient for an = adequate decision/selection.
=0A=
 
=0A=
this is an excellent point. Folks here do realize the = same issue here. the two negotiation layers (SPNEGO and TLS) should be = coordinated in some way, or do we need both negotiations? these are = kinds of issues that must be addressed when we have a draft.
=0A=

> The existing client credential = negotiation scheme in SSL/TLS is more
> flexible: the server sends = an entire list of trusted CAs to the client,
> and the client uses = it to determine whether it is in the posession
> of a suitable = credential.
=0A=
 
=0A=
this argues for using TLS negotiation = mechanisms and removal of SPNEGO, if I understand this correctly. Either = way, I can clearly see your points.
=0A=
 
=0A=
> Extending this scheme to SPNEGO would = likely be benefical, but also
> quite challenging, i.e. dealing = with mechanism-specific (lists of) hints
> providing guidance to = the client for selection of the most adequate
> client credential = (and gss-api mechanism)...
=0A=
I agree. this has prompted to the thinking of how to = solve this in the most efficient and generic way, and I am pondering = ...
=0A=
 
=0A=
-- Larry
=0A=
=0A=
=0A=
=0A=
From: Martin Rex = [mailto:martin.rex@sap.com]
Sent: Wed 11/8/2006 12:54 = PM
To: Liqiang(Larry) Zhu
Cc: martin.rex@sap.com; = Stefan Santesson; tls@ietf.org
Subject: Re: [TLS] SPNEGO over = TLS - proposed new work item

=0A=
=0A=

Liqiang wrote:
>
> In the proposal below = encrypt() means Gss_Wrap(), the client generates a
> random = quality and uses GSS_Wrap() to encrypt that random quality and
> = send it to the server, that is the basis of the SPNEGO key = exchange
> algorithm. Note this does not changes anything in the = TLS record layer,
> the output of GSS_Wrap() is embedded in a TLS = key exchange message.
>
> We understand SPNEGO does not = support PROT_READY and we expect that
> GSS_Wrap() won't be = invoked until the context has been fully
> = established.

OK.

My confusion might be caused by the = wording of the proposal, which
talks about one single API call = instead of an entire (GSS/SPNEGO)
handshake with multiple message = exchanges:

> >
> >   - ClientKeyExchange = message: After GSS initialize Security
> = >     context call is done, the client calls GSS = encrypt message
> >     to encrypt the = premaster secret. NOTE: the ClientKeyExchange
> = >     is always protected under the public key = obtained from the
> >     Server = cert.

was this supposed to mean something like = this:

      - ClientKeyExchange message: = the client uses the = message
        protection = services from the directly = preceding
        successfully = completed GSS/SPNEGO = handshake
        to additionally = encrypt the premaster secret, i.e. = using
        = gss_wrap(conf=3Dtrue) to cryptographically link = the
        gssapi authentication = into the TLS = handshake.
        
>> We have received significant positive feedbacks so far. For = example, we
> will be able to save a message by using GSS_PRF() = instead of GSS_Wrap().

gss_prf() is a fairly new optinal = extension, and whether it is available
is implementation = defined.  You should probably use distinct tls
ciphersuite ids = to identify which api call is used in order to = provide
interoperability with gssapi mechanisms that don't have = gss_prf().


But what I'm wondering is the following:
I = keeps coming up everywhere--the decision of the client = which
authentication method to use might be far from = simple/straightforward,
and a rather simple ciphersuite id or = mechanism OID might be
insufficient for an adequate = decision/selection.

The existing client credential negotiation = scheme in SSL/TLS is more
flexible: the server sends an entire list = of trusted CAs to the client,
and the client uses it to determine = whether it is in the posession
of a suitable = credential.

Extending this scheme to SPNEGO would likely be = benefical, but also
quite challenging, i.e. dealing with = mechanism-specific (lists of) hints
providing guidance to the client = for selection of the most adequate
client credential (and gss-api = mechanism)...


-Martin

------_=_NextPart_001_01C70397.5B2F00D9-- --===============1611789557== 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 --===============1611789557==-- From tls-bounces@lists.ietf.org Thu Nov 09 22:37:42 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiNAb-0005o9-2z; Thu, 09 Nov 2006 22:35:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GiNAZ-0005mW-0y for tls@ietf.org; Thu, 09 Nov 2006 22:35:07 -0500 Received: from smtp.microsoft.com ([131.107.115.215]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GiNAW-0005QE-6Z for tls@ietf.org; Thu, 09 Nov 2006 22:35:07 -0500 Received: from tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.0.685.15; Thu, 9 Nov 2006 19:35:03 -0800 Received: from DUB-EXHUB-C301.europe.corp.microsoft.com (65.53.213.91) by tk1-exhub-c104.redmond.corp.microsoft.com (157.56.116.117) with Microsoft SMTP Server (TLS) id 8.0.685.15; Thu, 9 Nov 2006 19:35:01 -0800 Received: from EA-EXMSG-C307.europe.corp.microsoft.com ([65.53.221.19]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Fri, 10 Nov 2006 03:34:48 +0000 From: Stefan Santesson To: "Liqiang(Larry) Zhu" , "martin.rex@sap.com" Date: Fri, 10 Nov 2006 03:34:47 +0000 Subject: RE: [TLS] SPNEGO over TLS - proposed new work item Thread-Topic: [TLS] SPNEGO over TLS - proposed new work item Thread-Index: AccDeEPij2LTMC2DT6qsywk5ahJCWgAHYh22ADftb6A= Message-ID: References: <200611082054.VAA17433@uw1048.wdf.sap.corp> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-Spam-Score: 1.3 (+) X-Scan-Signature: 92788d1b003e07b99aff407d30cf4598 Cc: "jaltman@secure-endpoints.com" , "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="===============0101924214==" Errors-To: tls-bounces@lists.ietf.org --===============0101924214== Content-Language: en-US Content-Type: multipart/alternative; boundary="_000_A15AC0FBACD3464E95961F7C0BCD1FF010B7E93FEAEXMSGC307euro_" --_000_A15AC0FBACD3464E95961F7C0BCD1FF010B7E93FEAEXMSGC307euro_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We had a design meeting today to conclude discussions about this proposal t= hat has surfaced during the IETF week. As such the proposal has changed in the way that SPNEGO has been removed fr= om the proposal and replaced with direct exchange of GSS-API tokens. The slides for the presentation tomorrow has been sent to Eric and should b= e up on the meeting materials page before the TLS meeting. A first draft will be available for consideration short after this IETF and= Jeff Altman has agreed to help as co-editor. Stefan Santesson Senior Program Manager Windows Security, Standards From: Liqiang(Larry) Zhu Sent: den 8 november 2006 16:38 To: martin.rex@sap.com Cc: martin.rex@sap.com; Stefan Santesson; tls@ietf.org Subject: RE: [TLS] SPNEGO over TLS - proposed new work item Martin Rex wrote: > was this supposed to mean something like this: > - ClientKeyExchange message: the client uses the message > protection services from the directly preceding > successfully completed GSS/SPNEGO handshake > to additionally encrypt the premaster secret, i.e. using > gss_wrap(conf=3Dtrue) to cryptographically link the > gssapi authentication into the TLS handshake. yes, this is what the initial proposal meant. > gss_prf() is a fairly new optinal extension, and whether it is available > is implementation defined. You should probably use distinct tls > ciphersuite ids to identify which api call is used in order to provide > interoperability with gssapi mechanisms that don't have gss_prf(). it should be fairly straightforward to implement PRF(), but we may also def= ine another set of cipher suites where the key exchange does NOT use PRF(), rat= her just use GSS_Wrap(). > I keeps coming up everywhere--the decision of the client which > authentication method to use might be far from simple/straightforward, > and a rather simple ciphersuite id or mechanism OID might be > insufficient for an adequate decision/selection. this is an excellent point. Folks here do realize the same issue here. the = two negotiation layers (SPNEGO and TLS) should be coordinated in some way, = or do we need both negotiations? these are kinds of issues that must be add= ressed when we have a draft. > The existing client credential negotiation scheme in SSL/TLS is more > flexible: the server sends an entire list of trusted CAs to the client, > and the client uses it to determine whether it is in the posession > of a suitable credential. this argues for using TLS negotiation mechanisms and removal of SPNEGO, if = I understand this correctly. Either way, I can clearly see your points. > Extending this scheme to SPNEGO would likely be benefical, but also > quite challenging, i.e. dealing with mechanism-specific (lists of) hints > providing guidance to the client for selection of the most adequate > client credential (and gss-api mechanism)... I agree. this has prompted to the thinking of how to solve this in the most= efficient and generic way, and I am pondering ... -- Larry ________________________________ From: Martin Rex [mailto:martin.rex@sap.com] Sent: Wed 11/8/2006 12:54 PM To: Liqiang(Larry) Zhu Cc: martin.rex@sap.com; Stefan Santesson; tls@ietf.org Subject: Re: [TLS] SPNEGO over TLS - proposed new work item Liqiang wrote: > > In the proposal below encrypt() means Gss_Wrap(), the client generates a > random quality and uses GSS_Wrap() to encrypt that random quality and > send it to the server, that is the basis of the SPNEGO key exchange > algorithm. Note this does not changes anything in the TLS record layer, > the output of GSS_Wrap() is embedded in a TLS key exchange message. > > We understand SPNEGO does not support PROT_READY and we expect that > GSS_Wrap() won't be invoked until the context has been fully > established. OK. My confusion might be caused by the wording of the proposal, which talks about one single API call instead of an entire (GSS/SPNEGO) handshake with multiple message exchanges: > > > > - ClientKeyExchange message: After GSS initialize Security > > context call is done, the client calls GSS encrypt message > > to encrypt the premaster secret. NOTE: the ClientKeyExchange > > is always protected under the public key obtained from the > > Server cert. was this supposed to mean something like this: - ClientKeyExchange message: the client uses the message protection services from the directly preceding successfully completed GSS/SPNEGO handshake to additionally encrypt the premaster secret, i.e. using gss_wrap(conf=3Dtrue) to cryptographically link the gssapi authentication into the TLS handshake. > > We have received significant positive feedbacks so far. For example, we > will be able to save a message by using GSS_PRF() instead of GSS_Wrap(). gss_prf() is a fairly new optinal extension, and whether it is available is implementation defined. You should probably use distinct tls ciphersuite ids to identify which api call is used in order to provide interoperability with gssapi mechanisms that don't have gss_prf(). But what I'm wondering is the following: I keeps coming up everywhere--the decision of the client which authentication method to use might be far from simple/straightforward, and a rather simple ciphersuite id or mechanism OID might be insufficient for an adequate decision/selection. The existing client credential negotiation scheme in SSL/TLS is more flexible: the server sends an entire list of trusted CAs to the client, and the client uses it to determine whether it is in the posession of a suitable credential. Extending this scheme to SPNEGO would likely be benefical, but also quite challenging, i.e. dealing with mechanism-specific (lists of) hints providing guidance to the client for selection of the most adequate client credential (and gss-api mechanism)... -Martin --_000_A15AC0FBACD3464E95961F7C0BCD1FF010B7E93FEAEXMSGC307euro_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [TLS] SPNEGO over TLS - proposed new work item

We had a design meeting today to conclude discussions about this proposal that has surfaced during the IETF week.

 

As such the proposal has changed in the way that SPNEGO has = been removed from the proposal and replaced with  direct exchange of GSS-AP= I tokens.

The slides for the presentation tomorrow has been sent to Er= ic and should be up on the meeting materials page before the TLS meeting.=

 

A first draft will be available for consideration short afte= r this IETF and Jeff Altman has agreed to help as co-editor.

 

 

Stefan Santesson

Senior Program Manager

Windows Security, Standards<= span lang=3DEN-US style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif"; color:#1F497D'>

 

From: Liqiang(Larry) Zhu
Sent: den 8 november 2006 16:38
To: martin.rex@sap.com
Cc: martin.rex@sap.com; Stefan Santesson; tls@ietf.org
Subject: RE: [TLS] SPNEGO over TLS - proposed new work item

 

 Mar= tin Rex wrote:

> = ; was this supposed to mean something like this:

 >     - ClientKeyExchange message: the client = uses the message
>        protection services from the directly preceding
 >       successfully completed GSS/S= PNEGO handshake
  >      to additionally encrypt the premaster secret, i.e. using
 >     gss_wrap(conf=3Dtrue) to cryptographical= ly link the
 >      gssapi authentication into the TLS handshake.

 

yes, this is what the initial proposal meant.

 

> gss_prf() is a f= airly new optinal extension, and whether it is available
> is implementation defined.  You should probably use distinct tls<= br> > ciphersuite ids to identify which api call is used in order to provide=
> interoperability with gssapi mechanisms that don't have gss_prf().

it should be fairly straightforward to implement PRF()= , but we may also define

another set of cipher suites where the key exchange does NOT use PRF(), rather just use GSS_Wrap().


> I keeps coming up everywhere--the dec= ision of the client which
> authentication method to use might be far from simple/straightforward,=
> and a rather simple ciphersuite id or mechanism OID might be
> insufficient for an adequate decision/selection.

 

this is an excellent point. Folks here do realize the = same issue here. the two negotiation layers (SPNEGO and TLS) should be coordinat= ed in some way, or do we need both negotiations? these are kinds of issues tha= t must be addressed when we have a draft.


> The existing client credential negoti= ation scheme in SSL/TLS is more
> flexible: the server sends an entire list of trusted CAs to the client= ,
> and the client uses it to determine whether it is in the posession
> of a suitable credential.

 

this argues for using= TLS negotiation mechanisms and removal of SPNEGO, if I understand this correctl= y. Either way, I can clearly see your points.

 

> Extending this s= cheme to SPNEGO would likely be benefical, but also
> quite challenging, i.e. dealing with mechanism-specific (lists of) hin= ts
> providing guidance to the client for selection of the most adequate > client credential (and gss-api mechanism)...

I agree. this has prompted to the thinking of how= to solve this in the most efficient and generic way, and I am pondering ...

 

-- Larry

From: Martin Rex [mailto:martin.rex@sap.com]<= br> Sent: Wed 11/8/2006 12:54 PM
To: Liqiang(Larry) Zhu
Cc: martin.rex@sap.com; Stefan Santesson; tls@ietf.org
Subject: Re: [TLS] SPNEGO over TLS - proposed new work item

Liqiang = wrote:
>
> In the proposal below encrypt() means Gss_Wrap(), the client generates= a
> random quality and uses GSS_Wrap() to encrypt that random quality and<= br> > send it to the server, that is the basis of the SPNEGO key exchange > algorithm. Note this does not changes anything in the TLS record layer= ,
> the output of GSS_Wrap() is embedded in a TLS key exchange message. >
> We understand SPNEGO does not support PROT_READY and we expect that > GSS_Wrap() won't be invoked until the context has been fully
> established.

OK.

My confusion might be caused by the wording of the proposal, which
talks about one single API call instead of an entire (GSS/SPNEGO)
handshake with multiple message exchanges:

> >
> >   - ClientKeyExchange message: After GSS initialize Security
> >     context call is done, the client calls GS= S encrypt message
> >     to encrypt the premaster secret. NOTE: th= e ClientKeyExchange
> >     is always protected under the public key obtained from the
> >     Server cert.

was this supposed to mean something like this:

      - ClientKeyExchange message: the client uses= the message
        protection services from the directly preceding
        successfully completed GSS/SPNEG= O handshake
        to additionally encrypt the premaster secret, i.e. using
        gss_wrap(conf=3Dtrue) to cryptog= raphically link the
        gssapi authentication into the T= LS handshake.
        
>
> We have received significant positive feedbacks so far. For example, w= e
> will be able to save a message by using GSS_PRF() instead of GSS_Wrap(= ).

gss_prf() is a fairly new optinal extension, and whether it is available is implementation defined.  You should probably use distinct tls
ciphersuite ids to identify which api call is used in order to provide
interoperability with gssapi mechanisms that don't have gss_prf().


But what I'm wondering is the following:
I keeps coming up everywhere--the decision of the client which
authentication method to use might be far from simple/straightforward,
and a rather simple ciphersuite id or mechanism OID might be
insufficient for an adequate decision/selection.

The existing client credential negotiation scheme in SSL/TLS is more
flexible: the server sends an entire list of trusted CAs to the client,
and the client uses it to determine whether it is in the posession
of a suitable credential.

Extending this scheme to SPNEGO would likely be benefical, but also
quite challenging, i.e. dealing with mechanism-specific (lists of) hints providing guidance to the client for selection of the most adequate
client credential (and gss-api mechanism)...


-Martin

--_000_A15AC0FBACD3464E95961F7C0BCD1FF010B7E93FEAEXMSGC307euro_-- --===============0101924214== 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 --===============0101924214==-- From tls-bounces@lists.ietf.org Fri Nov 10 14:42:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GicEo-0006mF-5g; Fri, 10 Nov 2006 14:40:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GicEm-0006lx-E4 for tls@ietf.org; Fri, 10 Nov 2006 14:40:28 -0500 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GicEl-00007u-1t for tls@ietf.org; Fri, 10 Nov 2006 14:40:28 -0500 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id UAA10572; Fri, 10 Nov 2006 20:40:19 +0100 (MEZ) From: Martin Rex Message-Id: <200611101940.UAA17935@uw1048.wdf.sap.corp> Subject: Re: [TLS] SPNEGO over TLS - proposed new work item To: stefans@microsoft.com (Stefan Santesson) Date: Fri, 10 Nov 2006 20:40:19 +0100 (MET) In-Reply-To: from "Stefan Santesson" at Nov 10, 6 03:34:47 am 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: 9466e0365fc95844abaf7c3f15a05c7d Cc: jaltman@secure-endpoints.com, 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 Stefan Santesson wrote: > > We had a design meeting today to conclude discussions about this proposal > that has surfaced during the IETF week. > > As such the proposal has changed in the way that SPNEGO has been removed > from the proposal and replaced with direct exchange of GSS-API tokens. > The slides for the presentation tomorrow has been sent to Eric and should > be up on the meeting materials page before the TLS meeting. > > A first draft will be available for consideration short after this IETF > and Jeff Altman has agreed to help as co-editor. A thought that came to me during todays tls meeting was the following: With exiting SSL/TLS (and -implementations), the authenticated peer becomes part of the SSL session state in the SSL session cache. When including an "external" authentication in the TLS handshake, what happens with the information about the authenicated peer, how is it "persistet", so that it will be transparently available when that SSL session is later resumed? Some features of existing GSS-API mechanisms (and future features, in particular about authorization attributes and subject alt name retrieval) might be extremely non-trivial to persist in the SSL session cache. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Nov 10 18:42:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gifym-0002uY-Oi; Fri, 10 Nov 2006 18:40:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gifyl-0002uN-E5 for tls@ietf.org; Fri, 10 Nov 2006 18:40:11 -0500 Received: from bay0-omc3-s29.bay0.hotmail.com ([65.54.246.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gifyj-00071I-TA for tls@ietf.org; Fri, 10 Nov 2006 18:40:11 -0500 Received: from BAY103-W4 ([65.54.174.104]) by bay0-omc3-s29.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 10 Nov 2006 15:40:09 -0800 X-Originating-IP: [208.114.202.64] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Stefan Santesson Subject: RE: [TLS] SPNEGO over TLS - proposed new work item Date: Fri, 10 Nov 2006 15:40:09 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 10 Nov 2006 23:40:09.0341 (UTC) FILETIME=[8EEE9AD0:01C70521] X-Spam-Score: 2.6 (++) X-Scan-Signature: 944ecb6e61f753561f559a497458fb4f 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="===============0157175377==" Errors-To: tls-bounces@lists.ietf.org --===============0157175377== Content-Type: multipart/alternative; boundary="_ba25bc00-0041-42c2-9736-cd6f02c8d700_" --_ba25bc00-0041-42c2-9736-cd6f02c8d700_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think, if work proceeds, there should be a parallel (minimal) effort, on = a revised https spec. It should state that "https" cannot use - in a confor= ming manner - "external" authentication mechanisms of TLS. =20 Nothing stops anyone defining another http/x protocol that embraces externa= l authentication techniques generally, or a specific external authenticatio= n technique such as offline kerberos. However, we need to keep the brand va= lue of "https" clear - not necessarily allowing all features in TLS to be m= ade available via the https moniker. > From: martin.rex@sap.com> Subject: Re: [TLS] SPNEGO over TLS - proposed n= ew work item> To: stefans@microsoft.com> Date: Fri, 10 Nov 2006 20:40:19 +0= 100> CC: jaltman@secure-endpoints.com; tls@ietf.org> > Stefan Santesson wro= te:> > > > We had a design meeting today to conclude discussions about this= proposal> > that has surfaced during the IETF week.> > > > As such the pro= posal has changed in the way that SPNEGO has been removed> > from the propo= sal and replaced with direct exchange of GSS-API tokens.> > The slides for = the presentation tomorrow has been sent to Eric and should> > be up on the = meeting materials page before the TLS meeting.> > > > A first draft will be= available for consideration short after this IETF> > and Jeff Altman has a= greed to help as co-editor.> > A thought that came to me during todays tls = meeting was the following:> > With exiting SSL/TLS (and -implementations), = the authenticated peer> becomes part of the SSL session state in the SSL se= ssion cache.> > When including an "external" authentication in the TLS hand= shake,> what happens with the information about the authenicated peer,> how= is it "persistet", so that it will be transparently available> when that S= SL session is later resumed?> > Some features of existing GSS-API mechanism= s (and future features,> in particular about authorization attributes and s= ubject alt name> retrieval) might be extremely non-trivial to persist in th= e> SSL session cache.> > -Martin> > _______________________________________= ________> TLS mailing list> TLS@lists.ietf.org> https://www1.ietf.org/mailm= an/listinfo/tls _________________________________________________________________ Use Messenger to talk to your IM friends, even those on Yahoo! http://ideas.live.com/programpage.aspx?versionId=3D7adb59de-a857-45ba-81cc-= 685ee3e858fe= --_ba25bc00-0041-42c2-9736-cd6f02c8d700_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable


I think, if work proceeds, there should be a parallel (mi= nimal) effort, on a revised https spec. It should state that "https" cannot= use - in a conforming manner - "external" authentication mechanisms of TLS= .
 
Nothing stops anyone defining another http/x protocol that embraces externa= l authentication techniques generally, or a specific external authenticatio= n technique such as offline kerberos. However, we need to keep the brand va= lue of "https" clear - not necessarily allowing all features in TLS to be m= ade available via the https moniker.


> From: martin.rex@sap.com
> Subject: Re: [TLS] SPNEGO over TLS - = proposed new work item
> To: stefans@microsoft.com
> Date: Fri,= 10 Nov 2006 20:40:19 +0100
> CC: jaltman@secure-endpoints.com; tls@i= etf.org
>
> Stefan Santesson wrote:
> >
> >= We had a design meeting today to conclude discussions about this proposal<= BR>> > that has surfaced during the IETF week.
> >
> = > As such the proposal has changed in the way that SPNEGO has been remov= ed
> > from the proposal and replaced with direct exchange of GSS-= API tokens.
> > The slides for the presentation tomorrow has been = sent to Eric and should
> > be up on the meeting materials page be= fore the TLS meeting.
> >
> > A first draft will be avai= lable for consideration short after this IETF
> > and Jeff Altman = has agreed to help as co-editor.
>
> A thought that came to me= during todays tls meeting was the following:
>
> With exiting= SSL/TLS (and -implementations), the authenticated peer
> becomes par= t of the SSL session state in the SSL session cache.
>
> When = including an "external" authentication in the TLS handshake,
> what h= appens with the information about the authenicated peer,
> how is it = "persistet", so that it will be transparently available
> when that S= SL session is later resumed?
>
> Some features of existing GSS= -API mechanisms (and future features,
> in particular about authoriza= tion attributes and subject alt name
> retrieval) might be extremely = non-trivial to persist in the
> SSL session cache.
>
> -= Martin
>
> _______________________________________________
= > TLS mailing list
> TLS@lists.ietf.org
> https://www1.ietf.= org/mailman/listinfo/tls


Use Messenger to talk to your I= M friends, even those on Yahoo! Ta= lk now! = --_ba25bc00-0041-42c2-9736-cd6f02c8d700_-- --===============0157175377== 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 --===============0157175377==-- From tls-bounces@lists.ietf.org Fri Nov 10 22:20:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GijNH-0008Cj-S9; Fri, 10 Nov 2006 22:17:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GijNG-0008CV-Du for tls@ietf.org; Fri, 10 Nov 2006 22:17:42 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GijNE-0005w6-Vm for tls@ietf.org; Fri, 10 Nov 2006 22:17:42 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id EAA29352; Sat, 11 Nov 2006 04:17:36 +0100 (MEZ) From: Martin Rex Message-Id: <200611110317.EAA09099@uw1048.wdf.sap.corp> Subject: Re: [TLS] SPNEGO over TLS - proposed new work item To: martin.rex@sap.com Date: Sat, 11 Nov 2006 04:17:31 +0100 (MET) In-Reply-To: <200611101940.UAA17935@uw1048.wdf.sap.corp> from "Martin Rex" at Nov 10, 6 08:40:19 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: 4b800b1eab964a31702fa68f1ff0e955 Cc: jaltman@secure-endpoints.com, 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 Followup on myself... Martin Rex wrote: > > Stefan Santesson wrote: > > > > As such the proposal has changed in the way that SPNEGO has been removed > > from the proposal and replaced with direct exchange of GSS-API tokens. > > The slides for the presentation tomorrow has been sent to Eric and should > > be up on the meeting materials page before the TLS meeting. > > A thought that came to me during todays tls meeting was the following: > > With exiting SSL/TLS (and -implementations), the authenticated peer > becomes part of the SSL session state in the SSL session cache. I meant the peers cert and cert chain (when one was sent) becomes part of the SSL session. > > When including an "external" authentication in the TLS handshake, > what happens with the information about the authenicated peer, > how is it "persistet", so that it will be transparently available > when that SSL session is later resumed? > > Some features of existing GSS-API mechanisms (and future features, > in particular about authorization attributes and subject alt name > retrieval) might be extremely non-trivial to persist in the > SSL session cache. At first glance, one may think about using "gss_export_sec_context()" and "gss_import_sec_context()". But even when using the transfered context only to retrieve information about the authenticated identity on session resume, it may not work. potential problems: - SSL sessions can be forked in high numbers (and it is actually the most interesting feature of SSL session caching), while it is undefined whether a exported gssapi security context can be imported more than once. It may work for many pure user-space library implementations of gssapi mechanisms. - Even if it does work (not covered by the GSS-API v2 spec), the actual use of message protection facilities on a duplicated and multiple times imported security context token will likely have serious security implications, like re-use of same crypto-keys with same sequence numbers, and in the case of symmetric stream ciphers for confidentiality protection, the exact same keystream may get used over and over again... - weird things like Microsoft's impersonation model might become tricky to implement. - credential delegation within gss-api will not work in a straightforward fashion -- how does the application recieve the gssapi cred handle and how can it later release it. How will multiple import of an exported security context token affect a delegated credential? A TLS-integrated (instead of HTTP-based GSS-API authentication) will also not work with existing SSL accellerators, and create a burdon for server-side (=reverse) proxies/loadbalancers. Btw. for large AppServers there are real performance benefits when the client authentication is not performed at the TLS layer (and **NOT** tied to the TLS channel) but instead at the HTTP or application level. The processing load (including the costly client authenication) can be much better loadbalanced to a farm of backend servers. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 15 20:07:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkVgI-0007VW-RA; Wed, 15 Nov 2006 20:04:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkVgH-0007Uq-Dg for tls@lists.ietf.org; Wed, 15 Nov 2006 20:04:41 -0500 Received: from proof.pobox.com ([207.106.133.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkVgE-0007gb-72 for tls@lists.ietf.org; Wed, 15 Nov 2006 20:04:41 -0500 Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id 3A8B923FAF for ; Wed, 15 Nov 2006 20:04:37 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id E831692A1D for ; Wed, 15 Nov 2006 20:04:36 -0500 (EST) Message-ID: <455BB8BC.2060403@pobox.com> Date: Wed, 15 Nov 2006 17:02:52 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@lists.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [TLS] Truncated HMAC 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 Hello, I have a question regarding the truncated HMAC extension. When this extension is negotiated, the spec says that CipherSpec.hash_size is 10 bytes. So does that mean I should only generate 10 bytes for each MAC secret? Thanks, Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 16 12:06:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkkfW-0007EC-J1; Thu, 16 Nov 2006 12:04:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkkfU-0007Dy-PV for tls@ietf.org; Thu, 16 Nov 2006 12:04:52 -0500 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkkfT-00076E-BI for tls@ietf.org; Thu, 16 Nov 2006 12:04:52 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAGH4RUw016553 for ; Thu, 16 Nov 2006 19:04:42 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 18:59:02 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 18:59:02 +0200 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: Thu, 16 Nov 2006 18:59:01 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: TLS minutes Thread-Index: AccJoIPxVOAsAJ3aQvG0jVSBMwUqKg== From: To: X-OriginalArrivalTime: 16 Nov 2006 16:59:03.0041 (UTC) FILETIME=[84C72710:01C709A0] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [TLS] TLS minutes 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 uploaded the first draft of TLS minutes to the meeting materials site: http://www3.ietf.org/proceedings/06nov/minutes/tls.txt If you have any additions or corrections, send them to me and Eric. And special thanks to Paul Hoffman and Tero Kivinen=20 for taking notes! Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 16 13:15:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gklkh-0007sX-Pj; Thu, 16 Nov 2006 13:14:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gklkg-0007sN-MZ for tls@ietf.org; Thu, 16 Nov 2006 13:14:18 -0500 Received: from ihemail4.lucent.com ([135.245.0.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gklkb-0000F8-B3 for tls@ietf.org; Thu, 16 Nov 2006 13:14:18 -0500 Received: from ihrh1.emsr.lucent.com (h135-1-218-53.lucent.com [135.1.218.53]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id kAGIE8r3004531; Thu, 16 Nov 2006 12:14:12 -0600 (CST) Received: from phal.lucentradius.com (phil.aaa.lucent.com [135.140.160.4]) by ihrh1.emsr.lucent.com (8.13.8/emsr) with ESMTP id kAGIE7Th018516; Thu, 16 Nov 2006 12:14:07 -0600 (CST) Received: from [135.140.160.28] (rocinante.lucentradius.com [135.140.160.28]) by phal.lucentradius.com (8.12.9+Sun/8.12.9) with ESMTP id kAGIE2Xk026544; Thu, 16 Nov 2006 10:14:06 -0800 (PST) Message-ID: <455CAA79.6080102@lucent.com> Date: Thu, 16 Nov 2006 10:14:17 -0800 From: Jan Nordqvist User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Rob Dugal Subject: Re: [TLS] TLS 1.1 and static DH References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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 Thank you. I will try it out as soon as I get a spare moment. Best regards, Jan Nordqvist Rob Dugal wrote: > > tls.secg.org has been updated to support DH ciphersuites. > The server now supports all ciphersuites (except PSK) of the Security > Builder SSL-C product. > > ----------------------------------------------- > Robert Dugal > Member of Development Group > Certicom Corp. > EMAIL: rdugal@certicom.com > PHONE: (905) 501-3848 > FAX : (905) 507-4230 > WEBSITE: www.certicom.com > > Jan Nordqvist wrote on 10/27/2006 05:57:46 PM: > > > Well, since at least we went through the effort of implementing them it > > would be nice to test them out too... > > OTOH, if no one else implements or uses them, they may be of little use > > in the real world. In any case, we are interested to get through > > testing, preferably both client and server side. > > > > Jan Nordqvist > > Lucent Technologies > > > > Rob Dugal wrote: > > > > > > The Certicom SSL-C product does contain implementations of static DH > > > ciphersuites. > > > We don't currently have a public server available for testing this > > > implementation. > > > If there is enough interest we can add these ciphersuites to > tls.secg.org > > > > > > > > > ----------------------------------------------- > > > 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 10/27/2006 05:30:31 AM: > > > > > > > Peter Gutmann wrote: > > > > > > > > > So perhaps the best option for TLS is to deprecate the static DH > > > > > suites. They seem to be pretty much entirely unsupported, and > even > > > > > if you did want to support them you'd end up in a quagmire from > > > > > which extrication would prove difficult. > > > > > > > > This question may become important if we want to progress TLS 1.2 to > > > > Draft Standard, where we need two interoperable implementations for > > > > every feature. > > > > > > > > Based on the discussion so far, it looks like static DH suites might > > > > be one feature where meeting that bar could be difficult. > > > > > > > > Any opinions from the WG about this? Should we e.g. remove static > > > > DH suites from TLS 1.2, move them to a separate document, or > > > > something else? > > > > > > > > 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 > > > > > > > > > _______________________________________________ > > 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 Nov 16 13:51:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkmJy-0001BG-UE; Thu, 16 Nov 2006 13:50:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkmJx-0001Aa-6C for tls@ietf.org; Thu, 16 Nov 2006 13:50:45 -0500 Received: from [38.113.160.194] (helo=mail.ca.certicom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkmJr-0003wr-OM for tls@ietf.org; Thu, 16 Nov 2006 13:50:45 -0500 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 718E710696AC4; Thu, 16 Nov 2006 12:37:32 -0500 (EST) 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 09270-93; Thu, 16 Nov 2006 12:37:16 -0500 (EST) Received: from domino1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 6BF80106842FD; Thu, 16 Nov 2006 12:37:16 -0500 (EST) In-Reply-To: <454280DA.10000@lucent.com> To: Jan Nordqvist Subject: Re: [TLS] TLS 1.1 and static DH MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Rob Dugal Date: Thu, 16 Nov 2006 12:35:26 -0500 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 7.0.1|January 17, 2006) at 11/16/2006 12:35:31 PM, Serialize complete at 11/16/2006 12:35:31 PM X-Spam-Score: 0.5 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 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="===============1589111435==" Errors-To: tls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============1589111435== Content-Type: multipart/alternative; boundary="=_alternative 0060BD9385257228_=" This is a multipart message in MIME format. --=_alternative 0060BD9385257228_= Content-Type: text/plain; charset="US-ASCII" tls.secg.org has been updated to support DH ciphersuites. The server now supports all ciphersuites (except PSK) of the Security Builder SSL-C product. ----------------------------------------------- Robert Dugal Member of Development Group Certicom Corp. EMAIL: rdugal@certicom.com PHONE: (905) 501-3848 FAX : (905) 507-4230 WEBSITE: www.certicom.com Jan Nordqvist wrote on 10/27/2006 05:57:46 PM: > Well, since at least we went through the effort of implementing them it > would be nice to test them out too... > OTOH, if no one else implements or uses them, they may be of little use > in the real world. In any case, we are interested to get through > testing, preferably both client and server side. > > Jan Nordqvist > Lucent Technologies > > Rob Dugal wrote: > > > > The Certicom SSL-C product does contain implementations of static DH > > ciphersuites. > > We don't currently have a public server available for testing this > > implementation. > > If there is enough interest we can add these ciphersuites to tls.secg.org > > > > > > ----------------------------------------------- > > 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 10/27/2006 05:30:31 AM: > > > > > Peter Gutmann wrote: > > > > > > > So perhaps the best option for TLS is to deprecate the static DH > > > > suites. They seem to be pretty much entirely unsupported, and even > > > > if you did want to support them you'd end up in a quagmire from > > > > which extrication would prove difficult. > > > > > > This question may become important if we want to progress TLS 1.2 to > > > Draft Standard, where we need two interoperable implementations for > > > every feature. > > > > > > Based on the discussion so far, it looks like static DH suites might > > > be one feature where meeting that bar could be difficult. > > > > > > Any opinions from the WG about this? Should we e.g. remove static > > > DH suites from TLS 1.2, move them to a separate document, or > > > something else? > > > > > > 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 > > > > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls --=_alternative 0060BD9385257228_= Content-Type: text/html; charset="US-ASCII"
tls.secg.org has been updated to support DH ciphersuites.
The server now supports all ciphersuites (except PSK) of the Security Builder SSL-C product.

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

Jan Nordqvist <jnordqvist@lucent.com> wrote on 10/27/2006 05:57:46 PM:

> Well, since at least we went through the effort of implementing them it
> would be nice to test them out too...
> OTOH, if no one else implements or uses them, they may be of little use
> in the real world. In any case, we are interested to get through
> testing, preferably both client and server side.
>
> Jan Nordqvist
> Lucent Technologies
>
> Rob Dugal wrote:
> >
> > The Certicom SSL-C product does contain implementations of static DH
> > ciphersuites.
> > We don't currently have a public server available for testing this
> > implementation.
> > If there is enough interest we can add these ciphersuites to tls.secg.org
> >
> >
> > -----------------------------------------------
> > 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 10/27/2006 05:30:31 AM:
> >
> > > Peter Gutmann wrote:
> > >
> > > > So perhaps the best option for TLS is to deprecate the static DH
> > > > suites.  They seem to be pretty much entirely unsupported, and even
> > > > if you did want to support them you'd end up in a quagmire from
> > > > which extrication would prove difficult.
> > >
> > > This question may become important if we want to progress TLS 1.2 to
> > > Draft Standard, where we need two interoperable implementations for
> > > every feature.
> > >
> > > Based on the discussion so far, it looks like static DH suites might
> > > be one feature where meeting that bar could be difficult.
> > >
> > > Any opinions from the WG about this? Should we e.g. remove static
> > > DH suites from TLS 1.2, move them to a separate document, or
> > > something else?
> > >
> > > 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
> >  
>
>
> _______________________________________________
> TLS mailing list
> TLS@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls
 --=_alternative 0060BD9385257228_=-- --===============1589111435== 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 --===============1589111435==-- From tls-bounces@lists.ietf.org Thu Nov 16 14:32:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkmwj-00050I-GE; Thu, 16 Nov 2006 14:30:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkmwh-0004x3-VH for tls@lists.ietf.org; Thu, 16 Nov 2006 14:30:47 -0500 Received: from proof.pobox.com ([207.106.133.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkmwg-0004O0-PH for tls@lists.ietf.org; Thu, 16 Nov 2006 14:30:47 -0500 Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id 059F428D88 for ; Thu, 16 Nov 2006 14:31:08 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id B4E24958E6 for ; Thu, 16 Nov 2006 14:31:07 -0500 (EST) Message-ID: <455CBC17.40407@pobox.com> Date: Thu, 16 Nov 2006 11:29:27 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@lists.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [TLS] TLS 1.1 servers available for testing? 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 Hello, I've implemented TLS 1.1 and have not found any servers to test against. Can anyone point me to one? Thanks, Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 16 14:52:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GknGq-0000R9-FD; Thu, 16 Nov 2006 14:51:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GknGp-0000Qx-E0 for tls@lists.ietf.org; Thu, 16 Nov 2006 14:51:35 -0500 Received: from sd-green-bigip-207.dreamhost.com ([208.97.132.207] helo=swarthymail-a4.dreamhost.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GknGo-0000at-59 for tls@lists.ietf.org; Thu, 16 Nov 2006 14:51:35 -0500 Received: from [172.100.50.7] (unknown [64.154.219.132]) by swarthymail-a4.dreamhost.com (Postfix) with ESMTP id 5329C129A96; Thu, 16 Nov 2006 11:51:31 -0800 (PST) In-Reply-To: <455CBC17.40407@pobox.com> References: <455CBC17.40407@pobox.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <235855A8-EA71-48D7-BC40-C609C2E03877@gnu.org> From: Casey Marshall Subject: Re: [TLS] TLS 1.1 servers available for testing? Date: Thu, 16 Nov 2006 11:51:15 -0800 To: Mike X-Pgp-Agent: GPGMail 1.1.2 (Tiger) X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: tls@lists.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="===============0745516616==" Errors-To: tls-bounces@lists.ietf.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --===============0745516616== Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Apple-Mail-1-715882481" Content-Transfer-Encoding: 7bit This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --Apple-Mail-1-715882481 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed On Nov 16, 2006, at 11:29 AM, Mike wrote: > Hello, > > I've implemented TLS 1.1 and have not found any > servers to test against. Can anyone point me > to one? > GNU Classpath supports TLS 1.1 in the "generics-branch" branch of CVS. We're due to make a developer snapshot sometime soon. Recent versions of GnuTLS support TLS 1.1. It is rather easy to start a simple test server with GnuTLS. HTH. --Apple-Mail-1-715882481 content-type: application/pgp-signature; x-mac-type=70674453; name=PGP.sig content-description: This is a digitally signed message part content-disposition: inline; filename=PGP.sig content-transfer-encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iQEVAwUBRVzBPeRILCRAfKHCAQJTjwgAnlYfJCm/KLUJjSwBMa2Xt2J8Qetx159h asnqHeo/wq3W4YaVNp9omO0wnCrXrCgsMouk+TsxNi1pgoPO1kUqFde8Ocl3/vOy wbDJ8aldO1gMIF4SZuLf5Shl6/0KuGOCE05xWHVFUyTebEUULGbD1MP2gWLLNGRf h1XX2VgzAPfeu6y4ZPDoElbMyNuDRINcaal8iC3xb6fK/HdvnZVD2h0FJ/RN18uG XDiheuFj+al/JHP1hCuGQxVuDVaH0nivgHGG86atA3ChrqCWinvvnyH3EEWsAxqK j59GPtofqLnObS9KY9FwjIZCmi2K5RIDB7qAWRre8IkDSi5kID/rlQ== =2dJg -----END PGP SIGNATURE----- --Apple-Mail-1-715882481-- --===============0745516616== 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 --===============0745516616==-- From tls-bounces@lists.ietf.org Thu Nov 16 15:02:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GknQg-0005AZ-Ha; Thu, 16 Nov 2006 15:01:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GknQe-00057N-FC for tls@lists.ietf.org; Thu, 16 Nov 2006 15:01:44 -0500 Received: from [38.113.160.194] (helo=mail.ca.certicom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GknQd-0002bL-5o for tls@lists.ietf.org; Thu, 16 Nov 2006 15:01:44 -0500 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id DB5B31069BC74; Thu, 16 Nov 2006 15:01:29 -0500 (EST) 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 13173-17; Thu, 16 Nov 2006 15:01:27 -0500 (EST) Received: from domino1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 95DAB1069BC73; Thu, 16 Nov 2006 15:01:27 -0500 (EST) In-Reply-To: <455CBC17.40407@pobox.com> To: Mike Subject: Re: [TLS] TLS 1.1 servers available for testing? MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Rob Dugal Date: Thu, 16 Nov 2006 14:59:37 -0500 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 7.0.1|January 17, 2006) at 11/16/2006 02:59:42 PM, Serialize complete at 11/16/2006 02:59:42 PM X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: tls@lists.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="===============0444447282==" Errors-To: tls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============0444447282== Content-Type: multipart/alternative; boundary="=_alternative 006DF0B585257228_=" This is a multipart message in MIME format. --=_alternative 006DF0B585257228_= Content-Type: text/plain; charset="US-ASCII" tls.secg.org ----------------------------------------------- Robert Dugal Member of Development Group Certicom Corp. EMAIL: rdugal@certicom.com PHONE: (905) 501-3848 FAX : (905) 507-4230 WEBSITE: www.certicom.com Mike wrote on 11/16/2006 02:29:27 PM: > Hello, > > I've implemented TLS 1.1 and have not found any > servers to test against. Can anyone point me > to one? > > Thanks, > > Mike > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls --=_alternative 006DF0B585257228_= Content-Type: text/html; charset="US-ASCII"
tls.secg.org

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

Mike <mike-list@pobox.com> wrote on 11/16/2006 02:29:27 PM:

> Hello,
>
> I've implemented TLS 1.1 and have not found any
> servers to test against.  Can anyone point me
> to one?
>
> Thanks,
>
> Mike
>
> _______________________________________________
> TLS mailing list
> TLS@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls
 --=_alternative 006DF0B585257228_=-- --===============0444447282== 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 --===============0444447282==-- From tls-bounces@lists.ietf.org Thu Nov 16 15:18:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkngE-0004G0-Qr; Thu, 16 Nov 2006 15:17:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkngC-0004Fm-S2 for tls@lists.ietf.org; Thu, 16 Nov 2006 15:17:48 -0500 Received: from sd-green-bigip-207.dreamhost.com ([208.97.132.207] helo=swarthymail-a1.dreamhost.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkngB-00067U-Ka for tls@lists.ietf.org; Thu, 16 Nov 2006 15:17:48 -0500 Received: from [172.100.50.7] (unknown [64.154.219.132]) by swarthymail-a1.dreamhost.com (Postfix) with ESMTP id 28B2F911D4; Thu, 16 Nov 2006 12:17:47 -0800 (PST) In-Reply-To: <455BB8BC.2060403@pobox.com> References: <455BB8BC.2060403@pobox.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2F0DED62-93B3-47AE-8397-434CC8208F02@gnu.org> Content-Transfer-Encoding: 7bit From: Casey Marshall Subject: Re: [TLS] Truncated HMAC Date: Thu, 16 Nov 2006 12:17:42 -0800 To: Mike X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: tls@lists.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 Nov 15, 2006, at 5:02 PM, Mike wrote: > Hello, > > I have a question regarding the truncated HMAC extension. > When this extension is negotiated, the spec says that > CipherSpec.hash_size is 10 bytes. So does that mean I > should only generate 10 bytes for each MAC secret? > From RFC 4366, section 3.5: "Note that this extension does not affect the calculation of the pseudo-random function (PRF) as part of handshaking or key derivation." _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 16 15:34:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gknuw-0005UT-1m; Thu, 16 Nov 2006 15:33:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gknuu-0005Si-Kj for tls@lists.ietf.org; Thu, 16 Nov 2006 15:33:00 -0500 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gknuo-0000oE-OZ for tls@lists.ietf.org; Thu, 16 Nov 2006 15:33:00 -0500 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id AACBC93815 for ; Thu, 16 Nov 2006 15:33:15 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id 51EA2936E9 for ; Thu, 16 Nov 2006 15:33:15 -0500 (EST) Message-ID: <455CCAA8.7040603@pobox.com> Date: Thu, 16 Nov 2006 12:31:36 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] Truncated HMAC References: <455BB8BC.2060403@pobox.com> <2F0DED62-93B3-47AE-8397-434CC8208F02@gnu.org> In-Reply-To: <2F0DED62-93B3-47AE-8397-434CC8208F02@gnu.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 Casey Marshall wrote: > On Nov 15, 2006, at 5:02 PM, Mike wrote: > >> I have a question regarding the truncated HMAC extension. >> When this extension is negotiated, the spec says that >> CipherSpec.hash_size is 10 bytes. So does that mean I >> should only generate 10 bytes for each MAC secret? > > From RFC 4366, section 3.5: > > "Note that this extension does not affect the calculation of the > pseudo-random function (PRF) as part of handshaking or key derivation." I saw that, but interpreted it to mean that the HMAC used in the PRF itself is not truncated. It is still unclear to me whether saying "CipherSpec.hash_size = 10" means that the MAC secrets should be 10 bytes. My implementation currently computes the MAC secrets the same whether HMAC truncation is specified or not. However, I think the spec. could be clarified to say that the secrets are not reduced to 10 bytes (if that's the intention). I suggest getting rid of the statement that CipherSpec.hash_size changes when the extension is used. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 16 16:23:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkogv-00083p-36; Thu, 16 Nov 2006 16:22:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkogt-00083h-Hr for tls@lists.ietf.org; Thu, 16 Nov 2006 16:22:35 -0500 Received: from mailbigip.dreamhost.com ([208.97.132.5] helo=swarthymail-a5.dreamhost.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkogq-000166-0a for tls@lists.ietf.org; Thu, 16 Nov 2006 16:22:35 -0500 Received: from [172.100.50.7] (unknown [64.154.219.132]) by swarthymail-a5.dreamhost.com (Postfix) with ESMTP id 07825109EB0; Thu, 16 Nov 2006 13:22:28 -0800 (PST) In-Reply-To: <455CCAA8.7040603@pobox.com> References: <455BB8BC.2060403@pobox.com> <2F0DED62-93B3-47AE-8397-434CC8208F02@gnu.org> <455CCAA8.7040603@pobox.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Casey Marshall Subject: Re: [TLS] Truncated HMAC Date: Thu, 16 Nov 2006 13:22:21 -0800 To: Mike X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: tls@lists.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 Nov 16, 2006, at 12:31 PM, Mike wrote: > Casey Marshall wrote: >> On Nov 15, 2006, at 5:02 PM, Mike wrote: >>> I have a question regarding the truncated HMAC extension. >>> When this extension is negotiated, the spec says that >>> CipherSpec.hash_size is 10 bytes. So does that mean I >>> should only generate 10 bytes for each MAC secret? >> From RFC 4366, section 3.5: >> "Note that this extension does not affect the calculation of the >> pseudo-random function (PRF) as part of handshaking or key >> derivation." > > I saw that, but interpreted it to mean that the HMAC used in the > PRF itself is not truncated. It is still unclear to me whether > saying "CipherSpec.hash_size = 10" means that the MAC secrets > should be 10 bytes. My implementation currently computes the > MAC secrets the same whether HMAC truncation is specified or not. > However, I think the spec. could be clarified to say that the > secrets are not reduced to 10 bytes (if that's the intention). > I suggest getting rid of the statement that CipherSpec.hash_size > changes when the extension is used. > But still, RFC 4346 says the key_block is split as: > client_write_MAC_secret[SecurityParameters.hash_size] > server_write_MAC_secret[SecurityParameters.hash_size] i.e., "CipherSpec.hash_size" isn't used here. I think the intention is that only the final MAC value sent in the record is truncated, and nothing else. This is certainly how my implementation works. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 16 16:27:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkokb-0000jF-MO; Thu, 16 Nov 2006 16:26:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkoka-0000ix-6G for tls@lists.ietf.org; Thu, 16 Nov 2006 16:26:24 -0500 Received: from mga03.intel.com ([143.182.124.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkokY-0001ls-SQ for tls@lists.ietf.org; Thu, 16 Nov 2006 16:26:24 -0500 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by mga03.intel.com with ESMTP; 16 Nov 2006 13:26:22 -0800 Received: from fmsmsx334.amr.corp.intel.com ([132.233.42.1]) by azsmga001.ch.intel.com with ESMTP; 16 Nov 2006 13:26:21 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,430,1157353200"; d="scan'208"; a="147561155:sNHT24435243" Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 13:26:21 -0800 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] Truncated HMAC Date: Thu, 16 Nov 2006 16:26:11 -0500 Message-ID: <279DDDAFA85EC74C9300A0598E704056F9145F@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Truncated HMAC thread-index: AccJvxNYysFU3W/ZTUGWEZ7sUhbbnAABNgRA From: "Blumenthal, Uri" To: "Mike" , X-OriginalArrivalTime: 16 Nov 2006 21:26:21.0465 (UTC) FILETIME=[DC6C7090:01C709C5] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 simply means that the *final output* of HMAC would be truncated to 10 bytes - but *not* that its input or key would be truncated in any way. -----Original Message----- From: Mike [mailto:mike-list@pobox.com]=20 Sent: Thursday, November 16, 2006 3:32 PM To: tls@lists.ietf.org Subject: Re: [TLS] Truncated HMAC Casey Marshall wrote: > On Nov 15, 2006, at 5:02 PM, Mike wrote: >=20 >> I have a question regarding the truncated HMAC extension. >> When this extension is negotiated, the spec says that >> CipherSpec.hash_size is 10 bytes. So does that mean I >> should only generate 10 bytes for each MAC secret? >=20 > From RFC 4366, section 3.5: >=20 > "Note that this extension does not affect the calculation of the=20 > pseudo-random function (PRF) as part of handshaking or key derivation." I saw that, but interpreted it to mean that the HMAC used in the PRF itself is not truncated. It is still unclear to me whether saying "CipherSpec.hash_size =3D 10" means that the MAC secrets should be 10 bytes. My implementation currently computes the MAC secrets the same whether HMAC truncation is specified or not. However, I think the spec. could be clarified to say that the secrets are not reduced to 10 bytes (if that's the intention). I suggest getting rid of the statement that CipherSpec.hash_size changes when the extension is used. Mike _______________________________________________ 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 Nov 16 17:55:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkq7W-00032E-R9; Thu, 16 Nov 2006 17:54:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gkq7V-00031v-PP for tls@lists.ietf.org; Thu, 16 Nov 2006 17:54:09 -0500 Received: from proof.pobox.com ([207.106.133.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gkq7S-0007oP-I9 for tls@lists.ietf.org; Thu, 16 Nov 2006 17:54:09 -0500 Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id A0D5C2B817 for ; Thu, 16 Nov 2006 17:54:00 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 644C092107 for ; Thu, 16 Nov 2006 17:54:00 -0500 (EST) Message-ID: <455CEBA9.2060205@pobox.com> Date: Thu, 16 Nov 2006 14:52:25 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] Truncated HMAC References: <455BB8BC.2060403@pobox.com> <2F0DED62-93B3-47AE-8397-434CC8208F02@gnu.org> <455CCAA8.7040603@pobox.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 > But still, RFC 4346 says the key_block is split as: > > > client_write_MAC_secret[SecurityParameters.hash_size] > > server_write_MAC_secret[SecurityParameters.hash_size] > > i.e., "CipherSpec.hash_size" isn't used here. I think the intention is > that only the final MAC value sent in the record is truncated, and > nothing else. This is certainly how my implementation works. Ok, so my implementation is correct then. I still think that the spec. could be clearer in stating that SecurityParameters. hash_size is not affected. Or change CipherSpec.hash_size to CipherSpec.mac_length to remove the confusion. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 16 19:06:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkrEM-0006S5-Ie; Thu, 16 Nov 2006 19:05:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GkrEL-0006QI-C0 for tls@lists.ietf.org; Thu, 16 Nov 2006 19:05:17 -0500 Received: from proof.pobox.com ([207.106.133.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GkrEK-0002La-64 for tls@lists.ietf.org; Thu, 16 Nov 2006 19:05:17 -0500 Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id 16EAA2B3B0 for ; Thu, 16 Nov 2006 19:05:10 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id D37538CDA6 for ; Thu, 16 Nov 2006 19:05:09 -0500 (EST) Message-ID: <455CFC56.3070400@pobox.com> Date: Thu, 16 Nov 2006 16:03:34 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] Truncated HMAC References: <279DDDAFA85EC74C9300A0598E704056F9145F@hdsmsx412.amr.corp.intel.com> In-Reply-To: <279DDDAFA85EC74C9300A0598E704056F9145F@hdsmsx412.amr.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 simply means that the *final output* of HMAC would be truncated to 10 > bytes - but *not* that its input or key would be truncated in any way. Then I would propose changing "CipherSpec.hash_size" to CipherSpec.mac_length so that "hash_size" does not have two related but different meanings. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 16 21:53:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gktpc-00083H-Ro; Thu, 16 Nov 2006 21:51:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gktpa-0007y7-QF for tls@lists.ietf.org; Thu, 16 Nov 2006 21:51:54 -0500 Received: from mga01.intel.com ([192.55.52.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GktpX-00080F-Fs for tls@lists.ietf.org; Thu, 16 Nov 2006 21:51:54 -0500 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by mga01.intel.com with ESMTP; 16 Nov 2006 18:51:48 -0800 Received: from fmsmsx333.amr.corp.intel.com ([132.233.42.2]) by fmsmga002.fm.intel.com with ESMTP; 16 Nov 2006 18:51:48 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,431,1157353200"; d="scan'208"; a="16839702:sNHT285657219" Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Nov 2006 18:51:48 -0800 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] Truncated HMAC Date: Thu, 16 Nov 2006 21:51:37 -0500 Message-ID: <279DDDAFA85EC74C9300A0598E704056F91551@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Truncated HMAC thread-index: AccJ3NLgsCSN+JG1QRem75QgfDbvwgAFc6Kg From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 17 Nov 2006 02:51:48.0907 (UTC) FILETIME=[53AF9FB0:01C709F3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 simply means that the *final output* of HMAC would be truncated to 10 >> bytes - but *not* that its input or key would be truncated in any way. > >Then I would propose changing "CipherSpec.hash_size" to=20 >CipherSpec.mac_length so that "hash_size" does not have >two related but different meanings. You see, strictly speaking it's the MAC size (output of HMAC) that gets truncated, not the hash size. I agree though that some clarification would be helpful. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Nov 17 05:28:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl0v2-00041p-HN; Fri, 17 Nov 2006 05:26:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gl0uz-00041i-IC for tls@ietf.org; Fri, 17 Nov 2006 05:25:57 -0500 Received: from sp.isima.fr ([193.55.95.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gl0uy-00076I-5k for tls@ietf.org; Fri, 17 Nov 2006 05:25:57 -0500 Received: from [127.0.0.1] (pc158.isima.fr [193.55.95.158]) by sp.isima.fr (8.9.3/jtpda-5.3.1) with ESMTP id LAA44842 ; Fri, 17 Nov 2006 11:21:32 +0100 Message-ID: <455D8D7B.10607@isima.fr> Date: Fri, 17 Nov 2006 11:22:51 +0100 From: badra User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [TLS] TLS minutes References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by sp.isima.fr id LAA44842 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Dear Pasi & all, I would like to recall that at Vancouver meeting, I presented alike Russ'= s proposal and I felt that participants to the TLS meeting don't agree on= doing non-repudiation and evidence generation at the TLS layer. Since I don't see in what way does Russ's proposal differ from http://www= .ietf.org/internet-drafts/draft-hajjeh-tls-sign-02.txt, I would like to h= ave WG feedbacks on the design of second draft. Best regards, Badra Pasi.Eronen@nokia.com a =E9crit : > I've uploaded the first draft of TLS minutes to the meeting > materials site: > > http://www3.ietf.org/proceedings/06nov/minutes/tls.txt > > If you have any additions or corrections, send them to me > and Eric. And special thanks to Paul Hoffman and Tero Kivinen=20 > for taking notes! > > Best regards, > Pasi > > _______________________________________________ > 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 Fri Nov 17 20:24:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlEud-0007Q9-Rf; Fri, 17 Nov 2006 20:22:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlEuc-0007Q2-ON for tls@ietf.org; Fri, 17 Nov 2006 20:22:30 -0500 Received: from laser.networkresonance.com ([198.144.196.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlEua-0002gN-Ep for tls@ietf.org; Fri, 17 Nov 2006 20:22:30 -0500 Received: from networkresonance.com (raman.networkresonance.com [198.144.196.3]) by laser.networkresonance.com (Postfix) with ESMTP id 142355C01E; Fri, 17 Nov 2006 17:25:32 -0800 (PST) To: saag@mit.edu, tls@ietf.org X-Mailer: MH-E 7.4.3; nmh 1.2; XEmacs 21.4 (patch 19) Date: Fri, 17 Nov 2006 17:22:27 -0800 From: Eric Rescorla Message-Id: <20061118012532.142355C01E@laser.networkresonance.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Subject: [TLS] IETF67 TLS 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 TLS met on Friday morning. The major discussion item was TLS 1.2, which is moving along. The only contentious issue is the PRF. The general theory seemed to be to have a default PRF (based on SHA-256) and then require future cipher suites to define their own PRF with a preference for something based on the TLS PRF. We also discussed the IV for counter mode and GCM but no consensus was reached and the issue will be taken to the list. Pasi Eronen presented on a bunch of bugs in the way that TLS stacks handle legal but unusual record layer constructs. These don't appear to be security issues but rather interop issues. It was suggested that TLS 1.2 forbid some unusual behaviors (e.g., empty fragments in the handshake). Text will be proposed on the list. Russ Housley gave a presentation on adding signatures to TLS for evidentiary purposes. This was somewhat contentious but the WG seemed generally in favor. This would require a charter change and discussion on the list. Tim Polk gave a presentation on some issues NIST had with TLS. Mostly these are minor issues or clarifications. Resolutions to be proposed on the list. Stefan Stantesson gave a presentation on an approach he's been working on for integrating GSS-API with TLS. This was quite contentious and no consensus seemed on hand. However, no actual draft is available so the next stage is for Stefan to circulate one. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Nov 18 12:58:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlUPa-00080a-Bo; Sat, 18 Nov 2006 12:55:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlUPZ-00080V-58 for tls@ietf.org; Sat, 18 Nov 2006 12:55:29 -0500 Received: from bay0-omc2-s21.bay0.hotmail.com ([65.54.246.157]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlUPW-0005Qe-G4 for tls@ietf.org; Sat, 18 Nov 2006 12:55:29 -0500 Received: from BAY103-W1 ([65.54.174.101]) by bay0-omc2-s21.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Nov 2006 09:53:44 -0800 X-Originating-IP: [71.140.81.171] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Subject: RE: [TLS] IETF67 TLS Summary Date: Sat, 18 Nov 2006 09:53:44 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 18 Nov 2006 17:53:44.0579 (UTC) FILETIME=[7D8D9D30:01C70B3A] X-Spam-Score: 2.4 (++) X-Scan-Signature: ded6070f7eed56e10c4f4d0d5043d9c7 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="===============1636111045==" Errors-To: tls-bounces@lists.ietf.org --===============1636111045== Content-Type: multipart/alternative; boundary="_a32980fd-742f-4cdf-b2d5-1f27e1d536b6_" --_a32980fd-742f-4cdf-b2d5-1f27e1d536b6_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 After 10 year, all IETF WGs should automatic candidates for closure. PEM an= d PKIX were exceptions for lengetivity, because govt policies had long kept= crypto technology suppressed, and time was the necessary element for good = stuff to find its place in the Internet. TLS isnt in the PEM/PKIX category,= tho. SSL was just a remake of already standardized NSA stuff, based on a = well understood set of design principles for secure IP lans/wans, done way = back in 1989! Several folks posting here were part of it! I think TLS has had benefits, over SSL3, in the EAP wireless, wap and IM sp= ace; and I do think IETF added some value to SSL3 - measured in objective l= evels of adoption in non web spheres. I find the SAML extensions fascinatin= g, and have lots of applicability with a next generation https suiting web2= .0 worlds (done in non IETF forums, better suited to web standardization). = Kerberos assertions from a remote IDP presented in a SAML authorization, ca= rried in a TLS extensions, converted to a trusted identity for a secure OS = host relying on TLS security contexts to create a local TPM context control= ling how the secure realmode desktop experience in Windows in China is limi= ted by remote US policy..... these are all exciting and future thinking ide= as. But they are DARPA *research*, not modern-IETF *standardization* effort= s. =20 Making TLS into a generic endpoint of all upper layer services (just becaus= e https is pretty universally implemented and widespread in applicability) = is not appropriate. The GSS-API initiative is such an inappropriate initiat= ive; its wrongheaded, and doesn't simply solve a kerberos problem. Fix brok= en kerberos -for-internet ciphersuites by all means (they have been broken = ever since introduced in 1995!), but dont - via TLS standardization - make = https into a universal bearer for all authentication techniques that have n= o design addressing the specific dynamics of the hypermedia world. Similarl= y, with signed evidence, make TLS handshakes participate in the surveillanc= e and eavesdropping world that Americans live in, so ISPs can more easily p= rove that their infrastructures satisfy the spying culture mandates. This i= s good for the Internet Society, continues the debate over those difficult = political issues, and will lead to an increased adoption of the "trusted In= ternet" into mainstream US society. But, lets not just create work items fo= r the sake it it. =20 TLS WG is looking very tired, speaking as a well-meaning, well-informed SSL= outsider, peeking in, occasionally. Ignore the comments, as one sees fit. = In my view, however, its time to create new work groups addressing TLS spin= offs, only when needed, with new leadership dynamics - assuming there is so= me real groundswell momentum that needs the magical IETF process to then do= its usual thing. Right now, it really looks like old money for old rope ty= ing up old problems, anew. =20 =20 > To: saag@mit.edu; tls@ietf.org> Date: Fri, 17 Nov 2006 17:22:27 -0800> Fr= om: ekr@networkresonance.com> CC: > Subject: [TLS] IETF67 TLS Summary> > TL= S met on Friday morning.> > The major discussion item was TLS 1.2, which is= moving along. The only> contentious issue is the PRF. The general theory s= eemed to be to have a> default PRF (based on SHA-256) and then require futu= re cipher suites to> define their own PRF with a preference for something b= ased on the TLS> PRF. We also discussed the IV for counter mode and GCM but= no consensus> was reached and the issue will be taken to the list.> > Pasi= Eronen presented on a bunch of bugs in the way that TLS stacks> handle leg= al but unusual record layer constructs. These don't appear to> be security = issues but rather interop issues. It was suggested that TLS> 1.2 forbid som= e unusual behaviors (e.g., empty fragments in the> handshake). Text will be= proposed on the list.> > Russ Housley gave a presentation on adding signat= ures to TLS for> evidentiary purposes. This was somewhat contentious but th= e WG seemed> generally in favor. This would require a charter change and di= scussion> on the list.> > Tim Polk gave a presentation on some issues NIST = had with TLS. Mostly> these are minor issues or clarifications. Resolutions= to be proposed on> the list.> > Stefan Stantesson gave a presentation on a= n approach he's been working> on for integrating GSS-API with TLS. This was= quite contentious and no> consensus seemed on hand. However, no actual dra= ft is available so the> next stage is for Stefan to circulate one.> > -Ekr>= > > > > > _______________________________________________> TLS mailing lis= t> TLS@lists.ietf.org> https://www1.ietf.org/mailman/listinfo/tls _________________________________________________________________ Check the weather nationwide with MSN Search: Try it now! http://search.msn.com/results.aspx?q=3Dweather&FORM=3DWLMTAG= --_a32980fd-742f-4cdf-b2d5-1f27e1d536b6_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable  
After 10 year, all IETF WGs should automatic candidates for closure. PEM an= d PKIX were exceptions for lengetivity, because govt policies had long kept= crypto technology suppressed, and time was the necessary element for good = stuff to find its place in the Internet. TLS isnt in the PE= M/PKIX category, tho. SSL was just a remake of already standardized NSA stu= ff,  based on a well understood set of design principles for secure IP= lans/wans, done way back in 1989! Several folks posting here were part of = it!

I think TLS has had benefits, over SSL3, in the EAP wireless, wap and IM sp= ace; and I do think IETF added some value to SSL3 - measured in objective l= evels of adoption in non web spheres. I find the SAML extensions fasci= nating, and have lots of applicability with a next generation https suiting= web2.0 worlds (done in non IETF forums, better suited to web standardizati= on). Kerberos assertions from a remote IDP presented in a SAML authori= zation, carried in a TLS extensions, converted to a trusted identity for a = secure OS host relying on TLS security contexts to create a local TPM conte= xt controlling how the secure realmode desktop experience in Windows i= n China is limited by remote US policy..... these are all exciting and futu= re thinking ideas. But they are DARPA *research*, not modern-IETF *standard= ization* efforts.
 
Making TLS into a generic endpoint of all upper layer services (just b= ecause https is pretty universally implemented and widespread in applicabil= ity) is not appropriate. The GSS-API initiative is such an inappropriate in= itiative; its wrongheaded, and doesn't simply solve a kerberos problem. Fix= broken kerberos -for-internet ciphersuites by all means (they have been br= oken ever since introduced in 1995!), but dont - via TLS standardization -&= nbsp;make https into a universal bearer for all authentication techniques t= hat have no design addressing the specific dynamics of the hypermedia world= . Similarly, with signed evidence, make TLS handshakes participate in the s= urveillance and eavesdropping world that Americans live in, so ISPs can mor= e easily prove that their infrastructures satisfy the spying culture m= andates. This is good for the Internet Society, continues the debate over t= hose difficult political issues, and will lead to an increased adoptio= n of the "trusted Internet" into mainstream US society. But, lets not just = create work items for the sake it it.
 
TLS WG is looking very tired, speaking as a well-meaning, well-informe= d SSL outsider, peeking in, occasionally. Ignore the comments, as one = sees fit. In my view, however, its time to create new work groups addressin= g TLS spinoffs, only when needed, with new leadership dynamics - assuming t= here is some real groundswell momentum that needs the magical IETF process = to then do its usual thing. Right now, it really looks like old money for o= ld rope tying up old problems, anew.
 
 

> To: saag@mit.edu; tls@ietf.org
> Date: Fri, 17 Nov 2006 17:22:27= -0800
> From: ekr@networkresonance.com
> CC:
> Subject:= [TLS] IETF67 TLS Summary
>
> TLS met on Friday morning.
&g= t;
> The major discussion item was TLS 1.2, which is moving along. T= he only
> contentious issue is the PRF. The general theory seemed to = be to have a
> default PRF (based on SHA-256) and then require future= cipher suites to
> define their own PRF with a preference for someth= ing based on the TLS
> PRF. We also discussed the IV for counter mode= and GCM but no consensus
> was reached and the issue will be taken t= o the list.
>
> Pasi Eronen presented on a bunch of bugs in th= e way that TLS stacks
> handle legal but unusual record layer constru= cts. These don't appear to
> be security issues but rather interop is= sues. It was suggested that TLS
> 1.2 forbid some unusual behaviors (= e.g., empty fragments in the
> handshake). Text will be proposed on t= he list.
>
> Russ Housley gave a presentation on adding signat= ures to TLS for
> evidentiary purposes. This was somewhat contentious= but the WG seemed
> generally in favor. This would require a charter= change and discussion
> on the list.
>
> Tim Polk gave = a presentation on some issues NIST had with TLS. Mostly
> these are m= inor issues or clarifications. Resolutions to be proposed on
> the li= st.
>
> Stefan Stantesson gave a presentation on an approach h= e's been working
> on for integrating GSS-API with TLS. This was quit= e contentious and no
> consensus seemed on hand. However, no actual d= raft is available so the
> next stage is for Stefan to circulate one.=
>
> -Ekr
>
>
>
>
>
>= _______________________________________________
> TLS mailing list> TLS@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tl= s


Check the weather nationwide with MSN Search Try it now! = --_a32980fd-742f-4cdf-b2d5-1f27e1d536b6_-- --===============1636111045== 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 --===============1636111045==-- From tls-bounces@lists.ietf.org Sat Nov 18 18:08:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlZH2-0003Hb-5M; Sat, 18 Nov 2006 18:07:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlZH0-0003H9-EW for TLS@lists.ietf.org; Sat, 18 Nov 2006 18:06:58 -0500 Received: from simmts5.bellnexxia.net ([206.47.199.163] helo=simmts5-srv.bellnexxia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlZGz-0002hc-4d for TLS@lists.ietf.org; Sat, 18 Nov 2006 18:06:58 -0500 Received: from pbo8f8e10aowa ([65.94.95.91]) by simmts5-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with SMTP id <20061118230649.PDKP21960.simmts5-srv.bellnexxia.net@pbo8f8e10aowa> for ; Sat, 18 Nov 2006 18:06:49 -0500 Message-ID: <003101c70b66$845f0d20$5b5f5e41@pbo8f8e10aowa> From: "O. Batyrbaev" To: Date: Sat, 18 Nov 2006 18:08:53 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Subject: [TLS] TLS load balancer 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, It seems to me that a TLS load balancer would first examine the client hello for the session ID so it can forward the connection to the appropriate TLS server that has this session in its cache (is this a deployment that is only seen in practice?). Then it would, I think, examine the TCP/IP parameters of the client and the server to forward the follow on TCP packets that underline the connection. Question arises how does the non-decrypting TLS load balancer would know when the connection ended (I recall that the close alerts are encrypted) so it can release its own resources allocated for the connection? What is the size of the most probable TCP packet data portion compared with the 2^14 bytes (maximum as in TLSPlaintext.fragment)? Or does the implementers encouraged to send one packet per fragment? What about https 1.1 "keep alive" option? Does this mean that the connection will stay alive until "keep alive" or session life time expires? And how this would affect a TLS load balancer? _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sat Nov 18 21:14:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlcAl-0006KN-Ld; Sat, 18 Nov 2006 21:12:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlcAk-0006KH-Lq for tls@ietf.org; Sat, 18 Nov 2006 21:12:42 -0500 Received: from bay0-omc2-s14.bay0.hotmail.com ([65.54.246.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlcAh-0007DG-9Q for tls@ietf.org; Sat, 18 Nov 2006 21:12:42 -0500 Received: from BAY103-W4 ([65.54.174.104]) by bay0-omc2-s14.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 18 Nov 2006 18:12:39 -0800 X-Originating-IP: [71.140.81.171] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Date: Sat, 18 Nov 2006 18:12:38 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 19 Nov 2006 02:12:39.0076 (UTC) FILETIME=[2FE75E40:01C70B80] X-Spam-Score: 2.6 (++) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: Subject: [TLS] comment on null encryption ciphersuite; https RFC amendment ...to compensate 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="===============1505156177==" Errors-To: tls-bounces@lists.ietf.org --===============1505156177== Content-Type: multipart/alternative; boundary="_9b3f639a-d582-4e62-8952-6cdba5c8be9a_" --_9b3f639a-d582-4e62-8952-6cdba5c8be9a_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm EXTREMELY worried socially about an IAB-endorsement of the null encrypt= ion ciphersuite for TLS. Whilst I recognize its value, on the stated merits= , I think we need a political balance addressing issues beyond IETF's scope= . Too many consumers are potentially going to be duped by the millions of w= ell-meant but potentially incorrect e-commerce website representations whi= ch today affirm that "SSL protects your credit-card data (via encryption et= c)". With the use of endorsed null encryption ciphersuites in TLS/SSL, that= is obviously not true (in any way grandma would understand). The average c= onsumer is trained to assume "SSL" (or TLS) protects your from obvious crim= inal activities, concerning pilfering credit card numbers. IAB activities = that destroy the brand name of SSL is something which is not worth the valu= e of endorsing the null-encryption ciphersuite, in my own view. =20 Perhaps the right balance for IAB/IESG is to to require that the https RFC = be simultaneously modified so that it makes it NON-CONFORMING for SSL/TLS i= n the https context to ever use the null encryption ciphersuites. Other URL= protocols can be registered with IANA that don't confuse consumers (e.g. h= ttpnos://1.1.1.1.6.5.4.2.0.2.enum.att.com/), which can even behave exactly = as https v.10 otherwise does, but allowing for a conforming use of the null= -encryption cipher suite.=20 =20 Peter =20 From: home_pw@msn.comTo: tls@ietf.orgSubject: RE: [TLS] IETF67 TLS SummaryD= ate: Sat, 18 Nov 2006 09:53:44 -0800CC:=20 _________________________________________________________________ Express yourself with gadgets on Windows Live Spaces http://discoverspaces.live.com?source=3Dhmtag1&loc=3Dus= --_9b3f639a-d582-4e62-8952-6cdba5c8be9a_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm EXTREMELY worried socially about an IAB-endorsement of the null e= ncryption ciphersuite for TLS. Whilst I recognize its value, on the stated = merits, I think we need a political balance addressing issues beyond IETF's= scope. Too many consumers are potentially going to be duped by the million= s of well-meant but potentially incorrect e-commerce website represent= ations  which today affirm that "SSL protects your credit-card data (v= ia encryption etc)". With the use of endorsed null encryption ciphersuites = in TLS/SSL, that is obviously not true (in any way grandma would understand= ). The average consumer is trained to assume "SSL" (or TLS) protects y= our from obvious criminal activities, concerning pilfering credit card numb= ers.  IAB activities that destroy the brand name of SSL is something w= hich is not worth the value of endorsing the null-encryption ciphersuite, i= n my own view.
 
Perhaps the right balance for IAB/IESG is to to require that the https RFC = be simultaneously modified so that it makes it NON-CONFORMING for SSL/TLS i= n the https context to ever use the null encryption ciphersuites. Other URL= protocols can be registered with IANA that don't confuse consumers (e.g. h= ttpnos://1.1.1.1.6.5.4.2.0.2.enum.att.com/), which can even behave exactly = as https v.10 otherwise does, but allowing for a conforming use of the= null-encryption cipher suite.
 
Peter
 
From: home_pw@msn.com
To: tls@ietf.org
Subject: RE: [TLS] IETF67 TLS = Summary
Date: Sat, 18 Nov 2006 09:53:44 -0800
CC:
Express yourself with gadgets on Windows Live Spaces Try= it! = --_9b3f639a-d582-4e62-8952-6cdba5c8be9a_-- --===============1505156177== 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 --===============1505156177==-- From tls-bounces@lists.ietf.org Sun Nov 19 10:17:29 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GloNk-0005kP-VO; Sun, 19 Nov 2006 10:14:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GloNk-0005kJ-64 for tls@ietf.org; Sun, 19 Nov 2006 10:14:56 -0500 Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GloNi-0005bO-RM for tls@ietf.org; Sun, 19 Nov 2006 10:14:56 -0500 Received: by delta.rtfm.com (Postfix, from userid 1001) id 45EDD1CC67; Sat, 18 Nov 2006 21:24:10 -0800 (PST) To: Peter Williams Subject: Re: [TLS] comment on null encryption ciphersuite; https RFC amendment ...to compensate References: From: EKR Date: Sat, 18 Nov 2006 21:24:09 -0800 In-Reply-To: (Peter Williams's message of "Sat, 18 Nov 2006 18:12:38 -0800") Message-ID: <86lkm8t3eu.fsf@delta.rtfm.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.2 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 Peter, This isn't an IAB issue. I suggest you raise it with the IESG: iesg@ietf.org -Ekr Peter Williams writes: > I'm EXTREMELY worried socially about an IAB-endorsement of the null > encryption ciphersuite for TLS. Whilst I recognize its value, on the > stated merits, I think we need a political balance addressing issues > beyond IETF's scope. Too many consumers are potentially going to be > duped by the millions of well-meant but potentially incorrect > e-commerce website representations which today affirm that "SSL > protects your credit-card data (via encryption etc)". With the use > of endorsed null encryption ciphersuites in TLS/SSL, that is > obviously not true (in any way grandma would understand). The > average consumer is trained to assume "SSL" (or TLS) protects your > from obvious criminal activities, concerning pilfering credit card > numbers. IAB activities that destroy the brand name of SSL is > something which is not worth the value of endorsing the > null-encryption ciphersuite, in my own view. > > Perhaps the right balance for IAB/IESG is to to require that the > https RFC be simultaneously modified so that it makes it > NON-CONFORMING for SSL/TLS in the https context to ever use the null > encryption ciphersuites. Other URL protocols can be registered with > IANA that don't confuse consumers > (e.g. httpnos://1.1.1.1.6.5.4.2.0.2.enum.att.com/), which can even > behave exactly as https v.10 otherwise does, but allowing for a > conforming use of the null-encryption cipher suite. > > Peter > > > > From: home_pw@msn.comTo: tls@ietf.orgSubject: RE: [TLS] IETF67 TLS SummaryDate: Sat, 18 Nov 2006 09:53:44 -0800CC: > _________________________________________________________________ > Express yourself with gadgets on Windows Live Spaces > http://discoverspaces.live.com?source=hmtag1&loc=us_______________________________________________ > 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 Sun Nov 19 11:35:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlpcV-0000Rd-QL; Sun, 19 Nov 2006 11:34:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlpcU-0000RI-0C for tls@ietf.org; Sun, 19 Nov 2006 11:34:14 -0500 Received: from mga09.intel.com ([134.134.136.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlpcP-0004ED-Ax for tls@ietf.org; Sun, 19 Nov 2006 11:34:13 -0500 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by mga09.intel.com with ESMTP; 19 Nov 2006 08:34:06 -0800 Received: from fmsmsx334.amr.corp.intel.com ([132.233.42.1]) by azsmga001.ch.intel.com with ESMTP; 19 Nov 2006 08:33:01 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,439,1157353200"; d="scan'208,217"; a="148275955:sNHT34094984" Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Nov 2006 08:33:01 -0800 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [TLS] comment on null encryption ciphersuite; https RFC amendment ...to compensate Date: Sun, 19 Nov 2006 11:32:51 -0500 Message-ID: <279DDDAFA85EC74C9300A0598E704056F91A47@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] comment on null encryption ciphersuite; https RFC amendment ...to compensate Thread-Index: AccLgX56GjKY4DrETrOpAZYOgokJggAde57Q From: "Blumenthal, Uri" To: "Peter Williams" , X-OriginalArrivalTime: 19 Nov 2006 16:33:01.0457 (UTC) FILETIME=[613D9810:01C70BF8] X-Spam-Score: 0.1 (/) X-Scan-Signature: bf422c85703d3d847fb014987125ac48 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="===============1156465574==" Errors-To: tls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============1156465574== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C70BF8.60744E6C" This is a multi-part message in MIME format. ------_=_NextPart_001_01C70BF8.60744E6C Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Peter, =20 Whether you like it or not, but (a) there are applications that are OK with authentication/integrity only, and more importantly (b) some legistations and domains forbid encrypted channels, period. To address this reality, authentication-only TLS protocol suites are introduced. Their applicability is clear and limited - exactly as explicitly specified in the document. =20 Political balance and issues should be brought to US Congress and corresponding foreign bodies. =20 P.S. Perhaps it is worth to ensure that GUI unambiguously differentiates between encrypted and authenticated-only channel. If so, I bet you that Firefox will be there before MS IE. :-) =20 =20 ________________________________ From: Peter Williams [mailto:home_pw@msn.com]=20 Sent: Saturday, November 18, 2006 9:13 PM To: tls@ietf.org Subject: [TLS] comment on null encryption ciphersuite; https RFC amendment ...to compensate =09 =09 I'm EXTREMELY worried socially about an IAB-endorsement of the null encryption ciphersuite for TLS. Whilst I recognize its value, on the stated merits, I think we need a political balance addressing issues beyond IETF's scope. Too many consumers are potentially going to be duped by the millions of well-meant but potentially incorrect e-commerce website representations which today affirm that "SSL protects your credit-card data (via encryption etc)". With the use of endorsed null encryption ciphersuites in TLS/SSL, that is obviously not true (in any way grandma would understand). The average consumer is trained to assume "SSL" (or TLS) protects your from obvious criminal activities, concerning pilfering credit card numbers. IAB activities that destroy the brand name of SSL is something which is not worth the value of endorsing the null-encryption ciphersuite, in my own view. =20 Perhaps the right balance for IAB/IESG is to to require that the https RFC be simultaneously modified so that it makes it NON-CONFORMING for SSL/TLS in the https context to ever use the null encryption ciphersuites. Other URL protocols can be registered with IANA that don't confuse consumers (e.g. httpnos://1.1.1.1.6.5.4.2.0.2.enum.att.com/), which can even behave exactly as https v.10 otherwise does, but allowing for a conforming use of the null-encryption cipher suite.=20 =20 Peter =20 =09 ________________________________ From: home_pw@msn.com To: tls@ietf.org Subject: RE: [TLS] IETF67 TLS Summary Date: Sat, 18 Nov 2006 09:53:44 -0800 CC:=20 =09 ________________________________ Express yourself with gadgets on Windows Live Spaces Try it! =20 ------_=_NextPart_001_01C70BF8.60744E6C Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Peter,
 
Whether you=20 like it or not, but (a) there are applications that are OK with=20 authentication/integrity only, and more importantly (b) some = legistations and=20 domains forbid encrypted channels, period. To address = this reality,=20 authentication-only TLS protocol suites are introduced. Their = applicability is=20 clear and limited - exactly as explicitly specified in the=20 document.
 
Political=20 balance and issues should be brought to US Congress and corresponding = foreign=20 bodies.
 
P.S.=20 Perhaps it is worth to ensure that GUI unambiguously = differentiates between encrypted and authenticated-only channel. If so, = I bet=20 you that Firefox will be there before MS IE. :-)
 
 
From: Peter Williams = [mailto:home_pw@msn.com]=20
Sent: Saturday, November 18, 2006 9:13 PM
To:=20 tls@ietf.org
Subject: [TLS] comment on null encryption = ciphersuite;=20 https RFC amendment ...to compensate

I'm EXTREMELY worried socially about an IAB-endorsement of = the null=20 encryption ciphersuite for TLS. Whilst I recognize its value, on the = stated=20 merits, I think we need a political balance addressing issues beyond = IETF's=20 scope. Too many consumers are potentially going to be duped by the = millions of=20 well-meant but potentially incorrect e-commerce = website representations=20  which today affirm that "SSL protects your credit-card data (via = encryption etc)". With the use of endorsed null encryption = ciphersuites in=20 TLS/SSL, that is obviously not true (in any way grandma would = understand). The=20 average consumer is trained to assume "SSL" (or TLS) protects = your from=20 obvious criminal activities, concerning pilfering credit card numbers. =  IAB activities that destroy the brand name of SSL is something = which is=20 not worth the value of endorsing the null-encryption ciphersuite, in = my own=20 view.
 
Perhaps the right balance for IAB/IESG is to to = require=20 that the https RFC be simultaneously modified so that it makes it=20 NON-CONFORMING for SSL/TLS in the https context to ever use the null=20 encryption ciphersuites. Other URL protocols can be registered with = IANA that=20 don't confuse consumers (e.g. = httpnos://1.1.1.1.6.5.4.2.0.2.enum.att.com/),=20 which can even behave exactly as https v.10 otherwise does, but = allowing=20 for a conforming use of the null-encryption cipher suite.=20
 
Peter
 
From: home_pw@msn.com
To: tls@ietf.org
Subject: RE: [TLS] = IETF67 TLS=20 Summary
Date: Sat, 18 Nov 2006 09:53:44 -0800
CC: =

Express yourself with gadgets on Windows Live Spaces Try=20 it! ------_=_NextPart_001_01C70BF8.60744E6C-- --===============1156465574== 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 --===============1156465574==-- From tls-bounces@lists.ietf.org Sun Nov 19 13:03:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glqyq-0005YZ-LD; Sun, 19 Nov 2006 13:01:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glqyp-0005YR-Fz for tls@lists.ietf.org; Sun, 19 Nov 2006 13:01:23 -0500 Received: from proof.pobox.com ([207.106.133.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Glqyn-0004Nm-9R for tls@lists.ietf.org; Sun, 19 Nov 2006 13:01:23 -0500 Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id E258929E76 for ; Sun, 19 Nov 2006 13:01:40 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id AB3EC8B83B for ; Sun, 19 Nov 2006 13:01:40 -0500 (EST) Message-ID: <45609BEC.8030708@pobox.com> Date: Sun, 19 Nov 2006 10:01:16 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@lists.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [TLS] draft-ietf-tls-rfc4346-bis-02.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 I have found an error in the current draft of TLS 1.2. On page 39, it says that the client_version should be 3.2 in the ClientHello message. As you know, 3.2 is the version of TLS 1.1. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Nov 19 14:55:32 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glsjm-0002vt-VN; Sun, 19 Nov 2006 14:53:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glsjl-0002vm-EH for tls@lists.ietf.org; Sun, 19 Nov 2006 14:53:57 -0500 Received: from proof.pobox.com ([207.106.133.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Glsjj-0006nr-83 for tls@lists.ietf.org; Sun, 19 Nov 2006 14:53:57 -0500 Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id A762628D88 for ; Sun, 19 Nov 2006 14:54:16 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 6F40C970D6 for ; Sun, 19 Nov 2006 14:54:16 -0500 (EST) Message-ID: <4560B64F.3020509@pobox.com> Date: Sun, 19 Nov 2006 11:53:51 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@lists.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Subject: [TLS] draft-ietf-tls-rfc4346-bis-02.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 I have a question about the Cert Hash Types extension. In the draft, it is defined as: enum{ md5(0), sha1(1), sha256(2), sha384(3), sha512(4), (255) } HashType; struct { HashType<255> types; } CertHashTypes; Shouldn't this be instead: struct { HashType types<1..2^8-1>; } CertHashTypes; Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Nov 19 15:12:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glt0N-0000a9-4s; Sun, 19 Nov 2006 15:11:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glt0L-0000Zt-V0 for tls@lists.ietf.org; Sun, 19 Nov 2006 15:11:05 -0500 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Glt0K-0001Z7-P9 for tls@lists.ietf.org; Sun, 19 Nov 2006 15:11:05 -0500 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 026D2949EC for ; Sun, 19 Nov 2006 15:11:25 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id C4280949EB for ; Sun, 19 Nov 2006 15:11:24 -0500 (EST) Message-ID: <4560BA53.1070501@pobox.com> Date: Sun, 19 Nov 2006 12:10:59 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@lists.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [TLS] draft-ietf-tls-rfc4346-bis-02.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 page 63, it says: [PKCS1B] defines a newer version of PKCS#1 encoding that is more secure against the Bleichenbacher attack. However, for maximal compatibility with TLS 1.0, TLS 1.1 retains the original encoding. No variants of the Bleichenbacher attack are known to exist provided that the above recommendations are followed. Does this continue with TLS 1.2? Thanks, Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Nov 19 15:29:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GltHw-0006Sy-Dz; Sun, 19 Nov 2006 15:29:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GltHv-0006Ss-Dv for tls@lists.ietf.org; Sun, 19 Nov 2006 15:29:15 -0500 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GltHu-00040A-88 for tls@lists.ietf.org; Sun, 19 Nov 2006 15:29:15 -0500 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 06F8D949F8 for ; Sun, 19 Nov 2006 15:29:36 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id CA249949D5 for ; Sun, 19 Nov 2006 15:29:35 -0500 (EST) Message-ID: <4560BE97.7010006@pobox.com> Date: Sun, 19 Nov 2006 12:29:11 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@lists.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Subject: [TLS] DH_anon 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 is said that DH_anon is subject to man-in-the-middle attacks, but that is only true during the first handshake. If you already have established an authenticated session, you can use DH_anon to renegotiate. I think it would be valid to "un-deprecate" DH_anon, and add a disclaimer that it should only be used for renegotiation. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Nov 19 16:47:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GluU9-00083X-J3; Sun, 19 Nov 2006 16:45:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GluU8-00083S-AN for tls@ietf.org; Sun, 19 Nov 2006 16:45:56 -0500 Received: from bay0-omc1-s32.bay0.hotmail.com ([65.54.246.104]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GluU5-0005Ak-Jh for tls@ietf.org; Sun, 19 Nov 2006 16:45:56 -0500 Received: from BAY103-W4 ([65.54.174.104]) by bay0-omc1-s32.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Nov 2006 13:45:52 -0800 X-Originating-IP: [71.140.81.171] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: "Blumenthal, Uri" , Subject: RE: [TLS] comment on null encryption ciphersuite; https RFC amendment ...to compensate Date: Sun, 19 Nov 2006 13:45:53 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 19 Nov 2006 21:45:52.0874 (UTC) FILETIME=[15E084A0:01C70C24] X-Spam-Score: 2.2 (++) X-Scan-Signature: 76c7db407a166e4c39f35d8215d8dd32 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="===============1103081612==" Errors-To: tls-bounces@lists.ietf.org --===============1103081612== Content-Type: multipart/alternative; boundary="_b9d9ac63-39c2-457e-90ae-23de7affcd8b_" --_b9d9ac63-39c2-457e-90ae-23de7affcd8b_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FINANCIAL DATA PROTECTION caveat , in INTEL null confidentiality scheme Im going to assume that Intel is only sponsoring this for "quality" PSK env= ironments.. perhaps by supporting integration with TPM cores in Intel CPUs,= which support external key fill, and thus support PSK by providing hardwar= e-based external key management for TLS-PSK-based confidentiality services. =20 Perhaps, we can cut a deal. Change the text in the draft, security sections= .=20 =20 There is a example disclaimer...which says something like "be advised: dont= use this technique for sensitive information exchange. E.g. passwords".=20 =20 Change the example list to include specific financial account types: i) cre= ditcard numbers, ii) bankaccount numbers, or iii) other Personal Identifyin= g Financial Information As it stands, the goals of Intel as stated in the email (presumably address= ing a few repressive regimes that want confidentiality - for any purpose - = to be lowered to less than 40bit encryption (despite 40 bit encryption bein= g shown even 10 years ago to be compromised in 3h, using a bit of brute-for= cing commodity equipment!) ) is not compatible with the security section - = which indicates that the technique is not appropriate for "sensitive inform= ation exchange". That incongruity aside, we can address my objection by lis= ting - as inappropirate - those financial data -related account data types = that I enumerate.=20 =20 Deal?=20 =20 s Subject: RE: [TLS] comment on null encryption ciphersuite; https RFC amendm= ent ...to compensateDate: Sun, 19 Nov 2006 11:32:51 -0500From: uri.blumenth= al@intel.comTo: home_pw@msn.com; tls@ietf.org Peter, =20 Whether you like it or not, but (a) there are applications that are OK with= authentication/integrity only, and more importantly (b) some legistations = and domains forbid encrypted channels, period. To address this reality, aut= hentication-only TLS protocol suites are introduced. Their applicability is= clear and limited - exactly as explicitly specified in the document. =20 Political balance and issues should be brought to US Congress and correspon= ding foreign bodies. =20 =20 P.S. Perhaps it is worth to ensure that GUI unambiguously differentiates be= tween encrypted and authenticated-only channel. If so, I bet you that Firef= ox will be there before MS IE. :-) =20 =20 From: Peter Williams [mailto:home_pw@msn.com] Sent: Saturday, November 18, = 2006 9:13 PMTo: tls@ietf.orgSubject: [TLS] comment on null encryption ciphe= rsuite; https RFC amendment ...to compensate I'm EXTREMELY worried socially about an IAB-endorsement of the null encrypt= ion ciphersuite for TLS. Whilst I recognize its value, on the stated merits= , I think we need a political balance addressing issues beyond IETF's scope= . Too many consumers are potentially going to be duped by the millions of w= ell-meant but potentially incorrect e-commerce website representations whi= ch today affirm that "SSL protects your credit-card data (via encryption et= c)". With the use of endorsed null encryption ciphersuites in TLS/SSL, that= is obviously not true (in any way grandma would understand). The average c= onsumer is trained to assume "SSL" (or TLS) protects your from obvious crim= inal activities, concerning pilfering credit card numbers. IAB activities = that destroy the brand name of SSL is something which is not worth the valu= e of endorsing the null-encryption ciphersuite, in my own view. Perhaps the= right balance for IAB/IESG is to to require that the https RFC be simultan= eously modified so that it makes it NON-CONFORMING for SSL/TLS in the https= context to ever use the null encryption ciphersuites. Other URL protocols = can be registered with IANA that don't confuse consumers (e.g. httpnos://1.= 1.1.1.6.5.4.2.0.2.enum.att.com/), which can even behave exactly as https v.= 10 otherwise does, but allowing for a conforming use of the null-encryption= cipher suite. Peter=20 From: home_pw@msn.comTo: tls@ietf.orgSubject: RE: [TLS] IETF67 TLS SummaryD= ate: Sat, 18 Nov 2006 09:53:44 -0800CC:=20 Express yourself with gadgets on Windows Live Spaces Try it!=20 _________________________________________________________________ Search from any Web page with powerful protection. Get the FREE Windows Liv= e Toolbar Today! http://get.live.com/toolbar/overview= --_b9d9ac63-39c2-457e-90ae-23de7affcd8b_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
FINANCIAL DATA PROTECTION caveat , in INTEL null confidentiality = scheme

Im going to assume that Intel is only sponsoring this for "quality" PSK= environments.. perhaps by supporting integration with TPM cores in Intel C= PUs, which support external key fill, and thus support PSK by providing har= dware-based external key management for TLS-PSK-based confidentiality = services.
 
Perhaps, we can cut a deal. Change the text in the draft, security sec= tions.
 
There is a example disclaimer...which says something like "be advised: dont= use this technique for sensitive information exchange. E.g. passwords".  
Change the example list to include specific financial account types: i) cre= ditcard numbers, ii) bankaccount numbers, or iii) other Personal Identifyin= g Financial Information

As it stands, the goals of Intel as stated in the email (presumably add= ressing a few repressive regimes that want confidentiality - for any purpos= e - to be lowered to less than 40bit encryption (despite 40 bit encryp= tion being shown even 10 years ago to be compromised in 3h, using a bit of = brute-forcing commodity equipment!) ) is not compatible with the security s= ection - which indicates that the technique is not appropriate for "sensiti= ve information exchange". That incongruity aside, we can address my objecti= on by listing - as inappropirate - those financial data -related account da= ta types that I enumerate.
 
Deal?
 
s
Subject: RE: [TLS] comment on null encryption ciphersuite; https RFC amendm= ent ...to compensate
Date: Sun, 19 Nov 2006 11:32:51 -0500
From: uri.= blumenthal@intel.com
To: home_pw@msn.com; tls@ietf.org

Peter,
 
Whether you like it or not, but (a) there are applications that are O= K with authentication/integrity only, and more importantly (b) some legista= tions and domains forbid encrypted channels, period. To addr= ess this reality, authentication-only TLS protocol suites are introduced. T= heir applicability is clear and limited - exactly as explicitly specified i= n the document.
 
Political balance and issues should be brought to US Congress and correspo= nding foreign bodies.
 
 
P.S. Perhaps it is worth to ensure that GUI unambiguou= sly differentiates between encrypted and authenticated-only channel. If so,= I bet you that Firefox will be there before MS IE. :-)
 
 
From: Peter Williams [mailto:home_pw@msn.com] Sent: Saturday, November 18, 2006 9:13 PM
To: tls@ietf.o= rg
Subject: [TLS] comment on null encryption ciphersuite; https R= FC amendment ...to compensate

I'm EXTREMELY worried socially about an IAB-endorsement of the n= ull encryption ciphersuite for TLS. Whilst I recognize its value, on the st= ated merits, I think we need a political balance addressing issues beyond I= ETF's scope. Too many consumers are potentially going to be duped by the mi= llions of well-meant but potentially incorrect e-commerce website repr= esentations  which today affirm that "SSL protects your credit-card da= ta (via encryption etc)". With the use of endorsed null encryption ciphersu= ites in TLS/SSL, that is obviously not true (in any way grandma would under= stand). The average consumer is trained to assume "SSL" (or TLS) prote= cts your from obvious criminal activities, concerning pilfering credit card= numbers.  IAB activities that destroy the brand name of SSL is someth= ing which is not worth the value of endorsing the null-encryption ciphersui= te, in my own view.
 
Perhaps the right balance for IAB/IESG is = to to require that the https RFC be simultaneously modified so that it make= s it NON-CONFORMING for SSL/TLS in the https context to ever use the null e= ncryption ciphersuites. Other URL protocols can be registered with IANA tha= t don't confuse consumers (e.g. httpnos://1.1.1.1.6.5.4.2.0.2.enum.att.com/= ), which can even behave exactly as https v.10 otherwise does, but all= owing for a conforming use of the null-encryption cipher suite.
 <= BR>Peter
 
From: home_pw@msn.com
To: tls@ietf.org
Subject: RE: [TLS] IETF67 TLS = Summary
Date: Sat, 18 Nov 2006 09:53:44 -0800
CC:
Express yourself with gadgets on Windows Live Spaces Try it!<= /A>

Search from any Web page with pow= erful protection. Get the FREE Windows Live Toolbar Today! Try it now! = --_b9d9ac63-39c2-457e-90ae-23de7affcd8b_-- --===============1103081612== 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 --===============1103081612==-- From tls-bounces@lists.ietf.org Sun Nov 19 17:07:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GluoZ-0006ON-3E; Sun, 19 Nov 2006 17:07:03 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GluoX-0006OI-Fh for tls@ietf.org; Sun, 19 Nov 2006 17:07:01 -0500 Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GluoW-0003KZ-6w for tls@ietf.org; Sun, 19 Nov 2006 17:07:01 -0500 Received: by delta.rtfm.com (Postfix, from userid 1001) id A0B1C1CC24; Sun, 19 Nov 2006 14:06:29 -0800 (PST) To: Peter Williams Subject: Re: [TLS] comment on null encryption ciphersuite; https RFC amendment ...to compensate References: From: EKR Date: Sun, 19 Nov 2006 14:06:29 -0800 In-Reply-To: (Peter Williams's message of "Sun, 19 Nov 2006 13:45:53 -0800") Message-ID: <86ac2nrt0a.fsf@delta.rtfm.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.2 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 Peter: 1. TLS has always included NULL cipher suites. They are in RFC 2246. 2. The IESG has already approved this document. It's in the RFC Editor queue. 3. I think the current security considerations text is clear and yours doesn't seem to to substantially improve matters. -Ekr Peter Williams writes: > FINANCIAL DATA PROTECTION caveat , in INTEL null confidentiality scheme > Im going to assume that Intel is only sponsoring this for "quality" PSK environments.. perhaps by supporting integration with TPM cores in Intel CPUs, which support external key fill, and thus support PSK by providing hardware-based external key management for TLS-PSK-based confidentiality services. > > Perhaps, we can cut a deal. Change the text in the draft, security sections. > > There is a example disclaimer...which says something like "be advised: dont use this technique for sensitive information exchange. E.g. passwords". > > Change the example list to include specific financial account types: i) creditcard numbers, ii) bankaccount numbers, or iii) other Personal Identifying Financial Information > As it stands, the goals of Intel as stated in the email (presumably addressing a few repressive regimes that want confidentiality - for any purpose - to be lowered to less than 40bit encryption (despite 40 bit encryption being shown even 10 years ago to be compromised in 3h, using a bit of brute-forcing commodity equipment!) ) is not compatible with the security section - which indicates that the technique is not appropriate for "sensitive information exchange". That incongruity aside, we can address my objection by listing - as inappropirate - those financial data -related account data types that I enumerate. > > Deal? _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Nov 19 20:20:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glxnt-0007CM-UA; Sun, 19 Nov 2006 20:18:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Glxns-0007AE-98 for tls@ietf.org; Sun, 19 Nov 2006 20:18:32 -0500 Received: from bay0-omc2-s11.bay0.hotmail.com ([65.54.246.147]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Glxnm-0004vN-Ng for tls@ietf.org; Sun, 19 Nov 2006 20:18:32 -0500 Received: from BAY103-W1 ([65.54.174.101]) by bay0-omc2-s11.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Nov 2006 17:18:26 -0800 X-Originating-IP: [71.140.81.171] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Date: Sun, 19 Nov 2006 17:18:26 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 20 Nov 2006 01:18:26.0298 (UTC) FILETIME=[C78295A0:01C70C41] X-Spam-Score: 2.6 (++) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac Cc: Subject: [TLS] RE: comment on null encryption ciphersuite; https RFC amendment ...to compensate 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="===============1694356651==" Errors-To: tls-bounces@lists.ietf.org --===============1694356651== Content-Type: multipart/alternative; boundary="_68cbaa36-1c22-48d5-86ba-dcde7558c877_" --_68cbaa36-1c22-48d5-86ba-dcde7558c877_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 =20 I retract my objection, referenced below, on the basis that its evident tha= t TLS, generically, supports cipher suites with null confidentiality compon= ent, with no limits on what kind of data are passed over such channels. Unl= ess i'm shown wrong (yet again), IETF has not counseled against using any o= f its endorsed ciphersuites, when transferring credit card data, securely. = It is entirely legitimate to knowingly transfer sensitive data over TLS_RSA= _WITH_NULL_MD5, for example. =20 Given the nature of the specification of the core TLS RFC, Intel folks' I-D= on PSK modality (with null confidentiality ciphers) looks rather professio= nal, warning against using the cited mechanism for transferring sensitive d= ata. There is no reason for Intel folk to articulate a rationale for their propo= sal that customers/governments are (now) demanding the authentication-only = feature, or null-confidentiality cipher feature. They are merely profiling = existing internet policy endorsing such practices, set by the process in 19= 99. From: home_pw@msn.comTo: tls@ietf.orgSubject: comment on null encryption ci= phersuite; https RFC amendment ...to compensateDate: Sat, 18 Nov 2006 18:12= :38 -0800 I'm EXTREMELY worried socially about an IAB-endorsement of the null encrypt= ion ciphersuite for TLS. Whilst I recognize its value, on the stated merits= , I think we need a political balance addressing issues beyond IETF's scope= . Too many consumers are potentially going to be duped by the millions of w= ell-meant but potentially incorrect e-commerce website representations whi= ch today affirm that "SSL protects your credit-card data (via encryption et= c)". With the use of endorsed null encryption ciphersuites in TLS/SSL, that= is obviously not true (in any way grandma would understand). The average c= onsumer is trained to assume "SSL" (or TLS) protects your from obvious crim= inal activities, concerning pilfering credit card numbers. IAB activities = that destroy the brand name of SSL is something which is not worth the valu= e of endorsing the null-encryption ciphersuite, in my own view. Perhaps the= right balance for IAB/IESG is to to require that the https RFC be simultan= eously modified so that it makes it NON-CONFORMING for SSL/TLS in the https= context to ever use the null encryption ciphersuites. Other URL protocols = can be registered with IANA that don't confuse consumers (e.g. httpnos://1.= 1.1.1.6.5.4.2.0.2.enum.att.com/), which can even behave exactly as https v.= 10 otherwise does, but allowing for a conforming use of the null-encryption= cipher suite. Peter=20 From: home_pw@msn.comTo: tls@ietf.orgSubject: RE: [TLS] IETF67 TLS SummaryD= ate: Sat, 18 Nov 2006 09:53:44 -0800CC:=20 Express yourself with gadgets on Windows Live Spaces Try it!=20 _________________________________________________________________ All-in-one security and maintenance for your PC.=A0 Get a free 90-day trial= ! http://www.windowsonecare.com/purchase/trial.aspx?sc_cid=3Dwl_wlmail= --_68cbaa36-1c22-48d5-86ba-dcde7558c877_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable  
 
I retract my objection, referenced below, on the basis that its e= vident that TLS, generically, supports cipher suites with null confidential= ity component, with no limits on what kind of data are passed over such cha= nnels. Unless i'm shown wrong (yet again), IETF has not counseled against u= sing any of its endorsed ciphersuites, when transferring credit card data, = securely. It is entirely legitimate to knowingly transfer sensitive data ov= er TLS_RSA_WITH_NULL_MD5, for example.
 
Given the nature of the specification of the core TLS RFC, Intel folks' I-D= on PSK modality (with null confidentiality ciphers) looks rather professio= nal, warning against using the cited mechanism for transferring sensit= ive data.

There is no reason for Intel folk to articulate a rationale for their propo= sal that customers/governments are (now) demanding the authentication-only = feature, or null-confidentiality cipher feature. They are merely profiling = existing internet policy endorsing such practices, set by the process in 19= 99.




From: home_pw@msn.com
To: tls@ietf.org
Subject: comment on null encry= ption ciphersuite; https RFC amendment ...to compensate
Date: Sat, 18 No= v 2006 18:12:38 -0800

I'm EXTREMELY worried socially about an IAB-endorsement of the null encrypt= ion ciphersuite for TLS. Whilst I recognize its value, on the stated merits= , I think we need a political balance addressing issues beyond IETF's scope= . Too many consumers are potentially going to be duped by the millions of w= ell-meant but potentially incorrect e-commerce website representations=  which today affirm that "SSL protects your credit-card data (via enc= ryption etc)". With the use of endorsed null encryption ciphersuites in TLS= /SSL, that is obviously not true (in any way grandma would understand). The= average consumer is trained to assume "SSL" (or TLS) protects your fr= om obvious criminal activities, concerning pilfering credit card numbers. &= nbsp;IAB activities that destroy the brand name of SSL is something which i= s not worth the value of endorsing the null-encryption ciphersuite, in my o= wn view.
 
Perhaps the right balance for IAB/IESG is to to requi= re that the https RFC be simultaneously modified so that it makes it NON-CO= NFORMING for SSL/TLS in the https context to ever use the null encryption c= iphersuites. Other URL protocols can be registered with IANA that don't con= fuse consumers (e.g. httpnos://1.1.1.1.6.5.4.2.0.2.enum.att.com/), which ca= n even behave exactly as https v.10 otherwise does, but allowing for a= conforming use of the null-encryption cipher suite.
 
Peter 
From: home_pw@msn.com
To: tls@ietf.org
Subject: RE: [TLS] IETF67 TLS = Summary
Date: Sat, 18 Nov 2006 09:53:44 -0800
CC:
Express yourself with gadgets on Windows Live Spaces Try it!<= /A>

All-in-one security and maintenance for your P= C.=A0 Get a free 90-day trial! Learn more! = --_68cbaa36-1c22-48d5-86ba-dcde7558c877_-- --===============1694356651== 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 --===============1694356651==-- From tls-bounces@lists.ietf.org Sun Nov 19 20:45:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlyDH-0008MD-VV; Sun, 19 Nov 2006 20:44:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlyDH-0008M3-6g for tls@ietf.org; Sun, 19 Nov 2006 20:44:47 -0500 Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlyDE-0007MD-UL for tls@ietf.org; Sun, 19 Nov 2006 20:44:47 -0500 Received: by machshav.com (Postfix, from userid 512) id 53ED1FB29D; Mon, 20 Nov 2006 01:44:34 +0000 (UTC) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 592F4FB27F; Mon, 20 Nov 2006 01:44:33 +0000 (UTC) Received: by berkshire.machshav.com (Postfix, from userid 54047) id 6D3283C0829; Sun, 19 Nov 2006 20:44:29 -0500 (EST) Date: Sun, 19 Nov 2006 20:44:29 -0500 From: "Steven M. Bellovin" To: "Blumenthal, Uri" Subject: Re: [TLS] comment on null encryption ciphersuite; https RFC amendment ...to compensate Message-Id: <20061119204429.910bcf63.smb@cs.columbia.edu> In-Reply-To: <279DDDAFA85EC74C9300A0598E704056F91A47@hdsmsx412.amr.corp.intel.com> References: <279DDDAFA85EC74C9300A0598E704056F91A47@hdsmsx412.amr.corp.intel.com> Organization: Columbia University X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.20; 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: 79899194edc4f33a41f49410777972f8 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 Sun, 19 Nov 2006 11:32:51 -0500, "Blumenthal, Uri" wrote: > Peter, > > Whether you like it or not, but (a) there are applications that are OK > with authentication/integrity only, and more importantly (b) some > legistations and domains forbid encrypted channels, period. To address > this reality, authentication-only TLS protocol suites are introduced. > Their applicability is clear and limited - exactly as explicitly > specified in the document. > > Political balance and issues should be brought to US Congress and > corresponding foreign bodies. Uri: ever since the Danvers IETF -- April, 1995 -- the IETF has had a policy of designing cryptographic mechanisms taking into account only technical criteria, not political issues. (Also see RFC 1984.) --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 Nov 19 21:26:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlypU-0004SG-SR; Sun, 19 Nov 2006 21:24:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlypT-0004S8-JU for TLS@lists.ietf.org; Sun, 19 Nov 2006 21:24:15 -0500 Received: from simmts7.bellnexxia.net ([206.47.199.165] helo=simmts7-srv.bellnexxia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlypS-0001tJ-Aw for TLS@lists.ietf.org; Sun, 19 Nov 2006 21:24:15 -0500 Received: from pbo8f8e10aowa ([65.94.168.135]) by simmts7-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with SMTP id <20061120022405.ODGT16677.simmts7-srv.bellnexxia.net@pbo8f8e10aowa> for ; Sun, 19 Nov 2006 21:24:05 -0500 Message-ID: <006001c70c4b$3d624780$87a85e41@pbo8f8e10aowa> From: "Omirjan Batyrbaev" To: Date: Sun, 19 Nov 2006 21:26:09 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Cc: Subject: [TLS] Serious crypto problem fixed by envelope HMAC method instead of currently used prefix 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, I propose to use envelope method instead of currently used prefix method in HMAC. The measure is important especially since it was pointed out that the NULL cipher suites have a real use and since some ciphers are intentionally weak. With the NULL cipher (or the 40 bits cipher) the current HMAC construct is exploitable by an active attacker who appends to the message and substitutes the new message and the newly generated HMAC value for the original. On the server side the HMAC operation will succeed. Of course it can be the server message that gets compromised this way. This attack is well known in the crypto community and is well documented in HAC (Handbook of Applied Cryptography). The book is available online and I can send you a page reference if you are not familiar with the attack on the HMAC prefix method. I quote TLS 1.2: "The MAC is generated as: HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length + TLSCompressed.fragment)); where "+" denotes concatenation." This is subject to the above mentioned attack. Instead I propose the HMAC construct which is not prone to the above stated exploit: HMAC_hash(MAC_write_secret, seq_num + TLSCompressed.type + TLSCompressed.version + TLSCompressed.length + TLSCompressed.fragment + MAC_write_secret)); addition of the MAC_write_secret as the last bits of the input to the HMAC makes it envelope method which is secure against the above stated exploit. Versions affected TLS 1.2; 1.1; 1.0 and SSL v3, etc. PS: it makes no difference if the plaintext compressed or not I just quoted from the draft/specs. Thanks. Regards, Omirjan Batyrbaev, CTO B3 Security Corp. batyr@b3securitycorp.com _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Nov 19 21:49:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlzDN-0004DQ-On; Sun, 19 Nov 2006 21:48:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GlzDM-0004D7-6Y for TLS@lists.ietf.org; Sun, 19 Nov 2006 21:48:56 -0500 Received: from mailhost.auckland.ac.nz ([130.216.190.14] helo=zeppo.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GlzDJ-0003Wi-P7 for TLS@lists.ietf.org; Sun, 19 Nov 2006 21:48:56 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id CE821346F5; Mon, 20 Nov 2006 15:48:49 +1300 (NZDT) Received: from zeppo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32208-06; Mon, 20 Nov 2006 15:48:49 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id 4E4E234661; Mon, 20 Nov 2006 15:48:49 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 81C2C37742; Mon, 20 Nov 2006 15:48:48 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1GlzDI-0007bO-00; Mon, 20 Nov 2006 15:48:52 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: batyr@sympatico.ca, TLS@lists.ietf.org Subject: Re: [TLS] Serious crypto problem fixed by envelope HMAC method instead of currently used prefix In-Reply-To: <006001c70c4b$3d624780$87a85e41@pbo8f8e10aowa> Message-Id: Date: Mon, 20 Nov 2006 15:48:52 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.5 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 "Omirjan Batyrbaev" writes: >I propose to use envelope method instead of currently used prefix method in >HMAC. The measure is important especially since it was pointed out that the >NULL cipher suites have a real use and since some ciphers are intentionally >weak. To quote one of the endless Police Academy films, "Is all this crap really necessary?". We've now got to the point where people are proposing to make significant, incompatible changes to core portions of TLS just to support broken, insecure mechanisms that should never be used in the first place. If people want to have weak security, let them have weak security, but don't make the rest of TLS suffer because of it. Or of you really think this is needed, put it in a separate profile of TLS so everyone else can stick with the standard mechanisms. Peter "little sympathy has been extended" (from the Vax assembler manual) _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Nov 19 22:48:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm06t-0000SQ-6G; Sun, 19 Nov 2006 22:46:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm06r-0000SC-TA for TLS@lists.ietf.org; Sun, 19 Nov 2006 22:46:17 -0500 Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gm06q-00007b-KJ for TLS@lists.ietf.org; Sun, 19 Nov 2006 22:46:17 -0500 Received: by delta.rtfm.com (Postfix, from userid 1001) id 386171CC24; Sun, 19 Nov 2006 19:45:46 -0800 (PST) To: "Omirjan Batyrbaev" Subject: Re: [TLS] Serious crypto problem fixed by envelope HMAC method instead of currently used prefix References: <006001c70c4b$3d624780$87a85e41@pbo8f8e10aowa> From: EKR Date: Sun, 19 Nov 2006 19:45:45 -0800 In-Reply-To: <006001c70c4b$3d624780$87a85e41@pbo8f8e10aowa> (Omirjan Batyrbaev's message of "Sun, 19 Nov 2006 21:26:09 -0500") Message-ID: <86lkm6rdau.fsf@delta.rtfm.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.2 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: TLS@lists.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 "Omirjan Batyrbaev" writes: > Hi, > > I propose to use envelope method instead of currently used prefix method in > HMAC. The measure is important especially since it was pointed out that the > NULL cipher suites have a real use and since some ciphers are intentionally > weak. With the NULL cipher (or the 40 bits cipher) the current HMAC > construct is exploitable by an active attacker who appends to the message > and substitutes the new message and the newly generated HMAC value for the > original. On the server side the HMAC operation will succeed. Of course it > can be the server message that gets compromised this way. This attack is > well known in the crypto community and is well documented in HAC (Handbook > of Applied Cryptography). The book is available online and I can send you a > page reference if you are not familiar with the attack on the HMAC prefix > method. I'm familiar with the appending attack on prefix-based keyed hashes such as H(Key || Message) but AFAIK, it doesn't apply to HMAC. Indeed, HMAC was designed in part in response to known problems in a variety of ad hoc keyed hash MAC constructions. The reason that you can append in H(Key || Message) is that the digest output includes the hash state and therefore can be extended. However, because HMAC has two hash operations, one of which only digests the output of the first, the state after processing the message is hidden. Even if there were an appending attack on HMAC, because the length value is included in the MAC, I don't believe you can apply the attack in the context of TLS. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 20 09:15:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm9uJ-0006dh-6s; Mon, 20 Nov 2006 09:13:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gm9uH-0006bZ-TJ for tls@ietf.org; Mon, 20 Nov 2006 09:13:57 -0500 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gm9uE-0007ci-Ep for tls@ietf.org; Mon, 20 Nov 2006 09:13:57 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAKDqb33008064; Mon, 20 Nov 2006 15:52:38 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 15:52:02 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 15:52:02 +0200 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] Truncated HMAC Date: Mon, 20 Nov 2006 15:52:02 +0200 Message-ID: In-Reply-To: <455CFC56.3070400@pobox.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Truncated HMAC Thread-Index: AccJ3PPKMzp0VAsNQ/KUUT9TNPbFewCy+K0g From: To: , X-OriginalArrivalTime: 20 Nov 2006 13:52:02.0397 (UTC) FILETIME=[0E67C0D0:01C70CAB] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 Mike wrote: > Then I would propose changing "CipherSpec.hash_size" to=20 > CipherSpec.mac_length so that "hash_size" does not have > two related but different meanings. The spec actually never defines a structure named "CipherSpec", so we need some more changes to make this consistent (and yes, this was inconsistent already in RFC2246...). Here's my=20 proposal: - Rename "CipherSpec.hash_size" with "SecurityParameters.mac_length" - Add field called "mac_key_length" to SecurityParameters structure, and use this when defining client/server_write_MAC_secret - Rename field "key_material_length" (in SecurityParameters) to "enc_key_length" And other consistency corrections: - Remove field "key_size" from SecurityParameters structure=20 (it's not used or mentioned anywhere in the document!) - Replace "CipherSpec.cipher_type" with "SecurityParameters. cipher_type" (the field is already there) - Replace "CipherSpec.block_length" with "SecurityParameters. block_length", and add field called "block_length" to=20 SecurityParameters. - Replace "CipherSpec.iv_length" with "SecurityParameters. iv_length", and add field called "iv_length" to =20 SecurityParameters. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 20 09:40:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmAJH-00043Y-Dp; Mon, 20 Nov 2006 09:39:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmAJG-000435-Ak for tls@ietf.org; Mon, 20 Nov 2006 09:39:46 -0500 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmAJD-0003eh-D8 for tls@ietf.org; Mon, 20 Nov 2006 09:39:46 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAKECuBT032673 for ; Mon, 20 Nov 2006 16:13:22 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 16:12:40 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 16:12:39 +0200 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: Mon, 20 Nov 2006 16:12:38 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PRF proposal Thread-Index: AccMre79MbTu6mNxRWmosKX29MV6xw== From: To: X-OriginalArrivalTime: 20 Nov 2006 14:12:39.0816 (UTC) FILETIME=[EFF6E880:01C70CAD] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Subject: [TLS] PRF proposal 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, We had a rather complicated discussion about the PRF issue in San Diego, and in the end we did not take a humm because it was not quite clear what the alternatives we would be choosing from really are (or whether the proposed alternatives really were different at all). Here's a strawman proposal that tries to capture the comments made in San Diego: o Future documents that define ciphersuites must explicitly say=20 either that (1) "the ciphersuites defined in this document use=20 the default PRF for the negotiated TLS version", or (2) "the=20 ciphersuites defined in this document use the following PRF:=20 (details of the PRF)". Especially documents that use something better than SHA-256 for integrity protection should use the latter choice (presumably defining a PRF based on the algorithm it considered "better than SHA-256"). Other documents might prefer choice 1 since=20 that would avoid updating them if someday we define TLS 1.3=20 or something. o In 4346bis, define the "default PRF for TLS 1.2" as P_SHA256. o In 4346bis, specify that all ciphersuites defined in old=20 documents predating the above-mentioned requirement use=20 choice 1 ("the default PRF for the negotiated TLS version"). (Already implied by the earlier decision.) o Specify that all ciphersuites defined in 4346bis use choice 1. Would this be satisfactory to everyone? Any other comments? Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 20 09:43:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmAM0-0005PY-Rr; Mon, 20 Nov 2006 09:42:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmALz-0005OV-DA for tls@ietf.org; Mon, 20 Nov 2006 09:42:35 -0500 Received: from mga01.intel.com ([192.55.52.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmALx-00043u-P6 for tls@ietf.org; Mon, 20 Nov 2006 09:42:35 -0500 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by mga01.intel.com with ESMTP; 20 Nov 2006 06:41:31 -0800 Received: from fmsmsx334.amr.corp.intel.com ([132.233.42.1]) by fmsmga001.fm.intel.com with ESMTP; 20 Nov 2006 06:41:24 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,440,1157353200"; d="scan'208"; a="166622830:sNHT16223807705" Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 06:41:02 -0800 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] Truncated HMAC X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 20 Nov 2006 09:40:53 -0500 Message-ID: <279DDDAFA85EC74C9300A0598E704056F91B28@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Truncated HMAC thread-index: AccJ3PPKMzp0VAsNQ/KUUT9TNPbFewCy+K0gAAGyUEA= From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 20 Nov 2006 14:41:02.0521 (UTC) FILETIME=[E6DB1290:01C70CB1] 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 Pasi, I support your proposal. It is a good solution, as it puts a clean separation between the entangled "mac", "hash" and "key". -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]=20 Sent: Monday, November 20, 2006 8:52 AM To: mike-list@pobox.com; tls@ietf.org Subject: RE: [TLS] Truncated HMAC Mike wrote: > Then I would propose changing "CipherSpec.hash_size" to=20 > CipherSpec.mac_length so that "hash_size" does not have > two related but different meanings. The spec actually never defines a structure named "CipherSpec", so we need some more changes to make this consistent (and yes, this was inconsistent already in RFC2246...). Here's my=20 proposal: - Rename "CipherSpec.hash_size" with "SecurityParameters.mac_length" - Add field called "mac_key_length" to SecurityParameters structure, and use this when defining client/server_write_MAC_secret - Rename field "key_material_length" (in SecurityParameters) to "enc_key_length" And other consistency corrections: - Remove field "key_size" from SecurityParameters structure=20 (it's not used or mentioned anywhere in the document!) - Replace "CipherSpec.cipher_type" with "SecurityParameters. cipher_type" (the field is already there) - Replace "CipherSpec.block_length" with "SecurityParameters. block_length", and add field called "block_length" to=20 SecurityParameters. - Replace "CipherSpec.iv_length" with "SecurityParameters. iv_length", and add field called "iv_length" to =20 SecurityParameters. 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 Mon Nov 20 09:54:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmAX8-0008Oj-PZ; Mon, 20 Nov 2006 09:54:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmAX7-0008Od-Qn for tls@ietf.org; Mon, 20 Nov 2006 09:54:05 -0500 Received: from mga01.intel.com ([192.55.52.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmAX4-000578-EV for tls@ietf.org; Mon, 20 Nov 2006 09:54:05 -0500 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by mga01.intel.com with ESMTP; 20 Nov 2006 06:52:07 -0800 Received: from fmsmsx333.amr.corp.intel.com ([132.233.42.2]) by fmsmga001.fm.intel.com with ESMTP; 20 Nov 2006 06:52:06 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,440,1157353200"; d="scan'208"; a="166628254:sNHT28439229" Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 20 Nov 2006 06:52:06 -0800 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] PRF proposal X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 20 Nov 2006 09:51:57 -0500 Message-ID: <279DDDAFA85EC74C9300A0598E704056F91B3D@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] PRF proposal thread-index: AccMre79MbTu6mNxRWmosKX29MV6xwABNtNw From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 20 Nov 2006 14:52:06.0850 (UTC) FILETIME=[72D3A220:01C70CB3] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 is a good proposal. I'm for it. I've one question. People are working on a better hash and PRF now. Practically speaking, there is no way to retrofit such a new hash/etc to the older already-existing/deployed cipher-suites, correct? -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]=20 Sent: Monday, November 20, 2006 9:13 AM To: tls@ietf.org Subject: [TLS] PRF proposal Hi, We had a rather complicated discussion about the PRF issue in San Diego, and in the end we did not take a humm because it was not quite clear what the alternatives we would be choosing from really are (or whether the proposed alternatives really were different at all). Here's a strawman proposal that tries to capture the comments made in San Diego: o Future documents that define ciphersuites must explicitly say=20 either that (1) "the ciphersuites defined in this document use=20 the default PRF for the negotiated TLS version", or (2) "the=20 ciphersuites defined in this document use the following PRF:=20 (details of the PRF)". Especially documents that use something better than SHA-256 for integrity protection should use the latter choice (presumably defining a PRF based on the algorithm it considered "better than SHA-256"). Other documents might prefer choice 1 since=20 that would avoid updating them if someday we define TLS 1.3=20 or something. o In 4346bis, define the "default PRF for TLS 1.2" as P_SHA256. o In 4346bis, specify that all ciphersuites defined in old=20 documents predating the above-mentioned requirement use=20 choice 1 ("the default PRF for the negotiated TLS version"). (Already implied by the earlier decision.) o Specify that all ciphersuites defined in 4346bis use choice 1. Would this be satisfactory to everyone? Any other comments? 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 Mon Nov 20 10:07:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmAjG-0000NO-AS; Mon, 20 Nov 2006 10:06:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmAjF-0000LY-0g for TLS@lists.ietf.org; Mon, 20 Nov 2006 10:06:37 -0500 Received: from simmts6.bellnexxia.net ([206.47.199.164] helo=simmts6-srv.bellnexxia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmAjD-0005xj-OK for TLS@lists.ietf.org; Mon, 20 Nov 2006 10:06:36 -0500 Received: from pbo8f8e10aowa ([65.94.170.85]) by simmts6-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with SMTP id <20061120150632.NGNZ25660.simmts6-srv.bellnexxia.net@pbo8f8e10aowa>; Mon, 20 Nov 2006 10:06:32 -0500 Message-ID: <002401c70cb5$c0a410a0$55aa5e41@pbo8f8e10aowa> From: "Omirjan Batyrbaev" To: "EKR" References: <006001c70c4b$3d624780$87a85e41@pbo8f8e10aowa> <86lkm6rdau.fsf@delta.rtfm.com> Subject: Re: [TLS] Serious crypto problem fixed by envelope HMAC method instead of currently used prefix Date: Mon, 20 Nov 2006 10:08:35 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: TLS@lists.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 Hi, please see inserted: ----- Original Message ----- From: "EKR" To: "Omirjan Batyrbaev" Cc: Sent: Sunday, November 19, 2006 10:45 PM Subject: Re: [TLS] Serious crypto problem fixed by envelope HMAC method instead of currently used prefix > "Omirjan Batyrbaev" writes: > > > Hi, > > > > I propose to use envelope method instead of currently used prefix method in > > HMAC. The measure is important especially since it was pointed out that the > > NULL cipher suites have a real use and since some ciphers are intentionally > > weak. With the NULL cipher (or the 40 bits cipher) the current HMAC > > construct is exploitable by an active attacker who appends to the message > > and substitutes the new message and the newly generated HMAC value for the > > original. On the server side the HMAC operation will succeed. Of course it > > can be the server message that gets compromised this way. This attack is > > well known in the crypto community and is well documented in HAC (Handbook > > of Applied Cryptography). The book is available online and I can send you a > > page reference if you are not familiar with the attack on the HMAC prefix > > method. > > > Even if there were an appending attack on HMAC, because the length > value is included in the MAC, I don't believe you can apply the > attack in the context of TLS. I agree that the inclusion of the length value has merit. But only if the peer checks the length value. With the proposed envelope method even if the peer does not check the length value the MAC can not be forged. Isn't it better to use a more robust envelope method instead? It is a small change to the spec and implementations. > > -Ekr > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 20 10:20:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmAvb-0006MY-Fr; Mon, 20 Nov 2006 10:19:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmAva-0006MS-6l for tls@lists.ietf.org; Mon, 20 Nov 2006 10:19:22 -0500 Received: from moutng.kundenserver.de ([212.227.126.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmAvY-00071U-RL for tls@lists.ietf.org; Mon, 20 Nov 2006 10:19:22 -0500 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1GmAuo3Dwv-0008Rf; Mon, 20 Nov 2006 16:18:35 +0100 Received: by tau.invalid (Postfix, from userid 1000) id 592064DE3; Mon, 20 Nov 2006 16:18:34 +0100 (CET) Date: Mon, 20 Nov 2006 16:18:34 +0100 From: Bodo Moeller To: Mike Subject: Re: [TLS] draft-ietf-tls-rfc4346-bis-02.txt Message-ID: <20061120151834.GA29676@tau.invalid> References: <4560BA53.1070501@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4560BA53.1070501@pobox.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: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: tls@lists.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 Sun, Nov 19, 2006 at 12:10:59PM -0800, Mike wrote: > On page 63, it says: > > [PKCS1B] defines a newer version of PKCS#1 encoding that is more > secure against the Bleichenbacher attack. However, for maximal > compatibility with TLS 1.0, TLS 1.1 retains the original > encoding. No variants of the Bleichenbacher attack are known to > exist provided that the above recommendations are followed. > > Does this continue with TLS 1.2? Yes, so TLS 1.2 should be mentioned here too. (There's a number of places where draft-ietf-tls-rfc4346-bis-02.txt fails to use the updated version number.) Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 20 10:24:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmB08-0000QQ-0n; Mon, 20 Nov 2006 10:24:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmB06-0000QB-QE for TLS@lists.ietf.org; Mon, 20 Nov 2006 10:24:02 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmB05-0007Qd-8V for TLS@lists.ietf.org; Mon, 20 Nov 2006 10:24:02 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 1B7481E8C5D; Mon, 20 Nov 2006 07:23:58 -0800 (PST) To: "Omirjan Batyrbaev" Subject: Re: [TLS] Serious crypto problem fixed by envelope HMAC method instead of currently used prefix References: <006001c70c4b$3d624780$87a85e41@pbo8f8e10aowa> <86lkm6rdau.fsf@delta.rtfm.com> <002401c70cb5$c0a410a0$55aa5e41@pbo8f8e10aowa> From: Eric Rescorla Date: Mon, 20 Nov 2006 07:23:58 -0800 In-Reply-To: <002401c70cb5$c0a410a0$55aa5e41@pbo8f8e10aowa> (Omirjan Batyrbaev's message of "Mon, 20 Nov 2006 10:08:35 -0500") Message-ID: <86d57irvjl.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: 2086112c730e13d5955355df27e3074b Cc: TLS@lists.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 "Omirjan Batyrbaev" writes: > Hi, please see inserted: > ----- Original Message ----- > From: "EKR" > To: "Omirjan Batyrbaev" > Cc: > Sent: Sunday, November 19, 2006 10:45 PM > Subject: Re: [TLS] Serious crypto problem fixed by envelope HMAC method > instead of currently used prefix > > >> "Omirjan Batyrbaev" writes: >> >> > Hi, >> > >> > I propose to use envelope method instead of currently used prefix method > in >> > HMAC. The measure is important especially since it was pointed out that > the >> > NULL cipher suites have a real use and since some ciphers are > intentionally >> > weak. With the NULL cipher (or the 40 bits cipher) the current HMAC >> > construct is exploitable by an active attacker who appends to the > message >> > and substitutes the new message and the newly generated HMAC value for > the >> > original. On the server side the HMAC operation will succeed. Of course > it >> > can be the server message that gets compromised this way. This attack is >> > well known in the crypto community and is well documented in HAC > (Handbook >> > of Applied Cryptography). The book is available online and I can send > you a >> > page reference if you are not familiar with the attack on the HMAC > prefix >> > method. >> >> >> Even if there were an appending attack on HMAC, because the length >> value is included in the MAC, I don't believe you can apply the >> attack in the context of TLS. > > I agree that the inclusion of the length value has merit. But only if the > peer checks the length value. I'm not sure what you mean by "check" in this context. The length value is explicit in the record and is used to find the record boundary (recall that TCP has no explicit record boundaries). The length field from the record is then used to compute the MAC. Let's take the case you suggest where we have record R, consisting of { ContentType = 23 (application_data) Version = {3, 1} length = 8 (for example) data = "testdata" MAC = "XXX" } The MAC here is computed as: HMAC_hash(MAC_write_secret, seq_num + 23 + {3, 1} + 8 + "testdata") The attacker modifies the application data to be "testdataMOREDATA" and mounts the extension attack on the MAC HMAC_hash(MAC_write_secret, seq_num + 23 + {3, 1} + 8 + "testdataMOREDATA") [I'm ignoring the fact that in order to mount extension attacks you need to include the hash padding as part of the extension] Note that because this is an extension attack he can't modify data already hashed so length MUST be 8. He then formats this into a record. { ContentType = 23 (application_data) Version = {3, 1} length = ??? data = "testdataMOREDATA" MAC = "YYY" } Now, the question is: what length value does he use. If he uses 8, then the receiver will interpret "MOREDATA" as part of the MAC and the MAC won't match. On the other hand, if he uses 16, then the receiver will compute: HMAC_hash(MAC_write_secret, seq_num + 23 + {3, 1} + 16 + "testdataMOREDATA") ^^ New length value This produces the wrong MAC and thus a MAC error. There's no need to explicitly check the length field: you just copy it from the header into the MAC input. Theoretically, this could be an issue with a datagram protocol such as DTLS [again, assuming HMAC was in fact broken, which I'm not convinced is true], but since more than one DTLS record can be packed into a transport-layer datagram, you use the length field to decode the records there as well, so I don't see that there's a problem. > With the proposed envelope method even if the peer does not check the length > value the MAC can not be forged. > Isn't it better to use a more robust envelope method instead? It is a small > change to the spec and implementations. Again, I believe that the claim that HMAC is susceptible to this attack is incorrect. I understand how to mount appending attacks on simple prefix-type keyed hashes but I don't see how this applies to HMAC. Please describe in detail how you believe you would mount this attack with HMAC. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 20 10:24:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmB0H-0000Vn-Of; Mon, 20 Nov 2006 10:24:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmB0G-0000VW-DO for TLS@lists.ietf.org; Mon, 20 Nov 2006 10:24:12 -0500 Received: from moutng.kundenserver.de ([212.227.126.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmB0D-0007RS-Vw for TLS@lists.ietf.org; Mon, 20 Nov 2006 10:24:12 -0500 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1GmB0B2LEa-0005Mo; Mon, 20 Nov 2006 16:24:08 +0100 Received: by tau.invalid (Postfix, from userid 1000) id 24F944DE3; Mon, 20 Nov 2006 16:24:07 +0100 (CET) Date: Mon, 20 Nov 2006 16:24:07 +0100 From: Bodo Moeller To: Omirjan Batyrbaev Subject: Re: [TLS] Serious crypto problem fixed by envelope HMAC method instead of currently used prefix Message-ID: <20061120152407.GB29676@tau.invalid> References: <006001c70c4b$3d624780$87a85e41@pbo8f8e10aowa> <86lkm6rdau.fsf@delta.rtfm.com> <002401c70cb5$c0a410a0$55aa5e41@pbo8f8e10aowa> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <002401c70cb5$c0a410a0$55aa5e41@pbo8f8e10aowa> User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: TLS@lists.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, Nov 20, 2006 at 10:08:35AM -0500, Omirjan Batyrbaev wrote: > I agree that the inclusion of the length value has merit. But only if the > peer checks the length value. > With the proposed envelope method even if the peer does not check the length > value the MAC can not be forged. > Isn't it better to use a more robust envelope method instead? It is a small > change to the spec and implementations. TLS uses HMAC, which *is* a "robust envelope method", and is not subject to the attacks that you mentioned -- so there's no need to change any of this in TLS. Your attacks would apply to a plain SHA-1 of the key followed by the message, but that's not what HMAC does: http://www-cse.ucsd.edu/~mihir/papers/hmac.html http://en.wikipedia.org/wiki/HMAC Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 20 10:52:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmBQ6-0006og-HJ; Mon, 20 Nov 2006 10:50:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmBQ5-0006oa-SY for tls@ietf.org; Mon, 20 Nov 2006 10:50:53 -0500 Received: from moutng.kundenserver.de ([212.227.126.177]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmBQ2-0001sF-Ei for tls@ietf.org; Mon, 20 Nov 2006 10:50:53 -0500 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1GmBPv26ai-0007TS; Mon, 20 Nov 2006 16:50:45 +0100 Received: by tau.invalid (Postfix, from userid 1000) id 1C0514DE3; Mon, 20 Nov 2006 16:50:43 +0100 (CET) Date: Mon, 20 Nov 2006 16:50:43 +0100 From: Bodo Moeller To: "Blumenthal, Uri" Subject: Re: [TLS] PRF proposal Message-ID: <20061120155042.GC29676@tau.invalid> References: <279DDDAFA85EC74C9300A0598E704056F91B3D@hdsmsx412.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <279DDDAFA85EC74C9300A0598E704056F91B3D@hdsmsx412.amr.corp.intel.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: 02ec665d00de228c50c93ed6b5e4fc1a 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, Nov 20, 2006 at 09:51:57AM -0500, Blumenthal, Uri wrote: > It is a good proposal. I'm for it. > > I've one question. People are working on a better hash and PRF now. > Practically speaking, there is no way to retrofit such a new hash/etc to > the older already-existing/deployed cipher-suites, correct? Assume that a great new PRF comes up. If everybody wants to use that PRF, then the existing ciphersuites would be retrofitted to use the new PRF by making it the default for, say, TLS 1.3. If only some folks want to use the new PRF, then it could be used with existing ciphersuites by defining a TLS extension allowing PRF negotiation. (There's no need to define such an extension before there is a PRF worth the extra protocol complexity.) If you want to change more than just the PRF (e.g. if you want to change the hash function used within HMAC, or use some non-HMAC variant of a current HMAC ciphersuite), you probably should define a new ciphersuite. But the hash functions used within HMAC aren't that important anyway (attacks against authentication must be executed in real time to achieve anything), so generally this should't be much of a problem. The PRF used for key derivation is much more important than that, so a need for PRF negotiation via a TLS extension looks much more likely. (If there *was* a great new MAC that everyone wanted to use, then theoretically we could define a TLS extension for negotiating its use in place of HMAC with SHA-1 in existing ciphersuites. This just doesn't appear too likely.) Pasi.Eronen@nokia.com: > Here's a strawman proposal that tries to capture the comments > made in San Diego: > > o Future documents that define ciphersuites must explicitly say > either that (1) "the ciphersuites defined in this document use > the default PRF for the negotiated TLS version", or (2) "the > ciphersuites defined in this document use the following PRF: > (details of the PRF)". [...] > Would this be satisfactory to everyone? Any other comments? Generally this looks very reasonable, I'd just change the wording: Currently, it only foresees having the default PRF tied to the TLS version; I'd also mention a provision for negotiating the PRF through a TLS extension. So in case (1), documents would say something along the lines of "The ciphersuites defined in this document use the default PRF for the negotiated TLS version, unless a replacement for the default PRF is negotiated by way of a TLS extension. (While no such TLS extension has been defined so far, it is foreseen that a need for PRF negotiation might possibly come up.)" Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 20 16:30:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmGgD-0000A5-A8; Mon, 20 Nov 2006 16:27:53 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmGgC-00006q-7s for TLS@lists.ietf.org; Mon, 20 Nov 2006 16:27:52 -0500 Received: from simmts7.bellnexxia.net ([206.47.199.165] helo=simmts7-srv.bellnexxia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmGgA-0005nv-PC for TLS@lists.ietf.org; Mon, 20 Nov 2006 16:27:52 -0500 Received: from pbo8f8e10aowa ([65.94.170.85]) by simmts7-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with SMTP id <20061120212749.XPT16677.simmts7-srv.bellnexxia.net@pbo8f8e10aowa>; Mon, 20 Nov 2006 16:27:49 -0500 Message-ID: <00ac01c70ceb$040bf990$55aa5e41@pbo8f8e10aowa> From: "Omirjan Batyrbaev" To: "EKR" References: <006001c70c4b$3d624780$87a85e41@pbo8f8e10aowa><86lkm6rdau.fsf@delta.rtfm.com><002401c70cb5$c0a410a0$55aa5e41@pbo8f8e10aowa> <86d57irvjl.fsf@raman.networkresonance.com> Subject: Re: [TLS] Serious crypto problem fixed by envelope HMAC method instead of currently used prefix Date: Mon, 20 Nov 2006 16:29:52 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 0.0 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Cc: TLS@lists.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 Hi Eric, I've seen the TLS reference to the "Request for Comments: 2104" so this is (probably) the HMAC used in TLS. Quoting to be on the same page: "To compute HMAC over the data `text' we perform H(K XOR opad, H(K XOR ipad, text))" However, this RFC was produced in 1997 but SSL was from 1995 (or earlier?). Do you know which HMAC they used in say SSL v3 and v2 (which is still an option in my browser, etc.)? -Best, Omirjan ----- Original Message ----- From: "Eric Rescorla" To: "Omirjan Batyrbaev" Cc: Sent: Monday, November 20, 2006 10:23 AM Subject: Re: [TLS] Serious crypto problem fixed by envelope HMAC method instead of currently used prefix > "Omirjan Batyrbaev" writes: > > > Hi, please see inserted: > > ----- Original Message ----- > > From: "EKR" > > To: "Omirjan Batyrbaev" > > Cc: > > Sent: Sunday, November 19, 2006 10:45 PM > > Subject: Re: [TLS] Serious crypto problem fixed by envelope HMAC method > > instead of currently used prefix > > > > > >> "Omirjan Batyrbaev" writes: > >> > >> > Hi, > >> > > >> > I propose to use envelope method instead of currently used prefix method > > in > >> > HMAC. The measure is important especially since it was pointed out that > > the > >> > NULL cipher suites have a real use and since some ciphers are > > intentionally > >> > weak. With the NULL cipher (or the 40 bits cipher) the current HMAC > >> > construct is exploitable by an active attacker who appends to the > > message > >> > and substitutes the new message and the newly generated HMAC value for > > the > >> > original. On the server side the HMAC operation will succeed. Of course > > it > >> > can be the server message that gets compromised this way. This attack is > >> > well known in the crypto community and is well documented in HAC > > (Handbook > >> > of Applied Cryptography). The book is available online and I can send > > you a > >> > page reference if you are not familiar with the attack on the HMAC > > prefix > >> > method. > >> > >> > >> Even if there were an appending attack on HMAC, because the length > >> value is included in the MAC, I don't believe you can apply the > >> attack in the context of TLS. > > > > I agree that the inclusion of the length value has merit. But only if the > > peer checks the length value. > > I'm not sure what you mean by "check" in this context. The length > value is explicit in the record and is used to find the record > boundary (recall that TCP has no explicit record boundaries). > The length field from the record is then used to compute the > MAC. > > Let's take the case you suggest where we have record R, consisting of > > { > ContentType = 23 (application_data) > Version = {3, 1} > length = 8 (for example) > data = "testdata" > MAC = "XXX" > } > > The MAC here is computed as: > > HMAC_hash(MAC_write_secret, seq_num + 23 + > {3, 1} + 8 + "testdata") > > > The attacker modifies the application data to be > "testdataMOREDATA" and mounts the extension attack on the MAC > > HMAC_hash(MAC_write_secret, seq_num + 23 + > {3, 1} + 8 + "testdataMOREDATA") > > [I'm ignoring the fact that in order to mount extension attacks > you need to include the hash padding as part of the extension] > > Note that because this is an extension attack he can't modify > data already hashed so length MUST be 8. He then formats > this into a record. > > { > ContentType = 23 (application_data) > Version = {3, 1} > length = ??? > data = "testdataMOREDATA" > MAC = "YYY" > } > > Now, the question is: what length value does he use. If he uses > 8, then the receiver will interpret "MOREDATA" as part of the MAC > and the MAC won't match. On the other hand, if he uses 16, then > the receiver will compute: > > HMAC_hash(MAC_write_secret, seq_num + 23 + > {3, 1} + 16 + "testdataMOREDATA") > ^^ > New length value > > This produces the wrong MAC and thus a MAC error. > > There's no need to explicitly check the length field: you just copy > it from the header into the MAC input. > > Theoretically, this could be an issue with a datagram protocol such as > DTLS [again, assuming HMAC was in fact broken, which I'm not convinced > is true], but since more than one DTLS record can be packed into a > transport-layer datagram, you use the length field to decode the > records there as well, so I don't see that there's a problem. > > > > With the proposed envelope method even if the peer does not check the length > > value the MAC can not be forged. > > Isn't it better to use a more robust envelope method instead? It is a small > > change to the spec and implementations. > > Again, I believe that the claim that HMAC is susceptible to this > attack is incorrect. I understand how to mount appending attacks > on simple prefix-type keyed hashes but I don't see how this applies > to HMAC. Please describe in detail how you believe you would > mount this attack with HMAC. > > -Ekr > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 20 16:43:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmGuZ-0000eK-Gv; Mon, 20 Nov 2006 16:42:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmGuY-0000e3-Lc for TLS@lists.ietf.org; Mon, 20 Nov 2006 16:42:42 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmGuX-0007Xk-42 for TLS@lists.ietf.org; Mon, 20 Nov 2006 16:42:42 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 54DC51E8C5D; Mon, 20 Nov 2006 13:42:40 -0800 (PST) To: "Omirjan Batyrbaev" Subject: Re: [TLS] Serious crypto problem fixed by envelope HMAC method instead of currently used prefix References: <006001c70c4b$3d624780$87a85e41@pbo8f8e10aowa> <86lkm6rdau.fsf@delta.rtfm.com> <002401c70cb5$c0a410a0$55aa5e41@pbo8f8e10aowa> <86d57irvjl.fsf@raman.networkresonance.com> <00ac01c70ceb$040bf990$55aa5e41@pbo8f8e10aowa> From: Eric Rescorla Date: Mon, 20 Nov 2006 13:42:40 -0800 In-Reply-To: <00ac01c70ceb$040bf990$55aa5e41@pbo8f8e10aowa> (Omirjan Batyrbaev's message of "Mon, 20 Nov 2006 16:29:52 -0500") Message-ID: <86wt5pre0f.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: d6b246023072368de71562c0ab503126 Cc: TLS@lists.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 "Omirjan Batyrbaev" writes: > Hi Eric, > I've seen the TLS reference to the "Request for Comments: 2104" so this is > (probably) the HMAC used in TLS. Quoting to be on the same page: > "To compute HMAC over the data `text' we perform > H(K XOR opad, H(K XOR ipad, text))" > > However, this RFC was produced in 1997 but SSL was from 1995 (or earlier?). > Do you know which HMAC they used in say SSL v3 and v2 (which is still an > option in my browser, etc.)? SSLv3 used a variant of the original HMAC (pre-2104). IIRC, SSLv2 didn't use HMAC and *did* have an extension attack, but that's hardly our problem at this point. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 20 16:52:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmH3L-00079Q-Rl; Mon, 20 Nov 2006 16:51:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmH3K-00078C-Mh for TLS@lists.ietf.org; Mon, 20 Nov 2006 16:51:46 -0500 Received: from sd-green-bigip-211.dreamhost.com ([208.97.132.211] helo=swarthymail-a4.dreamhost.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmH3I-0000eT-Dx for TLS@lists.ietf.org; Mon, 20 Nov 2006 16:51:46 -0500 Received: from [192.168.0.108] (dsl-63-249-108-128.cruzio.com [63.249.108.128]) by swarthymail-a4.dreamhost.com (Postfix) with ESMTP id 7C1C7129A86; Mon, 20 Nov 2006 13:51:40 -0800 (PST) In-Reply-To: <00ac01c70ceb$040bf990$55aa5e41@pbo8f8e10aowa> References: <006001c70c4b$3d624780$87a85e41@pbo8f8e10aowa><86lkm6rdau.fsf@delta.rtfm.com><002401c70cb5$c0a410a0$55aa5e41@pbo8f8e10aowa> <86d57irvjl.fsf@raman.networkresonance.com> <00ac01c70ceb$040bf990$55aa5e41@pbo8f8e10aowa> Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 3 Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2520D7F2-23CF-4566-9517-393F048411D3@gnu.org> Content-Transfer-Encoding: 7bit From: Casey Marshall Subject: Re: [TLS] Serious crypto problem fixed by envelope HMAC method instead of currently used prefix Date: Mon, 20 Nov 2006 13:51:36 -0800 To: Omirjan Batyrbaev X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: TLS@lists.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 Nov 20, 2006, at 1:29 PM, Omirjan Batyrbaev wrote: > Hi Eric, > I've seen the TLS reference to the "Request for Comments: 2104" so > this is > (probably) the HMAC used in TLS. Quoting to be on the same page: > "To compute HMAC over the data `text' we perform > H(K XOR opad, H(K XOR ipad, text))" > > However, this RFC was produced in 1997 but SSL was from 1995 (or > earlier?). > Do you know which HMAC they used in say SSL v3 and v2 (which is > still an > option in my browser, etc.)? > In SSLv3: hash(MAC_write_secret, pad_2 + hash(MAC_write_secret + pad_1 + data)); For hash == MD5 or SHA-1, and pad_1 is 0x36 48 or 40 times (depending on the hash) and pad_2 is 0x5c 48 or 40 times. This is all available in Netscape's document describing SSLv3. I don't know what SSLv2 used, but v2 has more problems than the MAC. I'm also fairly certain that the HMAC construction long predated the RFC describing it. It's pointless to start suggesting revising SSLv3, because they did that already, and TLSv1 was the result. If you are paranoid (unnecessarily, IMO) you can disable SSLv3 in your browser. Disabling SSLv2 is probably a good idea, unless you are using some backwards service that still only supports v2. Cheers. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 20 17:50:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmHx7-0000bX-RD; Mon, 20 Nov 2006 17:49:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmHx6-0000bP-8s for TLS@lists.ietf.org; Mon, 20 Nov 2006 17:49:24 -0500 Received: from simmts6.bellnexxia.net ([206.47.199.164] helo=simmts6-srv.bellnexxia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmHx4-0000UD-SZ for TLS@lists.ietf.org; Mon, 20 Nov 2006 17:49:24 -0500 Received: from pbo8f8e10aowa ([65.94.170.85]) by simmts6-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with SMTP id <20061120224912.SXNZ25660.simmts6-srv.bellnexxia.net@pbo8f8e10aowa>; Mon, 20 Nov 2006 17:49:12 -0500 Message-ID: <00d001c70cf6$62957a80$55aa5e41@pbo8f8e10aowa> From: "Omirjan Batyrbaev" To: "EKR" References: <006001c70c4b$3d624780$87a85e41@pbo8f8e10aowa><86lkm6rdau.fsf@delta.rtfm.com><002401c70cb5$c0a410a0$55aa5e41@pbo8f8e10aowa> <86d57irvjl.fsf@raman.networkresonance.com> Subject: Re: [TLS] Serious crypto problem fixed by envelope HMAC method instead of currently used prefix Date: Mon, 20 Nov 2006 17:51:15 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: TLS@lists.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 >The length > value is explicit in the record and is used to find the >record > boundary (recall that TCP has no explicit record >boundaries). Slightly OT: when client/server writes the TLS fragment or/and messages the TCP then puts it in one TCP packet? So it becomes one TCP packet per one TLS fragment. Is this what happens in the real world implementations? -Omirjan _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 20 18:14:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmIK5-0005Ro-8K; Mon, 20 Nov 2006 18:13:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmIK3-0005Rh-L5 for TLS@lists.ietf.org; Mon, 20 Nov 2006 18:13:07 -0500 Received: from mail.transactionware.com ([203.14.245.7]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GmIK1-0003vJ-Sn for TLS@lists.ietf.org; Mon, 20 Nov 2006 18:13:07 -0500 Received: (qmail 33552 invoked from network); 20 Nov 2006 23:13:13 -0000 Received: from new.transactionware.com (192.168.1.55) by dm.transactionware.com with SMTP; 20 Nov 2006 23:13:13 -0000 Received: (qmail 85076 invoked by uid 1026); 20 Nov 2006 23:13:13 -0000 Received: from 127.0.0.1 by new.transactionware.com (envelope-from , uid 1003) with qmail-scanner-1.25 (spamassassin: 3.0.2. Clear:RC:1(127.0.0.1):. Processed in 3.249335 secs); 20 Nov 2006 23:13:13 -0000 Received: from unknown (HELO JMLAPTOP) (unknown) by unknown with SMTP; 20 Nov 2006 23:13:09 -0000 From: "Jan Mikkelsen" To: "'Omirjan Batyrbaev'" , "'EKR'" Subject: RE: [TLS] Serious crypto problem fixed by envelope HMAC methodinstead of currently used prefix Date: Tue, 21 Nov 2006 10:12:47 +1100 Organization: Transactionware Message-ID: <001601c70cf9$64d10b40$0204a8c0@transactionware.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 In-Reply-To: <00d001c70cf6$62957a80$55aa5e41@pbo8f8e10aowa> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Cc: TLS@lists.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 Omirjan Batyrbaev wrote: > >The length > > value is explicit in the record and is used to find the >record > > boundary (recall that TCP has no explicit record >boundaries). > > Slightly OT: when client/server writes the TLS fragment > or/and messages the > TCP then puts it in one TCP packet? So it becomes one TCP > packet per one TLS > fragment. Is this what happens in the real world implementations? No. TCP provides a reliable byte stream service. As stated in the message you are responding to, TCP has no explicit record boundaries. Specifically, an implementor of any TCP based service (including TLS) should not assume that recipient reads will match sender writes. What happens with TCP packets depends on many variables. These are irrelevant to TLS and are hidden by a TCP implementation. TLS has a record layer to provide a record abstraction on top of TCP. Regards, Jan Mikkelsen _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 20 18:15:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmILy-0005km-C2; Mon, 20 Nov 2006 18:15:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmILx-0005kg-3R for TLS@lists.ietf.org; Mon, 20 Nov 2006 18:15:05 -0500 Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmILv-0004BM-RH for TLS@lists.ietf.org; Mon, 20 Nov 2006 18:15:05 -0500 Received: by machshav.com (Postfix, from userid 512) id 51DD2FB2DD; Mon, 20 Nov 2006 23:14:51 +0000 (UTC) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id D37F3FB2AC; Mon, 20 Nov 2006 23:14:49 +0000 (UTC) Received: by berkshire.machshav.com (Postfix, from userid 54047) id CCAC03C0137; Mon, 20 Nov 2006 18:14:33 -0500 (EST) Date: Mon, 20 Nov 2006 18:14:33 -0500 From: "Steven M. Bellovin" To: "Omirjan Batyrbaev" Subject: Re: [TLS] Serious crypto problem fixed by envelope HMAC method instead of currently used prefix Message-Id: <20061120181433.7fe164b0.smb@cs.columbia.edu> In-Reply-To: <00d001c70cf6$62957a80$55aa5e41@pbo8f8e10aowa> References: <006001c70c4b$3d624780$87a85e41@pbo8f8e10aowa> <86lkm6rdau.fsf@delta.rtfm.com> <002401c70cb5$c0a410a0$55aa5e41@pbo8f8e10aowa> <86d57irvjl.fsf@raman.networkresonance.com> <00d001c70cf6$62957a80$55aa5e41@pbo8f8e10aowa> Organization: Columbia University X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.20; 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: cf4fa59384e76e63313391b70cd0dd25 Cc: TLS@lists.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, 20 Nov 2006 17:51:15 -0500, "Omirjan Batyrbaev" wrote: > >The length > > value is explicit in the record and is used to find the >record > > boundary (recall that TCP has no explicit record >boundaries). > > Slightly OT: when client/server writes the TLS fragment or/and messages the > TCP then puts it in one TCP packet? So it becomes one TCP packet per one TLS > fragment. Is this what happens in the real world implementations? TCP offers no guarantees on that; you cannot predict what will happen. It can even change if TCP has to retransmit something. --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 Mon Nov 20 19:29:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmJUl-0007yd-BC; Mon, 20 Nov 2006 19:28:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmJUk-0007yU-5z for TLS@lists.ietf.org; Mon, 20 Nov 2006 19:28:14 -0500 Received: from proof.pobox.com ([207.106.133.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmJUh-0004ZY-VN for TLS@lists.ietf.org; Mon, 20 Nov 2006 19:28:14 -0500 Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id 35E4123FAF for ; Mon, 20 Nov 2006 19:28:07 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id E4E6294C2E for ; Mon, 20 Nov 2006 19:28:06 -0500 (EST) Message-ID: <456247F6.60106@pobox.com> Date: Mon, 20 Nov 2006 16:27:34 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: TLS@lists.ietf.org Subject: Re: [TLS] Serious crypto problem fixed by envelope HMAC method instead of currently used prefix References: <006001c70c4b$3d624780$87a85e41@pbo8f8e10aowa><86lkm6rdau.fsf@delta.rtfm.com><002401c70cb5$c0a410a0$55aa5e41@pbo8f8e10aowa> <86d57irvjl.fsf@raman.networkresonance.com> <00d001c70cf6$62957a80$55aa5e41@pbo8f8e10aowa> In-Reply-To: <00d001c70cf6$62957a80$55aa5e41@pbo8f8e10aowa> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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 > Slightly OT: when client/server writes the TLS fragment or/and messages the > TCP then puts it in one TCP packet? So it becomes one TCP packet per one TLS > fragment. Is this what happens in the real world implementations? A TLS fragment can be up to 16383 bytes, plus some extra data. A TCP packet is usually around 1500 bytes or less, so you will normally see a fair amount of fragmentation. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 20 21:11:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmL5J-0003Ep-GA; Mon, 20 Nov 2006 21:10:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmL5H-0003Ek-VX for TLS@lists.ietf.org; Mon, 20 Nov 2006 21:10:03 -0500 Received: from simmts8.bellnexxia.net ([206.47.199.166] helo=simmts8-srv.bellnexxia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmL5G-00048z-LN for TLS@lists.ietf.org; Mon, 20 Nov 2006 21:10:03 -0500 Received: from pbo8f8e10aowa ([65.94.170.85]) by simmts8-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with SMTP id <20061121021000.JCWJ1835.simmts8-srv.bellnexxia.net@pbo8f8e10aowa>; Mon, 20 Nov 2006 21:10:00 -0500 Message-ID: <012b01c70d12$6fa894c0$55aa5e41@pbo8f8e10aowa> From: "Omirjan Batyrbaev" To: "EKR" References: <006001c70c4b$3d624780$87a85e41@pbo8f8e10aowa><86lkm6rdau.fsf@delta.rtfm.com><002401c70cb5$c0a410a0$55aa5e41@pbo8f8e10aowa><86d57irvjl.fsf@raman.networkresonance.com><00ac01c70ceb$040bf990$55aa5e41@pbo8f8e10aowa> <86wt5pre0f.fsf@raman.networkresonance.com> Subject: Re: [TLS] Serious crypto problem fixed by envelope HMAC method instead of currently used prefix Date: Mon, 20 Nov 2006 21:12:03 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: TLS@lists.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 Then I apologies for a premature alert. When I was browsing the TLS RFC I've got a wrong impression that "HMAC" in the example I originally quoted meant a MD5, SHA-1 or a similar hash function. PS: did the vendors fix the SSLv2 extension attack problem? PPS: can ekr give me a URL to his web page please? ----- Original Message ----- From: "Eric Rescorla" To: "Omirjan Batyrbaev" Cc: Sent: Monday, November 20, 2006 4:42 PM Subject: Re: [TLS] Serious crypto problem fixed by envelope HMAC method instead of currently used prefix > "Omirjan Batyrbaev" writes: > > > Hi Eric, > > I've seen the TLS reference to the "Request for Comments: 2104" so this is > > (probably) the HMAC used in TLS. Quoting to be on the same page: > > "To compute HMAC over the data `text' we perform > > H(K XOR opad, H(K XOR ipad, text))" > > > > However, this RFC was produced in 1997 but SSL was from 1995 (or earlier?). > > Do you know which HMAC they used in say SSL v3 and v2 (which is still an > > option in my browser, etc.)? > > SSLv3 used a variant of the original HMAC (pre-2104). IIRC, SSLv2 > didn't use HMAC and *did* have an extension attack, but that's > hardly our problem at this point. > > -Ekr > > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 21 10:41:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmXiO-0006Q3-LF; Tue, 21 Nov 2006 10:39:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmXiN-0006Px-Jj for tls@lists.ietf.org; Tue, 21 Nov 2006 10:39:15 -0500 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmXiM-0007dj-4Y for tls@lists.ietf.org; Tue, 21 Nov 2006 10:39:15 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kALFd1gM029844; Tue, 21 Nov 2006 17:39:09 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 17:37:18 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 17:37:18 +0200 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] NIST TLS recomendations (IV generation) Date: Tue, 21 Nov 2006 17:37:21 +0200 Message-ID: In-Reply-To: <7.0.1.0.2.20061101091038.0208f420@nist.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] NIST TLS recomendations (IV generation) Thread-Index: Acb9wgSf1EKVbyKaR12QoVxxwPw3hAPwCs4w From: To: , X-OriginalArrivalTime: 21 Nov 2006 15:37:18.0003 (UTC) FILETIME=[ED368030:01C70D82] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 Ray Perlner wrote: > Page 20-21: Section 6.2.3.2 under IV The document specifies that the > IV SHOULD be generated by method (1) or (2) and MAY be generated by > an alternate method. There is, however, no language forbidding the > generation of IVs by a fourth unlisted method. If a fourth method is > used, the protocol will not fail but may be insecure. Therefore we > recommend adding language forbidding the use of an unlisted method > for IV generation. Actually the whole text about IVs is quite long, and contains implementation details that IMHO are likely to confuse rather than help an implementer. How about just replacing the whole text about IVs with something like this? IV The Initialization Vector (IV) MUST be chosen at random, and MUST be unpredictable. See [SP800-38A] Appendix C for RECOMMENDED methods for generating unpredictable IVs. It is critical that the IV is not sent before the entire plaintext of the record is known; otherwise it is possible for the attacker to mount the attack described in [CBCATT]. Note: In versions of TLS prior to 1.1, there was no IV field, and the last ciphertext block of the previous record (the "CBC residue") was used as the IV. This was changed to prevent the attacks described in [CBCATT]. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 21 11:12:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmYDT-0003RE-HH; Tue, 21 Nov 2006 11:11:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmYDS-0003R1-DT for tls@ietf.org; Tue, 21 Nov 2006 11:11:22 -0500 Received: from mgw-ext12.nokia.com ([131.228.20.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmYDQ-0004Y4-Vl for tls@ietf.org; Tue, 21 Nov 2006 11:11:22 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kALGAkRs031481 for ; Tue, 21 Nov 2006 18:11:19 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 18:09:41 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 18:09:38 +0200 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, 21 Nov 2006 18:06:27 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Record layer corner cases Thread-Index: AccNhwAmc2j+O0/aRu+KkwPWpYcf8w== From: To: X-OriginalArrivalTime: 21 Nov 2006 16:09:38.0090 (UTC) FILETIME=[719848A0:01C70D87] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Subject: [TLS] Record layer corner cases 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 all, In San Diego I gave a short presentation on how various TLS implementations handle some corner cases in the TLS record protocol: http://www3.ietf.org/proceedings/06nov/slides/tls-3.ppt The conclusion was that receiving these corner cases is not handled well, probably because real implementations never send them. Thus, I'd suggest explicitly forbidding some of these corner cases in TLS 1.2. In particular: - Implementations MUST NOT fragment Handshake, Alert, or Change cipher spec messages to multiple TLS records unless the message=20 exceeds the maximum fragment length (either 2^14 or negotiated=20 with max_fragment_length extension). - Implementations MUST NOT send zero-length fragments of Handshake,=20 Alert, or Change Cipher Spec content types (zero-length fragments of Application data would still be allowed; presumably they might be useful against traffic analysis). - Implementations MUST NOT send content types not defined in this document except when explicitly negotiated using e.g. a TLS extension (current text says unknown content types SHOULD be just ignored). - The maximum fragment size is a strict limit (i.e. change "the length should not exceed 2^14" to MUST NOT). Comments? Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 21 11:12:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmYEN-0003ci-CX; Tue, 21 Nov 2006 11:12:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmYEM-0003cc-5L for tls@lists.ietf.org; Tue, 21 Nov 2006 11:12:18 -0500 Received: from mga01.intel.com ([192.55.52.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmYEI-0004lI-Im for tls@lists.ietf.org; Tue, 21 Nov 2006 11:12:18 -0500 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by mga01.intel.com with ESMTP; 21 Nov 2006 08:12:14 -0800 Received: from fmsmsx334.amr.corp.intel.com ([132.233.42.1]) by fmsmga002.fm.intel.com with ESMTP; 21 Nov 2006 08:12:13 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,443,1157353200"; d="scan'208"; a="18393763:sNHT29536101" Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 08:12:13 -0800 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] NIST TLS recomendations (IV generation) Date: Tue, 21 Nov 2006 11:12:03 -0500 Message-ID: <279DDDAFA85EC74C9300A0598E704056FE6957@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] NIST TLS recomendations (IV generation) thread-index: Acb9wgSf1EKVbyKaR12QoVxxwPw3hAPwCs4wAAFWovA= From: "Blumenthal, Uri" To: , , X-OriginalArrivalTime: 21 Nov 2006 16:12:13.0567 (UTC) FILETIME=[CE4430F0:01C70D87] X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 Pasi, For the 1st statement how about: The IV SHOULD be chosen at random, and MUST be=20 unique and unpredictable.=20 (based on crypto wisdom :-) -----Original Message----- From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]=20 Sent: Tuesday, November 21, 2006 10:37 AM To: ray.perlner@nist.gov; tls@lists.ietf.org Subject: RE: [TLS] NIST TLS recomendations (IV generation) Ray Perlner wrote: > Page 20-21: Section 6.2.3.2 under IV The document specifies that the > IV SHOULD be generated by method (1) or (2) and MAY be generated by > an alternate method. There is, however, no language forbidding the > generation of IVs by a fourth unlisted method. If a fourth method is > used, the protocol will not fail but may be insecure. Therefore we > recommend adding language forbidding the use of an unlisted method > for IV generation. Actually the whole text about IVs is quite long, and contains implementation details that IMHO are likely to confuse rather than help an implementer. How about just replacing the whole text about IVs with something like this? IV The Initialization Vector (IV) MUST be chosen at random, and MUST be unpredictable. See [SP800-38A] Appendix C for RECOMMENDED methods for generating unpredictable IVs. It is critical that the IV is not sent before the entire plaintext of the record is known; otherwise it is possible for the attacker to mount the attack described in [CBCATT]. Note: In versions of TLS prior to 1.1, there was no IV field, and the last ciphertext block of the previous record (the "CBC residue") was used as the IV. This was changed to prevent the attacks described in [CBCATT]. 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 Tue Nov 21 11:40:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmYey-00061r-0Y; Tue, 21 Nov 2006 11:39:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmYex-00061a-4V for tls@lists.ietf.org; Tue, 21 Nov 2006 11:39:47 -0500 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmYev-0001JM-Ex for tls@lists.ietf.org; Tue, 21 Nov 2006 11:39:47 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kALGdd5m001064; Tue, 21 Nov 2006 18:39:42 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 18:39:38 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 18:39:37 +0200 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] NIST TLS recomendations (IV generation) Date: Tue, 21 Nov 2006 18:34:19 +0200 Message-ID: In-Reply-To: <279DDDAFA85EC74C9300A0598E704056FE6957@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] NIST TLS recomendations (IV generation) Thread-Index: Acb9wgSf1EKVbyKaR12QoVxxwPw3hAPwCs4wAAFWovAAAJYLoA== From: To: , , X-OriginalArrivalTime: 21 Nov 2006 16:39:37.0506 (UTC) FILETIME=[A2216020:01C70D8B] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 Uri, I'd like to align the text with NIST SP 800-38A, which doesn't=20 require uniqueness for CBC mode (and for other modes where=20 uniqueness is required, generating the IV randomly is not=20 usually acceptable). So how about "The Initialization Vector (IV) SHOULD be=20 chosen at random, and MUST be unpredictable" ? (This text is in section titled "CBC block cipher", so no need to consider OFB or CTR here...) Best regards, Pasi > -----Original Message----- > From: ext Blumenthal, Uri [mailto:uri.blumenthal@intel.com]=20 > Sent: 21 November, 2006 18:12 > To: Eronen Pasi (Nokia-NRC/Helsinki); ray.perlner@nist.gov;=20 > tls@lists.ietf.org > Subject: RE: [TLS] NIST TLS recomendations (IV generation) >=20 > Pasi, >=20 > For the 1st statement how about: >=20 > The IV SHOULD be chosen at random, and MUST be=20 > unique and unpredictable.=20 >=20 > (based on crypto wisdom :-) >=20 > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]=20 > Sent: Tuesday, November 21, 2006 10:37 AM > To: ray.perlner@nist.gov; tls@lists.ietf.org > Subject: RE: [TLS] NIST TLS recomendations (IV generation) >=20 > Ray Perlner wrote: > > Page 20-21: Section 6.2.3.2 under IV The document specifies that the > > IV SHOULD be generated by method (1) or (2) and MAY be generated by > > an alternate method. There is, however, no language forbidding the > > generation of IVs by a fourth unlisted method. If a fourth method is > > used, the protocol will not fail but may be insecure. Therefore we > > recommend adding language forbidding the use of an unlisted method > > for IV generation. >=20 > Actually the whole text about IVs is quite long, and contains > implementation details that IMHO are likely to confuse rather than > help an implementer. >=20 > How about just replacing the whole text about IVs with something > like this? >=20 > IV >=20 > The Initialization Vector (IV) MUST be chosen at random, and > MUST be unpredictable. See [SP800-38A] Appendix C for > RECOMMENDED methods for generating unpredictable IVs. >=20 > It is critical that the IV is not sent before the entire > plaintext of the record is known; otherwise it is possible for > the attacker to mount the attack described in [CBCATT]. >=20 > Note: In versions of TLS prior to 1.1, there was no IV field, > and the last ciphertext block of the previous record (the "CBC > residue") was used as the IV. This was changed to prevent the > attacks described in [CBCATT]. >=20 > Best regards, > Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 21 12:27:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmZNY-0007Fq-TC; Tue, 21 Nov 2006 12:25:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmZNX-0007Fj-6g for tls@lists.ietf.org; Tue, 21 Nov 2006 12:25:51 -0500 Received: from mga02.intel.com ([134.134.136.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmZNU-0008BX-TJ for tls@lists.ietf.org; Tue, 21 Nov 2006 12:25:51 -0500 Received: from orsmga001.jf.intel.com ([10.7.209.18]) by mga02.intel.com with ESMTP; 21 Nov 2006 09:25:47 -0800 Received: from fmsmsx333.amr.corp.intel.com ([132.233.42.2]) by orsmga001.jf.intel.com with ESMTP; 21 Nov 2006 09:25:24 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,443,1157353200"; d="scan'208"; a="165006061:sNHT478004989" Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 09:25:15 -0800 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] NIST TLS recomendations (IV generation) Date: Tue, 21 Nov 2006 12:25:04 -0500 Message-ID: <279DDDAFA85EC74C9300A0598E704056FE69FD@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] NIST TLS recomendations (IV generation) thread-index: Acb9wgSf1EKVbyKaR12QoVxxwPw3hAPwCs4wAAFWovAAAJYLoAABWDTw From: "Blumenthal, Uri" To: , , X-OriginalArrivalTime: 21 Nov 2006 17:25:15.0993 (UTC) FILETIME=[02655490:01C70D92] X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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'd like to align the text with NIST SP 800-38A, which doesn't=20 >require uniqueness for CBC mode (and for other modes where=20 >uniqueness is required, generating the IV randomly is not=20 >usually acceptable). I guess I have an issue with SP 800-38A then :-).=20 >So how about "The Initialization Vector (IV) SHOULD be=20 >chosen at random, and MUST be unpredictable" ? > >(This text is in section titled "CBC block cipher", >so no need to consider OFB or CTR here...) Well, I still would like to see at least "SHOULD be unique", but since we are aligning with the official standard (and the issue is indeed rather improbable for CBC) - I'm leaving it to the others to decide. No strong push from my side in either direction. :-) -----Original Message----- > From: ext Blumenthal, Uri [mailto:uri.blumenthal@intel.com]=20 > Sent: 21 November, 2006 18:12 > To: Eronen Pasi (Nokia-NRC/Helsinki); ray.perlner@nist.gov;=20 > tls@lists.ietf.org > Subject: RE: [TLS] NIST TLS recomendations (IV generation) >=20 > Pasi, >=20 > For the 1st statement how about: >=20 > The IV SHOULD be chosen at random, and MUST be=20 > unique and unpredictable.=20 >=20 > (based on crypto wisdom :-) >=20 > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com]=20 > Sent: Tuesday, November 21, 2006 10:37 AM > To: ray.perlner@nist.gov; tls@lists.ietf.org > Subject: RE: [TLS] NIST TLS recomendations (IV generation) >=20 > Ray Perlner wrote: > > Page 20-21: Section 6.2.3.2 under IV The document specifies that the > > IV SHOULD be generated by method (1) or (2) and MAY be generated by > > an alternate method. There is, however, no language forbidding the > > generation of IVs by a fourth unlisted method. If a fourth method is > > used, the protocol will not fail but may be insecure. Therefore we > > recommend adding language forbidding the use of an unlisted method > > for IV generation. >=20 > Actually the whole text about IVs is quite long, and contains > implementation details that IMHO are likely to confuse rather than > help an implementer. >=20 > How about just replacing the whole text about IVs with something > like this? >=20 > IV >=20 > The Initialization Vector (IV) MUST be chosen at random, and > MUST be unpredictable. See [SP800-38A] Appendix C for > RECOMMENDED methods for generating unpredictable IVs. >=20 > It is critical that the IV is not sent before the entire > plaintext of the record is known; otherwise it is possible for > the attacker to mount the attack described in [CBCATT]. >=20 > Note: In versions of TLS prior to 1.1, there was no IV field, > and the last ciphertext block of the previous record (the "CBC > residue") was used as the IV. This was changed to prevent the > attacks described in [CBCATT]. >=20 > Best regards, > Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 21 12:34:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmZVI-0007v0-Lo; Tue, 21 Nov 2006 12:33:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmZVH-0007uT-CT for tls@ietf.org; Tue, 21 Nov 2006 12:33:51 -0500 Received: from moutng.kundenserver.de ([212.227.126.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmZVE-0000v1-52 for tls@ietf.org; Tue, 21 Nov 2006 12:33:50 -0500 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1GmZVD0w3C-0005R8; Tue, 21 Nov 2006 18:33:47 +0100 Received: by tau.invalid (Postfix, from userid 1000) id 81B494DC2; Tue, 21 Nov 2006 18:33:46 +0100 (CET) Date: Tue, 21 Nov 2006 18:33:46 +0100 From: Bodo Moeller To: Pasi.Eronen@nokia.com Subject: Re: [TLS] Record layer corner cases Message-ID: <20061121173346.GA15201@tau.invalid> 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: c0bedb65cce30976f0bf60a0a39edea4 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 Tue, Nov 21, 2006 at 06:06:27PM +0200, Pasi.Eronen@nokia.com wrote: > In San Diego I gave a short presentation on how various TLS > implementations handle some corner cases in the TLS record protocol: > > http://www3.ietf.org/proceedings/06nov/slides/tls-3.ppt > > The conclusion was that receiving these corner cases is not handled > well, probably because real implementations never send them. > Thus, I'd suggest explicitly forbidding some of these corner > cases in TLS 1.2. In particular: > > - Implementations MUST NOT fragment Handshake, Alert, or Change > cipher spec messages to multiple TLS records unless the message > exceeds the maximum fragment length (either 2^14 or negotiated > with max_fragment_length extension). > > - Implementations MUST NOT send zero-length fragments of Handshake, > Alert, or Change Cipher Spec content types (zero-length fragments > of Application data would still be allowed; presumably they might > be useful against traffic analysis). > > - Implementations MUST NOT send content types not defined in this > document except when explicitly negotiated using e.g. a TLS > extension (current text says unknown content types SHOULD > be just ignored). > > - The maximum fragment size is a strict limit (i.e. change > "the length should not exceed 2^14" to MUST NOT). > > Comments? It seems to me that to avoid these problematic cases, "SHOULD NOT send but MUST accept" is better than "MUST NOT send". Can you describe the specific fragmentation strategies that you used for testing? I'd expect fragmentation to probably go wrong if it affects the very beginning of the TLS connection, when the server still has to decide which protocol version to use. (Support for the SSL 2.0 client hello format possibly makes this more complicated than it otherwise would have to be.) If the very first handshake fragment sent by the client contains at least six bytes to accommodate the handshake message type (one byte), the message length (three bytes), and the protocol version (two bytes), then things are much easier for the server. It's not fragmentation per se that should be a problem for most implementations, just pathologically small fragmentation; or so I hope. For the first of the proposed restrictions (i.e., don't fragment unless the message exceeds the maximum fragment length), I think that even SHOULD NOT is too much: - First, consider implementations that collect multiple handshake messages before sending these in TLS records. The *total* length of these messages may exceed the maximum fragment length even if each *single* message is below the limit, and in this case we naturally would have a record boundary that is not aligned with the message boundary. - Second, consider implementations designed to run with very little memory. These might be allowing large fragments when receiving data (since they can't rely on the max_fragment_length extension being universally available) but still be using smaller fragments when sending data. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 21 12:44:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmZeC-0005Yv-Rd; Tue, 21 Nov 2006 12:43:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmZeA-0005Yc-TP for tls@lists.ietf.org; Tue, 21 Nov 2006 12:43:02 -0500 Received: from moutng.kundenserver.de ([212.227.126.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmZe9-0002eU-9F for tls@lists.ietf.org; Tue, 21 Nov 2006 12:43:02 -0500 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1GmZe031ff-0005KL; Tue, 21 Nov 2006 18:42:54 +0100 Received: by tau.invalid (Postfix, from userid 1000) id 57B204DC2; Tue, 21 Nov 2006 18:42:52 +0100 (CET) Date: Tue, 21 Nov 2006 18:42:52 +0100 From: Bodo Moeller To: "Blumenthal, Uri" Subject: Re: [TLS] NIST TLS recomendations (IV generation) Message-ID: <20061121174252.GB15201@tau.invalid> References: <279DDDAFA85EC74C9300A0598E704056FE69FD@hdsmsx412.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <279DDDAFA85EC74C9300A0598E704056FE69FD@hdsmsx412.amr.corp.intel.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: e1e48a527f609d1be2bc8d8a70eb76cb Cc: tls@lists.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 Tue, Nov 21, 2006 at 12:25:04PM -0500, Blumenthal, Uri wrote: >>> For the 1st statement how about: >>> >>> The IV SHOULD be chosen at random, and MUST be >>> unique and unpredictable. >>> >>> (based on crypto wisdom :-) >> I'd like to align the text with NIST SP 800-38A, which doesn't >> require uniqueness for CBC mode (and for other modes where >> uniqueness is required, generating the IV randomly is not >> usually acceptable). > I guess I have an issue with SP 800-38A then :-). >> So how about "The Initialization Vector (IV) SHOULD be >> chosen at random, and MUST be unpredictable" ? >> >> (This text is in section titled "CBC block cipher", >> so no need to consider OFB or CTR here...) > Well, I still would like to see at least "SHOULD be unique", but since > we are aligning with the official standard (and the issue is indeed > rather improbable for CBC) - I'm leaving it to the others to decide. No > strong push from my side in either direction. Being unpredictable makes the IVs unique except with negligible probability (unless you've used CBC on too long a data stream), so there's no need for an explicit uniqueness requirement. If we write "MUST be unique", this might evoke the perception that implementations using randomly generated IVs are expected to check whether these actually are unique, which usually is totally impractical, and totally unnecessary. So "SHOULD be chosen at random, and MUST be unpredictable" looks exactly right to me. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 21 13:06:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmZze-0004h5-Np; Tue, 21 Nov 2006 13:05:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmZzd-0004eX-1p for tls@lists.ietf.org; Tue, 21 Nov 2006 13:05:13 -0500 Received: from mga03.intel.com ([143.182.124.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmZza-0005xo-PH for tls@lists.ietf.org; Tue, 21 Nov 2006 13:05:13 -0500 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by mga03.intel.com with ESMTP; 21 Nov 2006 10:05:08 -0800 Received: from fmsmsx334.amr.corp.intel.com ([132.233.42.1]) by azsmga001.ch.intel.com with ESMTP; 21 Nov 2006 10:05:07 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,444,1157353200"; d="scan'208"; a="148948669:sNHT21248843" Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Nov 2006 10:05:06 -0800 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] NIST TLS recomendations (IV generation) Date: Tue, 21 Nov 2006 13:04:55 -0500 Message-ID: <279DDDAFA85EC74C9300A0598E704056FE6A49@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] NIST TLS recomendations (IV generation) thread-index: AccNlH5r81ZMndAnRPKnF49KA+kVjQAAr81w From: "Blumenthal, Uri" To: "Bodo Moeller" X-OriginalArrivalTime: 21 Nov 2006 18:05:06.0311 (UTC) FILETIME=[9322E970:01C70D97] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: tls@lists.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 =20 >Being unpredictable makes the IVs unique except with=20 >negligible probability (unless you've used CBC on too=20 >long a data stream), so there's no need for an explicit=20 >uniqueness requirement. It's that small probability that bothers me. But I guess it is small enough to ignore for practical purposes of real-world commercial applications. >If we write "MUST be unique", this might evoke the perception=20 >that implementations using randomly generated IVs are expected=20 >to check whether these actually are unique, which usually is=20 >totally impractical, and totally unnecessary. Agree. >So "SHOULD be chosen at random, and MUST be unpredictable"=20 >looks exactly right to me. OK. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 21 16:16:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmcxG-0002hq-NE; Tue, 21 Nov 2006 16:14:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmcxF-0002hH-2Y for tls@lists.ietf.org; Tue, 21 Nov 2006 16:14:57 -0500 Received: from rimp2.nist.gov ([129.6.16.227] helo=smtp.nist.gov) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmcxB-0005JU-FB for tls@lists.ietf.org; Tue, 21 Nov 2006 16:14:57 -0500 Received: from magneto.nist.gov ([129.6.54.159]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id kALLEgeV017880; Tue, 21 Nov 2006 16:14:43 -0500 Message-Id: <7.0.1.0.2.20061121155529.02175ba8@nist.gov> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Tue, 21 Nov 2006 16:14:41 -0500 To: Bodo Moeller , "Blumenthal, Uri" From: Ray Perlner Subject: Re: [TLS] NIST TLS recomendations (IV generation) In-Reply-To: <20061121174252.GB15201@tau.invalid> References: <279DDDAFA85EC74C9300A0598E704056FE69FD@hdsmsx412.amr.corp.intel.com> <20061121174252.GB15201@tau.invalid> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: ray.perlner@nist.gov X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: tls@lists.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 It seems to me, that the proposed wording rules out procedure 2 and the alternate procedure, as in those procedures it is not the IV, but the first encrypted block which is unpredictable. Not that I have a problem with that -- it seems like it would be good for compatibility if TLS clients were consistent about whether the first block of the message is sent up to the application layer. Speaking of which, what is the standard procedure for a TLS 1.1 client to determine whether or not the first block of a decrypted message should be ignored? At 12:42 PM 11/21/2006, Bodo Moeller wrote: >On Tue, Nov 21, 2006 at 12:25:04PM -0500, Blumenthal, Uri wrote: > > >>> For the 1st statement how about: > >>> > >>> The IV SHOULD be chosen at random, and MUST be > >>> unique and unpredictable. > >>> > >>> (based on crypto wisdom :-) > > >> I'd like to align the text with NIST SP 800-38A, which doesn't > >> require uniqueness for CBC mode (and for other modes where > >> uniqueness is required, generating the IV randomly is not > >> usually acceptable). > > > I guess I have an issue with SP 800-38A then :-). > > >> So how about "The Initialization Vector (IV) SHOULD be > >> chosen at random, and MUST be unpredictable" ? > >> > >> (This text is in section titled "CBC block cipher", > >> so no need to consider OFB or CTR here...) > > > Well, I still would like to see at least "SHOULD be unique", but since > > we are aligning with the official standard (and the issue is indeed > > rather improbable for CBC) - I'm leaving it to the others to decide. No > > strong push from my side in either direction. > >Being unpredictable makes the IVs unique except with negligible >probability (unless you've used CBC on too long a data stream), so >there's no need for an explicit uniqueness requirement. > >If we write "MUST be unique", this might evoke the perception that >implementations using randomly generated IVs are expected to check >whether these actually are unique, which usually is totally >impractical, and totally unnecessary. > >So "SHOULD be chosen at random, and MUST be unpredictable" looks >exactly right to me. > >Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 21 17:45:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmeLS-0007CY-Da; Tue, 21 Nov 2006 17:44:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmeLR-0007AL-OR for tls@lists.ietf.org; Tue, 21 Nov 2006 17:44:01 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmeLQ-0007VE-Fm for tls@lists.ietf.org; Tue, 21 Nov 2006 17:44:01 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 6B24D1E8C5D; Tue, 21 Nov 2006 14:43:57 -0800 (PST) To: Ray Perlner Subject: Re: [TLS] NIST TLS recomendations (IV generation) References: <279DDDAFA85EC74C9300A0598E704056FE69FD@hdsmsx412.amr.corp.intel.com> <20061121174252.GB15201@tau.invalid> <7.0.1.0.2.20061121155529.02175ba8@nist.gov> From: Eric Rescorla Date: Tue, 21 Nov 2006 14:43:57 -0800 In-Reply-To: <7.0.1.0.2.20061121155529.02175ba8@nist.gov> (Ray Perlner's message of "Tue, 21 Nov 2006 16:14:41 -0500") Message-ID: <86lkm4qv2q.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: 7bac9cb154eb5790ae3b2913587a40de Cc: tls@lists.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 Ray Perlner writes: > It seems to me, that the proposed wording rules out procedure 2 and > the alternate procedure, as in those procedures it is not the IV, but > the first encrypted block which is unpredictable. But the first encrypted block is then used as the TLS IV. We're just talking about the interface with the encryption module. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 21 21:37:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmhxE-0005vA-Ho; Tue, 21 Nov 2006 21:35:16 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmhxB-0005ux-4i for TLS@lists.ietf.org; Tue, 21 Nov 2006 21:35:13 -0500 Received: from simmts6.bellnexxia.net ([206.47.199.164] helo=simmts6-srv.bellnexxia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmhx8-0007cz-S6 for TLS@lists.ietf.org; Tue, 21 Nov 2006 21:35:13 -0500 Received: from pbo8f8e10aowa ([65.94.94.137]) by simmts6-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with SMTP id <20061122023500.QMFQ25660.simmts6-srv.bellnexxia.net@pbo8f8e10aowa> for ; Tue, 21 Nov 2006 21:35:00 -0500 Message-ID: <00ba01c70ddf$16dd52e0$895e5e41@pbo8f8e10aowa> From: "Omirjan Batyrbaev" To: Date: Tue, 21 Nov 2006 21:37:01 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [TLS] https question 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, How does non-decrypting load balancer or proxy would know where is the end of the https request? Is content length encrypted? -Omirjan _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 21 22:57:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmjDV-0003ZK-24; Tue, 21 Nov 2006 22:56:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmjDT-0003Yt-LC for tls@ietf.org; Tue, 21 Nov 2006 22:56:07 -0500 Received: from zeppo.itss.auckland.ac.nz ([130.216.190.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmjDS-0000i2-89 for tls@ietf.org; Tue, 21 Nov 2006 22:56:07 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id BE4D434934; Wed, 22 Nov 2006 16:55:59 +1300 (NZDT) Received: from zeppo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21496-12; Wed, 22 Nov 2006 16:55:59 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id 76267345CC; Wed, 22 Nov 2006 16:55:59 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id AAA2D37742; Wed, 22 Nov 2006 16:55:58 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1GmjDP-00018o-00; Wed, 22 Nov 2006 16:56:03 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: Pasi.Eronen@nokia.com, tls@ietf.org Subject: Re: [TLS] Record layer corner cases In-Reply-To: Message-Id: Date: Wed, 22 Nov 2006 16:56:03 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.5 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 >Comments? Sounds good. One additional comment, this is also a security issue, the more weird bits and pieces you have to handle, the greater the chance for mis- handling some of them, and also the greater the chance of an attacker being able to manipulate things to get around security checks. Look at TCP fragmentation as an example, in particular IPv6 fragmentation, which has lead to unfixable (without changing the spec) security holes. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 22 07:11:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmqv4-0004MQ-O3; Wed, 22 Nov 2006 07:09:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gmqv3-0004MD-Sr for tls@ietf.org; Wed, 22 Nov 2006 07:09:37 -0500 Received: from [38.113.160.194] (helo=mail.ca.certicom.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gmqv1-00018x-Cd for tls@ietf.org; Wed, 22 Nov 2006 07:09:37 -0500 Received: from spamfilter.certicom.com (localhost.localdomain [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id EE089107773BC; Wed, 22 Nov 2006 07:09:29 -0500 (EST) 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 06816-94; Wed, 22 Nov 2006 07:09:25 -0500 (EST) Received: from domino1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 5834F1077711E; Wed, 22 Nov 2006 07:09:25 -0500 (EST) In-Reply-To: <20061121173346.GA15201@tau.invalid> To: tls@ietf.org Subject: Re: [TLS] Record layer corner cases MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: Rob Dugal Date: Wed, 22 Nov 2006 07:08:10 -0500 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 7.0.1|January 17, 2006) at 11/22/2006 07:07:37 AM, Serialize complete at 11/22/2006 07:07:37 AM X-Spam-Score: 0.5 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 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="===============1947557821==" Errors-To: tls-bounces@lists.ietf.org This is a multipart message in MIME format. --===============1947557821== Content-Type: multipart/alternative; boundary="=_alternative 0042C7598525722E_=" This is a multipart message in MIME format. --=_alternative 0042C7598525722E_= Content-Type: text/plain; charset="US-ASCII" Bodo Moeller wrote on 11/21/2006 12:33:46 PM: > On Tue, Nov 21, 2006 at 06:06:27PM +0200, Pasi.Eronen@nokia.com wrote: > > > In San Diego I gave a short presentation on how various TLS > > implementations handle some corner cases in the TLS record protocol: > > > > http://www3.ietf.org/proceedings/06nov/slides/tls-3.ppt > > > > The conclusion was that receiving these corner cases is not handled > > well, probably because real implementations never send them. > > Thus, I'd suggest explicitly forbidding some of these corner > > cases in TLS 1.2. In particular: > > > > - Implementations MUST NOT fragment Handshake, Alert, or Change > > cipher spec messages to multiple TLS records unless the message > > exceeds the maximum fragment length (either 2^14 or negotiated > > with max_fragment_length extension). > > > > - Implementations MUST NOT send zero-length fragments of Handshake, > > Alert, or Change Cipher Spec content types (zero-length fragments > > of Application data would still be allowed; presumably they might > > be useful against traffic analysis). > > > > - Implementations MUST NOT send content types not defined in this > > document except when explicitly negotiated using e.g. a TLS > > extension (current text says unknown content types SHOULD > > be just ignored). > > > > - The maximum fragment size is a strict limit (i.e. change > > "the length should not exceed 2^14" to MUST NOT). > > > > Comments? > > It seems to me that to avoid these problematic cases, "SHOULD NOT send > but MUST accept" is better than "MUST NOT send". > > Can you describe the specific fragmentation strategies that you used > for testing? I'd expect fragmentation to probably go wrong if it > affects the very beginning of the TLS connection, when the server > still has to decide which protocol version to use. (Support for the > SSL 2.0 client hello format possibly makes this more complicated than > it otherwise would have to be.) If the very first handshake fragment > sent by the client contains at least six bytes to accommodate the > handshake message type (one byte), the message length (three bytes), > and the protocol version (two bytes), then things are much easier for > the server. It's not fragmentation per se that should be a problem > for most implementations, just pathologically small fragmentation; > or so I hope. > > For the first of the proposed restrictions (i.e., don't fragment > unless the message exceeds the maximum fragment length), I think that > even SHOULD NOT is too much: > > - First, consider implementations that collect multiple handshake > messages before sending these in TLS records. The *total* length of > these messages may exceed the maximum fragment length even if each > *single* message is below the limit, and in this case we naturally > would have a record boundary that is not aligned with the message > boundary. > > - Second, consider implementations designed to run with very little > memory. These might be allowing large fragments when receiving > data (since they can't rely on the max_fragment_length extension > being universally available) but still be using smaller fragments > when sending data. > > Bodo I agree with Bodo. Our SSL product supports both of these options. They are usefull features I would hate to disable for TLS 1.2 --=_alternative 0042C7598525722E_= Content-Type: text/html; charset="US-ASCII"
Bodo Moeller <bmoeller@acm.org> wrote on 11/21/2006 12:33:46 PM:

> On Tue, Nov 21, 2006 at 06:06:27PM +0200, Pasi.Eronen@nokia.com wrote:
>
> > In San Diego I gave a short presentation on how various TLS
> > implementations handle some corner cases in the TLS record protocol:
> >
> > http://www3.ietf.org/proceedings/06nov/slides/tls-3.ppt
> >
> > The conclusion was that receiving these corner cases is not handled
> > well, probably because real implementations never send them.
> > Thus, I'd suggest explicitly forbidding some of these corner
> > cases in TLS 1.2. In particular:
> >
> > - Implementations MUST NOT fragment Handshake, Alert, or Change
> >   cipher spec messages to multiple TLS records unless the message
> >   exceeds the maximum fragment length (either 2^14 or negotiated
> >   with max_fragment_length extension).
> >
> > - Implementations MUST NOT send zero-length fragments of Handshake,
> >   Alert, or Change Cipher Spec content types (zero-length fragments
> >   of Application data would still be allowed; presumably they might
> >   be useful against traffic analysis).
> >
> > - Implementations MUST NOT send content types not defined in this
> >   document except when explicitly negotiated using e.g. a TLS
> >   extension (current text says unknown content types SHOULD
> >   be just ignored).
> >
> > - The maximum fragment size is a strict limit (i.e. change
> >   "the length should not exceed 2^14" to MUST NOT).
> >
> > Comments?
>
> It seems to me that to avoid these problematic cases, "SHOULD NOT send
> but MUST accept" is better than "MUST NOT send".
>
> Can you describe the specific fragmentation strategies that you used
> for testing?  I'd expect fragmentation to probably go wrong if it
> affects the very beginning of the TLS connection, when the server
> still has to decide which protocol version to use.  (Support for the
> SSL 2.0 client hello format possibly makes this more complicated than
> it otherwise would have to be.)  If the very first handshake fragment
> sent by the client contains at least six bytes to accommodate the
> handshake message type (one byte), the message length (three bytes),
> and the protocol version (two bytes), then things are much easier for
> the server.  It's not fragmentation per se that should be a problem
> for most implementations, just pathologically small fragmentation;
> or so I hope.
>
> For the first of the proposed restrictions (i.e., don't fragment
> unless the message exceeds the maximum fragment length), I think that
> even SHOULD NOT is too much:
>
> - First, consider implementations that collect multiple handshake
>   messages before sending these in TLS records.  The *total* length of
>   these messages may exceed the maximum fragment length even if each
>   *single* message is below the limit, and in this case we naturally
>   would have a record boundary that is not aligned with the message
>   boundary.
>
> - Second, consider implementations designed to run with very little
>   memory.  These might be allowing large fragments when receiving
>   data (since they can't rely on the max_fragment_length extension
>   being universally available) but still be using smaller fragments
>   when sending data.
>
> Bodo
I agree with Bodo. Our SSL product supports both of these options.
They are usefull features I would hate to disable for TLS 1.2 --=_alternative 0042C7598525722E_=-- --===============1947557821== 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 --===============1947557821==-- From tls-bounces@lists.ietf.org Wed Nov 22 08:54:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmsXr-0006rx-U4; Wed, 22 Nov 2006 08:53:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmsXq-0006rp-Kp for tls@lists.ietf.org; Wed, 22 Nov 2006 08:53:46 -0500 Received: from rimp2.nist.gov ([129.6.16.227] helo=smtp.nist.gov) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmsXp-0003zL-Ck for tls@lists.ietf.org; Wed, 22 Nov 2006 08:53:46 -0500 Received: from magneto.nist.gov ([129.6.54.159]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id kAMDrUtW019171; Wed, 22 Nov 2006 08:53:31 -0500 Message-Id: <7.0.1.0.2.20061122085154.020a5e50@nist.gov> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Wed, 22 Nov 2006 08:53:30 -0500 To: EKR From: Ray Perlner Subject: Re: [TLS] NIST TLS recomendations (IV generation) In-Reply-To: <86lkm4qv2q.fsf@raman.networkresonance.com> References: <279DDDAFA85EC74C9300A0598E704056FE69FD@hdsmsx412.amr.corp.intel.com> <20061121174252.GB15201@tau.invalid> <7.0.1.0.2.20061121155529.02175ba8@nist.gov> <86lkm4qv2q.fsf@raman.networkresonance.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-NIST-MailScanner: Found to be clean X-NIST-MailScanner-From: ray.perlner@nist.gov X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: tls@lists.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 Sorry about that. I must have flipped mask and IV in my head. I will try to read more carefully next time. At 05:43 PM 11/21/2006, Eric Rescorla wrote: >Ray Perlner writes: > > It seems to me, that the proposed wording rules out procedure 2 and > > the alternate procedure, as in those procedures it is not the IV, but > > the first encrypted block which is unpredictable. > >But the first encrypted block is then used as the TLS IV. >We're just talking about the interface with the encryption >module. > >-Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 22 10:57:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmuSf-00005t-9g; Wed, 22 Nov 2006 10:56:33 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmuSd-0008Ng-GX for tls@ietf.org; Wed, 22 Nov 2006 10:56:31 -0500 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmuSc-0002gD-1M for tls@ietf.org; Wed, 22 Nov 2006 10:56:31 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAMCvdJQ017787; Wed, 22 Nov 2006 14:59:16 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 14:53:36 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Nov 2006 14:53:37 +0200 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] Record layer corner cases Date: Wed, 22 Nov 2006 14:53:33 +0200 Message-ID: In-Reply-To: <20061121173346.GA15201@tau.invalid> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Record layer corner cases Thread-Index: AccNlOsx2D6/HxKNQRuBzyxJFvKxAwAnWcjQ From: To: X-OriginalArrivalTime: 22 Nov 2006 12:53:37.0444 (UTC) FILETIME=[3A1DDE40:01C70E35] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 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: > It seems to me that to avoid these problematic cases, "SHOULD NOT > send but MUST accept" is better than "MUST NOT send". This is very problematic for interoperability. If practically all implementations follow the "SHOULD NOT send" (which they seem to do today), the part about "MUST accept" never gets tested. This means that even future implementations (at least those which care about=20 good interoperability) cannot violate the SHOULD NOT. And this is IMHO roughly where we are today... the spec has a feature which nobody uses, and nobody can use. IMHO it would be better to remove it, rather than leave it there "just in case". > Can you describe the specific fragmentation strategies that you used > for testing? =20 I fragmented every handshake message (sent by the client) to two=20 fragments (split in the middle). > I'd expect fragmentation to probably go wrong if it affects the very > beginning of the TLS connection, when the server still has to decide > which protocol version to use. (Support for the SSL 2.0 client > hello format possibly makes this more complicated than it otherwise > would have to be.) Well, SSL 2.0 client hello can be distinguished from SSLv3/TLS hello by looking at the first byte... > If the very first handshake fragment sent by the client contains at > least six bytes to accommodate the handshake message type (one > byte), the message length (three bytes), and the protocol version > (two bytes), then things are much easier for the server. It's not > fragmentation per se that should be a problem for most > implementations, just pathologically small fragmentation; or so I > hope. The tests I did seemed to suggest that _any_ fragmentation, not=20 just pathologically small, is a problem for most implementations. =20 > For the first of the proposed restrictions (i.e., don't fragment > unless the message exceeds the maximum fragment length), I think=20 > that even SHOULD NOT is too much: >=20 > - First, consider implementations that collect multiple handshake > messages before sending these in TLS records. The *total* length of > these messages may exceed the maximum fragment length even if each > *single* message is below the limit, and in this case we naturally > would have a record boundary that is not aligned with the message > boundary. The restriction would apply only to TLS 1.2, and there aren't any=20 TLS 1.2 implementations yet... so we could even require that a single fragment can't contain multiple handshake messages. =20 > - Second, consider implementations designed to run with very little > memory. These might be allowing large fragments when receiving > data (since they can't rely on the max_fragment_length extension > being universally available) but still be using smaller fragments > when sending data. Hmm... this is a valid argument, at least when the fragments are being encrypted/MAC'd. What if the restriction (about not fragmenting unless needed) only applied when current ciphersuite is NULL_WITH_NULL? Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 22 12:55:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmwIX-0001wt-Im; Wed, 22 Nov 2006 12:54:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmwIV-0001uP-UQ for tls@ietf.org; Wed, 22 Nov 2006 12:54:11 -0500 Received: from proof.pobox.com ([207.106.133.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmwIU-0004XR-O3 for tls@ietf.org; Wed, 22 Nov 2006 12:54:11 -0500 Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id 3F78824E12 for ; Wed, 22 Nov 2006 12:54:32 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 05DC498571 for ; Wed, 22 Nov 2006 12:54:31 -0500 (EST) Message-ID: <45648EB0.8050404@pobox.com> Date: Wed, 22 Nov 2006 09:53:52 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Record layer corner cases References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 >> - First, consider implementations that collect multiple handshake >> messages before sending these in TLS records. The *total* length of >> these messages may exceed the maximum fragment length even if each >> *single* message is below the limit, and in this case we naturally >> would have a record boundary that is not aligned with the message >> boundary. > > The restriction would apply only to TLS 1.2, and there aren't any > TLS 1.2 implementations yet... so we could even require that a single > fragment can't contain multiple handshake messages. I think this would be taking it too far (consider sending ServerHelloDone in its own packet). Plus if you implement TLS 1.2, you also have to implement 1.1 and 1.0 and SSL3 which don't have the restriction. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 22 16:09:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmzKY-0004mG-Gh; Wed, 22 Nov 2006 16:08:30 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GmzKX-0004ld-64 for tls@lists.ietf.org; Wed, 22 Nov 2006 16:08:29 -0500 Received: from proof.pobox.com ([207.106.133.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GmzKS-0003Tt-T9 for tls@lists.ietf.org; Wed, 22 Nov 2006 16:08:29 -0500 Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id 28F03247EA for ; Wed, 22 Nov 2006 16:08:46 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id E5F859869C for ; Wed, 22 Nov 2006 16:08:45 -0500 (EST) Message-ID: <4564BC36.2020200@pobox.com> Date: Wed, 22 Nov 2006 13:08:06 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@lists.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [TLS] I put up a TLS test server 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 There is a TLS 1.2 (draft) test server running at: https://www.mikestoolbox.net:4433/ It also supports TLS 1.1, 1.0, and SSL3 (and SSL2 client hello). The server name, max fragment length, and truncated HMAC extensions are also implemented. It supports RSA, DHE_RSA, and DHE_DSS key exchange methods, and AES_256, AES_128, and DES3 encryption. If you connect to it at: https://www.mikestoolbox.org:4433/ and send it a server name extension, it will return a different certificate. I just changed the DNS, so if you can't connect, try 24.234.114.35. Note the server is iterative, so only one connection will be handled at a time. It will return some info about the TLS session if negotiation succeeds. The server should be able to handle any pathological fragmentation of handshake messages. Please let me know if you have any problems negotiating a session. Thanks, Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 23 05:55:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnCCf-0006cj-UQ; Thu, 23 Nov 2006 05:53:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnCCe-0006cd-PA for tls@ietf.org; Thu, 23 Nov 2006 05:53:12 -0500 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnCCc-0000EU-Ab for tls@ietf.org; Thu, 23 Nov 2006 05:53:12 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAN9as3s028038; Thu, 23 Nov 2006 11:38:16 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 11:37:37 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 11:37:37 +0200 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] Record layer corner cases Date: Thu, 23 Nov 2006 11:37:38 +0200 Message-ID: In-Reply-To: <45648EB0.8050404@pobox.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Record layer corner cases Thread-Index: AccOiy/tM0cyr9DXT2OZeX5X27zQPwAVyYFg From: To: , X-OriginalArrivalTime: 23 Nov 2006 09:37:37.0354 (UTC) FILETIME=[02F84AA0:01C70EE3] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 mike-list@pobox.com wrote: >=20 > I think this would be taking it too far (consider sending > ServerHelloDone in its own packet). Plus if you implement > TLS 1.2, you also have to implement 1.1 and 1.0 and SSL3 > which don't have the restriction. A separate record doesn't mean its own IP packet (or TCP segment); it's just 5 bytes of record header overhead (in case of NULL_WITH_NULL). But yes, maybe it would still be taking it too far... =20 (But TLS 1.2 spec doesn't require you to implement any older spec; and even the older specs in reality seem to have the restriction that you can't fragment handshake messages if you want good interoperability.) Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 23 08:12:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnELy-0003s3-OC; Thu, 23 Nov 2006 08:10:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnELx-0003ry-RP for tls@ietf.org; Thu, 23 Nov 2006 08:10:57 -0500 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnELv-00078I-Tp for tls@ietf.org; Thu, 23 Nov 2006 08:10:57 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kANDAYCc028473; Thu, 23 Nov 2006 15:10:48 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 15:10:11 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 15:10:10 +0200 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] Open issue: Record Version Numbers Date: Thu, 23 Nov 2006 15:10:08 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Open issue: Record Version Numbers Thread-Index: Acb4SZuSGo+szNheQnOXBYF04tkE/AWtL6Lw From: To: X-OriginalArrivalTime: 23 Nov 2006 13:10:10.0651 (UTC) FILETIME=[B486FAB0:01C70F00] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061123151049-6F332BB0-5D41E7C5/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 1a1bf7677bfe77d8af1ebe0e91045c5b 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 Yngve Nysaeter Pettersen wrote: > As I recall there is (or was) a problem with using a length of 32 > with some implementations, which is why Opera, at least is using a > 16 byte challenge in the SSL v2 Hello (which we are no longer using > by default). Hmm... I did some testing, and both IE6 and Firefox 1.5 also use 16-byte challenge in SSLv2 Hello. RFC 2246/4346 are not quite clear about this: in one part, they say the challenge in V2 hello MUST be 32, but elsewhere, they explain that how the challenge is padded with zeroes if it's shorter than 32. Given this, I don't think we should add a new requirement here. Here's an updated version of the text I proposed (also taking into account that according to the SSL2 spec, challenge shorter than 16=20 or longer than 32 is not legal): E.2 Compatibility with SSL 2.0 TLS 1.2 clients that wish to support SSL 2.0 servers MUST send version 2.0 CLIENT-HELLO messages defined in [SSL2]. The message MUST contain the same version number as would be used for ordinary ClientHello, and MUST encode the supported TLS ciphersuites in the CIPHER-SPECS-DATA field as described below. =20 Warning: The ability to send version 2.0 CLIENT-HELLO messages will be phased out with all due haste, since the newer ClientHello format provides better mechanisms for moving to newer versions and negotiating extensions. TLS 1.2 clients SHOULD NOT support SSL 2.0. However, even TLS servers that do not support SSL 2.0 SHOULD accept version 2.0 CLIENT-HELLO messages. The message is presented below in sufficient detail for TLS server implementors; the true definition is still assumed to be [SSL2]. For negotiation purposes, 2.0 CLIENT-HELLO is interpreted the same way as a ClientHello with a "null" compression method and no extensions. Note that this message MUST be sent directly on the wire, not wrapped as a TLS record. For the purposes of calculating Finished and CertificateVerify, the msg_length field is not considered to be a part of the handshake message. uint8 V2CipherSpec[3]; struct { uint16 msg_length; uint8 msg_type; ProtocolVersion version; uint16 cipher_spec_length; uint16 session_id_length; uint16 challenge_length; V2CipherSpec cipher_specs[V2ClientHello.cipher_spec_length]; opaque session_id[V2ClientHello.session_id_length]; opaque challenge[V2ClientHello.challenge_length; } V2ClientHello; msg_length The highest bit MUST be 1; the remaining bits contain the=20 length of the following data in bytes.=20 msg_type The message type for V2ClientHello is one (1). version Equal to ClientHello.client_version. cipher_spec_length This field is the total length of the field cipher_specs. It cannot be zero and MUST be a multiple of the V2CipherSpec=20 length (3). session_id_length The length of the session_id field in bytes; MUST be zero for a client that claims to support TLS 1.2. challenge_length=20 The length of the challenge field in bytes; MUST be between 16 and 32 (inclusive). cipher_specs This is a list of all CipherSpecs the client is willing and able to use. In addition to the 2.0 cipher specs defined in [SSL2], this includes the TLS cipher suites normally sent in ClientHello.cipher_suites, each cipher suite prefixed by a zero byte. For example, TLS ciphersuite {0x00,0x0A} would be sent as {0x00,0x00,0x0A}. session_id This field MUST be empty. challenge Corresponds to ClientHello.random. If the challenge length is less than 32, the TLS server will pad the data with=20 leading (note: not trailing) zero bytes to make it 32 bytes=20 long. Note: Requests to resume a TLS session MUST use a TLS client hello. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 23 10:16:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnGI1-0005Ja-JI; Thu, 23 Nov 2006 10:15:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnGI0-0005Ew-Ac for tls@lists.ietf.org; Thu, 23 Nov 2006 10:15:00 -0500 Received: from bay0-omc3-s12.bay0.hotmail.com ([65.54.246.212]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnGHy-0004XC-Oh for tls@lists.ietf.org; Thu, 23 Nov 2006 10:15:00 -0500 Received: from BAY103-W7 ([65.54.174.107]) by bay0-omc3-s12.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 07:14:56 -0800 X-Originating-IP: [71.140.81.171] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams CC: Subject: RE: [TLS] Serious crypto problem fixed by envelope HMAC methodinstead of currently used prefix Date: Thu, 23 Nov 2006 07:14:55 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 23 Nov 2006 15:14:56.0032 (UTC) FILETIME=[22297A00:01C70F12] X-Spam-Score: 2.4 (++) X-Scan-Signature: 827a2a57ca7ab0837847220f447e8d56 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="===============0635540378==" Errors-To: tls-bounces@lists.ietf.org --===============0635540378== Content-Type: multipart/alternative; boundary="_92a6598c-1116-49f8-a5e7-26867464ec26_" --_92a6598c-1116-49f8-a5e7-26867464ec26_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > From: janm@transactionware.com > No.> >... > What happens with TCP packets depends on many variables. These are> irrel= evant to TLS and are hidden by a TCP implementation.> > TLS has a record la= yer to provide a record abstraction on top of TCP.>=20 Distinguish TCP packets from TCP connection state changes, however. These w= ere all security-relevant signals, for SSL designers, as indicated by the s= ocket. =20 And, dont read too much into the term "record", and don't associate it with= TCP/IP's internal signalling or "framing" behaviour for a given network me= dia. The record construct refers to the framing of the SSL2 handshake messa= ges, and then the framing due to handling the resulting security context(s)= , suited to Type II cipher environments. =20 SSL3 always intended that one could multiplex different handshakes and diff= erent security contexts within the reliable byte stream(s) (perhaps and onl= y perhaps implemented using TCP/IP), befitting resolving an HTML page with = multiple image and voice tags to be rendered in parallel, along with other = HTML pages in the frameset being similarly rendered from other website sour= ces via http or other URL protocols. =20 TLS1.1+ seems to be rapidly deviating from the intended multiplexing archit= ecture, by always extending the common handshake (wot crypto wimps!). It sh= ould have been specifying and standardizing additional handshakes, for use = beyond https, using a common pool of std ciphersuites, when resolving non H= TML media such as different XML document classes.=20 =20 Perhaps its not too late to put TLS back into its original security model. = One could be ensuring that when the WS-Security secureConversation protocol= (for example) is performing the actions of resolving a particular class o= f XML media then suitably multiplexed handshake(s) are occuring within the = record layer - (a) supporting the http-bindinhs and (b) the secureconversat= ion protocol itself, in parallel as necessary. In such a handshake, entropy= may of course be being obtained from a server, rather than from random sou= rce, as in traditiona netscape https for example, where the server retains = information records to address crypto regulations (e.g. the proposed signed= evidence work items). If one is using the TLS1.1 SAML extension for identi= fication, this third handshake may be specifically using SAML's delegated = entropy modes when applying XML-encryption-based ciphersuites. Who knows! B= ut this is what the architecture was intended to support! =20 I for one make the assumption that, upon resuming a (or being induced by an= ISP to resume an interupted) SSL2 or SSl3 session, one may be being requir= ed to re-renegotiate ciphersuites when picking up the new TCP channel (that= requires SSL->TLS handling, and then use of govt-escrowed (i.e. compromise= d) PSK ciphersuite perhaps) - at the right moment to (i) perform the legal = interception of the particular multiplexed session identified, and (ii) ena= ble the ISP to show that its intervetion at the SSL session layer, probably= via TCP interference, fits the particular class of interception order. =20 Ok. Ive hope made my point. Makikng SSL3 be beholden to TCP signals is frau= ght with security sideeffects, that IETF's senior security architects may b= e intending or not intending when standardizing TLS. =20 =20 > Jan Mikkelsen>=20 Peter.> > _______________________________________________> TLS mailing list= > TLS@lists.ietf.org> https://www1.ietf.org/mailman/listinfo/tls _________________________________________________________________ Check the weather nationwide with MSN Search: Try it now! http://search.msn.com/results.aspx?q=3Dweather&FORM=3DWLMTAG= --_92a6598c-1116-49f8-a5e7-26867464ec26_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable






> From: janm@transactionware= .com

> No.
>
>...
> What happens with TCP packets depends on many variables. These are
= > irrelevant to TLS and are hidden by a TCP implementation.
>
= > TLS has a record layer to provide a record abstraction on top of TCP.<= BR>>

Distinguish TCP packets from TCP connection state changes, however. These w= ere all security-relevant signals, for SSL designers, as indicated by the s= ocket.
 
And, dont read too much into the term "record", and don't associate it with= TCP/IP's internal signalling or "framing" behaviour for a given network me= dia. The record construct refers to the framing of the SSL2 handshake messa= ges, and then the framing due to handling the resulting security context(s)= , suited to Type II cipher environments.
 
SSL3 always intended that one could multiplex different handshakes and diff= erent security contexts within the reliable byte stream(s) (perhaps and onl= y perhaps implemented using TCP/IP), befitting resolving an HTML page with = multiple image and voice tags to be rendered in parallel, along with other = HTML pages in the frameset being similarly rendered from other website sour= ces via http or other URL protocols.
 
TLS1.1+ seems to be rapidly deviating from the intended multiplexing archit= ecture, by always extending the common handshake (wot crypto wimps!). It sh= ould have been specifying and standardizing additional handshakes, for use = beyond https, using a common pool of std ciphersuites, when resolving non H= TML media such as different XML document classes.
 
Perhaps its not too late to put TLS back into its original security model. = One could be ensuring that when the WS-Security secureConversation pro= tocol (for example) is  performing the actions of resolving a particul= ar class of XML media then suitably multiplexed handshake(s) are = occuring within the record layer - (a) supporting the http-bindinhs and (b)= the secureconversation protocol itself, in parallel as necessary. In such = a handshake, entropy may of course be being obtained from a server, rather = than from random source, as in traditiona netscape https for example, where= the server retains information records to address crypto regulations = (e.g. the proposed signed evidence work items). If one is using the TLS1.1 = SAML extension for identification, this  third handshake may be s= pecifically using SAML's delegated entropy modes when applying XML-encrypti= on-based ciphersuites. Who knows! But this is what the architecture was int= ended to support!
 
I for one make the assumption that, upon resuming a (or being induced by an= ISP to resume an interupted) SSL2 or SSl3 session, one may be being requir= ed to re-renegotiate ciphersuites when picking up the new TCP channel (that= requires SSL->TLS handling, and then use of govt-escrowed (i.e. comprom= ised) PSK ciphersuite perhaps) - at the right moment to (i) perform th= e legal interception of the particular multiplexed session identified, and = (ii) enable the ISP to show that its intervetion at the SSL session layer, = probably via TCP interference, fits the particular class of interception or= der.
 
Ok. Ive hope made my point. Makikng SSL3 be beholden to TCP signals is frau= ght with security sideeffects, that IETF's senior security architects may b= e intending or not intending when standardizing TLS.
 
 
> Jan Mikkelsen
>
Peter.
>
> _______________________________________________
= > TLS mailing list
> TLS@lists.ietf.org
> https://www1.ietf.= org/mailman/listinfo/tls


Check the weather nationwide wi= th MSN Search Try it now! = --_92a6598c-1116-49f8-a5e7-26867464ec26_-- --===============0635540378== 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 --===============0635540378==-- From tls-bounces@lists.ietf.org Thu Nov 23 17:06:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnMgS-0005VV-U9; Thu, 23 Nov 2006 17:04:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnMgR-0005Sj-LB for tls@lists.ietf.org; Thu, 23 Nov 2006 17:04:39 -0500 Received: from proof.pobox.com ([207.106.133.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnMgM-0004DP-DF for tls@lists.ietf.org; Thu, 23 Nov 2006 17:04:39 -0500 Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id D69A528CAB for ; Thu, 23 Nov 2006 17:04:55 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 9C3BB96DE8 for ; Thu, 23 Nov 2006 17:04:55 -0500 (EST) Message-ID: <45661ADA.804@pobox.com> Date: Thu, 23 Nov 2006 14:04:10 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] I put up a TLS test server References: <4564BC36.2020200@pobox.com> In-Reply-To: <4564BC36.2020200@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 neglected to install a DSA certificate chain, so the DHE_DSS cipher suites weren't working. I have fixed it, so it should work now. Note that there is only one DSA certificate chain, so to test the server name extension, you need to negotiate with RSA or DHE_RSA. Mike I wrote: > There is a TLS 1.2 (draft) test server running at: > > https://www.mikestoolbox.net:4433/ > > It also supports TLS 1.1, 1.0, and SSL3 (and SSL2 > client hello). The server name, max fragment length, > and truncated HMAC extensions are also implemented. > > It supports RSA, DHE_RSA, and DHE_DSS key exchange > methods, and AES_256, AES_128, and DES3 encryption. > > If you connect to it at: > > https://www.mikestoolbox.org:4433/ > > and send it a server name extension, it will return > a different certificate. I just changed the DNS, so > if you can't connect, try 24.234.114.35. > > Note the server is iterative, so only one connection > will be handled at a time. It will return some info > about the TLS session if negotiation succeeds. > > The server should be able to handle any pathological > fragmentation of handshake messages. > > Please let me know if you have any problems negotiating > a session. > > Thanks, > > Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 23 17:19:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnMuQ-0001ed-61; Thu, 23 Nov 2006 17:19:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnMuP-0001eY-HQ for TLS@lists.ietf.org; Thu, 23 Nov 2006 17:19:05 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnMuO-0006QQ-5d for TLS@lists.ietf.org; Thu, 23 Nov 2006 17:19:05 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id XAA08142; Thu, 23 Nov 2006 23:19:01 +0100 (MEZ) From: Martin Rex Message-Id: <200611232219.XAA20698@uw1048.wdf.sap.corp> Subject: Re: [TLS] https question To: batyr@sympatico.ca (Omirjan Batyrbaev) Date: Thu, 23 Nov 2006 23:19:00 +0100 (MET) In-Reply-To: <00ba01c70ddf$16dd52e0$895e5e41@pbo8f8e10aowa> from "Omirjan Batyrbaev" at Nov 21, 6 09:37:01 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: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: TLS@lists.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 Omirjan Batyrbaev wrote: > > How does non-decrypting load balancer or proxy would know where is the end > of the https request? Is content length encrypted? A non-decrypting load balancer does not know that. I has also no means to detect whether the protocol within the SSL/TLS tunnel is really HTTP, or whether it is something else. Only the record protocol is visible to such a load-balancer, but nothing about the content once the encryption is started during the initial SSL/TLS handshake. A curious observer might attempt traffic analyisis by the number and size of the ssl records, but efficient client and browser implementations might aggregate requests and replies of a HTTP/1.1 persistent connection into few large SSL Records, i.e 10 pipelined requests into a single SSL Record with application data, and the Server could (in theory) do the same with the replies. Load balancing HTTPS without decrypting does have some limitations. If the application is not state-less, then using the ssl session ID for selecting the backend target is insufficient and will regularly cause problems. Routing the requests based on client IP addresses and configurable client IP address ranges (to support client-side proxy farms) is probably the most robust approach. If the majority of clients come through one single client-side proxy, then this doesn't work, of course. Having the backend (SSL/TLS terminating) Servers issue SSL session IDs with backend-idenifying tags and a loadbalancer that can extract and use these tags from the SSL session IDs might work, though, but the existing SSL/TLS implementations may not currently offer an API for the application to put such a tag into every SSL session ID that they issue. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 23 19:44:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnPA7-0003EL-Mn; Thu, 23 Nov 2006 19:43:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnPA6-0003EG-Tq for tls@ietf.org; Thu, 23 Nov 2006 19:43:26 -0500 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnPA5-0008Pv-Mh for tls@ietf.org; Thu, 23 Nov 2006 19:43:26 -0500 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id A077996306 for ; Thu, 23 Nov 2006 19:43:46 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id 6E045962F9 for ; Thu, 23 Nov 2006 19:43:46 -0500 (EST) Message-ID: <45664015.6000802@pobox.com> Date: Thu, 23 Nov 2006 16:43:01 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Record layer corner cases References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 clearly misunderstood what you meant, and actually agree that it would be good to have one handshake message per record. Practically, though, you will need to support earlier versions for some time. Just try to connect to the industry-leading certificate authority with TLS 1.0: https://www.verisign.com/ for example. Mike Pasi.Eronen@nokia.com wrote: > mike-list@pobox.com wrote: >> I think this would be taking it too far (consider sending >> ServerHelloDone in its own packet). Plus if you implement >> TLS 1.2, you also have to implement 1.1 and 1.0 and SSL3 >> which don't have the restriction. > > A separate record doesn't mean its own IP packet (or TCP segment); > it's just 5 bytes of record header overhead (in case of > NULL_WITH_NULL). But yes, maybe it would still be taking it too far... > > (But TLS 1.2 spec doesn't require you to implement any older spec; and > even the older specs in reality seem to have the restriction that you > can't fragment handshake messages if you want good interoperability.) > > Best regards, > Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 23 20:08:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnPXZ-0005no-4K; Thu, 23 Nov 2006 20:07:41 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnPXY-0005na-43 for tls@ietf.org; Thu, 23 Nov 2006 20:07:40 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnPXT-0004Ox-Ni for tls@ietf.org; Thu, 23 Nov 2006 20:07:40 -0500 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id CAA18026; Fri, 24 Nov 2006 02:01:09 +0100 (MEZ) From: Martin Rex Message-Id: <200611240101.CAA23300@uw1048.wdf.sap.corp> Subject: Re: [TLS] Record layer corner cases To: mike-list@pobox.com (Mike) Date: Fri, 24 Nov 2006 02:01:09 +0100 (MET) In-Reply-To: <45664015.6000802@pobox.com> from "Mike" at Nov 23, 6 04:43:01 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: 7655788c23eb79e336f5f8ba8bce7906 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 Mike wrote: > > I clearly misunderstood what you meant, and actually agree that it > would be good to have one handshake message per record. Practically, > though, you will need to support earlier versions for some time. > Just try to connect to the industry-leading certificate authority > with TLS 1.0: https://www.verisign.com/ for example. Talking of VeriSign... A few years ago, www.verisign.com had been sending out an expired rootCA certificate in the certification path of the Server, and curiously, none of the Web Browsers complained when it had a replacement cert (same Subject&Issuer, same key, longer validity) in the list of trust anchors. If the newer local key was deleted in the browsers list of trust anchors, then the expired rootCA cert sent by www.verisign.com became visible. Maybe there should be some guidance, common sense doesn't seem to be sufficient (it took VeriSign several months to fix it when I complained to them about their server misconfiguration/misbehaviour). -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 23 20:32:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnPuT-0000ol-71; Thu, 23 Nov 2006 20:31:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnPuR-0000od-Mf for tls@lists.ietf.org; Thu, 23 Nov 2006 20:31:19 -0500 Received: from mail.transactionware.com ([203.14.245.7]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GnPuP-0008Ez-Qu for tls@lists.ietf.org; Thu, 23 Nov 2006 20:31:19 -0500 Received: (qmail 17739 invoked from network); 24 Nov 2006 01:31:24 -0000 Received: from new.transactionware.com (192.168.1.55) by dm.transactionware.com with SMTP; 24 Nov 2006 01:31:24 -0000 Received: (qmail 25058 invoked by uid 1026); 24 Nov 2006 01:31:24 -0000 Received: from 127.0.0.1 by new.transactionware.com (envelope-from , uid 1003) with qmail-scanner-1.25 (spamassassin: 3.0.2. Clear:RC:1(127.0.0.1):. Processed in 3.288272 secs); 24 Nov 2006 01:31:24 -0000 Received: from unknown (HELO JMLAPTOP) (unknown) by unknown with SMTP; 24 Nov 2006 01:31:20 -0000 From: "Jan Mikkelsen" To: "'Peter Williams'" Subject: RE: [TLS] Serious crypto problem fixed by envelope HMACmethodinstead of currently used prefix Date: Fri, 24 Nov 2006 12:31:00 +1100 Organization: Transactionware Message-ID: <003201c70f68$32cd28b0$c801a8c0@transactionware.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Importance: Normal In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 287c806b254c6353fcb09ee0e53bbc5e Cc: tls@lists.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'm responding very generally ... Peter Williams wrote: > > What happens with TCP packets depends on many variables. These are > > irrelevant to TLS and are hidden by a TCP implementation. > >=20 > > TLS has a record layer to provide a record abstraction on=20 > top of TCP. > >=20 >=20 > Distinguish TCP packets from TCP connection state changes,=20 > however. These were all security-relevant signals, for SSL=20 > designers, as indicated by the socket. > =20 > And, dont read too much into the term "record", and don't=20 > associate it with TCP/IP's internal signalling or "framing"=20 > behaviour for a given network media. The record construct=20 > refers to the framing of the SSL2 handshake messages, and=20 > then the framing due to handling the resulting security=20 > context(s), suited to Type II cipher environments. > =20 > SSL3 always intended that one could multiplex different=20 > handshakes and different security contexts within the=20 > reliable byte stream(s) (perhaps and only perhaps implemented=20 > using TCP/IP), befitting resolving an HTML page with multiple=20 > image and voice tags to be rendered in parallel, along with=20 > other HTML pages in the frameset being similarly rendered=20 > from other website sources via http or other URL protocols. Are you saying that SSL3 was intended to allow multiplexing over a = single reliable byte stream? If so, do you have a reference? > TLS1.1+ seems to be rapidly deviating from the intended=20 > multiplexing architecture, by always extending the common=20 > handshake (wot crypto wimps!). It should have been specifying=20 > and standardizing additional handshakes, for use beyond=20 > https, using a common pool of std ciphersuites, when=20 > resolving non HTML media such as different XML document classes.=20 Why? TLS provides a reliable byte stream with specific security services = applied. Providing "media specific" services or multiplexing in a protocol like = TLS is clearly a mistake. TCP/IP does a fine job of multiplexing. Why do = it again? An application implementing a higher layer protocol can choose to allow specific TLS features and to deny others to meet a specific need, but = that is where it should end. TLS has no knowledge of https. > Perhaps its not too late to put TLS back into its original=20 > security model. One could be ensuring that when the=20 > WS-Security secureConversation protocol (for example) is =20 > performing the actions of resolving a particular class of XML=20 > media then suitably multiplexed handshake(s) are occuring=20 > within the record layer - (a) supporting the http-bindinhs=20 > and (b) the secureconversation protocol itself, in parallel=20 > as necessary. In such a handshake, entropy may of course be=20 > being obtained from a server, rather than from random source,=20 > as in traditiona netscape https for example, where the server=20 > retains information records to address crypto regulations=20 > (e.g. the proposed signed evidence work items). If one is=20 > using the TLS1.1 SAML extension for identification, this =20 > third handshake may be specifically using SAML's delegated=20 > entropy modes when applying XML-encryption-based=20 > ciphersuites. Who knows! But this is what the architecture=20 > was intended to support! > =20 > I for one make the assumption that, upon resuming a (or being=20 > induced by an ISP to resume an interupted) SSL2 or SSl3=20 > session, one may be being required to re-renegotiate=20 > ciphersuites when picking up the new TCP channel (that=20 > requires SSL->TLS handling, and then use of govt-escrowed=20 > (i.e. compromised) PSK ciphersuite perhaps) - at the right=20 > moment to (i) perform the legal interception of the=20 > particular multiplexed session identified, and (ii) enable=20 > the ISP to show that its intervetion at the SSL session=20 > layer, probably via TCP interference, fits the particular=20 > class of interception order. I am guessing that you are concerned about the crypto in a resumed TLS session being downgraded, but I'm not sure. If this is what concerns = you, then write (or configure) your application to not use ciphersuites you = don't want. =20 > Ok. Ive hope made my point. Makikng SSL3 be beholden to TCP=20 > signals is fraught with security sideeffects, that IETF's=20 > senior security architects may be intending or not intending=20 > when standardizing TLS. Sorry, I think I've missed your real point entirely. TLS's purpose is to provide a reliable byte stream service with strong confidentiality, integrity, and/or authentication. To do this, TLS uses = a reliable byte stream service without strong security guarantees, such as TCP. Regards, Jan Mikkelsen. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 23 22:47:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnS10-0001ok-IA; Thu, 23 Nov 2006 22:46:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnS0z-0001ob-JI for tls@lists.ietf.org; Thu, 23 Nov 2006 22:46:13 -0500 Received: from bay0-omc3-s23.bay0.hotmail.com ([65.54.246.223]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnS0w-0007u5-DM for tls@lists.ietf.org; Thu, 23 Nov 2006 22:46:13 -0500 Received: from BAY103-W1 ([65.54.174.101]) by bay0-omc3-s23.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 19:46:09 -0800 X-Originating-IP: [71.140.81.171] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Jan Mikkelsen Subject: RE: [TLS] Serious crypto problem fixed by envelope HMACmethodinstead of currently used prefix Date: Thu, 23 Nov 2006 19:46:09 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 24 Nov 2006 03:46:09.0861 (UTC) FILETIME=[1441F750:01C70F7B] X-Spam-Score: 2.4 (++) X-Scan-Signature: 6a817af60e4281a101681ecb646dffff Cc: tls@lists.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="===============1484841462==" Errors-To: tls-bounces@lists.ietf.org --===============1484841462== Content-Type: multipart/alternative; boundary="_5faffbd2-b477-43d9-be0c-46be0b912afc_" --_5faffbd2-b477-43d9-be0c-46be0b912afc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jan: =20 1. Introduction =20 I'm glad we can have a general conversation. Lets remember though that this= is ietf, not the ssl-talk community. IETF has formal information distribut= ion and decision processes, which are much less inclusive than ssl-talk pro= cesses were. We may well be told to shut up; IETF has to address a much bro= ader set of political issues and players, than we ever had to do. 10 years = into TLS, its not my intention to restart the process! At the same time, to= become a Internet Standard, the document has to show its being clearly und= erstood by the average technical reader.=20 =20 On this score, I do worry when I see the some of the topics being discussed= . TLS is apparently diverging from SSL precepts to the point where the inte= rnet standard time test is no longer valid, and we may need to restart the = clock. =20 So, to start the review, lets magine, as we did, that we are a microsoft-eq= uivalent winsock programming team for SSL, not knowing quite who will be us= ing our sockets, or for what purpose. Assume that those users on the initia= ting end are as diverse as content-specific plugins to browsers, or HTML-ba= sed javascript apps and java applets, on a competing "web" platform to wind= ows. While the winsock provider for SSL3 is installed by default, we dont k= now as a design team which other providers will be pre- or post-hooked; ass= ume we provide custom socket configuration support to orchestrate how, say,= SSL3's two layers cooperate. Perhaps, by default, the record layer only en= capsulates the "SSL Handshake" protocol, requiring socket configuration to = do otherwise. Assume that this is our architectural plan, and assumed prima= ry usage model. =20 We also have a target delivery date for IE3, Jan 1995. Assume noone knows w= hat to do with client certs, and only RSA ciphersuites matter, with RSA's r= eversible properties and software key management and crypto libraries; assu= me from the outset that OPTIONAL server-side caches retain session keys, fo= r use in session resumption and law enforcement processes relevant to banki= ng regulation (the main design target of SSL2) . Assume banks are writing l= arge CGI applications, and want SSL removed at the in router/network land, = and do NOT want network identification and authentication techniques to be = used (e.g. client certs, or IP addresses) within the mainframe application = domain that CGI is binding web applications to. Assume that actual delivery= of SSL as an actual winsock provider becomes politically/competitively imp= ractical, even tho the concept is retained architecturally. (* MSFT did act= ually deliver a winsock provider, before NSA politics killed it). =20 2. Evidence and Analysis =20 If we consider the authoritative SSL3 citation, we can refer to its opening= statements on architecture (that may not align with the "received architec= ture" in TLS, for all I know):- =20 "The primary goal of the SSL Protocol is to provide privacy and reliabili= ty between two communicating applications. The protocol is composed of t= wo layers. At the lowest level, layered on top of some reliable transpor= t protocol (e.g., TCP[TCP]), is the SSL Record Protocol. The SSL Record = Protocol is used for encapsulation of various higher level protocols. On= e such encapsulated protocol, the SSL Handshake Protocol, allows the serv= er and client to authenticate each other and to negotiate an encryption a= lgorithm and cryptographic keys before the application protocol transmits= or receives its first byte of data." =20 =20 Then we parse the design goals stated in this architecture: =20 1. the "SSL Handshake Protocol" is "one such encapsulated protocol" borne b= y the record protocol. Furthermore, various higher level protocol are archi= tecturally entitled to be encapsulated in the record protocol. I trust this= address my general point about multiplexing. Change the term multiplexing = to "multi-capsulating", if one must be an american pedant when using Englis= h. 2. the lowest record protocol layer is "layered on top of some reliable tra= nsport protocol (e.g., TCP[TCP])". TCP is clearly cited as an example, onl= y. TCP was not assumed in the security model design goals, though of course= reality often intruded on the team! A record layer layered on the protocol= known as the "SSL3 Protocol" was certainly intended (i.e. SSL tunneling). = Do not assume HTTP 1.1 keep-alive existed, and the internet is being floode= d by shortlife TCP instances that are upsetting US ISPs and the US FIX-arch= itecture backbone concept for an IP internetwork design. =20 3. the primary goal of SSL Protocol was to provide privacy and reliability,= app to app. As my parsing in (2) above indicates, the reliability properti= es of one protocol stack (record layer over TCP) might be different to anot= her (record layer over the SSL Protocol, over TP4). As history may recall, = at the time getting reliable transport sessions between class d addressed a= pplications was a challenge, as the internet had no bandwidth reservation t= echniques, at the time. =20 4. What is not stated (as https was deliberately never specified, except by= Eric's "authorized" rendition of web reality from his (then implementor's)= viewpoint) was how this protocol architecture addressed hypermedia applica= tions. It true that it is not stated that "reliable transport" should be as= sume to include multicast transport, supporting (multicast hypermedia) appl= ications. Take it from me, however, that this was intended, when addressing= protocol goals such as were being considered (at the time) for HTML-enhanc= ed nntp , and pre-ldap multicast white pages directories and their support= ing directory replication/authentication protocols (for efficient PKI cert = distribution!). In terms of its read./write secure session state management design, lets no= te, the critical text: " An SSL session may include multiple secure connections; in addition, = parties may have multiple simultaneous sessions." =20 3. Conclusions on Internet Standard status In terms of whether SSL3/TLS is prime time for Internet Standard status , i= ts often worth testing what folks read into the document, when they impleme= nt long after the original design issues have long since left the community= consciousness. =20 With TLS 1.0 endorsing null confidentiality ciphersuites, I assume the pri= mary goal statement ("provide privacy and reliabily...to apps") in TLS got = changed from that in SSL3. Goal:Privacy assumed a robust confidentiality se= rvice, and goal:reliablity assumed OPTIONAL robust session management/resum= ption techniques that were intended to be sensitive to the IP network over = which the https/SSL connections were flowing while understanding the socio-= political risks that come with sever-side session caches and hidden session= restarts using lower strength ciphersuites. =20 its not clear to me, from recent reading, that this community understand th= at session caches are OPTIONAL, and a function of the network topology of t= he IP backbone. In tying SSL interworking quality to TCP behavior in partic= ular (probably US) IP nets, I worry! hypermedia apps and https understandin= g aside, I worry about whether folks really get the secure session state ar= chitecture within SSL! Its really not clear that folks get that SSL Record = layer contains its own fragmentation and reassembly possibilities, which ad= dressed the competing goals of compression contexts and security contexts, = for multiple, multiplexed secure sessions operating in two directions, simu= ltaneously. While someone thought quite carefully about the interaction of = SAML1.1 protocol's session establisment process and its interaction with th= e SSL architecture for secure sessions, its not clear TLS1.2 is properly ad= dressing the radical changes brought about by SAML2.0 - on multi-site sessi= on destruction, for example.=20 =20 In summary, as an Internet Standard, its not clear that TLS is ready for su= ch standing. Its evidently really not a widely understood secure session m= anagement architecture , and its architecture or writeup was not sufficient= apparently for it to keep uptodate with the inevitable changes that always= go on around standard protocols. =20 But, when I rationalize, this is not all that surprising. The specific inte= nt of the writeup was to benefit implementors and RSA's cryptographic analy= sts; support standardization was not an explicit writing goal. > From: janm@transactionware.com> To: home_pw@msn.com> CC: tls@lists.ietf.o= rg> Subject: RE: [TLS] Serious crypto problem fixed by envelope HMACmethodi= nstead of currently used prefix> Date: Fri, 24 Nov 2006 12:31:00 +1100> > I= 'm responding very generally ...> > Peter Williams wrote:> > > What happens= with TCP packets depends on many variables. These are> > > irrelevant to T= LS and are hidden by a TCP implementation.> > > > > > TLS has a record laye= r to provide a record abstraction on > > top of TCP.> > > > > > > Distingui= sh TCP packets from TCP connection state changes, > > however. These were a= ll security-relevant signals, for SSL > > designers, as indicated by the so= cket.> > > > And, dont read too much into the term "record", and don't > > = associate it with TCP/IP's internal signalling or "framing" > > behaviour f= or a given network media. The record construct > > refers to the framing of= the SSL2 handshake messages, and > > then the framing due to handling the = resulting security > > context(s), suited to Type II cipher environments.> = > > > SSL3 always intended that one could multiplex different > > handshake= s and different security contexts within the > > reliable byte stream(s) (p= erhaps and only perhaps implemented > > using TCP/IP), befitting resolving = an HTML page with multiple > > image and voice tags to be rendered in paral= lel, along with > > other HTML pages in the frameset being similarly render= ed > > from other website sources via http or other URL protocols.> > Are y= ou saying that SSL3 was intended to allow multiplexing over a single> relia= ble byte stream? If so, do you have a reference?> > > TLS1.1+ seems to be r= apidly deviating from the intended > > multiplexing architecture, by always= extending the common > > handshake (wot crypto wimps!). It should have bee= n specifying > > and standardizing additional handshakes, for use beyond > = > https, using a common pool of std ciphersuites, when > > resolving non HT= ML media such as different XML document classes. > > Why?> > TLS provides a= reliable byte stream with specific security services applied.> Providing "= media specific" services or multiplexing in a protocol like TLS> is clearly= a mistake. TCP/IP does a fine job of multiplexing. Why do it> again?> > An= application implementing a higher layer protocol can choose to allow> spec= ific TLS features and to deny others to meet a specific need, but that> is = where it should end. TLS has no knowledge of https.> > > Perhaps its not to= o late to put TLS back into its original > > security model. One could be e= nsuring that when the > > WS-Security secureConversation protocol (for exam= ple) is > > performing the actions of resolving a particular class of XML >= > media then suitably multiplexed handshake(s) are occuring > > within the= record layer - (a) supporting the http-bindinhs > > and (b) the secureconv= ersation protocol itself, in parallel > > as necessary. In such a handshake= , entropy may of course be > > being obtained from a server, rather than fr= om random source, > > as in traditiona netscape https for example, where th= e server > > retains information records to address crypto regulations > > = (e.g. the proposed signed evidence work items). If one is > > using the TLS= 1.1 SAML extension for identification, this > > third handshake may be spec= ifically using SAML's delegated > > entropy modes when applying XML-encrypt= ion-based > > ciphersuites. Who knows! But this is what the architecture > = > was intended to support!> > > > I for one make the assumption that, upon = resuming a (or being > > induced by an ISP to resume an interupted) SSL2 or= SSl3 > > session, one may be being required to re-renegotiate > > ciphersu= ites when picking up the new TCP channel (that > > requires SSL->TLS handli= ng, and then use of govt-escrowed > > (i.e. compromised) PSK ciphersuite pe= rhaps) - at the right > > moment to (i) perform the legal interception of t= he > > particular multiplexed session identified, and (ii) enable > > the I= SP to show that its intervetion at the SSL session > > layer, probably via = TCP interference, fits the particular > > class of interception order.> > I= am guessing that you are concerned about the crypto in a resumed TLS> sess= ion being downgraded, but I'm not sure. If this is what concerns you,> then= write (or configure) your application to not use ciphersuites you don't> w= ant.> > > Ok. Ive hope made my point. Makikng SSL3 be beholden to TCP > > s= ignals is fraught with security sideeffects, that IETF's > > senior securit= y architects may be intending or not intending > > when standardizing TLS.>= > Sorry, I think I've missed your real point entirely.> > TLS's purpose is= to provide a reliable byte stream service with strong> confidentiality, in= tegrity, and/or authentication. To do this, TLS uses a> reliable byte strea= m service without strong security guarantees, such as> TCP.> > > Regards,> = > Jan Mikkelsen.>=20 _________________________________________________________________ Check the weather nationwide with MSN Search: Try it now! http://search.msn.com/results.aspx?q=3Dweather&FORM=3DWLMTAG= --_5faffbd2-b477-43d9-be0c-46be0b912afc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Jan:
 
1. Introduction
 
I'm glad we can have a general conversation. Lets remember though that this= is ietf, not the ssl-talk community. IETF has formal information distribut= ion and decision processes, which are much less inclusive than ssl-talk pro= cesses were. We may well be told to shut up; IETF has to address a much bro= ader set of political issues and players, than we ever had to do. 10 years = into TLS, its not my intention to restart the process! At the same time, to= become a Internet Standard, the document has to show its being clearl= y understood by the average technical reader.
 
On this score, I do worry when I see the some of the topics being discussed= . TLS is apparently diverging from SSL precepts to the point where the inte= rnet standard time test is no longer valid, and we may need to restart the = clock.
 
So, to start the review, lets magine, as we did, that we are a microso= ft-equivalent winsock programming team for SSL, not knowing quite who will = be using our sockets, or for what purpose. Assume that those users on the i= nitiating end are as diverse as content-specific plugins to browsers, or HT= ML-based javascript apps and java applets, on a competing "web" platform to= windows. While the winsock provider for SSL3 is installed by default, we d= ont know as a design team which other providers will be pre- or post-hooked= ; assume we provide custom socket configuration support to orchestrate how,= say, SSL3's two layers cooperate. Perhaps, by default, the record layer on= ly encapsulates the "SSL Handshake" protocol, requiring socket configuratio= n to do otherwise. Assume that this is our architectural plan, and assumed = primary usage model.
 
We also have a target delivery date for IE3, Jan 1995. Assume noone knows w= hat to do with client certs, and only RSA ciphersuites matter, with RSA's r= eversible properties and software key management and crypto libraries; assu= me from the outset that OPTIONAL server-side caches retain session keys, fo= r use in session resumption and law enforcement processes relevant to banki= ng regulation (the main design target of SSL2) . Assume banks are writing l= arge CGI applications, and want SSL removed at the in router/network land, = and do NOT want network identification and authentication techniques to be = used (e.g. client certs, or IP addresses) within the mainframe application = domain that CGI is binding web applications to. Assume that actual delivery= of SSL as an actual winsock provider becomes politically/competi= tively impractical, even tho the concept is retained architecturally. (* MS= FT did actually deliver a winsock provider, before NSA politics killed it).=
 
2. Evidence and Analysis
 
If we consider the authoritative SSL3 citation, we can refer to its opening= statements on architecture (that may not align with the "received architec= ture" in TLS, for all I know):-
 
"The primary goal of the SSL Protocol is to provide privacy and
 &n= bsp; reliability between two communicating applications.  The protocol=
   is composed of two layers.  At the lowest level, laye= red on top of
   some reliable transport protocol (e.g., TCP[T= CP]), is the SSL
   Record Protocol.  The SSL Record Prot= ocol is used for encapsulation
   of various higher level prot= ocols.  One such encapsulated protocol,
   the SSL Handsh= ake Protocol, allows the server and client to
   authenticate = each other and to negotiate an encryption algorithm
   and cry= ptographic keys before the application protocol transmits or
  = ; receives its first byte of data."
 
 
Then we parse the design goals stated in this architecture:
 
1. the "SSL Handshake Protocol" is "one such encapsulated protocol" borne b= y the record protocol. Furthermore, various higher level protocol are archi= tecturally entitled to be encapsulated in the record protocol. I trust this= address my general point about multiplexing. Change the term multiplexing = to "multi-capsulating", if one must be an american pedant when using Englis= h.

2. the lowest record protocol layer is "layered on top of some reliable tra= nsport protocol (e.g., TCP[TCP])". TCP is  clearly cited as an example= , only. TCP was not assumed in the security model design goals, though of c= ourse reality often intruded on the team! A record layer layered on the pro= tocol known as the "SSL3 Protocol" was certainly intended (i.e. SSL tunneli= ng). Do not assume HTTP 1.1 keep-alive existed, and the internet is being f= looded by shortlife TCP instances that are upsetting US ISPs and the US FIX= -architecture backbone concept for an IP internetwork design.
 
3. the primary goal of SSL Protocol was to provide privacy and reliability,= app to app. As my parsing in (2) above indicates, the reliability properti= es of one protocol stack (record layer over TCP) might be different to anot= her (record layer over the SSL Protocol, over TP4). As history may recall, = at the time getting reliable transport sessions between class d addressed a= pplications was a challenge, as the internet had no bandwidth reservation t= echniques, at the time.
 
4. What is not stated (as https was deliberately never specified, except by= Eric's "authorized" rendition of web reality from his (then implementor's)= viewpoint) was how this protocol architecture addressed hypermedia applica= tions. It true that it is not stated that "reliable transport" should be as= sume to include multicast transport, supporting (multicast hypermedia) appl= ications. Take it from me, however, that this was intended, when addressing= protocol goals such as were being considered (at the time) for HTML-enhanc= ed nntp  , and pre-ldap multicast white pages directories and the= ir supporting directory replication/authentication protocols (for effi= cient PKI cert distribution!).

In terms of its read./write secure session state management design, lets no= te, the critical text:
"   An SSL session may include multiple secure connections; in   addition, parties may have multiple simultaneous sessions."
 
3. Conclusions on Internet Standard status

In terms of whether SSL3/TLS is prime time for Internet Standard status= , its often worth testing what folks read into the document, when they imp= lement long after the original design issues have long since left the commu= nity consciousness.
 
With TLS 1.0 endorsing  null confidentiality ciphersuites, I assu= me the primary goal statement ("provide privacy and reliabily...to apps") i= n TLS got changed from that in SSL3. Goal:Privacy assumed a robust confiden= tiality service, and goal:reliablity assumed OPTIONAL robust session manage= ment/resumption techniques that were intended to be sensitive to the IP net= work over which the https/SSL connections were flowing while understanding = the socio-political risks that come with sever-side session caches and= hidden session restarts using lower strength ciphersuites.
 
its not clear to me, from recent reading, that this community understand th= at session caches are OPTIONAL, and a function of the network topology of t= he IP backbone. In tying SSL interworking quality to TCP behavior in partic= ular (probably US) IP nets, I worry! hypermedia apps and https understandin= g aside, I worry about whether folks really get the secure session state ar= chitecture within SSL! Its really not clear that folks get that SSL Record = layer contains its own fragmentation and reassembly possibilities, which ad= dressed the competing goals of compression contexts and security contexts, = for multiple, multiplexed secure sessions operating in two directions, simu= ltaneously. While someone thought quite carefully about the interaction of = SAML1.1 protocol's session establisment process and its interaction with th= e SSL architecture for secure sessions, its not clear TLS1.2 is properly ad= dressing the radical changes brought about by SAML2.0 - on multi-site sessi= on destruction, for example.
 
In summary, as an Internet Standard, its not clear that TLS is ready for su= ch standing. Its  evidently really not a widely understood secure sess= ion management architecture , and its architecture or writeup was not suffi= cient apparently for it to keep uptodate with the inevitable changes that a= lways go on around standard protocols.
 
But, when I rationalize, this is not all that surprising. The specific inte= nt of the writeup was to benefit implementors and RSA's cryptographic analy= sts; support standardization was not an explicit writing goal.


> From: janm@transactionware.com
> To: home_pw@msn.com
> CC:= tls@lists.ietf.org
> Subject: RE: [TLS] Serious crypto problem fixed= by envelope HMACmethodinstead of currently used prefix
> Date: Fri, = 24 Nov 2006 12:31:00 +1100
>
> I'm responding very generally .= ..
>
> Peter Williams wrote:
> > > What happens wi= th TCP packets depends on many variables. These are
> > > irrel= evant to TLS and are hidden by a TCP implementation.
> > >
= > > > TLS has a record layer to provide a record abstraction on > > top of TCP.
> > >
> >
> > Disti= nguish TCP packets from TCP connection state changes,
> > however= . These were all security-relevant signals, for SSL
> > designers= , as indicated by the socket.
> >
> > And, dont read too= much into the term "record", and don't
> > associate it with TCP= /IP's internal signalling or "framing"
> > behaviour for a given = network media. The record construct
> > refers to the framing of = the SSL2 handshake messages, and
> > then the framing due to hand= ling the resulting security
> > context(s), suited to Type II cip= her environments.
> >
> > SSL3 always intended that one = could multiplex different
> > handshakes and different security c= ontexts within the
> > reliable byte stream(s) (perhaps and only = perhaps implemented
> > using TCP/IP), befitting resolving an HTM= L page with multiple
> > image and voice tags to be rendered in p= arallel, along with
> > other HTML pages in the frameset being si= milarly rendered
> > from other website sources via http or other= URL protocols.
>
> Are you saying that SSL3 was intended to a= llow multiplexing over a single
> reliable byte stream? If so, do you= have a reference?
>
> > TLS1.1+ seems to be rapidly deviat= ing from the intended
> > multiplexing architecture, by always ex= tending the common
> > handshake (wot crypto wimps!). It should h= ave been specifying
> > and standardizing additional handshakes, = for use beyond
> > https, using a common pool of std ciphersuites= , when
> > resolving non HTML media such as different XML documen= t classes.
>
> Why?
>
> TLS provides a reliable = byte stream with specific security services applied.
> Providing "med= ia specific" services or multiplexing in a protocol like TLS
> is cle= arly a mistake. TCP/IP does a fine job of multiplexing. Why do it
> a= gain?
>
> An application implementing a higher layer protocol = can choose to allow
> specific TLS features and to deny others to mee= t a specific need, but that
> is where it should end. TLS has no know= ledge of https.
>
> > Perhaps its not too late to put TLS b= ack into its original
> > security model. One could be ensuring t= hat when the
> > WS-Security secureConversation protocol (for exa= mple) is
> > performing the actions of resolving a particular cla= ss of XML
> > media then suitably multiplexed handshake(s) are oc= curing
> > within the record layer - (a) supporting the http-bind= inhs
> > and (b) the secureconversation protocol itself, in paral= lel
> > as necessary. In such a handshake, entropy may of course = be
> > being obtained from a server, rather than from random sour= ce,
> > as in traditiona netscape https for example, where the se= rver
> > retains information records to address crypto regulation= s
> > (e.g. the proposed signed evidence work items). If one is <= BR>> > using the TLS1.1 SAML extension for identification, this
&= gt; > third handshake may be specifically using SAML's delegated
>= ; > entropy modes when applying XML-encryption-based
> > ciphe= rsuites. Who knows! But this is what the architecture
> > was int= ended to support!
> >
> > I for one make the assumption = that, upon resuming a (or being
> > induced by an ISP to resume a= n interupted) SSL2 or SSl3
> > session, one may be being required= to re-renegotiate
> > ciphersuites when picking up the new TCP c= hannel (that
> > requires SSL->TLS handling, and then use of g= ovt-escrowed
> > (i.e. compromised) PSK ciphersuite perhaps) - at= the right
> > moment to (i) perform the legal interception of th= e
> > particular multiplexed session identified, and (ii) enable =
> > the ISP to show that its intervetion at the SSL session
&= gt; > layer, probably via TCP interference, fits the particular
>= > class of interception order.
>
> I am guessing that you = are concerned about the crypto in a resumed TLS
> session being downg= raded, but I'm not sure. If this is what concerns you,
> then write (= or configure) your application to not use ciphersuites you don't
> wa= nt.
>
> > Ok. Ive hope made my point. Makikng SSL3 be behol= den to TCP
> > signals is fraught with security sideeffects, that= IETF's
> > senior security architects may be intending or not in= tending
> > when standardizing TLS.
>
> Sorry, I thi= nk I've missed your real point entirely.
>
> TLS's purpose is = to provide a reliable byte stream service with strong
> confidentiali= ty, integrity, and/or authentication. To do this, TLS uses a
> reliab= le byte stream service without strong security guarantees, such as
> = TCP.
>
>
> Regards,
>
> Jan Mikkelsen.
= >


Check the weather nationwide with MSN Search Try it now! = --_5faffbd2-b477-43d9-be0c-46be0b912afc_-- --===============1484841462== 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 --===============1484841462==-- From tls-bounces@lists.ietf.org Thu Nov 23 23:07:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnSL8-0000Qk-Js; Thu, 23 Nov 2006 23:07:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnSL7-0000Qf-Et for tls@ietf.org; Thu, 23 Nov 2006 23:07:01 -0500 Received: from zeppo.itss.auckland.ac.nz ([130.216.190.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnSL6-0000qd-1M for tls@ietf.org; Thu, 23 Nov 2006 23:07:01 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id CDF163427F; Fri, 24 Nov 2006 17:06:55 +1300 (NZDT) Received: from zeppo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15444-19; Fri, 24 Nov 2006 17:06:55 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id AC4B234215; Fri, 24 Nov 2006 17:06:55 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 20C8437742; Fri, 24 Nov 2006 17:06:55 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1GnSL6-0000KF-00; Fri, 24 Nov 2006 17:07:00 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: martin.rex@sap.com Subject: Re: [TLS] Record layer corner cases In-Reply-To: <200611240101.CAA23300@uw1048.wdf.sap.corp> Message-Id: Date: Fri, 24 Nov 2006 17:07:00 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.5 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 Rex writes: >A few years ago, www.verisign.com had been sending out an expired rootCA >certificate in the certification path of the Server, 31 December 1999 (a built-in Y2K failure, all their roots expired on that day). >and curiously, none of the Web Browsers complained when it had a replacement >cert (same Subject&Issuer, same key, longer validity) in the list of trust >anchors. They just checked the DN and key and left it at that, since only the date had changed the new cert was silently accepted. >Maybe there should be some guidance, common sense doesn't seem to be >sufficient (it took VeriSign several months to fix it when I complained to >them about their server misconfiguration/misbehaviour). For root certs, the practice is to have them never expire [0]. You'll never see this written down anywhere (you're supposed to roll over certs every few years), but I think in practice everyone in the industry knows that root cert replacement is so unworkable that you just give your certs an infinite lifetime. When it comes to security vs.availability, availability always wins out. Peter. [0] I've had users complain to me that my use of time_t prevents them from setting lifetimes of more than 35-odd years for their root certs, and would I consider moving to long long's instead. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 23 23:21:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnSYO-0001hc-Na; Thu, 23 Nov 2006 23:20:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnSYN-0001X5-0k for tls@lists.ietf.org; Thu, 23 Nov 2006 23:20:43 -0500 Received: from c-69-181-78-47.hsd1.ca.comcast.net ([69.181.78.47] helo=delta.rtfm.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnSYL-0001va-JO for tls@lists.ietf.org; Thu, 23 Nov 2006 23:20:43 -0500 Received: by delta.rtfm.com (Postfix, from userid 1001) id 9DAAC1CC61; Thu, 23 Nov 2006 20:20:05 -0800 (PST) To: Peter Williams Subject: Re: [TLS] Serious crypto problem fixed by envelope HMACmethodinstead of currently used prefix References: From: EKR Date: Thu, 23 Nov 2006 20:20:05 -0800 In-Reply-To: (Peter Williams's message of "Thu, 23 Nov 2006 19:46:09 -0800") Message-ID: <86wt5llbm2.fsf@delta.rtfm.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.2 (/) X-Scan-Signature: cd26b070c2577ac175cd3a6d878c6248 Cc: tls@lists.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 I really don't understand what point you're making, but a number of the specific claims you make below strike me as dubious. Peter Williams writes: > So, to start the review, lets magine, as we did, that we are a > microsoft-equivalent winsock programming team for SSL, not knowing > quite who will be using our sockets, or for what purpose. Assume > that those users on the initiating end are as diverse as > content-specific plugins to browsers, or HTML-based javascript apps > and java applets, on a competing "web" platform to windows. While > the winsock provider for SSL3 is installed by default, we dont know > as a design team which other providers will be pre- or post-hooked; > assume we provide custom socket configuration support to orchestrate > how, say, SSL3's two layers cooperate. Perhaps, by default, the > record layer only encapsulates the "SSL Handshake" protocol, > requiring socket configuration to do otherwise. Assume that this is > our architectural plan, and assumed primary usage model. > > We also have a target delivery date for IE3, Jan 1995. This is already a weird assertion, since Netscape designed SSL and they really didn't have any interest in anything working with IE. > 1. the "SSL Handshake Protocol" is "one such encapsulated protocol" > borne by the record protocol. Furthermore, various higher level > protocol are architecturally entitled to be encapsulated in the > record protocol. I trust this address my general point about > multiplexing. Change the term multiplexing to "multi-capsulating", > if one must be an american pedant when using English. I certainly agree that SSLv3 offered this feature, but it's not at all clear to me that anyone had any clear idea what to do with it, but rather that it was a placeholder. Recall that despite the fact that only 4 protocols were defined, the minimum enum size in SSL is 1 byte, so there were 252 unused values anyway. > 4. What is not stated (as https was deliberately never specified, > except by Eric's "authorized" rendition of web reality from his > (then implementor's) viewpoint) Do you have a source for "deliberately"? I never got any such sense from any of the Netscape personnel. Rather, it just seemed that it was so obvious what to do that nobody ever got around to documenting it. > 3. Conclusions on Internet Standard status In terms of whether > SSL3/TLS is prime time for Internet Standard status , its often > worth testing what folks read into the document, when they implement > long after the original design issues have long since left the > community consciousness. > > With TLS 1.0 endorsing null confidentiality ciphersuites, I assume > the primary goal statement ("provide privacy and reliabily...to > apps") in TLS got changed from that in SSL3. Goal:Privacy assumed a > robust confidentiality service, Huh? NULL cipher suites weren't something the IETF invented. They were in SSL version 3. http://wp.netscape.com/eng/ssl3/4-APPN.HTM#D-4 > its not clear to me, from recent reading, that this community > understand that session caches are OPTIONAL, and a function of the > network topology of the IP backbone. Huh? The need (or lack of need) for session caches has nothing whatsoever to do with the topology of IP networks and everything to do with the connection characteristics of the applications that are running over top of TLS, most importantly HTTP. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 23 23:59:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnT8E-00027j-Q2; Thu, 23 Nov 2006 23:57:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnT8D-00027e-2a for tls@ietf.org; Thu, 23 Nov 2006 23:57:45 -0500 Received: from bay0-omc2-s38.bay0.hotmail.com ([65.54.246.174]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnT8B-0005Pn-MH for tls@ietf.org; Thu, 23 Nov 2006 23:57:45 -0500 Received: from BAY103-W2 ([65.54.174.102]) by bay0-omc2-s38.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 20:57:43 -0800 X-Originating-IP: [71.140.81.171] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Peter Gutmann , Subject: RE: [TLS] Record layer corner cases Date: Thu, 23 Nov 2006 20:57:42 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 24 Nov 2006 04:57:43.0388 (UTC) FILETIME=[136631C0:01C70F85] X-Spam-Score: 2.4 (++) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b 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="===============0068027882==" Errors-To: tls-bounces@lists.ietf.org --===============0068027882== Content-Type: multipart/alternative; boundary="_9e5ea144-5b08-4eb0-a010-50178e41c7f8_" --_9e5ea144-5b08-4eb0-a010-50178e41c7f8_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > For root certs, the practice is to have them never expire [0]. You'll nev= er> see this written down anywhere (you're supposed to roll over certs ever= y few> years), but I think in practice everyone in the industry knows that = root cert> replacement is so unworkable that you just give your certs an in= finite> lifetime. When it comes to security vs.availability, availability a= lways wins> out.> > Peter. =20 The business/investement model dictated this. VeriSign existed to make mone= y for its venture investors; nothing would stand in that way, and certainly= not personal privacy interests (For example, implement mandatory key escro= w! or be put out of business by USG!! VeriSign management quickly kowtow'ed= , as did most but not all of the IETF luminaries, to be fair to the VeriSig= n team). So whilst capitalism broke through the barriers to engender adopti= on, capitalism also upheld certain other social issues concerning privacy l= imits via deception, etc. So, fair is fair... =20 But, we are still learning, about crypto and society. Peter was very wrong = recently! Even though TLS1.0 had null cipher suites for years, the credit-c= ard world did not *actually* crumble. At the same time, its true that only = in the recent IE7 has the global infrastructure for grandmas finally made T= LS1.1 the default (and with MSFT IETF-unverified techniques for testing whi= ch TLS extensions are actually supported on servers!). So, perhaps we will = yet see what further evidence of TLS design vs practice has to offer, now i= t enters mainstream testing. =20 Peter W. _________________________________________________________________ Search from any Web page with powerful protection. Get the FREE Windows Liv= e Toolbar Today! http://get.live.com/toolbar/overview= --_9e5ea144-5b08-4eb0-a010-50178e41c7f8_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable



> For root certs, the practice is to have them nev= er expire [0]. You'll never
> see this written down anywhere (you're = supposed to roll over certs every few
> years), but I think in practi= ce everyone in the industry knows that root cert
> replacement is so = unworkable that you just give your certs an infinite
> lifetime. When= it comes to security vs.availability, availability always wins
> out= .
>
> Peter.

 
The business/investement model dictated this. VeriSign existed to make mone= y for its venture investors; nothing would stand in that way, and certainly= not personal privacy interests (For example, implement mandatory key escro= w! or be put out of business by USG!! VeriSign management quickly kowtow'ed= , as did most but not all of the IETF luminaries, to be fair to the VeriSig= n team). So whilst capitalism broke through the barriers to engender adopti= on, capitalism also upheld certain other social issues concerning privacy l= imits via deception, etc. So, fair is fair...
 
But, we are still learning, about crypto and society. Peter was very wrong = recently! Even though TLS1.0 had null cipher suites for years, the credit-c= ard world did not *actually* crumble. At the same time, its true that only = in the recent IE7 has the global infrastructure for grandmas finally m= ade TLS1.1 the default (and with MSFT IETF-unverified techniques for testin= g which TLS extensions are actually supported on servers!). So, perhaps we = will yet see what further evidence of TLS design vs practice has to offer, = now it enters mainstream testing.
 
Peter W.

Search from any Web page with powerful protection. = Get the FREE Windows Live Toolbar Today! Try it now! = --_9e5ea144-5b08-4eb0-a010-50178e41c7f8_-- --===============0068027882== 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 --===============0068027882==-- From tls-bounces@lists.ietf.org Fri Nov 24 00:14:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnTNY-00015z-AO; Fri, 24 Nov 2006 00:13:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnTNX-00015p-6K for tls@lists.ietf.org; Fri, 24 Nov 2006 00:13:35 -0500 Received: from mail.transactionware.com ([203.14.245.7]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1GnTNV-0006qb-NZ for tls@lists.ietf.org; Fri, 24 Nov 2006 00:13:35 -0500 Received: (qmail 22089 invoked from network); 24 Nov 2006 05:13:52 -0000 Received: from new.transactionware.com (192.168.1.55) by dm.transactionware.com with SMTP; 24 Nov 2006 05:13:52 -0000 Received: (qmail 25725 invoked by uid 1026); 24 Nov 2006 05:13:52 -0000 Received: from 127.0.0.1 by new.transactionware.com (envelope-from , uid 1003) with qmail-scanner-1.25 (spamassassin: 3.0.2. Clear:RC:1(127.0.0.1):. Processed in 3.347676 secs); 24 Nov 2006 05:13:52 -0000 Received: from unknown (HELO JMLAPTOP) (unknown) by unknown with SMTP; 24 Nov 2006 05:13:48 -0000 From: "Jan Mikkelsen" To: "'Peter Williams'" Subject: RE: [TLS] Serious crypto problem fixed by envelope HMACmethodinstead of currently used prefix Date: Fri, 24 Nov 2006 16:13:29 +1100 Organization: Transactionware Message-ID: <004501c70f87$4784de00$c801a8c0@transactionware.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.6626 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Importance: Normal In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: a1dc446dc7ac353b90b60743d0e479e3 Cc: tls@lists.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 Peter, I'm not going to address all of your message, but I have picked some = below. >From my reading of your messages I think that you have two main points: 1. You want to add "multiplexing" to TLS for the transfer of more = complex data. =20 2. You have a problem with null cipher suites. On the first point, I don't see any requirement that isn't met by the current protocol. Please be specific (and concise) about the problem = you want to solve. On the second point, null ciphersuites were in the SSL3 document you = cite. There are three aspects to security in SSL: confidentiality, integrity = and authentication. Not all are required in all situations. I said this a = few messages ago, and it is also stated in the introduction to the SSL3 document. Anyway, I've addressed some things from your message, but I suggest that = you try a one or two paragraph statement of the problem you want to solve. Peter Williams writes: > [ ... Context, Microsoft, the 90s ... ] I see protocols and implementations as distinct things. Issues in implementing software in complex multivendors environments does not mean that the protocol is broken. > 2. Evidence and Analysis > =20 > If we consider the authoritative SSL3 citation, we can refer=20 > to its opening statements on architecture (that may not align=20 > with the "received architecture" in TLS, for all I know):- > =20 > "The primary goal of the SSL Protocol is to provide privacy and > reliability between two communicating applications. The protocol > is composed of two layers. At the lowest level, layered on top of > some reliable transport protocol (e.g., TCP[TCP]), is the SSL > Record Protocol. The SSL Record Protocol is used for encapsulation > of various higher level protocols. One such encapsulated protocol, > the SSL Handshake Protocol, allows the server and client to > authenticate each other and to negotiate an encryption algorithm > and cryptographic keys before the application protocol transmits or > receives its first byte of data." > =20 > =20 > Then we parse the design goals stated in this architecture: > =20 > 1. the "SSL Handshake Protocol" is "one such encapsulated=20 > protocol" borne by the record protocol. Furthermore, various=20 > higher level protocol are architecturally entitled to be=20 > encapsulated in the record protocol. I trust this address my=20 > general point about multiplexing. Change the term=20 > multiplexing to "multi-capsulating", if one must be an=20 > american pedant when using English. I don't see multiplexing "architecturally entitled" from this. I see an application data protocol, with the messages "treated as transparent = data to the record layer" (5.7). > 2. the lowest record protocol layer is "layered on top of=20 > some reliable transport protocol (e.g., TCP[TCP])". TCP is =20 > clearly cited as an example, only. TCP was not assumed in the=20 > security model design goals, though of course reality often=20 > intruded on the team! A record layer layered on the protocol=20 > known as the "SSL3 Protocol" was certainly intended (i.e. SSL=20 > tunneling). Do not assume HTTP 1.1 keep-alive existed, and=20 > the internet is being flooded by shortlife TCP instances that=20 > are upsetting US ISPs and the US FIX-architecture backbone=20 > concept for an IP internetwork design. > =20 > 3. the primary goal of SSL Protocol was to provide privacy=20 > and reliability, app to app. As my parsing in (2) above=20 > indicates, the reliability properties of one protocol stack=20 > (record layer over TCP) might be different to another (record=20 > layer over the SSL Protocol, over TP4). As history may=20 > recall, at the time getting reliable transport sessions=20 > between class d addressed applications was a challenge, as=20 > the internet had no bandwidth reservation techniques, at the time. Gee, OSI flashbacks! I don't see any different between SSL over TP4 and SSL over TCP. I = don't see how bandwidth reservation is relevant. > 4. What is not stated (as https was deliberately never=20 > specified, except by Eric's "authorized" rendition of web=20 > reality from his (then implementor's) viewpoint) was how this=20 > protocol architecture addressed hypermedia applications. It=20 > true that it is not stated that "reliable transport" should=20 > be assume to include multicast transport, supporting=20 > (multicast hypermedia) applications. Take it from me,=20 > however, that this was intended, when addressing protocol=20 > goals such as were being considered (at the time) for=20 > HTML-enhanced nntp , and pre-ldap multicast white pages=20 > directories and their supporting directory=20 > replication/authentication protocols (for efficient PKI cert=20 > distribution!). I'm having trouble getting the point here. Why are addressing = structures at that level relevant here? =20 > In terms of its read./write secure session state management=20 > design, lets note, the critical text: > " An SSL session may include multiple secure connections; in > addition, parties may have multiple simultaneous sessions." Sure. I read that as meaning that an SSL session may involve multiple underlying connections (eg. TCP, TP4, whatever) and those underlying connections may be used simulataneously or successively. In otherwords = the lifetime of the SSL session does not follow the lifetime of the = underlying transport session. I do not see this as a statement of architectural intention to add "multiplexing." > =20 > 3. Conclusions on Internet Standard status >=20 > In terms of whether SSL3/TLS is prime time for Internet=20 > Standard status , its often worth testing what folks read=20 > into the document, when they implement long after the=20 > original design issues have long since left the community=20 > consciousness. > =20 > With TLS 1.0 endorsing null confidentiality ciphersuites, I=20 > assume the primary goal statement ("provide privacy and=20 > reliabily...to apps") in TLS got changed from that in SSL3.=20 > Goal:Privacy assumed a robust confidentiality service, and=20 > goal:reliablity assumed OPTIONAL robust session=20 > management/resumption techniques that were intended to be=20 > sensitive to the IP network over which the https/SSL=20 > connections were flowing while understanding the=20 > socio-political risks that come with sever-side session=20 > caches and hidden session restarts using lower strength ciphersuites. > =20 > its not clear to me, from recent reading, that this community=20 > understand that session caches are OPTIONAL, and a function=20 > of the network topology of the IP backbone. In tying SSL=20 > interworking quality to TCP behavior in particular (probably=20 > US) IP nets, I worry! hypermedia apps and https understanding=20 > aside, I worry about whether folks really get the secure=20 > session state architecture within SSL! Its really not clear=20 > that folks get that SSL Record layer contains its own=20 > fragmentation and reassembly possibilities, which addressed=20 > the competing goals of compression contexts and security=20 > contexts, for multiple, multiplexed secure sessions operating=20 > in two directions, simultaneously. While someone thought=20 > quite carefully about the interaction of SAML1.1 protocol's=20 > session establisment process and its interaction with the SSL=20 > architecture for secure sessions, its not clear TLS1.2 is=20 > properly addressing the radical changes brought about by=20 > SAML2.0 - on multi-site session destruction, for example.=20 How is this relevant? =20 > In summary, as an Internet Standard, its not clear that TLS=20 > is ready for such standing. Its evidently really not a=20 > widely understood secure session management architecture ,=20 > and its architecture or writeup was not sufficient apparently=20 > for it to keep uptodate with the inevitable changes that=20 > always go on around standard protocols. I don't see this as evident at all. Can you be more precise? =20 > But, when I rationalize, this is not all that surprising. The=20 > specific intent of the writeup was to benefit implementors=20 > and RSA's cryptographic analysts; support standardization was=20 > not an explicit writing goal. Benefiting implementors is generally a good thing, in my experience, standards for the sake of standards generate lots of paper, but aren't terribly useful to implementers. And standards without implementers generally aren't very useful over time. Witness the current popularity = of TP4. Regards, Jan. =20 >=20 > _____ =20 >=20 >=20 > > From: janm@transactionware.com > > To: home_pw@msn.com > > CC: tls@lists.ietf.org > > Subject: RE: [TLS] Serious crypto problem fixed by envelope=20 > HMACmethodinstead of currently used prefix > > Date: Fri, 24 Nov 2006 12:31:00 +1100 > >=20 > > I'm responding very generally ... > >=20 > > Peter Williams wrote: > > > > What happens with TCP packets depends on many=20 > variables. These are > > > > irrelevant to TLS and are hidden by a TCP implementation. > > > >=20 > > > > TLS has a record layer to provide a record abstraction on=20 > > > top of TCP. > > > >=20 > > >=20 > > > Distinguish TCP packets from TCP connection state changes,=20 > > > however. These were all security-relevant signals, for SSL=20 > > > designers, as indicated by the socket. > > >=20 > > > And, dont read too much into the term "record", and don't=20 > > > associate it with TCP/IP's internal signalling or "framing"=20 > > > behaviour for a given network media. The record construct=20 > > > refers to the framing of the SSL2 handshake messages, and=20 > > > then the framing due to handling the resulting security=20 > > > context(s), suited to Type II cipher environments. > > >=20 > > > SSL3 always intended that one could multiplex different=20 > > > handshakes and different security contexts within the=20 > > > reliable byte stream(s) (perhaps and only perhaps implemented=20 > > > using TCP/IP), befitting resolving an HTML page with multiple=20 > > > image and voice tags to be rendered in parallel, along with=20 > > > other HTML pages in the frameset being similarly rendered=20 > > > from other website sources via http or other URL protocols. > >=20 > > Are you saying that SSL3 was intended to allow multiplexing=20 > over a single > > reliable byte stream? If so, do you have a reference? > >=20 > > > TLS1.1+ seems to be rapidly deviating from the intended=20 > > > multiplexing architecture, by always extending the common=20 > > > handshake (wot crypto wimps!). It should have been specifying=20 > > > and standardizing additional handshakes, for use beyond=20 > > > https, using a common pool of std ciphersuites, when=20 > > > resolving non HTML media such as different XML document classes.=20 > >=20 > > Why? > >=20 > > TLS provides a reliable byte stream with specific security=20 > services applied. > > Providing "media specific" services or multiplexing in a=20 > protocol like TLS > > is clearly a mistake. TCP/IP does a fine job of=20 > multiplexing. Why do it > > again? > >=20 > > An application implementing a higher layer protocol can=20 > choose to allow > > specific TLS features and to deny others to meet a specific=20 > need, but that > > is where it should end. TLS has no knowledge of https. > >=20 > > > Perhaps its not too late to put TLS back into its original=20 > > > security model. One could be ensuring that when the=20 > > > WS-Security secureConversation protocol (for example) is=20 > > > performing the actions of resolving a particular class of XML=20 > > > media then suitably multiplexed handshake(s) are occuring=20 > > > within the record layer - (a) supporting the http-bindinhs=20 > > > and (b) the secureconversation protocol itself, in parallel=20 > > > as necessary. In such a handshake, entropy may of course be=20 > > > being obtained from a server, rather than from random source,=20 > > > as in traditiona netscape https for example, where the server=20 > > > retains information records to address crypto regulations=20 > > > (e.g. the proposed signed evidence work items). If one is=20 > > > using the TLS1.1 SAML extension for identification, this=20 > > > third handshake may be specifically using SAML's delegated=20 > > > entropy modes when applying XML-encryption-based=20 > > > ciphersuites. Who knows! But this is what the architecture=20 > > > was intended to support! > > >=20 > > > I for one make the assumption that, upon resuming a (or being=20 > > > induced by an ISP to resume an interupted) SSL2 or SSl3=20 > > > session, one may be being required to re-renegotiate=20 > > > ciphersuites when picking up the new TCP channel (that=20 > > > requires SSL->TLS handling, and then use of govt-escrowed=20 > > > (i.e. compromised) PSK ciphersuite perhaps) - at the right=20 > > > moment to (i) perform the legal interception of the=20 > > > particular multiplexed session identified, and (ii) enable=20 > > > the ISP to show that its intervetion at the SSL session=20 > > > layer, probably via TCP interference, fits the particular=20 > > > class of interception order. > >=20 > > I am guessing that you are concerned about the crypto in a=20 > resumed TLS > > session being downgraded, but I'm not sure. If this is what=20 > concerns you, > > then write (or configure) your application to not use=20 > ciphersuites you don't > > want. > >=20 > > > Ok. Ive hope made my point. Makikng SSL3 be beholden to TCP=20 > > > signals is fraught with security sideeffects, that IETF's=20 > > > senior security architects may be intending or not intending=20 > > > when standardizing TLS. > >=20 > > Sorry, I think I've missed your real point entirely. > >=20 > > TLS's purpose is to provide a reliable byte stream service=20 > with strong > > confidentiality, integrity, and/or authentication. To do=20 > this, TLS uses a > > reliable byte stream service without strong security=20 > guarantees, such as > > TCP. > >=20 > >=20 > > Regards, > >=20 > > Jan Mikkelsen. > >=20 >=20 >=20 >=20 > _____ =20 >=20 > Check the weather nationwide with MSN Search Try it now!=20 > =20 >=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Nov 24 00:43:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnTpY-0006du-NL; Fri, 24 Nov 2006 00:42:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnTpX-0006dm-06 for tls@lists.ietf.org; Fri, 24 Nov 2006 00:42:31 -0500 Received: from proof.pobox.com ([207.106.133.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnTpV-0001X1-ND for tls@lists.ietf.org; Fri, 24 Nov 2006 00:42:30 -0500 Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id 3F21829A8C for ; Fri, 24 Nov 2006 00:42:51 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 00A1296024 for ; Fri, 24 Nov 2006 00:42:50 -0500 (EST) Message-ID: <4566862C.5060107@pobox.com> Date: Thu, 23 Nov 2006 21:42:04 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] Serious crypto problem fixed by envelope HMACmethodinstead of currently used prefix References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 Peter Williams wrote: > At the same time, to become a Internet Standard, the document > has to show its being clearly understood by the average technical reader. I am new to TLS; I first decided to try to implement it two months ago. Looking at my CVS logs, my first line of code was written on September 18, 2006. I've found all the specs to be straightforward, and my code interoperates with SSLv3, TLS 1.0, and TLS 1.1. I've implemented the spec in the TLS 1.2 draft, but so far nobody has connected to my test server (www.mikestoolbox.net:4433) with that version. It's possible that it doesn't work, but nobody has told me. Note that I had already implemented X.509 certificates and (ironically) use the OpenSSL libcrypto for all encryption and public-key operations. Also of note is that the C++ classes I wrote to handle SSL/TLS never make any socket calls; they merely do a lot of string processing. > its not clear to me, from recent reading, that this community understand > that session caches are OPTIONAL, and a function of the network topology > of the IP backbone. In tying SSL interworking quality to TCP behavior in > particular (probably US) IP nets, I worry! hypermedia apps and https > understanding aside, I worry about whether folks really get the secure > session state architecture within SSL! Its really not clear that folks > get that SSL Record layer contains its own fragmentation and reassembly > possibilities, which addressed the competing goals of compression > contexts and security contexts, for multiple, multiplexed secure > sessions operating in two directions, simultaneously. While someone > thought quite carefully about the interaction of SAML1.1 protocol's > session establisment process and its interaction with the SSL > architecture for secure sessions, its not clear TLS1.2 is properly > addressing the radical changes brought about by SAML2.0 - on multi-site > session destruction, for example. I don't know what SAML is, so I can't comment on that, but will note that it took me just a couple hours to add session caching to my TLS server code. All you need is a map with the session id as the key. > But, when I rationalize, this is not all that surprising. The specific > intent of the writeup was to benefit implementors and RSA's > cryptographic analysts; support standardization was not an explicit > writing goal. I'll admit that it took me a few tries to get through the first spec (TLS 1.0), because of the description of the presentation language. It's actually quite simple, once you get used to it, but I had to put it down a few times due to information overload before getting to the meat of the spec. Once I saw it being used in real examples, it became natural. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Nov 24 00:51:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnTx4-0007tO-Qf; Fri, 24 Nov 2006 00:50:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnTx3-0007sN-Bv for tls@ietf.org; Fri, 24 Nov 2006 00:50:17 -0500 Received: from bay0-omc3-s17.bay0.hotmail.com ([65.54.246.217]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnTx1-0002fI-O1 for tls@ietf.org; Fri, 24 Nov 2006 00:50:17 -0500 Received: from BAY103-W6 ([65.54.174.106]) by bay0-omc3-s17.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 23 Nov 2006 21:50:15 -0800 X-Originating-IP: [71.140.81.171] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Subject: RE: [TLS] Record layer corner cases Date: Thu, 23 Nov 2006 21:50:14 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 24 Nov 2006 05:50:15.0165 (UTC) FILETIME=[6A0132D0:01C70F8C] X-Spam-Score: 2.4 (++) X-Scan-Signature: 42e3ed3f10a1d8bef690f09da16f507a 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="===============0040484524==" Errors-To: tls-bounces@lists.ietf.org --===============0040484524== Content-Type: multipart/alternative; boundary="_3de49f56-905f-460c-8321-9618778cf3c5_" --_3de49f56-905f-460c-8321-9618778cf3c5_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable in https, the implementor is responsible for choosing how to form certifica= te paths. There is nothing standardized, or alluded to as good or best prac= tice, by specific intention. Earlier attempts by IETF to standardize certif= ication structures and standardize certification path formation had failed,= miserably. There had been three attempts, and the crypto-politics just wou= ld not converge: Vint Cerf's personal authority and political skills, notwi= thstanding. Letting go, infact...was the key to engendering adoption! =20 Netscape's browser team did have access to, but never applied, the results = of a DARPA project that locally constructed trust paths according to variou= s metrics concerning the "bestness" of paths through a semi-organized certi= fication mesh, built from certs obtained from any source, and qualified for= storage in a local MIB (close to MSFT trust stores, today). The https indu= stry enforcement practice followed what Netscape did, minimally, with whate= ver time was left in the schedule for parsing and handling certs, after doi= ng SSL: let the local trust store dominate the trust information signaled b= y the authentication peer. To be fair, this was viewed as good practice, at= the time; the only reason for a peer to signal certification paths was to = help distribute the cache of certs, per Lampson's theory on distributed aut= hentication for WANs. =20 Netscape set the tone for the web management of certs, never really having = "got PKI". The part they did get about it, quickly scared them (a giant con= trol technology). once export rules concerning their higher-strength SSL cr= ypto ciphersuites for international banks were forcing them to test certain= cert fields and particular signing keys, they rapidly started to be wary o= f certificate-based controls. for wire-=3Dprotocol, or authorizing client o= r server software to even do crypto. This lassez-faire mood spread, across = the web industry (and probably saved the internet from mandatory key escrow= .) it also engendered grassroots adoption! =20 So, this is what drives the apparent quandary, you saw. Its actually the in= tent, though it is counter-intuitive, to say the least! > From: martin.rex@sap.com> Subject: Re: [TLS] Record layer corner cases> T= o: mike-list@pobox.com> Date: Fri, 24 Nov 2006 02:01:09 +0100> CC: tls@ietf= .org> > Mike wrote:> > > > I clearly misunderstood what you meant, and actu= ally agree that it> > would be good to have one handshake message per recor= d. Practically,> > though, you will need to support earlier versions for so= me time.> > Just try to connect to the industry-leading certificate authori= ty> > with TLS 1.0: https://www.verisign.com/ for example.> > Talking of Ve= riSign...> > A few years ago, www.verisign.com had been sending out an expi= red> rootCA certificate in the certification path of the Server, and> curio= usly, none of the Web Browsers complained when it had a> replacement cert (= same Subject&Issuer, same key, longer validity)> in the list of trust ancho= rs. If the newer local key was> deleted in the browsers list of trust ancho= rs, then the expired> rootCA cert sent by www.verisign.com became visible.>= > Maybe there should be some guidance, common sense doesn't seem> to be su= fficient (it took VeriSign several months to fix it when> I complained to t= hem about their server misconfiguration/misbehaviour).> > -Martin> > ______= _________________________________________> TLS mailing list> TLS@lists.ietf= .org> https://www1.ietf.org/mailman/listinfo/tls _________________________________________________________________ Express yourself with gadgets on Windows Live Spaces http://discoverspaces.live.com?source=3Dhmtag1&loc=3Dus= --_3de49f56-905f-460c-8321-9618778cf3c5_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

in https, the implementor is responsible for choosing how to = form certificate paths. There is nothing standardized, or alluded to as goo= d or best practice, by specific intention. Earlier attempts by IETF to stan= dardize certification structures and standardize certification path fo= rmation had failed, miserably. There had been three attempts, and the crypt= o-politics just would not converge: Vint Cerf's personal authority and poli= tical skills, notwithstanding. Letting go, infact...was the key to engender= ing adoption!
 
Netscape's browser team did have access to, but never applied, the res= ults of a DARPA project that locally constructed trust paths according to v= arious metrics concerning the "bestness" of paths through a semi-organized = certification mesh, built from certs obtained from any source, and qualifie= d for storage in a local MIB (close to MSFT trust stores, today). The = https industry enforcement practice followed what Netscape did, minimally, = with whatever time was left in the schedule for parsing and handling certs,= after doing SSL: let the local trust store dominate the trust information = signaled by the authentication peer. To be fair, this was viewed as good pr= actice, at the time; the only reason for a peer to signal certification pat= hs was to help distribute the cache of certs, per Lampson's theory on distr= ibuted authentication for WANs.
 
Netscape set the tone for the web management of certs, never really having = "got PKI". The part they did get about it, quickly scared them (a giant con= trol technology). once export rules concerning their higher-strength SSL cr= ypto ciphersuites for international banks were forcing them to test certain= cert fields and particular signing keys, they rapidly started to be wary o= f certificate-based controls. for wire-=3Dprotocol, or authorizing client o= r server software to even do crypto. This lassez-faire mood spread, ac= ross the web industry (and probably saved the internet from mandatory key e= scrow.) it also engendered grassroots adoption!
 
So, this is what drives the apparent quandary, you saw. Its actually the in= tent, though it is counter-intuitive, to say the least!




> From: martin.rex@sap.com
> Subject: Re: [TLS] Record layer corne= r cases
> To: mike-list@pobox.com
> Date: Fri, 24 Nov 2006 02:0= 1:09 +0100
> CC: tls@ietf.org
>
> Mike wrote:
> &g= t;
> > I clearly misunderstood what you meant, and actually agree= that it
> > would be good to have one handshake message per recor= d. Practically,
> > though, you will need to support earlier versi= ons for some time.
> > Just try to connect to the industry-leading= certificate authority
> > with TLS 1.0: https://www.verisign.com/= for example.
>
> Talking of VeriSign...
>
> A fe= w years ago, www.verisign.com had been sending out an expired
> rootC= A certificate in the certification path of the Server, and
> curiousl= y, none of the Web Browsers complained when it had a
> replacement ce= rt (same Subject&Issuer, same key, longer validity)
> in the list= of trust anchors. If the newer local key was
> deleted in the browse= rs list of trust anchors, then the expired
> rootCA cert sent by www.= verisign.com became visible.
>
> Maybe there should be some gu= idance, common sense doesn't seem
> to be sufficient (it took VeriSig= n several months to fix it when
> I complained to them about their se= rver misconfiguration/misbehaviour).
>
> -Martin
>
&= gt; _______________________________________________
> TLS mailing lis= t
> TLS@lists.ietf.org
> https://www1.ietf.org/mailman/listinfo= /tls


Express yourself with gadgets on Windows Live Space= s Try it! = --_3de49f56-905f-460c-8321-9618778cf3c5_-- --===============0040484524== 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 --===============0040484524==-- From tls-bounces@lists.ietf.org Fri Nov 24 01:22:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnUQK-0007uU-8k; Fri, 24 Nov 2006 01:20:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GnUQI-0007uL-NW for tls@ietf.org; Fri, 24 Nov 2006 01:20:30 -0500 Received: from mailhost-old.auckland.ac.nz ([130.216.190.13] helo=harpo.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GnUQH-0006LO-32 for tls@ietf.org; Fri, 24 Nov 2006 01:20:30 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id 7C07D35838; Fri, 24 Nov 2006 19:20:24 +1300 (NZDT) Received: from harpo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09938-06; Fri, 24 Nov 2006 19:20:24 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id F1FEC34EBF; Fri, 24 Nov 2006 19:20:23 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 63EF437742; Fri, 24 Nov 2006 19:20:23 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1GnUQH-0002bi-00; Fri, 24 Nov 2006 19:20:29 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: home_pw@msn.com, martin.rex@sap.com Subject: RE: [TLS] Record layer corner cases In-Reply-To: Message-Id: Date: Fri, 24 Nov 2006 19:20:29 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.5 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 Peter Williams writes: >Netscape's browser team did have access to, but never applied, the results of >a DARPA project that locally constructed trust paths according to various >metrics concerning the "bestness" of paths through a semi-organized >certification mesh, built from certs obtained from any source, and qualified >for storage in a local MIB (close to MSFT trust stores, today). That's because using the strict hierarchical X.509 with a spaghetti PKI requires solving NP-complete graph theory problems, which (AFAIK) only the USG is currently attempting to do (I went to a scary talk some years ago where someone was talking about their spaghetti PKI experience and mentioned that their path construction algorithm ran for three days without terminating, whereupon they had to kill the process. Instead of taking this as some sort of hint, they simply continued with another approach. It was almost surreal, like watching a bunch of people talking about their different approaches to building perpetual-motion machines). >The https industry enforcement practice followed what Netscape did, >minimally, with whatever time was left in the schedule for parsing and >handling certs, after doing SSL: let the local trust store dominate the trust >information signaled by the authentication peer. Given that the (obvious with 20/20 hindsight) failures in the browser security model that we're now seeing have very little to do with certs, this approach wasn't so bad in the long run. (This may now be officially off-topic for ietf-tls :-). security-usability is probably a better list for this). Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Nov 24 11:51:45 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GneFR-000256-JK; Fri, 24 Nov 2006 11:49:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GneFQ-00023h-9Y for tls@ietf.org; Fri, 24 Nov 2006 11:49:56 -0500 Received: from moutng.kundenserver.de ([212.227.126.188]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GneFO-0006xd-Or for tls@ietf.org; Fri, 24 Nov 2006 11:49:56 -0500 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu3) with ESMTP (Nemesis), id 0MKxQS-1GneFL3qDw-0004Zx; Fri, 24 Nov 2006 17:49:52 +0100 Received: by tau.invalid (Postfix, from userid 1000) id 533C24D9F; Fri, 24 Nov 2006 17:49:51 +0100 (CET) Date: Fri, 24 Nov 2006 17:49:51 +0100 From: Bodo Moeller To: Pasi.Eronen@nokia.com Subject: Re: [TLS] Record layer corner cases Message-ID: <20061124164950.GA28453@tau.invalid> References: <20061121173346.GA15201@tau.invalid> 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: 5ebbf074524e58e662bc8209a6235027 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, Nov 22, 2006 at 02:53:33PM +0200, Pasi.Eronen@nokia.com wrote: > Bodo Moeller wrote: >> It seems to me that to avoid these problematic cases, "SHOULD NOT >> send but MUST accept" is better than "MUST NOT send". > This is very problematic for interoperability. If practically all > implementations follow the "SHOULD NOT send" (which they seem to do > today), the part about "MUST accept" never gets tested. This means > that even future implementations (at least those which care about > good interoperability) cannot violate the SHOULD NOT. > > And this is IMHO roughly where we are today... the spec has a feature > which nobody uses, and nobody can use. IMHO it would be better to > remove it, rather than leave it there "just in case". Well, for certificate chains that are "long" (compared to the maximum fragment length, or to some device's more limited maximum length for sending fragments), fragmentation is a feature that will be used. The minimum maximum fragment length (sic) is 2^9, so I suppose it would be reasonable to state that fragments of "handshake", "alert", and "change_cipher_spec" content type can't be empty and can't be smaller than 512 bytes unless they end where a message of the respective protocol ends. This does not rule out fragmentation within a message, but avoids pathological cases. >> Can you describe the specific fragmentation strategies that you used >> for testing? > I fragmented every handshake message (sent by the client) to two > fragments (split in the middle). I was asking because your observations do not agree with my earlier testing, which I repeated now: As far as I can determine, provided that the ClientHello and ServerHello messages are not pathologically fragmented, OpenSSL should not have problems with weird fragmentation. For my tests, except for Hello message fragmentation, I've used length-1 fragments and included the occasional length-0 fragment. So I'm not sure why you experienced problems with split-in-the-middle fragmentation unless you used some ancient software version. It seems possible that the implementation that you used for testing could be buggy, and that TLS servers don't really handle fragmentation as poorly as your observations indicate. >> I'd expect fragmentation to probably go wrong if it affects the very >> beginning of the TLS connection, when the server still has to decide >> which protocol version to use. (Support for the SSL 2.0 client >> hello format possibly makes this more complicated than it otherwise >> would have to be.) > Well, SSL 2.0 client hello can be distinguished from SSLv3/TLS hello > by looking at the first byte... Sure. However, things are more complicated if you have a mechanism intended to decide the protocol version among SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1, etc. Without SSL 2.0 and without the SSL 2.0 client hello format, it would be easier because you could do the record handling outside the version-specific stuff. If you need to accomodate SSL 2.0 as well, then the record handling becomes version specific, and thus it may require additional effort if you need to join fragments before the protocol version has actually been chosen. >> For the first of the proposed restrictions (i.e., don't fragment >> unless the message exceeds the maximum fragment length), I think >> that even SHOULD NOT is too much: >> >> - First, consider implementations that collect multiple handshake >> messages before sending these in TLS records. The *total* length of >> these messages may exceed the maximum fragment length even if each >> *single* message is below the limit, and in this case we naturally >> would have a record boundary that is not aligned with the message >> boundary. > The restriction would apply only to TLS 1.2, and there aren't any > TLS 1.2 implementations yet... so we could even require that a single > fragment can't contain multiple handshake messages. It's still extra implementation work for implementations that don't happen to follow the potential new requirement. (At least they won't have to distinguish between protocol versions for this because the proposed behavior certainly is valid for SSL 3.0, and TLS 1.0 and TLS 1.1 as well.) Now that I come to think of it, if we want to change the words of the specification for TLS 1.2, we might just as well simply take the current description of fragmentation and add "And we mean it" ... :-) Seriously, if we rule out some odd cases of fragmentation, I don't think it is unreasonable to require all implementations to be able to properly process fragmented handshake messages. >> - Second, consider implementations designed to run with very little >> memory. These might be allowing large fragments when receiving >> data (since they can't rely on the max_fragment_length extension >> being universally available) but still be using smaller fragments >> when sending data. > Hmm... this is a valid argument, at least when the fragments are being > encrypted/MAC'd. What if the restriction (about not fragmenting unless > needed) only applied when current ciphersuite is NULL_WITH_NULL? My initial thought on this is that different rules for NULL_WITH_NULL and for other ciphersuites are an unnecessary complication. Also it probably would mean that the recipient-side handling of fragmentation wouldn't get tested as much as it otherwise could. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Nov 24 14:50:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gnh26-00052O-9G; Fri, 24 Nov 2006 14:48:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gnh25-00052E-A0 for tls@ietf.org; Fri, 24 Nov 2006 14:48:21 -0500 Received: from smtpout06-01.prod.mesa1.secureserver.net ([64.202.165.224] helo=smtpout06-04.prod.mesa1.secureserver.net) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gnh23-0005We-Te for tls@ietf.org; Fri, 24 Nov 2006 14:48:21 -0500 Received: (qmail 28078 invoked from network); 24 Nov 2006 19:48:12 -0000 Received: from unknown (69.174.163.252) by smtpout06-04.prod.mesa1.secureserver.net (64.202.165.227) with ESMTP; 24 Nov 2006 19:48:12 -0000 From: "Ron Teitelbaum" To: Date: Fri, 24 Nov 2006 14:48:11 -0500 Organization: US Medical Records Specialists Message-ID: MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 Thread-Index: AccQAXkzoyeINBk8QUajkiOYSTQkbg== X-Spam-Score: 0.2 (/) X-Scan-Signature: 9a2be21919e71dc6faef12b370c4ecf5 Cc: Subject: [TLS] License or Patent Issues with ECC 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: , Content-Type: multipart/mixed; boundary="===============0192621973==" Errors-To: tls-bounces@lists.ietf.org This is a multi-part message in MIME format. --===============0192621973== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0167_01C70FD7.90FF3C60" This is a multi-part message in MIME format. ------=_NextPart_000_0167_01C70FD7.90FF3C60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit All, Does anyone know if there is are versions of ECC that can be implemented in an open source project? Thanks, Ron Teitelbaum ------=_NextPart_000_0167_01C70FD7.90FF3C60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

Does anyone know if there is are versions of ECC that = can be implemented in an open source project?

 

Thanks,

 

Ron Teitelbaum

------=_NextPart_000_0167_01C70FD7.90FF3C60-- --===============0192621973== 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 --===============0192621973==-- From tls-bounces@lists.ietf.org Sat Nov 25 22:46:09 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoAvx-0000iE-Gy; Sat, 25 Nov 2006 22:44:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoAvv-0000do-HV for tls@ietf.org; Sat, 25 Nov 2006 22:43:59 -0500 Received: from bay0-omc3-s32.bay0.hotmail.com ([65.54.246.232]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoAvt-0002z4-Uy for tls@ietf.org; Sat, 25 Nov 2006 22:43:59 -0500 Received: from BAY103-W4 ([65.54.174.104]) by bay0-omc3-s32.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 25 Nov 2006 19:43:57 -0800 X-Originating-IP: [71.140.81.171] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: , , Subject: RE: [TLS] Record layer corner cases Date: Sat, 25 Nov 2006 19:43:57 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 26 Nov 2006 03:43:57.0400 (UTC) FILETIME=[1A218580:01C7110D] X-Spam-Score: 2.4 (++) X-Scan-Signature: 2ed806e2f53ff1a061ad4f97e00345ac 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="===============0769853735==" Errors-To: tls-bounces@lists.ietf.org --===============0769853735== Content-Type: multipart/alternative; boundary="_1bb8edd9-2514-4a24-bcb7-b23cc4dcc392_" --_1bb8edd9-2514-4a24-bcb7-b23cc4dcc392_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Using TCP "urgent mode", say, for security signaling/controls is a marked d= eviation from the constructs and design precepts of the SSL Handshake, but = not the SSL Protocol, note. I'm being very pedantic with terminology, for a= reason: as we discussed earlier, the SSL Protocol is an encapsulation of {= SSL Handshake, or other ALPHA handshake(s)) by the Record Protocol.=20 =20 Allowing the (standard) SSL Handshake to use TCP urgent mode would detract = from allowing the SSL3 to be recognized as a fully fledged Internet Standar= d, known as TLS, a standing it clearly deserves - given its demonstrated ra= nge of applicability, its hardware and software implementation knowhow, and= the way SSL session handling succesfully cooeprates with stateful inspecti= on firewalls. In the same vein, recognizing that said potential Internet S= tandard has proper "future proofing" features (allowing ALPHA handshake des= igns down the line to evolve the standard) supports SSL3's designation as a= fully mature, Internet Standard, known as TLS. That SSL3 is not tied to to= day's dominant transport (TCP over IPv4 over the US IP backbone architectur= e) is also good for that standing! =20 Without interfering with the recognition SSL3 in its TLS1.1 form should hav= e as an Internet Standard , we could reasonably keep this WG open if there = were a new, distinct standards track initiative to specify one or more "ALP= HA Handshakes" - that (a) parallel the SSL Handshake, and (b) have some kno= wledge of and interaction with post-hooked socket providers (TCP, X, or som= e of the class d addressed reliable channels we experimented with, long ago= , using multicast key management, core-based access and connection controls= , and session directory support). A long long time ago, we found it necessa= ry to indeed allow the handshake to *interactively* control how the reliabl= e transport channel behaved, for those transports which merge byte transfer= with the very key management concept and access/connection controls being = used in the handshake's design. =20 If this is too abstract for folks, there were at one point I-Ds from NSA de= signers/engineers on using multicast key management for IKE-enhancements ad= dressing multi-drop security association management, that one can peruse fo= r background. Some of these ideas are appropriate for multi-drop session ma= nagement, particularly when ALPHA-design handshakes would be cooperating wi= th the SAML2 protocols at the https.v2 layer, in the setup/teardown of mul= ti-drop client authentication sessions. > Subject: RE: [TLS] Record layer corner cases> Date: Thu, 23 Nov 2006 11:3= 7:38 +0200> From: Pasi.Eronen@nokia.com> To: mike-list@pobox.com; tls@ietf.= org> CC: > > mike-list@pobox.com wrote:> > > > I think this would be taking= it too far (consider sending> > ServerHelloDone in its own packet). Plus i= f you implement> > TLS 1.2, you also have to implement 1.1 and 1.0 and SSL3= > > which don't have the restriction.> > A separate record doesn't mean its= own IP packet (or TCP segment);> it's just 5 bytes of record header overhe= ad (in case of> NULL_WITH_NULL). But yes, maybe it would still be taking it= too far...> > (But TLS 1.2 spec doesn't require you to implement any older= spec; and> even the older specs in reality seem to have the restriction th= at you> can't fragment handshake messages if you want good interoperability= .)> > Best regards,> Pasi> > ______________________________________________= _> TLS mailing list> TLS@lists.ietf.org> https://www1.ietf.org/mailman/list= info/tls _________________________________________________________________ Express yourself with gadgets on Windows Live Spaces http://discoverspaces.live.com?source=3Dhmtag1&loc=3Dus= --_1bb8edd9-2514-4a24-bcb7-b23cc4dcc392_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Using TCP "urgent mode", say, for security signaling/controls is= a marked deviation from the constructs and design precepts of the SSL Hand= shake, but not the SSL Protocol, note. I'm being very pedantic with termino= logy, for a reason: as we discussed earlier, the SSL Protocol is an encapsu= lation of {SSL Handshake, or other ALPHA handshake(s)) by the Record P= rotocol.
 
Allowing the (standard) SSL Handshake to use TCP urgent mode would detract = from allowing the SSL3 to be recognized as a fully fledged Internet Standar= d, known as TLS, a standing it clearly deserves - given its demonstrated ra= nge of applicability, its hardware and software implementation knowhow, and= the way SSL session handling succesfully cooeprates with stateful inspecti= on firewalls.  In the same vein, recognizing that said poten= tial Internet Standard has proper "future proofing" features (allowing= ALPHA handshake designs down the line to evolve the standard) supports SSL= 3's designation as a fully mature, Internet Standard, known as TLS. That SS= L3 is not tied to today's dominant transport (TCP over IPv4 over the US IP&= nbsp;backbone architecture) is also good for that standing!
 
Without interfering with the recognition SSL3 in its TLS1.1 form should hav= e as an Internet Standard , we could reasonably keep this WG open if there = were a new, distinct standards track initiative to specify one or more= "ALPHA Handshakes" - that (a) parallel the SSL Handshake, and (b) have som= e knowledge of and interaction with post-hooked socket providers (TCP,= X, or some of the class d addressed reliable channels we experimented with= , long ago, using multicast key management, core-based access and connectio= n controls, and session directory support). A long long time ago,= we found it necessary to indeed allow the handshake to *interactively* con= trol how the reliable transport channel behaved, for those transports which= merge byte transfer with the very key management concept and access/connec= tion controls being used in the handshake's design.
 
If this is too abstract for folks, there were at one point I-Ds from NSA de= signers/engineers on using multicast key management for IKE-enhancements ad= dressing multi-drop security association management, that one can peruse&nb= sp;for background. Some of these ideas are appropriate for multi-drop sessi= on management, particularly when ALPHA-design handshakes would be cooperati= ng with the SAML2 protocols at the https.v2  layer, in the setup/teard= own of multi-drop client authentication sessions.






> Subject: RE: [TLS] Record layer corner cases
> Date: Thu, 23 Nov= 2006 11:37:38 +0200
> From: Pasi.Eronen@nokia.com
> To: mike-l= ist@pobox.com; tls@ietf.org
> CC:
>
> mike-list@pobox.c= om wrote:
> >
> > I think this would be taking it too fa= r (consider sending
> > ServerHelloDone in its own packet). Plus i= f you implement
> > TLS 1.2, you also have to implement 1.1 and 1.= 0 and SSL3
> > which don't have the restriction.
>
> = A separate record doesn't mean its own IP packet (or TCP segment);
> = it's just 5 bytes of record header overhead (in case of
> NULL_WITH_N= ULL). But yes, maybe it would still be taking it too far...
>
>= ; (But TLS 1.2 spec doesn't require you to implement any older spec; and> even the older specs in reality seem to have the restriction that you=
> can't fragment handshake messages if you want good interoperabilit= y.)
>
> Best regards,
> Pasi
>
> __________= _____________________________________
> TLS mailing list
> TLS@= lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls

Express yourself with gadgets on Windows Live Spaces Try= it! = --_1bb8edd9-2514-4a24-bcb7-b23cc4dcc392_-- --===============0769853735== 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 --===============0769853735==-- From tls-bounces@lists.ietf.org Mon Nov 27 08:07:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GogBD-0008KI-T2; Mon, 27 Nov 2006 08:05:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GogBC-0008IJ-LV for tls@lists.ietf.org; Mon, 27 Nov 2006 08:05:50 -0500 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GogB8-00022g-RI for tls@lists.ietf.org; Mon, 27 Nov 2006 08:05:50 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kARD5Sj2030656; Mon, 27 Nov 2006 15:05:44 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Nov 2006 15:05:11 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Nov 2006 15:05:10 +0200 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] NIST TLS recomendations (PKCS#1 encryption attacks) Date: Mon, 27 Nov 2006 15:05:14 +0200 Message-ID: In-Reply-To: <7.0.1.0.2.20061101091038.0208f420@nist.gov> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] NIST TLS recomendations (PKCS#1 encryption attacks) Thread-Index: Acb9wgSf1EKVbyKaR12QoVxxwPw3hAUYMLgw From: To: , X-OriginalArrivalTime: 27 Nov 2006 13:05:10.0209 (UTC) FILETIME=[AB1A2B10:01C71224] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061127150544-7664FBB0-37743F0C/0-0/0-1 X-Nokia-AV: Clean 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 Ray Perlner wrote: > Page 62: Section 7.4.9.1 under Note: This section suggests a > procedure to prevent the Bleichenbacher attack on PKCS#1 v1.5 > encrypted messages (specifically the pre-master secret.) This > procedure is not listed as mandatory. We recommend that either this > procedure be made mandatory, or that all RSA encrypted messages be > required to use the OAEP padding scheme specified in PKCS#1 v2. In > the latter scenario, the overwhelming majority of PKCS#1 v1.5 > formatted messages would need to be rejected by any compliant > implementation. =20 > > There is ANOTHER note later in this section (at the very end, after > the implementation notes) that discusses a variant of the > Bleichenbacher attack (by Klima, Pokorny, and Rosa - see [KPR03]) > that depends on the server reporting on errors found in the version > number included in the RSA-decrypted premaster-secret > message. Therefore, the draft's weak statement to the effect that > servers shouldn't generate an alert if there is such a problem > should also be strengthened to a MUST NOT. In fact, it should be a > general rule that decryption problems with PKCS #1.5-formatted > messages MUST NOT trigger actions that are observably different than > the actions that would be taken if there were no problems. Hmm... IMHO this section, as its currently written, doesn't offer enough guidance for an implementer to get it right. Furthermore, the text in Appendix E.2 (about what TLS-capable servers should do in SSL 2.0 compatibility mode) confuses things even further (and seems to ignore the existence of Bleichenbacher/Klima attacks). Then there's the issue on what the spec should say about checking the version number in PreMasterSecret. Currently, it simply says "Client implementations MUST and Server implementations MAY check the version number", which is IMHO a bit vague. Here's a suggested rephrasing for the first and fourth note in Section 7.4.9.1: Note: The version number in the PreMasterSecret is the version offered by the client in the ClientHello.client_version, not the version negotiated for the connection. This feature is designed to prevent rollback attacks. Unfortunately, some old implementations use the negotiated version instead and therefore checking the version number may lead to failure to interoperate with such incorrect client implementations. Client implementations MUST always send the correct version number in PreMasterSecret. If ClientHello.client_version is TLS 1.1 or higher, server implementations MUST check the version number as described in the note below. If the version number is earlier than 1.0, server implementations SHOULD check the version number, but MAY have a configuration option to disable the check. Note: Attacks discovered by Bleichenbacher [BLEI] and Klima et al.=20 [KPR03] can be used to attack a TLS server that reveals whether a particular message, when decrypted, is properly PKCS#1 formatted, contains a valid PreMasterSecret structure, or has the correct version number. The best way to avoid these vulnerabilities is to treat incorrectly formatted messages in a manner indistinguishable from correctly formatted RSA blocks. In other 1. Generate a string R of 46 random bytes 2. Decrypt the message M 3. If the PKCS#1 padding is not correct, or the length of=20 message M is not exactly 48 bytes: premaster secret =3D ClientHello.client_version || R else If ClientHello.client_version <=3D TLS 1.0, and version number check is explicitly disabled: premaster secret =3D M else: premaster secret =3D ClientHello.client_version || M[2..47] In any case, a TLS server MUST NOT generate an alert if processing an RSA-encrypted premaster secret message fails, or the version number is not as expected. Instead, it MUST continue the handshake with a randomly generated premaster secret. Care must also be taken to avoid leaking information about the error situation via log files, or other channels. =20 The RSAES-OAEP encryption scheme defined in [PKCS1] is more secure against the Bleichenbacher attack. However, for maximal compatibility with earlier versions of TLS, this specification uses the RSAES-PKCS1-v1_5 scheme. No variants of the Bleichenbacher attack are known to exist provided that the above recommendations are followed. And rewrite appendix E.2 as follows (changing SHOULD to MUST=20 for sending the 0x03 padding): E.2. Avoiding man-in-the-middle version rollback When TLS clients fall back to Version 2.0 compatibility mode, they MUST use special PKCS#1 block formatting. This is done so that TLS servers will reject Version 2.0 sessions with TLS-capable clients. When a client negotiates SSL 2.0 but also supports TLS, it MUST set the right-hand (least-significant) 8 random bytes of the PKCS padding (not including the terminal null of the padding) for the RSA encryption of the ENCRYPTED-KEY-DATA field of the CLIENT-MASTER-KEY to 0x03 (the other padding bytes are random). When a TLS-capable server negotiates SSL 2.0 it SHOULD, after decrypting the ENCRYPTED-KEY-DATA field, check that these eight padding bytes are 0x03. If they are not, the server SHOULD generate a random value for SECRET-KEY-DATA, and continue the handshake (which will eventually fail since the keys will not match). Note that reporting the error situation to the client could make the server vulnerable to attacks described in [BLEI]. Comments? Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 27 10:46:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoigG-0000aO-7j; Mon, 27 Nov 2006 10:46:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoifU-0007sH-Lx for tls@ietf.org; Mon, 27 Nov 2006 10:45:16 -0500 Received: from proof.pobox.com ([207.106.133.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Goiab-0003Gw-L3 for tls@ietf.org; Mon, 27 Nov 2006 10:40:15 -0500 Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id 9B58427541 for ; Mon, 27 Nov 2006 10:40:30 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 4D8E89753B for ; Mon, 27 Nov 2006 10:40:30 -0500 (EST) Message-ID: <456B0749.4000008@pobox.com> Date: Mon, 27 Nov 2006 07:42:01 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: Subject: [TLS] compression 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 Are there any specs for standard compression schemes for TLS? Thanks, Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 27 10:46:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goig0-0008Re-AR; Mon, 27 Nov 2006 10:45:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goify-0008Nd-Sq for tls@ietf.org; Mon, 27 Nov 2006 10:45:46 -0500 Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Goifx-0004A2-79 for tls@ietf.org; Mon, 27 Nov 2006 10:45:46 -0500 Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id kARFjG5V024073; Mon, 27 Nov 2006 10:45:16 -0500 (EST) Received: from 144.51.60.34 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Mon, 27 Nov 2006 10:45:16 -0500 Received: from EXCH.missi.ncsc.mil ([144.51.60.21]) by gto.missi.ncsc.mil with Microsoft SMTPSVC(5.0.2195.6713); Mon, 27 Nov 2006 10:45:15 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [TLS] Record layer corner cases Date: Mon, 27 Nov 2006 10:45:14 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Record layer corner cases Thread-Index: AccPfhy2Uj/HIvkoRSG/ZRZOWOW59gCtq1rA From: "Kemp, David P." To: "Peter Gutmann" , X-OriginalArrivalTime: 27 Nov 2006 15:45:15.0924 (UTC) FILETIME=[088DF540:01C7123B] X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-14834000 X-TM-AS-Result: : Yes--12.729200-0-2-1 X-TM-AS-Category-Info: : 2:0.000000 X-TM-AS-MatchedID: : =?us-ascii?B?MTUwNTY3LTcwMTE0My03MDI3?= =?us-ascii?B?NzYtNzAxNjUxLTcwMTI1Mi03MTAzMjItNzA5OTE4LTcwNDUwNS03?= =?us-ascii?B?MTA5OTItNzAwODc3LTcxMDIwMS03MDAxNTctNzExMTY0LTcwNzk4?= =?us-ascii?B?NC03MDYyODAtNzEwNDg5LTcxMDQ3My03MDA3ODgtNzA3MzQ0LTcx?= =?us-ascii?B?MDI2NS03MDQ2NTQtMTIxNTM0LTcwMzA3Ni03MDEyOTEtNzAwNTg2?= =?us-ascii?B?LTEwNjY2MC03MDAwNzktNzAwNzg1LTcwMDIwNi03MDExNTAtNzAz?= =?us-ascii?B?MTgyLTcxMTk5Ny03MTAzMzAtNzAwNDY2LTcxMDU2NS03MDA0ODct?= =?us-ascii?B?NzAwNjM0LTcwMDg2Ny03MDkyNzktNzExMDAyLTcwMDgwMi03MTAy?= =?us-ascii?B?NDktNzAyNzY5LTcxMDA3Mi0xMzkwMDYtNzA0MjEzLTcxMTExMS03?= =?us-ascii?B?MDAwNjAtNzA1Mjc2LTcwNTA2NS03MDAxNTEtNzExNTAzLTcwNTU5?= =?us-ascii?B?MS0xMzkwMTAtNzA0NzcxLTcwMjE1Ni03MDMyMjUtNzAzMDk2LTcw?= =?us-ascii?B?MjUyNy03MDQ2NDAtNzAwODIxLTcwMzEwMy03MDIyMTctNzEwODQ1?= =?us-ascii?B?LTE0ODA1MC0yMDA0MA==?= X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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 There is no misbehavior involved at all, and no reason to complain to VeriSign about any dates contained in a rootCA certificate. In fact, VeriSign could have made the nature of trust anchor information more explicitly obvious if they had stuck in a validity period of Jan 1, 1900 0000Z - Jan 1, 1900 0000Z. Including nonsense in the certificate fields that are not part of a trust anchor makes it obvious that the certificate is just a data structure that is being re- (or mis-)used to convey trust anchor information. RFC 3280 (and draft 3280bis-05) clearly specify that trust anchors are maintained out of band, and that trust anchor information does not include a validity period any other certificate fields except the four listed: ----------------------------------------------------------------- (d) trust anchor information, describing a CA that serves as a trust anchor for the certification path. The trust anchor information includes: (1) the trusted issuer name, (2) the trusted public key algorithm, (3) the trusted public key, and (4) optionally, the trusted public key parameters associated with the public key. The trust anchor information may be provided to the path processing procedure in the form of a self-signed certificate. When the trust anchor information is provided in the form of a certificate, the name in the subject field is used as the trusted issuer name and the contents of the subjectPublicKeyInfo field is used as the source of the trusted public key algorithm and the trusted public key. The trust anchor information is trusted because it was delivered to the path processing procedure by some trustworthy out-of-band procedure. ------------------------------------------------------------------ A root CA certificate transmitted in a TLS handshake is neither a trust anchor nor a component of the path to be validated. It is merely a hint to the relying party as to which trust anchor to use for path validation in case the relying party has installed more than one trust anchor key with the same issuer name. If every trust anchor key has a unique issuer name, sending root CA certificates in handshakes is a pure waste of bandwidth without even the benefit of minimizing trial signature verifications. Dave -----Original Message----- From: Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz]=20 Sent: Thursday, November 23, 2006 11:07 PM To: martin.rex@sap.com Cc: tls@ietf.org Subject: Re: [TLS] Record layer corner cases Martin Rex writes: >A few years ago, www.verisign.com had been sending out an expired rootCA >certificate in the certification path of the Server,=20 >and curiously, none of the Web Browsers complained when it had a replacement >cert (same Subject&Issuer, same key, longer validity) in the list of trust >anchors. They just checked the DN and key and left it at that, since only the date had changed the new cert was silently accepted. >Maybe there should be some guidance, common sense doesn't seem to be >sufficient (it took VeriSign several months to fix it when I complained to >them about their server misconfiguration/misbehaviour). _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 27 10:46:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoigG-0000aO-7j; Mon, 27 Nov 2006 10:46:04 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoifU-0007sH-Lx for tls@ietf.org; Mon, 27 Nov 2006 10:45:16 -0500 Received: from proof.pobox.com ([207.106.133.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Goiab-0003Gw-L3 for tls@ietf.org; Mon, 27 Nov 2006 10:40:15 -0500 Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id 9B58427541 for ; Mon, 27 Nov 2006 10:40:30 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 4D8E89753B for ; Mon, 27 Nov 2006 10:40:30 -0500 (EST) Message-ID: <456B0749.4000008@pobox.com> Date: Mon, 27 Nov 2006 07:42:01 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: Subject: [TLS] compression 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 Are there any specs for standard compression schemes for TLS? Thanks, Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 27 10:46:57 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goig0-0008Re-AR; Mon, 27 Nov 2006 10:45:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goify-0008Nd-Sq for tls@ietf.org; Mon, 27 Nov 2006 10:45:46 -0500 Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Goifx-0004A2-79 for tls@ietf.org; Mon, 27 Nov 2006 10:45:46 -0500 Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id kARFjG5V024073; Mon, 27 Nov 2006 10:45:16 -0500 (EST) Received: from 144.51.60.34 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Mon, 27 Nov 2006 10:45:16 -0500 Received: from EXCH.missi.ncsc.mil ([144.51.60.21]) by gto.missi.ncsc.mil with Microsoft SMTPSVC(5.0.2195.6713); Mon, 27 Nov 2006 10:45:15 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [TLS] Record layer corner cases Date: Mon, 27 Nov 2006 10:45:14 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Record layer corner cases Thread-Index: AccPfhy2Uj/HIvkoRSG/ZRZOWOW59gCtq1rA From: "Kemp, David P." To: "Peter Gutmann" , X-OriginalArrivalTime: 27 Nov 2006 15:45:15.0924 (UTC) FILETIME=[088DF540:01C7123B] X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-14834000 X-TM-AS-Result: : Yes--12.729200-0-2-1 X-TM-AS-Category-Info: : 2:0.000000 X-TM-AS-MatchedID: : =?us-ascii?B?MTUwNTY3LTcwMTE0My03MDI3?= =?us-ascii?B?NzYtNzAxNjUxLTcwMTI1Mi03MTAzMjItNzA5OTE4LTcwNDUwNS03?= =?us-ascii?B?MTA5OTItNzAwODc3LTcxMDIwMS03MDAxNTctNzExMTY0LTcwNzk4?= =?us-ascii?B?NC03MDYyODAtNzEwNDg5LTcxMDQ3My03MDA3ODgtNzA3MzQ0LTcx?= =?us-ascii?B?MDI2NS03MDQ2NTQtMTIxNTM0LTcwMzA3Ni03MDEyOTEtNzAwNTg2?= =?us-ascii?B?LTEwNjY2MC03MDAwNzktNzAwNzg1LTcwMDIwNi03MDExNTAtNzAz?= =?us-ascii?B?MTgyLTcxMTk5Ny03MTAzMzAtNzAwNDY2LTcxMDU2NS03MDA0ODct?= =?us-ascii?B?NzAwNjM0LTcwMDg2Ny03MDkyNzktNzExMDAyLTcwMDgwMi03MTAy?= =?us-ascii?B?NDktNzAyNzY5LTcxMDA3Mi0xMzkwMDYtNzA0MjEzLTcxMTExMS03?= =?us-ascii?B?MDAwNjAtNzA1Mjc2LTcwNTA2NS03MDAxNTEtNzExNTAzLTcwNTU5?= =?us-ascii?B?MS0xMzkwMTAtNzA0NzcxLTcwMjE1Ni03MDMyMjUtNzAzMDk2LTcw?= =?us-ascii?B?MjUyNy03MDQ2NDAtNzAwODIxLTcwMzEwMy03MDIyMTctNzEwODQ1?= =?us-ascii?B?LTE0ODA1MC0yMDA0MA==?= X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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 There is no misbehavior involved at all, and no reason to complain to VeriSign about any dates contained in a rootCA certificate. In fact, VeriSign could have made the nature of trust anchor information more explicitly obvious if they had stuck in a validity period of Jan 1, 1900 0000Z - Jan 1, 1900 0000Z. Including nonsense in the certificate fields that are not part of a trust anchor makes it obvious that the certificate is just a data structure that is being re- (or mis-)used to convey trust anchor information. RFC 3280 (and draft 3280bis-05) clearly specify that trust anchors are maintained out of band, and that trust anchor information does not include a validity period any other certificate fields except the four listed: ----------------------------------------------------------------- (d) trust anchor information, describing a CA that serves as a trust anchor for the certification path. The trust anchor information includes: (1) the trusted issuer name, (2) the trusted public key algorithm, (3) the trusted public key, and (4) optionally, the trusted public key parameters associated with the public key. The trust anchor information may be provided to the path processing procedure in the form of a self-signed certificate. When the trust anchor information is provided in the form of a certificate, the name in the subject field is used as the trusted issuer name and the contents of the subjectPublicKeyInfo field is used as the source of the trusted public key algorithm and the trusted public key. The trust anchor information is trusted because it was delivered to the path processing procedure by some trustworthy out-of-band procedure. ------------------------------------------------------------------ A root CA certificate transmitted in a TLS handshake is neither a trust anchor nor a component of the path to be validated. It is merely a hint to the relying party as to which trust anchor to use for path validation in case the relying party has installed more than one trust anchor key with the same issuer name. If every trust anchor key has a unique issuer name, sending root CA certificates in handshakes is a pure waste of bandwidth without even the benefit of minimizing trial signature verifications. Dave -----Original Message----- From: Peter Gutmann [mailto:pgut001@cs.auckland.ac.nz]=20 Sent: Thursday, November 23, 2006 11:07 PM To: martin.rex@sap.com Cc: tls@ietf.org Subject: Re: [TLS] Record layer corner cases Martin Rex writes: >A few years ago, www.verisign.com had been sending out an expired rootCA >certificate in the certification path of the Server,=20 >and curiously, none of the Web Browsers complained when it had a replacement >cert (same Subject&Issuer, same key, longer validity) in the list of trust >anchors. They just checked the DN and key and left it at that, since only the date had changed the new cert was silently accepted. >Maybe there should be some guidance, common sense doesn't seem to be >sufficient (it took VeriSign several months to fix it when I complained to >them about their server misconfiguration/misbehaviour). _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 27 10:51:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goikd-0004zO-7A; Mon, 27 Nov 2006 10:50:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goikb-0004zJ-7J for tls@ietf.org; Mon, 27 Nov 2006 10:50:33 -0500 Received: from moutng.kundenserver.de ([212.227.126.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoikX-0004f0-QS for tls@ietf.org; Mon, 27 Nov 2006 10:50:33 -0500 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1GoikU0adf-0007TL; Mon, 27 Nov 2006 16:50:26 +0100 Received: by tau.invalid (Postfix, from userid 1000) id 208854DE5; Mon, 27 Nov 2006 16:50:24 +0100 (CET) Date: Mon, 27 Nov 2006 16:50:24 +0100 From: Bodo Moeller To: Mike Subject: Re: [TLS] compression Message-ID: <20061127155024.GA11216@tau.invalid> References: <456B0749.4000008@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <456B0749.4000008@pobox.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: 30ac594df0e66ffa5a93eb4c48bcb014 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, Nov 27, 2006 at 07:42:01AM -0800, Mike wrote: > Are there any specs for standard compression > schemes for TLS? Yes, please take a look at RFC 3749. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 27 11:54:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GojjH-0001DL-VO; Mon, 27 Nov 2006 11:53:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GojjH-0001DF-9B for tls@ietf.org; Mon, 27 Nov 2006 11:53:15 -0500 Received: from bay0-omc1-s23.bay0.hotmail.com ([65.54.246.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gojj8-0007xj-P0 for tls@ietf.org; Mon, 27 Nov 2006 11:53:15 -0500 Received: from BAY103-W3 ([65.54.174.103]) by bay0-omc1-s23.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Nov 2006 08:53:06 -0800 X-Originating-IP: [71.140.80.73] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Mike Subject: RE: [TLS] compression Date: Mon, 27 Nov 2006 08:53:06 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 27 Nov 2006 16:53:06.0237 (UTC) FILETIME=[82A66ED0:01C71244] X-Spam-Score: 2.6 (++) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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="===============0012515773==" Errors-To: tls-bounces@lists.ietf.org --===============0012515773== Content-Type: multipart/alternative; boundary="_cb4e5027-373c-44ec-a2b6-185cf971fd23_" --_cb4e5027-373c-44ec-a2b6-185cf971fd23_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It really doesn't provide much practical information - although is mostly c= orrect and excellent, in it own right. It does say in standardese much that= was not stated in the implementors/analysts writeup of SSL3, concerning co= mpression and fragmentation/reassembly procedures performed at the SSL Hand= shake/SSL Record layer boundary. Be aware, that https compression practices= are distinct from SSL compression design, understanding that compression i= s based on the many of the same math principles as type 2 cipher designs, a= nd have many of the same pitfalls when added to packet networking environme= nts. =20 Perhaps, take your new SSL library, and now apply it to class d addressed a= pplications. Take that code and apply it to the types of streams exchanged= between class d addressed applications, and see where it takes you: in the= stream-specific compression world, the supprot required of the SSL record = layer, the key management, and the socket/API controls.=20 =20 Never forget that the SSL (and TLS1.0) writeup only ever represented one vi= ew of the SSL patent: how to make a lightweight interoperable library, targ= eting "browsers" and SSL Connection proxies. =20 > Date: Mon, 27 Nov 2006 16:50:24 +0100> From: bmoeller@acm.org> To: mike-l= ist@pobox.com> Subject: Re: [TLS] compression> CC: tls@ietf.org> > On Mon, = Nov 27, 2006 at 07:42:01AM -0800, Mike wrote:> > > Are there any specs for = standard compression> > schemes for TLS?> > Yes, please take a look at RFC = 3749.> > Bodo> > > _______________________________________________> TLS mai= ling list> TLS@lists.ietf.org> https://www1.ietf.org/mailman/listinfo/tls _________________________________________________________________ Check the weather nationwide with MSN Search: Try it now! http://search.msn.com/results.aspx?q=3Dweather&FORM=3DWLMTAG= --_cb4e5027-373c-44ec-a2b6-185cf971fd23_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

It really doesn't provide much practical information - althou= gh is mostly correct and excellent, in it own right. It does say in standar= dese much that was not stated in the implementors/analysts writeup of SSL3,= concerning compression and fragmentation/reassembly procedures performed a= t the SSL Handshake/SSL Record layer boundary. Be aware, that https compres= sion practices are distinct from SSL compression design, understanding that= compression is based on the many of the same math principles as type = 2 cipher designs, and have many of the same pitfalls when added to packet n= etworking environments.
 
Perhaps, take your new SSL library, and now apply it to class d addressed a= pplications.  Take that code and apply it to the types of streams exch= anged between class d addressed applications, and see where it takes you: i= n the stream-specific compression world, the supprot required of the SSL re= cord layer, the key management, and the socket/API controls.
 
Never forget that the SSL (and TLS1.0) writeup only ever represented one vi= ew of the SSL patent: how to make a lightweight interoperable library, targ= eting "browsers" and SSL Connection proxies.

 

> Date: Mon, 27 Nov 2006 16:50:24 +0100
> From: bmoeller@acm.org> To: mike-list@pobox.com
> Subject: Re: [TLS] compression
&g= t; CC: tls@ietf.org
>
> On Mon, Nov 27, 2006 at 07:42:01AM -08= 00, Mike wrote:
>
> > Are there any specs for standard comp= ression
> > schemes for TLS?
>
> Yes, please take a l= ook at RFC 3749.
>
> Bodo
>
>
> __________= _____________________________________
> TLS mailing list
> TLS@= lists.ietf.org
> https://www1.ietf.org/mailman/listinfo/tls

Check the weather nationwide with MSN Search Try it= now! = --_cb4e5027-373c-44ec-a2b6-185cf971fd23_-- --===============0012515773== 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 --===============0012515773==-- From tls-bounces@lists.ietf.org Mon Nov 27 12:13:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gok2A-0001y3-W3; Mon, 27 Nov 2006 12:12:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gok29-0001xa-Tc for tls@ietf.org; Mon, 27 Nov 2006 12:12:45 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gok1p-0002HN-Fb for tls@ietf.org; Mon, 27 Nov 2006 12:12:45 -0500 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id SAA15467; Mon, 27 Nov 2006 18:12:11 +0100 (MEZ) From: Martin Rex Message-Id: <200611271712.SAA11395@uw1048.wdf.sap.corp> Subject: Re: [TLS] Record layer corner cases To: DPKemp@missi.ncsc.mil (Kemp David P.) Date: Mon, 27 Nov 2006 18:12:09 +0100 (MET) In-Reply-To: from "Kemp, David P." at Nov 27, 6 10:45:14 am 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: 79899194edc4f33a41f49410777972f8 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 Kemp, David P. wrote: > > There is no misbehavior involved at all, and no reason to > complain to VeriSign about any dates contained in a rootCA > certificate. In fact, VeriSign could have made the nature > of trust anchor information more explicitly obvious if they > had stuck in a validity period of Jan 1, 1900 0000Z - > Jan 1, 1900 0000Z. Including nonsense in the certificate > fields that are not part of a trust anchor makes it obvious > that the certificate is just a data structure that is being > re- (or mis-)used to convey trust anchor information. I do not mind about not checking validity dates (or even signatures) on trust anchors. But when an X.509 certficates is sent as part of a certification path, then it is not a trust anchor, but instead a regular certificate -- and therefore MUST be a correct certificate (or not be sent in a certification path!). -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 27 12:48:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GokaN-0000nK-Dr; Mon, 27 Nov 2006 12:48:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GokaL-0000ks-H1 for tls@ietf.org; Mon, 27 Nov 2006 12:48:05 -0500 Received: from bay0-omc2-s33.bay0.hotmail.com ([65.54.246.169]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GokZ9-0007jv-Nx for tls@ietf.org; Mon, 27 Nov 2006 12:46:53 -0500 Received: from BAY103-W8 ([65.54.174.108]) by bay0-omc2-s33.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Nov 2006 09:46:51 -0800 X-Originating-IP: [71.140.80.73] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: Peter Gutmann , Subject: RE: [TLS] Record layer corner cases Date: Mon, 27 Nov 2006 09:46:51 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 27 Nov 2006 17:46:51.0116 (UTC) FILETIME=[04D3EAC0:01C7124C] X-Spam-Score: 2.6 (++) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c 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="===============1709541921==" Errors-To: tls-bounces@lists.ietf.org --===============1709541921== Content-Type: multipart/alternative; boundary="_b2aa178c-1147-47b6-a401-227aa5b7ba1c_" --_b2aa178c-1147-47b6-a401-227aa5b7ba1c_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Out of interest Peter and Martin, how well do your software and hardward mo= dules handle the following change from SSL v2 to SSL v3, including fallback= handling as specified by SSL3, and then the TLS fallback mechanisms? =20 "SSL Version 3 supports the transmission and reception of "out of band data= ". Out of band data is normally defined at the TCP/IP protocol level, but b= ecause of SSL's privacy enhancements and support for block ciphers, this be= comes difficult to support. To send out-of-band data, the sender sends an e= scape record whose body contains a single byte of data indicating the escap= e type code: char escape-tee-code The escape-type-code value should be SSL.= sub.-- ET.sub.-- OOB.sub.-- DATA. The record following the escape record wi= ll be interpreted as "out-of-band" data and will only be made available to = the receiver through an unspecified mechanism that is different than the re= ceivers normal data reception method. The transmitted data record and the e= scape record are transmitted normally (i.e. encryption, MAC computations, a= nd block cipher padding remain in effect). "Its worth exploring this area, = in Windows 2000 onward, I found. From: home_pw@msn.comTo: pgut001@cs.auckland.ac.nz; martin.rex@sap.comCC: t= ls@ietf.orgSubject: RE: [TLS] Record layer corner casesDate: Thu, 23 Nov 20= 06 20:57:42 -0800 > For root certs, the practice is to have them never expire [0]. You'll nev= er> see this written down anywhere (you're supposed to roll over certs ever= y few> years), but I think in practice everyone in the industry knows that = root cert> replacement is so unworkable that you just give your certs an in= finite> lifetime. When it comes to security vs.availability, availability a= lways wins> out.> > Peter. The business/investement model dictated this. Ve= riSign existed to make money for its venture investors; nothing would stand= in that way, and certainly not personal privacy interests (For example, im= plement mandatory key escrow! or be put out of business by USG!! VeriSign m= anagement quickly kowtow'ed, as did most but not all of the IETF luminaries= , to be fair to the VeriSign team). So whilst capitalism broke through the = barriers to engender adoption, capitalism also upheld certain other social = issues concerning privacy limits via deception, etc. So, fair is fair... Bu= t, we are still learning, about crypto and society. Peter was very wrong re= cently! Even though TLS1.0 had null cipher suites for years, the credit-car= d world did not *actually* crumble. At the same time, its true that only in= the recent IE7 has the global infrastructure for grandmas finally made TLS= 1.1 the default (and with MSFT IETF-unverified techniques for testing which= TLS extensions are actually supported on servers!). So, perhaps we will ye= t see what further evidence of TLS design vs practice has to offer, now it = enters mainstream testing. Peter W. Search from any Web page with powerful protection. Get the FREE Windows Liv= e Toolbar Today! Try it now!=20 _________________________________________________________________ Check the weather nationwide with MSN Search: Try it now! http://search.msn.com/results.aspx?q=3Dweather&FORM=3DWLMTAG= --_b2aa178c-1147-47b6-a401-227aa5b7ba1c_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable  
Out of interest Peter and Martin, how well do your software and hardward mo= dules handle the following change from SSL v2 to SSL v3, including fallback= handling as specified by SSL3, and then the TLS fallback mechanisms?
 
"SSL Version 3 supports the transmission and reception of "out of band data= ". Out of band data is normally defined at the TCP/IP protocol level, but b= ecause of SSL's privacy enhancements and support for block ciphers, this be= comes difficult to support.

To send out-of-band data, the sender se= nds an escape record whose body contains a single byte of data indicating t= he escape type code:

char escape-tee-code

The escape-type-c= ode value should be SSL.sub.-- ET.sub.-- OOB.sub.-- = DATA. The record following the escape record will be interpreted as "out-of= -band" data and will only be made available to the receiver through an unsp= ecified mechanism that is different than the receivers normal data receptio= n method. The transmitted data record and the escape record are transmitted= normally (i.e. encryption, MAC computations, and block cipher padding rema= in in effect). "

Its worth exploring this area, in Windows 2000 onwa= rd, I found.


From: home_pw@msn.com
To: pgut001@cs.auckland.ac.nz; martin.rex@sap.com<= BR>CC: tls@ietf.org
Subject: RE: [TLS] Record layer corner cases
Date= : Thu, 23 Nov 2006 20:57:42 -0800





> For root certs, the practice is to have them never exp= ire [0]. You'll never
> see this written down anywhere (you're suppos= ed to roll over certs every few
> years), but I think in practice eve= ryone in the industry knows that root cert
> replacement is so unwork= able that you just give your certs an infinite
> lifetime. When it co= mes to security vs.availability, availability always wins
> out.
&= gt;
> Peter.

 
The business/investement model dictate= d this. VeriSign existed to make money for its venture investors; nothing w= ould stand in that way, and certainly not personal privacy interests (For e= xample, implement mandatory key escrow! or be put out of business by USG!! = VeriSign management quickly kowtow'ed, as did most but not all of the IETF = luminaries, to be fair to the VeriSign team). So whilst capitalism broke th= rough the barriers to engender adoption, capitalism also upheld certain oth= er social issues concerning privacy limits via deception, etc. So, fair is = fair...
 
But, we are still learning, about crypto and society. = Peter was very wrong recently! Even though TLS1.0 had null cipher suites fo= r years, the credit-card world did not *actually* crumble. At the same time= , its true that only in the recent IE7 has the global infrastructure f= or grandmas finally made TLS1.1 the default (and with MSFT IETF-unverified = techniques for testing which TLS extensions are actually supported on serve= rs!). So, perhaps we will yet see what further evidence of TLS design vs pr= actice has to offer, now it enters mainstream testing.
 
Peter W= .

Search from any Web page with powerful protection. Get the FREE Windows Liv= e Toolbar Today! Try it now!

Check the weather nationwid= e with MSN Search Try it now! = --_b2aa178c-1147-47b6-a401-227aa5b7ba1c_-- --===============1709541921== 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 --===============1709541921==-- From tls-bounces@lists.ietf.org Mon Nov 27 13:05:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GokqX-0005lx-9m; Mon, 27 Nov 2006 13:04:49 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GokqV-0005lm-Nl for tls@ietf.org; Mon, 27 Nov 2006 13:04:47 -0500 Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GokqU-0002MW-3n for tls@ietf.org; Mon, 27 Nov 2006 13:04:47 -0500 Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id kARI4i5V002215 for ; Mon, 27 Nov 2006 13:04:44 -0500 (EST) Received: from 144.51.60.34 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Mon, 27 Nov 2006 13:04:44 -0500 Received: from EXCH.missi.ncsc.mil ([144.51.60.21]) by gto.missi.ncsc.mil with Microsoft SMTPSVC(5.0.2195.6713); Mon, 27 Nov 2006 13:04:44 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [TLS] Record layer corner cases Date: Mon, 27 Nov 2006 13:04:42 -0500 Message-ID: In-Reply-To: <200611271712.SAA11395@uw1048.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Record layer corner cases Thread-Index: AccSRzD5ObTHuJ3HTVyX3k2v7dCv3QAAbGVw From: "Kemp, David P." To: X-OriginalArrivalTime: 27 Nov 2006 18:04:44.0333 (UTC) FILETIME=[8483D5D0:01C7124E] X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-14838003 X-TM-AS-Result: : Yes--8.841400-0-31-1 X-TM-AS-Category-Info: : 31:0.000000 X-TM-AS-MatchedID: : =?us-ascii?B?MTUwNTY3LTcwNzM0NC03MDI5?= =?us-ascii?B?MjgtNzEwOTkyLTExMzIyOC03MTAyMDEtNzAxMjkxLTcxMTI4Ni03?= =?us-ascii?B?MDE2NTEtNzEwMjgzLTcxMDI2NS03MDEwNjUtNzAxMTQzLTcwNTAy?= =?us-ascii?B?MC03MTIyMjQtNzAyNzY5LTcwMDc4OC0xODgwMTktNzAwNDg3LTcw?= =?us-ascii?B?ODMwMi03MDgwNjEtNzAwODc3LTcwMTEzNS03MDI5NjAtNzEwNTA0?= =?us-ascii?B?LTcwMDQzNy03MDQxNjktNzExMTAxLTcwMzE4Mi03MDE0MDAtNzAz?= =?us-ascii?B?MDk3LTcwMTI5NS0xMTMyMTEtNzEwMDcyLTEzOTAwNi03MDUyNzYt?= =?us-ascii?B?NzA1MDY1LTcwMDE1MS03MDU0OTktNzAwMDYwLTcwMzAwMS03MTE1?= =?us-ascii?B?MDMtNzAwMjcwLTEzOTAxMC03MDI3NzYtNzAxMjUyLTcxMDMyMi03?= =?us-ascii?B?MDk5MTgtNzA0NTA1LTcwMDE1Ny03MTExNjQtMTIxNjI4LTcwMDU4?= =?us-ascii?B?Ni03MDAzNjktNzAyNTI2LTcwMjA1MS0xNDgwNTAtMjAwNDA=?= X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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 The objective of path validation is to ensure that a valid path exists from an end entity certificate back to a trust anchor. If a self-issued certificate is transmitted as part of a path and its name and key are also used as a trust anchor, then there are many paths that will satisfy signature/name chaining: 1) TA -> CA Cert -> EE Cert 2) TA -> Root Cert -> CA Cert -> EE Cert 3) TA -> Root Cert -> Root Cert -> CA Cert -> EE Cert 4) TA -> Root Cert -> Root Cert -> Root Cert -> CA Cert -> EE 5) ... If the root cert has a bad validity, then path 2) will not validate. However, in order to authenticate the end entity, it is sufficient that path 1) validates. The fact that there are any number of invalid paths from EE to TA does not negate the fact that there is at least one valid path. Unlike S/MIME, the TLS spec requires transmission of a complete cert chain from EE to TA. However, if TLS requires that a transmitted root cert be used as a component of a path as in 2), not just a TA hint as in 1), then the TLS spec is broken. I don't believe that's the case: SSL or TLS do not require that a transmitted self-issued cert be used as both a TA hint *and* a path component. Dave -----Original Message----- From: Martin Rex [mailto:martin.rex@sap.com]=20 Sent: Monday, November 27, 2006 12:12 PM To: Kemp, David P. Cc: pgut001@cs.auckland.ac.nz; martin.rex@sap.com; tls@ietf.org Subject: Re: [TLS] Record layer corner cases Kemp, David P. wrote: >=20 > There is no misbehavior involved at all, and no reason to > complain to VeriSign about any dates contained in a rootCA > certificate. In fact, VeriSign could have made the nature > of trust anchor information more explicitly obvious if they > had stuck in a validity period of Jan 1, 1900 0000Z - > Jan 1, 1900 0000Z. Including nonsense in the certificate > fields that are not part of a trust anchor makes it obvious > that the certificate is just a data structure that is being > re- (or mis-)used to convey trust anchor information. I do not mind about not checking validity dates (or even signatures) on trust anchors. But when an X.509 certficates is sent as part of a certification path, then it is not a trust anchor, but instead a regular certificate -- and therefore MUST be a correct certificate (or not be sent in a certification path!). -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 27 13:08:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goktl-0006e4-PL; Mon, 27 Nov 2006 13:08:09 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goktl-0006dt-3x for tls@ietf.org; Mon, 27 Nov 2006 13:08:09 -0500 Received: from proof.pobox.com ([207.106.133.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gokth-0002vm-TT for tls@ietf.org; Mon, 27 Nov 2006 13:08:09 -0500 Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id 7428924E15 for ; Mon, 27 Nov 2006 13:08:27 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 3C8F199FE0 for ; Mon, 27 Nov 2006 13:08:27 -0500 (EST) Message-ID: <456B29F6.8060501@pobox.com> Date: Mon, 27 Nov 2006 10:09:58 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] compression References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 > Perhaps, take your new SSL library, and now apply it to class d > addressed applications. Take that code and apply it to the types of > streams exchanged between class d addressed applications, and see where > it takes you: in the stream-specific compression world, the supprot > required of the SSL record layer, the key management, and the socket/API > controls. What is a "class d addressed application"? Thanks, Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 27 13:12:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GokxR-0007jU-Hr; Mon, 27 Nov 2006 13:11:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GokxP-0007jH-TZ for tls@ietf.org; Mon, 27 Nov 2006 13:11:55 -0500 Received: from proof.pobox.com ([207.106.133.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GokxO-0003g3-NL for tls@ietf.org; Mon, 27 Nov 2006 13:11:55 -0500 Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id 7D2FB2B3AF for ; Mon, 27 Nov 2006 13:12:16 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 8D69496B4D for ; Mon, 27 Nov 2006 13:12:15 -0500 (EST) Message-ID: <456B2ADB.1070406@pobox.com> Date: Mon, 27 Nov 2006 10:13:47 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Record layer corner cases References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed 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 > "SSL Version 3 supports the transmission and reception of "out of band > data". I don't think so. But it would be easy to define a new record type for that. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 27 13:33:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GolHk-0005GN-9d; Mon, 27 Nov 2006 13:32:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GolHj-0005G9-6d for tls@ietf.org; Mon, 27 Nov 2006 13:32:55 -0500 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GolHi-0006jW-05 for tls@ietf.org; Mon, 27 Nov 2006 13:32:55 -0500 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 6A9669658E for ; Mon, 27 Nov 2006 13:33:15 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id 394B8964F1 for ; Mon, 27 Nov 2006 13:33:15 -0500 (EST) Message-ID: <456B2FC6.10902@pobox.com> Date: Mon, 27 Nov 2006 10:34:46 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: Subject: [TLS] Truncated HMAC recommendation 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 it would be good to add a recommendation that when the truncated HMAC extension is used, the amount of padding added for block ciphers should be the minimum required. It seems silly to save 10 bytes of MAC data and then add 250+ extra padding bytes. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 27 13:36:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GolKu-0007eO-4H; Mon, 27 Nov 2006 13:36:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GolKs-0007b2-Va for tls@ietf.org; Mon, 27 Nov 2006 13:36:10 -0500 Received: from raman.networkresonance.com ([198.144.196.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GolKr-0007Gu-3C for tls@ietf.org; Mon, 27 Nov 2006 13:36:10 -0500 Received: by raman.networkresonance.com (Postfix, from userid 1001) id 471C81E8C5D; Mon, 27 Nov 2006 10:36:05 -0800 (PST) To: Mike Subject: Re: [TLS] Truncated HMAC recommendation References: <456B2FC6.10902@pobox.com> From: Eric Rescorla Date: Mon, 27 Nov 2006 10:36:05 -0800 In-Reply-To: <456B2FC6.10902@pobox.com> (Mike's message of "Mon, 27 Nov 2006 10:34:46 -0800") Message-ID: <86ac2cohyi.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: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 Mike writes: > I think it would be good to add a recommendation > that when the truncated HMAC extension is used, > the amount of padding added for block ciphers > should be the minimum required. It seems silly > to save 10 bytes of MAC data and then add 250+ > extra padding bytes. I agree with your analysis, but it's not clear why this should go into the standard. -Ekr _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 27 13:38:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GolME-0008H5-BJ; Mon, 27 Nov 2006 13:37:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GolMC-0008Gz-U0 for tls@ietf.org; Mon, 27 Nov 2006 13:37:32 -0500 Received: from mga03.intel.com ([143.182.124.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GolM9-0007SQ-34 for tls@ietf.org; Mon, 27 Nov 2006 13:37:32 -0500 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by mga03.intel.com with ESMTP; 27 Nov 2006 10:37:28 -0800 Received: from fmsmsx334.amr.corp.intel.com ([132.233.42.1]) by azsmga001.ch.intel.com with ESMTP; 27 Nov 2006 10:37:28 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,464,1157353200"; d="scan'208"; a="150842750:sNHT25328058" Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Nov 2006 10:37:25 -0800 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] Truncated HMAC recommendation Date: Mon, 27 Nov 2006 13:37:23 -0500 Message-ID: <279DDDAFA85EC74C9300A0598E704056FE7433@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Truncated HMAC recommendation thread-index: AccSUqo2kyHuBzq4QiO53UXew6RcmAAAErRw From: "Blumenthal, Uri" To: "Mike" , X-OriginalArrivalTime: 27 Nov 2006 18:37:25.0618 (UTC) FILETIME=[15882D20:01C71253] 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 MAC truncation is not done to save bytes over the wire. -----Original Message----- From: Mike [mailto:mike-list@pobox.com]=20 Sent: Monday, November 27, 2006 1:35 PM To: tls@ietf.org Subject: [TLS] Truncated HMAC recommendation I think it would be good to add a recommendation that when the truncated HMAC extension is used, the amount of padding added for block ciphers should be the minimum required. It seems silly to save 10 bytes of MAC data and then add 250+ extra padding bytes. Mike _______________________________________________ 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 Mon Nov 27 13:39:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GolN0-0000Ah-Vn; Mon, 27 Nov 2006 13:38:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GolN0-00009s-Bk for tls@ietf.org; Mon, 27 Nov 2006 13:38:22 -0500 Received: from proof.pobox.com ([207.106.133.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GolMy-0007a4-5P for tls@ietf.org; Mon, 27 Nov 2006 13:38:22 -0500 Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id BF2E529E76 for ; Mon, 27 Nov 2006 13:38:41 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 7D2599A009 for ; Mon, 27 Nov 2006 13:38:41 -0500 (EST) Message-ID: <456B310D.1080106@pobox.com> Date: Mon, 27 Nov 2006 10:40:13 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [TLS] 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: , Errors-To: tls-bounces@lists.ietf.org Over the weekend someone was able to negotiate TLS 1.2 with my test server at: https://www.mikestoolbox.net:4433/ So it appears that I got it right. Feel free to use it to check your own implementations. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 27 14:12:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoltX-00014N-9z; Mon, 27 Nov 2006 14:11:59 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GoltV-00014C-SN for tls@ietf.org; Mon, 27 Nov 2006 14:11:57 -0500 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GoltT-00043n-M6 for tls@ietf.org; Mon, 27 Nov 2006 14:11:57 -0500 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 649FA97732 for ; Mon, 27 Nov 2006 14:12:17 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id 9F99D9772F for ; Mon, 27 Nov 2006 14:12:16 -0500 (EST) Message-ID: <456B38EC.3030409@pobox.com> Date: Mon, 27 Nov 2006 11:13:48 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Truncated HMAC recommendation References: <279DDDAFA85EC74C9300A0598E704056FE7433@hdsmsx412.amr.corp.intel.com> In-Reply-To: <279DDDAFA85EC74C9300A0598E704056FE7433@hdsmsx412.amr.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 > MAC truncation is not done to save bytes over the wire. The spec says that "it may be desirable in constrained environments to save bandwidth by truncating the output of the hash function to 80 bits when forming MAC tags." If that weren't the case, why would you want to truncate the MAC? Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 27 14:24:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gom5g-00031k-04; Mon, 27 Nov 2006 14:24:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gom5e-00031J-Rc for TLS@lists.ietf.org; Mon, 27 Nov 2006 14:24:30 -0500 Received: from simmts7.bellnexxia.net ([206.47.199.165] helo=simmts7-srv.bellnexxia.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gom5d-0005sK-Ig for TLS@lists.ietf.org; Mon, 27 Nov 2006 14:24:30 -0500 Received: from pbo8f8e10aowa ([65.94.92.118]) by simmts7-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with SMTP id <20061127192424.WFXW16677.simmts7-srv.bellnexxia.net@pbo8f8e10aowa>; Mon, 27 Nov 2006 14:24:24 -0500 Message-ID: <003001c71259$ebc19470$765c5e41@pbo8f8e10aowa> From: "Omirjan Batyrbaev" To: "EKR" References: <006001c70c4b$3d624780$87a85e41@pbo8f8e10aowa><86lkm6rdau.fsf@delta.rtfm.com><002401c70cb5$c0a410a0$55aa5e41@pbo8f8e10aowa><86d57irvjl.fsf@raman.networkresonance.com><00ac01c70ceb$040bf990$55aa5e41@pbo8f8e10aowa> <86wt5pre0f.fsf@raman.networkresonance.com> Subject: Re: [TLS] Serious crypto problem fixed by envelope HMAC method instead of currently used prefix Date: Mon, 27 Nov 2006 14:26:21 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1409 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1409 X-Spam-Score: 1.0 (+) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: TLS@lists.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 see below: > "Omirjan Batyrbaev" writes: > > > Hi Eric, > > I've seen the TLS reference to the "Request for Comments: 2104" so this is > > (probably) the HMAC used in TLS. Quoting to be on the same page: > > "To compute HMAC over the data `text' we perform > > H(K XOR opad, H(K XOR ipad, text))" > > > > However, this RFC was produced in 1997 but SSL was from 1995 (or earlier?). > > Do you know which HMAC they used in say SSL v3 and v2 (which is still an > > option in my browser, etc.)? > > SSLv3 used a variant of the original HMAC (pre-2104). IIRC, SSLv2 > didn't use HMAC and *did* have an extension attack, but that's > hardly our problem at this point. > > -Ekr But does SSL v2 has the lenth field protection (as we discussed) against an extension attack? Can somebody send me the function used in SSL v2? -Omirjan > > _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 27 14:28:38 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gom8x-0004UZ-4y; Mon, 27 Nov 2006 14:27:55 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gom8v-0004UA-3f for tls@ietf.org; Mon, 27 Nov 2006 14:27:53 -0500 Received: from mga09.intel.com ([134.134.136.24]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gom8q-0006xf-E6 for tls@ietf.org; Mon, 27 Nov 2006 14:27:53 -0500 Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by mga09.intel.com with ESMTP; 27 Nov 2006 11:27:45 -0800 Received: from fmsmsx334.amr.corp.intel.com ([132.233.42.1]) by fmsmga002.fm.intel.com with ESMTP; 27 Nov 2006 11:27:45 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,464,1157353200"; d="scan'208"; a="20244652:sNHT18914499" Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Nov 2006 11:27:45 -0800 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] Truncated HMAC recommendation Date: Mon, 27 Nov 2006 14:27:42 -0500 Message-ID: <279DDDAFA85EC74C9300A0598E704056FE74A3@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Truncated HMAC recommendation thread-index: AccSWD6j7rsyhSPVR0S9tZ1Cd5YbAQAANmoA From: "Blumenthal, Uri" To: "Mike" , X-OriginalArrivalTime: 27 Nov 2006 19:27:45.0364 (UTC) FILETIME=[1D70D940:01C7125A] 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 >> MAC truncation is not done to save bytes over the wire. > >The spec says that "it may be desirable in constrained >environments to save bandwidth by truncating the output >of the hash function to 80 bits when forming MAC tags." > >If that weren't the case, why would you want to >truncate the MAC? *I* would want to truncate the MAC to make cryptanalytic job of my adversary harder by forbidding him verification of his guesses of the correct authentication key (as I do not provide the entire computed MAC). On the other hand, truncatng MAC makes the birthday paradox attacks easier (the shorter the MAC - the fewer messages you need). So the transmitted MAC size is a compromise between mitigating both of these two threats. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 27 14:31:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GomCH-000223-75; Mon, 27 Nov 2006 14:31:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GomCG-00021s-Hf for TLS@lists.ietf.org; Mon, 27 Nov 2006 14:31:20 -0500 Received: from mga01.intel.com ([192.55.52.88]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GomCF-0007bX-7s for TLS@lists.ietf.org; Mon, 27 Nov 2006 14:31:20 -0500 Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by mga01.intel.com with ESMTP; 27 Nov 2006 11:31:07 -0800 Received: from fmsmsx334.amr.corp.intel.com ([132.233.42.1]) by fmsmga001.fm.intel.com with ESMTP; 27 Nov 2006 11:31:06 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,464,1157353200"; d="scan'208"; a="169601940:sNHT34671616" Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Nov 2006 11:31:06 -0800 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] Serious crypto problem fixed by envelope HMAC methodinstead of currently used prefix Date: Mon, 27 Nov 2006 14:31:04 -0500 Message-ID: <279DDDAFA85EC74C9300A0598E704056FE74AC@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Serious crypto problem fixed by envelope HMAC methodinstead of currently used prefix thread-index: AccSWb3bTW/M59oURD+M+/FTlCLt6QAAG2UA From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 27 Nov 2006 19:31:06.0613 (UTC) FILETIME=[95650250:01C7125A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 >> SSLv3 used a variant of the original HMAC (pre-2104). >> IIRC, SSLv2 didn't use HMAC and *did* have an extension >> attack, but that's hardly our problem at this point. > > But does SSL v2 has the lenth field protection > (as we discussed) against an extension attack? > Can somebody send me the function used in SSL v2? As SSLv2 is a technically-dead protocol (that is not thrown out from the code only for compatibility reasons), how relevant is it now??? _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 27 14:41:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GomLW-0006nE-5v; Mon, 27 Nov 2006 14:40:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GomLV-0006n2-7N for tls@ietf.org; Mon, 27 Nov 2006 14:40:53 -0500 Received: from webmail.ntru.com ([64.115.150.147] helo=OHTHREE.jjj-i.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GomLU-0000m0-19 for tls@ietf.org; Mon, 27 Nov 2006 14:40:53 -0500 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] Truncated HMAC recommendation Date: Mon, 27 Nov 2006 14:39:03 -0500 Message-ID: <9DC3EBEFB87A97498A7D25F130DE27E49845E5@ohthree.jjj-i.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Truncated HMAC recommendation thread-index: AccSWD6j7rsyhSPVR0S9tZ1Cd5YbAQAANmoAAACe5NA= From: "Whyte, William" To: "Blumenthal, Uri" , "Mike" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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* would want to truncate the MAC to make cryptanalytic job of my > adversary harder by forbidding him verification of his guesses of the > correct authentication key (as I do not provide the entire computed > MAC). But if you truncate it to half-length, two MACs are enough to allow verification of a guess with high probability. I don't think this is a significant gain. William _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 27 14:48:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GomSG-0000Lo-5j; Mon, 27 Nov 2006 14:47:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GomSF-0000Li-8Q for tls@ietf.org; Mon, 27 Nov 2006 14:47:51 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GomSC-0001Un-ST for tls@ietf.org; Mon, 27 Nov 2006 14:47:51 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id UAA19201; Mon, 27 Nov 2006 20:47:23 +0100 (MEZ) From: Martin Rex Message-Id: <200611271947.UAA13557@uw1048.wdf.sap.corp> Subject: Re: [TLS] Record layer corner cases To: DPKemp@missi.ncsc.mil (Kemp David P.) Date: Mon, 27 Nov 2006 20:47:20 +0100 (MET) In-Reply-To: from "Kemp, David P." at Nov 27, 6 01:04:42 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: e1e48a527f609d1be2bc8d8a70eb76cb 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 SSLv3 didn't say whether the certification path includes a rootCA (=self-signed) cert or not, i.e. the spec was ambiguous. TLSv1 improved the situation, indicating that the path may or may not contain a rootCA (=self-signed) cert, and mentioned that such a cert, if present, should not have an impact on the decision whether the peer's certificate is trusted. Kemp, David P. wrote: > > The objective of path validation is to ensure that a valid path > exists from an end entity certificate back to a trust anchor. > If a self-issued certificate is transmitted as part of a path > and its name and key are also used as a trust anchor, then there > are many paths that will satisfy signature/name chaining: > > 1) TA -> CA Cert -> EE Cert > 2) TA -> Root Cert -> CA Cert -> EE Cert > 3) TA -> Root Cert -> Root Cert -> CA Cert -> EE Cert > 4) TA -> Root Cert -> Root Cert -> Root Cert -> CA Cert -> EE > 5) ... > > If the root cert has a bad validity, then path 2) will not > validate. However, in order to authenticate the end entity, > it is sufficient that path 1) validates. The fact that there > are any number of invalid paths from EE to TA does not negate the > fact that there is at least one valid path. I don't know whether the PKI fanciers have specified this anywhere, but I would consider it seriously braindead if there was such a path validation algorithm. If a path can be built, it must verify. If a path can not be built, it can not be verified and must be ignored. Requiring the receiver to weed our garbage sent by the peer is asking for (interoperability) troubles, and a serious waste of every receives resources (especially for busy servers). -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 27 14:53:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GomWp-0007sz-VT; Mon, 27 Nov 2006 14:52:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GomWp-0007sC-1F for TLS@lists.ietf.org; Mon, 27 Nov 2006 14:52:35 -0500 Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GomWn-0002FM-J5 for TLS@lists.ietf.org; Mon, 27 Nov 2006 14:52:35 -0500 Received: by machshav.com (Postfix, from userid 512) id 209BBFB513; Mon, 27 Nov 2006 19:52:33 +0000 (UTC) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 41EE0FB46D; Mon, 27 Nov 2006 19:52:32 +0000 (UTC) Received: by berkshire.machshav.com (Postfix, from userid 54047) id 325A23C06EB; Mon, 27 Nov 2006 14:52:31 -0500 (EST) Date: Mon, 27 Nov 2006 14:52:31 -0500 From: "Steven M. Bellovin" To: "Blumenthal, Uri" Subject: Re: [TLS] Serious crypto problem fixed by envelope HMAC methodinstead of currently used prefix In-Reply-To: <279DDDAFA85EC74C9300A0598E704056FE74AC@hdsmsx412.amr.corp.intel.com> References: <279DDDAFA85EC74C9300A0598E704056FE74AC@hdsmsx412.amr.corp.intel.com> Organization: Columbia University X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20061127195231.325A23C06EB@berkshire.machshav.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: TLS@lists.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, 27 Nov 2006 14:31:04 -0500 "Blumenthal, Uri" wrote: > >> SSLv3 used a variant of the original HMAC (pre-2104). > >> IIRC, SSLv2 didn't use HMAC and *did* have an extension > >> attack, but that's hardly our problem at this point. > > > > But does SSL v2 has the lenth field protection > > (as we discussed) against an extension attack? > > Can somebody send me the function used in SSL v2? > > As SSLv2 is a technically-dead protocol (that is not thrown out from > the code only for compatibility reasons), how relevant is it now??? > Agreed. SSLv2 has other flaws beyond that. Besides, if memory serves, IE7 doesn't include it, which means that it's quite irrelevant going forward. Finally -- we're defining TLS versions; we're not trying to repair flaws in SSLv2 or even v3. I don't see the relevance of the question to this WG. --Steve 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 Mon Nov 27 15:29:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gon4u-0006kR-Ti; Mon, 27 Nov 2006 15:27:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gon4t-0006jd-DE for tls@lists.ietf.org; Mon, 27 Nov 2006 15:27:47 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gon4s-0007XF-0S for tls@lists.ietf.org; Mon, 27 Nov 2006 15:27:47 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id VAA08117; Mon, 27 Nov 2006 21:27:18 +0100 (MEZ) From: Martin Rex Message-Id: <200611272027.VAA14146@uw1048.wdf.sap.corp> Subject: Re: [TLS] NIST TLS recomendations (PKCS#1 encryption attacks) To: Pasi.Eronen@nokia.com Date: Mon, 27 Nov 2006 21:27:16 +0100 (MET) In-Reply-To: from "Pasi.Eronen@nokia.com" at Nov 27, 6 03:05: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-SAP: out X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: tls@lists.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: > > Note: Attacks discovered by Bleichenbacher [BLEI] and Klima et al. > [KPR03] can be used to attack a TLS server that reveals whether > a particular message, when decrypted, is properly PKCS#1 > formatted, contains a valid PreMasterSecret structure, or has > the correct version number. > > The best way to avoid these vulnerabilities is to treat > incorrectly formatted messages in a manner indistinguishable > from correctly formatted RSA blocks. In other > > 1. Generate a string R of 46 random bytes > > 2. Decrypt the message M > > 3. If the PKCS#1 padding is not correct, or the length of > message M is not exactly 48 bytes: > premaster secret = ClientHello.client_version || R > else If ClientHello.client_version <= TLS 1.0, and > version number check is explicitly disabled: > premaster secret = M > else: > premaster secret = ClientHello.client_version || M[2..47] > > In any case, a TLS server MUST NOT generate an alert if > processing an RSA-encrypted premaster secret message fails, or > the version number is not as expected. Instead, it MUST continue > the handshake with a randomly generated premaster secret. Care > must also be taken to avoid leaking information about the error > situation via log files, or other channels. I once had to analyze a handshake problem with a particular's vendor SSL accellerator (server-side middle-box), where that box contained an error in the RSA encryption and every once in a while sent garbage, i.e. there was no recognizable PKCS#1 padding when RSA-decrypting on the backend server. I was lucky that our SSL implementation did not use the OpenSSL approach, where this kind of error is not only hidden from the peer, but also from the local caller. Completely hiding the decryption failure from the local caller creates a serious supportablility issue, so please be more careful with the recommendation. One should be careful, though, that the local error reporting, which may be as simple as setting an integer value to a particular value, does not result in a measurable timing difference. It is important that the local caller is able to retrieve the real reason why the session establishment failed, not "MAC failure" (as the SSL alert on the wire suggests") but RSA-decryption failure. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 27 15:56:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GonVj-0001Dy-6c; Mon, 27 Nov 2006 15:55:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GonVg-0001Cc-ER for tls@ietf.org; Mon, 27 Nov 2006 15:55:28 -0500 Received: from mga03.intel.com ([143.182.124.21]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GonVA-0002x9-La for tls@ietf.org; Mon, 27 Nov 2006 15:55:28 -0500 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by mga03.intel.com with ESMTP; 27 Nov 2006 12:54:55 -0800 Received: from fmsmsx333.amr.corp.intel.com ([132.233.42.2]) by azsmga001.ch.intel.com with ESMTP; 27 Nov 2006 12:54:52 -0800 X-ExtLoop1: 1 X-IronPort-AV: i="4.09,464,1157353200"; d="scan'208"; a="150898249:sNHT405334209" Received: from hdsmsx412.amr.corp.intel.com ([10.127.2.72]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Nov 2006 12:54:51 -0800 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] Truncated HMAC recommendation Date: Mon, 27 Nov 2006 15:54:48 -0500 Message-ID: <279DDDAFA85EC74C9300A0598E704056FE754D@hdsmsx412.amr.corp.intel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Truncated HMAC recommendation thread-index: AccSWD6j7rsyhSPVR0S9tZ1Cd5YbAQAANmoAAACe5NAAAD5vMA== From: "Blumenthal, Uri" To: X-OriginalArrivalTime: 27 Nov 2006 20:54:51.0994 (UTC) FILETIME=[48C14BA0:01C71266] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 > But if you truncate it to half-length, two > MACs are enough to allow verification of a > guess with high probability. I don't think > this is a significant gain. Cryptologic science disagrees with you.=20 If your MAC size is N bits and your key size is K bits, then you need K/N known pairs of messsage <-> MAC in order to verify your guess of the key (I wonder why you think that just two MACs are enough if you leave only half of the MAC bits). Among other sources, see (page 15). _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 27 16:15:43 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GonoS-0001wY-Ku; Mon, 27 Nov 2006 16:14:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GonoR-0001wE-Aw for tls@ietf.org; Mon, 27 Nov 2006 16:14:51 -0500 Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GonoO-0006Xh-QF for tls@ietf.org; Mon, 27 Nov 2006 16:14:51 -0500 Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id kARLEm5V012289 for ; Mon, 27 Nov 2006 16:14:48 -0500 (EST) Received: from 144.51.60.34 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Mon, 27 Nov 2006 16:14:48 -0500 Received: from EXCH.missi.ncsc.mil ([144.51.60.21]) by gto.missi.ncsc.mil with Microsoft SMTPSVC(5.0.2195.6713); Mon, 27 Nov 2006 16:14:48 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [TLS] Record layer corner cases Date: Mon, 27 Nov 2006 16:14:47 -0500 Message-ID: In-Reply-To: <200611271947.UAA13557@uw1048.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Record layer corner cases Thread-Index: AccSXOZmqXqmrapXSPePoLLD39KLGQABLghA From: "Kemp, David P." To: X-OriginalArrivalTime: 27 Nov 2006 21:14:48.0453 (UTC) FILETIME=[11E67350:01C71269] X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-14840000 X-TM-AS-Result: : Yes--4.296600-0-2-1 X-TM-AS-Category-Info: : 2:0.000000 X-TM-AS-MatchedID: : =?us-ascii?B?MTUwNTY3LTcwMDc4OC03MDE2?= =?us-ascii?B?NTEtNzEwOTkyLTcxMDIwMS03MDA4NzctNzAxMzM0LTcwMTM2OC03?= =?us-ascii?B?MTAzMDAtMTM5MDEwLTcxMDMyMi03MDAxNTEtNzA0NzcxLTcwNzM0?= =?us-ascii?B?NC03MDA1ODYtMTA2NjYwLTcxMDI2NS03MDIxNTYtNzAzMjI1LTcw?= =?us-ascii?B?MDkyNy03MDIwNTEtNzAwODIxLTcxMDI4My03MTA2MTYtNzA5Mjc5?= =?us-ascii?B?LTcwMjc2OS0xMjExMjQtNzAwNzI0LTcwMDIzNy03MTAwNzItNzA1?= =?us-ascii?B?Mjc2LTcwNTA2NS03MDU1OTEtNzAzMjEyLTcwNDc5Mi03MDc5OTct?= =?us-ascii?B?NzAxMTQzLTcwNDY1NC03MDM4MTQtNzA0ODcyLTcwNDAyMi03MDAx?= =?us-ascii?B?NDctNzAyNzY0LTcwMDY4Ni03MDA4MDItNzAxMDc2LTcwMDIyNC03?= =?us-ascii?B?MDEzOTAtMTQ4MDUwLTIwMDQw?= X-Spam-Score: 0.0 (/) 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 We are not discussing weeding out garbage sent by a peer, we are discussing a peer that sends (hypothetically) exactly three certs: root, CA, and EE. The sensible thing to do in such a circumstance is to map the root certificate to a trust anchor: 1) TA -> CA -> EE And in fact, you indicated that that is exactly the observed behavior: > A few years ago, www.verisign.com had been sending > out an expired rootCA certificate in the certification > path of the Server, and curiously, none of the Web Browsers > complained when it had a replacement cert (same > Subject&Issuer, same key, longer validity) in the list > of trust anchors. This discussion is about why the observed behavior is correct. You argue that a TLS receiver should go out of its way to build a second, longer path that contains the root certificate: 2) TA -> Root -> CA -> EE just so it could reject that path, but that is not how either PKI fanciers or TLS implementers intend root certificates to be used. Root certs are *not* part of a certification path, they are convenient containers for conveying trust anchor information, and everything else in them (including signature and validity) can (and should, to minimize load on busy servers) be safely ignored during path validation. Dave -------------------------------------------------- Martin Rex writes: I don't know whether the PKI fanciers have specified this anywhere, but I would consider it seriously braindead if there was such a path validation algorithm. If a path can be built, it must verify. If a path can not be built, it can not be verified and must be ignored. Requiring the receiver to weed our garbage sent by the peer is asking for (interoperability) troubles, and a serious waste of every receives resources (especially for busy servers). -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 27 17:40:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gop8F-0004vg-IL; Mon, 27 Nov 2006 17:39:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gop8E-0004mU-3V for tls@ietf.org; Mon, 27 Nov 2006 17:39:22 -0500 Received: from smtpde01.sap-ag.de ([155.56.68.171]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gop8C-0006Y4-L5 for tls@ietf.org; Mon, 27 Nov 2006 17:39:22 -0500 Received: from sap-ag.de (smtpde01) by smtpde01.sap-ag.de (out) with ESMTP id XAA23838; Mon, 27 Nov 2006 23:39:13 +0100 (MEZ) From: Martin Rex Message-Id: <200611272239.XAA17494@uw1048.wdf.sap.corp> Subject: Re: [TLS] Record layer corner cases To: DPKemp@missi.ncsc.mil (Kemp David P.) Date: Mon, 27 Nov 2006 23:39:12 +0100 (MET) In-Reply-To: from "Kemp, David P." at Nov 27, 6 04:14:47 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: fb6060cb60c0cea16e3f7219e40a0a81 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 Kemp, David P. wrote: > > We are not discussing weeding out garbage sent by a > peer, we are discussing a peer that sends (hypothetically) > exactly three certs: root, CA, and EE. I disagree. This is about weeding out garbage. > > The sensible thing to do in such a circumstance is to > map the root certificate to a trust anchor: > > 1) TA -> CA -> EE > > > This discussion is about why the observed behavior is correct. > > You argue that a TLS receiver should go out of its way to > build a second, longer path that contains the root certificate: > > 2) TA -> Root -> CA -> EE Correct. SSLv3 (and probably TLS as well) supports only a straight forward certification path, and if the local trust anchor happens to be the rootCA cert, then I think it is correct to check that rootCA cert during path validation in case the peer sends it. > > just so it could reject that path, but that is not how either > PKI fanciers or TLS implementers intend root certificates > to be used. Root certs are *not* part of a certification > path, they are convenient containers for conveying trust > anchor information, and everything else in them (including > signature and validity) can (and should, to minimize load > on busy servers) be safely ignored during path validation. >From my experience, Browsers do NOT entirely ignore a rootCA cert sent in the SSL-Server's forward certification chain. On a different occasion we ran into a problem with SSL server certs issued from the GlobalSign RootCA when installed on our AppServer. Web Browsers complained about an invalid certificate (not matching the trust anchor) when connecting. The problem turned out to be that the GlobalSign RootCA cert is not valid ASN.1 DER. Our oem ssl software stores the RootCA (and other trust anchors) in an unparsed format. the signature of one's own rootCA is retained in order to build forward certification pathes that include the rootCA cert, however when reassembling the GlobalSign RootCA cert with correct ASN.1 DER, the signature no longer verifies... And that caused the browsers to complain (I don't remember whether all Browsers complained, and the original customer problem message has been moved to archive from our support system so I can no longer find it). Personally, I dislike text in a specification that will result in different, non-interoperable behaviour. It would be much better if all implementations did the same kind of tests so that interoperability tests become meaningful. In general, security software an protocols should be designed so that they reliably fail if something is incorrect. Every attempt to ignore errors is a security problem waiting to happen, just like planting land-mines -- and should be banned. Ignoring errors is only acceptable when a spec explicitly describes the particular error and provides exact details what to do, so that everyone knows that the designed thought about this problem and the resulting implementations are all going to behave the same way. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 27 18:07:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GopYd-0000vq-5p; Mon, 27 Nov 2006 18:06:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GopYc-0000vb-6A for tls@ietf.org; Mon, 27 Nov 2006 18:06:38 -0500 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GopYZ-00040a-Vo for tls@ietf.org; Mon, 27 Nov 2006 18:06:38 -0500 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 2AEFB9783D for ; Mon, 27 Nov 2006 18:06:53 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id 810CF975E2 for ; Mon, 27 Nov 2006 18:06:52 -0500 (EST) Message-ID: <456B6FE6.7030108@pobox.com> Date: Mon, 27 Nov 2006 15:08:22 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Record layer corner cases References: <200611272239.XAA17494@uw1048.wdf.sap.corp> In-Reply-To: <200611272239.XAA17494@uw1048.wdf.sap.corp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 >> You argue that a TLS receiver should go out of its way to >> build a second, longer path that contains the root certificate: >> >> 2) TA -> Root -> CA -> EE > > Correct. SSLv3 (and probably TLS as well) supports only a straight > forward certification path, and if the local trust anchor happens > to be the rootCA cert, then I think it is correct to check that > rootCA cert during path validation in case the peer sends it. My certificate store (which contains all the trusted certificates) is indexed based on the DER encoding of the certificates, so if a server includes a root certificate in its certification path, it is easily determined to be a trust anchor. So in my case TA == Root and you are left with TA -> CA -> EE. However, this discussion pointed out that I was checking the expiration date of the trust anchor, which apparently is not the right thing to do, so I just eliminated that check. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 27 19:47:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gor6Y-0007mm-Uv; Mon, 27 Nov 2006 19:45:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gor6X-0007mc-HX for tls@ietf.org; Mon, 27 Nov 2006 19:45:45 -0500 Received: from webmail.ntru.com ([64.115.150.147] helo=OHTHREE.jjj-i.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gor6V-000422-1Z for tls@ietf.org; Mon, 27 Nov 2006 19:45:45 -0500 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] Truncated HMAC recommendation Date: Mon, 27 Nov 2006 19:43:55 -0500 Message-ID: <9DC3EBEFB87A97498A7D25F130DE27E49845EC@ohthree.jjj-i.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Truncated HMAC recommendation thread-index: AccSWD6j7rsyhSPVR0S9tZ1Cd5YbAQAANmoAAACe5NAAAD5vMAAKRsqw From: "Whyte, William" To: "Blumenthal, Uri" , X-Spam-Score: 0.1 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 Okay, so I was foolishly assuming that the key size was equal to the non-truncated MAC length. Even given that the key size might be larger, it'll be rare in TLS to require more than 16 (MAC, message) pairs, so I think the broader point (that truncation doesn't significantly raise the bar for an attacker who can collect messages) still holds. William > -----Original Message----- > From: Blumenthal, Uri [mailto:uri.blumenthal@intel.com]=20 > Sent: Monday, November 27, 2006 3:55 PM > To: tls@ietf.org > Subject: RE: [TLS] Truncated HMAC recommendation >=20 > > But if you truncate it to half-length, two > > MACs are enough to allow verification of a > > guess with high probability. I don't think > > this is a significant gain. >=20 > Cryptologic science disagrees with you.=20 >=20 > If your MAC size is N bits and your key size is K bits, then you need > K/N known pairs of messsage <-> MAC in order to verify your=20 > guess of the > key (I wonder why you think that just two MACs are enough if you leave > only half of the MAC bits). Among other sources, see > (page > 15). >=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 Nov 27 20:55:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GosAu-00052Q-GN; Mon, 27 Nov 2006 20:54:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GosAs-00052J-Um for tls@ietf.org; Mon, 27 Nov 2006 20:54:18 -0500 Received: from mailhost.auckland.ac.nz ([130.216.190.13] helo=harpo.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GosAr-0008WD-HO for tls@ietf.org; Mon, 27 Nov 2006 20:54:18 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id 527CD359F2; Tue, 28 Nov 2006 14:54:12 +1300 (NZDT) Received: from harpo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26101-09; Tue, 28 Nov 2006 14:54:12 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id D8CA536065; Tue, 28 Nov 2006 14:54:11 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 7A27F37742; Tue, 28 Nov 2006 14:54:10 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1GosAo-0002xR-00; Tue, 28 Nov 2006 14:54:14 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: DPKemp@missi.ncsc.mil, martin.rex@sap.com, pgut001@cs.auckland.ac.nz Subject: RE: [TLS] Record layer corner cases In-Reply-To: Message-Id: Date: Tue, 28 Nov 2006 14:54:14 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.5 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 "Kemp, David P." writes: >RFC 3280 (and draft 3280bis-05) clearly specify that trust anchors are >maintained out of band, and that trust anchor information does not include a >validity period any other certificate fields except the four listed: At the time this first appeared (in X.509v4 drafts) I did an informal survey of PKI implementors, and exactly *zero* implementors were aware of this sudden change retroactively hacked onto X.509's behaviour. It may be in the spec now, but how many existing implementations do you think will handle this as required? To handle this complete reversal of root cert handling you'd have to more or less tear down everything built in the last 10-15 years and start again. I wonder what the chances of that happening are? (The correct way to handle this change would have been to stipulate the pre- X.509v4 behaviour by default, and then require the presence of some special critical extension to denote the new behaviour. As it stands, the text is little better than random noise for all the effect it'll have on implementors. The horse not only bolted on this one 15 years ago, it's had time to raise entire herds of new horses who aren't going to go back in the barn no matter how hard you slam the door). Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 27 21:01:59 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GosHi-00037u-4X; Mon, 27 Nov 2006 21:01:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GosHg-000374-Qc for tls@ietf.org; Mon, 27 Nov 2006 21:01:20 -0500 Received: from harpo.itss.auckland.ac.nz ([130.216.190.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GosHf-00012J-DX for tls@ietf.org; Mon, 27 Nov 2006 21:01:20 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id CDE3936432; Tue, 28 Nov 2006 15:01:17 +1300 (NZDT) Received: from harpo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26830-35; Tue, 28 Nov 2006 15:01:17 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id 1777C36473; Tue, 28 Nov 2006 15:00:27 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id C1EB037742; Tue, 28 Nov 2006 15:00:27 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1GosGt-000398-00; Tue, 28 Nov 2006 15:00:31 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: home_pw@msn.com, martin.rex@sap.com, pgut001@cs.auckland.ac.nz Subject: RE: [TLS] Record layer corner cases In-Reply-To: Message-Id: Date: Tue, 28 Nov 2006 15:00:31 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.5 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Peter Williams writes: >Out of interest Peter and Martin, how well do your software and hardward >modules handle the following change from SSL v2 to SSL v3, including fallback >handling as specified by SSL3, and then the TLS fallback mechanisms? > >"SSL Version 3 supports the transmission and reception of "out of band data". >Out of band data is normally defined at the TCP/IP protocol level, but >because of SSL's privacy enhancements and support for block ciphers, this >becomes difficult to support. I don't handle it at all, if my code sees OOB data in the middle of a TLS stream it flags it as a network-level error (my security model is default- deny). I've never seen OOB data used and can't imagine why it'd ever be used except as a potential attack vector targetting corner cases in TLS implementations. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 27 21:11:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GosQo-0000zs-8r; Mon, 27 Nov 2006 21:10:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GosQm-0000zn-Vk for tls@ietf.org; Mon, 27 Nov 2006 21:10:44 -0500 Received: from wr-out-0506.google.com ([64.233.184.234]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GosQl-0002fz-PN for tls@ietf.org; Mon, 27 Nov 2006 21:10:44 -0500 Received: by wr-out-0506.google.com with SMTP id i7so457870wra for ; Mon, 27 Nov 2006 18:10:43 -0800 (PST) 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=tFbjDWTWRBanNhEVpmeKL2pqkly9Q51d84C8j0w0PCUYVS0Dm6ve+MlaiCKf81f1A/Cm3gDPrrkawBoteJ6b6iyQ8U4sJBXsqAkdzH8gNATpMIZ0Eq1D4eGeXxr2nHtElV+5y6LfUYOlHKRznTLJpif/FSCsWETPivvVsU+1Wgg= Received: by 10.90.117.15 with SMTP id p15mr366821agc.1164679842473; Mon, 27 Nov 2006 18:10:42 -0800 (PST) Received: by 10.90.70.4 with HTTP; Mon, 27 Nov 2006 18:10:42 -0800 (PST) Message-ID: <6b9359640611271810m673ab64dlb44186bef4306cbe@mail.gmail.com> Date: Mon, 27 Nov 2006 19:10:42 -0700 From: "Kyle Hamilton" To: tls@ietf.org Subject: Re: [TLS] Record layer corner cases In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: 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 On 11/27/06, Peter Gutmann wrote: > I don't handle it at all, if my code sees OOB data in the middle of a TLS > stream it flags it as a network-level error (my security model is default- > deny). I've never seen OOB data used and can't imagine why it'd ever be used > except as a potential attack vector targetting corner cases in TLS > implementations. Evidently you've never used SIGURG, nor seen urgent data sent (that which causes TCP PSH headers to be generated in BSD-type stacks). I'd like to see the discussions from when TCP was designed as to what it was designed to be used for -- it would seem to be for metadata involving the connection. (This is akin to the TLS record protocol being used to request a rehandshake, since the TLS implementation consumes those records.) I would think that such a concept could be useful in modification of the trust parameters associated with the data stream (specifically, notification of revocation or expiration of trust parameters would be a good reason for it). -Kyle H _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Nov 27 21:35:26 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Goso0-0001w1-9B; Mon, 27 Nov 2006 21:34:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gosny-0001rK-Gt for tls@ietf.org; Mon, 27 Nov 2006 21:34:42 -0500 Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gosnw-0008JV-38 for tls@ietf.org; Mon, 27 Nov 2006 21:34:42 -0500 Received: by machshav.com (Postfix, from userid 512) id 74CEAFB4AD; Tue, 28 Nov 2006 02:34:33 +0000 (UTC) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 6FE06FB453; Tue, 28 Nov 2006 02:34:32 +0000 (UTC) Received: by berkshire.machshav.com (Postfix, from userid 54047) id 1B48E3C080B; Mon, 27 Nov 2006 21:34:45 -0500 (EST) Date: Mon, 27 Nov 2006 21:34:44 -0500 From: "Steven M. Bellovin" To: "Kyle Hamilton" Subject: Re: [TLS] Record layer corner cases In-Reply-To: <6b9359640611271810m673ab64dlb44186bef4306cbe@mail.gmail.com> References: <6b9359640611271810m673ab64dlb44186bef4306cbe@mail.gmail.com> Organization: Columbia University X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20061128023445.1B48E3C080B@berkshire.machshav.com> 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 List-Id: "This 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, 27 Nov 2006 19:10:42 -0700 "Kyle Hamilton" wrote: > On 11/27/06, Peter Gutmann wrote: > > > I don't handle it at all, if my code sees OOB data in the middle of > > a TLS stream it flags it as a network-level error (my security > > model is default- deny). I've never seen OOB data used and can't > > imagine why it'd ever be used except as a potential attack vector > > targetting corner cases in TLS implementations. > > Evidently you've never used SIGURG, nor seen urgent data sent (that > which causes TCP PSH headers to be generated in BSD-type stacks). I'd > like to see the discussions from when TCP was designed as to what it > was designed to be used for -- it would seem to be for metadata > involving the connection. (This is akin to the TLS record protocol > being used to request a rehandshake, since the TLS implementation > consumes those records.) > First, that's not what cause the push bit to be set. PSH is set when there's nothing pending to be written. More precisely, it's set to zero when a packet is sent and the stack knows that there's nothing else about to be sent. Here's the comment and code in NetBSD's tcp_output.c: /* * If we're sending everything we've got, set PUSH. * (This will keep happy those implementations which only * give data to the user when a buffer fills or * a PUSH comes in.) */ if (off + len == so->so_snd.sb_cc) flags |= TH_PUSH; Second, and more important, it was intended to be sent when the user had hit BREAK on their ASR-35 Teletypes or ATTN on their IBM 2741s -- see RFC 764. It was part of the "flush all buffers until the urgent pointer" mechanism; TCP Urgent is ill-suited to anything else, since (as is noted in the RFC) multiple urgent pointers pending at the same time are coalesced. The only other place I can recall seeing it used was for window size change notifications in rlogin. Rlogin did not make suitable provision (more accurately, did not make any useful provision) for any sort of connection metadata; the implementors of later versions fell back on TCP Urgent when it became important to do *something*. --Steve 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 Mon Nov 27 21:50:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Got2Z-0002Uf-5u; Mon, 27 Nov 2006 21:49:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Got2X-0002RM-8V for tls@lists.ietf.org; Mon, 27 Nov 2006 21:49:45 -0500 Received: from mailhost-old.auckland.ac.nz ([130.216.190.13] helo=harpo.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Got2V-0004L9-Rg for tls@lists.ietf.org; Mon, 27 Nov 2006 21:49:45 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id A678134A34; Tue, 28 Nov 2006 15:49:39 +1300 (NZDT) Received: from harpo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17945-31; Tue, 28 Nov 2006 15:49:39 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id 9622E36540; Tue, 28 Nov 2006 15:49:09 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 158A337742; Tue, 28 Nov 2006 15:49:09 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1Got21-0003vF-00; Tue, 28 Nov 2006 15:49:13 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: martin.rex@sap.com Subject: Re: [TLS] NIST TLS recomendations (PKCS#1 encryption attacks) In-Reply-To: <200611272027.VAA14146@uw1048.wdf.sap.corp> Message-Id: Date: Tue, 28 Nov 2006 15:49:13 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.5 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: tls@lists.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 Rex writes: >Completely hiding the decryption failure from the local caller creates a >serious supportablility issue, so please be more careful with the >recommendation. Another thing that should really be mentioned in the text (which I've pointed out before) is that the requirement to continue makes for a marvellous DoS attack, just blindly send a string of TLS handshake packets with a garbage value for the RSA-encrypted data and the server has to go through the entire rest of the handshake. In some situations (e.g. low-powered devices) this "defensive" measure may be an own-goal. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 28 06:03:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp0ik-00087d-Ud; Tue, 28 Nov 2006 06:01:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp0ij-00085c-I3 for tls@lists.ietf.org; Tue, 28 Nov 2006 06:01:49 -0500 Received: from moutng.kundenserver.de ([212.227.126.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp0ii-00029l-5R for tls@lists.ietf.org; Tue, 28 Nov 2006 06:01:49 -0500 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu2) with ESMTP (Nemesis), id 0MKwtQ-1Gp0ih0vOW-0007Zj; Tue, 28 Nov 2006 12:01:47 +0100 Received: by tau.invalid (Postfix, from userid 1000) id D5F514D93; Tue, 28 Nov 2006 12:01:46 +0100 (CET) Date: Tue, 28 Nov 2006 12:01:46 +0100 From: Bodo Moeller To: Martin Rex Subject: Re: [TLS] NIST TLS recomendations (PKCS#1 encryption attacks) Message-ID: <20061128110146.GA11403@tau.invalid> References: <200611272027.VAA14146@uw1048.wdf.sap.corp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200611272027.VAA14146@uw1048.wdf.sap.corp> User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: tls@lists.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, Nov 27, 2006 at 09:27:16PM +0100, Martin Rex wrote: > Pasi.Eronen@nokia.com wrote: >> In any case, a TLS server MUST NOT generate an alert if >> processing an RSA-encrypted premaster secret message fails, or >> the version number is not as expected. Instead, it MUST continue >> the handshake with a randomly generated premaster secret. Care >> must also be taken to avoid leaking information about the error >> situation via log files, or other channels. > I once had to analyze a handshake problem with a particular's vendor > SSL accellerator (server-side middle-box), where that box contained > an error in the RSA encryption and every once in a while sent garbage, > i.e. there was no recognizable PKCS#1 padding when RSA-decrypting > on the backend server. I was lucky that our SSL implementation did > not use the OpenSSL approach, where this kind of error is not only > hidden from the peer, but also from the local caller. > > Completely hiding the decryption failure from the local caller > creates a serious supportablility issue, so please be more careful > with the recommendation. [...] "Care must be taken to avoid leaking information" is exactly right. It is true that supressing the detailed error information can be a problem for debugging, but this just means that the standard production setup isn't always adequate for debugging purposes. (E.g. software could have a switch that enables more detailed log file entries that reveal when a padding error was detected.) The problem is that the adversary might have access, however limited, to the server system. Even if the adversary can't actually read the TLS server logfile, we may have an "ls -l" attack if the error messages are of different length for different error cases: merely observing the length of the logfile may allow the adversary to distinguish between different error cases, and thus to perform the attack. You still can record the information if you desire, you just have to thoroughly make sure you don't leak it to the adversary. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 28 06:07:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp0nx-00046R-Qs; Tue, 28 Nov 2006 06:07:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp0nw-00045n-MK for tls@lists.ietf.org; Tue, 28 Nov 2006 06:07:12 -0500 Received: from moutng.kundenserver.de ([212.227.126.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp0nv-0003F7-As for tls@lists.ietf.org; Tue, 28 Nov 2006 06:07:12 -0500 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1Gp0no2HKA-0005RE; Tue, 28 Nov 2006 12:07:05 +0100 Received: by tau.invalid (Postfix, from userid 1000) id DD0BB4D93; Tue, 28 Nov 2006 12:07:03 +0100 (CET) Date: Tue, 28 Nov 2006 12:07:03 +0100 From: Bodo Moeller To: Peter Gutmann Subject: Re: [TLS] NIST TLS recomendations (PKCS#1 encryption attacks) Message-ID: <20061128110703.GB11403@tau.invalid> References: <200611272027.VAA14146@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: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: tls@lists.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 Tue, Nov 28, 2006 at 03:49:13PM +1300, Peter Gutmann wrote: > Another thing that should really be mentioned in the text (which I've pointed > out before) is that the requirement to continue makes for a marvellous DoS > attack, just blindly send a string of TLS handshake packets with a garbage > value for the RSA-encrypted data and the server has to go through the entire > rest of the handshake. In some situations (e.g. low-powered devices) this > "defensive" measure may be an own-goal. Is this relevant? The adversary might just as well send valid RSA-encrypted data (which is quite quickly done for e=65537) to keep the server busy. Even with invalid RSA-encrypted data, the server already has spent considerable effort on RSA decryption when it can finally check the padding -- so it's not as if servers could effortlessly handle the DoD attack that you described without the Bleichenbacher defense. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 28 06:34:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp1Dj-0008Cy-HY; Tue, 28 Nov 2006 06:33:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp1Dh-0008Ct-WA for tls@lists.ietf.org; Tue, 28 Nov 2006 06:33:49 -0500 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp1Dg-0001A5-Hu for tls@lists.ietf.org; Tue, 28 Nov 2006 06:33:49 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kASBWeX9001253; Tue, 28 Nov 2006 13:33:42 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 13:32:41 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 13:32:40 +0200 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] NIST TLS recomendations (PKCS#1 encryption attacks) Date: Tue, 28 Nov 2006 13:32:40 +0200 Message-ID: In-Reply-To: <200611272027.VAA14146@uw1048.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] NIST TLS recomendations (PKCS#1 encryption attacks) Thread-Index: AccSYoPI67x9/wOoRAWRqJGszMG34gAdyFtw From: To: X-OriginalArrivalTime: 28 Nov 2006 11:32:40.0780 (UTC) FILETIME=[E9CC40C0:01C712E0] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: tls@lists.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 Rex wrote: > I once had to analyze a handshake problem with a particular's vendor > SSL accellerator (server-side middle-box), where that box contained > an error in the RSA encryption and every once in a while sent garbage, > i.e. there was no recognizable PKCS#1 padding when RSA-decrypting > on the backend server. I was lucky that our SSL implementation did > not use the OpenSSL approach, where this kind of error is not only > hidden from the peer, but also from the local caller. >=20 > Completely hiding the decryption failure from the local caller > creates a serious supportablility issue, so please be more careful > with the recommendation. One should be careful, though, that the > local error reporting, which may be as simple as setting an integer > value to a particular value, does not result in a measurable timing > difference. It is important that the local caller is able to > retrieve the real reason why the session establishment failed, > not "MAC failure" (as the SSL alert on the wire suggests") but > RSA-decryption failure. I do agree that such debugging features are useful in many=20 circumstances -- but there are other channels than timing that may leak information. How about rephrasing this: "Care must also be taken to avoid leaking information about the error situation via log files, or other channels." as follows: "It may be useful to log the real cause of failure for troubleshooting purposes; however, care must be taken to=20 avoid leaking the information the attacker (though, e.g., timing, log files, or other channels)." Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 28 06:37:25 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp1Ga-00018W-Ni; Tue, 28 Nov 2006 06:36:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp1GY-00012W-Pi for tls@lists.ietf.org; Tue, 28 Nov 2006 06:36:46 -0500 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp1GX-0001sq-Bn for tls@lists.ietf.org; Tue, 28 Nov 2006 06:36:46 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kASBZdlO005824; Tue, 28 Nov 2006 13:36:13 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 13:35:35 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Nov 2006 13:35:35 +0200 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] NIST TLS recomendations (PKCS#1 encryption attacks) Date: Tue, 28 Nov 2006 13:35:35 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] NIST TLS recomendations (PKCS#1 encryption attacks) Thread-Index: AccSq49sfctv1oA7RsyP0EGRWu+gnwANWGVg From: To: X-OriginalArrivalTime: 28 Nov 2006 11:35:35.0115 (UTC) FILETIME=[51B5A9B0:01C712E1] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: tls@lists.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 Peter Gutmann: > Another thing that should really be mentioned in the text (which > I've pointed out before) is that the requirement to continue makes > for a marvellous DoS attack, just blindly send a string of TLS > handshake packets with a garbage value for the RSA-encrypted data > and the server has to go through the entire rest of the handshake. > In some situations (e.g. low-powered devices) this "defensive" > measure may be an own-goal. The most resource-consuming part of the handshake is the RSA decryption, and this we have to do before we can detect any padding errors. So I'm not sure if continuing the handshake really makes the situation any worse DoS-wise... (Especially remembering that we don't have any good alternatives; reporting the error leads to revealing your private key.) Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 28 06:44:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp1Ml-0005cH-7y; Tue, 28 Nov 2006 06:43:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp1Mj-0005cA-Pc for tls@lists.ietf.org; Tue, 28 Nov 2006 06:43:09 -0500 Received: from mailhost.auckland.ac.nz ([130.216.190.14] helo=zeppo.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp1Mi-0003Oe-D4 for tls@lists.ietf.org; Tue, 28 Nov 2006 06:43:09 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id 2C10F3429E; Wed, 29 Nov 2006 00:43:04 +1300 (NZDT) Received: from zeppo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27842-04; Wed, 29 Nov 2006 00:43:04 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id 9E61A36147; Wed, 29 Nov 2006 00:42:08 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 6311537743; Wed, 29 Nov 2006 00:42:08 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1Gp1Lt-0000an-00; Wed, 29 Nov 2006 00:42:17 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: bmoeller@acm.org, pgut001@cs.auckland.ac.nz Subject: Re: [TLS] NIST TLS recomendations (PKCS#1 encryption attacks) In-Reply-To: <20061128110703.GB11403@tau.invalid> Message-Id: Date: Wed, 29 Nov 2006 00:42:17 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.5 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: tls@lists.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 writes: >On Tue, Nov 28, 2006 at 03:49:13PM +1300, Peter Gutmann wrote: >> Another thing that should really be mentioned in the text (which I've pointed >> out before) is that the requirement to continue makes for a marvellous DoS >> attack, just blindly send a string of TLS handshake packets with a garbage >> value for the RSA-encrypted data and the server has to go through the entire >> rest of the handshake. In some situations (e.g. low-powered devices) this >> "defensive" measure may be an own-goal. > >Is this relevant? The adversary might just as well send valid RSA-encrypted >data (which is quite quickly done for e=65537) to keep the server busy. TLS doesn't have any anticlogging mechanism, so all an attacker needs to do is open a socket, write a pre-generated string of TLS client messages, and close the socket again. In the meantime the server has to go through a full TLS handshake to discover that it's just a DoS. This makes that attack it waaaay too asymmetric for my liking... Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 28 06:54:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp1XM-00059g-Ao; Tue, 28 Nov 2006 06:54:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp1XL-00059a-Lr for tls@lists.ietf.org; Tue, 28 Nov 2006 06:54:07 -0500 Received: from anchor-post-35.mail.demon.net ([194.217.242.85]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp1XI-0005kl-Bb for tls@lists.ietf.org; Tue, 28 Nov 2006 06:54:07 -0500 Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.2]) by anchor-post-35.mail.demon.net with esmtp (Exim 4.42) id 1Gp1Wm-0005Xt-HX for tls@lists.ietf.org; Tue, 28 Nov 2006 11:53:41 +0000 Message-ID: <456C2335.8080403@drh-consultancy.demon.co.uk> Date: Tue, 28 Nov 2006 11:53:25 +0000 From: Dr Stephen Henson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] NIST TLS recomendations (PKCS#1 encryption attacks) References: In-Reply-To: X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 Pasi.Eronen@nokia.com wrote: > Peter Gutmann: > >> Another thing that should really be mentioned in the text (which >> I've pointed out before) is that the requirement to continue makes >> for a marvellous DoS attack, just blindly send a string of TLS >> handshake packets with a garbage value for the RSA-encrypted data >> and the server has to go through the entire rest of the handshake. >> In some situations (e.g. low-powered devices) this "defensive" >> measure may be an own-goal. > > The most resource-consuming part of the handshake is the RSA > decryption, and this we have to do before we can detect any padding > errors. So I'm not sure if continuing the handshake really makes the > situation any worse DoS-wise... > > (Especially remembering that we don't have any good alternatives; > reporting the error leads to revealing your private key.) > Does it? I thought a successful attack revealed a premaster secret, not the actual private key. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 28 07:23:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp1yK-0002Zw-OR; Tue, 28 Nov 2006 07:22:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp1yI-0002Wd-SE for tls@ietf.org; Tue, 28 Nov 2006 07:21:58 -0500 Received: from moutng.kundenserver.de ([212.227.126.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp1xt-0004Hn-Az for tls@ietf.org; Tue, 28 Nov 2006 07:21:34 -0500 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu0) with ESMTP (Nemesis), id 0MKwh2-1Gp1xl42Ep-0001KK; Tue, 28 Nov 2006 13:21:27 +0100 Received: by tau.invalid (Postfix, from userid 1000) id 6A2004D93; Tue, 28 Nov 2006 13:21:25 +0100 (CET) Date: Tue, 28 Nov 2006 13:21:25 +0100 From: Bodo Moeller To: Peter Gutmann Subject: Re: [TLS] Record layer corner cases Message-ID: <20061128122125.GC11403@tau.invalid> 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: bb8f917bb6b8da28fc948aeffb74aa17 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 Tue, Nov 28, 2006 at 03:00:31PM +1300, Peter Gutmann wrote: > Peter Williams writes: >> Out of interest Peter and Martin, how well do your software and hardward >> modules handle the following change from SSL v2 to SSL v3, including fallback >> handling as specified by SSL3, and then the TLS fallback mechanisms? >> >> "SSL Version 3 supports the transmission and reception of "out of band data". >> Out of band data is normally defined at the TCP/IP protocol level, but >> because of SSL's privacy enhancements and support for block ciphers, this >> becomes difficult to support. > I don't handle it at all, if my code sees OOB data in the middle of a TLS > stream it flags it as a network-level error (my security model is default- > deny). I've never seen OOB data used and can't imagine why it'd ever be used > except as a potential attack vector targetting corner cases in TLS > implementations. The above quote is from the SSL patent, which does mention "SSL Version 3" -- but it's not really about what we know as SSL 3.0, it only describes the SSL 2 protocol design. The patent says that "currently there are several versions of the novel SSL", and there the "novel SSL" is what we know as SSL 2 and variants thereof. What eventually was fielded as SSL 3.0 is, of course, a very different protocol. The SSL 2 protocol design provides for a "security escape" flag in record headers ("reserved for future versions of the protocol"), which would be used to tag out-of-band data. That and now TCP-leve out-of-band data is what the above patent text is talking about. (As noted there, handling TCP out-of-band data would be difficult within SSL.) Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 28 07:24:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp1zv-0003aN-7b; Tue, 28 Nov 2006 07:23:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp1zu-0003a7-FW for tls@lists.ietf.org; Tue, 28 Nov 2006 07:23:38 -0500 Received: from moutng.kundenserver.de ([212.227.126.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp1zr-0004sL-QO for tls@lists.ietf.org; Tue, 28 Nov 2006 07:23:38 -0500 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu4) with ESMTP (Nemesis), id 0ML21M-1Gp1zq1gmQ-0005KI; Tue, 28 Nov 2006 13:23:35 +0100 Received: by tau.invalid (Postfix, from userid 1000) id 0C1014D93; Tue, 28 Nov 2006 13:23:34 +0100 (CET) Date: Tue, 28 Nov 2006 13:23:33 +0100 From: Bodo Moeller To: Peter Gutmann Subject: Re: [TLS] NIST TLS recomendations (PKCS#1 encryption attacks) Message-ID: <20061128122333.GD11403@tau.invalid> References: <20061128110703.GB11403@tau.invalid> 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: 2409bba43e9c8d580670fda8b695204a Cc: tls@lists.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, Nov 29, 2006 at 12:42:17AM +1300, Peter Gutmann wrote: > Bodo Moeller writes: >> On Tue, Nov 28, 2006 at 03:49:13PM +1300, Peter Gutmann wrote: >>> Another thing that should really be mentioned in the text (which I've pointed >>> out before) is that the requirement to continue makes for a marvellous DoS >>> attack, just blindly send a string of TLS handshake packets with a garbage >>> value for the RSA-encrypted data and the server has to go through the entire >>> rest of the handshake. In some situations (e.g. low-powered devices) this >>> "defensive" measure may be an own-goal. >> Is this relevant? The adversary might just as well send valid RSA-encrypted >> data (which is quite quickly done for e=65537) to keep the server busy. > TLS doesn't have any anticlogging mechanism, so all an attacker needs to do is > open a socket, write a pre-generated string of TLS client messages, and close > the socket again. In the meantime the server has to go through a full TLS > handshake to discover that it's just a DoS. This makes that attack it waaaay > too asymmetric for my liking... Yes, I understand that -- what I meant is, would it significantly help not to have to do the Bleichenbacher countermeasure? I don't think so, because even without the countermeasure the same attack could easily keep the server very busy. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 28 07:29:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp250-0007x9-G6; Tue, 28 Nov 2006 07:28:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp24y-0007tZ-SY for tls@lists.ietf.org; Tue, 28 Nov 2006 07:28:52 -0500 Received: from moutng.kundenserver.de ([212.227.126.183]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp24x-0005zK-G7 for tls@lists.ietf.org; Tue, 28 Nov 2006 07:28:52 -0500 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu5) with ESMTP (Nemesis), id 0ML25U-1Gp24s34o4-0003GV; Tue, 28 Nov 2006 13:28:47 +0100 Received: by tau.invalid (Postfix, from userid 1000) id 5505A4D93; Tue, 28 Nov 2006 13:28:46 +0100 (CET) Date: Tue, 28 Nov 2006 13:28:46 +0100 From: Bodo Moeller To: Dr Stephen Henson Subject: Re: [TLS] NIST TLS recomendations (PKCS#1 encryption attacks) Message-ID: <20061128122846.GE11403@tau.invalid> References: <456C2335.8080403@drh-consultancy.demon.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <456C2335.8080403@drh-consultancy.demon.co.uk> User-Agent: Mutt/1.5.9i X-Provags-ID: kundenserver.de abuse@kundenserver.de login:2100a517a32aea841b51dac1f7c5a318 X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: tls@lists.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 Tue, Nov 28, 2006 at 11:53:25AM +0000, Dr Stephen Henson wrote: > Pasi.Eronen@nokia.com wrote: >> The most resource-consuming part of the handshake is the RSA >> decryption, and this we have to do before we can detect any padding >> errors. So I'm not sure if continuing the handshake really makes the >> situation any worse DoS-wise... >> >> (Especially remembering that we don't have any good alternatives; >> reporting the error leads to revealing your private key.) > Does it? I thought a successful attack revealed a premaster secret, not > the actual private key. True: the attack allows an adversary to *use* you private key, but not to *obtain* it. (No-one knows for sure if an oracle that computes e-th roots modulo some composite integer n, which is what RSA decryption does, can be used to obtain the inverse of e modulo phi(n) or -- equivalently -- to factor n. Thus, there is no known algorithm to use an RSA decryption oracle, such as the one involved in the Bleichenbacher attack, to obtain the private RSA key.) Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 28 08:27:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp2yr-0004Qf-20; Tue, 28 Nov 2006 08:26:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp2yq-0004QZ-3Q for tls@ietf.org; Tue, 28 Nov 2006 08:26:36 -0500 Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp2yn-000289-Oe for tls@ietf.org; Tue, 28 Nov 2006 08:26:36 -0500 Received: by machshav.com (Postfix, from userid 512) id 65CBCFB3DD; Tue, 28 Nov 2006 13:26:33 +0000 (UTC) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 5A4F6FB3B8; Tue, 28 Nov 2006 13:26:31 +0000 (UTC) Received: by berkshire.machshav.com (Postfix, from userid 54047) id 7D2D23C0318; Tue, 28 Nov 2006 08:26:15 -0500 (EST) Date: Tue, 28 Nov 2006 08:26:15 -0500 From: "Steven M. Bellovin" To: Subject: Re: [TLS] NIST TLS recomendations (PKCS#1 encryption attacks) In-Reply-To: References: Organization: Columbia University X-Mailer: Sylpheed-Claws 2.6.0 (GTK+ 2.8.20; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-Id: <20061128132615.7D2D23C0318@berkshire.machshav.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 Tue, 28 Nov 2006 13:35:35 +0200 wrote: > Peter Gutmann: > > > Another thing that should really be mentioned in the text (which > > I've pointed out before) is that the requirement to continue makes > > for a marvellous DoS attack, just blindly send a string of TLS > > handshake packets with a garbage value for the RSA-encrypted data > > and the server has to go through the entire rest of the handshake. > > In some situations (e.g. low-powered devices) this "defensive" > > measure may be an own-goal. > > The most resource-consuming part of the handshake is the RSA > decryption, and this we have to do before we can detect any padding > errors. So I'm not sure if continuing the handshake really makes the > situation any worse DoS-wise... > If we want to deal with DoS attacks at that layer, we could standardize the Dean/Stubblefield TLS client puzzle scheme. --Steve 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 Tue Nov 28 10:01:04 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp4R4-0000v6-3y; Tue, 28 Nov 2006 09:59:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp4R2-0000qv-Vv for tls@ietf.org; Tue, 28 Nov 2006 09:59:48 -0500 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp4R1-0003GC-KA for tls@ietf.org; Tue, 28 Nov 2006 09:59:48 -0500 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id PAA04379; Tue, 28 Nov 2006 15:55:54 +0100 (MEZ) From: Martin Rex Message-Id: <200611281455.PAA29110@uw1048.wdf.sap.corp> Subject: Re: [TLS] Record layer corner cases To: home_pw@msn.com (Peter Williams) Date: Tue, 28 Nov 2006 15:55:51 +0100 (MET) In-Reply-To: from "Peter Williams" at Nov 27, 6 09:46:51 am 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: 9182cfff02fae4f1b6e9349e01d62f32 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 Peter Williams wrote: > > Out of interest Peter and Martin, how well do your software and hardward > modules handle the following change from SSL v2 to SSL v3, including > fallback handling as specified by SSL3, and then the TLS fallback > mechanisms? > > "SSL Version 3 supports the transmission and reception of "out of band > data". Out of band data is normally defined at the TCP/IP protocol level, > but because of SSL's privacy enhancements and support for block ciphers, > this becomes difficult to support. That might be an issue for a generic SSL/TLS toolkit and/or a vendor implementor thereof. My employer sells applications and includes an OEM sslv3 implementation which is used almost exclusively for HTTPS. I'm not aware that HTTPS specifies a usage of TCP OOB data--and the document that comes closest to a spec for HTTPS (rfc2818) does not seem to contain the words "urgent", "out of band" and "OOB". It might be useful to check whether OOB data has any negative unexpected side-effects (aka vulnerabilities) besides causing the communication channel to be closed. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 28 10:33:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp4wV-0005Kj-BQ; Tue, 28 Nov 2006 10:32:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp4wT-0005Kc-KH for tls@ietf.org; Tue, 28 Nov 2006 10:32:17 -0500 Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp4wM-0003UZ-TS for tls@ietf.org; Tue, 28 Nov 2006 10:32:17 -0500 Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id kASFW95V012982 for ; Tue, 28 Nov 2006 10:32:09 -0500 (EST) Received: from 144.51.60.34 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Tue, 28 Nov 2006 10:32:09 -0500 Received: from EXCH.missi.ncsc.mil ([144.51.60.19]) by gto.missi.ncsc.mil with Microsoft SMTPSVC(5.0.2195.6713); Tue, 28 Nov 2006 10:32:08 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [TLS] Record layer corner cases Date: Tue, 28 Nov 2006 10:32:08 -0500 Message-ID: In-Reply-To: <200611272239.XAA17494@uw1048.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Record layer corner cases Thread-Index: AccSdODX2T7ByeuzRuq6uZauQp0MVwAfXLcA From: "Kemp, David P." To: X-OriginalArrivalTime: 28 Nov 2006 15:32:08.0990 (UTC) FILETIME=[5DEB1BE0:01C71302] X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-14840003 X-TM-AS-Result: : Yes--1.891300-0-31-1 X-TM-AS-Category-Info: : 31:0.000000 X-TM-AS-MatchedID: : =?us-ascii?B?MTUwNTY3LTcwMTE0My03MDE4?= =?us-ascii?B?NjctMTEzMjgzLTcwMTY1MS03MDA2NzAtNzAwNTUxLTcxMDMwMC03?= =?us-ascii?B?MDE0MjQtNzAxMzM0LTcwNzM0NC03MDM3MTgtNzAwNjI3LTcwMDc4?= =?us-ascii?B?OC03MDE4NTYtNzA1NjQ2LTcwMTU4Mi03MDkyNzktNzEwMjgzLTcx?= =?us-ascii?B?MDI2NS0xMjExMDEtNzAwMjAyLTcwODMwMi0xMjE2MjgtNzA5NjE5?= =?us-ascii?B?LTcwMTA2NS03MTA5OTItNzA0OTM3LTcwMDYyNi03MDU1NDItNzAy?= =?us-ascii?B?NzA0LTcwMjEwMy03MDc3NDgtNzAzMDc2LTcwMDc5Mi03MDEwNDMt?= =?us-ascii?B?NzAxMTcyLTcxMDMyNC03MDExNDktNzExMDAxLTcwMDU4Ni03MDI2?= =?us-ascii?B?OTItNzAwNTU0LTcxMDc2OC03MDg0OTktNzA0MTcwLTcxMjA2MS03?= =?us-ascii?B?MDMyMTItNzEyMzIwLTcwNDY1NC0xMzkwMTAtNzAyNzM4LTcwMTI5?= =?us-ascii?B?MS03MDk3NTctNzAwODIxLTcwMDc1NC03MTIxOTYtNzAwMTMwLTcw?= =?us-ascii?B?MzcwNS03MTAwNzItNzAyNjQxLTcwNDUxNy03MDEzODQtNzA5OTc5?= =?us-ascii?B?LTcwMTI5NS03MTIzMTMtNzAzMDk2LTcwMTgxNy03MDExNjktNzAy?= =?us-ascii?B?MzY1LTcwMzA5Ny03MDA3ODktNzEwMzczLTcwMzMxNC03MDMwNzEt?= =?us-ascii?B?NzExMDY2LTcwNTI3Ni03MDUwNjUtNzAwMTUxLTEyMTY0OC03MDc1?= =?us-ascii?B?MDUtNzAyNjI3LTcwMzk0MS0xMDY1ODAtNzAwNDQxLTExMzIyOS0x?= =?us-ascii?B?MjExMjUtNzA1MDM5LTcwMDkwMi03MDUwMjAtMTQ4MDUwLTIwMDQw?= X-Spam-Score: 0.0 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 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 There is fortunately a difference between errors that are security land mines waiting to explode, and differences in interpretation that do not lead to security errors. Assume that the world view and behavior described in X.509 and RFC 3280 (root certs map to TAs) is called Type A, and the behavior you describe (root certs both map to TAs and are evaluated during path validation) is called Type B. Assume that there is a mix of Type A and Type B sender and receiver implementations on the Internet. Assume that a CA (call it GloboSign, with apologies to the movie Dodgeball) chooses to publish two root certificates for its single root signing key, one expiring in 1900 (RootA) and the other expiring in 2050 (RootB) in order to cater to both types of customers. Type A senders include RootA, CA, EE in their paths. Type B senders include RootB, CA, EE in their paths. Type A receivers validate TA -> CA -> EE. Type B receivers validate TA -> Root(x) -> CA -> EE. I contend that the Type B receivers are impacting both their own performance (by checking 50% more signatures than necessary) and their own interoperability (by unnecessarily rejecting connections from Type A senders) without gaining an ounce of security. If there is an undetected compromise of GloboSign's root key, then validating the RootB certificate will not prevent a rogue CA from being validated. If the compromise is detected and receivers of both types change their GloboSign TA keys, then CA certs signed with the compromised root key will be rejected regardless of whether the root cert is validated. Simplicity is one form of security goodness. A web site that chooses to purchase a Type A web server will gain 1) standards compliance with X.509 and PKIX, 2) performance (by eliminating unnecessary cert validations), and 3) interoperability with both Type A and Type B browsers. A web site that purchases a Type B server loses performance and interoperability with Type A browsers (when doing client auth) and gains nothing in security. I too dislike ambiguity in specifications. The text in RFC 3280 is unambiguous about what constitutes TA information (and you do not disagree with that definition). And according to you, the TLS spec calls for the same decision that a Type A receiver would render, without specifying an algorithm for reaching that decision: > TLSv1 improved the situation, indicating that the > path may or may not contain a rootCA (=3Dself-signed) > cert, and mentioned that such a cert, if present, > should not have an impact on the decision whether > the peer's certificate is trusted. It would appear that the PKIX and TLS standards are unambiguous and in agreement with each other in specifying Type A behavior, and that horses that refuse to drink when led to water are hurting only themselves. Dave P.S. If you can come up with an example combination of circumstances where Type B behavior would have a security advantage over Type A, I'd listen. But vague references to not checking errors and land mines are not persuasive. The ASN.1 reconstruction example you cite is an argument in favor of Type A. The only case I can think of is a Type A sender (expired root cert) with a Type B receiver (root cert checked) and an undetected root key compromise (TA not replaced, rogue CA cert signed by adversary). In that case a Type B receiver stumbles onto the right decision, but since Type B always rejects Type A connections regardless of whether the root is compromised, that's like saying a stopped perpetual clock/calendar is right once a millennium. -------------------- From: Martin Rex [mailto:martin.rex@sap.com]=20 Personally, I dislike text in a specification that will result in different, non-interoperable behaviour. It would be much better if all implementations did the same kind of tests so that interoperability tests become meaningful. In general, security software an protocols should be designed so that they reliably fail if something is incorrect. Every attempt to ignore errors is a security problem waiting to happen, just like planting land-mines -- and should be banned. -Martin -------------------- From: pgut001 [mailto:pgut001@cs.auckland.ac.nz]=20 At the time this first appeared (in X.509v4 drafts) I did an informal survey of PKI implementors, and exactly *zero* implementors were aware of this sudden change retroactively hacked onto X.509's behaviour. It may be in the spec now, but how many existing implementations do you think will handle this as required? To handle this complete reversal of root cert handling you'd have to more or less tear down everything built in the last 10-15 years and start again. I wonder what the chances of that happening are? Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 28 15:37:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp9fS-0002YP-JJ; Tue, 28 Nov 2006 15:35:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gp9fS-0002YJ-67 for tls@lists.ietf.org; Tue, 28 Nov 2006 15:35:02 -0500 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gp9fN-0001SF-Ks for tls@lists.ietf.org; Tue, 28 Nov 2006 15:35:02 -0500 Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id kASKYSFA030665 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 28 Nov 2006 21:34:29 +0100 Resent-To: tls@lists.ietf.org Resent-From: Simon Josefsson Resent-Date: Tue, 28 Nov 2006 21:34:28 +0100 Resent-Message-ID: <87bqmrmht7.fsf@latte.josefsson.org> X-Hashcash: 1:22:061126:tls@lists.ietf.org::985X3Ic3h9+Ps4qz:3++p From: Simon Josefsson To: tls@lists.ietf.org OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Date: Sun, 26 Nov 2006 12:37:59 +0100 Message-ID: <87hcwmtp48.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.2 required=4.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=unavailable version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.6 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Subject: [TLS] Two notes on TLS 1.2 after implementing it in GnuTLS 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: , Sender: tls-bounces@lists.ietf.org Errors-To: tls-bounces@lists.ietf.org Resent-Date: Tue, 28 Nov 2006 15:35:02 -0500 Hello. I have implemented TLS 1.2 in GnuTLS following draft-ietf-tls-rfc4346-bis-02.txt. I was able to connect successfully to https://www.mikestoolbox.net:4433/ (thanks Mike!) so I believe my implementation is ready enough that I can write down some of my thoughts on the draft. 1. It would have reduced implementation time if there were a list of protocol syntax changes. For example, it took me some debugging to understand that CertificateRequest was modified from (RFC 4346): struct { ClientCertificateType certificate_types<1..2^8-1>; DistinguishedName certificate_authorities<0..2^16-1>; } CertificateRequest; into struct { ClientCertificateType certificate_types<1..2^8-1>; HashType certificate_hash<1..2^8-1>; DistinguishedName certificate_authorities<0..2^16-1>; } CertificateRequest; In general I recommend to add new fields to the end of a structure instead of in the middle of it. It makes version-aware parsers cleaner. 2. The modification to change RSA signing was to change: In RSA signing, a 36-byte structure of two hashes (one SHA and one MD5) is signed (encrypted with the private key). It is encoded with PKCS #1 block type 1, as described in [PKCS1A]. into: In RSA signing, the output of the chosen hash function is encoded as a PKCS #1 DigestInfo and then signed using block type 01 as described in Section 8.1 as described in [PKCS1A]. This could be improved with some helpful discussion to guide implementers. PKCS1A is under-specified and even incorrect here. Is there a reason we don't reference PKCS1B here? DigestInfo mis-handling was the cause of the recent bugs that affected OpenSSL, Mozilla NSS, GnuTLS and several proprietary TLS libraries for X.509 signature validations. It would be unfortunate if TLS 1.2 introduce the same problem into TLS itself. The problems with PKCS1A are: 1) It uses BER encoding, when PKCS1B correctly changed this to DER. 2) It doesn't specify whether the parameters field should be NULL or omitted for non-MD2/MD4/MD5 algorithms. I don't think there is any controversy around 1). DER should be used. Whether to use a DigestInfo.AlgorithmIdentifier.parameters field that is NULL or omitted seems somewhat problematic. PKCS1A says regarding MD2/MD4/MD5: For these object identifiers, the parameters field of the digestAlgorithm value should be NULL. It doesn't say anything about other hashes. PKCS1B says: The parameters field associated with id-sha1, id-sha256, id-sha384, and id-sha512 should be omitted, but if present, shall have a value of type NULL. However the example in PKCS1B uses NULL: SHA-1: (0x)30 21 30 09 06 05 2b 0e 03 02 1a 05 00 04 14 || H. Further, appendix H of PKCS1B contains additional discussions: * The requirement that the parameters in an AlgorithmIdentifier value for id-sha1, id-sha256, id-sha384, and id-sha512 be NULL was changed to a recommendation that the parameters be omitted (while still allowing the parameters to be NULL). This is to align with the definitions originally promulgated by NIST. Implementations MUST accept AlgorithmIdentifier values both without parameters and with NULL parameters. I note that Mike's server required a NULL here. I initially didn't send one, my ASN.1 library computed a DER encoding with an omitted parameters field. For reference, that DER code is: SHA-1: 30 1f 30 07 06 05 2b 0e 03 02 1a 04 14 || H Mike's server didn't accept this. This will leads to interoperability problems with TLS 1.2 unless the specification is more explicit about the problem. I suggest adding after this paragraph: In RSA signing, the output of the chosen hash function is encoded as a PKCS #1 DigestInfo and then signed using block type 01 as described in Section 8.1 as described in [PKCS1A]. This new paragraph: As discussed in [PKCS1B], the DigestInfo MUST be DER encoded and for digest algorithms without parameters (which include SHA-1) the DigestInfo.AlgorithmIdentifier.parameters field SHOULD be omitted but implementations MUST accept both without parameters and with NULL parameters. Other text instead would be fine, but I strongly believe that this problem should be mentioned explicitly because we have seen that it has serious failure modes (false positives in RSA signature verification). For the record, I wouldn't have any problem with saying that the parameters field MUST be omitted -- the fewer choices the better. However, that would be a taking things a bit further than PKCS1B. Thanks, Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 28 17:57:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpBsS-0004nH-FY; Tue, 28 Nov 2006 17:56:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpBsR-0004mH-PO for tls@lists.ietf.org; Tue, 28 Nov 2006 17:56:35 -0500 Received: from smtpde03.sap-ag.de ([155.56.68.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpBsQ-000111-E3 for tls@lists.ietf.org; Tue, 28 Nov 2006 17:56:35 -0500 Received: from sap-ag.de (smtpde03) by smtpde03.sap-ag.de (out) with ESMTP id XAA27360; Tue, 28 Nov 2006 23:52:33 +0100 (MEZ) From: Martin Rex Message-Id: <200611282252.XAA06938@uw1048.wdf.sap.corp> Subject: Re: [TLS] NIST TLS recomendations (PKCS#1 encryption attacks) To: Pasi.Eronen@nokia.com Date: Tue, 28 Nov 2006 23:52:32 +0100 (MET) In-Reply-To: from "Pasi.Eronen@nokia.com" at Nov 28, 6 01:32:40 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: 7655788c23eb79e336f5f8ba8bce7906 Cc: tls@lists.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 do agree that such debugging features are useful in many > circumstances -- but there are other channels than timing > that may leak information. How about rephrasing this: > > "Care must also be taken to avoid leaking information about > the error situation via log files, or other channels." > > as follows: > > "It may be useful to log the real cause of failure for > troubleshooting purposes; however, care must be taken to > avoid leaking the information the attacker (though, e.g., > timing, log files, or other channels)." Fine with me. ... the information to an attacker ... maybe. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 28 22:56:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpGWX-0004Ve-CB; Tue, 28 Nov 2006 22:54:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpGWV-0004VT-Kd for tls@ietf.org; Tue, 28 Nov 2006 22:54:15 -0500 Received: from wx-out-0506.google.com ([66.249.82.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpGWU-00080x-9F for tls@ietf.org; Tue, 28 Nov 2006 22:54:15 -0500 Received: by wx-out-0506.google.com with SMTP id h27so2221509wxd for ; Tue, 28 Nov 2006 19:54:14 -0800 (PST) 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=qPwMaLJIEII/e7dFHQVw0upW1yVjHVgKcJQDTtTVyOlnritlTVfIIqc/tUTsSDS8dRM2Ao8hUFZvg0dwz1w/fCeN2O8cv9qCl9XRHVJ4OiPl+kU7EYcf5QA7H9v/abz+E2H+2//Nci6Bpupr9swiMS7FjSg64mlfTAcsPhdWqAE= Received: by 10.90.75.10 with SMTP id x10mr1832663aga.1164772453910; Tue, 28 Nov 2006 19:54:13 -0800 (PST) Received: by 10.90.70.4 with HTTP; Tue, 28 Nov 2006 19:54:13 -0800 (PST) Message-ID: <6b9359640611281954v20f1b3b5xad05986751e15281@mail.gmail.com> Date: Tue, 28 Nov 2006 20:54:13 -0700 From: "Kyle Hamilton" To: "Kemp, David P." Subject: Re: [TLS] Record layer corner cases In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200611272239.XAA17494@uw1048.wdf.sap.corp> X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f 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 A TA that creates a CA identification/authentication certificate in the correct format (including proper date handling) is much more likely to create other certificates in the correct format, and thus NOT create issues in ASN.1 parsing. Various ASN.1 parsers have had security vulnerabilities that came to light. -Kyle H On 11/28/06, Kemp, David P. wrote: > > > There is fortunately a difference between errors that are security > land mines waiting to explode, and differences in interpretation > that do not lead to security errors. > > Assume that the world view and behavior described in X.509 and > RFC 3280 (root certs map to TAs) is called Type A, and the behavior > you describe (root certs both map to TAs and are evaluated during > path validation) is called Type B. Assume that there is a mix > of Type A and Type B sender and receiver implementations on the > Internet. Assume that a CA (call it GloboSign, with apologies > to the movie Dodgeball) chooses to publish two root certificates > for its single root signing key, one expiring in 1900 (RootA) > and the other expiring in 2050 (RootB) in order to cater to > both types of customers. > > Type A senders include RootA, CA, EE in their paths. > Type B senders include RootB, CA, EE in their paths. > Type A receivers validate TA -> CA -> EE. > Type B receivers validate TA -> Root(x) -> CA -> EE. > > I contend that the Type B receivers are impacting both their > own performance (by checking 50% more signatures than necessary) > and their own interoperability (by unnecessarily rejecting > connections from Type A senders) without gaining an ounce > of security. If there is an undetected compromise of > GloboSign's root key, then validating the RootB certificate > will not prevent a rogue CA from being validated. If > the compromise is detected and receivers of both types > change their GloboSign TA keys, then CA certs signed with > the compromised root key will be rejected regardless of whether > the root cert is validated. > > Simplicity is one form of security goodness. A web site > that chooses to purchase a Type A web server will gain > 1) standards compliance with X.509 and PKIX, 2) performance > (by eliminating unnecessary cert validations), and > 3) interoperability with both Type A and Type B browsers. > A web site that purchases a Type B server loses performance > and interoperability with Type A browsers (when doing > client auth) and gains nothing in security. > > I too dislike ambiguity in specifications. The text > in RFC 3280 is unambiguous about what constitutes TA > information (and you do not disagree with that definition). > And according to you, the TLS spec calls for the same > decision that a Type A receiver would render, without > specifying an algorithm for reaching that decision: > > > TLSv1 improved the situation, indicating that the > > path may or may not contain a rootCA (=self-signed) > > cert, and mentioned that such a cert, if present, > > should not have an impact on the decision whether > > the peer's certificate is trusted. > > It would appear that the PKIX and TLS standards are > unambiguous and in agreement with each other in specifying > Type A behavior, and that horses that refuse to drink > when led to water are hurting only themselves. > > Dave > > P.S. If you can come up with an example combination of > circumstances where Type B behavior would have a > security advantage over Type A, I'd listen. But vague > references to not checking errors and land mines are > not persuasive. The ASN.1 reconstruction example > you cite is an argument in favor of Type A. > The only case I can think of is a Type A sender > (expired root cert) with a Type B receiver (root > cert checked) and an undetected root key compromise > (TA not replaced, rogue CA cert signed by adversary). > In that case a Type B receiver stumbles onto the > right decision, but since Type B always rejects > Type A connections regardless of whether the root > is compromised, that's like saying a stopped perpetual > clock/calendar is right once a millennium. > > > -------------------- > From: Martin Rex [mailto:martin.rex@sap.com] > > Personally, I dislike text in a specification that will result > in different, non-interoperable behaviour. It would be much > better if all implementations did the same kind of tests so > that interoperability tests become meaningful. > > In general, security software an protocols should be designed > so that they reliably fail if something is incorrect. Every > attempt to ignore errors is a security problem waiting to happen, > just like planting land-mines -- and should be banned. > > -Martin > > -------------------- > From: pgut001 [mailto:pgut001@cs.auckland.ac.nz] > > At the time this first appeared (in X.509v4 drafts) I did an informal > survey > of PKI implementors, and exactly *zero* implementors were aware of this > sudden > change retroactively hacked onto X.509's behaviour. It may be in the > spec > now, but how many existing implementations do you think will handle this > as > required? To handle this complete reversal of root cert handling you'd > have > to more or less tear down everything built in the last 10-15 years and > start > again. I wonder what the chances of that happening are? > > Peter. > > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls > -- -Kyle H _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 28 23:01:14 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpGce-0000Xx-QR; Tue, 28 Nov 2006 23:00:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpGcd-0000Wi-VB for tls@lists.ietf.org; Tue, 28 Nov 2006 23:00:35 -0500 Received: from mailhost.auckland.ac.nz ([130.216.190.13] helo=harpo.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpGcc-0000gC-IX for tls@lists.ietf.org; Tue, 28 Nov 2006 23:00:35 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id 213D234D4C; Wed, 29 Nov 2006 17:00:30 +1300 (NZDT) Received: from harpo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpc.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31410-03; Wed, 29 Nov 2006 17:00:30 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by harpo.itss.auckland.ac.nz (Postfix) with ESMTP id 8BD2A344B5; Wed, 29 Nov 2006 17:00:29 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id E731937742; Wed, 29 Nov 2006 17:00:28 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1GpGcb-0002Cw-00; Wed, 29 Nov 2006 17:00:33 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: DPKemp@missi.ncsc.mil, pgut001@cs.auckland.ac.nz Subject: RE: [TLS] Record layer corner cases In-Reply-To: Message-Id: Date: Wed, 29 Nov 2006 17:00:33 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.5 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: tls@lists.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 "Kemp, David P." writes: >Apparently, the browser vendors referred to below have been busy tearing down >and rebuilding. More likely they never checked in the first place, and this just appears to work by coincidence. Perhaps we could ask the browser folks, a few of them read this list: Did you consciously implement the X.509v4 changes to trust anchor handling in your code within the last year or two? Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Nov 28 23:24:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpGzT-0005rR-4q; Tue, 28 Nov 2006 23:24:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpGzS-0005nl-4K for tls@lists.ietf.org; Tue, 28 Nov 2006 23:24:10 -0500 Received: from mailhost.auckland.ac.nz ([130.216.190.14] helo=zeppo.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpGzQ-0004oK-Nj for tls@lists.ietf.org; Tue, 28 Nov 2006 23:24:10 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id B2A1F33F9E; Wed, 29 Nov 2006 17:24:06 +1300 (NZDT) Received: from zeppo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 03649-10; Wed, 29 Nov 2006 17:24:06 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id 809A233EFC; Wed, 29 Nov 2006 17:24:06 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 3428737742; Wed, 29 Nov 2006 17:24:06 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1GpGzT-0002Z5-00; Wed, 29 Nov 2006 17:24:11 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: bmoeller@acm.org, pgut001@cs.auckland.ac.nz Subject: Re: [TLS] NIST TLS recomendations (PKCS#1 encryption attacks) In-Reply-To: <20061128122333.GD11403@tau.invalid> Message-Id: Date: Wed, 29 Nov 2006 17:24:11 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.5 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: tls@lists.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 writes: >On Wed, Nov 29, 2006 at 12:42:17AM +1300, Peter Gutmann wrote: >> TLS doesn't have any anticlogging mechanism, so all an attacker needs to do is >> open a socket, write a pre-generated string of TLS client messages, and close >> the socket again. In the meantime the server has to go through a full TLS >> handshake to discover that it's just a DoS. This makes that attack it waaaay >> too asymmetric for my liking... > >Yes, I understand that -- what I meant is, would it significantly help not to >have to do the Bleichenbacher countermeasure? I don't think so, because even >without the countermeasure the same attack could easily keep the server very >busy. I think specifically building in a countermeasure may be overkill, but since the text mentions various implementation considerations it should probably also mention this one in case it's a concern for anyone. In particular the fact that even a small botnet can, via source address forgery sending large numbers of pre-generated handshake packets, bring pretty much any TLS server to its knees (and I'm surprised this DoS hasn't been tried yet) should be a security concern. There's no pressing need to fix it (yet :-), but the text should at least mention it as something that implementors may want to consider. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 29 07:53:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpOv4-0004pM-G8; Wed, 29 Nov 2006 07:52:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpOv2-0004oo-P7 for tls@lists.ietf.org; Wed, 29 Nov 2006 07:52:08 -0500 Received: from proof.pobox.com ([207.106.133.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpOv0-0001vx-Hi for tls@lists.ietf.org; Wed, 29 Nov 2006 07:52:08 -0500 Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id 4F06528D88 for ; Wed, 29 Nov 2006 07:52:28 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 1726999D0C for ; Wed, 29 Nov 2006 07:52:27 -0500 (EST) Message-ID: <456D82E2.2020700@pobox.com> Date: Wed, 29 Nov 2006 04:53:54 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] Two notes on TLS 1.2 after implementing it in GnuTLS References: <87hcwmtp48.fsf@latte.josefsson.org> In-Reply-To: <87hcwmtp48.fsf@latte.josefsson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 > Further, appendix H of PKCS1B contains additional discussions: > > * The requirement that the parameters in an AlgorithmIdentifier > value for id-sha1, id-sha256, id-sha384, and id-sha512 be NULL was > changed to a recommendation that the parameters be omitted (while > still allowing the parameters to be NULL). This is to align with > the definitions originally promulgated by NIST. Implementations > MUST accept AlgorithmIdentifier values both without parameters and > with NULL parameters. > > I note that Mike's server required a NULL here. I initially didn't > send one, my ASN.1 library computed a DER encoding with an omitted > parameters field. For reference, that DER code is: > > SHA-1: 30 1f 30 07 06 05 2b 0e 03 02 1a 04 14 || H > > Mike's server didn't accept this. > > This will leads to interoperability problems with TLS 1.2 unless the > specification is more explicit about the problem. I have to admit I don't understand this issue. That's because I didn't write any RSA code myself. I used to use OpenSSL for SSL/TLS, but was never sure if my code was correct, so I decided to write my own implementation. However, I am comfortable with the functions in OpenSSL's libcrypto, so I used that for all public-key algorithms and bulk encryption. Perhaps I need to write my own RSA code instead of relying on OpenSSL EVP functions for signing/verifying? Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 29 08:13:35 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpPFG-00067D-ID; Wed, 29 Nov 2006 08:13:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpPFF-00066i-F7 for tls@ietf.org; Wed, 29 Nov 2006 08:13:01 -0500 Received: from moutng.kundenserver.de ([212.227.126.187]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpPFD-0007h3-8w for tls@ietf.org; Wed, 29 Nov 2006 08:13:01 -0500 Received: from [134.147.40.251] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu6) with ESMTP (Nemesis), id 0ML29c-1GpPCm1c93-0008WV; Wed, 29 Nov 2006 14:10:29 +0100 Received: by tau.invalid (Postfix, from userid 1000) id A19F64D9C; Wed, 29 Nov 2006 14:10:27 +0100 (CET) Date: Wed, 29 Nov 2006 14:10:27 +0100 From: Bodo Moeller To: Pasi.Eronen@nokia.com Subject: Re: [TLS] Record layer corner cases Message-ID: <20061129131027.GA7003@tau.invalid> References: <20061124164950.GA28453@tau.invalid> 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: 082a9cbf4d599f360ac7f815372a6a15 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, Nov 29, 2006 at 02:51:45PM +0200, Pasi.Eronen@nokia.com wrote: >>> And this is IMHO roughly where we are today... the spec has a >>> feature which nobody uses, and nobody can use. IMHO it would be >>> better to remove it, rather than leave it there "just in case". >> Well, for certificate chains that are "long" (compared to the >> maximum fragment length, or to some device's more limited maximum >> length for sending fragments), fragmentation is a feature that will >> be used. > Assuming, of course, that long certificate chains will be used in the > first place... Typical SSL web server certs today seem to be around > 1KB, so receiving fragments never gets tested in practice. The maximum fragment length extension allows negotiating fragment lengths as low as 512 bytes, so I think this length should be taken into account. With 512-byte fragments, those 1-KB certs will have to be fragmented. Thus my proposal: >> The minimum maximum fragment length (sic) is 2^9, so I suppose it >> would be reasonable to state that fragments of "handshake", "alert", >> and "change_cipher_spec" content type can't be empty and can't be >> smaller than 512 bytes unless they end where a message of the >> respective protocol ends. This does not rule out fragmentation within >> a message, but avoids pathological cases. >>> I fragmented every handshake message (sent by the client) to two >>> fragments (split in the middle). > The test was done with the latest release (0.9.8d). I did some > debugging, and the reason why OpenSSL failed is as follows: usually > OpenSSL (correctly) accepts any record layer version number of form > {03,XX} for ClientHello, but if ClientHello is split to two separate > records, it chokes on the second fragment and replies with > "protocol_version" alert. > > (My test client used TLS 1.1 version (03,02) for both fields; I guess > yours used TLS 1.0 which does indeed work.) Bingo! In the current OpenSSL server-side implementation, the server uses the first few bytes to decide about the version, and insists on that particular record-layer version for subsequent records -- even if the client hasn't yet had a chance to learn about the protocol version chosen by the server. That's a bug, of course. > I don't think the recipient-side code will get tested unless we > specify "MUST randomly fragment messages" :-) And as Peter Gutmann > pointed out, having poorly tested code for corner cases that really > never happen is a security issue as well... Testing with 512-byte fragments looks reasonable. (It wouldn't have cought the OpenSSL bug though since a typical ClientHello isn't that long; however, with ClientHello extensions, it could become quite large, so ClientHello fragmentation might eventually happen in some real-life situations.) Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 29 08:21:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpPN7-0000ex-2x; Wed, 29 Nov 2006 08:21:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpPN5-0000eM-Mo for tls@lists.ietf.org; Wed, 29 Nov 2006 08:21:07 -0500 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GpPMz-0003Mg-HX for tls@lists.ietf.org; Wed, 29 Nov 2006 08:21:03 -0500 Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id kATDKfjI002285 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Nov 2006 14:20:45 +0100 From: Simon Josefsson To: Mike References: <87hcwmtp48.fsf@latte.josefsson.org> <456D82E2.2020700@pobox.com> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:061129:tls@lists.ietf.org::7OfFONtwxJBg3WI/:4VCZ X-Hashcash: 1:22:061129:mike-list@pobox.com::81a4yFLLmD7BPkkx:NEwJ Date: Wed, 29 Nov 2006 14:20:40 +0100 In-Reply-To: <456D82E2.2020700@pobox.com> (Mike's message of "Wed\, 29 Nov 2006 04\:53\:54 -0800") Message-ID: <87psb6jsnr.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.2 required=4.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Cc: tls@lists.ietf.org Subject: [TLS] Re: Two notes on TLS 1.2 after implementing it in GnuTLS 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 Mike writes: >> Further, appendix H of PKCS1B contains additional discussions: >> >> * The requirement that the parameters in an AlgorithmIdentifier >> value for id-sha1, id-sha256, id-sha384, and id-sha512 be NULL was >> changed to a recommendation that the parameters be omitted (while >> still allowing the parameters to be NULL). This is to align with >> the definitions originally promulgated by NIST. Implementations >> MUST accept AlgorithmIdentifier values both without parameters and >> with NULL parameters. >> >> I note that Mike's server required a NULL here. I initially didn't >> send one, my ASN.1 library computed a DER encoding with an omitted >> parameters field. For reference, that DER code is: >> >> SHA-1: 30 1f 30 07 06 05 2b 0e 03 02 1a 04 14 || H >> >> Mike's server didn't accept this. >> >> This will leads to interoperability problems with TLS 1.2 unless the >> specification is more explicit about the problem. > > I have to admit I don't understand this issue. That's because I > didn't write any RSA code myself. I used to use OpenSSL for SSL/TLS, > but was never sure if my code was correct, so I decided to write my > own implementation. However, I am comfortable with the functions in > OpenSSL's libcrypto, so I used that for all public-key algorithms and > bulk encryption. > > Perhaps I need to write my own RSA code instead of relying on OpenSSL > EVP functions for signing/verifying? It seems better if the WG clarify how TLS 1.2 should work here first, and then we both can decide if and how to update our implementations. Alternatives: 1) Find an external spec that is clear on how the DigestInfo is encoded. Using PKCS1B instead of PKCS1A would solve the problem. That would imply DER encoding and omitted parameters field, and acceptance of both omitted and NULL parameters. 2) Clarify that DER encoding is used and: A) unused parameters MUST be omitted. B) unused parameters MUST be encoded as NULL. C) unused parameters MUST be omitted and NULL parameters MUST be accepted. D) unused parameters MUST be encoded as NULL and omitted parameters MUST be accepted. E) unused parameters MUST be encoded as NULL or omitted, and both alternatives MUST be accepted. There are probably more choices. I believe some clarification regarding this may be useful even if 1) is chosen. Many people are still using PKCS#1 RSA implementations that were written on the old standard. I currently prefer choice 1) together with additional text such as: As discussed in [PKCS1B], the DigestInfo MUST be DER encoded and for digest algorithms without parameters (which include SHA-1) the DigestInfo.AlgorithmIdentifier.parameters field SHOULD be omitted but implementations MUST accept both without parameters and with NULL parameters. Other thoughts? /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 29 08:53:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpPrM-0000CA-8y; Wed, 29 Nov 2006 08:52:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpPrK-0000Bp-2U for tls@ietf.org; Wed, 29 Nov 2006 08:52:22 -0500 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpPrH-0006cR-Hk for tls@ietf.org; Wed, 29 Nov 2006 08:52:22 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kATCpoCO030736; Wed, 29 Nov 2006 14:52:23 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Nov 2006 14:51:44 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Nov 2006 14:51:43 +0200 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] Record layer corner cases Date: Wed, 29 Nov 2006 14:51:45 +0200 Message-ID: In-Reply-To: <20061124164950.GA28453@tau.invalid> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Record layer corner cases Thread-Index: AccP7G5vuFMik7AjR3aGa8EoqaL8lwDx1bCg From: To: X-OriginalArrivalTime: 29 Nov 2006 12:51:43.0936 (UTC) FILETIME=[1F5A2C00:01C713B5] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 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: > > And this is IMHO roughly where we are today... the spec has a > > feature which nobody uses, and nobody can use. IMHO it would be > > better to remove it, rather than leave it there "just in case". >=20 > Well, for certificate chains that are "long" (compared to the > maximum fragment length, or to some device's more limited maximum > length for sending fragments), fragmentation is a feature that will > be used. Assuming, of course, that long certificate chains will be used in the first place... Typical SSL web server certs today seem to be around 1KB, so receiving fragments never gets tested in practice. > > I fragmented every handshake message (sent by the client) to two=20 > > fragments (split in the middle). >=20 > I was asking because your observations do not agree with my earlier > testing, which I repeated now: As far as I can determine, provided > that the ClientHello and ServerHello messages are not pathologically > fragmented, OpenSSL should not have problems with weird fragmentation. > For my tests, except for Hello message fragmentation, I've used > length-1 fragments and included the occasional length-0 fragment. So > I'm not sure why you experienced problems with split-in-the-middle > fragmentation unless you used some ancient software version. It seems > possible that the implementation that you used for testing could be > buggy, and that TLS servers don't really handle fragmentation as > poorly as your observations indicate. The test was done with the latest release (0.9.8d). I did some debugging, and the reason why OpenSSL failed is as follows: usually OpenSSL (correctly) accepts any record layer version number of form {03,XX} for ClientHello, but if ClientHello is split to two separate records, it chokes on the second fragment and replies with "protocol_version" alert. (My test client used TLS 1.1 version (03,02) for both fields; I guess=20 yours used TLS 1.0 which does indeed work.) > > The restriction would apply only to TLS 1.2, and there aren't any=20 > > TLS 1.2 implementations yet... so we could even require=20 > > that a single fragment can't contain multiple handshake messages. >=20 > It's still extra implementation work for implementations that don't > happen to follow the potential new requirement. (At least they won't > have to distinguish between protocol versions for this because the > proposed behavior certainly is valid for SSL 3.0, and TLS 1.0 and > TLS 1.1 as well.) >=20 > Now that I come to think of it, if we want to change the words of > the specification for TLS 1.2, we might just as well simply take the > current description of fragmentation and add "And we mean it" ... :-) >=20 > Seriously, if we rule out some odd cases of fragmentation, I don't > think it is unreasonable to require all implementations to be able to > properly process fragmented handshake messages. My worry is that just adding "And we mean it" wouldn't change the current situation: since receiving-side processing is so poorly implemented, the sending side can't really rely on it. But yes, if we decide not to ban unnecessary fragmentation totally, clearly such an implementation note (probably longer and more strictly worded than just "And we mean it") would be in order. > My initial thought on this is that different rules for NULL_WITH_NULL > and for other ciphersuites are an unnecessary complication. Also it > probably would mean that the recipient-side handling of fragmentation > wouldn't get tested as much as it otherwise could. I don't think the recipient-side code will get tested unless we specify "MUST randomly fragment messages" :-) And as Peter Gutmann pointed out, having poorly tested code for corner cases that really never happen is a security issue as well... Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 29 08:55:54 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpPu6-0001fM-J3; Wed, 29 Nov 2006 08:55:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpPu5-0001e7-2B for tls@lists.ietf.org; Wed, 29 Nov 2006 08:55:13 -0500 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpPu2-0006zS-Aj for tls@lists.ietf.org; Wed, 29 Nov 2006 08:55:13 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kATDWLnf017527; Wed, 29 Nov 2006 15:32:37 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Nov 2006 15:32:28 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Nov 2006 15:32:28 +0200 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] Two notes on TLS 1.2 after implementing it in GnuTLS (PKCS#1) Date: Wed, 29 Nov 2006 15:32:29 +0200 Message-ID: In-Reply-To: <87hcwmtp48.fsf@latte.josefsson.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Two notes on TLS 1.2 after implementing it in GnuTLS (PKCS#1) Thread-Index: AccTlEL5mmW8RqJQTD+kZwt0OBIvxwAIi+hQ From: To: , X-OriginalArrivalTime: 29 Nov 2006 13:32:28.0379 (UTC) FILETIME=[D05A92B0:01C713BA] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be 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 Simon Josefsson wrote: > 2. The modification to change RSA signing was to change: >=20 > In RSA signing, a 36-byte structure of two hashes (one SHA and=20 > one MD5) is signed (encrypted with the private key). It is=20 > encoded with PKCS #1 block type 1, as described in [PKCS1A]. >=20 > into: >=20 > In RSA signing, the output of the chosen hash function is=20 > encoded as a PKCS #1 DigestInfo and then signed using block=20 > type 01 as described in Section 8.1 as described in [PKCS1A]. >=20 > This could be improved with some helpful discussion to guide > implementers. PKCS1A is under-specified and even incorrect here. =20 > Is there a reason we don't reference PKCS1B here? Some time ago, I suggested to Eric that we should change to PKCS#1 v2.1 terminology [PKCS1B], since IMHO it's a big improvement over the old terminology. My proposal was simply: =20 In RSA signing, the opaque vector contains the signature generated using the RSASSA-PKCS1-v1_5 signature scheme defined in [PKCS1B]. Note that earlier versions of TLS used a different RSA signature scheme. The proposed text can also be found from our new issue tracker (yes, we started one so that we don't accidentally forget things): http://www1.tools.ietf.org/wg/tls/trac/ticket/1 > DigestInfo mis-handling was the cause of the recent bugs that > affected OpenSSL, Mozilla NSS, GnuTLS and several proprietary TLS > libraries for X.509 signature validations. It would be unfortunate > if TLS 1.2 introduce the same problem into TLS itself. >=20 > The problems with PKCS1A are: >=20 > 1) It uses BER encoding, when PKCS1B correctly changed this to DER. >=20 > 2) It doesn't specify whether the parameters field should be NULL or > omitted for non-MD2/MD4/MD5 algorithms. >=20 > I don't think there is any controversy around 1). DER should be used. >=20 > Whether to use a DigestInfo.AlgorithmIdentifier.parameters field that > is NULL or omitted seems somewhat problematic. PKCS1A says regarding > MD2/MD4/MD5: >=20 > For these object identifiers, the parameters field of the > digestAlgorithm value should be NULL. >=20 > It doesn't say anything about other hashes. PKCS1B says: >=20 > The parameters field associated with id-sha1, id-sha256, id-sha384, > and id-sha512 should be omitted, but if present, shall have a value > of type NULL. >=20 > However the example in PKCS1B uses NULL: >=20 > SHA-1: (0x)30 21 30 09 06 05 2b 0e 03 02 1a 05 00 04 14 || H. >=20 > Further, appendix H of PKCS1B contains additional discussions: >=20 > * The requirement that the parameters in an AlgorithmIdentifier > value for id-sha1, id-sha256, id-sha384, and id-sha512=20 > be NULL was changed to a recommendation that the parameters be=20 > omitted (while still allowing the parameters to be NULL).=20 > This is to align with the definitions originally promulgated=20 > by NIST. Implementations MUST accept AlgorithmIdentifier values=20 > both without parameters and with NULL parameters. There's text in PKCS#1 errata regarding this topic: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1errata.txt The proposed text in the errata (as far as I understand it) says that when using EMSA-PKCS1-V1.5 (which we are using), and any of id-sha1/256/384/512, the parameters MUST be included and MUST have type NULL. It is not totally clear (to me, at least) whether the "MUST accept without parameters" part still applies. In IEEE 1363a-2003 (EMSA3 encoding method), NULL parameters must be included. (But yes, I do agree that TLS 1.2 spec should say something about this.) Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 29 09:05:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpQ3A-0002y0-1R; Wed, 29 Nov 2006 09:04:36 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpQ38-0002xg-Ir for tls@ietf.org; Wed, 29 Nov 2006 09:04:34 -0500 Received: from rune.pobox.com ([208.210.124.79]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GpQ37-0000ar-0a for tls@ietf.org; Wed, 29 Nov 2006 09:04:34 -0500 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id E00A898070 for ; Wed, 29 Nov 2006 09:04:51 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rune.sasl.smtp.pobox.com (Postfix) with ESMTP id ABB2E97244 for ; Wed, 29 Nov 2006 09:04:51 -0500 (EST) Message-ID: <456D93D9.9060406@pobox.com> Date: Wed, 29 Nov 2006 06:06:17 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] Record layer corner cases References: <20061124164950.GA28453@tau.invalid> <20061129131027.GA7003@tau.invalid> In-Reply-To: <20061129131027.GA7003@tau.invalid> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 >> The test was done with the latest release (0.9.8d). I did some >> debugging, and the reason why OpenSSL failed is as follows: usually >> OpenSSL (correctly) accepts any record layer version number of form >> {03,XX} for ClientHello, but if ClientHello is split to two separate >> records, it chokes on the second fragment and replies with >> "protocol_version" alert. >> >> (My test client used TLS 1.1 version (03,02) for both fields; I guess >> yours used TLS 1.0 which does indeed work.) > > Bingo! In the current OpenSSL server-side implementation, the server > uses the first few bytes to decide about the version, and insists on > that particular record-layer version for subsequent records -- even if > the client hasn't yet had a chance to learn about the protocol version > chosen by the server. That's a bug, of course. In my implementation, I don't check the version of records prior to establishing a secure connection. However I found that the best strategy for my client is to find out what version the server supports from ServerHello, and then use that version for the rest of the handshake. Before I did that, I would occasionally get a protocol_version error after sending the ChangeCipherSpec message. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 29 09:09:08 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpQ6n-0008C7-0T; Wed, 29 Nov 2006 09:08:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpQ6l-0008Br-AR for tls@lists.ietf.org; Wed, 29 Nov 2006 09:08:19 -0500 Received: from mailhost-dr.auckland.ac.nz ([130.216.190.14] helo=zeppo.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpQ6i-0001IP-TP for tls@lists.ietf.org; Wed, 29 Nov 2006 09:08:19 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id 46BE93483F; Thu, 30 Nov 2006 03:08:12 +1300 (NZDT) Received: from zeppo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01437-08; Thu, 30 Nov 2006 03:08:12 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id C404E33F77; Thu, 30 Nov 2006 03:08:11 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 2D87937743; Thu, 30 Nov 2006 03:08:08 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1GpQ6j-00045Z-00; Thu, 30 Nov 2006 03:08:17 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: mike-list@pobox.com, simon@josefsson.org Subject: Re: [TLS] Re: Two notes on TLS 1.2 after implementing it in GnuTLS In-Reply-To: <87psb6jsnr.fsf@latte.josefsson.org> Message-Id: Date: Thu, 30 Nov 2006 03:08:17 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.5 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: tls@lists.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 Simon Josefsson writes: >2) Clarify that DER encoding is used and: Which standard do you want to comply with? From RFC 3274: There are two possible encodings for the [algorithm] null parameters field which arise from the fact that when the 1988 syntax for AlgorithmIdentifier was translated into the 1997 syntax, the OPTIONAL associated with the AlgorithmIdentifier parameters got lost. Later it was recovered via a defect report, but by then, everyone thought that algorithm parameters were mandatory. Because of this, some implementations will encode null parameters as an ASN.1 NULL element and some will omit them entirely (see for example section 12 of CMS [RFC2630]). Although the correct encoding is to omit the parameters field, implementations may encounter encodings which use an ASN.1 NULL element for the parameters. (I've seen this issue come up so often across so many WGs that maybe I should do some sort of cross-WG RFC on it that can be referred to wherever the problem comes up. Comments?). Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 29 09:18:39 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpQGK-0008IE-Oy; Wed, 29 Nov 2006 09:18:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpQGJ-0008Hx-U4 for tls@lists.ietf.org; Wed, 29 Nov 2006 09:18:11 -0500 Received: from proof.pobox.com ([207.106.133.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpQGG-0003fQ-MP for tls@lists.ietf.org; Wed, 29 Nov 2006 09:18:11 -0500 Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id 40EF228D8A for ; Wed, 29 Nov 2006 09:18:30 -0500 (EST) Received: from [192.168.1.8] (wsip-24-234-114-35.lv.lv.cox.net [24.234.114.35]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 088A299D87 for ; Wed, 29 Nov 2006 09:18:29 -0500 (EST) Message-ID: <456D970B.9040607@pobox.com> Date: Wed, 29 Nov 2006 06:19:55 -0800 From: Mike User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] Two notes on TLS 1.2 after implementing it in GnuTLS References: <87hcwmtp48.fsf@latte.josefsson.org> In-Reply-To: <87hcwmtp48.fsf@latte.josefsson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 was able to connect successfully > to https://www.mikestoolbox.net:4433/ Since some of you may be behind a firewall that doesn't permit https except to port 443, I added a second listener to my server on that port. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 29 09:27:18 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpQOI-0000Z3-UQ; Wed, 29 Nov 2006 09:26:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpQOH-0000Y8-2M for tls@ietf.org; Wed, 29 Nov 2006 09:26:25 -0500 Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpQOE-0005ch-EG for tls@ietf.org; Wed, 29 Nov 2006 09:26:25 -0500 Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id kATEQJ5V023383 for ; Wed, 29 Nov 2006 09:26:19 -0500 (EST) Received: from 144.51.60.34 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Wed, 29 Nov 2006 09:26:19 -0500 Received: from EXCH.missi.ncsc.mil ([144.51.60.19]) by gto.missi.ncsc.mil with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Nov 2006 09:26:18 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [TLS] Record layer corner cases Date: Wed, 29 Nov 2006 09:26:17 -0500 Message-ID: In-Reply-To: <6b9359640611281954v20f1b3b5xad05986751e15281@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Record layer corner cases Thread-Index: AccTagl61woqh/XSTGeVxJzSEaovVwAUwf/g From: "Kemp, David P." To: X-OriginalArrivalTime: 29 Nov 2006 14:26:18.0906 (UTC) FILETIME=[55E5DFA0:01C713C2] X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-14842002 X-TM-AS-Result: : Yes--8.112900-0-31-1 X-TM-AS-Category-Info: : 31:0.000000 X-TM-AS-MatchedID: : =?us-ascii?B?MTUwNTY3LTcwMzQzNS03MTAy?= =?us-ascii?B?MDEtNzEwNDg5LTcwNDc5MC03MDA1NTQtNzAwODIxLTcwMTQ4MS03?= =?us-ascii?B?MDEzMzQtNzAwMTU0LTcwNDQzMC03MTA5NDYtNzAyMDQ1LTcxMDk3?= =?us-ascii?B?NC03MDEyODYtNzA2NTY1LTcwMTY1MS03MDEzNDQtMTEwMzEwLTEw?= =?us-ascii?B?NTI1MC03MTE2MTctNzA0NDE2LTcwNTc3NS03MTAxMTQtNzA4MzAy?= =?us-ascii?B?LTcwMDc4OC03MDAxMDctNzAwNzkyLTcwMDI0NS0xMDU2MzAtNzAy?= =?us-ascii?B?MDUxLTcwMTE4OS03MDQ2MTktNzExMTQyLTcwMzIyNS03MDA1NjQt?= =?us-ascii?B?NzAwNDg3LTcwMDYzNC03MTAwNzItMTM5MDA2LTcwMDE1MS03MDU4?= =?us-ascii?B?MjItNzAwMDYwLTcwMzAwMS03MTE1MDMtNzAxNDM4LTcxMDk5Mi03?= =?us-ascii?B?MDE0MjMtMTIxMTE0LTcxMDI0Ny03MDAyOTQtNzA5Mjc5LTcxMTUy?= =?us-ascii?B?MC03MTAxNDUtMTIxNTM2LTcwMjg2Mi03MDM0MjctMTQ4MDUw?= X-Spam-Score: 1.1 (+) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 The point is that trust anchor installation is an out-of-band process: standards say nothing about the due diligence that a relying party should apply before deciding to accept a trust anchor. Out-of-band also means that if you receive a root cert that expires in 2050, you are perfectly within your rights to configure your application to make the corresponding TA valid until 2040, or 2060, as you see fit. The standards also say nothing about how relying party applications might be instrumented to perform debugging and error logging. It is perfectly legal to check a root cert every single time you receive it, and generate whatever error messages you wish if you don't like what you see. But it's also legal (according to TLS and X.509) *and secure* to ignore a root cert received in a handshake and validate the intermediate CA cert using just your own pre-installed TA information. Therefore, it is incorrect to claim that a web site or a browser that is configured to send an expired root cert is misconfigured. You are free to complain, but they are free, and correct, to point out that standards do not require them to send a root cert that is acceptable to you. The responsibility is on you to decide what intermediate CAs to trust based on your own TA list, not based on the root certs someone else has installed in their applications. Dave -----Original Message----- From: Kyle Hamilton [mailto:aerowolf@gmail.com]=20 Sent: Tuesday, November 28, 2006 10:54 PM To: Kemp, David P. Cc: tls@ietf.org Subject: Re: [TLS] Record layer corner cases A TA that creates a CA identification/authentication certificate in the correct format (including proper date handling) is much more likely to create other certificates in the correct format, and thus NOT create issues in ASN.1 parsing. Various ASN.1 parsers have had security vulnerabilities that came to light. -Kyle H _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 29 10:37:46 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRUB-00053X-NM; Wed, 29 Nov 2006 10:36:35 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRU9-0004za-1V for tls@lists.ietf.org; Wed, 29 Nov 2006 10:36:33 -0500 Received: from groucho.itss.auckland.ac.nz ([130.216.190.11]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1GpRU7-0008Pm-JC for tls@lists.ietf.org; Wed, 29 Nov 2006 10:36:32 -0500 Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by groucho.itss.auckland.ac.nz (Postfix) with ESMTP id A18F93415F; Thu, 30 Nov 2006 04:36:26 +1300 (NZDT) Received: from groucho.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 26415-09; Thu, 30 Nov 2006 04:36:26 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by groucho.itss.auckland.ac.nz (Postfix) with ESMTP id 80E623414B; Thu, 30 Nov 2006 04:36:26 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 438F737742; Thu, 30 Nov 2006 04:36:26 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1GpRUC-00069Z-00; Thu, 30 Nov 2006 04:36:36 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: simon@josefsson.org, tls@lists.ietf.org Subject: Re: [TLS] Two notes on TLS 1.2 after implementing it in GnuTLS In-Reply-To: <87hcwmtp48.fsf@latte.josefsson.org> Message-Id: Date: Thu, 30 Nov 2006 04:36:36 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.5 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 Simon Josefsson writes: >1. It would have reduced implementation time if there were a list of >protocol syntax changes. For example, it took me some debugging to >understand that CertificateRequest was modified from (RFC 4346): Can I add a "me too" to this, finding some of the surprises hidden in the 1.2 draft took quite a bit of doing. A section detailing the changes would be of considerable benefit to people upgrading existing implementations. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 29 10:45:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRcR-0006Ya-9B; Wed, 29 Nov 2006 10:45:07 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRcQ-0006YS-GQ for tls@lists.ietf.org; Wed, 29 Nov 2006 10:45:06 -0500 Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpRcN-0003vU-Sc for tls@lists.ietf.org; Wed, 29 Nov 2006 10:45:06 -0500 Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id kATFj25V027461 for ; Wed, 29 Nov 2006 10:45:02 -0500 (EST) Received: from 144.51.60.34 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Wed, 29 Nov 2006 10:45:02 -0500 Received: from EXCH.missi.ncsc.mil ([144.51.60.19]) by gto.missi.ncsc.mil with Microsoft SMTPSVC(5.0.2195.6713); Wed, 29 Nov 2006 10:45:02 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [TLS] Record layer corner cases Date: Wed, 29 Nov 2006 10:45:01 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Record layer corner cases Thread-Index: AccTauvzWWCGZO2+Qjqt1zBJ41f9rQAXYEjw From: "Kemp, David P." To: X-OriginalArrivalTime: 29 Nov 2006 15:45:02.0103 (UTC) FILETIME=[55248A70:01C713CD] X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-14842003 X-TM-AS-Result: : Yes--6.965100-0-31-1 X-TM-AS-Category-Info: : 31:0.000000 X-TM-AS-MatchedID: : =?us-ascii?B?MTUwNTY3LTcxMDMwMC03MDIz?= =?us-ascii?B?NjUtNzAxNjUxLTEyMTExNC03MDE4NzEtNzAwMTk3LTcxMTE0Mi03?= =?us-ascii?B?MDQwNDEtNzEwMTk2LTcwMDMwNi03MDY1NjUtNzAwNTI5LTcxMDM0?= =?us-ascii?B?OS03MTAyMDEtMTIxNTA0LTcwMjc3Ni03MDEyOTEtNzExMjg2LTcw?= =?us-ascii?B?OTI3OS03MDQ3NzEtNzEwNzQxLTcxMDE5Ny03MDA3ODgtNzEwOTky?= =?us-ascii?B?LTcwMDg3Ny03MTAyNjUtNzA0MjcwLTcxMDQ4OS03MDY2MjQtNzAz?= =?us-ascii?B?OTAzLTcwNTMyMC03MDA5NjEtNzEwMDcyLTEzOTAwNi03MDU4MjIt?= =?us-ascii?B?NzAwMDYwLTcwMzAwMS03MDAxMDMtNzExNTAzLTcwNTU5MS0xMzkw?= =?us-ascii?B?MTAtNzAzMDA4LTcwMDI0NS03MDM1NTktNzEwNDY4LTcxMDI0Ny03?= =?us-ascii?B?MDEyMDgtNzAzMDk2LTcwMjQ5MS03MDI5NDMtNzAwMTkwLTcwMzIy?= =?us-ascii?B?NS03MDEzMzQtNzA3MTM0LTcwMjA0NS03MTA5NDYtNzEwMjI1LTcw?= =?us-ascii?B?MTU4Mi03MDQyMTMtMTQ4MDUw?= X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 Or did they consciously implement the X.509v4 behavior before it was documented in X.509v4 because they intuitively understood that it was the right way to handle TAs? And that the section on TA handling wasn't just dreamed up by PKI fanciers divorced from reality, but was added based on the expertise of, and problems encountered by, real developers? In a mesh PKI environment, one might want to establish trust anchors at nodes where no self-issued certificates have ever been created and where less than the entire content of a normal CA certificate is appropriate across all RPs. TAs deal with that fact by designating name and key as the only essential information; all else goes in the bin labeled "out of band". I suppose a zillion monkeys might produce Shakespeare, but it's highly improbable that computer code from multiple sources works correctly by coincidence. =20 Dave -----Original Message----- From: pgut001 [mailto:pgut001@cs.auckland.ac.nz]=20 Sent: Tuesday, November 28, 2006 11:01 PM To: Kemp, David P.; pgut001@cs.auckland.ac.nz Cc: tls@lists.ietf.org Subject: RE: [TLS] Record layer corner cases "Kemp, David P." writes: >Apparently, the browser vendors referred to below have been busy tearing down >and rebuilding. More likely they never checked in the first place, and this just appears to work by coincidence. Perhaps we could ask the browser folks, a few of them read this list: Did you consciously implement the X.509v4 changes to trust anchor handling in your code within the last year or two? Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 29 11:10:27 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRzz-0005lX-Sq; Wed, 29 Nov 2006 11:09:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpRzy-0005lN-Tj for tls@lists.ietf.org; Wed, 29 Nov 2006 11:09:26 -0500 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpRzx-00089F-DX for tls@lists.ietf.org; Wed, 29 Nov 2006 11:09:26 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kATG93VB005946; Wed, 29 Nov 2006 18:09:13 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Nov 2006 18:08:58 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Nov 2006 18:08:58 +0200 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: Two notes on TLS 1.2 after implementing it in GnuTLS Date: Wed, 29 Nov 2006 18:08:57 +0200 Message-ID: In-Reply-To: <87psb6jsnr.fsf@latte.josefsson.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Re: Two notes on TLS 1.2 after implementing it in GnuTLS Thread-Index: AccTvYzcZTW5wPSNReKkizwuds+eXQAD2KGg From: To: , X-OriginalArrivalTime: 29 Nov 2006 16:08:58.0061 (UTC) FILETIME=[AD0A57D0:01C713D0] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 Simon Josefsson wrote: > It seems better if the WG clarify how TLS 1.2 should work here first, > and then we both can decide if and how to update our implementations. >=20 > Alternatives: >=20 > 1) Find an external spec that is clear on how the DigestInfo is > encoded. Using PKCS1B instead of PKCS1A would solve the problem. > That would imply DER encoding and omitted parameters field, and > acceptance of both omitted and NULL parameters. Note that PKCS1B requires NULL parameters for MD5 (omitting is not=20 acceptable). But unfortunately, even PKCS1B doesn't solve the problem, since the errata changes the relevant text... ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1errata.txt IEEE 1363a-2004 would be unambiguous (DER encoding, NULL parameter required for SHA-*, omitted parameters not acceptable); this would also be in line with the errata... (Note that other specs, such as RFC 3280, may have an identically named DigestInfo structure, but whether parameters are optional there or not doesn't really have any direct impact on whether they're optional in PKCS#1 EMSA-PKCS1-v1_5 encoding.) Best regards, Pasi=20 _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 29 12:20:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpT5C-0002FJ-2e; Wed, 29 Nov 2006 12:18:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpT5A-0002Eo-NF for tls@ietf.org; Wed, 29 Nov 2006 12:18:52 -0500 Received: from bay0-omc3-s4.bay0.hotmail.com ([65.54.246.204]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpT58-0002ja-QI for tls@ietf.org; Wed, 29 Nov 2006 12:18:52 -0500 Received: from BAY103-W3 ([65.54.174.103]) by bay0-omc3-s4.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Nov 2006 09:18:50 -0800 X-Originating-IP: [75.213.174.122] X-Originating-Email: [home_pw@msn.com] Message-ID: From: Peter Williams To: "Kemp, David P." , Subject: RE: [TLS] Record layer corner cases Date: Wed, 29 Nov 2006 09:18:50 -0800 MIME-Version: 1.0 X-OriginalArrivalTime: 29 Nov 2006 17:18:50.0374 (UTC) FILETIME=[6FDA8A60:01C713DA] X-Spam-Score: 3.5 (+++) X-Scan-Signature: a3f7094ccc62748c06b21fcf44c073ee 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="===============0770251799==" Errors-To: tls-bounces@lists.ietf.org --===============0770251799== Content-Type: multipart/alternative; boundary="_16e860b0-4c0e-4638-97aa-9d45fc188cb9_" --_16e860b0-4c0e-4638-97aa-9d45fc188cb9_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I've gave up making this argument about 5 years ago after 10 years of tryin= g - its ineffective, despite being valid. Folks roll their eyes when you tell then (a) path *validation* is about str= ict hierarchical evaluation (b) path *discovery* is about you choosing the = certs that makeup your chosen path. =20 They get even more confused when you then tell them that actually, you don'= t even need to do validation or discovery in SSL/TLS if that is your design= whim. Its conforming and as intended, tho not particularly interoperable w= ith the "Netscape https" world, or the DoD-profile of "Netscape https" =20 They get even more confused when you tell them that actually, if you do put= 0, 1 or more X.509 Certificate values format in SSL3's PKCS#7 bag in certi= ficate-data, then any of the values can be trust anchors - with arbitrary v= alues in the certificate date fields. =20 You can just send a self-signed cert of the SSL server, if you want, as in = the IIS6 resource kit. You can turn off the URI name validation, too, per N= etscape https. =20 Lets remember, from the SSL patent: SSL provides the security service of "s= trongly naming" (my term) the TCP port, including its IP address. In the No= vell embodiment, it strongly names the SPX/IPX port. In NATO secure X.400 o= ver IP, it strongly names the TSAP. This cryptographic port naming is a fu= nction of the cryptography and the handshake design, not the certificates. = When you no longer trust the cryptographic binding to the newly-named port,= you were supposed to escape (sent OOB using the appropriate network servic= e), force a new handshake, rebuild the sessions exchanging the tokens over = the current session, and rebind without dropping the connection. Just like = a layer 5 secure session-layer protocol entity is supposed to do! =20 Certificates just name and control public keys; in the cryptographic analys= is, the strong naming provided by the socket service (or socket-like API) = does not depend on certificates. Neither the the assurance level of that se= rvice nor the strength of the port naming mechanism depend on certificates.= This trust model is directly analogous to the .NET trust model, when you = sign your .dll, with an RSA key that has no certificate controls attached. = The assurance and strength come from the handshake design, and the math/key= of the PKC algorithm, not the key distribution. =20 Of course, Https is just http sent over a socket enhanced with SSL, per the= patent and per the original declaration when seeking IANA's registration. =20 In "Netscape https", there is of course a more advanced trust model designe= d for the web, that is rather broken, and doesnt work well with reducing tr= ust (involving multiple hidden session control handshakes, potentially!) to= a simple padlock icon in a browser targeting grandma. It involves a hodge = podge of PKI theory, URI theory, HTTP proxying practice, and SSO Connect tu= nneling and bridging. I hope it never becomes an Internet Standard, and I d= o not support it being on the standards track!=20 =20 At the same time, its very effective, socially. Celebrate a success in the = difficult world of crypto-politics, and just leave it alone, IETF! The act= of observing the information may destroy the delicate balance of its natur= e! Standardize on TLS 1.1 with its SAML extensions, and now stop! Come back= in 5 years, once the internet's upper layers have evolved some more. > Subject: RE: [TLS] Record layer corner cases> Date: Wed, 29 Nov 2006 09:2= 6:17 -0500> From: DPKemp@missi.ncsc.mil> To: tls@ietf.org> CC: > > The poin= t is that trust anchor installation is an out-of-band process:> standards s= ay nothing about the due diligence that a relying party> should apply befor= e deciding to accept a trust anchor. Out-of-band> also means that if you re= ceive a root cert that expires in 2050, you> are perfectly within your righ= ts to configure your application to make> the corresponding TA valid until = 2040, or 2060, as you see fit.> > The standards also say nothing about how = relying party applications> might be instrumented to perform debugging and = error logging.> It is perfectly legal to check a root cert every single tim= e you> receive it, and generate whatever error messages you wish if you> do= n't like what you see. But it's also legal (according to TLS> and X.509) *a= nd secure* to ignore a root cert received in a> handshake and validate the = intermediate CA cert using just your> own pre-installed TA information.> > = Therefore, it is incorrect to claim that a web site or a browser> that is c= onfigured to send an expired root cert is misconfigured.> You are free to c= omplain, but they are free, and correct, to point> out that standards do no= t require them to send a root cert> that is acceptable to you. The responsi= bility is on you to decide> what intermediate CAs to trust based on your ow= n TA list, not based> on the root certs someone else has installed in their= applications.> > Dave> > > -----Original Message-----> From: Kyle Hamilton= [mailto:aerowolf@gmail.com] > Sent: Tuesday, November 28, 2006 10:54 PM> T= o: Kemp, David P.> Cc: tls@ietf.org> Subject: Re: [TLS] Record layer corner= cases> > A TA that creates a CA identification/authentication certificate = in> the correct format (including proper date handling) is much more> likel= y to create other certificates in the correct format, and thus> NOT create = issues in ASN.1 parsing. Various ASN.1 parsers have had> security vulnerabi= lities that came to light.> > -Kyle H> > > ________________________________= _______________> TLS mailing list> TLS@lists.ietf.org> https://www1.ietf.or= g/mailman/listinfo/tls _________________________________________________________________ Search from any Web page with powerful protection. Get the FREE Windows Liv= e Toolbar Today! http://get.live.com/toolbar/overview= --_16e860b0-4c0e-4638-97aa-9d45fc188cb9_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I've gave up making this argument about 5 years ago after 10 years&nb= sp;of trying - its ineffective, despite being valid.

Folks roll their eyes when you tell then (a) path *validation* is about str= ict hierarchical evaluation (b) path *discovery* is about you choosing the = certs that makeup your chosen path.
 
They get even more confused when you then tell them that actually, you don'= t even need to do validation or discovery in SSL/TLS if that is your d= esign whim. Its conforming and as intended, tho not particularly interopera= ble with the "Netscape https" world, or the DoD-profile of "Netscape h= ttps"
 
They get even more confused when you tell them that actually, if you do put= 0, 1 or more X.509 Certificate values format in SSL3's PKCS#7 bag in certi= ficate-data, then any of the values can be trust anchors - with arbitrary v= alues in the certificate date fields.
 
You can just send a self-signed cert of the SSL server, if you want, as in = the IIS6 resource kit. You can turn off the URI name validation, too, per N= etscape https.
 
Lets remember, from the SSL patent: SSL provides the security service of "s= trongly naming" (my term) the TCP port, including its IP address. In t= he Novell embodiment, it strongly names the SPX/IPX port. In NATO secure X.= 400 over IP, it strongly names the TSAP.  This cryptographic port nami= ng is a function of the cryptography and the handshake design, not the cert= ificates. When you no longer trust the cryptographic binding to the newly-n= amed port, you were supposed to escape (sent OOB using the appropriate netw= ork service), force a new handshake, rebuild the sessions exchanging the to= kens over the current session, and rebind without dropping the connection. = Just like a layer 5 secure session-layer protocol entity is supposed t= o do!
 
Certificates just name and control public keys; in the cryptographic analys= is, the strong naming provided by the socket service (or socket-like API) &= nbsp;does not depend on certificates. Neither the the assurance level = of that service nor the strength of the port naming mechanism depend on cer= tificates. This trust model is directly analogous to  the .NET tr= ust model, when you sign your .dll, with an RSA key that has no certif= icate controls attached. The assurance and strength come from the handshake= design, and the math/key of the PKC algorithm, not the key distribution.  
Of course, Https is just http sent over a socket enhanced with SSL, per the= patent and per the original declaration when seeking IANA's registration.<= BR>  
In "Netscape https", there is of course a more advanced trust model designe= d for the web, that is rather broken, and doesnt work well with reducing tr= ust (involving multiple hidden session control handshakes, potentially!) to= a simple padlock icon in a browser targeting grandma. It involves a hodge = podge of PKI theory, URI theory, HTTP proxying practice, and SSO Connect tu= nneling and bridging. I hope it never becomes an Internet Standard, and I d= o not support it being on the standards track!
 
At the same time, its very effective, socially. Celebrate a success in the = difficult world of crypto-politics, and just leave it alone, IETF!  Th= e act of observing the information may destroy the delicate balance of= its nature! Standardize on TLS 1.1 with its SAML extensions, and now stop!= Come back in 5 years, once the internet's upper layers have evolved some m= ore.

> Subject: RE: [TLS] Record layer corner cases
> Date: Wed, 29 Nov= 2006 09:26:17 -0500
> From: DPKemp@missi.ncsc.mil
> To: tls@ie= tf.org
> CC:
>
> The point is that trust anchor install= ation is an out-of-band process:
> standards say nothing about the du= e diligence that a relying party
> should apply before deciding to ac= cept a trust anchor. Out-of-band
> also means that if you receive a r= oot cert that expires in 2050, you
> are perfectly within your rights= to configure your application to make
> the corresponding TA valid u= ntil 2040, or 2060, as you see fit.
>
> The standards also say= nothing about how relying party applications
> might be instrumented= to perform debugging and error logging.
> It is perfectly legal to c= heck a root cert every single time you
> receive it, and generate wha= tever error messages you wish if you
> don't like what you see. But i= t's also legal (according to TLS
> and X.509) *and secure* to ignore = a root cert received in a
> handshake and validate the intermediate C= A cert using just your
> own pre-installed TA information.
> > Therefore, it is incorrect to claim that a web site or a browser
= > that is configured to send an expired root cert is misconfigured.
&= gt; You are free to complain, but they are free, and correct, to point
&= gt; out that standards do not require them to send a root cert
> that= is acceptable to you. The responsibility is on you to decide
> what = intermediate CAs to trust based on your own TA list, not based
> on t= he root certs someone else has installed in their applications.
> > Dave
>
>
> -----Original Message-----
> Fro= m: Kyle Hamilton [mailto:aerowolf@gmail.com]
> Sent: Tuesday, Novemb= er 28, 2006 10:54 PM
> To: Kemp, David P.
> Cc: tls@ietf.org> Subject: Re: [TLS] Record layer corner cases
>
> A TA th= at creates a CA identification/authentication certificate in
> the co= rrect format (including proper date handling) is much more
> likely t= o create other certificates in the correct format, and thus
> NOT cre= ate issues in ASN.1 parsing. Various ASN.1 parsers have had
> securit= y vulnerabilities that came to light.
>
> -Kyle H
>
= >
> _______________________________________________
> TLS m= ailing list
> TLS@lists.ietf.org
> https://www1.ietf.org/mailma= n/listinfo/tls


Search from any Web page with powerful pr= otection. Get the FREE Windows Live Toolbar Today! Try it now! = --_16e860b0-4c0e-4638-97aa-9d45fc188cb9_-- --===============0770251799== 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 --===============0770251799==-- From tls-bounces@lists.ietf.org Wed Nov 29 15:43:15 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpWFb-0007NR-OS; Wed, 29 Nov 2006 15:41:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpWFZ-0007MA-Nn for tls@lists.ietf.org; Wed, 29 Nov 2006 15:41:49 -0500 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpWFX-0001Z9-R8 for tls@lists.ietf.org; Wed, 29 Nov 2006 15:41:49 -0500 Received: from localhost.localdomain (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id kATKfMLv006707 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Nov 2006 21:41:24 +0100 From: Simon Josefsson To: pgut001@cs.auckland.ac.nz (Peter Gutmann) References: <87psb6jsnr.fsf@latte.josefsson.org> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:061129:mike-list@pobox.com::0I1vDcvWgRNZrzIb:Zz6 X-Hashcash: 1:22:061129:pgut001@cs.auckland.ac.nz::oZuvX7xID+/LAQWH:EJXO X-Hashcash: 1:22:061129:tls@lists.ietf.org::ZparZ7+PFS64iF57:O0uw Date: Wed, 29 Nov 2006 21:41:21 +0100 In-Reply-To: (Peter Gutmann's message of "Thu\, 30 Nov 2006 03\:08\:17 +1300") Message-ID: <87vekyasum.fsf@latte.josefsson.org> User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.91 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-2.2 required=4.0 tests=AWL,BAYES_00, FORGED_RCVD_HELO autolearn=ham version=3.1.1 X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: tls@lists.ietf.org Subject: [TLS] Re: Two notes on TLS 1.2 after implementing it in GnuTLS 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 pgut001@cs.auckland.ac.nz (Peter Gutmann) writes: > Simon Josefsson writes: > >>2) Clarify that DER encoding is used and: > > Which standard do you want to comply with? From RFC 3274: > > There are two possible encodings for the [algorithm] null parameters field > which arise from the fact that when the 1988 syntax for AlgorithmIdentifier > was translated into the 1997 syntax, the OPTIONAL associated with the > AlgorithmIdentifier parameters got lost. Later it was recovered via a > defect report, but by then, everyone thought that algorithm parameters were > mandatory. Because of this, some implementations will encode null > parameters as an ASN.1 NULL element and some will omit them entirely (see > for example section 12 of CMS [RFC2630]). Although the correct encoding is > to omit the parameters field, implementations may encounter encodings which > use an ASN.1 NULL element for the parameters. > > (I've seen this issue come up so often across so many WGs that maybe I should > do some sort of cross-WG RFC on it that can be referred to wherever the > problem comes up. Comments?). Given the current situation, the pragmatic approach seem to be to allow implementations to send both variants and require that both MUST be accepted and have the same meaning. It doesn't seem necessary to declare that one variant is preferred for TLS. I suspect that trying to decide which of the two variants is the one we should prefer is a rat-hole. /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 29 15:59:12 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpWVn-0001dZ-9H; Wed, 29 Nov 2006 15:58:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpWVm-0001dN-5o for tls@lists.ietf.org; Wed, 29 Nov 2006 15:58:34 -0500 Received: from wr-out-0506.google.com ([64.233.184.229]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpWVj-0004XB-VV for tls@lists.ietf.org; Wed, 29 Nov 2006 15:58:34 -0500 Received: by wr-out-0506.google.com with SMTP id i7so869439wra for ; Wed, 29 Nov 2006 12:58:31 -0800 (PST) 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=DrPJPL0sLVOhCrQ3u8xtFb2VFeIX4QWdeHMclRsF4+z16hD7HULo5myvgNDtJamv+LuE2pGLogXdGnf1OGPiIH9DzZLxH1b7rf4OFfYMX+4zTks8pQJx2h6Ra2jde+0FeMPexYHnm1uWzY85zjDEVYTK/wavCqehSOo/NrppZLg= Received: by 10.90.120.6 with SMTP id s6mr2826775agc.1164833911330; Wed, 29 Nov 2006 12:58:31 -0800 (PST) Received: by 10.90.70.4 with HTTP; Wed, 29 Nov 2006 12:58:31 -0800 (PST) Message-ID: <6b9359640611291258g12d6bcbbia2b23f761551a4f7@mail.gmail.com> Date: Wed, 29 Nov 2006 13:58:31 -0700 From: "Kyle Hamilton" To: "Simon Josefsson" Subject: Re: [TLS] Re: Two notes on TLS 1.2 after implementing it in GnuTLS In-Reply-To: <87vekyasum.fsf@latte.josefsson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <87psb6jsnr.fsf@latte.josefsson.org> <87vekyasum.fsf@latte.josefsson.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: tls@lists.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 As has been noted elsewhere, any time you have a choice of which option to take, you have at least one bit of information leakage potential. One of the rules for Common Criteria validation of higher assurance levels is the proven removal of covert channels. I think the ability to precisely specify during negotiation exactly which behavior you're going to use might be helpful? -Kyle H On 11/29/06, Simon Josefsson wrote: > > Given the current situation, the pragmatic approach seem to be to > allow implementations to send both variants and require that both MUST > be accepted and have the same meaning. > > It doesn't seem necessary to declare that one variant is preferred for > TLS. I suspect that trying to decide which of the two variants is the > one we should prefer is a rat-hole. > > /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 29 20:15:05 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpaUd-0002Xj-6X; Wed, 29 Nov 2006 20:13:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpaUZ-0002Rc-KQ for tls@ietf.org; Wed, 29 Nov 2006 20:13:35 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpaS2-0007LP-Fd for tls@ietf.org; Wed, 29 Nov 2006 20:10:59 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id CAA19772; Thu, 30 Nov 2006 02:10:50 +0100 (MEZ) From: Martin Rex Message-Id: <200611300110.CAA01035@uw1048.wdf.sap.corp> Subject: Re: [TLS] Record layer corner cases To: DPKemp@missi.ncsc.mil (Kemp David P.) Date: Thu, 30 Nov 2006 02:10:49 +0100 (MET) In-Reply-To: from "Kemp, David P." at Nov 29, 6 09:26:17 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: 1.1 (+) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 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 Kemp, David P. wrote: > > The point is that trust anchor installation is an out-of-band process: Correct! What is a trust anchor is determined exclusively by local configuration established through some out-of-band process. Existing SSL/TLS protocols do NOT have a means to transfer trust anchors. An X.509 certificate is something entirely different than a Trust Anchor. It is just a convenience to use an X.509 container for distributing Trust Anchors. Whenever a Trust Anchor is wrapped in X.509 for transport, and especially when it is tunneled through other protocols/PDUs that are specified to carry X.509 certificates for authentication purposes (and NOT to distribute trust anchors), then the sender MUST create a valid X.509 cert, otherwise the sender is obviously and undoubtedly broken and asking for interoperability problems. SSL/TLS certainly does NOT (natively) provide a Trust Anchor transport facility, it only provides one for X.509 certs for the purpose of authenticating the communication peers. Trust Anchors for an SSL/TLS communication peer is information that is installed/configured out of band. Certs that arrive within forward certificate chains of an SSL/TLS are NEVER Trust Anchors. A SSL/TLS that verifies rootCA certs arriving in forward certification paths and verifies them like this TA -> rootCA -> CA -> EE may not be "highly optimized", but is certainly working correctly. And if it is validating the certification path in this fashion, it certainly MUST fail validation if the rootCA is not valid. An SSL/TLS peer that sends an invalid self-signed rootCA cert together with a valid end-entity cert in the forward certification path is likely broken. It is definitely broken if it also has a valid rootCA cert (and sends the wrong one) or if it creates an invalid rootCA cert for inclusion from local TrustAnchor information (which is what our OEM ssl implementation had been doing with the GlobalSign RootCA cert). > > The standards also say nothing about how relying party applications > might be instrumented to perform debugging and error logging. > It is perfectly legal to check a root cert every single time you > receive it, and generate whatever error messages you wish if you > don't like what you see. But it's also legal (according to TLS > and X.509) *and secure* to ignore a root cert received in a > handshake and validate the intermediate CA cert using just your > own pre-installed TA information. It is legal and secure to ignore certificates that are outside of the certification path between the peers end entity cert and the verifiers chosen trust anchor. Security-wise, the signature verification on the certification path should be performed starting with the trust anchor and towards the end entitiy certificate. However, if a local trust anchor matches a rootCA cert, then that rootCA cert then it is at the discretion of the verifier to consider it part of the certification path or attempt an optimization and eliminate it. There certainly is no requirement that it be ignored! > > Therefore, it is incorrect to claim that a web site or a browser > that is configured to send an expired root cert is misconfigured. I strongly disagree. A Server that sends a non-expired server cert together with an expired CA cert is definitely misconfigured. And if the servers SSL/TLS implementation has access to several variants of the CA certs, some expired and some valid, then the SSL/TLS implementation definitely and undoubtedly is broken (i.e. needs a patch) if it sends the expired cert. > You are free to complain, but they are free, and correct, to point > out that standards do not require them to send a root cert > that is acceptable to you. The responsibility is on you to decide > what intermediate CAs to trust based on your own TA list, not based > on the root certs someone else has installed in their applications. sending a valid rootCA cert is OK. sending a trust anchor wrapped like an X.509 cert but with characteristics that will certificate path validation is a pretty dumb idea and screaming for interoperability problems. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 29 20:16:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpaWL-00059m-8s; Wed, 29 Nov 2006 20:15:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpaWK-00059Z-C9 for tls@lists.ietf.org; Wed, 29 Nov 2006 20:15:24 -0500 Received: from groucho.itss.auckland.ac.nz ([130.216.190.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpaWI-0008E5-VN for tls@lists.ietf.org; Wed, 29 Nov 2006 20:15:24 -0500 Received: from localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) by groucho.itss.auckland.ac.nz (Postfix) with ESMTP id 961B43446A; Thu, 30 Nov 2006 14:15:18 +1300 (NZDT) Received: from groucho.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpa.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12871-12; Thu, 30 Nov 2006 14:15:18 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by groucho.itss.auckland.ac.nz (Postfix) with ESMTP id BC25534464; Thu, 30 Nov 2006 14:15:17 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id D832E37742; Thu, 30 Nov 2006 14:15:16 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1GpaWG-0007dC-00; Thu, 30 Nov 2006 14:15:20 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: DPKemp@missi.ncsc.mil, tls@lists.ietf.org Subject: RE: [TLS] Record layer corner cases In-Reply-To: Message-Id: Date: Thu, 30 Nov 2006 14:15:20 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.5 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 "Kemp, David P." writes: >Or did they consciously implement the X.509v4 behavior before it was >documented in X.509v4 because they intuitively understood that it was the >right way to handle TAs? OK, so they had some deep insight into ignoring dates in TAs even before it was standardised in X.509v4. Perhaps you could also explain the deep insight they had that caused them to ignore basicConstraints (until widespread bad publicity forced them to pay attention to it a year or two back), to ignore keyUsage (this is even touted as a feature in some implementations), to ignore... well, you get the picture. >I suppose a zillion monkeys might produce Shakespeare, but it's highly >improbable that computer code from multiple sources works correctly by >coincidence. You've got the analogy wrong. The default behaviour for monkeys is to produce gibberish. The default behaviour for a minimal/least-effort/under-time- pressure/whatever X.509 implementation is to check as little as possible, i.e. to "process" certs in an oblivious manner. So you need to say "I suppose a zillion monkeys might produce gibberish" if you're going to use analogies with X.509 implementations. (As I noted before, I'd still like to hear from implementors if any of them consciously made the change in X.509v4. Send me private mail if you don't want to go public with it). Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 29 20:28:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpahu-0002rV-0X; Wed, 29 Nov 2006 20:27:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpahs-0002py-IR for tls@ietf.org; Wed, 29 Nov 2006 20:27:20 -0500 Received: from smtpde02.sap-ag.de ([155.56.68.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpahr-0001ip-7G for tls@ietf.org; Wed, 29 Nov 2006 20:27:20 -0500 Received: from sap-ag.de (smtpde02) by smtpde02.sap-ag.de (out) with ESMTP id CAA19248; Thu, 30 Nov 2006 02:27:12 +0100 (MEZ) From: Martin Rex Message-Id: <200611300127.CAA01351@uw1048.wdf.sap.corp> Subject: Re: [TLS] Record layer corner cases To: bmoeller@acm.org (Bodo Moeller) Date: Thu, 30 Nov 2006 02:27:11 +0100 (MET) In-Reply-To: <20061129131027.GA7003@tau.invalid> from "Bodo Moeller" at Nov 29, 6 02:10:27 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: 7655788c23eb79e336f5f8ba8bce7906 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 Bodo Moeller wrote: > > Testing with 512-byte fragments looks reasonable. (It wouldn't have > cought the OpenSSL bug though since a typical ClientHello isn't that > long; however, with ClientHello extensions, it could become quite > large, so ClientHello fragmentation might eventually happen in some > real-life situations.) Since we had this discussion about what version number should be used on the record protocol when sending the ClientHello -- the case where ClientHello is fragmented is interesting: Although most if not all SSLv3-only implementations have been patched to accept {3,1} on the first record of a new connection, this is not necessarily true for the additional records of a fragmented ClientHello. IMHO, using the lowest protocol version acceptable to the client for all records carrying fragments of a ClientHello message is the most interoperable and the only reasonable recommendation. -Martin _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Nov 29 21:31:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpbgQ-00041s-90; Wed, 29 Nov 2006 21:29:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpbgN-0003vx-Us for tls@lists.ietf.org; Wed, 29 Nov 2006 21:29:51 -0500 Received: from mailhost-dr.auckland.ac.nz ([130.216.190.14] helo=zeppo.itss.auckland.ac.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpbgK-0007BD-Hk for tls@lists.ietf.org; Wed, 29 Nov 2006 21:29:51 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id A779E3474E; Thu, 30 Nov 2006 15:29:41 +1300 (NZDT) Received: from zeppo.itss.auckland.ac.nz ([127.0.0.1]) by localhost (smtpd.itss.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09861-07; Thu, 30 Nov 2006 15:29:41 +1300 (NZDT) Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by zeppo.itss.auckland.ac.nz (Postfix) with ESMTP id 204E73460E; Thu, 30 Nov 2006 15:29:41 +1300 (NZDT) Received: from medusa01.cs.auckland.ac.nz (medusa01.cs.auckland.ac.nz [130.216.34.33]) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 7A0BD37742; Thu, 30 Nov 2006 15:29:40 +1300 (NZDT) Received: from pgut001 by medusa01.cs.auckland.ac.nz with local (Exim 3.36 #1 (Debian)) id 1GpbgG-0000Pb-00; Thu, 30 Nov 2006 15:29:44 +1300 From: pgut001@cs.auckland.ac.nz (Peter Gutmann) To: DPKemp@missi.ncsc.mil, , tls@lists.ietf.org Subject: RE: [TLS] Record layer corner cases Message-Id: Date: Thu, 30 Nov 2006 15:29:44 +1300 X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz X-Spam-Score: 0.5 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 "Kemp, David P." writes: >Or did they consciously implement the X.509v4 behavior before it was >documented in X.509v4 because they intuitively understood that it was the >right way to handle TAs? Oh, one thing I forgot from my other message: Wouldn't such an implementation be totally non-compliant with the spec if it implemented behaviour that was at odds with the actual requirements? If everyone ignored the spec and implemented whatever they intuitively felt right we'd get... well, I think we've already got it. Peter. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 30 04:54:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpib5-0008TC-St; Thu, 30 Nov 2006 04:52:51 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpib4-0008T3-7E for tls@lists.ietf.org; Thu, 30 Nov 2006 04:52:50 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gpib0-0006tl-Ka for tls@lists.ietf.org; Thu, 30 Nov 2006 04:52:50 -0500 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext04.nokia.com (Switch-3.1.10/Switch-3.1.10) with ESMTP id kAU9qL7c017951; Thu, 30 Nov 2006 11:52:34 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 11:52:33 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Nov 2006 11:52:32 +0200 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: Two notes on TLS 1.2 after implementing it in GnuTLS Date: Thu, 30 Nov 2006 11:52:33 +0200 Message-ID: In-Reply-To: <87vekyasum.fsf@latte.josefsson.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Re: Two notes on TLS 1.2 after implementing it in GnuTLS Thread-Index: AccT9xp7p2J2P4r3Qq2awz1NctR4RQAbSv3Q From: To: , X-OriginalArrivalTime: 30 Nov 2006 09:52:32.0715 (UTC) FILETIME=[4189C9B0:01C71465] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::061130115235-45944BB0-3BF0F3EB/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) 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 Simon Josefsson wrote: > Given the current situation, the pragmatic approach seem to be to > allow implementations to send both variants and require that both MUST > be accepted and have the same meaning. Unnecessary options are a recipe for interoperability (and security) problems, and in this situation, we don't have to be backwards compatible with old implementations (since TLS 1.0/1.1 didn't have this issue). So IMHO we should specify this in TLS 1.2 spec one way or another. Given that both IEEE 1363a-2004 and PKCS#1 v2.1 latest errata seem to agree on the issue (NULL parameter MUST be include), that would seem the most obvious choice... Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 30 05:35:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpjG3-00053U-HS; Thu, 30 Nov 2006 05:35:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpjG1-00052a-VY for tls@lists.ietf.org; Thu, 30 Nov 2006 05:35:09 -0500 Received: from 178.230.13.217.in-addr.dgcsystems.net ([217.13.230.178] helo=yxa.extundo.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpjFz-0006GV-HR for tls@lists.ietf.org; Thu, 30 Nov 2006 05:35:09 -0500 Received: from [192.168.1.13] (c80-217-219-89.bredband.comhem.se [80.217.219.89]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id kAUAYaWt012291; Thu, 30 Nov 2006 11:34:36 +0100 Subject: RE: [TLS] Re: Two notes on TLS 1.2 after implementing it in GnuTLS From: Simon Josefsson To: Pasi.Eronen@nokia.com In-Reply-To: References: Content-Type: text/plain Date: Thu, 30 Nov 2006 11:34:31 +0100 Message-Id: <1164882871.6962.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=2.3 required=4.0 tests=AWL,BAYES_00, RCVD_IN_NJABL_DUL,RCVD_IN_SORBS_DUL autolearn=no version=3.1.1 X-Spam-Level: ** X-Spam-Checker-Version: SpamAssassin 3.1.1 (2006-03-10) on yxa-iv X-Virus-Scanned: ClamAV version 0.88.2, clamav-milter version 0.88.2 on yxa.extundo.com X-Virus-Status: Clean X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: tls@lists.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 Thu, 2006-11-30 at 11:52 +0200, Pasi.Eronen@nokia.com wrote: > Simon Josefsson wrote: > > > Given the current situation, the pragmatic approach seem to be to > > allow implementations to send both variants and require that both MUST > > be accepted and have the same meaning. > > Unnecessary options are a recipe for interoperability (and security) > problems, and in this situation, we don't have to be backwards > compatible with old implementations (since TLS 1.0/1.1 didn't have > this issue). Sure. > So IMHO we should specify this in TLS 1.2 spec one way or another. Ok. What about accepting the other alternative? MUST NOT, to avoid a covert channel? MUST, to cater for those implementers with external RSA libraries that they can't change? Or MAY or SHOULD? > Given that both IEEE 1363a-2004 and PKCS#1 v2.1 latest errata > seem to agree on the issue (NULL parameter MUST be include), > that would seem the most obvious choice... RFC 3447 says the parameters field is omitted, due to NIST specifications. It might make sense to ask around what today's preferences are. /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 30 10:47:03 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpo6A-0005XD-Cg; Thu, 30 Nov 2006 10:45:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gpo69-0005Vx-Fg for tls@lists.ietf.org; Thu, 30 Nov 2006 10:45:17 -0500 Received: from woodstock.binhost.com ([66.150.120.2]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Gpo67-0006XG-7X for tls@lists.ietf.org; Thu, 30 Nov 2006 10:45:17 -0500 Received: (qmail 31983 invoked by uid 0); 30 Nov 2006 15:45:07 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.246.224.157) by woodstock.binhost.com with SMTP; 30 Nov 2006 15:45:07 -0000 Message-Id: <7.0.0.16.2.20061130103805.0409bc08@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Thu, 30 Nov 2006 10:41:35 -0500 To: tls@lists.ietf.org From: Russ Housley Subject: RE: [TLS] Re: Two notes on TLS 1.2 after implementing it in GnuTLS In-Reply-To: References: <87psb6jsnr.fsf@latte.josefsson.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.1 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 > > 1) Find an external spec that is clear on how the DigestInfo is > > encoded. Using PKCS1B instead of PKCS1A would solve the problem. > > That would imply DER encoding and omitted parameters field, and > > acceptance of both omitted and NULL parameters. > >Note that PKCS1B requires NULL parameters for MD5 (omitting is not >acceptable). But unfortunately, even PKCS1B doesn't solve the >problem, since the errata changes the relevant text... > >ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-1/pkcs-1v2-1errata.txt > >IEEE 1363a-2004 would be unambiguous (DER encoding, NULL parameter >required for SHA-*, omitted parameters not acceptable); this would >also be in line with the errata... > >(Note that other specs, such as RFC 3280, may have an identically >named DigestInfo structure, but whether parameters are optional >there or not doesn't really have any direct impact on whether >they're optional in PKCS#1 EMSA-PKCS1-v1_5 encoding.) I agree. One word of warning: if the idea of salted hash functions catches on, then the hash algorithm parameter will not always be NULL. I would like to see this documented in a separate document that can be referenced by TLS, S/MIME, and any other protocol that needs to make use of PKCS#1 v1.5. Russ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 30 10:52:16 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpoCJ-0000WR-Ek; Thu, 30 Nov 2006 10:51:39 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GpoCI-0000VD-Bh for tls@ietf.org; Thu, 30 Nov 2006 10:51:38 -0500 Received: from stingray.missi.ncsc.mil ([144.51.50.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GpoCG-0007Fv-4t for tls@ietf.org; Thu, 30 Nov 2006 10:51:38 -0500 Received: from Cerberus.missi.ncsc.mil (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with SMTP id kAUFpY5V010579 for ; Thu, 30 Nov 2006 10:51:34 -0500 (EST) Received: from 144.51.60.34 by Cerberus.missi.ncsc.mil (InterScan VirusWall 6); Thu, 30 Nov 2006 10:51:34 -0500 Received: from EXCH.missi.ncsc.mil ([144.51.60.19]) by gto.missi.ncsc.mil with Microsoft SMTPSVC(5.0.2195.6713); Thu, 30 Nov 2006 10:51:34 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Subject: RE: [TLS] Record layer corner cases Date: Thu, 30 Nov 2006 10:51:33 -0500 Message-ID: In-Reply-To: <200611300110.CAA01035@uw1048.wdf.sap.corp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] Record layer corner cases Thread-Index: AccUHGW9+23ZrjBTS2W9bCXqfH2tTgAaxtCw From: "Kemp, David P." To: X-OriginalArrivalTime: 30 Nov 2006 15:51:34.0515 (UTC) FILETIME=[69739C30:01C71497] X-TM-AS-Product-Ver: : ISVW-6.0.0.1396-3.6.0.1039-14844003 X-TM-AS-Result: : Yes--7.261900-0-2-1 X-TM-AS-Category-Info: : 2:0.000000 X-TM-AS-MatchedID: : =?us-ascii?B?MTUwNTY3LTcwNDIxMy03MDIw?= =?us-ascii?B?NTEtNzAwMzczLTcwMjc3Ni03MDU2ODgtNzEwNjAzLTcwMTE0My03?= =?us-ascii?B?MDQ3NzEtNzEwMzA0LTE4ODAxOS0xMzkwMTAtNzAxNjUxLTcwNTc3?= =?us-ascii?B?NS03MDkyNzktNzExMTU0LTcwNzM0NC03MDI5MjgtNzEwMjAxLTcw?= =?us-ascii?B?NTIxOS03MDI3NjktNzAwMzg2LTcwMDgyMS03MDI5NTAtNzEwOTky?= =?us-ascii?B?LTcwODA2MS03MDE2MTgtNzAxMDY1LTcwMzA5NS03MDQ3OTItNzAz?= =?us-ascii?B?NTYyLTcwNDk1MC03MDAyMzctNzAyNDkxLTcwNTU0Mi03MDEyOTEt?= =?us-ascii?B?NzExMTAxLTcwMDg0OS03MDgzMDItNzAxMjk1LTcwMzIxMi03MDAx?= =?us-ascii?B?ODItNzAxMzM0LTcwMjcwNi03MDc5ODQtNzAyNzM4LTcwOTc1Ny03?= =?us-ascii?B?MTAwNzItMTQ4MDUwLTIwMDQy?= X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 see that Peter Williams is correct in that this topic is no more amenable to a meeting of the minds than is religion or politics. There is very little to say that hasn't already been said, except ... > It is legal and secure to ignore certificates that are outside of > the certification path between the peers end entity cert and the > verifiers chosen trust anchor. > > Security-wise, the signature verification on the certification path > should be performed starting with the trust anchor and towards the > end entitiy certificate. > > However, if a local trust anchor matches a rootCA cert, then that > rootCA cert then it is at the discretion of the verifier to consider > it part of the certification path or attempt an optimization and > eliminate it. There certainly is no requirement that it be ignored! Correct, no such requirement appears in RFC 2246 or RFC 4346: Because certificate validation requires that root keys be distributed independently, the self-signed certificate which specifies the root certificate authority may optionally be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case. In the interest of unambiguity and interoperability, I would suggest that the "ignore" statement you previously imputed to TLSv1 be added as a requirement to TLS 1.2 (draft 4346bis): TLSv1 improved the situation, indicating that the path may or may not contain a rootCA (=3Dself-signed) cert, and mentioned that such a cert, if present, should not have an impact on the decision whether the peer's certificate is trusted. Signing off, Dave _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Nov 30 11:57:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GppCS-00027g-2T; Thu, 30 Nov 2006 11:55:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GppCR-00027Z-3f for tls@lists.ietf.org; Thu, 30 Nov 2006 11:55:51 -0500 Received: from anchor-post-34.mail.demon.net ([194.217.242.92]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GppCM-0007GA-Qe for tls@lists.ietf.org; Thu, 30 Nov 2006 11:55:51 -0500 Received: from drh-consultancy.demon.co.uk ([80.177.30.10] helo=[192.168.7.2]) by anchor-post-34.mail.demon.net with esmtp (Exim 4.42) id 1GppC5-000KzD-Dm for tls@lists.ietf.org; Thu, 30 Nov 2006 16:55:29 +0000 Message-ID: <456F0CC8.1040405@drh-consultancy.demon.co.uk> Date: Thu, 30 Nov 2006 16:54:32 +0000 From: Dr Stephen Henson User-Agent: Thunderbird 1.5.0.8 (Windows/20061025) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] Re: Two notes on TLS 1.2 after implementing it in GnuTLS References: <87psb6jsnr.fsf@latte.josefsson.org> <7.0.0.16.2.20061130103805.0409bc08@vigilsec.com> In-Reply-To: <7.0.0.16.2.20061130103805.0409bc08@vigilsec.com> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 My 2c on the subject... As I think has been mentioned some implementations generate the DigestInfo structure using a cut+paste operation from a binary blob. Others perform cut, paste and compare for the verify operation. This is often done in resouce limited environments or those who have no wish to implement a full ASN1 library just to produce and parse this one structure. Some existing examples, such as smart cards, cannot change the format they use and would be rendered non compliant if we make their format illegal. All the examples I've seen using that technique (and a few specs) require that a NULL parameter is present and not omitted but I can't rule out some which may omit parameters. Steve. -- Dr Stephen N. Henson. Core developer of the OpenSSL project: http://www.openssl.org/ Freelance consultant see: http://www.drh-consultancy.co.uk/ Email: shenson@drh-consultancy.co.uk, PGP key: via homepage. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls