From tls-bounces@lists.ietf.org Wed Aug 01 01:17:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG6Zw-0004Rx-7H; Wed, 01 Aug 2007 01:17:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IG6Zv-0004Rp-D2 for tls@ietf.org; Wed, 01 Aug 2007 01:16:59 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IG6Zu-0007f3-PR for tls@ietf.org; Wed, 01 Aug 2007 01:16:59 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 31 Jul 2007 22:16:58 -0700 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CACq0r0arR7PD/2dsb2JhbAA X-IronPort-AV: i="4.19,206,1183359600"; d="scan'208"; a="11483912:sNHT14588826" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l715Gwot011853; Tue, 31 Jul 2007 22:16:58 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l715Gl6Q015336; Wed, 1 Aug 2007 05:16:58 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 31 Jul 2007 22:16:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] RFC 4507bis Date: Tue, 31 Jul 2007 22:17:02 -0700 Message-ID: In-Reply-To: <46ACC722.8080702@pobox.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] RFC 4507bis Thread-Index: AcfSAXbyDC75dAGYRzO0SfZt8aQjOAB+SMLw From: "Joseph Salowey \(jsalowey\)" To: "Mike" , X-OriginalArrivalTime: 01 Aug 2007 05:16:57.0882 (UTC) FILETIME=[2ECD7FA0:01C7D3FB] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3061; t=1185945418; x=1186809418; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[TLS]=20RFC=204507bis |Sender:=20; bh=hQ5+3Ba5bd9qaDLbXfQaHSjXMKChsr8EjLcUxI9qvwQ=; b=KaALR/MKj3LbT5iJ7mVE68w8i8gw9otHmS1occjRXMd+6c/LDr0FbQtM+FX20hVt9wYp3snT r6X4Gg0k1jvBVamLM+pvlA39a6o9MNkvahYpUk0u3/RmIHFYVA1lefFY; Authentication-Results: sj-dkim-3; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org Hi Mike, Thanks for reviewing the document, comments inline below:=20 > -----Original Message----- > From: Mike [mailto:mike-list@pobox.com]=20 > Sent: Sunday, July 29, 2007 9:58 AM > To: tls@ietf.org > Subject: [TLS] RFC 4507bis >=20 > I'm working on adding support for RFC 4507 to my code and=20 > have found a few issues with the draft. >=20 > - Should the NewSessionTicket message be included > in the hash used to create/verify the Finished > message. I believe it should since it's a > handshake message, but it's not stated anywhere. > I think it would be a good idea to specifically > state that it is. >=20 [Joe]It is part of the TLS hello message and is therefore included in the finished message. This is part of the TLS extensions spec. I'm not sure we need to clarify it here. > - Is it legal for the server to resume a session > and not provide a NewSessionTicket? The message > flow I'm referring to would look like this: >=20 > Client Server > ClientHello > (SessionTicket extension) --> > ServerHello > (no SessionTicket extension) > [ChangeCipherSpec] > <-- Finished > [ChangeCipherSpec] > Finished --> > Application Data <-> Application Data >=20 > If this is not allowed, it should probably be > stated that when a server resumes a session using > a SessionTicket, it MUST send an empty Session > Ticket extension and a NewSessionTicket message > (optionally with an empty ticket). >=20 [Joe] It is legal to not provide a new session ticket if you do not provide an empty session ticket extension from the server. However if you include an empty session ticket extension from the server you must provide a NewSessionTicket message (which may be empty). Some other reviewers have had similar comments, is there a place where the text could be clearer? > - It may be useful to state that the MAC computation > in the ticket is over the encrypted contents to > be able to quickly reject a ticket and not have to > perform a decryption first. >=20 [Joe] This is a implementation detail that I'm not sure we need to go into in the specification.=20 > - Should HMAC-SHA256 be recommended instead of > HMAC-SHA1? >=20 [Joe] I was under the impression that most people were OK with HMAC-SHA-1 use for the foreseeable future. If this is not the case we can probably change it to HMAC-SHA-256. > - StatePlaintext needs more data fields when TLS > extensions are used such as max fragment length. > This should be obvious, but it wouldn't hurt to > state. >=20 > Mike >=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 Wed Aug 01 10:43:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGFPK-00055Z-7A; Wed, 01 Aug 2007 10:42:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGFPJ-00055N-AM for tls@ietf.org; Wed, 01 Aug 2007 10:42:37 -0400 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGFPH-0000Im-L1 for tls@ietf.org; Wed, 01 Aug 2007 10:42:37 -0400 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 4980D1158EF for ; Wed, 1 Aug 2007 10:42:57 -0400 (EDT) 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 8C4A21158B1 for ; Wed, 1 Aug 2007 10:42:56 -0400 (EDT) Message-ID: <46B09C2B.70609@pobox.com> Date: Wed, 01 Aug 2007 07:43:55 -0700 From: Mike User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] RFC 4507bis 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: f4c2cf0bccc868e4cc88dace71fb3f44 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 >> - Should the NewSessionTicket message be included >> in the hash used to create/verify the Finished >> message. I believe it should since it's a >> handshake message, but it's not stated anywhere. >> I think it would be a good idea to specifically >> state that it is. >> > [Joe]It is part of the TLS hello message and is therefore included in > the finished message. This is part of the TLS extensions spec. I'm not > sure we need to clarify it here. I was referring to the NewSessionTicket message sent by the server to the client just before ChangeCipherSpec. I think you should state that it is included in the hash used to create/verify the Finished messages. >> - Is it legal for the server to resume a session >> and not provide a NewSessionTicket? The message >> flow I'm referring to would look like this: >> >> Client Server >> ClientHello >> (SessionTicket extension) --> >> ServerHello >> (no SessionTicket extension) >> [ChangeCipherSpec] >> <-- Finished >> [ChangeCipherSpec] >> Finished --> >> Application Data <-> Application Data >> >> If this is not allowed, it should probably be >> stated that when a server resumes a session using >> a SessionTicket, it MUST send an empty Session >> Ticket extension and a NewSessionTicket message >> (optionally with an empty ticket). >> > [Joe] It is legal to not provide a new session ticket if you do not > provide an empty session ticket extension from the server. However if > you include an empty session ticket extension from the server you must > provide a NewSessionTicket message (which may be empty). Some other > reviewers have had similar comments, is there a place where the text > could be clearer? The message flow diagram in the draft that shows session resumption has the server send an empty SessionTicket extension. If the message flow above is also allowed (where no SessionTicket extension is sent by the server), then I think you should include the diagram in the spec. > [Joe] I was under the impression that most people were OK with > HMAC-SHA-1 use for the foreseeable future. If this is not the case we > can probably change it to HMAC-SHA-256. I will leave that up to the experts to decide, but will use SHA-256 in my code in any case. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Aug 01 12:45:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGHKD-0003Qy-8b; Wed, 01 Aug 2007 12:45:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGHKB-0003Qj-SS for tls@ietf.org; Wed, 01 Aug 2007 12:45:27 -0400 Received: from relay1.mail.uk.clara.net ([80.168.70.181]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGHK9-0003Qi-FL for tls@ietf.org; Wed, 01 Aug 2007 12:45:27 -0400 Received: from [149.254.200.222] (helo=[10.36.234.32]) by relay1.mail.uk.clara.net with esmtpa (Exim 4.62) (envelope-from ) id 1IGHJu-0003Vk-Qk; Wed, 01 Aug 2007 17:45:14 +0100 Message-ID: <46B0B88D.5000909@drh-consultancy.demon.co.uk> Date: Wed, 01 Aug 2007 17:45:01 +0100 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Mike Subject: Re: [TLS] RFC 4507bis References: <46B09C2B.70609@pobox.com> In-Reply-To: <46B09C2B.70609@pobox.com> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Clara-Relay: Message sent using Claranet Relay Service using auth code: drh X-Spam-Score: 1.1 (+) 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 Mike wrote: > >>> - Is it legal for the server to resume a session >>> and not provide a NewSessionTicket? The message >>> flow I'm referring to would look like this: >>> >>> Client Server >>> ClientHello >>> (SessionTicket extension) --> >>> ServerHello >>> (no SessionTicket extension) >>> [ChangeCipherSpec] >>> <-- Finished >>> [ChangeCipherSpec] >>> Finished --> >>> Application Data <-> Application Data >>> >>> If this is not allowed, it should probably be >>> stated that when a server resumes a session using >>> a SessionTicket, it MUST send an empty Session >>> Ticket extension and a NewSessionTicket message >>> (optionally with an empty ticket). >>> >> [Joe] It is legal to not provide a new session ticket if you do not >> provide an empty session ticket extension from the server. However if >> you include an empty session ticket extension from the server you must >> provide a NewSessionTicket message (which may be empty). Some other >> reviewers have had similar comments, is there a place where the text >> could be clearer? > > The message flow diagram in the draft that shows session > resumption has the server send an empty SessionTicket > extension. If the message flow above is also allowed > (where no SessionTicket extension is sent by the server), > then I think you should include the diagram in the spec. > I agree that some clarification is needed in that case. I wasn't aware of a special meaning for an empty ticket in a NewSessionTicket message either so an explicit mention of that would be helpful. One other area I'd like clarified is in 3.4: > When presenting a ticket, the client MAY generate and include a > Session ID in the TLS ClientHello. If the server accepts the ticket > and the Session ID is not empty, then it MUST respond with the same > Session ID present in the ClientHello. I'm assuming this means that if the server accepts the ticket then it MUST repond with the same Session ID present in ClientHello (which would mean it MUST be empty if ClientHello Session ID is empty). One alternative reading of that would be that the server can send an empty Session ID if it accepts a ticket even if the ClientHello Session ID is not empty. 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 Wed Aug 01 14:02:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGIWq-0000IE-R1; Wed, 01 Aug 2007 14:02:36 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGIWo-0000I7-E1 for tls@ietf.org; Wed, 01 Aug 2007 14:02:34 -0400 Received: from relay1.mail.uk.clara.net ([80.168.70.181]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGIWo-0006hE-0M for tls@ietf.org; Wed, 01 Aug 2007 14:02:34 -0400 Received: from [149.254.200.222] (helo=[10.36.238.225]) by relay1.mail.uk.clara.net with esmtpa (Exim 4.62) (envelope-from ) id 1IGIWj-0004IK-Dg; Wed, 01 Aug 2007 19:02:30 +0100 Message-ID: <46B0CAA7.2080309@drh-consultancy.demon.co.uk> Date: Wed, 01 Aug 2007 19:02:15 +0100 From: Dr Stephen Henson User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: Mike Subject: Re: [TLS] RFC 4507bis References: <46B09C2B.70609@pobox.com> <46B0B88D.5000909@drh-consultancy.demon.co.uk> In-Reply-To: <46B0B88D.5000909@drh-consultancy.demon.co.uk> X-Enigmail-Version: 0.95.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Clara-Relay: Message sent using Claranet Relay Service using auth code: drh 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 Dr Stephen Henson wrote: > Mike wrote: >> The message flow diagram in the draft that shows session >> resumption has the server send an empty SessionTicket >> extension. If the message flow above is also allowed >> (where no SessionTicket extension is sent by the server), >> then I think you should include the diagram in the spec. >> > > I agree that some clarification is needed in that case. > Actually now I've re-read it this is exactly what Figure 3 is showing. I suppose it could emphasize that an empty SessionTicket in ServerHello MUST be present if and only if a NewSessionTicket message will be sent. 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 Wed Aug 01 14:46:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGJDI-0001QE-2X; Wed, 01 Aug 2007 14:46:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGJDG-0001Q7-5E for tls@lists.ietf.org; Wed, 01 Aug 2007 14:46:26 -0400 Received: from extu-mxob-2.symantec.com ([216.10.194.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGJDE-0006Yd-GI for tls@lists.ietf.org; Wed, 01 Aug 2007 14:46:26 -0400 Received: from tus1opsmtapin02.ges.symantec.com ([192.168.214.44]:42377) by extu-mxob-2.symantec.com with esmtp (Exim 4.66) (envelope-from ) id 1IGJDD-0007VT-Be for tls@lists.ietf.org; Wed, 01 Aug 2007 11:46:23 -0700 Received: from reserved-155-64-230-19.ges.symantec.com ([155.64.230.19] helo=TUS1XCHECNPIN02.enterprise.veritas.com) by tus1opsmtapin02.ges.symantec.com with esmtp (Exim 4.67) (envelope-from ) id 1IGJDD-0002Gz-8b for tls@lists.ietf.org; Wed, 01 Aug 2007 11:46:23 -0700 Received: from TUS1XCHEVSPIN02.enterprise.veritas.com ([155.64.230.42]) by TUS1XCHECNPIN02.enterprise.veritas.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Aug 2007 11:46:23 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 1 Aug 2007 11:46:22 -0700 Message-ID: <1D526804BA83A2459C60E28CA73ABD9001FC9DE0@TUS1XCHCLUPIN03.enterprise.veritas.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RFC 4507bis (Joseph Salowey (jsalowey)) thread-index: AcfUVRePRd0P445dQU+ceHtZv6t9ngAFZLyA References: From: "Mark Tillinghast" To: X-OriginalArrivalTime: 01 Aug 2007 18:46:23.0352 (UTC) FILETIME=[42141F80:01C7D46C] X-Brightmail-Verdict: VlJEQwAAAAIAAAABAAAAAAAAAAEAAAAAAAAAAWluYm94AHRsc0BsaXN0cy5pZXRmLm9yZwA= X-Brightmail-Tracker: AAAAAA== X-Spam-Score: -4.0 (----) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Subject: [TLS] RE: RFC 4507bis (Joseph Salowey (jsalowey)) 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 Joe, I am very concerned about sha1 vs sha256. I have two different certificates with the same signature complements of Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu. =20 Nist guidance I think is along the lines of moving forward, SHA-256 should be used, TLS 1.2 is a big part of the moving forward. To quote Bruce Schneier quoting the NSA "Attacks get better; they never get worse." Mark -----Original Message----- From: tls-request@lists.ietf.org [mailto:tls-request@lists.ietf.org]=20 Sent: Wednesday, August 01, 2007 9:00 AM To: tls@lists.ietf.org Subject: TLS Digest, Vol 37, Issue 1 Send TLS mailing list submissions to tls@lists.ietf.org To subscribe or unsubscribe via the World Wide Web, visit https://www1.ietf.org/mailman/listinfo/tls or, via email, send a message with subject or body 'help' to tls-request@lists.ietf.org You can reach the person managing the list at tls-owner@lists.ietf.org When replying, please edit your Subject line so it is more specific than "Re: Contents of TLS digest..." Today's Topics: 1. RE: RFC 4507bis (Joseph Salowey (jsalowey)) 2. Re: RFC 4507bis (Mike) ---------------------------------------------------------------------- Message: 1 Date: Tue, 31 Jul 2007 22:17:02 -0700 From: "Joseph Salowey \(jsalowey\)" Subject: RE: [TLS] RFC 4507bis To: "Mike" , Message-ID: =09 Content-Type: text/plain; charset=3D"us-ascii" Hi Mike, Thanks for reviewing the document, comments inline below:=20 > -----Original Message----- > From: Mike [mailto:mike-list@pobox.com] > Sent: Sunday, July 29, 2007 9:58 AM > To: tls@ietf.org > Subject: [TLS] RFC 4507bis >=20 > I'm working on adding support for RFC 4507 to my code and have found a > few issues with the draft. >=20 > - Should the NewSessionTicket message be included > in the hash used to create/verify the Finished > message. I believe it should since it's a > handshake message, but it's not stated anywhere. > I think it would be a good idea to specifically > state that it is. >=20 [Joe]It is part of the TLS hello message and is therefore included in the finished message. This is part of the TLS extensions spec. I'm not sure we need to clarify it here. > - Is it legal for the server to resume a session > and not provide a NewSessionTicket? The message > flow I'm referring to would look like this: >=20 > Client Server > ClientHello > (SessionTicket extension) --> > ServerHello > (no SessionTicket extension) > [ChangeCipherSpec] > <-- Finished > [ChangeCipherSpec] > Finished --> > Application Data <-> Application Data >=20 > If this is not allowed, it should probably be > stated that when a server resumes a session using > a SessionTicket, it MUST send an empty Session > Ticket extension and a NewSessionTicket message > (optionally with an empty ticket). >=20 [Joe] It is legal to not provide a new session ticket if you do not provide an empty session ticket extension from the server. However if you include an empty session ticket extension from the server you must provide a NewSessionTicket message (which may be empty). Some other reviewers have had similar comments, is there a place where the text could be clearer? > - It may be useful to state that the MAC computation > in the ticket is over the encrypted contents to > be able to quickly reject a ticket and not have to > perform a decryption first. >=20 [Joe] This is a implementation detail that I'm not sure we need to go into in the specification.=20 > - Should HMAC-SHA256 be recommended instead of > HMAC-SHA1? >=20 [Joe] I was under the impression that most people were OK with HMAC-SHA-1 use for the foreseeable future. If this is not the case we can probably change it to HMAC-SHA-256. > - StatePlaintext needs more data fields when TLS > extensions are used such as max fragment length. > This should be obvious, but it wouldn't hurt to > state. >=20 > Mike >=20 > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls >=20 ------------------------------ Message: 2 Date: Wed, 01 Aug 2007 07:43:55 -0700 From: Mike Subject: Re: [TLS] RFC 4507bis To: tls@ietf.org Message-ID: <46B09C2B.70609@pobox.com> Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >> - Should the NewSessionTicket message be included >> in the hash used to create/verify the Finished >> message. I believe it should since it's a >> handshake message, but it's not stated anywhere. >> I think it would be a good idea to specifically >> state that it is. >> > [Joe]It is part of the TLS hello message and is therefore included in=20 > the finished message. This is part of the TLS extensions spec. I'm=20 > not sure we need to clarify it here. I was referring to the NewSessionTicket message sent by the server to the client just before ChangeCipherSpec. I think you should state that it is included in the hash used to create/verify the Finished messages. >> - Is it legal for the server to resume a session >> and not provide a NewSessionTicket? The message >> flow I'm referring to would look like this: >> >> Client Server >> ClientHello >> (SessionTicket extension) --> >> ServerHello >> (no SessionTicket extension) >> [ChangeCipherSpec] >> <-- Finished >> [ChangeCipherSpec] >> Finished --> >> Application Data <-> Application Data >> >> If this is not allowed, it should probably be >> stated that when a server resumes a session using >> a SessionTicket, it MUST send an empty Session >> Ticket extension and a NewSessionTicket message >> (optionally with an empty ticket). >> > [Joe] It is legal to not provide a new session ticket if you do not=20 > provide an empty session ticket extension from the server. However if=20 > you include an empty session ticket extension from the server you must > provide a NewSessionTicket message (which may be empty). Some other=20 > reviewers have had similar comments, is there a place where the text=20 > could be clearer? The message flow diagram in the draft that shows session resumption has the server send an empty SessionTicket extension. If the message flow above is also allowed (where no SessionTicket extension is sent by the server), then I think you should include the diagram in the spec. > [Joe] I was under the impression that most people were OK with > HMAC-SHA-1 use for the foreseeable future. If this is not the case we > can probably change it to HMAC-SHA-256. I will leave that up to the experts to decide, but will use SHA-256 in my code in any case. Mike ------------------------------ _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls End of TLS Digest, Vol 37, Issue 1 ********************************** _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Aug 01 14:49:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGJFn-0003Ti-Oh; Wed, 01 Aug 2007 14:49:03 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGJFm-0003Od-4z for tls@ietf.org; Wed, 01 Aug 2007 14:49:02 -0400 Received: from rune.pobox.com ([208.210.124.79]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGJFl-0007ng-Ra for tls@ietf.org; Wed, 01 Aug 2007 14:49:02 -0400 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 329D61196BB for ; Wed, 1 Aug 2007 14:49:21 -0400 (EDT) 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 EA7721196B9 for ; Wed, 1 Aug 2007 14:49:20 -0400 (EDT) Message-ID: <46B0D5EB.9040803@pobox.com> Date: Wed, 01 Aug 2007 11:50:19 -0700 From: Mike User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] RFC 4507bis References: <46B09C2B.70609@pobox.com> <46B0B88D.5000909@drh-consultancy.demon.co.uk> <46B0CAA7.2080309@drh-consultancy.demon.co.uk> In-Reply-To: <46B0CAA7.2080309@drh-consultancy.demon.co.uk> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 message flow diagram in the draft that shows session >>> resumption has the server send an empty SessionTicket >>> extension. If the message flow above is also allowed >>> (where no SessionTicket extension is sent by the server), >>> then I think you should include the diagram in the spec. >> >> I agree that some clarification is needed in that case. > > Actually now I've re-read it this is exactly what Figure 3 is showing. But Figure 3 illustrates a full handshake. The case I'm talking about is an abbreviated handshake (session resume) without the server sending an empty SessionTicket extension or NewSessionTicket message. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Aug 01 15:00:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGJRH-0003T7-0B; Wed, 01 Aug 2007 15:00:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGJRF-0003Sl-Ss for tls@ietf.org; Wed, 01 Aug 2007 15:00:53 -0400 Received: from rune.pobox.com ([208.210.124.79]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGJRF-00083O-Jk for tls@ietf.org; Wed, 01 Aug 2007 15:00:53 -0400 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 02DDA1196D6 for ; Wed, 1 Aug 2007 15:01:15 -0400 (EDT) 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 ADA111196D4 for ; Wed, 1 Aug 2007 15:01:14 -0400 (EDT) Message-ID: <46B0D8B5.6000203@pobox.com> Date: Wed, 01 Aug 2007 12:02:13 -0700 From: Mike User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] TLS 1.2 References: <46ABB82D.8090709@pobox.com> In-Reply-To: <46ABB82D.8090709@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) 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 To the person trying to interoperate with my server: You uncovered a bug in my server that was looking for a HashType in the CertificateVerify message regardless of the key type. I fixed it so now it only looks for that if it's an RSA client certificate. Also, your client gets as far as establishing the master secret, but when an encrypted packet arrives, either the MAC or padding is invalid. I will look over my code to see if it's my fault. Mike Mike wrote: > I realize it's still a moving target, but I updated > my test server to implement TLS 1.2 as of the latest > draft (-04). You can test against it at > > https://www.mikestoolbox.net > > Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Aug 02 12:57:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGdxp-0004kJ-FZ; Thu, 02 Aug 2007 12:55:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGdxo-0004kE-Qa for tls@ietf.org; Thu, 02 Aug 2007 12:55:52 -0400 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IGdxn-0005E5-LS for tls@ietf.org; Thu, 02 Aug 2007 12:55:52 -0400 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id 02262119FA0 for ; Thu, 2 Aug 2007 12:56:13 -0400 (EDT) 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 C3EEC119F9E for ; Thu, 2 Aug 2007 12:56:12 -0400 (EDT) Message-ID: <46B20CE1.7020308@pobox.com> Date: Thu, 02 Aug 2007 09:57:05 -0700 From: Mike User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: tls@ietf.org References: <46ABB82D.8090709@pobox.com> <46B0D8B5.6000203@pobox.com> In-Reply-To: <46B0D8B5.6000203@pobox.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [TLS] TLS 1.2 MAC calculation 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 just want to make sure I'm reading the spec correctly. Is SHA-256 used only for the PRF calculation and the MAC algorithm is still whatever the cipher suite says? Or is SHA- 256 also used for MAC calculations? I believe the former, so MD5 could even still be used with RC4 -- is this correct? Thanks, Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Aug 03 06:26:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGuLE-0006UX-PZ; Fri, 03 Aug 2007 06:25:08 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGuLE-0006UQ-6c for tls@ietf.org; Fri, 03 Aug 2007 06:25:08 -0400 Received: from mail.gi-de.com ([193.108.184.25]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGuLD-0005Ry-JE for tls@ietf.org; Fri, 03 Aug 2007 06:25:08 -0400 Received: from notessmtp1.domino.intern [10.4.4.49] by mail.gi-de.com id 6GAX4V30 outgoing id 6GAX4V30; 03 Aug 2007 12:25:06 +0200 In-Reply-To: <46B20CE1.7020308@pobox.com> To: Mike Subject: Antwort: [TLS] TLS 1.2 MAC calculation MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: Axel.Heider@gi-de.com Date: Fri, 3 Aug 2007 12:25:03 +0200 X-MIMETrack: Serialize by Router on NOTESSMTP1/SRV/GuD(Release 7.0.2|September 26, 2006) at 03.08.2007 12:25:03, Serialize complete at 03.08.2007 12:25:03 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) 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 Mike, > I just want to make sure I'm reading the spec > correctly. Is SHA-256 used only for the PRF > calculation and the MAC algorithm is still > whatever the cipher suite says? Or is SHA- > 256 also used for MAC calculations? I believe > the former, so MD5 could even still be used > with RC4 -- is this correct? My opinion is, that for compatibility reasons, all defined cipher suits sould work as before. The SHA-256 versions of any cipher suits should get a new id. This would also make the implementation easier if all SSL/TLS versions are supported. Axel _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Aug 03 06:47:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGugV-0001Fn-I4; Fri, 03 Aug 2007 06:47:07 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IGugU-0001EH-Ad for tls@ietf.org; Fri, 03 Aug 2007 06:47:06 -0400 Received: from moutng.kundenserver.de ([212.227.126.179]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IGugT-00062b-J2 for tls@ietf.org; Fri, 03 Aug 2007 06:47:06 -0400 Received: from [80.142.172.66] (helo=tau.invalid) by mrelayeu.kundenserver.de (node=mrelayeu8) with ESMTP (Nemesis), id 0ML31I-1IGugR1nAt-0003qL; Fri, 03 Aug 2007 12:47:04 +0200 Received: by tau.invalid (Postfix, from userid 1000) id 4067F1A2DF; Fri, 3 Aug 2007 12:47:02 +0200 (CEST) Date: Fri, 3 Aug 2007 12:47:02 +0200 From: Bodo Moeller To: Axel.Heider@gi-de.com Subject: Re: Antwort: [TLS] TLS 1.2 MAC calculation Message-ID: <20070803104702.GA8485@tau.invalid> References: <46B20CE1.7020308@pobox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.9i X-Provags-ID: V01U2FsdGVkX1+zkoRhMlp+VR4xGpntaafqZaCJOLFph80RROv O7Von+mCPadJrxXDZ8YrXaoeFkFwq2Rn6YsxrVQIkRNwmNsm/t 4StcjU6L5TdH6BSww6Mf8dQVOSn+dm8GGqyZzjX4LxsTxt1XLm hlw== X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: tls@ietf.org X-BeenThere: tls@lists.ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: tls-bounces@lists.ietf.org On Fri, Aug 03, 2007 at 12:25:03PM +0200, Axel.Heider@gi-de.com wrote: >> I just want to make sure I'm reading the spec >> correctly. Is SHA-256 used only for the PRF >> calculation and the MAC algorithm is still >> whatever the cipher suite says? Or is SHA- >> 256 also used for MAC calculations? I believe >> the former, so MD5 could even still be used >> with RC4 -- is this correct? > My opinion is, that for compatibility reasons, > all defined cipher suits sould work as before. > The SHA-256 versions of any cipher suits should > get a new id. This would also make the > implementation easier if all SSL/TLS versions > are supported. Compatibility isn't really an important issue here (we have explicit version negotiation). Ease of implementation is. Luckily, appendices B and C make it quite clear that SHA still means SHA-1, and that MD5 still means MD5. There's really nothing wrong with this: This use of HMAC is for ephemeral authentication only, so there's no reason to force everyone to live with the overhead of SHA-256 or something. The situation is quite different for hashes in the PRF. The PRF is essential for the long-term security of encryption, and the old PRF is somewhat weird; replacing it makes a lot of sense. Bodo _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Aug 03 15:44:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH33W-0007oP-O1; Fri, 03 Aug 2007 15:43:26 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IH33U-0007oK-Vw for tls@ietf.org; Fri, 03 Aug 2007 15:43:25 -0400 Received: from sceptre.pobox.com ([207.106.133.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IH33U-0005mu-Mc for tls@ietf.org; Fri, 03 Aug 2007 15:43:24 -0400 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id D460B2EF for ; Fri, 3 Aug 2007 15:42:44 -0400 (EDT) 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 sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id 9D9686B09C for ; Fri, 3 Aug 2007 15:42:44 -0400 (EDT) Message-ID: <46B38563.6060106@pobox.com> Date: Fri, 03 Aug 2007 12:43:31 -0700 From: Mike User-Agent: Thunderbird 2.0.0.5 (Windows/20070716) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] TLS 1.2 interoperating References: <46ABB82D.8090709@pobox.com> <46B0D8B5.6000203@pobox.com> In-Reply-To: <46B0D8B5.6000203@pobox.com> 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 Today someone has successfully connected to my server using TLS 1.2 (-04 draft). An added benefit is that TLS 1.2 is about 3-4% faster than TLS 1.1 in establishing a connection (RSA_WITH_RC4_128_MD5 1024 bit was used to test). Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Aug 06 12:14:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1II5Do-0005rA-Nh; Mon, 06 Aug 2007 12:14:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1II5Dn-0005r0-96 for tls@ietf.org; Mon, 06 Aug 2007 12:14:19 -0400 Received: from sceptre.pobox.com ([207.106.133.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1II5Dn-0003qw-0q for tls@ietf.org; Mon, 06 Aug 2007 12:14:19 -0400 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id 8B1632EF for ; Mon, 6 Aug 2007 12:14:38 -0400 (EDT) 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 sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id 467816CFDF for ; Mon, 6 Aug 2007 12:14:38 -0400 (EDT) Message-ID: <46B74837.1040506@pobox.com> Date: Mon, 06 Aug 2007 09:11:35 -0700 From: Mike User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) 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] RFC 4507 support? 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 Does anyone know of a server that supports RFC 4507 session tickets for session resumption? Thanks, Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Aug 08 16:33:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIsBh-00073i-CN; Wed, 08 Aug 2007 16:31:25 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIsBf-00073b-8a for tls@ietf.org; Wed, 08 Aug 2007 16:31:23 -0400 Received: from web37010.mail.mud.yahoo.com ([209.191.85.95]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1IIsBe-0001WS-T4 for tls@ietf.org; Wed, 08 Aug 2007 16:31:23 -0400 Received: (qmail 57168 invoked by uid 60001); 8 Aug 2007 20:31:22 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=xhTyze/aAymfsyi+iO9Qv178XG8/LGJzCWIuEk/VXc/pSpT1fdjnyyaYpDHItbpC8u18qOgEJ9uY12YbmreeOSrrObT85AvAFSCMo3/HTTAS7TUySEmaGrFi2rgi9XqOgUZKFzy+Oot+O7n3pa7sl+NOdDzJLJ/y10tHP6CU6s8=; X-YMail-OSG: pAKjhQEVM1l7zlBEB6gmZyuzr9h9rF0.rZ_cdlwT9kO.yMp6eRUuME7Q0fjA._midQ-- Received: from [198.208.159.19] by web37010.mail.mud.yahoo.com via HTTP; Wed, 08 Aug 2007 13:31:22 PDT Date: Wed, 8 Aug 2007 13:31:22 -0700 (PDT) From: Ken Peirce To: tls@ietf.org MIME-Version: 1.0 Message-ID: <354403.57111.qm@web37010.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Subject: [TLS] compression of certificates 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="===============0797837510==" Errors-To: tls-bounces@lists.ietf.org --===============0797837510== Content-Type: multipart/alternative; boundary="0-1481586871-1186605082=:57111" Content-Transfer-Encoding: 8bit --0-1481586871-1186605082=:57111 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Hi All, I am a bit confused. If I wish to use non-null compression and non-null encryption with certificates, can I compress the certificates prior to sending them or can compression only run after the handshake is done? Cheers, Ken --0-1481586871-1186605082=:57111 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Hi All,
 
I am a bit confused. If I wish to use non-null compression and non-null encryption with certificates, can I compress the certificates prior to sending them or can compression only run after the handshake is done?
 
Cheers,
Ken
 
--0-1481586871-1186605082=:57111-- --===============0797837510== 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 --===============0797837510==-- From tls-bounces@lists.ietf.org Wed Aug 08 17:03:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIsew-0003iQ-4w; Wed, 08 Aug 2007 17:01:38 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IIseu-0003iK-Em for tls@ietf.org; Wed, 08 Aug 2007 17:01:36 -0400 Received: from sceptre.pobox.com ([207.106.133.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IIseu-0002D7-3b for tls@ietf.org; Wed, 08 Aug 2007 17:01:36 -0400 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id 3D3722FB for ; Wed, 8 Aug 2007 17:01:57 -0400 (EDT) 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 sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id 0F3E06DC53 for ; Wed, 8 Aug 2007 17:01:56 -0400 (EDT) Message-ID: <46BA2E84.10208@pobox.com> Date: Wed, 08 Aug 2007 13:58:44 -0700 From: Mike User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tls@ietf.org Subject: Re: [TLS] compression of certificates References: <354403.57111.qm@web37010.mail.mud.yahoo.com> In-Reply-To: <354403.57111.qm@web37010.mail.mud.yahoo.com> 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 > I am a bit confused. If I wish to use non-null compression and non-null > encryption with certificates, can I compress the certificates prior to > sending them or can compression only run after the handshake is done? The certificates are sent during the initial handshake, so they are not compressed. There is an extension for client certificate URL's that you may be interested in. Instead of sending the certificate, you send a URL from which it can be retrieved. See RFC 4366 for details. Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Thu Aug 09 05:36:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ4PK-00052m-3g; Thu, 09 Aug 2007 05:34:18 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJ4PG-00052g-Tn for tls@ietf.org; Thu, 09 Aug 2007 05:34:14 -0400 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IJ4PG-0006hA-7d for tls@ietf.org; Thu, 09 Aug 2007 05:34:14 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l799XrgZ030107; Thu, 9 Aug 2007 12:34:11 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 12:34:08 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Aug 2007 12:34:08 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] TLS 1.2 hash agility Date: Thu, 9 Aug 2007 12:34:07 +0300 Message-ID: In-Reply-To: <46ACCCCB.8000201@pobox.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] TLS 1.2 hash agility Thread-Index: AcfSBNF7OVhlsjbTRSqAbpHRF19ogQIYxI5Q References: <46ABB82D.8090709@pobox.com> <46ACCCCB.8000201@pobox.com> From: To: , X-OriginalArrivalTime: 09 Aug 2007 09:34:08.0569 (UTC) FILETIME=[6F837A90:01C7DA68] X-Nokia-AV: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 (mike-list@pobox.com) wrote: > I think the solution we need is to specifically list each supported > signature algorithm, e.g. >=20 > enum { > rsa_with_md5(0), rsa_with_sha1(1), > rsa_with_sha256(2), rsa_with_sha384(3), > rsa_with_sha512(4), dsa_with_sha1(5), > (65535) > }; >=20 > These may not be specific enough, as I've seen suggestions for, > e.g. rsa_pkcs1v1_5_with_sha1, and I've heard that some algorithms > need parameters, but I think I've made my point. I think your suggestion looks good; it seems to handle the DSA and ECDSA cases better than just a list of hashes, and it's more in TLS style than sending DER-encoded AlgorithmIdentifiers.=20 And then we could change Signature structure to struct { SignatureAlgorithm signature_algorithm; opaque signature_value<0..2^16-1>; } Signature; =20 Eric, what's your opinion? Best regards, Pasi _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Fri Aug 10 16:05:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJaha-0006yg-RB; Fri, 10 Aug 2007 16:03:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IJahZ-0006yW-7R for tls@ietf.org; Fri, 10 Aug 2007 16:03:17 -0400 Received: from web37013.mail.mud.yahoo.com ([209.191.85.98]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1IJahX-0006DV-Gf for tls@ietf.org; Fri, 10 Aug 2007 16:03:16 -0400 Received: (qmail 88690 invoked by uid 60001); 10 Aug 2007 20:03:15 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=bcXXUf2g9vpQMT+PE70tNa4P0szyzdJVuX9Eg5+B1bGI6wq+FQc5Vn2AYmtF+Lc8C1Qq/RuF0qtR1pZCMZU14NkEJJBZxIEZMBwO6xGJWDKGMFdGNj7Lk2UsGT8hwjFQB9ScM3FXae8ucdfFxvvspqIaZHh0bmXQyu/Ww+sfAGw=; X-YMail-OSG: 4gZolE4VM1ltqyC2kEPJI8ttXV1.nqbF9NQPHooosAe3ScAxNUWE4_wL7XhSWq6TJy1Fuv1O0g-- Received: from [198.208.159.19] by web37013.mail.mud.yahoo.com via HTTP; Fri, 10 Aug 2007 13:03:14 PDT Date: Fri, 10 Aug 2007 13:03:14 -0700 (PDT) From: Ken Peirce To: TLS Working Group MIME-Version: 1.0 Message-ID: <956570.88678.qm@web37013.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Subject: [TLS] ECC licensing? 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="===============0791088266==" Errors-To: tls-bounces@lists.ietf.org --===============0791088266== Content-Type: multipart/alternative; boundary="0-944983073-1186776194=:88678" Content-Transfer-Encoding: 8bit --0-944983073-1186776194=:88678 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Thanks for the explanations concerning the point at which compression can take place during session creation. I have another question. Someone has told me that you have to license ECC to be able to use it. I didnt think that this was the case. I believe it was published in 1985. So if there was patent it should have already expired. Is this just FUD? Cheers, Ken --0-944983073-1186776194=:88678 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Thanks for the explanations concerning the point at which compression can take place during session creation. I have another question. Someone has told me that you have to license ECC to be able to use it. I didnt think that this was the case. I believe it was published in 1985. So if there was patent it should have already expired. Is this just FUD?
Cheers,
Ken
 
--0-944983073-1186776194=:88678-- --===============0791088266== 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 --===============0791088266==-- From tls-bounces@lists.ietf.org Mon Aug 13 15:15:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKfMB-0000jZ-Ig; Mon, 13 Aug 2007 15:13:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKfMA-0000jT-Cj for tls@lists.ietf.org; Mon, 13 Aug 2007 15:13:38 -0400 Received: from wa-out-1112.google.com ([209.85.146.176]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKfM9-0001UV-10 for tls@lists.ietf.org; Mon, 13 Aug 2007 15:13:38 -0400 Received: by wa-out-1112.google.com with SMTP id j4so2070621wah for ; Mon, 13 Aug 2007 12:13:35 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=K5Has5SSI5YAXLT2B08MJXRLeo20Lr5Ax6AeqIg6dD/ArSHBx3xbl0ukUH6V5zczrVQVJhTa7fpur4i0LPAytpQZFCbcvNw9mcvrGs/yRteftarMFzuFGWmSzjkcemXQOlwXyJuE9ut4avig86K7/Opc5djgDZU0qWTCp29qkVg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=uMRiOREIprx5cnVS67rKXhWh6WxWNvNC2XQOfoPOkGhCQamrkRTsnTywHqhwL586Gz9UrhJ0tTVhC339PEOvLdo6fmZct4oLKeqPquHb5ICjwHt0tAtJAWtKaLOCdLt7Fmer7W+cJNLGxWOag53rQhI+gQaQzW918FxyLKPMhRM= Received: by 10.114.132.5 with SMTP id f5mr2096753wad.1187032415279; Mon, 13 Aug 2007 12:13:35 -0700 (PDT) Received: by 10.114.205.17 with HTTP; Mon, 13 Aug 2007 12:13:35 -0700 (PDT) Message-ID: Date: Mon, 13 Aug 2007 15:13:35 -0400 From: "Erwin Davis" To: tls@lists.ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [TLS] resources for sniffing TLS packet 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="===============0439327800==" Errors-To: tls-bounces@lists.ietf.org --===============0439327800== Content-Type: multipart/alternative; boundary="----=_Part_7334_7862592.1187032415190" ------=_Part_7334_7862592.1187032415190 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello, I'm looking for any tool/source which is able to sniff/interpret the TLS packet including session establishment and the code with the feeded certificate(s). Thanks for your help, Bests, e ------=_Part_7334_7862592.1187032415190 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hello,

I'm looking for any tool/source which is able to sniff/interpret the TLS packet including session establishment and the code with the feeded certificate(s). Thanks for your help,

Bests,

e


------=_Part_7334_7862592.1187032415190-- --===============0439327800== 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 --===============0439327800==-- From tls-bounces@lists.ietf.org Tue Aug 14 07:15:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKuLX-0004Xl-Jq; Tue, 14 Aug 2007 07:13:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IKuLV-0004XW-LW for tls@lists.ietf.org; Tue, 14 Aug 2007 07:13:57 -0400 Received: from mail.gi-de.com ([193.108.184.25]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IKuLU-0004fq-2g for tls@lists.ietf.org; Tue, 14 Aug 2007 07:13:57 -0400 Received: from notessmtp1.domino.intern [10.4.4.49] by mail.gi-de.com id DUT273UE outgoing id V14WS4QI; 14 Aug 2007 13:13:54 +0200 In-Reply-To: To: tls@lists.ietf.org Subject: Antwort: [TLS] resources for sniffing TLS packet MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: Axel.Heider@gi-de.com Date: Tue, 14 Aug 2007 13:13:53 +0200 X-MIMETrack: Serialize by Router on NOTESSMTP1/SRV/GuD(Release 7.0.2|September 26, 2006) at 14.08.2007 13:13:52, Serialize complete at 14.08.2007 13:13:52 Content-Type: text/plain; charset="US-ASCII" X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: Erwin Davis 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 Erwin, > I'm looking for any tool/source which is able to sniff/interpret > the TLS packet including session establishment and the code with > the feeded certificate(s). Thanks for your help, The latest version of Wireshark can do that quite well. You have to give Wireshark a list of private keys and servers in the protocol preferences for SSL. See Wireshark Wiki for details. Axel _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Aug 15 10:34:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILJv0-0003bJ-He; Wed, 15 Aug 2007 10:32:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1ILJuz-0003bD-3p for tls@lists.ietf.org; Wed, 15 Aug 2007 10:32:17 -0400 Received: from yxa.extundo.com ([83.241.177.38]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ILJux-0006l3-GN for tls@lists.ietf.org; Wed, 15 Aug 2007 10:32:17 -0400 Received: from mocca.josefsson.org (yxa.extundo.com [83.241.177.38]) (authenticated bits=0) by yxa.extundo.com (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l7FEW7Sx017804 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 15 Aug 2007 16:32:08 +0200 X-Hashcash: 1:22:070815:ekr@networkresonance.com::qFUWcqAQiBu0YmFm:BmfZ X-Hashcash: 1:22:070815:msalter@restarea.ncsc.mil::+duYo062MwMRXt2U:Ce3h X-Hashcash: 1:22:070815:tls@lists.ietf.org::WTfOOflBiL0jc+Sd:3jHZ From: Simon Josefsson To: ekr@networkresonance.com, msalter@restarea.ncsc.mil OpenPGP: id=B565716F; url=http://josefsson.org/key.txt Date: Wed, 15 Aug 2007 16:32:07 +0200 Message-ID: <873aykzx5k.fsf@mocca.josefsson.org> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Status: No, score=-1.0 required=4.0 tests=AWL,BAYES_50, FORGED_RCVD_HELO,SPF_PASS 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.0 (/) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Cc: tls@lists.ietf.org Subject: [TLS] Comments on draft-rescorla-tls-opaque-prf-input-00.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 Hi. I have read the document and wrote down some comments, that I try to distill into this e-mail. Take this post for what its worth, an hour or so worth of looking at the document and composing the feedback. I may have misunderstood something, and in that case, I would appreciate clarifications. In general, I believe the document is in good technical shape, and that implementations of it should be possible. The abstract should spell out PRF, I suggest to replace: This document describes a mechanism for using opaque PRF inputs with Transport Layer Security (TLS) and Datagram TLS (DTLS). with This document describes a mechanism for using opaque pseudo-random function (PRF) inputs with Transport Layer Security (TLS) and Datagram TLS (DTLS). The introduction, section 1, could be improved by also mentioning the PRF term. I suggest to change: The client and server each contribute a Random value which is then mixed with secret keying material to produce the final per- association keying material. into: The client and server each contribute a Random value which is then mixed, using a pseudo-random function (PRF), with secret keying material to produce the final per-association keying material. The title of section 3.2 ('PRF Modifications') is miss-leading because the PRF is not modified by this document. What is modified by the document is the algorithm described in section 8.1 of RFC 4346. I suggest to change the title of section 3.2 to 'Modifications to Master Secret Computation'. The observation in the previous paragraph may suggest that a better title for the entire document would be 'Opaque Inputs to Master Secret Computation for TLS'. The document only discuss new PRF inputs to one particular use of the PRF. The document do not discuss new PRF inputs to all PRF computations, which could be inferred from the current title 'Opaque PRF Inputs for TLS'. I got a flawed impression of the goals with the document after reading the title and not having read much of the details in the document. Section 3.2 uses terms 'PMS' and 'MS' without explanation, and there is no references to the appropriate place in RFC 4346 that is modified. I suggest to replace the current paragraph: When the opaque PRF input feature is in use, the opaque PRF input values MUST be mixed into the PRF along with the client and server random values during the PMS->MS conversion. Thus, the PRF becomes: with the following: When the opaque PRF input feature is in use, the opaque PRF input values MUST be mixed into the PRF along with the client and server random values during the pre-master secret to master secret conversion (section 8.1 of RFC 4346). Thus, the step becomes: The final paragraph in section 3.2 reads: Because new extensions may not be introduced in resumed handshakes, mixing in the opaque PRF inputs during the MS->keying material conversion would simply involve mixing in the same material twice. Therefore, the opaque PRF inputs are only used when the PMS is converted into the MS. The statement is not specific to resumed session, as far as I can tell. Further, there is already a section 4.3 that explain the interactions with resumed handshake (a forward reference would have helped me). I believe it would be clearer to drop the reference to resumed handshakes here, and focus on the assertion itself, because it is helpful in understanding the design choice. I suggest to drop the first line, and to add some references and word explanations, making the paragraph read: Mixing in the opaque PRF inputs during master secret to keying material conversion (see section 6.3 of RFC 4346) would simply involve mixing in the same material twice. Therefore, the opaque PRF inputs are only used when the premaster secret is converted into the master secret. See also section 4.3. For symmetry between (all in section 3.1): If a client requires the opaque PRF input feature but the server does not negotiate it, the client SHOULD generate a fatal "handshake_failure" alert. and: In this case, the server should generate a fatal "handshake_failure" alert. I suggest the last 'should' be in upper case. In section 4.1, I suggest to add something like this: This extension enables client and servers to send significant amount of data "out-of-band" to each other, which can be abused to leak information. Finally, I wonder whether the size limit of the opaque prf inputs is appropriate. It is currently limited to 64KB. This is larger than what would be justified by entropy to better seed the PRF, where (if I understand the cryptography properly) you'd typically use 128 or 256 bytes. However, 64KB may be too limited if, as is suggested by the document, the data will be in some pre-agreed format that the client and server can parse and do something intelligible with. This also begs the question whether there should be an optional type-indicator present, to indicate the format of the opaque data? /Simon _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Aug 19 23:44:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMy9R-0006H5-3Q; Sun, 19 Aug 2007 23:42:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IMy9P-0006Gz-Lj for tls@lists.ietf.org; Sun, 19 Aug 2007 23:41:59 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IMy9O-0008Se-Hd for tls@lists.ietf.org; Sun, 19 Aug 2007 23:41:59 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 19 Aug 2007 20:41:58 -0700 X-IronPort-AV: i="4.19,283,1183359600"; d="scan'208"; a="202861920:sNHT60768864" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l7K3fv4B027930; Sun, 19 Aug 2007 20:41:57 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l7K3fvF4008749; Mon, 20 Aug 2007 03:41:57 GMT Received: from xmb-sjc-225.amer.cisco.com ([128.107.191.38]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 19 Aug 2007 20:41:57 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [TLS] RE: RFC 4507bis (Joseph Salowey (jsalowey)) Date: Sun, 19 Aug 2007 20:41:58 -0700 Message-ID: In-Reply-To: <1D526804BA83A2459C60E28CA73ABD9001FC9DE0@TUS1XCHCLUPIN03.enterprise.veritas.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [TLS] RE: RFC 4507bis (Joseph Salowey (jsalowey)) Thread-Index: AcfUVRePRd0P445dQU+ceHtZv6t9ngAFZLyAA5xQI0A= From: "Joseph Salowey \(jsalowey\)" To: "Mark Tillinghast" , X-OriginalArrivalTime: 20 Aug 2007 03:41:57.0345 (UTC) FILETIME=[0EDDD510:01C7E2DC] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=8942; t=1187581317; x=1188445317; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jsalowey@cisco.com; z=From:=20=22Joseph=20Salowey=20\(jsalowey\)=22=20 |Subject:=20RE=3A=20[TLS]=20RE=3A=20=20RFC=204507bis=20(Joseph=20Salowey= 20(jsalowey)) |Sender:=20; bh=1/mzejx7zIUSdRIMxIlB3NSQeX7VWLYwEiEEIWF9IIw=; b=H0drsr7AzXZV6+wAW9cv6RUM5dfZZq9SB8zeP1iD+L77KNCUKZRbQr58MmlxM6lqkFGhS4ws 6ZWIaaZ8mzvJSPAqq+UL6YEU8bmlgslbEJjvBnoy42kv+G25mBd+QXHJ; Authentication-Results: sj-dkim-4; header.From=jsalowey@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: -4.0 (----) X-Scan-Signature: 187ae6c2eea74946c0ab707161f6256d 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 Does anyone object to changing the example ticket integrity to HMAC-SHA-256? If not I'll look into getting this done. =20 Joe=20 > -----Original Message----- > From: Mark Tillinghast [mailto:Mark_Tillinghast@symantec.com]=20 > Sent: Wednesday, August 01, 2007 11:46 AM > To: tls@lists.ietf.org > Subject: [TLS] RE: RFC 4507bis (Joseph Salowey (jsalowey)) >=20 > Hi Joe, >=20 > I am very concerned about sha1 vs sha256. > I have two different certificates with the same signature=20 > complements of Xiaoyun Wang, Yiqun Lisa Yin, and Hongbo Yu. > =20 > Nist guidance I think is along the lines of moving forward,=20 > SHA-256 should be used, TLS 1.2 is a big part of the moving forward. >=20 > To quote Bruce Schneier quoting the NSA "Attacks get better;=20 > they never get worse." >=20 > Mark >=20 >=20 > -----Original Message----- > From: tls-request@lists.ietf.org [mailto:tls-request@lists.ietf.org] > Sent: Wednesday, August 01, 2007 9:00 AM > To: tls@lists.ietf.org > Subject: TLS Digest, Vol 37, Issue 1 >=20 > Send TLS mailing list submissions to > tls@lists.ietf.org >=20 > To subscribe or unsubscribe via the World Wide Web, visit > https://www1.ietf.org/mailman/listinfo/tls > or, via email, send a message with subject or body 'help' to > tls-request@lists.ietf.org >=20 > You can reach the person managing the list at > tls-owner@lists.ietf.org >=20 > When replying, please edit your Subject line so it is more=20 > specific than > "Re: Contents of TLS digest..." >=20 >=20 > Today's Topics: >=20 > 1. RE: RFC 4507bis (Joseph Salowey (jsalowey)) > 2. Re: RFC 4507bis (Mike) >=20 >=20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Tue, 31 Jul 2007 22:17:02 -0700 > From: "Joseph Salowey \(jsalowey\)" > Subject: RE: [TLS] RFC 4507bis > To: "Mike" , > Message-ID: > =09 > > Content-Type: text/plain; charset=3D"us-ascii" >=20 > Hi Mike, >=20 > Thanks for reviewing the document, comments inline below:=20 >=20 > > -----Original Message----- > > From: Mike [mailto:mike-list@pobox.com] > > Sent: Sunday, July 29, 2007 9:58 AM > > To: tls@ietf.org > > Subject: [TLS] RFC 4507bis > >=20 > > I'm working on adding support for RFC 4507 to my code and=20 > have found a >=20 > > few issues with the draft. > >=20 > > - Should the NewSessionTicket message be included > > in the hash used to create/verify the Finished > > message. I believe it should since it's a > > handshake message, but it's not stated anywhere. > > I think it would be a good idea to specifically > > state that it is. > >=20 > [Joe]It is part of the TLS hello message and is therefore=20 > included in the finished message. This is part of the TLS=20 > extensions spec. I'm not sure we need to clarify it here. >=20 >=20 > > - Is it legal for the server to resume a session > > and not provide a NewSessionTicket? The message > > flow I'm referring to would look like this: > >=20 > > Client Server > > ClientHello > > (SessionTicket extension) --> > > ServerHello > > (no SessionTicket extension) > > [ChangeCipherSpec] > > <-- Finished > > [ChangeCipherSpec] > > Finished --> > > Application Data <-> Application Data > >=20 > > If this is not allowed, it should probably be > > stated that when a server resumes a session using > > a SessionTicket, it MUST send an empty Session > > Ticket extension and a NewSessionTicket message > > (optionally with an empty ticket). > >=20 > [Joe] It is legal to not provide a new session ticket if you=20 > do not provide an empty session ticket extension from the=20 > server. However if you include an empty session ticket=20 > extension from the server you must provide a NewSessionTicket=20 > message (which may be empty). Some other reviewers have had=20 > similar comments, is there a place where the text could be clearer? >=20 > > - It may be useful to state that the MAC computation > > in the ticket is over the encrypted contents to > > be able to quickly reject a ticket and not have to > > perform a decryption first. > >=20 > [Joe] This is a implementation detail that I'm not sure we=20 > need to go into in the specification.=20 >=20 > > - Should HMAC-SHA256 be recommended instead of > > HMAC-SHA1? > >=20 > [Joe] I was under the impression that most people were OK with > HMAC-SHA-1 use for the foreseeable future. If this is not=20 > the case we can probably change it to HMAC-SHA-256. >=20 > > - StatePlaintext needs more data fields when TLS > > extensions are used such as max fragment length. > > This should be obvious, but it wouldn't hurt to > > state. > >=20 > > Mike > >=20 > > _______________________________________________ > > TLS mailing list > > TLS@lists.ietf.org > > https://www1.ietf.org/mailman/listinfo/tls > >=20 >=20 >=20 >=20 > ------------------------------ >=20 > Message: 2 > Date: Wed, 01 Aug 2007 07:43:55 -0700 > From: Mike > Subject: Re: [TLS] RFC 4507bis > To: tls@ietf.org > Message-ID: <46B09C2B.70609@pobox.com> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed >=20 > >> - Should the NewSessionTicket message be included > >> in the hash used to create/verify the Finished > >> message. I believe it should since it's a > >> handshake message, but it's not stated anywhere. > >> I think it would be a good idea to specifically > >> state that it is. > >> > > [Joe]It is part of the TLS hello message and is therefore=20 > included in=20 > > the finished message. This is part of the TLS extensions=20 > spec. I'm=20 > > not sure we need to clarify it here. >=20 > I was referring to the NewSessionTicket message sent by the=20 > server to the client just before ChangeCipherSpec. > I think you should state that it is included in the hash used=20 > to create/verify the Finished messages. >=20 > >> - Is it legal for the server to resume a session > >> and not provide a NewSessionTicket? The message > >> flow I'm referring to would look like this: > >> > >> Client Server > >> ClientHello > >> (SessionTicket extension) --> > >> ServerHello > >> (no SessionTicket extension) > >> [ChangeCipherSpec] > >> <-- Finished > >> [ChangeCipherSpec] > >> Finished --> > >> Application Data <-> Application Data > >> > >> If this is not allowed, it should probably be > >> stated that when a server resumes a session using > >> a SessionTicket, it MUST send an empty Session > >> Ticket extension and a NewSessionTicket message > >> (optionally with an empty ticket). > >> > > [Joe] It is legal to not provide a new session ticket if you do not=20 > > provide an empty session ticket extension from the server.=20 > However if=20 > > you include an empty session ticket extension from the=20 > server you must >=20 > > provide a NewSessionTicket message (which may be empty). =20 > Some other=20 > > reviewers have had similar comments, is there a place where=20 > the text=20 > > could be clearer? >=20 > The message flow diagram in the draft that shows session=20 > resumption has the server send an empty SessionTicket=20 > extension. If the message flow above is also allowed (where=20 > no SessionTicket extension is sent by the server), then I=20 > think you should include the diagram in the spec. >=20 > > [Joe] I was under the impression that most people were OK with > > HMAC-SHA-1 use for the foreseeable future. If this is not=20 > the case we >=20 > > can probably change it to HMAC-SHA-256. >=20 > I will leave that up to the experts to decide, but will use=20 > SHA-256 in my code in any case. >=20 > Mike >=20 >=20 >=20 > ------------------------------ >=20 > _______________________________________________ > TLS mailing list > TLS@lists.ietf.org > https://www1.ietf.org/mailman/listinfo/tls >=20 >=20 > End of TLS Digest, Vol 37, Issue 1 > ********************************** >=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 Aug 20 06:24:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN4Ow-0001z4-8x; Mon, 20 Aug 2007 06:22:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN4Ov-0001y5-4k for tls@lists.ietf.org; Mon, 20 Aug 2007 06:22:25 -0400 Received: from nf-out-0910.google.com ([64.233.182.186]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN4Ot-00086m-T0 for tls@lists.ietf.org; Mon, 20 Aug 2007 06:22:25 -0400 Received: by nf-out-0910.google.com with SMTP id 4so728100nfv for ; Mon, 20 Aug 2007 03:22:23 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=VE4N8l56UgEm20w93nOAip1o6IC158hEvOoho1hZf7TPUATyeINXacmxzNxoMZoCQj15ykuELIAt7sSRsEG6iExO/s0yNZW+isjWSiZUenZK13MXREho21roZjVVBXKHCfi7+Z35uULqG/LQXV57b2rZFiQtgovCerkilryJQG0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=NMMvFjv+dgtS+30DLOxdxflnL1W9LZ7qIMyeAnLjeaswMslOv0haREDG01mSPbwEQnFxsSnYWFSbrK/W/pmrndCiD6VornMSCW1OuTLkzQA9WtsMO/Mj4aRxhpz0UUHJE0uCBYijhcAD+1PLmWJnbz47GnNsWhBJl/7iAgBenYo= Received: by 10.86.57.9 with SMTP id f9mr4428172fga.1187605343023; Mon, 20 Aug 2007 03:22:23 -0700 (PDT) Received: by 10.86.57.17 with HTTP; Mon, 20 Aug 2007 03:22:23 -0700 (PDT) Message-ID: <4697c6140708200322q2e7f0cf0l221d6c8833556ade@mail.gmail.com> Date: Mon, 20 Aug 2007 15:52:23 +0530 From: "kalyani Viswanadhapalli" To: tls@lists.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [TLS] hi 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 want the source code of TLS 1.0 for the latest version. We find openssl 0.9.8e is the latest version, but it doesn't consist the definitions of TLSv1_method(), TLSv1_client_method() and TLSv1_server_method() etc. pls send a full-fledged source code of TLS 1.0. Is it possible to implement TLS 1.0 without SSL? _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Mon Aug 20 11:35:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN9Fx-0002zi-6Y; Mon, 20 Aug 2007 11:33:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IN9Fw-0002zY-01 for tls@lists.ietf.org; Mon, 20 Aug 2007 11:33:28 -0400 Received: from sceptre.pobox.com ([207.106.133.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IN9Fu-0008Pc-5m for tls@lists.ietf.org; Mon, 20 Aug 2007 11:33:27 -0400 Received: from sceptre (localhost.localdomain [127.0.0.1]) by sceptre.pobox.com (Postfix) with ESMTP id 7F5302FB; Mon, 20 Aug 2007 11:33:47 -0400 (EDT) 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 sceptre.sasl.smtp.pobox.com (Postfix) with ESMTP id 737B272F7E; Mon, 20 Aug 2007 11:33:43 -0400 (EDT) Message-ID: <46C9B369.2010808@pobox.com> Date: Mon, 20 Aug 2007 08:29:45 -0700 From: Mike User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Simon Josefsson Subject: Re: [TLS] Comments on draft-rescorla-tls-opaque-prf-input-00.txt References: <873aykzx5k.fsf@mocca.josefsson.org> In-Reply-To: <873aykzx5k.fsf@mocca.josefsson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c 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 This I-D is no longer in the repository; is there a plan to renew it? One comment: Why is it necessary for the server's opaque input to be exactly the same length as the client's? Could it be left up to the application to decide if the server's opaque input is acceptable? Mike Simon Josefsson wrote: > Hi. I have read the document and wrote down some comments, that I try > to distill into this e-mail. Take this post for what its worth, an hour > or so worth of looking at the document and composing the feedback. I > may have misunderstood something, and in that case, I would appreciate > clarifications. > > In general, I believe the document is in good technical shape, and that > implementations of it should be possible. > > The abstract should spell out PRF, I suggest to replace: > > This document describes a mechanism for using opaque PRF inputs with > Transport Layer Security (TLS) and Datagram TLS (DTLS). > > with > > This document describes a mechanism for using opaque pseudo-random > function (PRF) inputs with Transport Layer Security (TLS) and > Datagram TLS (DTLS). > > The introduction, section 1, could be improved by also mentioning the > PRF term. I suggest to change: > > The client and server each contribute a Random value which is then > mixed with secret keying material to produce the final per- > association keying material. > > into: > > The client and server each contribute a Random value which is then > mixed, using a pseudo-random function (PRF), with secret keying > material to produce the final per-association keying material. > > The title of section 3.2 ('PRF Modifications') is miss-leading because > the PRF is not modified by this document. What is modified by the > document is the algorithm described in section 8.1 of RFC 4346. I > suggest to change the title of section 3.2 to 'Modifications to Master > Secret Computation'. > > The observation in the previous paragraph may suggest that a better > title for the entire document would be 'Opaque Inputs to Master Secret > Computation for TLS'. The document only discuss new PRF inputs to one > particular use of the PRF. The document do not discuss new PRF inputs > to all PRF computations, which could be inferred from the current title > 'Opaque PRF Inputs for TLS'. I got a flawed impression of the goals > with the document after reading the title and not having read much of > the details in the document. > > Section 3.2 uses terms 'PMS' and 'MS' without explanation, and there is > no references to the appropriate place in RFC 4346 that is modified. I > suggest to replace the current paragraph: > > When the opaque PRF input feature is in use, the opaque PRF input > values MUST be mixed into the PRF along with the client and server > random values during the PMS->MS conversion. Thus, the PRF becomes: > > with the following: > > When the opaque PRF input feature is in use, the opaque PRF input > values MUST be mixed into the PRF along with the client and server > random values during the pre-master secret to master secret > conversion (section 8.1 of RFC 4346). Thus, the step becomes: > > The final paragraph in section 3.2 reads: > > Because new extensions may not be introduced in resumed handshakes, > mixing in the opaque PRF inputs during the MS->keying material > conversion would simply involve mixing in the same material twice. > Therefore, the opaque PRF inputs are only used when the PMS is > converted into the MS. > > The statement is not specific to resumed session, as far as I can tell. > Further, there is already a section 4.3 that explain the interactions > with resumed handshake (a forward reference would have helped me). I > believe it would be clearer to drop the reference to resumed handshakes > here, and focus on the assertion itself, because it is helpful in > understanding the design choice. I suggest to drop the first line, and > to add some references and word explanations, making the paragraph read: > > Mixing in the opaque PRF inputs during master secret to keying > material conversion (see section 6.3 of RFC 4346) would simply > involve mixing in the same material twice. Therefore, the opaque PRF > inputs are only used when the premaster secret is converted into the > master secret. See also section 4.3. > > For symmetry between (all in section 3.1): > > If a client requires the opaque PRF input feature but > the server does not negotiate it, the client SHOULD generate a fatal > "handshake_failure" alert. > > and: > > In this > case, the server should generate a fatal "handshake_failure" alert. > > I suggest the last 'should' be in upper case. > > In section 4.1, I suggest to add something like this: > > This extension enables client and servers to send significant amount > of data "out-of-band" to each other, which can be abused to leak > information. > > Finally, I wonder whether the size limit of the opaque prf inputs is > appropriate. It is currently limited to 64KB. This is larger than what > would be justified by entropy to better seed the PRF, where (if I > understand the cryptography properly) you'd typically use 128 or 256 > bytes. However, 64KB may be too limited if, as is suggested by the > document, the data will be in some pre-agreed format that the client and > server can parse and do something intelligible with. This also begs the > question whether there should be an optional type-indicator present, to > indicate the format of the opaque data? > > /Simon > > _______________________________________________ > 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 Aug 21 01:21:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INM8q-0002Tl-VJ; Tue, 21 Aug 2007 01:19:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INM8p-0002Td-FX for TLS@lists.ietf.org; Tue, 21 Aug 2007 01:18:59 -0400 Received: from mu-out-0910.google.com ([209.85.134.190]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1INM8o-0004Bc-5O for TLS@lists.ietf.org; Tue, 21 Aug 2007 01:18:59 -0400 Received: by mu-out-0910.google.com with SMTP id i10so2150732mue for ; Mon, 20 Aug 2007 22:18:57 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=P7qjwbNY0qaFO7b63+VNJ1X6mVmnt1hZ8et891TApYbZuM9dMu8gu+tMFpAqHuEHuO6abqGiJ3NOXgMN70Jdn8sqVafoVzTfjnTVJOOdFI2gy15RqWhayLfwGW6TGqRoBjqBlFNlpJzIu1I9bTa8j3QcbsKHtFqRU2wSRaGVgbc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=tayVoyBLS/FWZx5B4nnVOPB7lGQEHEL3wE8+htrQuzOIcQWVuLpsuQpUg5liAoISHFp3D0Q12vLXdlcoySW1RF9RQLOCaVwjtnIQIemwF2sWf9r+Ebq3AJoGLNjjwQzPsX3cYb/XAgrXDgaAldb0KUSQljmZmkDNGKRB2Ua8cqI= Received: by 10.86.60.7 with SMTP id i7mr5120164fga.1187673537171; Mon, 20 Aug 2007 22:18:57 -0700 (PDT) Received: by 10.86.57.17 with HTTP; Mon, 20 Aug 2007 22:18:57 -0700 (PDT) Message-ID: <4697c6140708202218h5e021d05h16557baebe18616d@mail.gmail.com> Date: Tue, 21 Aug 2007 10:48:57 +0530 From: "kalyani Viswanadhapalli" To: TLS@lists.ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: Subject: [TLS] hi 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 Good Morning.., If we want to work on TLS 0.9.8, which software we will install? Thanks & Regards kalyani.v _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Wed Aug 22 16:33:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1INwrq-0007Ar-LH; Wed, 22 Aug 2007 16:31:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1INwrp-0007Al-EK for tls@lists.ietf.org; Wed, 22 Aug 2007 16:31:53 -0400 Received: from web37001.mail.mud.yahoo.com ([209.191.85.86]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1INwrp-00037J-4l for tls@lists.ietf.org; Wed, 22 Aug 2007 16:31:53 -0400 Received: (qmail 22152 invoked by uid 60001); 22 Aug 2007 20:31:52 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding:Message-ID; b=MfyBb4yFFCbw2P8sfy3OsxbcF6xuC0OmLYNzCFa0c1tHJ4v1i3HvFl+i8m15vFxjjqZn0ulTsfysmzMuKK36kUAWrCaW6qRVQIq4WN7sKjfPuqg20Yr3smYP1iVYPVomyl5WiUSfB5wIil1p7SKFjZZlw7SNNLnzaaSWbX7s/FQ=; X-YMail-OSG: bM3rinIVM1kSYWUYrHMyxzHO9eGafp_vafOSGAqstv0qN69jFKDhgCa78PPrt.mJkxrJkst9DQ-- Received: from [198.208.159.19] by web37001.mail.mud.yahoo.com via HTTP; Wed, 22 Aug 2007 13:31:52 PDT Date: Wed, 22 Aug 2007 13:31:52 -0700 (PDT) From: Ken Peirce To: tls@lists.ietf.org MIME-Version: 1.0 Message-ID: <678735.20234.qm@web37001.mail.mud.yahoo.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [TLS] TLS 1.0 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: , Content-Type: multipart/mixed; boundary="===============1458094234==" Errors-To: tls-bounces@lists.ietf.org --===============1458094234== Content-Type: multipart/alternative; boundary="0-1859398603-1187814712=:20234" Content-Transfer-Encoding: 8bit --0-1859398603-1187814712=:20234 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Is there any reason an implementation of TLS 1.0 couldn't use the TLS_DHE_PSK_WITH_AES_128_CBC_SHA cipher suite. Cheers, Ken --0-1859398603-1187814712=:20234 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Is there any reason an implementation of TLS 1.0 couldn't use the     TLS_DHE_PSK_WITH_AES_128_CBC_SHA   cipher suite.
 
Cheers,
Ken
 
--0-1859398603-1187814712=:20234-- --===============1458094234== 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 --===============1458094234==-- From tls-bounces@lists.ietf.org Wed Aug 22 21:36:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO1aw-0007Qk-JT; Wed, 22 Aug 2007 21:34:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IO1av-0007Qf-GZ for tls@lists.ietf.org; Wed, 22 Aug 2007 21:34:45 -0400 Received: from rune.pobox.com ([208.210.124.79]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IO1av-0001gR-9z for tls@lists.ietf.org; Wed, 22 Aug 2007 21:34:45 -0400 Received: from rune (localhost [127.0.0.1]) by rune.pobox.com (Postfix) with ESMTP id DE88C12685A for ; Wed, 22 Aug 2007 21:35:06 -0400 (EDT) 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 AFBFC126859 for ; Wed, 22 Aug 2007 21:35:06 -0400 (EDT) Message-ID: <46CCE38D.6060603@pobox.com> Date: Wed, 22 Aug 2007 18:31:57 -0700 From: Mike User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: tls@lists.ietf.org Subject: Re: [TLS] TLS 1.0 question References: <678735.20234.qm@web37001.mail.mud.yahoo.com> In-Reply-To: <678735.20234.qm@web37001.mail.mud.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 > Is there any reason an implementation of TLS 1.0 couldn't use the > TLS_DHE_PSK_WITH_AES_128_CBC_SHA cipher suite. No. As long as the cipher suite doesn't require features of a future version, you can use it. You could even use it with SSLv3 since it doesn't require extensions. Note that there are some new cipher suites that use AEAD encryption with authentication, and thus can only be used with TLS 1.2 (or later). Mike _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Sun Aug 26 21:05:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPSzy-0007Yk-53; Sun, 26 Aug 2007 21:02:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPSzx-0007Ye-6V for tls@lists.ietf.org; Sun, 26 Aug 2007 21:02:33 -0400 Received: from ccaix.jsums.edu ([143.132.8.108]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPSzv-0000ND-C5 for tls@lists.ietf.org; Sun, 26 Aug 2007 21:02:32 -0400 Received: from webmail.jsums.edu ([143.132.8.100]) by ccaix.jsums.edu (8.13.1/8.13.1) with ESMTP id l7R12TK3011879; Sun, 26 Aug 2007 20:02:29 -0500 Received: from 172.163.29.210 (SquirrelMail authenticated user nmeghanathan) by webmail.jsums.edu with HTTP; Sun, 26 Aug 2007 20:02:29 -0500 (CDT) Message-ID: <1690.172.163.29.210.1188176549.squirrel@webmail.jsums.edu> Date: Sun, 26 Aug 2007 20:02:29 -0500 (CDT) From: nmeghanathan@jsums.edu To: tls@lists.ietf.org User-Agent: SquirrelMail/1.4.8-4.el4.centos MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.2 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: iaria.announce@gmail.com Subject: [TLS] ICQNM [QSEC] Call for Papers 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 Invitation, During ICQNM 2008 we organize a special event on " Quantum Security " , [QSEC]. The Second International Conference on Quantum, Nano, and Micro Technologies ICQNM 2008 February 10-15, 2008 - Sainte Luce, Martinique Site: http://www.iaria.org/conferences2008/ICQNM08.html Submission: http://www.iaria.org/conferences2008/SubmitICQNM08.html Important deadlines: Submission deadline: September 14, 2007 Notification of acceptance: October 15, 2007 Registration/camera ready: November 5, 2007 Please consider to contribute and distribute to the appropriate groups the invitation for submission to the special event on " Quantum Security " , [QSEC]. Topics to be considered (but not limited to): Quantum cryptographic systems Quantum key distribution primitives Security of QKD protocols Privacy and authentication in QKD based networks Quantum Cryptograhpic error-correcting codes Quantum cheating Attacking QKD devices Quantum correlations Current limitations of QKD based communication Reasoning about QKD security Security frameworks for QKD environments QKD based networks security vulnerabilities Applications of QKD systems QSEC Co-Chairs: Masahito Hayashi, Japan Science and Technology Agency, Japan Christian Kollmitzer, ARC Seibersdorf Research GmbH, Austria ====================== _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls From tls-bounces@lists.ietf.org Tue Aug 28 01:48:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPttt-00005g-5q; Tue, 28 Aug 2007 01:46:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IPttr-00005b-9o for tls@lists.ietf.org; Tue, 28 Aug 2007 01:46:03 -0400 Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=barracuda.intoto.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IPttp-0001U2-RM for tls@lists.ietf.org; Tue, 28 Aug 2007 01:46:03 -0400 Received: from angel.intoto.com (smtp.intoto.com [10.1.5.29]) by barracuda.intoto.com (Spam Firewall) with ESMTP id C4C236CA for ; Mon, 27 Aug 2007 22:46:00 -0700 (PDT) Received: from brahma.hyd.intoto.com (intotoind.com [172.16.1.10]) by angel.intoto.com (8.13.1/8.13.1) with ESMTP id l7S5jxW3011521 for ; Mon, 27 Aug 2007 22:46:00 -0700 Received: from Babu.intoto.com (emb.hyd.intoto.com [172.16.3.102] (may be forged)) by brahma.hyd.intoto.com (8.13.1/8.13.1) with ESMTP id l7S5iRb1026327 for ; Tue, 28 Aug 2007 11:14:30 +0530 Message-Id: <200708280544.l7S5iRb1026327@brahma.hyd.intoto.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 28 Aug 2007 11:15:54 +0530 To: tls@lists.ietf.org From: "Babu.N" Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.62 on 172.16.1.10 X-Spam-Score: 0.1 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Subject: [TLS] TLS extension for Proxies to transfer original Server certificate 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="===============0236585068==" Errors-To: tls-bounces@lists.ietf.org --===============0236585068== Content-Type: multipart/alternative; boundary="=====================_88841734==.ALT" --=====================_88841734==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, I have submitted a draft on " TLS extension for Proxies to transfer Server certificate ":http://www.ietf.org/internet-drafts/draft-babu-serv-cert-trans-from-proxy-00.txt Intercepting transparent proxies splice the client-Server connection into two connections: Client-Proxy connection, Proxy-server connection. On Client-Proxy connection, proxy sends it's certificate to the client. As client is generally (in such a scenario) pre-configured to accept proxy's certificate, client accepts and proceeds further with the connection. On Proxy-Server connection, server sends its certificate to the proxy. Proxy typically doesn't possess the information (like MX domain name in case of SMTP) required to validate the certificate. The certificate validation is at times very complex & hence it is better to offload this responsibility to the original client itself. This document addresses this issue by extending TLS to let proxy send server's certificate to the client for validation and suggests how client can indicate certificate validation result to the proxy. Based on the client's decision, proxy can determine whether to proceed/terminate the connection. Like to hear feedback on this. Thanks, Babu ******************************************************************************** This email message (including any attachments) is for the sole use of the intended recipient(s) and may contain confidential, proprietary and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please immediately notify the sender by reply email and destroy all copies of the original message. Thank you. Intoto Inc. --=====================_88841734==.ALT Content-Type: text/html; charset="us-ascii" Hi,

I have submitted a draft on "
TLS extension for Proxies to transfer Server certificate
": http://www.ietf.org/internet-drafts/draft-babu-serv-cert-trans-from-proxy-00.txt

Intercepting transparent proxies splice the client-Server
connection into two connections: Client-Proxy connection, Proxy-server
connection. On Client-Proxy connection, proxy sends it's certificate to
the client. As client is generally (in such a scenario) pre-configured to
accept proxy's certificate, client accepts and proceeds further with the
connection. On Proxy-Server connection, server sends its certificate to
the proxy. Proxy typically doesn't possess the information (like MX
domain name in case of SMTP) required to validate the certificate. The
certificate validation is at times very complex & hence it is better
to offload this responsibility to the original client itself.

This document addresses this issue by extending TLS to let proxy send
server's certificate to the client for validation and suggests how client
can indicate certificate validation result to the proxy. Based on the
client's decision, proxy can determine whether to proceed/terminate the
connection.
Like to hear feedback on this.


Thanks,
Babu
--=====================_88841734==.ALT-- --===============0236585068== 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 --===============0236585068==-- From tls-bounces@lists.ietf.org Thu Aug 30 13:06:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQnRz-0000zI-Lo; Thu, 30 Aug 2007 13:04:59 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQnRv-0000Zb-02; Thu, 30 Aug 2007 13:04:55 -0400 Received: from ns4.neustar.com ([156.154.24.139]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IQnRu-0007Rq-Lx; Thu, 30 Aug 2007 13:04:54 -0400 Received: from stiedprstage1.ietf.org (stiedprstage1.va.neustar.com [10.31.47.10]) by ns4.neustar.com (Postfix) with ESMTP id 89D122AC7E; Thu, 30 Aug 2007 17:04:24 +0000 (GMT) Received: from ietf by stiedprstage1.ietf.org with local (Exim 4.43) id 1IQnRQ-0007Vc-6b; Thu, 30 Aug 2007 13:04:24 -0400 X-test-idtracker: no From: The IESG To: IETF-Announce Message-Id: Date: Thu, 30 Aug 2007 13:04:24 -0400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Internet Architecture Board , tls mailing list , tls chair , RFC Editor Subject: [TLS] Document Action: 'Using SRP for TLS Authentication' to Informational RFC 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 IESG has approved the following document: - 'Using SRP for TLS Authentication ' as an Informational RFC This document is the product of the Transport Layer Security Working Group. The IESG contact persons are Tim Polk and Sam Hartman. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tls-srp-14.txt Technical Summary This document adds Secure Remote Password (SRP) based authentication to TLS. Working Group Summary This document is a product of the Transport Layer Security (TLS) Working Group. The document had significant review and reflects the consensus of the working group. Protocol Quality Tim Polk reviewed this document for the IESG. RFC Editor Note Please replace paragraph 1 of Section 2.1 as described below. OLD: The version of SRP used here is sometimes referred to as "SRP-6" [SRP-6]. This version is a slight improvement over "SRP-3", which was described in [SRP] and [SRP-RFC]. NEW: The version of SRP used here is sometimes referred to as "SRP-6" [SRP-6]. This version is a slight improvement over "SRP-3", which was described in [SRP] and [SRP-RFC]. For convenience, this document and [SRP-RFC] include the details necessary to implement SRP-6; [SRP-6] is cited for informative purposes only. _______________________________________________ TLS mailing list TLS@lists.ietf.org https://www1.ietf.org/mailman/listinfo/tls