On 1 August 2013 17:21, Alistair Crooks <agc@pkgsrc.org> wrote:

On Thu, Aug 01, 2013 at 12= :04:26PM +0100, Ben Laurie wrote:
> =A0 =A0We've finally brought the CT

> =A0 =A0site, [1]http://www.certificate-transparency.org/, back u= p to speed.
> =A0 =A0Comments welcome!

Dogfooding, I'd kind of expected port 443?

Fair point, though this is only info about CT, not CT itself.=A0

--001a11c3b8344d119f04e2e56cc7-- From iesg-secretary@ietf.org Fri Aug 2 00:23:51 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0E9611E8279; Fri, 2 Aug 2013 00:23:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LIt5aOIsO72Z; Fri, 2 Aug 2013 00:23:51 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0567511E81E3; Fri, 2 Aug 2013 00:23:51 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Sender: Message-ID: <20130802072350.14846.84073.idtracker@ietfa.amsl.com> Date: Fri, 02 Aug 2013 00:23:50 -0700 Cc: tls@ietf.org Subject: [TLS] Last Call: (Out-of-Band Public Key Validation for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 07:23:51 -0000 The IESG has received a request from the Transport Layer Security WG (tls) to consider the following document: - 'Out-of-Band Public Key Validation for Transport Layer Security (TLS)' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2013-08-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document specifies a new certificate type and two TLS extensions, one for the client and one for the server, for exchanging raw public keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) for use with out-of-band public key validation. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-tls-oob-pubkey/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-tls-oob-pubkey/ballot/ No IPR declarations have been submitted directly on this I-D. From agc@nef.pbox.org Thu Aug 1 09:21:40 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33C8C11E8121; Thu, 1 Aug 2013 09:21:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MsdBaZI0xpLf; Thu, 1 Aug 2013 09:21:38 -0700 (PDT) Received: from nef.pbox.org (ns.pbox.org [IPv6:2001:41d0:1:e836::1]) by ietfa.amsl.com (Postfix) with ESMTP id F0CD611E810A; Thu, 1 Aug 2013 09:21:37 -0700 (PDT) Received: from nef.pbox.org (localhost [127.0.0.1]) by nef.pbox.org (8.14.5/8.14.5/) with ESMTP id r71GLXmw015050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 1 Aug 2013 18:21:33 +0200 (CEST) Received: (from agc@localhost) by nef.pbox.org (8.14.5/8.14.5/Submit) id r71GLVks029988; Thu, 1 Aug 2013 18:21:31 +0200 (CEST) Date: Thu, 1 Aug 2013 18:21:31 +0200 From: Alistair Crooks To: Ben Laurie Message-ID: <20130801162131.GT12793@nef.pbox.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-PGP-Fingerprint: D415 9DEB 336D E4CC CDFA 00CD 1B68 DCFC C059 6823 User-Agent: Mutt/1.5.21 (2010-09-15) X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.4.3 (nef.pbox.org [0.0.0.0]); Thu, 01 Aug 2013 18:21:34 +0200 (CEST) X-Mailman-Approved-At: Fri, 02 Aug 2013 00:52:43 -0700 Cc: "therightkey@ietf.org" , "tls@ietf.org" Subject: Re: [TLS] [therightkey] Revamped CT site X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 16:22:45 -0000 On Thu, Aug 01, 2013 at 12:04:26PM +0100, Ben Laurie wrote: > We've finally brought the CT > site, [1]http://www.certificate-transparency.org/, back up to speed. > Comments welcome! Dogfooding, I'd kind of expected port 443? From balfanz@google.com Fri Aug 2 03:10:25 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C89C11E828C for ; Fri, 2 Aug 2013 03:10:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZT5kn-9dlwR for ; Fri, 2 Aug 2013 03:10:24 -0700 (PDT) Received: from mail-ob0-x234.google.com (mail-ob0-x234.google.com [IPv6:2607:f8b0:4003:c01::234]) by ietfa.amsl.com (Postfix) with ESMTP id 5D84C11E8210 for ; Fri, 2 Aug 2013 03:10:24 -0700 (PDT) Received: by mail-ob0-f180.google.com with SMTP id up14so793658obb.25 for ; Fri, 02 Aug 2013 03:10:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=RRykl+aAUfZFGgjPXVArwe6SEYhjpUbo9Ek7YKz5w7I=; b=mAfopTY1ogOMksk0hnt1FkCBacWjeyFcbRB0KQjooA+jDipu30Db2PG+0Qcbkwmlu9 dWAPpR6wI9IYKqE6nJZzX5pMa0O2pi2urDaWvO25RmBUYmvCIg20CWBXMO21ZqTHsq9N YehsKlJkKoUu9Crqe5JzxZFSGwi4ualERE20R2vCQ8BfvT7yUkg2oFXsbdXSCzvEkGHQ FKQs7fKUS+OgS43amcK6ngpOZub6j9ciYi7oRCmyM7lTQyaQuwlZzAOyEomZZgKujX0h NVw6xfAbEECNkq2knYlRsGlbDQFD52/bwuDhYmpi07b60e3H4RpjWYYz7SRl588Km2AF jrgw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=RRykl+aAUfZFGgjPXVArwe6SEYhjpUbo9Ek7YKz5w7I=; b=osAQYZotB9+5CUdnztyYkYLQjVjN1z13fpMkvtIuuMXQRsoNMzjDbHVpwrdVnEwfIx v/hV2WtqpWftzJCdzn7LLmq2zomxGITDxjzCWqeerzGkxgu6c3if4N7lcbg5IMY3Iwhx n2yjqaOhVP9uTvT6ibIRUgmN8eLEg2R87wUikl5/8wJVHmCgkS7kzhwGppBU0jdXqdkY nWjYMHM3/VLYvOSGGNJ6SdkeKKuI5c+t/MNRBCiXXuoJieSzJD690Ur17ts9RyrVqC67 0RnLsgbVrH3RzMRTcZFgvVKhU787gP+W302ygm1OlLVqIiEwu1Q9lCqiGuGmi0tEXTUz T4zg== X-Gm-Message-State: ALoCoQmBR2pB0SYG3Vf42jRUUiccgl/U6SF8aUdZGC7mML4xujh8hdt/U0tWza7DGkpFCqrfa0KfxdioD8d/Mw1kL1JSuy74kHddztKe4QbDVzcRf9yQ0Dc+DkGTZsDKA8431HnLOVhmge1WYiz5D0/swaG4mXCGmsmftvUcdSViQjKFdV6ZjNNy2gio+GntjLJHn/h5c1l1 MIME-Version: 1.0 X-Received: by 10.50.16.102 with SMTP id f6mr221123igd.41.1375438223742; Fri, 02 Aug 2013 03:10:23 -0700 (PDT) Received: by 10.64.33.107 with HTTP; Fri, 2 Aug 2013 03:10:23 -0700 (PDT) Date: Fri, 2 Aug 2013 03:10:23 -0700 Message-ID: From: Dirk Balfanz To: IETF TLS WG Content-Type: multipart/alternative; boundary=047d7bdc0cf0bcb44204e2f42a67 Subject: [TLS] channel id and oob X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Aug 2013 10:10:25 -0000 --047d7bdc0cf0bcb44204e2f42a67 Content-Type: text/plain; charset=ISO-8859-1 Hi guys, I was asked to write a quick analysis of draft-ietf-tls-oob-pubkey, and whether it can be applied to the use cases we have in mind for Channel ID. My conclusion is that it can not, or that the necessary modifications to the OOB draft would be too substantial to be considered during Last Call. First, the similarities: both proposals allow the client to prove possession of a key pair. The fact that this proof-of-possession is forthcoming is negotiated using the TLS extension mechanism (during ClientHello/ServerHello). Now for the differences: - We don't want the client public key to be sent in the clear. It's a client identifier, and shouldn't be known to anyone but the client and the server. - We don't want the proof-of-keypair-possession to be part of the session state, for two reasons: - It blows up the session state, with ramifications on the size of the fleet of servers that cache this information. Remember that in our use case, we don't intend this to be used for the occasional client that wants to use non-password authentication with the server; it's designed to be used by _every_ client talking to big service providers like Google. Raw public keys are of course smaller than full certificates, but they still represent a significant increase in the size of session state. - We don't want someone who is not actually wielding the private key of the keypair to make it appear to the server as if they were in control of that private key. Session resumption, however, gives you that power: Let's assume that the private key of the keypair sits in a hardware-protected secure element, and is therefore out of reach of malware. Master secrets and other session information, however, is very likely kept in RAM and therefore available to thieves. If such a thief extracts the session data from the client and resumes the session, the server will treat the thief as the holder of the original private key. If the proof-of-keypair possession is explicitly declared not part of the session, then a client has to re-prove possession of the keypair even during abbreviated handshakes. Thus, a thief of session secrets (but not of the private key) won't be able to convince a server that it is in control of that private key. The oob-draft keeps the raw key in the session state, thus inheriting this problem with session state and session resumption. - Channel ID keys are different from key material sent in the Certificate message, and the certificate message shouldn't be overloaded with this new semantics: Key material presented in the Certificate message (even if it's a raw key) presumably carries some semantics for the application: "this is a certain user", "this is an enterprise-issued machine", etc., while the Channel-ID keys are always self-generated and their semantics include (among other things) "this is the key that will be nuked when the user presses the 'reset my browsing state' button". It makes for tricky implementations when those two different semantics get mapped to the same protocol message. More importantly, applications may want to do both: authenticate a user with a client cert, and then set a channel-bound cookie as a result of the authentication. You can't do that if you only have one proof-of-possession available in the handshake. As mentioned above, I don't really see how this issues could possibly be addressed within the draft-ietf-tls-oob-pubkey draft, especially since it's in last-call. Just the first point above alone seemed to be something that folks didn't want to touch until TLS 1.3. Thoughts? Dirk. --047d7bdc0cf0bcb44204e2f42a67 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi guys,=A0

I was asked to write a quic= k analysis of=A0draft-ietf-tls-oob-pubkey, and whether it can be applied to= the use cases we have in mind for Channel ID.

My = conclusion is that it can not, or that the necessary modifications to the O= OB draft would be too substantial to be considered during Last Call.

First, the similarities: both proposals allow the clien= t to prove possession of a key pair. The fact that this proof-of-possession= is forthcoming is negotiated using the TLS extension mechanism (during Cli= entHello/ServerHello).

Now for the differences:

We don't= want the client public key to be sent in the clear. It's a client iden= tifier, and shouldn't be known to anyone but the client and the server.=
We don't want the proof-of-keypair-possession to be part o= f the session state, for two reasons:

It blows up the session s= tate, with ramifications on the size of the fleet of servers that cache thi= s information. Remember that in our use case, we don't intend this to b= e used for the occasional client that wants to use non-password authenticat= ion with the server; it's designed to be used by _every_ client talking= to big service providers like Google. Raw public keys are of course smalle= r than full certificates, but they still represent a significant increase i= n the size of session state.
We don't want someone who is not actually wielding the private key = of the keypair to make it appear to the server as if they were in control o= f that private key. Session resumption, however, gives you that power: Let&= #39;s assume that the private key of the keypair sits in a hardware-protect= ed secure element, and is therefore out of reach of malware. Master secrets= and other session information, however, is very likely kept in RAM and the= refore available to thieves. If such a thief extracts the session data from= the client and resumes the session, the server will treat the thief as the= holder of the original private key. If the proof-of-keypair possession is = explicitly declared not part of the session, then a client has to re-prove = possession of the keypair even during abbreviated handshakes. Thus, a thief= of session secrets (but not of the private key) won't be able to convi= nce a server that it is in control of that private key.

The oob-draft keeps the raw key in the session state, = thus inheriting this problem with session state and session resumption.

Channel ID keys are different from key= material sent in the Certificate message, and the certificate message shou= ldn't be overloaded with this new semantics: Key material presented in = the Certificate message=A0(even if it's a raw key)=A0presumably carries= some semantics for the application: "this is a certain user", &q= uot;this is an enterprise-issued machine", etc., while the Channel-ID = keys are always self-generated and their semantics include (among other thi= ngs) "this is the key that will be nuked when the user presses the = 9;reset my browsing state' button". It makes for tricky implementa= tions when those two different semantics get mapped to the same protocol me= ssage. More importantly, applications may want to do both: authenticate a u= ser with a client cert, and then set a channel-bound cookie as a result of = the authentication. You can't do that if you only have one proof-of-pos= session available in the handshake.

