RE: [TLS] Conflict between TLS 1.1 (RFC4346) and Krb5 Cipher Suite(RFC2712)
<Pasi.Eronen@nokia.com> Thu, 14 December 2006 14:42 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gurmm-0007Hx-R1; Thu, 14 Dec 2006 09:42:12 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Gurml-0007Hs-JV for tls@lists.ietf.org; Thu, 14 Dec 2006 09:42:11 -0500
Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Gurmj-0002iN-4a for tls@lists.ietf.org; Thu, 14 Dec 2006 09:42:11 -0500
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id kBEEfRwb015865; Thu, 14 Dec 2006 16:41:41 +0200
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Dec 2006 16:42:03 +0200
Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 14 Dec 2006 16:42:03 +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] Conflict between TLS 1.1 (RFC4346) and Krb5 Cipher Suite(RFC2712)
Date: Thu, 14 Dec 2006 16:42:03 +0200
Message-ID: <B356D8F434D20B40A8CEDAEC305A1F240388EF4F@esebe105.NOE.Nokia.com>
In-Reply-To: <45815525.10806@secure-endpoints.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Conflict between TLS 1.1 (RFC4346) and Krb5 Cipher Suite(RFC2712)
Thread-Index: AccfiX56Jdo0ngkEQTe0QADs24nU6QAAt9Rw
From: Pasi.Eronen@nokia.com
To: jaltman@secure-endpoints.com, tls@lists.ietf.org
X-OriginalArrivalTime: 14 Dec 2006 14:42:03.0768 (UTC) FILETIME=[05469F80:01C71F8E]
X-eXpurgate-Category: 1/0
X-eXpurgate-ID: 149371::061214164142-3D271BB0-09810DBC/0-0/0-1
X-Nokia-AV: Clean
X-Spam-Score: 0.2 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Cc:
X-BeenThere: tls@lists.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.lists.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/tls>
List-Post: <mailto:tls@lists.ietf.org>
List-Help: <mailto:tls-request@lists.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@lists.ietf.org?subject=subscribe>
Errors-To: tls-bounces@lists.ietf.org
Jeffrey Altman wrote: > One more revision combining the best of Pasi's and Bodo's text: > > This message is omitted if the agreed-upon key exchange method is > anonymous or uses server authentication method that does not > involve certificates. For all key exchange methods specified in > this document except for DH_anon, the server MUST send this > message. For non-anonymous key exchange methods specified > elsewhere that do not provide an alternative method of server > authentication, the server MUST send this message. This message > will always immediately follow the server hello message. Improving... except I still prefer an ordering where we first say when the message is sent, and the explain the exceptions: This message MUST be sent if the agreed-upon key exchange method involves certificates for server authentication. This includes all key exchange methods defined in this document except DH_anon. For key exchange methods specified elsewhere that are either anonymous or provide an alternative method of server authentication, this message MUST NOT be sent. This message will always immediately follow the server hello message. Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls
- [TLS] Conflict between TLS 1.1 (RFC4346) and Krb5… Jeffrey Altman
- RE: [TLS] Conflict between TLS 1.1 (RFC4346) and … Pasi.Eronen
- Re: [TLS] Conflict between TLS 1.1 (RFC4346) and … Bodo Moeller
- Re: [TLS] Conflict between TLS 1.1 (RFC4346) and … Jeffrey Altman
- RE: [TLS] Conflict between TLS 1.1 (RFC4346) and … Pasi.Eronen
- Re: [TLS] Conflict between TLS 1.1 (RFC4346) and … Jeffrey Altman