As mentioned above, I don't really see how this issues could = possibly be addressed within the draft-ietf-tls-oob-pubkey draft, especiall= y since it's in last-call. Just the first point above alone seemed to b= e something that folks didn't want to touch until TLS 1.3.

Thoughts?

Dirk.

--047d7bdc0cf0bcb44204e2f42a67-- From benl@google.com Sat Aug 3 06:43:22 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A61521F9D89 for ; Sat, 3 Aug 2013 06:43:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.98 X-Spam-Level: X-Spam-Status: No, score=-0.98 tagged_above=-999 required=5 tests=[AWL=-0.862, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5v6Xt4KQso33 for ; Sat, 3 Aug 2013 06:43:22 -0700 (PDT) Received: from mail-qc0-x22d.google.com (mail-qc0-x22d.google.com [IPv6:2607:f8b0:400d:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 350A121F9D95 for ; Sat, 3 Aug 2013 06:43:19 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id z10so859756qcx.32 for ; Sat, 03 Aug 2013 06:43:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=uREHhji4YXbMUfhDlPNsW3mDABcyw4VI7eQWR9dUtJk=; b=XXmQHR7ltPWf6OgOkajhqUlo2M4+4mfst+TUdnNLvZW0OrLGuudlRGXD+5k9aJlcwq 3SZpkDPvS96UzM+S9v5yl3lHpniGstj//OojrLNsjmDdd1QTiashDhfHMlSlOqY5dx/H pQjBO4bzMFIqlL5uG6vQTUG/WGXBQjB8XDaF6cp8XX3Zlscn+pbSYqvxfN8CSVLASquh 9VeES7RF+mcx4Bg+pcQFR+DuKfULaGcFDtk4asq3UQHlVOxPTM1OUkF+8oCpFxFK9Dz+ ZT/OGXJx+WdBXg53KpoK+4Cq+cYODtS7sqn4MwoFV1vvz11zR28GSKrj++P6PHV8peTD ENfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=uREHhji4YXbMUfhDlPNsW3mDABcyw4VI7eQWR9dUtJk=; b=WnXMMOwZS2hIwZTF2jixsmYM64v0zJCTnWOfwotJnW8oJswbJcD7eASd552TP9Jcta /sZnrRK9Rz2zDbOlWAwuN5812oV1/HmIViQmUoeHMqnayDe/CzdoF3L6NAvuhBI9CXG9 l5m5hASMtW9y6LAvRl9gxxGJ1Rsg4/XtJzkGHO6MM8baUEvM6FTO0Y3s3vXdS78YN1y7 YSYbXjtQ2LX5AblqNOhcnTuOwpUmtljVDMy/FPpj7HgrlffrB7pV0c6hwulPEBR26gRP r7mhhv+yTEko+uJECMqe1neZQccE778LWXcJL4gf5oZxaOBeOSnXZHwDPblrpsqrPc4L mUyQ== MIME-Version: 1.0 X-Received: by 10.224.21.202 with SMTP id k10mr17593830qab.10.1375537398617; Sat, 03 Aug 2013 06:43:18 -0700 (PDT) Received: by 10.229.169.196 with HTTP; Sat, 3 Aug 2013 06:43:18 -0700 (PDT) Date: Sat, 3 Aug 2013 14:43:18 +0100 Message-ID: From: Ben Laurie To: "tls@ietf.org" , IETF DANE WG list , certificate-transparency@googlegroups.com, "therightkey@ietf.org" Content-Type: multipart/alternative; boundary=047d7bf0c10c05508f04e30b4266 X-Gm-Message-State: ALoCoQlp+jFwzufKRzYpSsKF3elJ1NDMwIzEsvLNGsgrn6uMdLpPcljy6kDd3HHQYZ7tNSVuVp4V3C959ljjQaA8aaw4O/syX+7s2GloZVpxBU/xbKP5DZp/5427TGK27v1zWZl05LTLzmgd1A696PNph/J4ibqRa9iBR0yxmcKLFMYzs0+YpuEFL5ZOqwbhRgZvzylchWwY Subject: [TLS] Certificate Transparency Hack Day: Weds Aug 28th X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Aug 2013 13:43:22 -0000 --047d7bf0c10c05508f04e30b4266 Content-Type: text/plain; charset=ISO-8859-1 We've set the date: Weds Aug 28th at Google's London office. More information to follow soon. --047d7bf0c10c05508f04e30b4266 Content-Type: text/html; charset=ISO-8859-1

We've set the date: Weds Aug 28th at Google's London office.

More information to follow soon.

--047d7bf0c10c05508f04e30b4266-- From agl@google.com Tue Aug 6 08:25:43 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF88821F9EB8 for ; Tue, 6 Aug 2013 08:25:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.453 X-Spam-Level: X-Spam-Status: No, score=-0.453 tagged_above=-999 required=5 tests=[AWL=-1.524, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001, SARE_MLB_Stock6=1.56] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9UBi42tESll for ; Tue, 6 Aug 2013 08:25:43 -0700 (PDT) Received: from mail-oa0-x231.google.com (mail-oa0-x231.google.com [IPv6:2607:f8b0:4003:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id D123221F9C53 for ; Tue, 6 Aug 2013 08:25:33 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id n10so983933oag.36 for ; Tue, 06 Aug 2013 08:25:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nvn3xwThZWieF0TOJAq80oa+50onmZwlmwmHTiNhBRY=; b=KHrsL3j26TxsU/2838d7iHvTW5UiKM1gregkvyexwkOaOYyKJgiVjPTSNE2yte97aC rbv3ii0PNs+SXhm9OPihRRLj5orY7YBx+39KMgPT8/wol+kU61zCE2ZRJ275I/r7Cu92 k6sZq8vfso4A62sqh5U0PeAo/8UCPrSBtM5WdpNQHcvZFR11iKPsjlX6O0vvzecKK6W4 jKYfMnoMqcbdDH1bNX+V0lUu3EbQqRWvEKZiI0rKaC7x8xEP1G+SROeiMWk8x23ynyV6 rjZ8+CqcZC3QIwI2/CYNo2oUuPZL9ThhKQrDLXChzl2VwnwAG+t81E4zL6vZb3hfNiOm qgog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=nvn3xwThZWieF0TOJAq80oa+50onmZwlmwmHTiNhBRY=; b=pNqLjwY+/epkM4f3ErWQmvoLDCJDGZiXRuH0mmSE/I8qgo87tPSA3OdCmAjSkAh8Y3 sDwitMjXwosl7zbxOBhhS3tuCUMaAXICuIikflb0/tfBpj6M7hAfF8YeY3ADdJxlT5BO QrxS0RNVRTDMRQcAt7sE3+o71hfekhZKWYebacQzhyPyaMDO4aw/uNehf9BU7u7qiD3D sQQWhWgViJWOk8Up0OIM6RV9+ToOtVXzgI9uDfN35z/tbJDwk6p6aj3A+NFctHSb3Yc4 9RxMAvvP91fosid316KhspGI4W3DvbPNhxUzl+RQ9va6/jkD+ICEHhdVEeg0OY0voGAQ HXiQ== X-Gm-Message-State: ALoCoQkTJrs7XCtdeOPZESh6ylZWX3HmoaBXV+6B6DxPqSXD2rc21Nijmq5USw1wfkVQclcZZ33LMteGxN5KVuL/+nF/8cF0IU+upA5uN4ZCODvH5/Bsamw1PsuoK5oP2UpclZ3n9aGziSUZ5A4X74rsS0F/IkNdQtd/CNjxAOzFiISn2HH+zSPX/rW/wEt4WE5a5+s91+ww X-Received: by 10.60.42.168 with SMTP id p8mr1411672oel.73.1375802733160; Tue, 06 Aug 2013 08:25:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.111.66 with HTTP; Tue, 6 Aug 2013 08:25:12 -0700 (PDT) In-Reply-To: References: <23D5606B-9225-4428-99AA-EC66C93D4088@krovetz.net> From: Adam Langley Date: Tue, 6 Aug 2013 11:25:12 -0400 Message-ID: To: Ted Krovetz Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Salsa20 and Poly1305 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 15:25:43 -0000 On Tue, Jul 30, 2013 at 10:45 AM, Adam Langley wrote: > I will try to repeat the above benchmarks for VMAC this week. (And, hopefully, run some tests on ARM.) Recap, to authenticate 1K of data: UMAC96 (with AES for nonce generation, since Nikos suggested that was the intended design previously): 9146ns HMAC-SHA1: 3667ns Poly1305: 561ns On the same machine (E5-2690@2.90GHz with Hyperthreading and Turboboost disabled), with VMAC code from fastcrypto.org: VMAC (128-bit, with AES calls removed in order to better compare to Poly1305): 270ns with 248 bytes of memory On a Cortex-A8 (specifically a Galaxy Nexus) using Linaro GCC 4.7: VMAC (128-bit, with AES calls removed): 13203ns with 248 bytes of memory Poly1305 (code from SUPERCOP): 3567ns For VMAC I used ARM optimised code provided by Ted Krovetz. Other, random measurements: VMAC (128-bit, AES for nonces, Intel): 368ns with 424 bytes of memory and 1308ns one-time key schedule. VMAC (64-bit, no AES, Intel): 138ns, 360 bytes of memory. VMAC (64-bit, AES, Intel): 229ns, 360 bytes of memory. VMAC (128-bit, AES, ARM): 14322ns, 424 bytes of memory For the ARM measurements I was careful to do them with the screen on and unlocked. Android reduces the clock speed when the phone is `asleep'. When measuring VMAC "with AES", I used "rijndael-alg-fst.c", not OpenSSL. When removing AES from VMAC I just removed all AES calls and AES related elements of the context structure. That's not intended to be a real design, but a reasonable simulation for the purposes of timing. Poly1305 is very fast on ARM, but VMAC is twice as fast on servers at the cost of a bit of memory. I think I'm still leaning towards Poly1305, but I could be persuaded by VMAC, it's very impressive. Cheers AGL From agl@google.com Tue Aug 6 09:38:40 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39C7F21F9F3A for ; Tue, 6 Aug 2013 09:38:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.673 X-Spam-Level: X-Spam-Status: No, score=-1.673 tagged_above=-999 required=5 tests=[AWL=0.305, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xBOAJGQWTGTg for ; Tue, 6 Aug 2013 09:38:39 -0700 (PDT) Received: from mail-ob0-x233.google.com (mail-ob0-x233.google.com [IPv6:2607:f8b0:4003:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id CA78221F9F59 for ; Tue, 6 Aug 2013 09:38:39 -0700 (PDT) Received: by mail-ob0-f179.google.com with SMTP id fb19so1347803obc.38 for ; Tue, 06 Aug 2013 09:38:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=nz2yOWY7BTUn8t1QxsTeTnXspTIpgAFcUR58QPT86AE=; b=SgC8HRSDA3O8JFigm3cszKlL11VxbVfLC3f6acO079iqtU8f25R0ZgYtIGnNAeX71l 9Tpwf1s7xnNS2JBLUBxZc99m9jIiWsaFpeosMFxYXadxDuGMVMoOWJmhEvD4Lh/wrs++ 5df4a88GhW7M6KgzihiO03oSSWptjIhh2d7mAko6pV95X5SW46jRdE5L74CoAm1WqSTa wOGm8rV9ln/Lp1elJD6z8pUGkdh/E1+OMEQ9EvYZIbq0Z36WUlFC8guVtj+Xv1h1GoF/ fryxX6CKblVjVIotGr7N4u4VXlOQ7ZHpfBhyE5nyLIFDoncRkynn7/rwlgvSudmF1180 +eOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=nz2yOWY7BTUn8t1QxsTeTnXspTIpgAFcUR58QPT86AE=; b=UlWM0yQlHUPhstykI58zQpAsLeyvZ9dMOj6RP7iqUye6wmC9p2/gljZHbqzfMGI+Ac LS5IZ2wGFAkC/QDix1Re8pzhlzTZckudEiO6AoEfZtY56dVTG9sMotgO/f0ZjnO3o/tI UHyn1ZyDVHG23DkqIpMsrkiO9HAP3tsbj5XL4EG0gWvQHeFz5qrl7yNXcoZm6tCtE8BD tENBJihav22pqykcWrgfy8Jtvpp7wmyq8SWF3PMSQzlMNFWRQDStDJEy+pokra62NL3c MesQQKcJfXt4i1euPNt6OgIBs82rZTWKNgFYxbpYJZJ72ZiccISWIi7ChG8MqY8jxtnU nTmw== X-Gm-Message-State: ALoCoQnlEKPYUUgNFXMVOv+BL0ysoXAc/uorrEv/BE/c2ckfRp5euoMCVRchH/UYqlO4BgA+73XNEIMzig/9W/UNfAliSspWuHGnJde/BCF0qMYap5DSeZ01SN/pND85jY4jfHLbEJc14BK4eyAwXqpZ/8CmblmPFAReNz6zDkG/Is0Iv/Oz3jorY2SxRjDZ+izD/6vrxkPI X-Received: by 10.60.38.234 with SMTP id j10mr1752724oek.42.1375807119010; Tue, 06 Aug 2013 09:38:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.111.66 with HTTP; Tue, 6 Aug 2013 09:38:18 -0700 (PDT) In-Reply-To: References: <23D5606B-9225-4428-99AA-EC66C93D4088@krovetz.net>

From: Adam Langley Date: Tue, 6 Aug 2013 12:38:18 -0400 Message-ID: To: Ted Krovetz Content-Type: text/plain; charset=UTF-8 Cc: "tls@ietf.org" Subject: Re: [TLS] Salsa20 and Poly1305 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 16:38:40 -0000 On Tue, Aug 6, 2013 at 12:20 PM, Ted Krovetz wrote: > I'm a bozo. When I gave you the VMAC code using ARM intrinsics I should have explicitly reminded you to enable NEON when compiling: > > gcc -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=hard > > On a modern ARM, you should always use these settings so that your compiler uses the NEON unit when possible. Thank you! I used -O3, but I don't develop on ARM very often. Please ignore previous measurements for VMAC on ARM. VMAC (ARM, 128-bit, with AES calls removed): 5015.1ns with 248 bytes of memory Poly1305 (ARM, with same flags): 3457ns I don't believe that either can be said to be better than the other now, which makes the call harder if anything :) Cheers AGL From benl@google.com Tue Aug 6 14:55:05 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF7CF21F846E for ; Tue, 6 Aug 2013 14:55:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.777 X-Spam-Level: X-Spam-Status: No, score=-1.777 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rJhJkWjmpPGH for ; Tue, 6 Aug 2013 14:55:05 -0700 (PDT) Received: from mail-ob0-x236.google.com (mail-ob0-x236.google.com [IPv6:2607:f8b0:4003:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 2AFA421F997E for ; Tue, 6 Aug 2013 14:54:57 -0700 (PDT) Received: by mail-ob0-f182.google.com with SMTP id wo10so2171118obc.27 for ; Tue, 06 Aug 2013 14:54:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=FY/wGRdc8cmXcikoSPoicS2c+1sSsvD5DUnUemRbiQ4=; b=kUqJQ/7xhlMJEcUoFSLCGn5YUqIj8hxVmMQEg3+eAwR2rD91GXXEEJ6txHxdl6iKz/ kGk/G/2Ee09w8DFL6UCLvMABoTUHuYxKyzGEbGRvc2D4D2gQVfHGp/D/V8/aNOjgjRQH ReQMq2X/TJvDYDZWLMslP9HFeqGj/WXj7+IWx/DYdxs0cfAVYlAUIivQHYxhc0UJHKpK 81GogzV93IwleCE5hDyWlsejXVdRSDh2W7nptIbULEGRT7/LZM2BY7f4JLHCcw59n3So Nj9zqmHmzPZu1ln3JC7ktqoJRFyajtn1l37mBzNBvcQi60/9v2JSaIqLi+5uMWu8V3AG 3GCA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=FY/wGRdc8cmXcikoSPoicS2c+1sSsvD5DUnUemRbiQ4=; b=ekvz63WCf7jYlnuOwKI/LT20msT8hmMi8ijPqxbQmCYHqIERyhkDuMr7kto6a79uPl DZ9ieP6uccZYVBvjxy/FnA1u/oxe1S7NxCu7PB93fvEyUEL2+tqQssGS9kyJB3eWI/r4 D7nneYJVsq/L6erlYp5Eg+6oAd0GkEGKfmpMwQtbTW68T49DuhlMJzZ9SEfYjV7p2ea9 j2cxAFhDj/H1fgBQSF/Ot8hSvXFP/toYUVRpRjzgVAIiUqisinvQHN78xDJzPdMT1jVV DqQCWZfVULCibAjQVC10gnAK9yTx7AzT0ehu16RRNQQfA+AoKmb5PjT4y8k9HEiy7obh qiYA== X-Gm-Message-State: ALoCoQncAX7B7Z5Afg14ScDGu4ZArEXWrUD8eDBSEr5sppikuG56PxzblqKq/OWAllrC18zF5UrTqu9Ngsv7DVDviu5Uux5JleiuNcJ72iAUs82Zeo/uzFhpGMQ4ymkPnJdcaHFfIh7Zdx8nNMThWMW9rvUV6h0T8NSo7VzQ46AOmjb2OE+Pvm+6Hl8P50OmaUbvHV6X6Z8H MIME-Version: 1.0 X-Received: by 10.50.154.106 with SMTP id vn10mr506466igb.0.1375826093134; Tue, 06 Aug 2013 14:54:53 -0700 (PDT) Received: by 10.64.230.239 with HTTP; Tue, 6 Aug 2013 14:54:52 -0700 (PDT) In-Reply-To: References: <23D5606B-9225-4428-99AA-EC66C93D4088@krovetz.net>

Date: Tue, 6 Aug 2013 22:54:52 +0100 Message-ID: From: Ben Laurie To: Adam Langley , Emilia Kasper Content-Type: multipart/alternative; boundary=047d7bd74b628dfad104e34e7997 Cc: Ted Krovetz , "tls@ietf.org" Subject: Re: [TLS] Salsa20 and Poly1305 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 21:55:06 -0000 --047d7bd74b628dfad104e34e7997 Content-Type: text/plain; charset=ISO-8859-1 [+ekasper] Emilia was getting some interesting results doing this kind of stuff many times in parallel... On 6 August 2013 17:38, Adam Langley wrote: > On Tue, Aug 6, 2013 at 12:20 PM, Ted Krovetz wrote: > > I'm a bozo. When I gave you the VMAC code using ARM intrinsics I should > have explicitly reminded you to enable NEON when compiling: > > > > gcc -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=hard > > > > On a modern ARM, you should always use these settings so that your > compiler uses the NEON unit when possible. > > Thank you! I used -O3, but I don't develop on ARM very often. > > Please ignore previous measurements for VMAC on ARM. > > VMAC (ARM, 128-bit, with AES calls removed): 5015.1ns with 248 bytes of > memory > Poly1305 (ARM, with same flags): 3457ns > > I don't believe that either can be said to be better than the other > now, which makes the call harder if anything :) > > > Cheers > > AGL > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --047d7bd74b628dfad104e34e7997 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

[+ekasper]

Emilia was getting some inte= resting results doing this kind of stuff many times in parallel...

On 6 Augus= t 2013 17:38, Adam Langley <agl@google.com> wrote:

On Tue, Aug 6, 2013 at 12:20 PM, Ted Krovetz= <ted@krovetz.net> wrote:
> I'm a bozo. When I gave you the VMAC code using ARM intrinsics I s= hould have explicitly reminded you to enable NEON when compiling:
>
> =A0 gcc -mcpu=3Dcortex-a8 -mfpu=3Dneon -mfloat-abi=3Dhard
>
> On a modern ARM, you should always use these settings so that your com= piler uses the NEON unit when possible.

Thank you! I used -O3, but I don't develop on ARM very often.

Please ignore previous measurements for VMAC on ARM.

VMAC (ARM, 128-bit, with AES calls removed): 5015.1ns with 248 bytes of mem= ory
Poly1305 (ARM, with same flags): 3457ns

I don't believe that either can be said to be better than the other
now, which makes the call harder if anything :)

Cheers

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

--047d7bd74b628dfad104e34e7997-- From agl@google.com Tue Aug 6 15:01:21 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EE1E21F9EB3 for ; Tue, 6 Aug 2013 15:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.724 X-Spam-Level: X-Spam-Status: No, score=-1.724 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hHqbbDDQH1oY for ; Tue, 6 Aug 2013 15:01:21 -0700 (PDT) Received: from mail-oa0-x22d.google.com (mail-oa0-x22d.google.com [IPv6:2607:f8b0:4003:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id E59E821F9CD1 for ; Tue, 6 Aug 2013 15:01:20 -0700 (PDT) Received: by mail-oa0-f45.google.com with SMTP id m1so1973982oag.32 for ; Tue, 06 Aug 2013 15:01:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=X+S9kXOsVN+/HlxabwApSHeed3q6oF+IDeLHHKIQoQA=; b=FgDnlSfrm1uvzgQ451CrDxy4tUHGEHl2+FMdSJ02kWa+ESsab1LqkX/dYpbbCfUui+ SsWyVEdjMRjSgjFlpef/g9kpUzdzrlV+OzPELz6asB2+myOPJlmvvbKrXDDAuQzzebU6 SDg8cjZkurcWIktB/utmd52xXcrcp5JTzrKa2YK9F1BgHO3klfhCkZO359YD1i9GK5Lx R+vtTtZoc/zKZhK3KsD0q+RYn8o2jSPrGl1765vOq4ifbdwg9WQT8EZ4xG7pLafYCzqk VBa5eHOV4wFIK5iiGJrZqHlrxkRWE8k+8R7AIzg37KUxqE4zBayx23G+WAMdvT17ySAo +bkA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=X+S9kXOsVN+/HlxabwApSHeed3q6oF+IDeLHHKIQoQA=; b=MYtR8KaD+zV+JwbPGCGpAeeGVjMzmchtyF0EWUwSleCyShJxcpKKMPnVOQNlRFOKWu PwdNDIso+1BGKfL2MlN+v0rLHb6lXESyn3WT9fcIHRwQjSRT59SqvAq414lq4GxDmFNG evCKmmaRtpOH/SMAKHgvjdnHGf46lL+HDipfByOTpRGclWSxOsohOPAJrwTmYdB3DUq8 aI1D/2dTlwhcsN0vkzhE43CAhUnAYy4i/dFRF/cVtzSpLkd43ykxx6KhCDdNqRqunuA/ +pvQYEJtwNaJNNXqLob7MZZ83MpJPedxOSuKdgpW2b4QU9/rbpxDIr2Hj7MAgFfFb/65 3qVQ== X-Gm-Message-State: ALoCoQmBd101CB9wQxiiO4QwZEyKzBaHMcljTTxl4padpr/lnELSCSomI5GHirfLUWqgXEGSq4eHYWd+8sQFz7WLVrHSc/Vsko9BXyIneJS8GQ5UCan7NwY5butPr7iFnxcSuG7mapBk04xvFRIslZlXLHnQzI52Y4uhEaGfim2lZTKz9G7MI5VkROqfetgzb6fzICzJheha X-Received: by 10.60.42.168 with SMTP id p8mr171027oel.73.1375826480475; Tue, 06 Aug 2013 15:01:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.111.66 with HTTP; Tue, 6 Aug 2013 15:01:00 -0700 (PDT) In-Reply-To: References: <23D5606B-9225-4428-99AA-EC66C93D4088@krovetz.net>

From: Adam Langley Date: Tue, 6 Aug 2013 18:01:00 -0400 Message-ID: To: Ben Laurie Content-Type: text/plain; charset=UTF-8 Cc: Ted Krovetz , Emilia Kasper , "tls@ietf.org" Subject: Re: [TLS] Salsa20 and Poly1305 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 22:01:21 -0000 On Tue, Aug 6, 2013 at 5:54 PM, Ben Laurie wrote: > Emilia was getting some interesting results doing this kind of stuff many > times in parallel... The Poly1305 code is doing multiple terms of the polynomial concurrent with SSE2 and NEON. I'm assuming that VMAC is doing the same. That does bode well for the AVX2/AVX-512 future, but those chips are widely distributed yet. Cheers AGL From alexey.melnikov@isode.com Thu Aug 8 08:26:53 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8348111E8132; Thu, 8 Aug 2013 08:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.776 X-Spam-Level: X-Spam-Status: No, score=-101.776 tagged_above=-999 required=5 tests=[AWL=0.824, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EOc09VmXuFz0; Thu, 8 Aug 2013 08:26:48 -0700 (PDT) Received: from statler.isode.com (statler.isode.com [62.3.217.254]) by ietfa.amsl.com (Postfix) with ESMTP id 51D0C11E814C; Thu, 8 Aug 2013 08:26:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1375975607; d=isode.com; s=selector; i=@isode.com; bh=TwASpAMHgbRb/efhcyU0hoR/qAsNrA/hDcbn97XbcDk=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=dGsMd30XxnVnmdoE+/YsZZKk6PQpRdCwG5h+/at+DacCMecQ5Pk6+/hfS5E+jqdttn6Fb6 CDTpt0xzqVKPNEz6BmiLWHvNapgUzeUmm4LpAnlKQ1qoNoqzblosni5+02oZb8zrjMV17Y zjDQF50ilBBiC3Fb/xl3mvOXvVJJsb4=; Received: from [172.16.1.29] (shiny.isode.com [62.3.217.250]) by statler.isode.com (submission channel) via TCP with ESMTPA id ; Thu, 8 Aug 2013 16:26:46 +0100 Message-ID: <5203B8BC.9080108@isode.com> Date: Thu, 08 Aug 2013 16:26:52 +0100 From: Alexey Melnikov User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 To: ietf@ietf.org References: <20130802072350.14846.84073.idtracker@ietfa.amsl.com> In-Reply-To: <20130802072350.14846.84073.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: tls@ietf.org Subject: Re: [TLS] Last Call: (Out-of-Band Public Key Validation for Transport Layer Security (TLS)) to Proposed Standard X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Aug 2013 15:26:53 -0000 On 02/08/2013 08:23, The IESG wrote: > The IESG has received a request from the Transport Layer Security WG > (tls) to consider the following document: > - 'Out-of-Band Public Key Validation for Transport Layer Security (TLS)' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf@ietf.org mailing lists by 2013-08-16. Exceptionally, comments may be > sent to iesg@ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. > > Abstract > > > This document specifies a new certificate type and two TLS > extensions, one for the client and one for the server, for exchanging > raw public keys in Transport Layer Security (TLS) and Datagram > Transport Layer Security (DTLS) for use with out-of-band public key > validation. Hi, I just read the document and support its publication. I think I found one minor issue: Section 4.1 says: In order to indicate the support of out-of-band raw public keys, clients MUST include the 'client_certificate_type' and 'server_certificate_type' extensions in an extended client hello message. The hello extension mechanism is described in TLS 1.2 [RFC5246]. In Section 5 (the first example): client_hello, server_certificate_type=(RawPublicKey) -> // [1] So it looks like the example doesn't comply with the MUST requirement in the Section 4.1 ("client_certificate_type" is missing) or the requirement stated in Section 4.1 is incorrect. I suspect you meant "'client_certificate_type' and/or 'server_certificate_type'" in Section 4.1. Best Regards, Alexey From ted@krovetz.net Tue Aug 6 09:20:58 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11E4121F9FFC for ; Tue, 6 Aug 2013 09:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fd9x-YEJw2gK for ; Tue, 6 Aug 2013 09:20:50 -0700 (PDT) Received: from mail-pd0-f173.google.com (mail-pd0-f173.google.com [209.85.192.173]) by ietfa.amsl.com (Postfix) with ESMTP id AAAF221F991F for ; Tue, 6 Aug 2013 09:20:40 -0700 (PDT) Received: by mail-pd0-f173.google.com with SMTP id p11so458058pdj.4 for ; Tue, 06 Aug 2013 09:20:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=gDEgNDM2ZSQga4y/wdWw6mTBr9rI9pVpxrIY+fBoQFo=; b=JpFhx/h5gCLpR66aqSwhELvj6xw+lvPKcvVk31L3pqv4RPwIQ4rTdONbXNZsTxnQVA ExIqJdEd5esAe4rWx6HRjVgfUYkSOKXjgG4UoO6FbiLeUDiP5BQl0mTmAY5ImBjUnYYD tqkU12XnnV90X1iImyH4PNrjhJAmmr5t2j/iM0Oxipd4CnKzwX3SRcozV9cq7kj5pNwL e6ONITRMSSiaufOjvQt5lNaWP4SvKbTQPNI81fm+pUSgBccLqmNYdB+Z2OIOgoZPRuzH R3OyY0iJ70LaLpRkGIBEvcAmVeTKaHlsRMv9tUSdKotf4V32fFye+fMYUjNTE9fy9i+Q SQxA== X-Gm-Message-State: ALoCoQkTETnyJ3eDdzXL3S40qYX/faop/fBKAgzK/MKNcE1asDtLyZFNR+dvv+IfsoF5z8H0AWyX X-Received: by 10.66.122.5 with SMTP id lo5mr3991810pab.175.1375806034652; Tue, 06 Aug 2013 09:20:34 -0700 (PDT) Received: from [192.168.1.162] (c-67-166-145-119.hsd1.ca.comcast.net. [67.166.145.119]) by mx.google.com with ESMTPSA id il4sm2827843pbb.36.2013.08.06.09.20.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 06 Aug 2013 09:20:33 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ted Krovetz In-Reply-To: Date: Tue, 6 Aug 2013 09:20:32 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <23D5606B-9225-4428-99AA-EC66C93D4088@krovetz.net> To: Adam Langley X-Mailer: Apple Mail (2.1508) X-Mailman-Approved-At: Sat, 10 Aug 2013 11:29:03 -0700 Cc: "tls@ietf.org" Subject: Re: [TLS] Salsa20 and Poly1305 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Aug 2013 16:20:58 -0000 Adam, Thanks a lot for taking the time to do these tests. > On a Cortex-A8 (specifically a Galaxy Nexus) using Linaro GCC 4.7: I'm a bozo. When I gave you the VMAC code using ARM intrinsics I should = have explicitly reminded you to enable NEON when compiling: gcc -mcpu=3Dcortex-a8 -mfpu=3Dneon -mfloat-abi=3Dhard On a modern ARM, you should always use these settings so that your = compiler uses the NEON unit when possible. -Ted= From Michael.Tuexen@lurchi.franken.de Sun Aug 11 06:24:37 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81AB321F8CB0 for ; Sun, 11 Aug 2013 06:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-YXkbex9-ap for ; Sun, 11 Aug 2013 06:24:37 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id CD9EC21F9703 for ; Sun, 11 Aug 2013 06:17:57 -0700 (PDT) Received: from [192.168.1.200] (p508F1653.dip0.t-ipconnect.de [80.143.22.83]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 2BB991C0C069C for ; Sun, 11 Aug 2013 15:17:54 +0200 (CEST) From: Michael Tuexen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <1CBCCCAF-163A-474B-8DD0-6634460644C1@lurchi.franken.de> Date: Sun, 11 Aug 2013 15:17:54 +0200 To: "tls@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [TLS] DTLS Handshake race condition X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 13:24:37 -0000 Dear all, while fixing a bug in OpenSSL regarding the DTLS handshake, I thought = about the following scenario (both sides decide to renegotiate at about the = same time): * A DTLS connection is established. * The server sends a HelloRequest(MsgSeqNo =3D 0) and starts the = retransmission timer, since this is a flight. * The HelloRequest is dropped by the network. * The client sends a ClientHello(MsgSeqNo =3D 0) and start a = retransmission timer, since it is its first flight. * The server receives the ClientHello, stops the retransmission timer and sends the next flight starting with ServerHello(MsgSeqNo =3D 1)=20 since it considers the received ClientHello as an ack for the flight. * The client doesn't process the ServerHello, since it expects the MsgSeqNo =3D=3D 0. Therefore the client retransmits its ClientHello and the server = retransmits its flight containing the ServerHello. Am I missing something? The problem is that the server has no way to figure out if the received ClientHello is a reaction to a HelloRequest or not. The only way out I see is that the client accepts ServerHellos with MsgSeqNo=3D0 and MsgSeqNo=3D1. I don't think this is covered in http://tools.ietf.org/html/rfc6347 Any opinions? Best regards Michael= From andrewgwilson@gmail.com Sun Aug 11 07:25:53 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC02A11E80F9 for ; Sun, 11 Aug 2013 07:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lh2yLldGfmU6 for ; Sun, 11 Aug 2013 07:25:53 -0700 (PDT) Received: from mail-bk0-x22c.google.com (mail-bk0-x22c.google.com [IPv6:2a00:1450:4008:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 87CAC21E8050 for ; Sun, 11 Aug 2013 07:19:30 -0700 (PDT) Received: by mail-bk0-f44.google.com with SMTP id mz10so1897077bkb.31 for ; Sun, 11 Aug 2013 07:19:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=7D63AltDBDZ0CzQ3DF7WKP5Yb5w0N22Zsax123PPpeM=; b=EiljkGIch6/7Ti28NrVouRF2Zhsd4qSASHoYRsRvsuy9qnsigIJKKgrU/NYBFJrdu7 gqvk2w2VU9/JjkZSHlCglkmcU8oSHC6QWp7ojrccRmgN2rfAa3DnCcHlr5oPCkvzHfNR XvAuGwxRbQL8dhfGPtJw9xZfJLdoWUEf/giX6m2m1J7DhlHUKXQECFm7L7SRMiHlNSrn UTzSgniZ82JOMTQdKChDvKWm8zm54Ynnp1fr/Vl1ojdJshw7ky6kbLNtSDMPkuVO7wWG bG+UlTQB5hJEJeKWkPh36FWi0kH7pe82C8Jg6jphoiCxJ7elDmGW850kYH1Pyx0uAWJk XoWg== MIME-Version: 1.0 X-Received: by 10.204.187.196 with SMTP id cx4mr3000264bkb.118.1376230769559; Sun, 11 Aug 2013 07:19:29 -0700 (PDT) Received: by 10.205.115.141 with HTTP; Sun, 11 Aug 2013 07:19:29 -0700 (PDT) In-Reply-To: <1CBCCCAF-163A-474B-8DD0-6634460644C1@lurchi.franken.de> References: <1CBCCCAF-163A-474B-8DD0-6634460644C1@lurchi.franken.de> Date: Mon, 12 Aug 2013 02:19:29 +1200 Message-ID: From: Andy Wilson To: Michael Tuexen Content-Type: multipart/alternative; boundary=20cf302acee2263bb504e3acb215 Cc: tls@ietf.org Subject: Re: [TLS] DTLS Handshake race condition X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 14:25:54 -0000 --20cf302acee2263bb504e3acb215 Content-Type: text/plain; charset=UTF-8 After looking over the RFC a bit, wouldn't the client be expecting a HelloVerifyRequest after its ClientHello? On 12 August 2013 01:17, Michael Tuexen wrote: > Dear all, > > while fixing a bug in OpenSSL regarding the DTLS handshake, I thought about > the following scenario (both sides decide to renegotiate at about the same > time): > > * A DTLS connection is established. > * The server sends a HelloRequest(MsgSeqNo = 0) and starts the > retransmission > timer, since this is a flight. > * The HelloRequest is dropped by the network. > * The client sends a ClientHello(MsgSeqNo = 0) and start a retransmission > timer, > since it is its first flight. > * The server receives the ClientHello, stops the retransmission timer > and sends the next flight starting with ServerHello(MsgSeqNo = 1) > since it considers the received ClientHello as an ack for the flight. > * The client doesn't process the ServerHello, since it expects the > MsgSeqNo == 0. > > Therefore the client retransmits its ClientHello and the server retransmits > its flight containing the ServerHello. Am I missing something? > > The problem is that the server has no way to figure out if the received > ClientHello is a reaction to a HelloRequest or not. > The only way out I see is that the client accepts ServerHellos with > MsgSeqNo=0 and MsgSeqNo=1. > I don't think this is covered in http://tools.ietf.org/html/rfc6347 > > Any opinions? > > Best regards > Michael > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Regards Andy --20cf302acee2263bb504e3acb215 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

After looking over the RFC a bit, wouldn't the client = be expecting a=C2=A0HelloVer= ifyRequest after its ClientHello?

On 12 August 2013 01:17, Michael Tuexen <Michael.Tuexen@lur= chi.franken.de> wrote:

Dear all,

while fixing a bug in OpenSSL regarding the DTLS handshake, I thought about=
the following scenario (both sides decide to renegotiate at about the same<= br> time):

* A DTLS connection is established.
* The server sends a HelloRequest(MsgSeqNo =3D 0) and starts the retransmis= sion
=C2=A0 timer, since this is a flight.
* The HelloRequest is dropped by the network.
* The client sends a ClientHello(MsgSeqNo =3D 0) and start a retransmission= timer,
=C2=A0 since it is its first flight.
* The server receives the ClientHello, stops the retransmission timer
=C2=A0 and sends the next flight starting with ServerHello(MsgSeqNo =3D 1)<= br> =C2=A0 since it considers the received ClientHello as an ack for the flight= .
* The client doesn't process the ServerHello, since it expects the
=C2=A0 MsgSeqNo =3D=3D 0.

Therefore the client retransmits its ClientHello and the server retransmits=
its flight containing the ServerHello. Am I missing something?

The problem is that the server has no way to figure out if the received
ClientHello is a reaction to a HelloRequest or not.
The only way out I see is that the client accepts ServerHellos with
MsgSeqNo=3D0 and MsgSeqNo=3D1.
I don't think this is covered in http://tools.ietf.org/html/rfc6347

Any opinions?

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

--
Regards
<= br>Andy

--20cf302acee2263bb504e3acb215-- From Michael.Tuexen@lurchi.franken.de Sun Aug 11 10:15:32 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6940121F9A18 for ; Sun, 11 Aug 2013 10:15:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4DzafZF1-2mt for ; Sun, 11 Aug 2013 10:15:31 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 37FFE11E80E0 for ; Sun, 11 Aug 2013 10:08:54 -0700 (PDT) Received: from [192.168.1.200] (p508F2769.dip0.t-ipconnect.de [80.143.39.105]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id E37F01C0C0692; Sun, 11 Aug 2013 19:08:50 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Tuexen In-Reply-To: Date: Sun, 11 Aug 2013 19:08:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1F5455F5-439B-4215-9D92-1FDC2FDFBDE7@lurchi.franken.de> References: <1CBCCCAF-163A-474B-8DD0-6634460644C1@lurchi.franken.de> To: Andy Wilson X-Mailer: Apple Mail (2.1508) Cc: tls@ietf.org Subject: Re: [TLS] DTLS Handshake race condition X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 17:15:32 -0000 On Aug 11, 2013, at 4:19 PM, Andy Wilson = wrote: > After looking over the RFC a bit, wouldn't the client be expecting a = HelloVerifyRequest after its ClientHello? I don't think this is necessary, since the client and the server have = already a relation. So there is no need to use the cookie mechanism. However, the question is the same. In your case * The server sends a HelloRequest(MsgSeqNo =3D 0) and starts the = retransmission timer, since this is a flight. * The HelloRequest is dropped by the network. * The client sends a ClientHello(MsgSeqNo =3D 0) and start a = retransmission timer, since it is its first flight. * The server sends a HelloVerifyRequest(MsgSeqNo =3D 1) * The client doesn't process the ServerHello, since it expects the MsgSeqNo =3D=3D 0. Therefore, the server retransmits the flight consisting of the = HelloVerifyRequest and the client retransmits the flight containing the ClientHello. So the solution would be that the client accepts * ServerHellos with MsgSeqNo=3D0 and MsgSeqNo=3D1. * HelloVerifyRequest with MsgSeqNo=3D0 and MsgSeqNo=3D1. Am I missing something? Best regards Michael >=20 > On 12 August 2013 01:17, Michael Tuexen = wrote: > Dear all, >=20 > while fixing a bug in OpenSSL regarding the DTLS handshake, I thought = about > the following scenario (both sides decide to renegotiate at about the = same > time): >=20 > * A DTLS connection is established. > * The server sends a HelloRequest(MsgSeqNo =3D 0) and starts the = retransmission > timer, since this is a flight. > * The HelloRequest is dropped by the network. > * The client sends a ClientHello(MsgSeqNo =3D 0) and start a = retransmission timer, > since it is its first flight. > * The server receives the ClientHello, stops the retransmission timer > and sends the next flight starting with ServerHello(MsgSeqNo =3D 1) > since it considers the received ClientHello as an ack for the = flight. > * The client doesn't process the ServerHello, since it expects the > MsgSeqNo =3D=3D 0. >=20 > Therefore the client retransmits its ClientHello and the server = retransmits > its flight containing the ServerHello. Am I missing something? >=20 > The problem is that the server has no way to figure out if the = received > ClientHello is a reaction to a HelloRequest or not. > The only way out I see is that the client accepts ServerHellos with > MsgSeqNo=3D0 and MsgSeqNo=3D1. > I don't think this is covered in http://tools.ietf.org/html/rfc6347 >=20 > Any opinions? >=20 > Best regards > Michael > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls >=20 >=20 >=20 > --=20 > Regards >=20 > Andy From simon@josefsson.org Sun Aug 11 15:24:14 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C754321F9005 for ; Sun, 11 Aug 2013 15:24:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQD5OL93LQmh for ; Sun, 11 Aug 2013 15:24:13 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) by ietfa.amsl.com (Postfix) with ESMTP id 7FF4511E812B for ; Sun, 11 Aug 2013 15:18:56 -0700 (PDT) Received: from latte.josefsson.org (static-213-115-179-130.sme.bredbandsbolaget.se [213.115.179.130]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id r7BMIn1T016831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 12 Aug 2013 00:18:52 +0200 From: Simon Josefsson To: Ted Krovetz References: <23D5606B-9225-4428-99AA-EC66C93D4088@krovetz.net> OpenPGP: id=B565716F; url=http://josefsson.org/key.txt X-Hashcash: 1:22:130811:tls@ietf.org::YQ6i2D9LUGMRSKX8:1ELc X-Hashcash: 1:22:130811:ted@krovetz.net::xxV2y9V8QCcziPFO:EHNf Date: Mon, 12 Aug 2013 00:18:49 +0200 In-Reply-To: <23D5606B-9225-4428-99AA-EC66C93D4088@krovetz.net> (Ted Krovetz's message of "Mon, 29 Jul 2013 17:03:44 -1000") Message-ID: <87zjsn3m7q.fsf@latte.josefsson.org> User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Virus-Scanned: clamav-milter 0.97.8 at duva.sjd.se X-Virus-Status: Clean Cc: tls@ietf.org Subject: Re: [TLS] Salsa20 and Poly1305 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 22:24:14 -0000 Ted Krovetz writes: > I'd also suggest using Bernstein's Chacha instead of Bernstein's > Salsa. It has the same core as Salsa, but Bernstein cleaned up the > rough edges of its prolog and epilog, making it smaller, faster and > nicer to program. Chacha is basically a better Salsa. > > http://cr.yp.to/chacha.html Right, there is a bunch of stream ciphers that have nicer properties than Salsa20, but Salsa20 was chosen conservatively from the set of modern stream cipher. Do you think the benefits of Chacha motivate ignoring the time that went into reviewing Salsa20? I'm assuming Salsa20 has received more review than Chacha, but I cannot quantify it. I would have prefered a stream cipher with builtin authentication, so we wouldn't have to debate the choice of MAC. Alas, I'm not aware of any with good performance that has gone through significant review. /Simon From prvs=1935fad10c=uri@ll.mit.edu Sun Aug 11 16:55:41 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1196B21F9A1C for ; Sun, 11 Aug 2013 16:55:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.223 X-Spam-Level: X-Spam-Status: No, score=-6.223 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_ALL=0.751, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-pZJ0ib1i41 for ; Sun, 11 Aug 2013 16:55:37 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 37BBC21F9AF5 for ; Sun, 11 Aug 2013 16:48:24 -0700 (PDT) Received: from LLE2K7-HUB02.mitll.ad.local (LLE2K7-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id r7BNmK1A015920; Sun, 11 Aug 2013 19:48:23 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: "'simon@josefsson.org'" , "'ted@krovetz.net'" Date: Sun, 11 Aug 2013 19:40:19 -0400 Thread-Topic: [TLS] Salsa20 and Poly1305 in TLS Thread-Index: Ac6W4+e/ZC6bsxeqQQiFx0vOuoNqxAAB/aL6 In-Reply-To: <87zjsn3m7q.fsf@latte.josefsson.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.10.8794, 1.0.431, 0.0.0000 definitions=2013-08-11_08:2013-08-09, 2013-08-11, 1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1308110271 Message-Id: <20130811234824.37BBC21F9AF5@ietfa.amsl.com> Cc: "'tls@ietf.org'" Subject: Re: [TLS] Salsa20 and Poly1305 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Aug 2013 23:55:41 -0000 Considering the similarity between Salsa and Chacha design & construction (= and the amount of analysis that went into it), IMHO Chacha advantages justi= fy its use over Salsa. Thanks! -- Regards, Uri Blumenthal Voice: (781) 981-1638 Cyber Systems and Technology Fax: (781) 981-0186 MIT Lincoln Laboratory Cell: (339) 223-5363 244 Wood Street Email: Lexington, MA 02420-9185 =20 Web: http://www.ll.mit.edu/CST/ =20 MIT LL Root CA:=20 DSN: 478-5980 ask Lincoln ext.1638 ----- Original Message ----- From: Simon Josefsson [mailto:simon@josefsson.org] Sent: Sunday, August 11, 2013 06:18 PM=0A= To: Ted Krovetz Cc: tls@ietf.org Subject: Re: [TLS] Salsa20 and Poly1305 in TLS Ted Krovetz writes: > I'd also suggest using Bernstein's Chacha instead of Bernstein's > Salsa. It has the same core as Salsa, but Bernstein cleaned up the > rough edges of its prolog and epilog, making it smaller, faster and > nicer to program. Chacha is basically a better Salsa. > > http://cr.yp.to/chacha.html Right, there is a bunch of stream ciphers that have nicer properties than Salsa20, but Salsa20 was chosen conservatively from the set of modern stream cipher. Do you think the benefits of Chacha motivate ignoring the time that went into reviewing Salsa20? I'm assuming Salsa20 has received more review than Chacha, but I cannot quantify it. I would have prefered a stream cipher with builtin authentication, so we wouldn't have to debate the choice of MAC. Alas, I'm not aware of any with good performance that has gone through significant review. /Simon _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From ted@krovetz.net Sun Aug 11 18:14:38 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6515D11E8121 for ; Sun, 11 Aug 2013 18:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6q1EGhz9A15r for ; Sun, 11 Aug 2013 18:14:32 -0700 (PDT) Received: from mail-pa0-f51.google.com (mail-pa0-f51.google.com [209.85.220.51]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1D211E8167 for ; Sun, 11 Aug 2013 18:06:20 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id lf1so4047122pab.24 for ; Sun, 11 Aug 2013 18:06:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=+2Us4szwPFTUFyJZS5BVvc/Z+d5Ch+qU6v5JEyXaMxM=; b=Q8OXHtX2t1ierThgo3nb5hUAb6RRgP+CK63pTbXLWyWvkNheZhEEMNG+7qG8FuaLnS EzljtXjBw/pwywXy5h9tOGFRyJAXz+/qNMyTrLL1TkTDJxvfHEbxR3ep/myE0VVQMnVW lefIAON+WAkQvETw5XlzAtcgerPhRlVNJMcOz+pjxedT8jNQO9H0To4P6hvdKx8JY2EG eRksDJ8oon7GETPUDMq0XQ64Gcdojr5qR+p+6+R+BbJRIT1WPxIDO8ui2R7+UrwWAyGW e3v3vzsCYxlDJzW4vU7u6izxqXXHhFwVWfxLH+l6MwminE0nNGjEg5aE3zLU/F8xVjQZ YTyA== X-Gm-Message-State: ALoCoQns66qj1K+VkotFyXGzJLz4GeAkcGhVQB8ebl7UFaq0VVXT3Aq+d/sKcPttkZUuHnHKu6X0 X-Received: by 10.66.235.105 with SMTP id ul9mr21545669pac.112.1376269578533; Sun, 11 Aug 2013 18:06:18 -0700 (PDT) Received: from [192.168.1.162] (c-67-166-145-119.hsd1.ca.comcast.net. [67.166.145.119]) by mx.google.com with ESMTPSA id r7sm36321927pao.18.2013.08.11.18.06.16 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 11 Aug 2013 18:06:17 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ted Krovetz In-Reply-To: <87zjsn3m7q.fsf@latte.josefsson.org> Date: Sun, 11 Aug 2013 18:06:16 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <92C52D00-644F-4814-A77B-FD793FB4D676@krovetz.net> References: <23D5606B-9225-4428-99AA-EC66C93D4088@krovetz.net> <87zjsn3m7q.fsf@latte.josefsson.org> To: Simon Josefsson X-Mailer: Apple Mail (2.1508) Cc: "tls@ietf.org" Subject: Re: [TLS] Salsa20 and Poly1305 in TLS X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 01:14:38 -0000 > Do you think the benefits of Chacha motivate > ignoring the time that went into reviewing Salsa20? The nice thing about Chacha is that most of the Salsa analysis applies. = The only differences between the two algorithms is (1) the ordering of = the initial and final 16 word state, and (2) two rotation distances. I = believe that Dan Bernstein has said that he believes (1) has no security = consequences and that (2) improves security. If I were choosing between the two, yes, I'd be willing to transfer my = confidence from Salsa to Chacha and use that. -Ted From andrewgwilson@gmail.com Mon Aug 12 04:23:49 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B1A11E81BF for ; Mon, 12 Aug 2013 04:23:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rPKkEdF1sdWB for ; Mon, 12 Aug 2013 04:23:44 -0700 (PDT) Received: from mail-bk0-x230.google.com (mail-bk0-x230.google.com [IPv6:2a00:1450:4008:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id A285121F999B for ; Mon, 12 Aug 2013 03:29:19 -0700 (PDT) Received: by mail-bk0-f48.google.com with SMTP id my13so1769626bkb.7 for ; Mon, 12 Aug 2013 03:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=/PK8rvd2hKpR1D37kuY/IwHfxvmuWYH0KHHJ/xK8fn4=; b=sM/ozqv8SEMq63XmumzegZ8Vj1yn9UngqMYUS2Y7Tq4ifdMq7hiA55aJBzBTdmGdO1 yj9KXSYLPfEcDpU4/BtoPywvmdUcAaju6lXfRM4hqFXSMRy4e9c9Y7JRw7qI0E7k1bHa tTpgjBw8gkA/L5Xy6UEfAYn/GKzKh3q5SoYhDFg4yzpfRvlCwhM10T97F0g0nTk1xyME oKDaNIlqY7hmId0KNfJxX4zyM7BgzWTCRXUkN6TOIEQiJKxPiFdt9aXExW0pO7fuB9vh SNUIbyX4VRkDDZi4opucPkSqd6cK4syfMDTVu2pQdWgJoJICxQRppSAnWlWuxrZmpBDq OtMg== MIME-Version: 1.0 X-Received: by 10.204.187.196 with SMTP id cx4mr3361180bkb.118.1376303336947; Mon, 12 Aug 2013 03:28:56 -0700 (PDT) Received: by 10.205.115.141 with HTTP; Mon, 12 Aug 2013 03:28:56 -0700 (PDT) In-Reply-To: <1F5455F5-439B-4215-9D92-1FDC2FDFBDE7@lurchi.franken.de> References: <1CBCCCAF-163A-474B-8DD0-6634460644C1@lurchi.franken.de> <1F5455F5-439B-4215-9D92-1FDC2FDFBDE7@lurchi.franken.de> Date: Mon, 12 Aug 2013 22:28:56 +1200 Message-ID: From: Andy Wilson To: Michael Tuexen Content-Type: multipart/alternative; boundary=20cf302acee280c18704e3bd9705 Cc: tls@ietf.org Subject: Re: [TLS] DTLS Handshake race condition X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 11:23:49 -0000 --20cf302acee280c18704e3bd9705 Content-Type: text/plain; charset=UTF-8 Section 4.2.2 states: The first message each side transmits in each handshake always has message_seq = 0. Whenever each new message is generated, the message_seq value is incremented by one. Note that in the case of a rehandshake, this implies that the HelloRequest will have message_seq = 0 and the ServerHello will have message_seq = 1 This would imply that the client WOULD process the ServerHello with seq==1 as this is a re-handshake. That's the way i'm reading the spec.. On 12 August 2013 05:08, Michael Tuexen wrote: > On Aug 11, 2013, at 4:19 PM, Andy Wilson wrote: > > > After looking over the RFC a bit, wouldn't the client be expecting a > HelloVerifyRequest after its ClientHello? > I don't think this is necessary, since the client and the server have > already > a relation. So there is no need to use the cookie mechanism. > > However, the question is the same. In your case > * The server sends a HelloRequest(MsgSeqNo = 0) and starts the > retransmission > timer, since this is a flight. > * The HelloRequest is dropped by the network. > * The client sends a ClientHello(MsgSeqNo = 0) and start a retransmission > timer, > since it is its first flight. > * The server sends a HelloVerifyRequest(MsgSeqNo = 1) > * The client doesn't process the ServerHello, since it expects the > MsgSeqNo == 0. > > Therefore, the server retransmits the flight consisting of the > HelloVerifyRequest > and the client retransmits the flight containing the ClientHello. > So the solution would be that the client accepts > * ServerHellos with MsgSeqNo=0 and MsgSeqNo=1. > * HelloVerifyRequest with MsgSeqNo=0 and MsgSeqNo=1. > > Am I missing something? > > Best regards > Michael > > > > On 12 August 2013 01:17, Michael Tuexen < > Michael.Tuexen@lurchi.franken.de> wrote: > > Dear all, > > > > while fixing a bug in OpenSSL regarding the DTLS handshake, I thought > about > > the following scenario (both sides decide to renegotiate at about the > same > > time): > > > > * A DTLS connection is established. > > * The server sends a HelloRequest(MsgSeqNo = 0) and starts the > retransmission > > timer, since this is a flight. > > * The HelloRequest is dropped by the network. > > * The client sends a ClientHello(MsgSeqNo = 0) and start a > retransmission timer, > > since it is its first flight. > > * The server receives the ClientHello, stops the retransmission timer > > and sends the next flight starting with ServerHello(MsgSeqNo = 1) > > since it considers the received ClientHello as an ack for the flight. > > * The client doesn't process the ServerHello, since it expects the > > MsgSeqNo == 0. > > > > Therefore the client retransmits its ClientHello and the server > retransmits > > its flight containing the ServerHello. Am I missing something? > > > > The problem is that the server has no way to figure out if the received > > ClientHello is a reaction to a HelloRequest or not. > > The only way out I see is that the client accepts ServerHellos with > > MsgSeqNo=0 and MsgSeqNo=1. > > I don't think this is covered in http://tools.ietf.org/html/rfc6347 > > > > Any opinions? > > > > Best regards > > Michael > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > > > > > -- > > Regards > > > > Andy > > -- Regards Andy --20cf302acee280c18704e3bd9705 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Section 4.2.2 states:

The first me= ssage each side transmits in each handshake always has

=C2=A0 =C2= =A0message_seq =3D 0. =C2=A0Whenever each new message is generated, the

=C2=A0 =C2=A0message_seq value is incremented by one. =C2=A0Note tha= t in the case of a

=C2=A0 =C2=A0rehandshake, this implies that the HelloRequest will have= message_seq

=C2=A0 =C2=A0=3D 0 and the ServerHello will have mes= sage_seq =3D 1

This would imply that the cli= ent WOULD process the ServerHello with seq=3D=3D1 as this is a re-handshake= .

That's the way i'm reading the spec..

On 12 August 2013 05:08, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote:

On Aug 11, 2013, at 4:19 P= M, Andy Wilson <andrewgwilson= @gmail.com> wrote:

> After looking over the RFC a bit, wouldn't the client be expecting= a HelloVerifyRequest after its ClientHello?

I don't think this is necessary, since the client and the server = have already
a relation. So there is no need to use the cookie mechanism.

However, the question is the same. In your case

* The server sends a HelloRequest(MsgSeqNo =3D 0) and sta= rts the retransmission
=C2=A0 timer, since this is a flight.
* The HelloRequest is dropped by the network.
* The client sends a ClientHello(MsgSeqNo =3D 0) and start a retransmission= timer,
=C2=A0 since it is its first flight.

* The server sends a HelloVerifyRequest(MsgSeqNo =3D 1)

* The client doesn't process the ServerHello, since i= t expects the
=C2=A0 MsgSeqNo =3D=3D 0.

Therefore, the server retransmits the flight consisting of the HelloV= erifyRequest
and the client retransmits the flight containing the ClientHello.
So the solution would be that the client accepts

* ServerHellos with MsgSeqNo=3D0 and MsgSeqNo=3D1.

* HelloVerifyRequest with MsgSeqNo=3D0 and MsgSeqNo=3D1.

Am I missing something?

Best regards
Michael

>
> On 12 August 2013 01:17, Michael Tuexen <Michael.Tuexen@lurchi.franken.de> wrote: > Dear all,
>
> while fixing a bug in OpenSSL regarding the DTLS handshake, I thought = about
> the following scenario (both sides decide to renegotiate at about the = same
> time):
>
> * A DTLS connection is established.
> * The server sends a HelloRequest(MsgSeqNo =3D 0) and starts the retra= nsmission
> =C2=A0 timer, since this is a flight.
> * The HelloRequest is dropped by the network.
> * The client sends a ClientHello(MsgSeqNo =3D 0) and start a retransmi= ssion timer,
> =C2=A0 since it is its first flight.
> * The server receives the ClientHello, stops the retransmission timer<= br> > =C2=A0 and sends the next flight starting with ServerHello(MsgSeqNo = =3D 1)
> =C2=A0 since it considers the received ClientHello as an ack for the f= light.
> * The client doesn't process the ServerHello, since it expects the=
> =C2=A0 MsgSeqNo =3D=3D 0.
>
> Therefore the client retransmits its ClientHello and the server retran= smits
> its flight containing the ServerHello. Am I missing something?
>
> The problem is that the server has no way to figure out if the receive= d
> ClientHello is a reaction to a HelloRequest or not.
> The only way out I see is that the client accepts ServerHellos with > MsgSeqNo=3D0 and MsgSeqNo=3D1.
> I don't think this is covered in http://tools.ietf.org/html/rfc6347
>
> Any opinions?
>
> Best regards
> Michael
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>
>
>
> --
> Regards
>
> Andy

--
= Regards

Andy

--20cf302acee280c18704e3bd9705-- From Michael.Tuexen@lurchi.franken.de Mon Aug 12 04:34:22 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D8311E814C for ; Mon, 12 Aug 2013 04:34:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j33zFgpZ-2bs for ; Mon, 12 Aug 2013 04:34:20 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 83BA921F9E3C for ; Mon, 12 Aug 2013 03:47:10 -0700 (PDT) Received: from [192.168.1.200] (p508F2769.dip0.t-ipconnect.de [80.143.39.105]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 23E071C0C0693; Mon, 12 Aug 2013 12:46:45 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Tuexen In-Reply-To: Date: Mon, 12 Aug 2013 12:46:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1CBCCCAF-163A-474B-8DD0-6634460644C1@lurchi.franken.de> <1F5455F5-439B-4215-9D92-1FDC2FDFBDE7@lurchi.franken.de> To: Andy Wilson X-Mailer: Apple Mail (2.1508) Cc: tls@ietf.org Subject: Re: [TLS] DTLS Handshake race condition X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 11:34:22 -0000 On Aug 12, 2013, at 12:28 PM, Andy Wilson = wrote: > Section 4.2.2 states: >=20 > The first message each side transmits in each handshake always has > message_seq =3D 0. Whenever each new message is generated, the > message_seq value is incremented by one. Note that in the case of = a > rehandshake, this implies that the HelloRequest will have = message_seq > =3D 0 and the ServerHello will have message_seq =3D 1 >=20 > This would imply that the client WOULD process the ServerHello with = seq=3D=3D1 as this is a re-handshake. >=20 > That's the way i'm reading the spec.. Me too. I think the RFC does cover the race condition I'm referring to... What if the HelloRequest(message_seq=3D0) is lost and the client sends a ClientHello(message_seq=3D0) on its own (since the local user initates a re-handshake). The server accepts the ClientHello and responds with a ServerHello(message_seq=3D1). The client however expects a ServerHello(message_seq=3D0), since it never saw the HelloRequest. The HelloRequest is also not retransmitted, since the server considers it acked by the ClientHello. It is only the collision case I'm considering and I think which is not covered by the RFC. Best regards Michael >=20 >=20 >=20 >=20 > On 12 August 2013 05:08, Michael Tuexen = wrote: > On Aug 11, 2013, at 4:19 PM, Andy Wilson = wrote: >=20 > > After looking over the RFC a bit, wouldn't the client be expecting a = HelloVerifyRequest after its ClientHello? > I don't think this is necessary, since the client and the server have = already > a relation. So there is no need to use the cookie mechanism. >=20 > However, the question is the same. In your case > * The server sends a HelloRequest(MsgSeqNo =3D 0) and starts the = retransmission > timer, since this is a flight. > * The HelloRequest is dropped by the network. > * The client sends a ClientHello(MsgSeqNo =3D 0) and start a = retransmission timer, > since it is its first flight. > * The server sends a HelloVerifyRequest(MsgSeqNo =3D 1) > * The client doesn't process the ServerHello, since it expects the > MsgSeqNo =3D=3D 0. >=20 > Therefore, the server retransmits the flight consisting of the = HelloVerifyRequest > and the client retransmits the flight containing the ClientHello. > So the solution would be that the client accepts > * ServerHellos with MsgSeqNo=3D0 and MsgSeqNo=3D1. > * HelloVerifyRequest with MsgSeqNo=3D0 and MsgSeqNo=3D1. >=20 > Am I missing something? >=20 > Best regards > Michael > > > > On 12 August 2013 01:17, Michael Tuexen = wrote: > > Dear all, > > > > while fixing a bug in OpenSSL regarding the DTLS handshake, I = thought about > > the following scenario (both sides decide to renegotiate at about = the same > > time): > > > > * A DTLS connection is established. > > * The server sends a HelloRequest(MsgSeqNo =3D 0) and starts the = retransmission > > timer, since this is a flight. > > * The HelloRequest is dropped by the network. > > * The client sends a ClientHello(MsgSeqNo =3D 0) and start a = retransmission timer, > > since it is its first flight. > > * The server receives the ClientHello, stops the retransmission = timer > > and sends the next flight starting with ServerHello(MsgSeqNo =3D = 1) > > since it considers the received ClientHello as an ack for the = flight. > > * The client doesn't process the ServerHello, since it expects the > > MsgSeqNo =3D=3D 0. > > > > Therefore the client retransmits its ClientHello and the server = retransmits > > its flight containing the ServerHello. Am I missing something? > > > > The problem is that the server has no way to figure out if the = received > > ClientHello is a reaction to a HelloRequest or not. > > The only way out I see is that the client accepts ServerHellos with > > MsgSeqNo=3D0 and MsgSeqNo=3D1. > > I don't think this is covered in http://tools.ietf.org/html/rfc6347 > > > > Any opinions? > > > > Best regards > > Michael > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > > > > > -- > > Regards > > > > Andy >=20 >=20 >=20 >=20 > --=20 > Regards >=20 > Andy From Michael.Tuexen@lurchi.franken.de Mon Aug 12 04:39:19 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDA321F8C66 for ; Mon, 12 Aug 2013 04:39:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ooaDPqO6zgfr for ; Mon, 12 Aug 2013 04:39:18 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id ACCFB21F9B53 for ; Mon, 12 Aug 2013 03:58:21 -0700 (PDT) Received: from [192.168.1.200] (p508F2769.dip0.t-ipconnect.de [80.143.39.105]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 317FF1C0C069F; Mon, 12 Aug 2013 12:58:05 +0200 (CEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Michael Tuexen In-Reply-To: Date: Mon, 12 Aug 2013 12:57:42 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <1CBCCCAF-163A-474B-8DD0-6634460644C1@lurchi.franken.de> <1F5455F5-439B-4215-9D92-1FDC2FDFBDE7@lurchi.franken.de>

To: Andy Wilson X-Mailer: Apple Mail (2.1508) Cc: tls@ietf.org Subject: Re: [TLS] DTLS Handshake race condition X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 11:39:19 -0000 On Aug 12, 2013, at 12:46 PM, Michael Tuexen = wrote: >=20 > On Aug 12, 2013, at 12:28 PM, Andy Wilson = wrote: >=20 >> Section 4.2.2 states: >>=20 >> The first message each side transmits in each handshake always has >> message_seq =3D 0. Whenever each new message is generated, the >> message_seq value is incremented by one. Note that in the case of = a >> rehandshake, this implies that the HelloRequest will have = message_seq >> =3D 0 and the ServerHello will have message_seq =3D 1 >>=20 >> This would imply that the client WOULD process the ServerHello with = seq=3D=3D1 as this is a re-handshake. >>=20 >> That's the way i'm reading the spec.. > Me too. >=20 > I think the RFC does cover the race condition I'm referring to... ... I meant "does NOT cover" > What if the HelloRequest(message_seq=3D0) is lost and the client sends > a ClientHello(message_seq=3D0) on its own (since the local user = initates > a re-handshake). The server accepts the ClientHello and responds with > a ServerHello(message_seq=3D1). The client however expects a > ServerHello(message_seq=3D0), since it never saw the HelloRequest. > The HelloRequest is also not retransmitted, since the server considers > it acked by the ClientHello. >=20 > It is only the collision case I'm considering and I think which is > not covered by the RFC. >=20 > Best regards > Michael >>=20 >>=20 >>=20 >>=20 >> On 12 August 2013 05:08, Michael Tuexen = wrote: >> On Aug 11, 2013, at 4:19 PM, Andy Wilson = wrote: >>=20 >>> After looking over the RFC a bit, wouldn't the client be expecting a = HelloVerifyRequest after its ClientHello? >> I don't think this is necessary, since the client and the server have = already >> a relation. So there is no need to use the cookie mechanism. >>=20 >> However, the question is the same. In your case >> * The server sends a HelloRequest(MsgSeqNo =3D 0) and starts the = retransmission >> timer, since this is a flight. >> * The HelloRequest is dropped by the network. >> * The client sends a ClientHello(MsgSeqNo =3D 0) and start a = retransmission timer, >> since it is its first flight. >> * The server sends a HelloVerifyRequest(MsgSeqNo =3D 1) >> * The client doesn't process the ServerHello, since it expects the >> MsgSeqNo =3D=3D 0. >>=20 >> Therefore, the server retransmits the flight consisting of the = HelloVerifyRequest >> and the client retransmits the flight containing the ClientHello. >> So the solution would be that the client accepts >> * ServerHellos with MsgSeqNo=3D0 and MsgSeqNo=3D1. >> * HelloVerifyRequest with MsgSeqNo=3D0 and MsgSeqNo=3D1. >>=20 >> Am I missing something? >>=20 >> Best regards >> Michael >>>=20 >>> On 12 August 2013 01:17, Michael Tuexen = wrote: >>> Dear all, >>>=20 >>> while fixing a bug in OpenSSL regarding the DTLS handshake, I = thought about >>> the following scenario (both sides decide to renegotiate at about = the same >>> time): >>>=20 >>> * A DTLS connection is established. >>> * The server sends a HelloRequest(MsgSeqNo =3D 0) and starts the = retransmission >>> timer, since this is a flight. >>> * The HelloRequest is dropped by the network. >>> * The client sends a ClientHello(MsgSeqNo =3D 0) and start a = retransmission timer, >>> since it is its first flight. >>> * The server receives the ClientHello, stops the retransmission = timer >>> and sends the next flight starting with ServerHello(MsgSeqNo =3D 1) >>> since it considers the received ClientHello as an ack for the = flight. >>> * The client doesn't process the ServerHello, since it expects the >>> MsgSeqNo =3D=3D 0. >>>=20 >>> Therefore the client retransmits its ClientHello and the server = retransmits >>> its flight containing the ServerHello. Am I missing something? >>>=20 >>> The problem is that the server has no way to figure out if the = received >>> ClientHello is a reaction to a HelloRequest or not. >>> The only way out I see is that the client accepts ServerHellos with >>> MsgSeqNo=3D0 and MsgSeqNo=3D1. >>> I don't think this is covered in http://tools.ietf.org/html/rfc6347 >>>=20 >>> Any opinions? >>>=20 >>> Best regards >>> Michael >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>>=20 >>>=20 >>>=20 >>> -- >>> Regards >>>=20 >>> Andy >>=20 >>=20 >>=20 >>=20 >> --=20 >> Regards >>=20 >> Andy >=20 From mrex@sap.com Mon Aug 12 11:08:27 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 244C821F9E0A for ; Mon, 12 Aug 2013 11:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yToxsf1sbbY7 for ; Mon, 12 Aug 2013 11:08:20 -0700 (PDT) Received: from smtpde01.sap-ag.de (smtpde01.sap-ag.de [155.56.68.170]) by ietfa.amsl.com (Postfix) with ESMTP id 45FC521F9D8D for ; Mon, 12 Aug 2013 11:08:17 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde01.sap-ag.de (26) with ESMTP id r7CI8B5W029453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Aug 2013 20:08:11 +0200 (MEST) In-Reply-To: To: Michael Tuexen Date: Mon, 12 Aug 2013 20:08:11 +0200 (CEST) X-Mailer: ELM [version 2.4ME+ PL125 (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="US-ASCII" Message-Id: <20130812180811.779011A8FF@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Cc: tls@ietf.org Subject: Re: [TLS] DTLS Handshake race condition X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: mrex@sap.com List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Aug 2013 18:08:29 -0000 Michael Tuexen wrote: > > I think the RFC does not cover the race condition I'm referring to... > What if the HelloRequest(message_seq=0) is lost and the client sends > a ClientHello(message_seq=0) on its own (since the local user initates > a re-handshake). The server accepts the ClientHello and responds with > a ServerHello(message_seq=1). The client however expects a > ServerHello(message_seq=0), since it never saw the HelloRequest. > The HelloRequest is also not retransmitted, since the server considers > it acked by the ClientHello. > > It is only the collision case I'm considering and I think which is > not covered by the RFC. Your observation seems correct. The original TLS handshake is only half duplex. Properly dealing with renegotiation is therefore non-trivial. The original TLS spec addresses the overlapping of the renegotiation handshake by - omitting HelloRequests from the Handshake message hash computation. - require the TLS client to ignore any HelloRequests that are be received during the handshake (which includes the one received after the client has already requested a new handshake by sending a ClientHello from your scenario. Another "grey" area, that may not work particularly well with some TLS implementations, is what happens if one side requests a renegotiation while the other is still sending application data. While the TLS spec itself this should be OK when renegotiation handshake messages are interleaved with application data, it may not actually work with all implementations. Taken to the extreme, with TLS APIs that perform peer certificate validation in an event-based fashion, it may open a potential vulnerability (for servers doing delayed client authentication) when the client starts the renegotiation handshake, but stops sending handshake messages after the client's certificate handshake message and then continues sending application data under the original/enclosing TLS session. -Martin From turners@ieca.com Mon Aug 12 13:46:52 2013 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E36B221F9D7B for ; Mon, 12 Aug 2013 13:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.788 X-Spam-Level: X-Spam-Status: No, score=-101.788 tagged_above=-999 required=5 tests=[AWL=0.477, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ej484FpDBhH for ; Mon, 12 Aug 2013 13:46:47 -0700 (PDT) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [69.41.248.84]) by ietfa.amsl.com (Postfix) with ESMTP id D790521F9E26 for ; Mon, 12 Aug 2013 13:46:47 -0700 (PDT) Received: by gateway02.websitewelcome.com (Postfix, from userid 5007) id 3FBC9440A554; Mon, 12 Aug 2013 15:46:34 -0500 (CDT) Received: from gator1743.hostgator.com (gator1743.hostgator.com [184.173.253.227]) by gateway02.websitewelcome.com (Postfix) with ESMTP id 2CD79440A500 for ; Mon, 12 Aug 2013 15:46:34 -0500 (CDT) Received: from [96.231.225.44] (port=54485 helo=thunderfish.local) by gator1743.hostgator.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80) (envelope-from ) id 1V8z0l-0002yo-DQ for tls@ietf.org; Mon, 12 Aug 2013 15:46:43 -0500 Message-ID: <520949B2.7010002@ieca.com> Date: Mon, 12 Aug 2013 16:46:42 -0400 From: Sean Turner User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: tls@ietf.org References: <20130614045028.38DBD62104@rfc-editor.org> In-Reply-To: <20130614045028.38DBD62104@rfc-editor.org> X-Forwarded-Message-Id: <20130614045028.38DBD62104@rfc-editor.org> Content-Type: multipart/mixed; boundary="------------020700070905030302050109" X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator1743.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ieca.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (thunderfish.local) [96.231.225.44]:54485 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 5 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IxNzQzLmhvc3RnYXRvci5jb20= Subject: [TLS] Fwd: [Editorial Errata Reported] RFC4492 (3652) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: