From nobody Mon Sep 1 08:25:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 669F01A048F for ; Mon, 1 Sep 2014 08:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.15 X-Spam-Level: * X-Spam-Status: No, score=1.15 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LhWW7iU9oQUk for ; Mon, 1 Sep 2014 08:25:03 -0700 (PDT) Received: from smtp.serverkommune.de (serverkommune.de [176.9.61.43]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01AEA1A6FE3 for ; Mon, 1 Sep 2014 07:58:17 -0700 (PDT) Received: by smtp.serverkommune.de (Postfix, from userid 5001) id 80A2480AD0; Mon, 1 Sep 2014 16:58:15 +0200 (CEST) Received: from [131.159.20.131] (ex6.serverkommune.de [176.9.61.43]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.serverkommune.de (Postfix) with ESMTPSA id 7E41E80AC9 for ; Mon, 1 Sep 2014 16:58:13 +0200 (CEST) Message-ID: <54048985.1020005@net.in.tum.de> Date: Mon, 01 Sep 2014 16:58:13 +0200 From: Ralph Holz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: tls@ietf.org Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.98.1 at ex6 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/tls/H8v58_wxB3u54UQNzjGMfz3FCmM Subject: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 01 Sep 2014 15:25:05 -0000 Dear list, I would like to notify the list of a feature in the draft for Best Practices "Recommendations for Secure Use of TLS and DTLS" http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-02 => "Implementations MUST NOT negotiate the NULL cipher suites" This may lead to implementations dropping NULL (or making it hard to enable). There used to be one reasonable use case for NULL that I am personally aware of: grid traffic between large computing centres. Our group did see such high-speed, high-volume traffic on our network monitors when we did SSL/TLS/X.509 analyses - that was 3 years ago. My contacts at grid centres tell me that NULL encryption was useful then as the data was public anyway and good integrity was all that was needed. I am told by one centre at least there is no real need for NULL any more. In fact, the agreement seems to be that that cipher should be eliminated now. My personal take as one of the authors of the BCP is that the UTA WG should process UNLESS someone has a use case that is relevant on the same scale, or thinks the above statement does not hold in general. In that case, please bring your use case to the attention of the UTA or directly to the authors (i.e. Yaron Sheffer, yaronf.ietf@gmail.com, or me). We would like to keep any discussion focused. Thanks, Ralph -- Ralph Holz I8 - Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18043 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF From nobody Mon Sep 1 15:24:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6CE1A0AED for ; Mon, 1 Sep 2014 15:24:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxZFVhKDgvRU for ; Mon, 1 Sep 2014 15:24:00 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1A7A31A0AEC for ; Mon, 1 Sep 2014 15:23:59 -0700 (PDT) Received: from Philemon (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id EF7582CA08 for ; Mon, 1 Sep 2014 15:23:58 -0700 (PDT) From: "Jim Schaad" To: Date: Mon, 1 Sep 2014 15:21:38 -0700 Message-ID: <00c001cfc633$1964ec70$4c2ec550$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C1_01CFC5F8.6D0948C0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: Ac/GLzbHFDfsQSe7SF6jXb2X454PSw== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/x57dskq1Fc7N5xHX4400erQEE-g Subject: [TLS] Clarifictions for failure to agree on key sizes during hello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 01 Sep 2014 22:24:03 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00C1_01CFC5F8.6D0948C0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I am trying to figure out how this works and I find myself confused and not able to make headway. My view of the messages looks like the following: (Yes I know that I have shortened the cipher suite strings and have defined a new extension for ECDH parameters that I do not believe exists yet.) ClientHello Cipher_suites = NegotiatedDHParams= NegotiatedECDHParams= ClientKeyExchange=<(dhe, ffdhe2432), (ecdh, P-256)> ServerHello Cipher_suite = ?????? NegotiatedDHParams = NegotiatedECHDParams = ClientHello Copy above with a different ClientKeyExchange extension. I don't know what is going to be placed in the Cipher_suite field so that the client can say - who there is a mismatch in the keys that I passed in, but I should not expect to see a ServerkeyExchange message (which I might not like). Putting a cipher suite means that the client must check for an overlap between the negotiated params extension for that suite to check for an overlap between what the server returns and what it put into the client key exchange record. Putting a cipher suite means that the client might get locked into doing DH in this case, when it would prefer doing ECDH for P-521 to doing DH t 4096. It was not clear to me from the document, but I think it is correct, that the way this is handled is to use the negotiated params extensions to declare what sizes I support, even if I did not send keys of that size to start with. Putting a value into the cipher_suite field that is not in the client hello list seems to be a bad idea, unless there is a specific value that says I did not like the set of client keys you gave me to start with. Since this is not defined I assume that it is not there. (as an example putting TLS_DH_anon_* would be a disaster in the making.) Jim ------=_NextPart_000_00C1_01CFC5F8.6D0948C0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I am = trying to figure out how this works and I find myself confused and not = able to make headway.

 

My view of = the messages looks like the following:

(Yes I know that I have shortened the cipher suite = strings and have defined a new extension for ECDH parameters that I do = not believe exists yet.)

 

ClientHello

         &= nbsp;      Cipher_suites =3D <TLS_DHE_RSA, = TLS_DHE_DSS, TLS_ECDHE_RSA, TLS_ECDHE_ECDSS>

         &= nbsp;      NegotiatedDHParams=3D<ffdhe2432, = ffdhe4096>

         &= nbsp;      NegotiatedECDHParams=3D<P-256, = P-521>

         &= nbsp;      ClientKeyExchange=3D<(dhe, = ffdhe2432), (ecdh, P-256)>

 

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

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp; Cipher_suite =3D ??????

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp; NegotiatedDHParams =3D <ffdhe4096>

         &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;            = ;            =             &= nbsp;           &n= bsp; NegotiatedECHDParams =3D <P-521>

 

ClientHello

         &= nbsp;      Copy above with a different = ClientKeyExchange extension.

 

 

I = don’t know what is going to be placed in the Cipher_suite field so = that the client can say – who there is a mismatch in the keys that = I passed in, but I should not expect to see a ServerkeyExchange message = (which I might not like).

 

Putting a = cipher suite means that the client must check for an overlap between the = negotiated params extension for that suite to check for an overlap = between what the server returns and what it put into the client key = exchange record.

 

Putting a = cipher suite means that the client might get locked into doing DH in = this case, when it would prefer doing ECDH for P-521 to doing  DH t = 4096.

 

It was not clear to me from the document, but I think = it is correct, that the way this is handled is to use the negotiated = params extensions to declare what sizes I support, even if I did not = send keys of that size to start with. 

 

Putting a = value into the cipher_suite field that is not in the client hello list = seems to be a bad idea, unless there is a specific value that says I did = not like the set of client keys you gave me to start with.  Since = this is not defined I assume that it is not there.  (as an example = putting TLS_DH_anon_* would be a disaster in the = making.)

 

Jim

 

------=_NextPart_000_00C1_01CFC5F8.6D0948C0-- From nobody Mon Sep 1 15:42:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 373AC1A0B13 for ; Mon, 1 Sep 2014 15:42:11 -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=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lduh5aChJLbm for ; Mon, 1 Sep 2014 15:42:09 -0700 (PDT) Received: from mail-we0-f181.google.com (mail-we0-f181.google.com [74.125.82.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 745EB1A0B11 for ; Mon, 1 Sep 2014 15:42:08 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id x48so6085958wes.40 for ; Mon, 01 Sep 2014 15:42:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=WfS08R3Yw70Zkb7bsqT5sf7mTL6YkRaRit5JAaqqxFg=; b=XsA9ebyr0vdvToU1W7eI7cMkSc+at02is5qWUhhwR1vmIQ6vKj0yKGf8d8xzH1iGMu AggSvvsy90Wn6F2edAaq3JBytfII7MZJjpUcfMOppwvfGWDPKutWIl1vO8z9l51HpzbC RX2cp5J8eq9JhrUUKLmIM05Lx3aUFssNZ+4aj5WXShNJtMCBSrV0Reup669YaLgz6K1U zMcNSFLxSMBWdFJ2xtlHTn3oSijyCAyq/l6MV8dlm3m8x/nJ4ZwJ4oBoUxS9zw3iMgMP 2kL1hFl/BMEw5adAQD904aFX4R9AZmYUpgQ+GSkB0faQVg655GIGM04U3DwKy4CUEpg8 oDPQ== X-Gm-Message-State: ALoCoQm6Gzvo2y4osOPYr7MEsTQdEcBvq+2Z/WvYRFX3UOrSRhELvshgRFkQOA1H+DeUpWp8rd3O X-Received: by 10.180.37.77 with SMTP id w13mr24156697wij.78.1409611327026; Mon, 01 Sep 2014 15:42:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.128.12 with HTTP; Mon, 1 Sep 2014 15:41:26 -0700 (PDT) X-Originating-IP: [2620:101:80fc:232:8413:1a4c:daa5:7b99] In-Reply-To: <00c001cfc633$1964ec70$4c2ec550$@augustcellars.com> References: <00c001cfc633$1964ec70$4c2ec550$@augustcellars.com> From: Eric Rescorla Date: Mon, 1 Sep 2014 15:41:26 -0700 Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=e89a8f6470216b533e050208b6ad Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bYMNSwSMdko8-RnLbqxspD4U3BA Cc: "tls@ietf.org" Subject: Re: [TLS] Clarifictions for failure to agree on key sizes during hello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 01 Sep 2014 22:42:11 -0000 --e89a8f6470216b533e050208b6ad Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Sep 1, 2014 at 3:21 PM, Jim Schaad wrote: > I am trying to figure out how this works and I find myself confused and > not able to make headway. > > > > My view of the messages looks like the following: > > (Yes I know that I have shortened the cipher suite strings and have > defined a new extension for ECDH parameters that I do not believe exists > yet.) > > > > ClientHello > > Cipher_suites =3D TLS_ECDHE_ECDSS> > > NegotiatedDHParams=3D > > NegotiatedECDHParams=3D > > ClientKeyExchange=3D<(dhe, ffdhe2432), (ecdh, P-256)> > > > > > ServerHello > > > Cipher_suite =3D ?????? > > > NegotiatedDHParams =3D > > > NegotiatedECHDParams =3D > > > > ClientHello > > Copy above with a different ClientKeyExchange extension. > > > > > > I don=E2=80=99t know what is going to be placed in the Cipher_suite field= so that > the client can say =E2=80=93 who there is a mismatch in the keys that I p= assed in, > but I should not expect to see a ServerkeyExchange message (which I might > not like). > > > > Putting a cipher suite means that the client must check for an overlap > between the negotiated params extension for that suite to check for an > overlap between what the server returns and what it put into the client k= ey > exchange record. > > Putting a cipher suite means that the client might get locked into doing > DH in this case, when it would prefer doing ECDH for P-521 to doing DH t > 4096. > > > > It was not clear to me from the document, but I think it is correct, that > the way this is handled is to use the negotiated params extensions to > declare what sizes I support, even if I did not send keys of that size to > start with. > If I understand your question, then I think the answer is: yes. The client sends a list of all the ciphersuite and group values it supports and then sends some subset of the keys in his CKE. The server then selects the specific ciphersuite/group he wants. If the client has already supplied a share for that, great. If not, the client needs to resent. The intention is that this has the same negotiation properties as TLS currently has, namely that the client announces all of his capabilities and the server selects what he wants. -Ekr --e89a8f6470216b533e050208b6ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: base64 PGRpdiBkaXI9Imx0ciI+PGRpdiBjbGFzcz0iZ21haWxfZXh0cmEiPjxkaXYgY2xhc3M9ImdtYWls X3F1b3RlIj5PbiBNb24sIFNlcCAxLCAyMDE0IGF0IDM6MjEgUE0sIEppbSBTY2hhYWQgPHNwYW4g ZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZkBhdWd1c3RjZWxsYXJzLmNvbSIgdGFy Z2V0PSJfYmxhbmsiPmlldGZAYXVndXN0Y2VsbGFycy5jb208L2E+Jmd0Ozwvc3Bhbj4gd3JvdGU6 PGJyPg0KDQo8YmxvY2txdW90ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46MCAw IDAgLjhleDtib3JkZXItbGVmdDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij48ZGl2 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj48cCBjbGFzcz0iTXNvTm9y bWFsIj5JIGFtIHRyeWluZyB0byBmaWd1cmUgb3V0IGhvdyB0aGlzIHdvcmtzIGFuZCBJIGZpbmQg bXlzZWxmIGNvbmZ1c2VkIGFuZCBub3QgYWJsZSB0byBtYWtlIGhlYWR3YXkuPHU+PC91Pjx1Pjwv dT48L3A+DQoNCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjx1PjwvdT7CoDx1PjwvdT48L3A+PHAgY2xh c3M9Ik1zb05vcm1hbCI+TXkgdmlldyBvZiB0aGUgbWVzc2FnZXMgbG9va3MgbGlrZSB0aGUgZm9s bG93aW5nOjx1PjwvdT48dT48L3U+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPihZZXMgSSBrbm93 IHRoYXQgSSBoYXZlIHNob3J0ZW5lZCB0aGUgY2lwaGVyIHN1aXRlIHN0cmluZ3MgYW5kIGhhdmUg ZGVmaW5lZCBhIG5ldyBleHRlbnNpb24gZm9yIEVDREggcGFyYW1ldGVycyB0aGF0IEkgZG8gbm90 IGJlbGlldmUgZXhpc3RzIHlldC4pPHU+PC91Pjx1PjwvdT48L3A+DQoNCjxwIGNsYXNzPSJNc29O b3JtYWwiPjx1PjwvdT7CoDx1PjwvdT48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2xpZW50SGVs bG88dT48L3U+PHU+PC91PjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj7CoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqAgQ2lwaGVyX3N1aXRlcyA9ICZsdDtUTFNfREhFX1JTQSwgVExTX0RIRV9E U1MsIFRMU19FQ0RIRV9SU0EsIFRMU19FQ0RIRV9FQ0RTUyZndDs8dT48L3U+PHU+PC91PjwvcD4N Cg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIE5l Z290aWF0ZWRESFBhcmFtcz0mbHQ7ZmZkaGUyNDMyLCBmZmRoZTQwOTYmZ3Q7PHU+PC91Pjx1Pjwv dT48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg IE5lZ290aWF0ZWRFQ0RIUGFyYW1zPSZsdDtQLTI1NiwgUC01MjEmZ3Q7PHU+PC91Pjx1PjwvdT48 L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIENs aWVudEtleUV4Y2hhbmdlPSZsdDsoZGhlLCBmZmRoZTI0MzIpLCAoZWNkaCwgUC0yNTYpJmd0Ozx1 PjwvdT48dT48L3U+PC9wPg0KDQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48L3U+wqA8dT48L3U+ PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgIFNlcnZlckhlbGxvPHU+PC91Pjx1PjwvdT48L3A+PHAgY2xhc3M9Ik1zb05v cm1hbCI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBDaXBoZXJfc3VpdGUgPSA/Pz8/Pz88dT48L3U+PHU+ PC91PjwvcD4NCg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBOZWdv dGlhdGVkREhQYXJhbXMgPSAmbHQ7ZmZkaGU0MDk2Jmd0Ozx1PjwvdT48dT48L3U+PC9wPjxwIGNs YXNzPSJNc29Ob3JtYWwiPsKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgTmVnb3RpYXRlZEVDSERQYXJhbXMg PSAmbHQ7UC01MjEmZ3Q7PHU+PC91Pjx1PjwvdT48L3A+DQoNCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjx1PjwvdT7CoDx1PjwvdT48L3A+PHAgY2xhc3M9Ik1zb05vcm1hbCI+Q2xpZW50SGVsbG88dT48 L3U+PHU+PC91PjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj7CoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqAgQ29weSBhYm92ZSB3aXRoIGEgZGlmZmVyZW50IENsaWVudEtleUV4Y2hhbmdlIGV4 dGVuc2lvbi48dT48L3U+PHU+PC91PjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj4NCg0KPHU+PC91 PsKgPHU+PC91PjwvcD48cCBjbGFzcz0iTXNvTm9ybWFsIj48dT48L3U+wqA8dT48L3U+PC9wPjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgZG9u4oCZdCBrbm93IHdoYXQgaXMgZ29pbmcgdG8gYmUgcGxh Y2VkIGluIHRoZSBDaXBoZXJfc3VpdGUgZmllbGQgc28gdGhhdCB0aGUgY2xpZW50IGNhbiBzYXkg 4oCTIHdobyB0aGVyZSBpcyBhIG1pc21hdGNoIGluIHRoZSBrZXlzIHRoYXQgSSBwYXNzZWQgaW4s IGJ1dCBJIHNob3VsZCBub3QgZXhwZWN0IHRvIHNlZSBhIFNlcnZlcmtleUV4Y2hhbmdlIG1lc3Nh Z2UgKHdoaWNoIEkgbWlnaHQgbm90IGxpa2UpLjx1PjwvdT48dT48L3U+PC9wPg0KDQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48dT48L3U+wqA8dT48L3U+PC9wPjxwIGNsYXNzPSJNc29Ob3JtYWwiPlB1 dHRpbmcgYSBjaXBoZXIgc3VpdGUgbWVhbnMgdGhhdCB0aGUgY2xpZW50IG11c3QgY2hlY2sgZm9y IGFuIG92ZXJsYXAgYmV0d2VlbiB0aGUgbmVnb3RpYXRlZCBwYXJhbXMgZXh0ZW5zaW9uIGZvciB0 aGF0IHN1aXRlIHRvIGNoZWNrIGZvciBhbiBvdmVybGFwIGJldHdlZW4gd2hhdCB0aGUgc2VydmVy IHJldHVybnMgYW5kIHdoYXQgaXQgcHV0IGludG8gdGhlIGNsaWVudCBrZXkgZXhjaGFuZ2UgcmVj b3JkLjx1PjwvdT48dT48L3U+PC9wPg0KDQo8YnI+PHAgY2xhc3M9Ik1zb05vcm1hbCI+UHV0dGlu ZyBhIGNpcGhlciBzdWl0ZSBtZWFucyB0aGF0IHRoZSBjbGllbnQgbWlnaHQgZ2V0IGxvY2tlZCBp bnRvIGRvaW5nIERIIGluIHRoaXMgY2FzZSwgd2hlbiBpdCB3b3VsZCBwcmVmZXIgZG9pbmcgRUNE SCBmb3IgUC01MjEgdG8gZG9pbmfCoCBESCB0IDQwOTYuPHU+PC91Pjx1PjwvdT48L3A+PHAgY2xh c3M9Ik1zb05vcm1hbCI+PHU+PC91PsKgPHU+PC91PjwvcD4NCg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SXQgd2FzIG5vdCBjbGVhciB0byBtZSBmcm9tIHRoZSBkb2N1bWVudCwgYnV0IEkgdGhpbmsg aXQgaXMgY29ycmVjdCwgdGhhdCB0aGUgd2F5IHRoaXMgaXMgaGFuZGxlZCBpcyB0byB1c2UgdGhl IG5lZ290aWF0ZWQgcGFyYW1zIGV4dGVuc2lvbnMgdG8gZGVjbGFyZSB3aGF0IHNpemVzIEkgc3Vw cG9ydCwgZXZlbiBpZiBJIGRpZCBub3Qgc2VuZCBrZXlzIG9mIHRoYXQgc2l6ZSB0byBzdGFydCB3 aXRoLsKgIDx1PjwvdT48dT48L3U+PC9wPg0KDQo8L2Rpdj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+ PC9kaXY+PGRpdj5JZiBJIHVuZGVyc3RhbmQgeW91ciBxdWVzdGlvbiwgdGhlbiBJIHRoaW5rIHRo ZSBhbnN3ZXIgaXM6IHllcy48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PlRoZSBjbGllbnQgc2Vu ZHMgYSBsaXN0IG9mIGFsbCB0aGUgY2lwaGVyc3VpdGUgYW5kIGdyb3VwIHZhbHVlcyBpdCBzdXBw b3J0czwvZGl2PjxkaXY+YW5kIHRoZW4gc2VuZHMgc29tZSBzdWJzZXQgb2YgdGhlIGtleXMgaW4g aGlzIENLRS4gVGhlIHNlcnZlciB0aGVuPC9kaXY+DQoNCjxkaXY+c2VsZWN0cyB0aGUgc3BlY2lm aWMgY2lwaGVyc3VpdGUvZ3JvdXAgaGUgd2FudHMuIElmIHRoZSBjbGllbnQgaGFzIGFscmVhZHk8 L2Rpdj48ZGl2PnN1cHBsaWVkIGEgc2hhcmUgZm9yIHRoYXQsIGdyZWF0LiBJZiBub3QsIHRoZSBj bGllbnQgbmVlZHMgdG8gcmVzZW50LjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+VGhlIGludGVu dGlvbiBpcyB0aGF0IHRoaXMgaGFzIHRoZSBzYW1lIG5lZ290aWF0aW9uIHByb3BlcnRpZXMgYXMg VExTPC9kaXY+DQoNCjxkaXY+Y3VycmVudGx5IGhhcywgbmFtZWx5IHRoYXQgdGhlIGNsaWVudCBh bm5vdW5jZXMgYWxsIG9mIGhpcyBjYXBhYmlsaXRpZXM8L2Rpdj48ZGl2PmFuZCB0aGUgc2VydmVy IHNlbGVjdHMgd2hhdCBoZSB3YW50cy48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pi1Fa3I8L2Rp dj48ZGl2Pjxicj48L2Rpdj48L2Rpdj48L2Rpdj48L2Rpdj4NCg== --e89a8f6470216b533e050208b6ad-- From nobody Mon Sep 1 15:59:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CA431A0B83 for ; Mon, 1 Sep 2014 15:59:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rSXRkSHsAwSx for ; Mon, 1 Sep 2014 15:59:11 -0700 (PDT) Received: from smtp2.pacifier.net (smtp2.pacifier.net [64.255.237.172]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A75181A0B7D for ; Mon, 1 Sep 2014 15:59:11 -0700 (PDT) Received: from Philemon (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp2.pacifier.net (Postfix) with ESMTPSA id D623C2CA09; Mon, 1 Sep 2014 15:59:10 -0700 (PDT) From: "Jim Schaad" To: "'Eric Rescorla'" References: <00c001cfc633$1964ec70$4c2ec550$@augustcellars.com> In-Reply-To: Date: Mon, 1 Sep 2014 15:56:50 -0700 Message-ID: <00d101cfc638$042f7140$0c8e53c0$@augustcellars.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQHQo1fizZC555npRqfASzSZUrg2IwFMcajMm+DE7MA= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/f6Y127fCnCY8ftDBNUXq5A3h6w8 Cc: tls@ietf.org Subject: Re: [TLS] Clarifictions for failure to agree on key sizes during hello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 01 Sep 2014 22:59:13 -0000 From: Eric Rescorla [mailto:ekr@rtfm.com]=20 Sent: Monday, September 01, 2014 3:41 PM To: Jim Schaad Cc: tls@ietf.org Subject: Re: [TLS] Clarifictions for failure to agree on key sizes = during hello On Mon, Sep 1, 2014 at 3:21 PM, Jim Schaad = wrote: I am trying to figure out how this works and I find myself confused and = not able to make headway. =20 My view of the messages looks like the following: (Yes I know that I have shortened the cipher suite strings and have = defined a new extension for ECDH parameters that I do not believe exists = yet.) =20 ClientHello Cipher_suites =3D NegotiatedDHParams=3D NegotiatedECDHParams=3D ClientKeyExchange=3D<(dhe, ffdhe2432), (ecdh, P-256)> =20 = ServerHello = Cipher_suite =3D ?????? = NegotiatedDHParams =3D = NegotiatedECHDParams =3D =20 ClientHello Copy above with a different ClientKeyExchange extension. =20 =20 I don=E2=80=99t know what is going to be placed in the Cipher_suite = field so that the client can say =E2=80=93 who there is a mismatch in = the keys that I passed in, but I should not expect to see a = ServerkeyExchange message (which I might not like). =20 Putting a cipher suite means that the client must check for an overlap = between the negotiated params extension for that suite to check for an = overlap between what the server returns and what it put into the client = key exchange record. Putting a cipher suite means that the client might get locked into doing = DH in this case, when it would prefer doing ECDH for P-521 to doing DH = t 4096. =20 It was not clear to me from the document, but I think it is correct, = that the way this is handled is to use the negotiated params extensions = to declare what sizes I support, even if I did not send keys of that = size to start with. =20 If I understand your question, then I think the answer is: yes. The client sends a list of all the ciphersuite and group values it = supports and then sends some subset of the keys in his CKE. The server then selects the specific ciphersuite/group he wants. If the client has = already supplied a share for that, great. If not, the client needs to resent. The intention is that this has the same negotiation properties as TLS currently has, namely that the client announces all of his capabilities and the server selects what he wants. -Ekr So just to be clear. In this case the server would put TLS_RSA_DHE_ = into the cipher suite field, and the client would understand that there = is not going to be a server key exchange record because the lack of = intersection between what it sent in the client key exchange record and = the the negotiated_dhe_params extension returned from the server. In = this case the negotiated_ecdhe_params extension would not need to be = sent from the server since it is extraneous information. Jim From nobody Mon Sep 1 16:07:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E694E1A6EDA for ; Mon, 1 Sep 2014 16:07:12 -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=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMXwDO48Ewlw for ; Mon, 1 Sep 2014 16:07:08 -0700 (PDT) Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 087E81A6ED9 for ; Mon, 1 Sep 2014 16:07:02 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id bs8so13349715wib.9 for ; Mon, 01 Sep 2014 16:06:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=AO6IJmHvdxwwnyDsD6W0cIhqC3RIB3nsdPTxL+cqDJc=; b=kb6SdHkfIEbMTJgMSrUQIwm5NTFbh6aVYipKo6+0r1wAvYsl7xW6zE/355dUSqowd6 MgCaBMfbrgdIrPssSKsxOGLcbXeENnvSug4y5EpWKhq9UMu7V1WDxIc3RvVjR1EFzMA5 OIBP+VisX3FiPzlcWJrqJwFynL5/OAjBTvQZU/LiDf1pLZ14QlHQVi/joDrdRJhkEYg/ cuDNC9JgT8N0jg7mWdzZwSw/E0lLMB3471E499Es9mfexvBXW0HKTpm/P2cTCu3X8a2l 7f8gAMzJEI+vCX0eDKQZMGOY5BiPIMVYIY42wzTLHTNcDXTEQSnn1EILU4RYOGAz1HHo WWJg== X-Gm-Message-State: ALoCoQnVBzmKTja4N84FvhE2oi3ahSTwzobi1xf2/vNXAKhbaSKSfwBZmbb3C2Eu3bNPBG9PMcTv X-Received: by 10.194.90.114 with SMTP id bv18mr35904992wjb.63.1409612819628; Mon, 01 Sep 2014 16:06:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.217.128.12 with HTTP; Mon, 1 Sep 2014 16:06:19 -0700 (PDT) X-Originating-IP: [2620:101:80fc:232:8413:1a4c:daa5:7b99] In-Reply-To: <00d101cfc638$042f7140$0c8e53c0$@augustcellars.com> References: <00c001cfc633$1964ec70$4c2ec550$@augustcellars.com> <00d101cfc638$042f7140$0c8e53c0$@augustcellars.com> From: Eric Rescorla Date: Mon, 1 Sep 2014 16:06:19 -0700 Message-ID: To: Jim Schaad Content-Type: multipart/alternative; boundary=047d7bfcfdbc6296b10502090ff2 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0s5lWb_FPTkczJvRdlXJ7SefvvU Cc: "tls@ietf.org" Subject: Re: [TLS] Clarifictions for failure to agree on key sizes during hello X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 01 Sep 2014 23:07:15 -0000 --047d7bfcfdbc6296b10502090ff2 Content-Type: text/plain; charset=UTF-8 > > > So just to be clear. In this case the server would put TLS_RSA_DHE_ into > the cipher suite field, and the client would understand that there is not > going to be a server key exchange record because the lack of intersection > between what it sent in the client key exchange record and the the > negotiated_dhe_params extension returned from the server. In this case the > negotiated_ecdhe_params extension would not need to be sent from the server > since it is extraneous information. Affirmative. -Ekr > > Jim > > > --047d7bfcfdbc6296b10502090ff2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

So just to be clear.=C2=A0 In this case the server would put TL= S_RSA_DHE_ into the cipher suite field, and the client would understand tha= t there is not going to be a server key exchange record because the lack of= intersection between what it sent in the client key exchange record and th= e the negotiated_dhe_params extension returned from the server.=C2=A0 In th= is case the negotiated_ecdhe_params extension would not need to be sent fro= m the server since it is extraneous information.

Affirmative.

-Ekr
= =C2=A0

Jim



--047d7bfcfdbc6296b10502090ff2-- From nobody Mon Sep 1 16:21:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D98621A6EDC for ; Mon, 1 Sep 2014 16:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.111 X-Spam-Level: X-Spam-Status: No, score=0.111 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_HTML_ATTACH=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1FBbYcEXmWqD for ; Mon, 1 Sep 2014 16:21:21 -0700 (PDT) Received: from smtp4.pacifier.net (smtp4.pacifier.net [64.255.237.176]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CE7E1A6EDB for ; Mon, 1 Sep 2014 16:21:21 -0700 (PDT) Received: from Philemon (winery.augustcellars.com [206.212.239.129]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp4.pacifier.net (Postfix) with ESMTPSA id D17F138F0B for ; Mon, 1 Sep 2014 16:21:19 -0700 (PDT) From: "Jim Schaad" To: Date: Mon, 1 Sep 2014 16:18:58 -0700 Message-ID: <00d201cfc63b$1c48b1d0$54da1570$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00D3_01CFC600.6FEA27F0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: Ac/GNCmKgoBDcylmToWffrwtpa0mlg== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EOqnUjaLpqWIC1MW_rtKj6AMAuA Subject: [TLS] Master Secret Computation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 01 Sep 2014 23:21:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00D3_01CFC600.6FEA27F0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit This message applies to both the 1.3 TLS document and to the session hash document. I have not ever implemented TLS, so I have been spending some time reading the documents to try and figure out how things are going to work. Based on mail see, I have assumed that 1.3 is going to adopt the extended hash computation for the master secret and have created my table based on this. (If this is not the case then I think it needs to be argued.) As part of putting together the attacked picture, I read a number of different TLS documents which are not part of the core spec. It is possible that some of these are no longer needed and should be ruled out as possible extensions to the TLS 1.3 document, but would be relevant to the extension for the 1.2 (and prior) documents. Notes on the picture that I have included: Items tagged with [1] are sent only in the event that the server does not want to have a client certificate. Items tagged with [2] are sent only in the event that the a) there is a client certificate or b) the new session ticket extension is being used. Items tagged with [3] are sent in the event that a restart is made because of a mismatch of key agree groups. I am not clear if the use of the Supplemental Data extension means that the server Finish message cannot be sent before receiving the response from the client. The new session ticket extension requires that the client finish message be validated before it can be sent to the client, thus it falls into the [2] grouping. The green means that the handshake message is part of the hash computation. The yellow means that it would be part of the computation for [2] but not for [1]. The "pink" is part of my assumption that a the hashing should include the failed early handshake message. The current hashing document says that the hash would not include the CertificateVerify message (for the client). I am assuming that this is because there is a large presumption that the hash that is used for the PRF function and the hash that the client would use in computing the CertificateVerify message is going to same. This presumption should probably be documented. I am unsure what the correct behavior should be in the event that the SupplementalData extension is used, but the client certificate message is not used. Should this be part of the master secret hash or not? In looking at the sequence, doing a re-negotiation would seem to have a bad property of going from the cipher suite which uses the hash of the handshake to one that just uses the keys and the randoms part way through the re-negotiation process. This means that any application data sent between the first and the second change_cipher_suite messages would potentially not be as well protected. This could be fixed by not having the first pair of change_cipher_suite messages in the event of a re-negotiation as there is no need to go from a NULL_NULL cipher suite to one which has encryption. Jim ------=_NextPart_000_00D3_01CFC600.6FEA27F0 Content-Type: text/html; name="tls-table.htm" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="tls-table.htm"
PRF Hash Client Has Server Has
ClientHello fixed    
signature_algorithms   restricted fixed
early_data      
ClientKeyExchange "---->      
<---- ServerHello[3]      
ClientHello[3]      
ClientKeyExchange[3] "---->      
ServerHello      
ServerKeyExchange      
[ChangeCipherSuite]  
EnryptedExtensions*      
SupplementalData*      
Certificate*      
CertificateStatus*      
CertificateRequest[2]    
CertificateVerify*    
ServerHelloDone[2]    
[ChangeCipherSuite][1]
<---- Finished[1]
[ChangeCipherSuite]
SupplementalData*    
Certificate*[2]   fixed
CertificateURL*[2]    
CertificateVerify[2]
[ChangeCipherSuite]
Finished "----->
NewSessionTicket*[2]
[ChangeCipherSuite][2]
Finished[2]
------=_NextPart_000_00D3_01CFC600.6FEA27F0-- From nobody Tue Sep 2 08:15:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D15C51A06AC for ; Tue, 2 Sep 2014 08:15:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.968 X-Spam-Level: X-Spam-Status: No, score=-2.968 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ai_mfxRxXZF9 for ; Tue, 2 Sep 2014 08:15:27 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 393CD1A0686 for ; Tue, 2 Sep 2014 08:15:27 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s82FFDPR007218; Tue, 2 Sep 2014 11:15:26 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: "'holz@net.in.tum.de'" , "'tls@ietf.org'" Thread-Topic: [TLS] NULL cipher to become a MUST NOT in UTA BCP Thread-Index: AQHPxfjrFyzs0NTAq0uDUGuetkiK35vt9W44 Date: Tue, 2 Sep 2014 15:15:10 +0000 Message-ID: <65D2FD736B6B2B48B2EAD2BD189DC9CC20BBCF@LLE2K10-MBX01.mitll.ad.local> In-Reply-To: <54048985.1020005@net.in.tum.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.34.14.22] 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.12.52, 1.0.27, 0.0.0000 definitions=2014-09-02_05:2014-09-02,2014-09-02,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-1402240000 definitions=main-1409020180 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8qbYTjBhS97_so8hNE31RLKq9AQ Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 02 Sep 2014 15:15:30 -0000 IMHO there is a need for integrity-only protection. Monitoring traffic insi= de your administrative boundary is one obvious example.=20 -- 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, Lexington, MA 02420-9185 =20 Web: http://www.ll.mit.edu/CST/ MIT LL Root CA: ----- Original Message ----- From: Ralph Holz [mailto:holz@net.in.tum.de] Sent: Monday, September 01, 2014 10:58 AM=0A= To: tls@ietf.org Subject: [TLS] NULL cipher to become a MUST NOT in UTA BCP Dear list,=0A= =0A= I would like to notify the list of a feature in the draft for Best=0A= Practices "Recommendations for Secure Use of TLS and DTLS"=0A= =0A= http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-02=0A= =0A= =3D> "Implementations MUST NOT negotiate the NULL cipher suites"=0A= =0A= This may lead to implementations dropping NULL (or making it hard to=0A= enable).=0A= =0A= There used to be one reasonable use case for NULL that I am personally=0A= aware of: grid traffic between large computing centres. Our group did=0A= see such high-speed, high-volume traffic on our network monitors when we=0A= did SSL/TLS/X.509 analyses - that was 3 years ago.=0A= =0A= My contacts at grid centres tell me that NULL encryption was useful then=0A= as the data was public anyway and good integrity was all that was=0A= needed. I am told by one centre at least there is no real need for NULL=0A= any more. In fact, the agreement seems to be that that cipher should be=0A= eliminated now.=0A= =0A= My personal take as one of the authors of the BCP is that the UTA WG=0A= should process UNLESS someone has a use case that is relevant on the=0A= same scale, or thinks the above statement does not hold in general.=0A= =0A= In that case, please bring your use case to the attention of the UTA or=0A= directly to the authors (i.e. Yaron Sheffer, yaronf.ietf@gmail.com, or=0A= me). We would like to keep any discussion focused.=0A= =0A= Thanks,=0A= Ralph=0A= =0A= -- =0A= Ralph Holz=0A= I8 - Network Architectures and Services=0A= Technische Universit=E4t M=FCnchen=0A= http://www.net.in.tum.de/de/mitarbeiter/holz/=0A= Phone +49.89.289.18043=0A= PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF=0A= =0A= _______________________________________________=0A= TLS mailing list=0A= TLS@ietf.org=0A= https://www.ietf.org/mailman/listinfo/tls=0A= From nobody Tue Sep 2 08:23:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62F4D1A0424 for ; Tue, 2 Sep 2014 08:23:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id equel1M5_X92 for ; Tue, 2 Sep 2014 08:23:10 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AB9B1A0385 for ; Tue, 2 Sep 2014 08:23:10 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8BCC22AB2B7; Tue, 2 Sep 2014 15:23:08 +0000 (UTC) Date: Tue, 2 Sep 2014 15:23:08 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140902152308.GB14392@mournblade.imrryr.org> References: <54048985.1020005@net.in.tum.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54048985.1020005@net.in.tum.de> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HQ7jVQXbDRMcxJ05lFO_6wfKtKQ Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@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: Tue, 02 Sep 2014 15:23:12 -0000 On Mon, Sep 01, 2014 at 04:58:13PM +0200, Ralph Holz wrote: > Practices "Recommendations for Secure Use of TLS and DTLS" > > http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-02 > > => "Implementations MUST NOT negotiate the NULL cipher suites" > > This may lead to implementations dropping NULL (or making it hard to > enable). > > My personal take as one of the authors of the BCP is that the UTA WG > should process UNLESS someone has a use case that is relevant on the > same scale, or thinks the above statement does not hold in general. Postfix supports authenticated NULL ciphers for communication between an MTA and local (127.0.0.1 or ::1) LMTP server. Encrypting local IPC is just a waste of CPU. Yes, this is a specialized use-case. This can also be useful for access-controlled hand-off between reverse HTTP proxies, and web applications that support client certificates. These are sometimes used to implement GSSAPI SPNEGO support in front of application that don't support GSSAPI. The application is configured to listen on 127.0.0.1, but is then vulnerable to impersonation attacks from anything running on the host. With authenticated NULL ciphers, the connection can be restricted to just the front-end reverse proxy. -- Viktor. From markulf@microsoft.com Tue Sep 2 08:04:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A36E1A8789 for ; Tue, 2 Sep 2014 08:04:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.002 X-Spam-Level: X-Spam-Status: No, score=-0.002 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R6j6gTXFn7P1 for ; Tue, 2 Sep 2014 08:04:35 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1lp0142.outbound.protection.outlook.com [207.46.163.142]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B0981A879A for ; Tue, 2 Sep 2014 08:04:31 -0700 (PDT) Received: from BN3PR0301CA0003.namprd03.prod.outlook.com (25.160.180.141) by BY2PR03MB585.namprd03.prod.outlook.com (10.141.143.16) with Microsoft SMTP Server (TLS) id 15.0.1005.10; Tue, 2 Sep 2014 15:04:28 +0000 Received: from BL2FFO11FD035.protection.gbl (2a01:111:f400:7c09::186) by BN3PR0301CA0003.outlook.office365.com (2a01:111:e400:4000::13) with Microsoft SMTP Server (TLS) id 15.0.1019.16 via Frontend Transport; Tue, 2 Sep 2014 15:04:27 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD035.mail.protection.outlook.com (10.173.161.131) with Microsoft SMTP Server (TLS) id 15.0.1010.11 via Frontend Transport; Tue, 2 Sep 2014 15:04:26 +0000 Received: from 064-smtp-out.microsoft.com (141.251.33.15) by TK5EX14HUBC102.redmond.corp.microsoft.com (157.54.7.154) with Microsoft SMTP Server (TLS) id 14.3.195.2; Tue, 2 Sep 2014 15:03:41 +0000 Received: from AMSPRD3001MB017.064d.mgd.msft.net ([169.254.8.57]) by AMSPRD3001HT002.064d.mgd.msft.net ([141.251.33.15]) with mapi id 14.16.0466.000; Tue, 2 Sep 2014 15:03:38 +0000 From: Markulf Kohlweiss To: "tls@ietf.org" Thread-Topic: Re: [TLS] Simplifying the proof Thread-Index: Ac/GuqXgGSxMP7KrRoGu94JOxIEFpA== Date: Tue, 2 Sep 2014 15:03:38 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [141.251.33.5] Content-Type: multipart/alternative; boundary="_000_C90F31503317124C8A9B59786EF212EA032D2CAMSPRD3001MB01706_" MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(6009001)(438002)(243025005)(189002)(199003)(107046002)(46102001)(21056001)(84326002)(71186001)(86362001)(86612001)(74502001)(85852003)(74662001)(79102001)(83322001)(6806004)(55846006)(19580395003)(81342001)(44976005)(19300405004)(68736004)(4396001)(66066001)(84676001)(69596002)(2656002)(81542001)(77982001)(16236675004)(110136001)(15975445006)(80022001)(97736001)(87936001)(19625215002)(106466001)(107886001)(15202345003)(90102001)(64706001)(16796002)(81156004)(33656002)(76482001)(92726001)(83072002)(31966008)(20776003)(92566001)(2351001)(86146001)(54356999)(95666004)(77096002)(99396002)(26826002)(50986999)(85306004)(2501002)(512954002); DIR:OUT; SFP:; SCL:1; SRVR:BY2PR03MB585; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 0322B4EDE1 Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=markulf@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xWHuqXjSUeltPNbvpXr_mypriIE Subject: Re: [TLS] Simplifying the proof X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 02 Sep 2014 15:45:31 -0000 --_000_C90F31503317124C8A9B59786EF212EA032D2CAMSPRD3001MB01706_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Watson, Nigel, I would like to reply to your email on simplifying the proof of TLS, primarily to keep this important discussion alive and to invite everyone interested in cryptographic definitions and modelling to participate. There have been many efforts on verifying TLS, some computer checked but in the symbolic cryptographic model, others hand-written and brain-checked in the computational cryptographic model. miTLS is our latest effort to be faithful to the TLS protocol, both with respect to the low-level cryptography, unless abstracted by cryptographic assumptions, as well as with respect to the protocol logic. (http://www.mitls.org, http://eprint.iacr.org/2014/182) You are right, extending the miTLS proof to TLS 1.3 is hard work. We believe that it would be worthwhile. One goal of using a high-level functional programming language to implement miTLS was to make it both accessible for human as well as machine reasoning. In addition it's meant to be a test platform for implementing new extensions and even attacks. Working out which changes in TLS 1.3 would simplify a security analysis is an important and timely question---at the minimum we should aim at not making it harder. At the same time there is no panacea or silver bullet. The "encrypted finished message" or "key confirmation" issue is more of a distraction or red herring than a show stopper for verification and provable security. It means that a key-exchange protocol secure under a Bellare & Rogaway style definitions may not necessarily result in a secure Handshake protocol when used in TLS. But there are many other reasons why this is not the case, such as key reuse for encryption and signing, ciphersuite negotiation, resumption, backward compatibility through support of older protocol versions that make use of the same long-term keys... We completely agree that it is desirable to "defining security properties we want new features to have" in advance "instead of going back from a design to determine the security it actually provides" (if any). Protocol design and protocol analysis should go hand-in-hand. At the danger of preaching to the converted, the ideal methodology for designing a protocol corresponds to that of building a bridge, the requirements should come first, then one should get an understanding of the building blocks one wants to use--and their properties-- and how to put them together to get the necessary structural properties. A few constructive and less philosophical ideas: * While developing miTLS, we felt that the biggest obstacle to verifying TLS was the lack of an API which formalizes how applications should use TLS. * To remove distraction and be closer to standard models like Bellare & Rogaway, we would prefer unencrypted finished messages. In practice this means that the finished message should be sent before the ChangeCipherSuite message. * A lot of (tedious) work in miTLS went into proving that message formats are disjoint to achieve cross-protocol security, e.g. that ServerKeyExchange parameters for one key exchange method cannot be confused with ServerKeyExchange parameters for another ciphersuite. See http://www.cosic.esat.kuleuven.be/publications/thesis-208.pdf for a discussion of these attacks. Changing the message format would prevent such attacks once and for all. Ultimately if our verification methodology is shown to work and once we have sufficient confidence that our model captures all necessary requirements we can remove redundant security components in the protocol that are not necessary for security, but that were put there just in case. This makes both the security analysis and the protocol itself more efficient. In future work on miTLS we want to focus particularly on system engineering and performance aspects. To conclude and falling back into the philosophical again, protocol analysis---be it of the cryptographic or the formal methods variant---is not mean to be formalism for the sake of formalism, but something in which everyone building secure systems participates. Domain knowledge is just as important (arguably more important) than cryptographic reductions or logical specification of functions to help tools along, most of which in the real world are tedious but mathematically simple. The biggest danger is that, in order to avoid this tedious, often boring work, researchers focus on his/her own part of the puzzle--i.e. stays on separate islands. Our hope is that, with miTLS already supporting SSL 3.0 - TLS 1.2, a lot of existing code and annotations can be reused to verify TLS 1.3. Let's continue building bridges, Markulf --_000_C90F31503317124C8A9B59786EF212EA032D2CAMSPRD3001MB01706_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Watson, Nigel,

 

I would like to reply to your email on simplifying t= he proof of TLS,

primarily to keep this important discussion alive an= d to invite

everyone interested in cryptographic definitions and= modelling to

participate.

 

There have been many efforts on verifying TLS, some = computer checked

but in the symbolic cryptographic model, others hand= -written and

brain-checked in the computational cryptographic mod= el.

 

miTLS is our latest effort to be faithful to the TLS= protocol, both

with respect to the low-level cryptography, unless a= bstracted by

cryptographic assumptions, as well as with respect t= o the protocol

logic. (http://www.mitls.org, http://eprint.iacr.org= /2014/182)

 

You are right, extending the miTLS proof to TLS 1.3 = is hard work. We

believe that it would be worthwhile. One goal of usi= ng a high-level

functional programming language to implement miTLS w= as to make it both

accessible for human as well as machine reasoning. I= n addition it's

meant to be a test platform for implementing new ext= ensions and even

attacks.

 

Working out which changes in TLS 1.3 would simplify = a security

analysis is an important and timely question---at th= e minimum we

should aim at not making it harder.

 

At the same time there is no panacea or silver bulle= t. The “encrypted

finished message” or “key confirmation&#= 8221; issue is more of a distraction

or red herring than a show stopper for verification = and provable

security. It means that a key-exchange protocol secu= re under a Bellare

& Rogaway style definitions may not necessarily = result in a secure

Handshake protocol when used in TLS. But there are m= any other reasons

why this is not the case, such as key reuse for encr= yption and

signing, ciphersuite negotiation, resumption, backwa= rd compatibility

through support of older protocol versions that make= use of the same

long-term keys...

 

We completely agree that it is desirable to "de= fining security

properties we want new features to have" in adv= ance "instead of going

back from a design to determine the security it actu= ally provides" (if

any). Protocol design and protocol analysis should g= o hand-in-hand.

 

At the danger of preaching to the converted, the ide= al methodology for

designing a protocol corresponds to that of building= a bridge, the

requirements should come first, then one should get = an understanding

of the building blocks one wants to use--and their p= roperties-- and

how to put them together to get the necessary struct= ural properties.

 

A few constructive and less philosophical ideas:

 

* While developing miTLS, we felt that the biggest o= bstacle to

  verifying TLS was the lack of an API which fo= rmalizes how

  applications should use TLS.

 

* To remove distraction and be closer to standard mo= dels like Bellare

  & Rogaway, we would prefer unencrypted fi= nished messages. In

  practice this means that the finished message= should be sent before

  the ChangeCipherSuite message.

 

* A lot of (tedious) work in miTLS went into proving= that message

  formats are disjoint to achieve cross-protoco= l security, e.g. that

  ServerKeyExchange parameters for one key exch= ange method cannot be

  confused with ServerKeyExchange parameters fo= r another ciphersuite.

  See http://www.cosic.esat.kuleuven.be/publica= tions/thesis-208.pdf

  for a discussion of these attacks. Changing t= he message format would

  prevent such attacks once and for all.

 

Ultimately if our verification methodology is shown = to work and once

we have sufficient confidence that our model capture= s all necessary

requirements we can remove redundant security compon= ents in the

protocol that are not necessary for security, but th= at were put there

just in case. This makes both the security analysis = and the protocol

itself more efficient. In future work on miTLS we wa= nt to focus

particularly on system engineering and performance a= spects.  

 

To conclude and falling back into the philosophical = again, protocol

analysis---be it of the cryptographic or the formal = methods

variant---is not mean to be formalism for the sake o= f formalism, but

something in which everyone building secure systems = participates.

 

Domain knowledge is just as important (arguably more= important) than

cryptographic reductions or logical specification of= functions to help

tools along, most of which in the real world are ted= ious but

mathematically simple. The biggest danger is that, i= n order to avoid this

tedious, often boring work, researchers focus on his= /her own part of

the puzzle--i.e. stays on separate islands.

 

Our hope is that, with miTLS already supporting SSL = 3.0 - TLS 1.2,

a lot of existing code and annotations can be reused= to verify TLS 1.3.

 

Let’s continue building bridges,

 

Markulf

--_000_C90F31503317124C8A9B59786EF212EA032D2CAMSPRD3001MB01706_-- From nobody Tue Sep 2 08:58:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9D81A04F6 for ; Tue, 2 Sep 2014 08:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h6V-uQNKPjOR for ; Tue, 2 Sep 2014 08:58:29 -0700 (PDT) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38AD71A0444 for ; Tue, 2 Sep 2014 08:58:29 -0700 (PDT) Received: from [10.20.30.90] (142-254-17-22.dsl.dynamic.fusionbroadband.com [142.254.17.22]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id s82FwQ6J014486 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 2 Sep 2014 08:58:28 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-22.dsl.dynamic.fusionbroadband.com [142.254.17.22] claimed to be [10.20.30.90] Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Paul Hoffman In-Reply-To: <65D2FD736B6B2B48B2EAD2BD189DC9CC20BBCF@LLE2K10-MBX01.mitll.ad.local> Date: Tue, 2 Sep 2014 08:58:24 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <029F49F3-B25B-4B06-A694-88F4224356D0@vpnc.org> References: <65D2FD736B6B2B48B2EAD2BD189DC9CC20BBCF@LLE2K10-MBX01.mitll.ad.local> To: "Blumenthal, Uri - 0558 - MITLL" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5MJ__he-KYn6huzGd_ye0SH3wlg Cc: "tls@ietf.org" Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 02 Sep 2014 15:58:30 -0000 On Sep 2, 2014, at 8:15 AM, Blumenthal, Uri - 0558 - MITLL = wrote: > IMHO there is a need for integrity-only protection. Monitoring traffic = inside your administrative boundary is one obvious example.=20 That's not at all an "obvious" example for TLS. What could TLS = integrity-only protection buy you in that environment? It is only of = value if you can act when the integrity is broken, such as modified = packets. And yet there are essentially no systems where there is an = administrative interface for TLS that says what to do when the integrity = is broken. And yet there are *plenty* of examples of how to do this with = integrity-only IPsec. I support NULL encryption being a MUST NOT as long as IPsec supports = null encryption for the use cases that people want to force on TLS. --Paul Hoffman= From nobody Tue Sep 2 09:05:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EDE91A0700 for ; Tue, 2 Sep 2014 09:05:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.669 X-Spam-Level: X-Spam-Status: No, score=-0.669 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxHA-NVnx7mz for ; Tue, 2 Sep 2014 09:05:33 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 3E85F1A06EE for ; Tue, 2 Sep 2014 09:05:32 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 4B04648423 for ; Tue, 2 Sep 2014 16:05:32 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 4732148446 for ; Tue, 2 Sep 2014 16:05:32 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 268FC9804A for ; Tue, 2 Sep 2014 16:05:32 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.218]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Tue, 2 Sep 2014 12:05:31 -0400 From: "Salz, Rich" To: "tls@ietf.org" Date: Tue, 2 Sep 2014 12:05:30 -0400 Thread-Topic: [TLS] NULL cipher to become a MUST NOT in UTA BCP Thread-Index: Ac/GwdIOpf5qBMJUTkGysMHPCGMwkAABYenA Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BDBB@USMBX1.msg.corp.akamai.com> References: <54048985.1020005@net.in.tum.de> <20140902152308.GB14392@mournblade.imrryr.org> In-Reply-To: <20140902152308.GB14392@mournblade.imrryr.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/upfnBkjDyEDjpA3exmGdUHf2kKQ Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 02 Sep 2014 16:05:36 -0000 > Encrypting local IPC is just a waste of CPU. Not always. Imagine a component that had a root-priv escalation incident a= fter the system was booted. PFS for local IPC would keep that communicatio= n secure until the adversary managed to break one of the communicating proc= esses. We believe that would take much longer than just the initial RSE. =20 -- =20 Principal Security Engineer Akamai Technologies, Cambridge MA IM: rsalz@jabber.me Twitter: RichSalz From nobody Tue Sep 2 09:21:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0FC31A02BB for ; Tue, 2 Sep 2014 09:21:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.807 X-Spam-Level: ** X-Spam-Status: No, score=2.807 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FSL_HELO_BARE_IP_2=1.674, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cfHmL3Mvnj-R for ; Tue, 2 Sep 2014 09:21:11 -0700 (PDT) Received: from gateway16.websitewelcome.com (gateway16.websitewelcome.com [69.56.185.3]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B06A1A0311 for ; Tue, 2 Sep 2014 09:21:11 -0700 (PDT) Received: by gateway16.websitewelcome.com (Postfix, from userid 5007) id D71EA1A83889C; Tue, 2 Sep 2014 11:21:10 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway16.websitewelcome.com (Postfix) with ESMTP id 8A4BC1A838702 for ; Tue, 2 Sep 2014 11:21:10 -0500 (CDT) Received: from [96.231.227.95] (port=54139 helo=192.168.1.6) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XOqpR-0004kL-8o; Tue, 02 Sep 2014 11:21:09 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: Date: Tue, 2 Sep 2014 12:21:03 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <2C416956-7298-4E1D-BCD3-355CC663094E@ieca.com> References: To: "TLS@ietf.org (tls@ietf.org)" X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.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-IP: 96.231.227.95 X-Exim-ID: 1XOqpR-0004kL-8o X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.6) [96.231.227.95]:54139 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FAeuSGTzjP3FBhRndnLdEsza6aI Subject: Re: [TLS] TLS interim planning fall 2014 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 02 Sep 2014 16:21:13 -0000 Based on the responses in the doodle poll we=92re going to go with Paris = 21-22 October. We=92ll get the formal announcement out in a second = along with an agenda, etc. spt On Aug 27, 2014, at 17:11, Sean Turner wrote: > We would like to get input on the preferred dates and locations of an = interim TLS meeting. The dates on offer are: >=20 > October 1-2 > October 2-3 >=20 > in either Dublin or Paris >=20 > or=20 >=20 > October 20-21 > October 21-22 >=20 > in London, Dublin, or Paris. >=20 > Please fill out the following doodle poll to indicate your preferences = by the end of Friday September 29th: >=20 > http://doodle.com/6v3s6ve6zase766n >=20 > Thanks, >=20 > J&S From nobody Tue Sep 2 09:23:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0461A005C for ; Tue, 2 Sep 2014 09:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yY3D7gNHupeB for ; Tue, 2 Sep 2014 09:23:47 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 326461A6EFA for ; Tue, 2 Sep 2014 09:23:31 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 4A2982AB2B7; Tue, 2 Sep 2014 16:23:22 +0000 (UTC) Date: Tue, 2 Sep 2014 16:23:22 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140902162321.GC14392@mournblade.imrryr.org> References: <54048985.1020005@net.in.tum.de> <20140902152308.GB14392@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BDBB@USMBX1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BDBB@USMBX1.msg.corp.akamai.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xCYmV6Q8Et0dMZ29Das_K3eP2lM Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@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: Tue, 02 Sep 2014 16:23:49 -0000 On Tue, Sep 02, 2014 at 12:05:30PM -0400, Salz, Rich wrote: > > Encrypting local IPC is just a waste of CPU. > > Not always. Imagine a component that had a root-priv escalation > incident after the system was booted. PFS for local IPC would keep > that communication secure until the adversary managed to break one > of the communicating processes. We believe that would take much > longer than just the initial RSE. Root can generally read the data before it is encrypted (debug the sending or receiving process for example). Yes, "tcpdump lo" is easier. So while my statement could gain a qualifier that hedges it somewhat, it is essentially correct as is. FWIW, in the case of local IPC with MTA to MailStore LMTP, the connections tend to be rather short-lived. -- Viktor. From nobody Tue Sep 2 10:05:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53B551A0706 for ; Tue, 2 Sep 2014 10:05:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Es50glhh8mAe for ; Tue, 2 Sep 2014 10:05:14 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 39E1B1A0700 for ; Tue, 2 Sep 2014 10:05:13 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A32C2474C7 for ; Tue, 2 Sep 2014 17:05:10 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 960E4474BA for ; Tue, 2 Sep 2014 17:05:10 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 8E38A80040 for ; Tue, 2 Sep 2014 17:05:10 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.218]) by USMA1EX-CASHUB6.kendall.corp.akamai.com ([172.27.105.22]) with mapi; Tue, 2 Sep 2014 13:05:10 -0400 From: "Salz, Rich" To: "TLS@ietf.org (tls@ietf.org)" Date: Tue, 2 Sep 2014 13:05:09 -0400 Thread-Topic: tickets or sesssions or both (oh my) Thread-Index: Ac/Gz8oQp3LCuGinQ4CDT7fKauIhyw== Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08USMBX1msgcorp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PVNs4vcfrxYPMCa45rf9LVR5gy4 Subject: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 02 Sep 2014 17:05:19 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08USMBX1msgcorp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Right now we have sessions (server-side, possible scalability issues) and t= ickets (client-side, hard to make work well with PFS). A poll for this community: is one likely to be more strategic, or are both = likely to be important in the near term (say within two years after TLS 1.= 3 is done). -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rsalz@jabber.me Twitter: RichSalz --_000_2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08USMBX1msgcorp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Right now we hav= e sessions (server-side, possible scalability issues) and tickets (client-s= ide, hard to make work well with PFS).

<= o:p> 

A poll for this community: is one = likely to be more strategic, or are both likely to be important in the near= term  (say within two years after TLS 1.3 is done).

 

--  <= /o:p>

Principal Security Engineer

Akamai Technologies, Cambridge MA

IM: rsalz@jabber.me Twi= tter: RichSalz

 

= --_000_2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08USMBX1msgcorp_-- From nobody Tue Sep 2 10:11:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89C921A0273 for ; Tue, 2 Sep 2014 10:11:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t6AYWyMjcdED for ; Tue, 2 Sep 2014 10:11:27 -0700 (PDT) Received: from mx201.easyname.com (mx201.easyname.com [212.232.28.122]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC4F51A0243 for ; Tue, 2 Sep 2014 10:11:26 -0700 (PDT) Received: from 89-26-76-175.goll.dyn.salzburg-online.at ([89.26.76.175] helo=[192.168.0.11]) by mx.easyname.eu with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XOrc0-0002LD-Vz for tls@ietf.org; Tue, 02 Sep 2014 19:11:24 +0200 Message-ID: <5405F911.7090700@fussenegger.info> Date: Tue, 02 Sep 2014 19:06:25 +0200 From: "Richard Fussenegger, BSc" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: tls@ietf.org References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> Content-Type: multipart/alternative; boundary="------------040908040400030203080600" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rqqGrXuB8GZIZyzPKnGrHSAnY4E Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 02 Sep 2014 17:11:32 -0000 This is a multi-part message in MIME format. --------------040908040400030203080600 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit May I ask out of interest what the problem is with session tickets in regards to PFS? Or is it just the key rotation thing? Many browsers still don't implement session tickets, therefor removing sessions might be a problem that would be bad for fast adoption of version 1.3 (not that I count on this). Richard On 9/2/2014 7:05 PM, Salz, Rich wrote: > > Right now we have sessions (server-side, possible scalability issues) > and tickets (client-side, hard to make work well with PFS). > > A poll for this community: is one likely to be more strategic, or are > both likely to be important in the near term (say within two years > after TLS 1.3 is done). > > -- > > Principal Security Engineer > > Akamai Technologies, Cambridge MA > > IM: rsalz@jabber.me Twitter: RichSalz > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------040908040400030203080600 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit May I ask out of interest what the problem is with session tickets in regards to PFS? Or is it just the key rotation thing?
Many browsers still don't implement session tickets, therefor removing sessions might be a problem that would be bad for fast adoption of version 1.3 (not that I count on this).

Richard

On 9/2/2014 7:05 PM, Salz, Rich wrote:

Right now we have sessions (server-side, possible scalability issues) and tickets (client-side, hard to make work well with PFS).

A poll for this community: is one likely to be more strategic, or are both likely to be important in the near term (say within two years after TLS 1.3 is done).

--

Principal Security Engineer

Akamai Technologies, Cambridge MA

IM: rsalz@jabber.me Twitter: RichSalz



_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--------------040908040400030203080600-- From nobody Tue Sep 2 10:15:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 485E01A0ACA for ; Tue, 2 Sep 2014 10:15:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RPwCy70bMDrY for ; Tue, 2 Sep 2014 10:15:51 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id BE7161A0970 for ; Tue, 2 Sep 2014 10:15:51 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id AF0311656FE; Tue, 2 Sep 2014 17:15:50 +0000 (GMT) Received: from prod-mail-relay09.akamai.com (prod-mail-relay09.akamai.com [172.27.22.68]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 9A13D1656F3; Tue, 2 Sep 2014 17:15:50 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub4.kendall.corp.akamai.com [172.27.105.20]) by prod-mail-relay09.akamai.com (Postfix) with ESMTP id 7896F1E049; Tue, 2 Sep 2014 17:15:50 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.218]) by USMA1EX-CASHUB4.kendall.corp.akamai.com ([172.27.105.20]) with mapi; Tue, 2 Sep 2014 13:15:50 -0400 From: "Salz, Rich" To: "Richard Fussenegger, BSc" , "tls@ietf.org" Date: Tue, 2 Sep 2014 13:15:48 -0400 Thread-Topic: [TLS] tickets or sesssions or both (oh my) Thread-Index: Ac/G0PaoNUIXHKsPQS6c6uFbgl+KxAAAIZaw Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE1B@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <5405F911.7090700@fussenegger.info> In-Reply-To: <5405F911.7090700@fussenegger.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE1BUSMBX1msgcorp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/oB5nq5RH2J7V8bCP3usrGrMJMFE Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 02 Sep 2014 17:15:55 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE1BUSMBX1msgcorp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable > May I ask - out of interest - what the problem is with session tickets in= regards to PFS? Or is it just the key rotation thing? Yeah. " just" :) -- Principal Security Engineer Akamai Technologies, Cambridge MA IM: rsalz@jabber.me Twitter: RichSalz --_000_2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE1BUSMBX1msgcorp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= > May I ask — out of interest= — what the problem is with session tickets in regards to PFS? Or is = it just the key rotation thing?

<= /o:p>

Yeah. &#= 8220; just” J

 

--  <= /p>

Principal Security En= gineer

Akamai Technologies, Cambridge MA

IM: <= span style=3D'color:blue'>rsalz@jabber.me Twitter: RichSalz=

= --_000_2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE1BUSMBX1msgcorp_-- From nobody Tue Sep 2 10:24:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6447D1A7021 for ; Tue, 2 Sep 2014 10:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XjMDmmTnBmBS for ; Tue, 2 Sep 2014 10:24:20 -0700 (PDT) Received: from mx208.easyname.com (mx208.easyname.com [212.232.25.164]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3B6141A6FFE for ; Tue, 2 Sep 2014 10:24:19 -0700 (PDT) Received: from 89-26-76-175.goll.dyn.salzburg-online.at ([89.26.76.175] helo=[192.168.0.11]) by mx.easyname.eu with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XOroV-0003VI-IS; Tue, 02 Sep 2014 19:24:17 +0200 Message-ID: <5405FC17.1080905@fussenegger.info> Date: Tue, 02 Sep 2014 19:19:19 +0200 From: "Richard Fussenegger, BSc" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Salz, Rich" , "tls@ietf.org" References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <5405F911.7090700@fussenegger.info> <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE1B@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE1B@USMBX1.msg.corp.akamai.com> Content-Type: multipart/alternative; boundary="------------010304000904040102010900" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PaezJGd6MxIOY6D_0kzle9Ge0Xs Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 02 Sep 2014 17:24:27 -0000 This is a multi-part message in MIME format. --------------010304000904040102010900 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit I can imagine that it's not just a just if you're Akamai, but it's definitely not that hard to solve the key rotation problem if you have a single server. Or if you have shared hosting for multiple servers. I think the technology is very useful for environments that have limited memory and/or storage. Of course default implementations would have to change. Right now e.g. nginx isn't rotation anything and shares sessions and keys among all defined servers. They are blaming OpenSSL for that, but that's just a library and the server should rotate and distribute the keys while each instance has its own library. Isn't early termination a viable solution for bigger networks instead of sharing the keys among many servers like Twitter is doing it? Richard On 9/2/2014 7:15 PM, Salz, Rich wrote: > > > May I ask out of interest what the problem is with session > tickets in regards to PFS? Or is it just the key rotation thing? > > Yeah. just J > > -- > > Principal Security Engineer > > Akamai Technologies, Cambridge MA > > IM: rsalz@jabber.me Twitter: RichSalz > --------------010304000904040102010900 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I can imagine that it's not just a just if you're Akamai, but it's definitely not that hard to solve the key rotation problem if you have a single server. Or if you have shared hosting for multiple servers. I think the technology is very useful for environments that have limited memory and/or storage. Of course default implementations would have to change. Right now e.g. nginx isn't rotation anything and shares sessions and keys among all defined servers. They are blaming OpenSSL for that, but that's just a library and the server should rotate and distribute the keys while each instance has its own library.

Isn't early termination a viable solution for bigger networks instead of sharing the keys among many servers like Twitter is doing it?

Richard

On 9/2/2014 7:15 PM, Salz, Rich wrote:

> May I ask out of interest what the problem is with session tickets in regards to PFS? Or is it just the key rotation thing?

Yeah. just J

--

Principal Security Engineer

Akamai Technologies, Cambridge MA

IM: rsalz@jabber.me Twitter: RichSalz


--------------010304000904040102010900-- From nobody Tue Sep 2 10:26:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D05D1A7021 for ; Tue, 2 Sep 2014 10:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DsaU-NJ6-5-0 for ; Tue, 2 Sep 2014 10:26:06 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B27221A6F61 for ; Tue, 2 Sep 2014 10:26:06 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id BBA592AB2AA; Tue, 2 Sep 2014 17:26:05 +0000 (UTC) Date: Tue, 2 Sep 2014 17:26:05 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140902172605.GH14392@mournblade.imrryr.org> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/i1CwL766EtozABrmU3crUk79CjA Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@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: Tue, 02 Sep 2014 17:26:08 -0000 On Tue, Sep 02, 2014 at 01:05:09PM -0400, Salz, Rich wrote: > Right now we have sessions (server-side, possible scalability > issues) and tickets (client-side, hard to make work well with PFS). > > A poll for this community: is one likely to be more strategic, > or are both likely to be important in the near term (say within > two years after TLS 1.3 is done). My data point: In Postfix SMTP servers, tickets are enabled by default, but a server-side session cache needs to be enabled explicitly (due to the scalability issue you note). (Again in Postfix) There are no problems with respect to PFS. Session ticket encryption keys are rotated hourly. Session ticket encryption keys are less exposed than cached session master keys (which are written to the session cache database and deleted from there when the session expires and is garbage collected), because session ticket encryption keys do only live in memory. >From my perspective, any weakening of PFS through the use of session tickets is an application architecture artifact, and not an intrinsic defect of tickets. In some applications tickets are less likely to lead to future exposure of keys than server-side session caches. -- Viktor. From nobody Tue Sep 2 11:03:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56CEC1A03D1 for ; Tue, 2 Sep 2014 11:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.867 X-Spam-Level: X-Spam-Status: No, score=-4.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zijXhsWUaR4P for ; Tue, 2 Sep 2014 11:03:43 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id B4FD71A029F for ; Tue, 2 Sep 2014 11:03:43 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s82I3c6f018583; Tue, 2 Sep 2014 14:03:42 -0400 Content-Type: text/plain; charset="iso-8859-1" MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: "Blumenthal, Uri - 0558 - MITLL" In-Reply-To: <029F49F3-B25B-4B06-A694-88F4224356D0@vpnc.org> Date: Tue, 2 Sep 2014 14:03:24 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <26A5F1E4-761A-414C-89FF-0DD08C3C2D99@ll.mit.edu> References: <65D2FD736B6B2B48B2EAD2BD189DC9CC20BBCF@LLE2K10-MBX01.mitll.ad.local> <029F49F3-B25B-4B06-A694-88F4224356D0@vpnc.org> To: Paul Hoffman X-Mailer: Apple Mail (2.1510) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.27, 0.0.0000 definitions=2014-09-02_07:2014-09-02,2014-09-02,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-1402240000 definitions=main-1409020197 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/y3x56ooMXDfltdAmX42a-l3eTIY Cc: "tls@ietf.org" Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 02 Sep 2014 18:03:45 -0000 On Sep 2, 2014, at 11:58 , Paul Hoffman wrote: > That's not at all an "obvious" example for TLS. I knew I'd bait somebody at least. :-) > What could TLS integrity-only protection buy you in that environment? Traffic visibility for those who are responsible for monitoring, and = integrity protection who want tamper detection but don't require (or = aren't allowed to have) confidentiality. > It is only of value if you can act when the integrity is broken, such = as modified packets. Of corse. AFAIK, TLS would just reject modified packets, won't it?=20 > And yet there are essentially no systems where there is an = administrative interface for TLS that says what to do when the integrity = is broken. And yet there are *plenty* of examples of how to do this with = integrity-only IPsec. My personal opinion is that VPN should be built upon IPsec, not TLS. = Unfortunately, the market does not seem to agree. I see (in my = environment) the need to (sometimes) run a VPN across the corporate = boundary. One implication is - IT on both sides want to examine the = traffic, at the same time ensuring nothing is injected into the stream.=20= > I support NULL encryption being a MUST NOT as long as IPsec supports = null encryption for the use cases that people want to force on TLS. I am all for IPsec. Unfortunately, most of the VPNs we're dealing with = now are TLS-based (and my dislike cannot alter this fact). Besides, I don't think it is wise to limit usability of a tool because = there may be another tool that could do it. From nobody Tue Sep 2 12:46:07 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36E671A8862 for ; Tue, 2 Sep 2014 12:46:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ZUTLUPlMd3L for ; Tue, 2 Sep 2014 12:46:03 -0700 (PDT) Received: from smtp.serverkommune.de (serverkommune.de [176.9.61.43]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6429C1A8877 for ; Tue, 2 Sep 2014 12:45:55 -0700 (PDT) Received: by smtp.serverkommune.de (Postfix, from userid 5001) id 97FD38027B; Tue, 2 Sep 2014 21:45:52 +0200 (CEST) Received: from [192.168.178.34] (ex6.serverkommune.de [176.9.61.43]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.serverkommune.de (Postfix) with ESMTPSA id AC13E80232 for ; Tue, 2 Sep 2014 21:45:51 +0200 (CEST) Message-ID: <54061E6F.6040204@net.in.tum.de> Date: Tue, 02 Sep 2014 21:45:51 +0200 From: Ralph Holz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: tls@ietf.org References: <65D2FD736B6B2B48B2EAD2BD189DC9CC20BBCF@LLE2K10-MBX01.mitll.ad.local> <029F49F3-B25B-4B06-A694-88F4224356D0@vpnc.org> <26A5F1E4-761A-414C-89FF-0DD08C3C2D99@ll.mit.edu> In-Reply-To: <26A5F1E4-761A-414C-89FF-0DD08C3C2D99@ll.mit.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.98.1 at ex6 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yeTbG6auZl7UYCUMh66UazQMvTU Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 02 Sep 2014 19:46:05 -0000 Hi, >> What could TLS integrity-only protection buy you in that >> environment? > > Traffic visibility for those who are responsible for monitoring, and > integrity protection who want tamper detection but don't require (or > aren't allowed to have) confidentiality. Is this a real use case? I.e., do you really know companies/organisations that do this? > My personal opinion is that VPN should be built upon IPsec, not TLS. > Unfortunately, the market does not seem to agree. I see (in my > environment) the need to (sometimes) run a VPN across the corporate > boundary. One implication is - IT on both sides want to examine the > traffic, at the same time ensuring nothing is injected into the > stream. Why can't they simply monitor on the two gateways? Or are you suggesting a setup where an organisation fowards internal traffic via a tunnel, only integrity-protected? Why that? > I am all for IPsec. Unfortunately, most of the VPNs we're dealing > with now are TLS-based (and my dislike cannot alter this fact). I'd disagree with that, but that's another topic. :) Ralph -- Ralph Holz I8 - Network Architectures and Services Technische Universitt Mnchen http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18043 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF From nobody Tue Sep 2 12:47:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 443451A887C for ; Tue, 2 Sep 2014 12:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id efrDMkp4toqh for ; Tue, 2 Sep 2014 12:47:11 -0700 (PDT) Received: from smtp.serverkommune.de (serverkommune.de [176.9.61.43]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 513CF1A8876 for ; Tue, 2 Sep 2014 12:47:11 -0700 (PDT) Received: by smtp.serverkommune.de (Postfix, from userid 5001) id F1B9B802B1; Tue, 2 Sep 2014 21:47:09 +0200 (CEST) Received: from [192.168.178.34] (ex6.serverkommune.de [176.9.61.43]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.serverkommune.de (Postfix) with ESMTPSA id 2A29B80256 for ; Tue, 2 Sep 2014 21:47:09 +0200 (CEST) Message-ID: <54061EBC.5080909@net.in.tum.de> Date: Tue, 02 Sep 2014 21:47:08 +0200 From: Ralph Holz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: tls@ietf.org References: <54048985.1020005@net.in.tum.de> <20140902152308.GB14392@mournblade.imrryr.org> In-Reply-To: <20140902152308.GB14392@mournblade.imrryr.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.98.1 at ex6 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ljr6u5PTc6sJCsJaHGAos1Yu5Fo Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 02 Sep 2014 19:47:12 -0000 Hi, > Postfix supports authenticated NULL ciphers for communication > between an MTA and local (127.0.0.1 or ::1) LMTP server. Encrypting > local IPC is just a waste of CPU. Yes, this is a specialized use-case. > > This can also be useful for access-controlled hand-off between > reverse HTTP proxies, and web applications that support client > certificates. These are sometimes used to implement GSSAPI SPNEGO > support in front of application that don't support GSSAPI. The > application is configured to listen on 127.0.0.1, but is then > vulnerable to impersonation attacks from anything running on the > host. With authenticated NULL ciphers, the connection can be > restricted to just the front-end reverse proxy. Both seem to be real corner cases - wouldn't they be covered just as well with encryption prescribed? Ralph -- Ralph Holz I8 - Network Architectures and Services Technische Universitt Mnchen http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18043 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF From nobody Tue Sep 2 12:51:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF451A884D for ; Tue, 2 Sep 2014 12:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dYd6rIVSfQGc for ; Tue, 2 Sep 2014 12:51:49 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 874911A8862 for ; Tue, 2 Sep 2014 12:51:49 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 8E29B2AB2C4; Tue, 2 Sep 2014 19:51:48 +0000 (UTC) Date: Tue, 2 Sep 2014 19:51:48 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140902195148.GR14392@mournblade.imrryr.org> References: <54048985.1020005@net.in.tum.de> <20140902152308.GB14392@mournblade.imrryr.org> <54061EBC.5080909@net.in.tum.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54061EBC.5080909@net.in.tum.de> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/w-mAWb2Tza60JhZlAVwsitlesGw Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@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: Tue, 02 Sep 2014 19:51:51 -0000 On Tue, Sep 02, 2014 at 09:47:08PM +0200, Ralph Holz wrote: > > Postfix supports authenticated NULL ciphers for communication > > between an MTA and local (127.0.0.1 or ::1) LMTP server. Encrypting > > local IPC is just a waste of CPU. Yes, this is a specialized use-case. > > > > This can also be useful for access-controlled hand-off between > > reverse HTTP proxies, and web applications that support client > > certificates. These are sometimes used to implement GSSAPI SPNEGO > > support in front of application that don't support GSSAPI. The > > application is configured to listen on 127.0.0.1, but is then > > vulnerable to impersonation attacks from anything running on the > > host. With authenticated NULL ciphers, the connection can be > > restricted to just the front-end reverse proxy. > > Both seem to be real corner cases - wouldn't they be covered just as > well with encryption prescribed? Yes, these are "corner cases". A sufficiently broadly applicable tool has a lot of corners. While I agree that NULL ciphers should not be enabled *by default*, making NULL ciphers a "MUST NOT" seems rather too strong. Why burn limited CPU cycles doing nothing useful (encrypting local IPC). -- Viktor. From nobody Tue Sep 2 13:02:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 943341A889C for ; Tue, 2 Sep 2014 13:02:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BJcXg41lQ639 for ; Tue, 2 Sep 2014 13:02:02 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 021471A8896 for ; Tue, 2 Sep 2014 13:02:02 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 356372AB2C4; Tue, 2 Sep 2014 20:02:00 +0000 (UTC) Date: Tue, 2 Sep 2014 20:02:00 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140902200200.GS14392@mournblade.imrryr.org> References: <54048985.1020005@net.in.tum.de> <20140902152308.GB14392@mournblade.imrryr.org> <54061EBC.5080909@net.in.tum.de> <20140902195148.GR14392@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140902195148.GR14392@mournblade.imrryr.org> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-17qji6v2Q6sjIzfvN1eriVoYuY Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@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: Tue, 02 Sep 2014 20:02:03 -0000 On Tue, Sep 02, 2014 at 07:51:48PM +0000, Viktor Dukhovni wrote: > > > Postfix supports authenticated NULL ciphers for communication > > > between an MTA and local (127.0.0.1 or ::1) LMTP server. Encrypting > > > local IPC is just a waste of CPU. Yes, this is a specialized use-case. > > > > > > This can also be useful for access-controlled hand-off between > > > reverse HTTP proxies, and web applications that support client > > > certificates. These are sometimes used to implement GSSAPI SPNEGO > > > support in front of application that don't support GSSAPI. The > > > application is configured to listen on 127.0.0.1, but is then > > > vulnerable to impersonation attacks from anything running on the > > > host. With authenticated NULL ciphers, the connection can be > > > restricted to just the front-end reverse proxy. > > > > Both seem to be real corner cases - wouldn't they be covered just as > > well with encryption prescribed? > > Yes, these are "corner cases". A sufficiently broadly applicable > tool has a lot of corners. > > While I agree that NULL ciphers should not be enabled *by default*, > making NULL ciphers a "MUST NOT" seems rather too strong. Why burn > limited CPU cycles doing nothing useful (encrypting local IPC). I forgot to mention one thing. In Postfix for any given destination either *no* NULL ciphers are enabled, or *only* NULL ciphers are enabled. I have no objection to language that prohibits NULL ciphers when any non-NULL ciphers are enabled. -- Viktor. From nobody Tue Sep 2 14:01:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338A41A88C8 for ; Tue, 2 Sep 2014 14:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.267 X-Spam-Level: X-Spam-Status: No, score=-2.267 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NgUJasSUZKtL for ; Tue, 2 Sep 2014 14:01:27 -0700 (PDT) Received: from mx0b-0016f401.pphosted.com (mx0b-0016f401.pphosted.com [67.231.156.173]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A83FA1A06CE for ; Tue, 2 Sep 2014 14:01:26 -0700 (PDT) Received: from pps.filterd (m0045851.ppops.net [127.0.0.1]) by mx0b-0016f401.pphosted.com (8.14.5/8.14.5) with SMTP id s82KtxDp026543 for ; Tue, 2 Sep 2014 14:01:25 -0700 Received: from sc-owa03.marvell.com ([199.233.58.149]) by mx0b-0016f401.pphosted.com with ESMTP id 1p59ty1rnx-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 02 Sep 2014 14:01:25 -0700 Received: from SC-vEXCH2.marvell.com ([10.93.76.134]) by SC-OWA03.marvell.com ([fe80::5efe:10.93.76.24%18]) with mapi; Tue, 2 Sep 2014 14:01:23 -0700 From: Paul Lambert To: "tls@ietf.org" Date: Tue, 2 Sep 2014 14:01:22 -0700 Thread-Topic: [TLS] NULL cipher to become a MUST NOT in UTA BCP Thread-Index: Ac/G51vdlW9DMG4nS2C6fKMGKfsIqQACVxzw Message-ID: <7BAC95F5A7E67643AAFB2C31BEE662D01EE567EC7D@SC-VEXCH2.marvell.com> References: <54048985.1020005@net.in.tum.de> <20140902152308.GB14392@mournblade.imrryr.org> <54061EBC.5080909@net.in.tum.de> <20140902195148.GR14392@mournblade.imrryr.org> In-Reply-To: <20140902195148.GR14392@mournblade.imrryr.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.27, 0.0.0000 definitions=2014-09-02_07:2014-09-02,2014-09-02,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1409020222 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IVfKcQ_RuB4UIZ4Fw4i9GJY3MIU Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 02 Sep 2014 21:01:28 -0000 ]-----Original Message----- ]From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Viktor Dukhovni ]Sent: Tuesday, September 02, 2014 12:52 PM ]To: tls@ietf.org ]Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP ] ]On Tue, Sep 02, 2014 at 09:47:08PM +0200, Ralph Holz wrote: ] ]> > Postfix supports authenticated NULL ciphers for communication ]> > between an MTA and local (127.0.0.1 or ::1) LMTP server. Encrypting ]> > local IPC is just a waste of CPU. Yes, this is a specialized use- ]case. ]> > ]> > This can also be useful for access-controlled hand-off between ]> > reverse HTTP proxies, and web applications that support client ]> > certificates. These are sometimes used to implement GSSAPI SPNEGO ]> > support in front of application that don't support GSSAPI. The ]> > application is configured to listen on 127.0.0.1, but is then ]> > vulnerable to impersonation attacks from anything running on the ]> > host. With authenticated NULL ciphers, the connection can be ]> > restricted to just the front-end reverse proxy. ]> ]> Both seem to be real corner cases - wouldn't they be covered just as ]> well with encryption prescribed? ] ]Yes, these are "corner cases". A sufficiently broadly applicable tool ]has a lot of corners. ] ]While I agree that NULL ciphers should not be enabled *by default*, ]making NULL ciphers a "MUST NOT" seems rather too strong. Why burn ]limited CPU cycles doing nothing useful (encrypting local IPC). I disagree, and support the draft as written. =20 'MUST NOT' is the appropriate recommendation for NULL ciphers. Paul ] ]-- ] Viktor. ] ]_______________________________________________ ]TLS mailing list ]TLS@ietf.org ]https://www.ietf.org/mailman/listinfo/tls From nobody Tue Sep 2 15:06:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71C41A0AE3 for ; Tue, 2 Sep 2014 15:06:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.596 X-Spam-Level: X-Spam-Status: No, score=-1.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fjMJwbiti11T for ; Tue, 2 Sep 2014 15:06:26 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 674451A0720 for ; Tue, 2 Sep 2014 15:06:26 -0700 (PDT) Received: from mail-yh0-f43.google.com (mail-yh0-f43.google.com [209.85.213.43]) by mrelayeu.kundenserver.de (node=mreue001) with ESMTP (Nemesis) id 0MeGZ4-1XlWU206ww-00Py0n; Wed, 03 Sep 2014 00:06:24 +0200 Received: by mail-yh0-f43.google.com with SMTP id f73so4749386yha.2 for ; Tue, 02 Sep 2014 15:06:22 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.129.205 with SMTP id h53mr58658379yhi.74.1409695582869; Tue, 02 Sep 2014 15:06:22 -0700 (PDT) Received: by 10.170.129.17 with HTTP; Tue, 2 Sep 2014 15:06:22 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> Date: Wed, 3 Sep 2014 00:06:22 +0200 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=20cf301afd977560e805021c54d1 X-Provags-ID: V02:K0:htAJSctYN+4IjgseE0+fgFrrKLJtTO7d7UWtGK7K5dt KLhaYnI8+NKudnR+4dcESAfXMquqqhTe7dvtAI2fdwsVJxvIlO SPb9e615rFdXVTlbE6k/e0PXslfgnLkAg0RXFXzjVKvqTq5EQD ISOj1FTNRpOa0LF6JJXRrricm2gUr3rA4gP1PkGRq2MraQ8k0H LXS6b+Kmvu3bk3057pjuy+rCuMoIbUGJx/eVDC1TjV5zkm5V4o bM7LBW9/Olsddxbp56JE9quBJaZJgH8l/jADhZphuDDl7b5Yf1 gqU3ZXw8vSdta67UXRNFs9rQ+H9WV3P0tDJ32aRA/5bQAn2iCa A6PPUvTmrMDdPWtTGEBKIct5cQV2btFSLEKfPfuV1asYlJ0m4g mftMAFrN8y9FwisI0oLnU+poMl6S7TTFvgPsxCfj7H9qgtB6lT 8adMR X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/MSyFvSMHDyAol9XJ6T64TF9lwo4 Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 02 Sep 2014 22:06:28 -0000 --20cf301afd977560e805021c54d1 Content-Type: text/plain; charset=UTF-8 Salz, Rich : > Right now we have sessions (server-side, possible scalability issues) and > tickets (client-side, hard to make work well with PFS). > > > > A poll for this community: is one likely to be more strategic, or are both > likely to be important in the near term (say within two years after TLS > 1.3 is done). > As far as the actual network protocol is concerned, isn't the main difference between session IDs and session tickets just that the session ID has a maximum length of 32 bytes while a session ticket can be much longer (65535 bytes) and comes with a lifetime hint? Other than that, the main difference is in server details that are opaque to the client. If your "encryption algorithm" for session tickets is to allocate a random 32-byte ciphertext and define its decryption accordingly going forward, you're back to session IDs. Similarly, you could fold session tickets into session IDs by specifying ServerHello.session_id differently for a new protocol version so that it can hold more information (however since ClientHello.session_id needs to remain backwards-compatible, clients would still have to use the TLS extension, so that's probably not a good idea). The other main difference is that session IDs are part of the main spec, while session tickets are an extension. This means that for maximum benefit, you'll always need to support both because the other party may not. So maybe what TLS 1.3 should be doing is merge part of the TLS session ticket spec into the main document, using the traditional session ID fields for legacy cases only (i.e., ClientHello.session_id would be present for backwards compatibility but always empty unless you're trying to resume a <= TLS 1.2 session), always using a session-ticket compatible on-the-wire format with TLS 1.3 sessions. Servers could use this for tickets or for short IDs based on their own preference. The question that we're at then is, Does it make sense to complicate the protocol just to allow clients to specify whether they prefer short (= "session ID") or long (= "session ticket") session identifiers? (If so, why don't they just send a maximum length so that the server can act accordingly -- e.g., omit a session identifier that the client would be expected to ignore?) Bodo --20cf301afd977560e805021c54d1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Salz= , Rich <rsalz@akamai.com>:

Right now we have sessions (server-side, possible scalability issues) a= nd tickets (client-side, hard to make work well with PFS).

=C2=A0

A poll for this community: i= s one likely to be more strategic, or are both likely to be important in th= e near term=C2=A0 (say within two years after TLS 1.3 is done).


As far as the actual network protocol is concerned, isn= 't the main difference between session IDs and session tickets just tha= t the session ID has a maximum length of 32 bytes while a session ticket ca= n be much longer (65535 bytes) and comes with a lifetime hint? Other than t= hat, the main difference is in server details that are opaque to the client= . If your "encryption algorithm" for session tickets is to alloca= te a random 32-byte ciphertext and define its decryption accordingly going = forward, you're back to session IDs. Similarly, you could fold session = tickets into session IDs by specifying ServerHello.session_id differently f= or a new protocol version so that it can hold more information (however sin= ce ClientHello.session_id needs to remain backwards-compatible, clients wou= ld still have to use the TLS extension, so that's probably not a good i= dea).

The other main difference is that session IDs are part = of the main spec, while session tickets are an extension. This means that f= or maximum benefit, you'll always need to support both because the othe= r party may not. So maybe what TLS 1.3 should be doing is merge part of the= TLS session ticket spec into the main document, using the traditional sess= ion ID fields for legacy cases only (i.e., ClientHello.session_id would be = present for backwards compatibility but always empty unless you're tryi= ng to resume a <=3D TLS 1.2 session), always using a session-ticket comp= atible on-the-wire format with TLS 1.3 sessions. Servers could use this for= tickets or for short IDs based on their own preference.

The question that we're at then is, Does it make se= nse to complicate the protocol just to allow clients to specify whether the= y prefer short (=3D "session ID") or long (=3D "session tick= et") session identifiers? =C2=A0(If so, why don't they just send a= maximum length so that the server can act accordingly -- e.g., omit a sess= ion identifier that the client would be expected to ignore?)

Bodo
--20cf301afd977560e805021c54d1-- From nobody Tue Sep 2 15:11:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D65E01A0720 for ; Tue, 2 Sep 2014 15:11:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.031 X-Spam-Level: ** X-Spam-Status: No, score=2.031 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_IMAGE_ONLY_24=1.618, HTML_MESSAGE=0.001, HTML_OBFUSCATE_20_30=1.999, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, T_REMOTE_IMAGE=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UoU_0qrH2rEw for ; Tue, 2 Sep 2014 15:11:19 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEAEF1A071F for ; Tue, 2 Sep 2014 15:11:18 -0700 (PDT) Received: from mail-yk0-f176.google.com (mail-yk0-f176.google.com [209.85.160.176]) by mrelayeu.kundenserver.de (node=mreue101) with ESMTP (Nemesis) id 0M6mZQ-1YJ7qq2wzs-00wWTB; Wed, 03 Sep 2014 00:11:17 +0200 Received: by mail-yk0-f176.google.com with SMTP id 19so4491575ykq.21 for ; Tue, 02 Sep 2014 15:11:15 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.223.36 with SMTP id u34mr54715740yhp.79.1409695875503; Tue, 02 Sep 2014 15:11:15 -0700 (PDT) Received: by 10.170.129.17 with HTTP; Tue, 2 Sep 2014 15:11:15 -0700 (PDT) In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01EE567EC7D@SC-VEXCH2.marvell.com> References: <54048985.1020005@net.in.tum.de> <20140902152308.GB14392@mournblade.imrryr.org> <54061EBC.5080909@net.in.tum.de> <20140902195148.GR14392@mournblade.imrryr.org> <7BAC95F5A7E67643AAFB2C31BEE662D01EE567EC7D@SC-VEXCH2.marvell.com> Date: Wed, 3 Sep 2014 00:11:15 +0200 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=001a11c20234e6a17805021c6528 X-Provags-ID: V02:K0:PaOLvkhTd0hZK0dusDZA70RBSf9QzeqX2PsHQTbzx6K gcuHHRIA0I9CJDLqrJ+wy3NWNbmBcUzyF6AwXytpkURjqBzr1i zqNFmWmNaKvpaGlyvWUsSJXdCruxITVu4fbXbwHa10x/rtQu+v hfiqKJi0x9QnztqzvZU5cW3TRaJyUGTYV+2koK7cFBlWjsxDtq kRJ2AzsDgCOGep/1AtU2Co6OzmxSbB7SCbg9q1nAgDYOhI7Mod 6ZdxyedU53M3CUXZ6bs/2A2y7/A2DT//scUIrrywLRKLY5U60p jNRF2Imuhy1AV6ywfNIIOQEcwGHB+fVsyKRBuQPXj9/FR/U+Et V/bdTKY1H3qAJ6/ZcVs5Ak17rD/x7IZpugGaKL8N0Q9JHv9owJ 8lYFUqTsyybkgsCwX5w5nIkr8Y51aExz2efs5QYECx41+rd9YG okQPh X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IB_tQRQKyQ5jIARQ0_5ACTNJBr4 Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 02 Sep 2014 22:11:26 -0000 --001a11c20234e6a17805021c6528 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Also note =E2=80=8Bthat the current plan for TLS 1.3 is to get rid of NULL = encryption entirely anyway ( http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-tls-tls13-02.txt), apart fr= om the initial TLS_NULL_WITH_NULL_NULL cipher suite, which exists only for formal reasons and can't be negotiated. (I don't know why TLS even has a c= ode point allocated for it.) Nostalgia seems misplaced here. In any case, these are supposed to be recommendations for secure use of TLS and DTLS. For insecure use, you're still free to do whatever you like. If protocol implementations meant for secure use don't make that easy, that's a feature and not a bug. Bodo --001a11c20234e6a17805021c6528 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Also note=C2=A0=E2=80=8Bthat the current plan for TLS 1.3 is=C2=A0= to=C2=A0get = rid of=C2=A0NULL=C2=A0encryption entirely anyway (http://tools.ietf.org/rf= cdiff?url2=3Ddraft-ietf-tls-tls13-02.txt), apart from the initial=C2=A0TLS_NULL_WITH_N= ULL_NULL=C2=A0cipher=C2=A0suite, which exists only for formal reasons and can't b= e negotiated. =C2=A0(I don't know why TLS even has=C2=A0a=C2=A0code point al= located for it.) =C2=A0Nostalgia seems misplaced here.

In=C2=A0any case, these are supposed=C2=A0to=C2=A0be recommendations for secure use of TLS and DTLS. =C2=A0F= or insecure use, you're still free=C2=A0to=C2= =A0do whatever you like. =C2=A0If protocol implementations meant for secure= use don't make that easy, that's=C2=A0a=C2= =A0feature and=C2=A0not=C2=A0a=C2=A0bug.=C2=A0
Bodo

--001a11c20234e6a17805021c6528-- From nobody Tue Sep 2 16:26:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 892D41A88FF for ; Tue, 2 Sep 2014 16:26:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.867 X-Spam-Level: X-Spam-Status: No, score=-4.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWgBGZj2YiCg for ; Tue, 2 Sep 2014 16:26:34 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id A97C11A88F8 for ; Tue, 2 Sep 2014 16:26:34 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s82NQXij022011; Tue, 2 Sep 2014 19:26:33 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: "'holz@net.in.tum.de'" , "'tls@ietf.org'" Thread-Topic: [TLS] NULL cipher to become a MUST NOT in UTA BCP Thread-Index: AQHPxfjrFyzs0NTAq0uDUGuetkiK35vt9W44gABPIQCAACLtAIAAHKCA///6m5s= Date: Tue, 2 Sep 2014 23:26:33 +0000 Message-ID: <65D2FD736B6B2B48B2EAD2BD189DC9CC20CE23@LLE2K10-MBX01.mitll.ad.local> In-Reply-To: <54061E6F.6040204@net.in.tum.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.34.14.22] 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.12.52, 1.0.27, 0.0.0000 definitions=2014-09-03_01:2014-09-02,2014-09-02,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-1402240000 definitions=main-1409020243 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KNv56l8_H__2H1QNlVjC_j-q5Hw Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 02 Sep 2014 23:26:36 -0000 Yes I really do know such organizations. You can call it "first hand experi= ence". Why not "MiTM" - aka "cracked SSL"? My personal take: I prefer my security = guarantees - whatever they are - to be end-to-end. Especially integrity/aut= henticity. And interrupting the flow at the gateway breaks this. There coul= d be other reasons, which I may not know or think of (not working closely w= ith IT). (Also, I hope you didn't miss the "not allowed" part.) I add that I violently disagree with Paul L., and insist that while NULL ci= phers should not be enabled by default - they "must not" be "MUST NOT"-ed. -- 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, Lexington, MA 02420-9185 =20 Web: http://www.ll.mit.edu/CST/ MIT LL Root CA: ----- Original Message ----- From: Ralph Holz [mailto:holz@net.in.tum.de] Sent: Tuesday, September 02, 2014 03:45 PM=0A= To: tls@ietf.org Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP Hi, >> What could TLS integrity-only protection buy you in that >> environment? >=20 > Traffic visibility for those who are responsible for monitoring, and > integrity protection who want tamper detection but don't require (or > aren't allowed to have) confidentiality. Is this a real use case? I.e., do you really know companies/organisations that do this? > My personal opinion is that VPN should be built upon IPsec, not TLS. > Unfortunately, the market does not seem to agree. I see (in my > environment) the need to (sometimes) run a VPN across the corporate > boundary. One implication is - IT on both sides want to examine the > traffic, at the same time ensuring nothing is injected into the > stream. Why can't they simply monitor on the two gateways? Or are you suggesting a setup where an organisation fowards internal traffic via a tunnel, only integrity-protected? Why that? > I am all for IPsec. Unfortunately, most of the VPNs we're dealing > with now are TLS-based (and my dislike cannot alter this fact). I'd disagree with that, but that's another topic. :) Ralph --=20 Ralph Holz I8 - Network Architectures and Services Technische Universit=E4t M=FCnchen http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18043 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Tue Sep 2 16:29:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 723BC1A8903 for ; Tue, 2 Sep 2014 16:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WSOf6QOoCQeL for ; Tue, 2 Sep 2014 16:29:07 -0700 (PDT) Received: from mx202.easyname.com (mx202.easyname.com [212.232.28.123]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 348C21A8900 for ; Tue, 2 Sep 2014 16:29:07 -0700 (PDT) Received: from 89-26-76-175.goll.dyn.salzburg-online.at ([89.26.76.175] helo=[192.168.0.11]) by mx.easyname.eu with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XOxVW-0006fp-NB for tls@ietf.org; Wed, 03 Sep 2014 01:29:05 +0200 Message-ID: <54065198.7030802@fussenegger.info> Date: Wed, 03 Sep 2014 01:24:08 +0200 From: "Richard Fussenegger, BSc" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: tls@ietf.org References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060602020806010105040904" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qr4Ioy9scnjH6w17ZfceJ2SZKzs Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 02 Sep 2014 23:29:10 -0000 This is a multi-part message in MIME format. --------------060602020806010105040904 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit I think it would be good to merge the tickets into the specs because in a long term the ticket approach makes much more sense. Clients are gaining more and more storage and maintaining a session cache for all clients is a huge burden for the servers. Especially if you're running a huge server network. As you all agreed with me, the fact that current web server implementations of server tickets are broken in regards to rotation is not a problem of the specs. Such a huge server network would have to share the session cache as well. Tickets are e.g. three 48 byte strings (plus maybe a timestamp or identifier) to share, that should be much easier and especially faster and less memory intensive. On a last note, merging the tickets into the spec would also force browser vendors that are currently not supporting them to include support in the future (the major browsers are already offering support). Maybe it would be possible to remove sessions with the next incarnation of the specs entirely and not only simplify them again but also make something like a "maximum length" unnecessary. Tickets would have to be marked as successor of sessions. Honestly, I only see benefits from using tickets instead of sessions. Especially with the advent of HTTP/2 where it won't be as problematic to transfer a few bytes as it is with HTTP/1. Richard On 9/3/2014 12:06 AM, Bodo Moeller wrote: > Salz, Rich >: > > Right now we have sessions (server-side, possible scalability > issues) and tickets (client-side, hard to make work well with PFS). > > A poll for this community: is one likely to be more strategic, or > are both likely to be important in the near term (say within two > years after TLS 1.3 is done). > > > As far as the actual network protocol is concerned, isn't the main > difference between session IDs and session tickets just that the > session ID has a maximum length of 32 bytes while a session ticket can > be much longer (65535 bytes) and comes with a lifetime hint? Other > than that, the main difference is in server details that are opaque to > the client. If your "encryption algorithm" for session tickets is to > allocate a random 32-byte ciphertext and define its decryption > accordingly going forward, you're back to session IDs. Similarly, you > could fold session tickets into session IDs by specifying > ServerHello.session_id differently for a new protocol version so that > it can hold more information (however since ClientHello.session_id > needs to remain backwards-compatible, clients would still have to use > the TLS extension, so that's probably not a good idea). > > The other main difference is that session IDs are part of the main > spec, while session tickets are an extension. This means that for > maximum benefit, you'll always need to support both because the other > party may not. So maybe what TLS 1.3 should be doing is merge part of > the TLS session ticket spec into the main document, using the > traditional session ID fields for legacy cases only (i.e., > ClientHello.session_id would be present for backwards compatibility > but always empty unless you're trying to resume a <= TLS 1.2 session), > always using a session-ticket compatible on-the-wire format with TLS > 1.3 sessions. Servers could use this for tickets or for short IDs > based on their own preference. > > The question that we're at then is, Does it make sense to complicate > the protocol just to allow clients to specify whether they prefer > short (= "session ID") or long (= "session ticket") session > identifiers? (If so, why don't they just send a maximum length so > that the server can act accordingly -- e.g., omit a session identifier > that the client would be expected to ignore?) > > Bodo > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --------------060602020806010105040904 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I think it would be good to merge the tickets into the specs because in a long term the ticket approach makes much more sense. Clients are gaining more and more storage and maintaining a session cache for all clients is a huge burden for the servers. Especially if you're running a huge server network. As you all agreed with me, the fact that current web server implementations of server tickets are broken in regards to rotation is not a problem of the specs. Such a huge server network would have to share the session cache as well. Tickets are e.g. three 48 byte strings (plus maybe a timestamp or identifier) to share, that should be much easier and especially faster and less memory intensive.

On a last note, merging the tickets into the spec would also force browser vendors that are currently not supporting them to include support in the future (the major browsers are already offering support). Maybe it would be possible to remove sessions with the next incarnation of the specs entirely and not only simplify them again but also make something like a "maximum length" unnecessary. Tickets would have to be marked as successor of sessions. Honestly, I only see benefits from using tickets instead of sessions. Especially with the advent of HTTP/2 where it won't be as problematic to transfer a few bytes as it is with HTTP/1.

Richard
On 9/3/2014 12:06 AM, Bodo Moeller wrote:
Salz, Rich <rsalz@akamai.com>:

Right now we have sessions (server-side, possible scalability issues) and tickets (client-side, hard to make work well with PFS).

A poll for this community: is one likely to be more strategic, or are both likely to be important in the near term (say within two years after TLS 1.3 is done).


As far as the actual network protocol is concerned, isn't the main difference between session IDs and session tickets just that the session ID has a maximum length of 32 bytes while a session ticket can be much longer (65535 bytes) and comes with a lifetime hint? Other than that, the main difference is in server details that are opaque to the client. If your "encryption algorithm" for session tickets is to allocate a random 32-byte ciphertext and define its decryption accordingly going forward, you're back to session IDs. Similarly, you could fold session tickets into session IDs by specifying ServerHello.session_id differently for a new protocol version so that it can hold more information (however since ClientHello.session_id needs to remain backwards-compatible, clients would still have to use the TLS extension, so that's probably not a good idea).

The other main difference is that session IDs are part of the main spec, while session tickets are an extension. This means that for maximum benefit, you'll always need to support both because the other party may not. So maybe what TLS 1.3 should be doing is merge part of the TLS session ticket spec into the main document, using the traditional session ID fields for legacy cases only (i.e., ClientHello.session_id would be present for backwards compatibility but always empty unless you're trying to resume a <= TLS 1.2 session), always using a session-ticket compatible on-the-wire format with TLS 1.3 sessions. Servers could use this for tickets or for short IDs based on their own preference.

The question that we're at then is, Does it make sense to complicate the protocol just to allow clients to specify whether they prefer short (= "session ID") or long (= "session ticket") session identifiers? (If so, why don't they just send a maximum length so that the server can act accordingly -- e.g., omit a session identifier that the client would be expected to ignore?)

Bodo


_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

--------------060602020806010105040904-- From nobody Tue Sep 2 16:44:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 447F11A8904 for ; Tue, 2 Sep 2014 16:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6DEojHFekpx1 for ; Tue, 2 Sep 2014 16:44:07 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3AF1A8900 for ; Tue, 2 Sep 2014 16:44:07 -0700 (PDT) Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 6F9E231805D for ; Tue, 2 Sep 2014 16:44:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=F/BFjJZKj38+nJtGFEQAVsweUHU=; b=YI0c706qZMi zmrCxbpuYz+J/9ZH59HJ2kYkoWbg5E3cqbuJj0SjmsaH2WQvlfE03jA21M2Cwp3Q ZozXtyXoaVCPO55UMNNo9vaHZpifgNAQI2zT3IAsYhC0gx/Bq5WANBP2nAacL90O lqTqElUcFqqHB52wWZhUBXL3EVSKAmwM= Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id 2287C31805C for ; Tue, 2 Sep 2014 16:44:06 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id n3so15240364wiv.5 for ; Tue, 02 Sep 2014 16:44:05 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.13.195 with SMTP id j3mr31138941wic.70.1409701445741; Tue, 02 Sep 2014 16:44:05 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Tue, 2 Sep 2014 16:44:05 -0700 (PDT) In-Reply-To: <65D2FD736B6B2B48B2EAD2BD189DC9CC20CE23@LLE2K10-MBX01.mitll.ad.local> References: <54061E6F.6040204@net.in.tum.de> <65D2FD736B6B2B48B2EAD2BD189DC9CC20CE23@LLE2K10-MBX01.mitll.ad.local> Date: Tue, 2 Sep 2014 18:44:05 -0500 Message-ID: From: Nico Williams To: "Blumenthal, Uri - 0558 - MITLL" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nd6kAkk0hf0ikNZ10RTI3QSuvJ0 Cc: "tls@ietf.org" Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 02 Sep 2014 23:44:08 -0000 On Tue, Sep 2, 2014 at 6:26 PM, Blumenthal, Uri - 0558 - MITLL wrote: > Yes I really do know such organizations. You can call it "first hand expe= rience". > > Why not "MiTM" - aka "cracked SSL"? My personal take: I prefer my securit= y guarantees - whatever they are - to be end-to-end. Especially integrity/a= uthenticity. And interrupting the flow at the gateway breaks this. There co= uld be other reasons, which I may not know or think of (not working closely= with IT). (Also, I hope you didn't miss the "not allowed" part.) Trusting proxies is likely something we'll have to live with in some environments. Aside from that though I agree with this: > I add that I violently disagree with Paul L., and insist that while NULL = ciphers should not be enabled by default - they "must not" be "MUST NOT"-ed= . We can't really keep people from pointing a loaded gun at their feet and pulling the trigger. We can make them take some extra effort to _load_ the thing, and that's as far as we ought to go. Nico -- From nobody Wed Sep 3 00:55:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5841A0032 for ; Wed, 3 Sep 2014 00:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.57 X-Spam-Level: X-Spam-Status: No, score=-7.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D_KWzR6i_yCt for ; Wed, 3 Sep 2014 00:55:09 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFF521A004B for ; Wed, 3 Sep 2014 00:55:09 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s837t88R032264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 3 Sep 2014 03:55:09 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s837t6gI022513 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 3 Sep 2014 03:55:08 -0400 Message-ID: <1409730906.17577.2.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Paul Lambert Date: Wed, 03 Sep 2014 09:55:06 +0200 In-Reply-To: <7BAC95F5A7E67643AAFB2C31BEE662D01EE567EC7D@SC-VEXCH2.marvell.com> References: <54048985.1020005@net.in.tum.de> <20140902152308.GB14392@mournblade.imrryr.org> <54061EBC.5080909@net.in.tum.de> <20140902195148.GR14392@mournblade.imrryr.org> <7BAC95F5A7E67643AAFB2C31BEE662D01EE567EC7D@SC-VEXCH2.marvell.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Jpm7WETil9SaIWvX7q1nUozNLrw Cc: "tls@ietf.org" Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 07:55:11 -0000 On Tue, 2014-09-02 at 14:01 -0700, Paul Lambert wrote: > ]> Both seem to be real corner cases - wouldn't they be covered just as > ]> well with encryption prescribed? > ] > ]Yes, these are "corner cases". A sufficiently broadly applicable tool > ]has a lot of corners. > ] > ]While I agree that NULL ciphers should not be enabled *by default*, > ]making NULL ciphers a "MUST NOT" seems rather too strong. Why burn > ]limited CPU cycles doing nothing useful (encrypting local IPC). > I disagree, and support the draft as written. > 'MUST NOT' is the appropriate recommendation for NULL ciphers. Putting such strong wording there is a recipe for the document's advices to be ignored. A "MUST NOT" in a document like that will not prevent me from using that ciphersuite if I need it, and most probably neutralize every other positive advice given by that draft. "MUST NOT" must be really "must not", not "some people don't have a use case for it". regards, Nikos From nobody Wed Sep 3 01:34:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 737A61A0794 for ; Wed, 3 Sep 2014 01:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.394 X-Spam-Level: X-Spam-Status: No, score=0.394 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1_2eIyXOPPWH for ; Wed, 3 Sep 2014 01:34:03 -0700 (PDT) Received: from vps2.brainspark.nl (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BCB41A00E9 for ; Wed, 3 Sep 2014 01:34:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=Qlj8Ukf+CuAys5XzowEblE2gZC3LL00YaaYxJU+mN/Y=; b=deN8vTWAeIEp3mXdrKEpvVspzJGWh70uuG42kkzB4BAi9voqkllRfnH0CfHnyzznYrXYGaeLvru8YpJ1xhWdyAY+OqoWVDNM1L/FH7utQ9TfOiN1apNbKATi1dVJxvUJICpioEO9feOpk5vFloWAc+p93Zkf3yHilqdfsZ5R1P8=; Received: from mna75-11-88-161-199-191.fbx.proxad.net ([88.161.199.191] helo=[192.168.0.12]) by vps2.brainspark.nl with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XP60m-0007w8-UF; Wed, 03 Sep 2014 10:33:53 +0200 Message-ID: <5406D275.3010101@polarssl.org> Date: Wed, 03 Sep 2014 10:33:57 +0200 From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Bodo Moeller , "tls@ietf.org" References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.161.199.191 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.brainspark.nl) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GbZwcp7u_xtI71uQ5d5kDdNJ38M Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 08:34:04 -0000 On 03/09/2014 00:06, Bodo Moeller wrote: > So maybe what TLS 1.3 should be doing is merge part of the TLS session > ticket spec into the main document, using the traditional session ID fields > for legacy cases only (i.e., ClientHello.session_id would be present for > backwards compatibility but always empty unless you're trying to resume a > <= TLS 1.2 session) Technical nitpick: currently a non-empty ClientHello.session_id can also be used with tickets: When presenting a ticket, the client MAY generate and include a Session ID in the TLS ClientHello. If the server accepts the ticket and the Session ID is not empty, then it MUST respond with the same Session ID present in the ClientHello. This allows the client to easily differentiate when the server is resuming a session from when it is falling back to a full handshake. Which is useful IMO. Manuel. From nobody Wed Sep 3 01:45:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC0B1A8028 for ; Wed, 3 Sep 2014 01:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[AC_BR_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4pa_InXzbjEK for ; Wed, 3 Sep 2014 01:44:56 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 389691A00BF for ; Wed, 3 Sep 2014 01:44:46 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id wp4so5856664obc.20 for ; Wed, 03 Sep 2014 01:44:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lAl7sM4JNaSSIPv3UpkfZO0JG0cQNX5E4NAFe++ovUI=; b=Z4sb/EShoJpY5zpEsbsB63A6y0Zt7EMTrm0TjIXVDu5UkKFq21ZFDMrwkpqyeY4pe0 78hy1ZUgL9gBk0gRN4t8ihe3viTMv+jYgyA/6mlHgIVRNlW9KRMoncKeriqqvpKhOKsL HF+VftACG5gkL0TG2p5PPTbgkkQqD1dkM+vB4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=lAl7sM4JNaSSIPv3UpkfZO0JG0cQNX5E4NAFe++ovUI=; b=csLed4FfCGRIdjAIMuevo1mMdBJLZ20lJtwTmqxQqoSwSk7h0eaGMxD8L4jiIZ5IdY rubRVtMgGIOTV7W/8J0DrT4BlYBWfLe1dTrL+rThJrDjbweG0gw7MFrCaiX1aODCymIU c6LpIIrWcT2aKr0QQcOcoLw7Q+Quu7uceDt3O7wjYI2ver+UaraHxN6RPpSUla6Ei1hH c4JyYDrlRn0TfRsp5AagoZb4/GHCdH6FR8Jjj0gt7KCtl94ZgJr51D6HPpQzM4cd1vYY VVCzpM3LqPVJ0IuEwB31YVmfJyZqaefXcHbHR+hO0OsdEB3NxuOAjTAAndXc2MMXvRox K/mw== X-Gm-Message-State: ALoCoQn5fpuqTmVkRCyks/DgoW2muZAKd4w6amRx1pZyVbOojMCtQiJZpDmv2i2WNsb9W0mRglgM MIME-Version: 1.0 X-Received: by 10.182.94.204 with SMTP id de12mr7004126obb.66.1409733886369; Wed, 03 Sep 2014 01:44:46 -0700 (PDT) Received: by 10.76.97.172 with HTTP; Wed, 3 Sep 2014 01:44:46 -0700 (PDT) X-Originating-IP: [128.93.62.11] In-Reply-To: <00d201cfc63b$1c48b1d0$54da1570$@augustcellars.com> References: <00d201cfc63b$1c48b1d0$54da1570$@augustcellars.com> Date: Wed, 3 Sep 2014 10:44:46 +0200 Message-ID: From: Alfredo Pironti To: Jim Schaad Content-Type: multipart/alternative; boundary=e89a8f83964f8674540502253f7d Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WfgsS1sIO0WUJxs9aC8eta9qgyE Cc: "tls@ietf.org" Subject: Re: [TLS] Master Secret Computation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 08:44:59 -0000 --e89a8f83964f8674540502253f7d Content-Type: text/plain; charset=UTF-8 On Tue, Sep 2, 2014 at 1:18 AM, Jim Schaad wrote: > This message applies to both the 1.3 TLS document and to the session hash > document. > > > I have not ever implemented TLS, so I have been spending some time reading > the documents to try and figure out how things are going to work. Based on > mail see, I have assumed that 1.3 is going to adopt the extended hash > computation for the master secret and have created my table based on this. > (If this is not the case then I think it needs to be argued.) > > As part of putting together the attacked picture, I read a number of > different TLS documents which are not part of the core spec. It is > possible > that some of these are no longer needed and should be ruled out as possible > extensions to the TLS 1.3 document, but would be relevant to the extension > for the 1.2 (and prior) documents. > > Notes on the picture that I have included: > > Items tagged with [1] are sent only in the event that the server does not > want to have a client certificate. > Items tagged with [2] are sent only in the event that the a) there is a > client certificate or b) the new session ticket extension is being used. > Items tagged with [3] are sent in the event that a restart is made because > of a mismatch of key agree groups. > > I am not clear if the use of the Supplemental Data extension means that the > server Finish message cannot be sent before receiving the response from the > client. > The new session ticket extension requires that the client finish message be > validated before it can be sent to the client, thus it falls into the [2] > grouping. > > The green means that the handshake message is part of the hash computation. > The yellow means that it would be part of the computation for [2] but not > for [1]. The "pink" is part of my assumption that a the hashing should > include the failed early handshake message. > > The current hashing document says that the hash would not include the > CertificateVerify message (for the client). I am assuming that this is > because there is a large presumption that the hash that is used for the PRF > function and the hash that the client would use in computing the > CertificateVerify message is going to same. This presumption should > probably be documented. > The hash used for signature and the one used for the PRF can indeed be different. The reason why we left CertificateVerify out from the session_hash is that the master_secret computation depends on session_hash. In turn, in SSL 3.0, the computation of CertificateVerify depends on the master_secret. This could be relaxed for later TLS versions, where the master_secret is not used in the computation of the CertificateVerify message. However, since CertificateVerify does not alter the state of the session, we left it out for all TLS versions, to ease implementation of the extension. This choice is documented in the implementation note of section 3 of the current session-hash draft. But if the text doesn't read clear enough, we can try to improve it. > > I am unsure what the correct behavior should be in the event that the > SupplementalData extension is used, but the client certificate message is > not used. Should this be part of the master secret hash or not? > > In looking at the sequence, doing a re-negotiation would seem to have a bad > property of going from the cipher suite which uses the hash of the > handshake > to one that just uses the keys and the randoms part way through the > re-negotiation process. This means that any application data sent between > the first and the second change_cipher_suite messages would potentially not > be as well protected. This could be fixed by not having the first pair of > change_cipher_suite messages in the event of a re-negotiation as there is > no > need to go from a NULL_NULL cipher suite to one which has encryption. > As discussed in the session-hash call for adoption thread [1], the session-hash extension is mainly intended as a fix for TLS <= 1.2; whereas the fix should be an integral part of TLS 1.3 (and how this is precisely achieved is still under design). Best, Alfredo [1] http://www.ietf.org/mail-archive/web/tls/current/msg13173.html > > > Jim > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --e89a8f83964f8674540502253f7d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable



On Tue, Sep 2, 2014 at 1:18 AM, Jim Schaad <ietf@augustcellar= s.com> wrote:
This message applies to both the 1.3 TLS document and to the session = hash
document.


I have not ever implemented TLS, so I have been spending some time reading<= br> the documents to try and figure out how things are going to work.=C2=A0 Bas= ed on
mail see, I have assumed that 1.3 is going to adopt the extended hash
computation for the master secret and have created my table based on this.<= br> (If this is not the case then I think it needs to be argued.)

As part of putting together the attacked picture, I read a number of
different TLS documents which are not part of the core spec.=C2=A0 It is po= ssible
that some of these are no longer needed and should be ruled out as possible=
extensions to the TLS 1.3 document, but would be relevant to the extension<= br> for the 1.2 (and prior) documents.

Notes on the picture that I have included:

Items tagged with [1] are sent only in the event that the server does not want to have a client certificate.
Items tagged with [2] are sent only in the event that the a) there is a
client certificate or b) the new session ticket extension is being used. Items tagged with [3] are sent in the event that a restart is made because<= br> of a mismatch of key agree groups.

I am not clear if the use of the Supplemental Data extension means that the=
server Finish message cannot be sent before receiving the response from the=
client.
The new session ticket extension requires that the client finish message be=
validated before it can be sent to the client, thus it falls into the [2] grouping.

The green means that the handshake message is part of the hash computation.=
The yellow means that it would be part of the computation for [2] but not for [1].=C2=A0 The "pink" is part of my assumption that a the has= hing should
include the failed early handshake message.

The current hashing document says that the hash would not include the
CertificateVerify message (for the client).=C2=A0 I am assuming that this i= s
because there is a large presumption that the hash that is used for the PRF=
function and the hash that the client would use in computing the
CertificateVerify message is going to same.=C2=A0 This presumption should probably be documented.

The hash used f= or signature and the one used for the PRF can indeed be different.
The r= eason why we left CertificateVerify out from the session_hash is that the m= aster_secret computation depends on session_hash. In turn, in SSL 3.0, the = computation of CertificateVerify depends on the master_secret.
This coul= d be relaxed for later TLS versions, where the master_secret is not used in= the computation of the CertificateVerify message. However, since Certifica= teVerify does not alter the state of the session, we left it out for all TL= S versions, to ease implementation of the extension.
This choice is docu= mented in the implementation note of section 3 of the current session-hash = draft. But if the text doesn't read clear enough, we can try to improve= it.
=C2=A0

I am unsure what the correct behavior should be in the event that the
SupplementalData extension is used, but the client certificate message is not used.=C2=A0 Should this be part of the master secret hash or not?

In looking at the sequence, doing a re-negotiation would seem to have a bad=
property of going from the cipher suite which uses the hash of the handshak= e
to one that just uses the keys and the randoms part way through the
re-negotiation process.=C2=A0 This means that any application data sent bet= ween
the first and the second change_cipher_suite messages would potentially not=
be as well protected.=C2=A0 This could be fixed by not having the first pai= r of
change_cipher_suite messages in the event of a re-negotiation as there is n= o
need to go from a NULL_NULL cipher suite to one which has encryption.

As discussed in the session-hash call for ad= option thread [1], the session-hash extension is mainly intended as a fix f= or TLS <=3D 1.2; whereas the fix should be an integral part of TLS 1.3 (= and how this is precisely achieved is still under design).

Best,
= Alfredo

[1] http://www.ietf.org/mail-archive/web/tls/current/msg1317= 3.html
=C2=A0


Jim























































































































































































































































































































































































































































































































































































































































































































































































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


--e89a8f83964f8674540502253f7d-- From nobody Wed Sep 3 03:34:36 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E62C01A015F for ; Wed, 3 Sep 2014 03:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3p7BxYyYJDWj for ; Wed, 3 Sep 2014 03:34:31 -0700 (PDT) Received: from na3sys010aog108.obsmtp.com (na3sys010aog108.obsmtp.com [74.125.245.84]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26EA91A01CB for ; Wed, 3 Sep 2014 03:34:31 -0700 (PDT) Received: from mail-vc0-f180.google.com ([209.85.220.180]) (using TLSv1) by na3sys010aob108.postini.com ([74.125.244.12]) with SMTP ID DSNKVAbutv4IW/4MxTAQqqxh4aYNAmLn57LM@postini.com; Wed, 03 Sep 2014 03:34:31 PDT Received: by mail-vc0-f180.google.com with SMTP id lf12so8295482vcb.25 for ; Wed, 03 Sep 2014 03:34:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=j9QuGARGqY7uyHFvz+Ezchjobn8MPD7wcjDZrH4wu1g=; b=wS3L82yyfAOU4IKDEIvLn7urN/7IpA2gEyYawxtfoBNAQEyrxONbCyEzcLGKSIpRzk wFyCuEP1ZXK6mDcQS+9KPFj+Qa/s5AL3CxgWuYZ2Im1JlcImsyFwNEvRHb2ZxQlKAK0y oT6kLcy8lBxxkAHum39E5GB5X9NPnzrEvfUNA= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=j9QuGARGqY7uyHFvz+Ezchjobn8MPD7wcjDZrH4wu1g=; b=TbioP+ZSXo3FEYLXFNOZNsrakETa8IC2GVF+39jhU4RCfkpy4YWTYshX/Oyt/ne4tF Gs9jCqGOdzLoiN3K3C7sNAX4115INOEKIMyQ8dir6NdOfcG+YyPvALTen2DcpLioHUKs bKOsd5QcNQ/59KPpaK0yvLfR/xiCe7+LOB3wptA5Y4UBnrR+Dqu+oXJoG6etA1FNndtR HebSTYbNp7088dhLXR+A2c9Pb/V7z2le41dq6FYaeiS4KmPCGIvXFp//f1JMmv+c+iaX L9QttSKaS+XcJNLv5k+eE4ulE7kklygWykigeD7sQJdevLpg+YuXsif1nwgDcNDbLGzQ Od0w== X-Gm-Message-State: ALoCoQlO5flI5wlXd25IdgUQg8nuzctXBb+/PkLYouuMe3Tu3dPUy6V7ij/HFoyDI9RtTnBFyczjN1Kg1Rgk/0F3d8OTMkUabQzB2LvGHDnrMPy5p3j5Otpye+GBLA2hGsuVu1XQkIGi X-Received: by 10.220.86.193 with SMTP id t1mr22635972vcl.22.1409740470027; Wed, 03 Sep 2014 03:34:30 -0700 (PDT) X-Received: by 10.220.86.193 with SMTP id t1mr22635967vcl.22.1409740469893; Wed, 03 Sep 2014 03:34:29 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.134.70 with HTTP; Wed, 3 Sep 2014 03:34:09 -0700 (PDT) In-Reply-To: <54048985.1020005@net.in.tum.de> References: <54048985.1020005@net.in.tum.de> From: Yutaka OIWA Date: Wed, 3 Sep 2014 19:34:09 +0900 Message-ID: To: Ralph Holz Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QwIcKjaBxQkl8bqtV1m9qi6u8bk Cc: "" Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 10:34:34 -0000 The document title is "Recommendations for Secure Use of TLS and DTLS", clearly applicable for the "Secure Uses". It also says "These are minimum recommendations for the general use of TLS." For the purposes of such secure and general use cases, NULL ciphers are clearly "MUST NOT" with no doubt. If you have any "insecure", special (non-general) use cases of TLS, the document do not forbid you to use it, because the document is simply not applicable. However, such special use cases shall not make any hindrance for making a BCP document for general use cases. If you worry for implementors to drop codes for special use cases, you should say it loud to implementors, not to this document. Also, if you worry for making it hard to use, it is the fair cost for non-generic but supported use cases. Security libraries easily configurable for insecure setting is a huge security concern for general applications. One possible solution is to add a short note about such special uses, saying "it's out of this document's scope, but you should really take care of its security setting and consequences by yourself." 2014-09-01 23:58 GMT+09:00 Ralph Holz : > Dear list, > > I would like to notify the list of a feature in the draft for Best > Practices "Recommendations for Secure Use of TLS and DTLS" > > http://tools.ietf.org/html/draft-ietf-uta-tls-bcp-02 > > =3D> "Implementations MUST NOT negotiate the NULL cipher suites" > > This may lead to implementations dropping NULL (or making it hard to > enable). > > There used to be one reasonable use case for NULL that I am personally > aware of: grid traffic between large computing centres. Our group did > see such high-speed, high-volume traffic on our network monitors when we > did SSL/TLS/X.509 analyses - that was 3 years ago. > > My contacts at grid centres tell me that NULL encryption was useful then > as the data was public anyway and good integrity was all that was > needed. I am told by one centre at least there is no real need for NULL > any more. In fact, the agreement seems to be that that cipher should be > eliminated now. > > My personal take as one of the authors of the BCP is that the UTA WG > should process UNLESS someone has a use case that is relevant on the > same scale, or thinks the above statement does not hold in general. > > In that case, please bring your use case to the attention of the UTA or > directly to the authors (i.e. Yaron Sheffer, yaronf.ietf@gmail.com, or > me). We would like to keep any discussion focused. > > Thanks, > Ralph > > -- > Ralph Holz > I8 - Network Architectures and Services > Technische Universit=C3=A4t M=C3=BCnchen > http://www.net.in.tum.de/de/mitarbeiter/holz/ > Phone +49.89.289.18043 > PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --=20 Yutaka OIWA, Ph.D. Leader, System Life-cycle Research Group Research Institute for Secure Systems (RISEC= ) National Institute of Advanced Industrial Science and Technology (AIST= ) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5= ] From nobody Wed Sep 3 04:15:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23E2A1A00E1 for ; Wed, 3 Sep 2014 04:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKPhcIMsBXZa for ; Wed, 3 Sep 2014 04:15:13 -0700 (PDT) Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by ietfa.amsl.com (Postfix) with ESMTP id D13221A0068 for ; Wed, 3 Sep 2014 04:15:13 -0700 (PDT) Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s83BF2DY017150; Wed, 3 Sep 2014 07:15:02 -0400 Date: Wed, 3 Sep 2014 07:15:02 -0400 (EDT) From: Hubert Kario To: "Richard Fussenegger, BSc" Message-ID: <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> In-Reply-To: <54065198.7030802@fussenegger.info> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_42281154_1642475867.1409742902145" X-Originating-IP: [10.5.82.7] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922) Thread-Topic: tickets or sesssions or both (oh my) Thread-Index: EtskSF2NN4uR4X6svqLoNTNrqibtOw== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1Gw4hxU-zMKZL2lqU9544K0opEg Cc: tls@ietf.org Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 11:15:15 -0000 ------=_Part_42281154_1642475867.1409742902145 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > From: "Richard Fussenegger, BSc" > To: tls@ietf.org > Sent: Wednesday, September 3, 2014 1:24:08 AM > Subject: Re: [TLS] tickets or sesssions or both (oh my) > I think it would be good to merge the tickets into the specs because in a > long term the ticket approach makes much more sense. Clients are gaining > more and more storage and maintaining a session cache for all clients is = a > huge burden for the servers. Especially if you're running a huge server > network. The one big feature of TLS 1.3 is PFS by default. It is hard to make ticket= s work with PFS, you need a synchronisation mechanism between servers one w= ay or the other if you want to retain PFS.=20 You can do tickets and not do synchronisation, in effect destroying PFS eff= orts, while you can't do IDs without synchronisation, so making them PFS-re= taining is relatively simple.=20 If anything, I'd say that we should drop tickets entirely from TLS 1.3, as = the implementations don't implement them in a way that preserves general pr= operties of protocol.=20 --=20 Regards,=20 Hubert Kario=20 Quality Engineer, QE BaseOS Security team=20 Email: hkario@redhat.com=20 Web: www.cz.redhat.com=20 Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic=20 ------=_Part_42281154_1642475867.1409742902145 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
From: "Richard Fussenegger, BSc" <richard@f= ussenegger.info>
To: tls@ietf.org
Sent: Wednesday, S= eptember 3, 2014 1:24:08 AM
Subject: Re: [TLS] tickets or sesssio= ns or both (oh my)

I think it would be good to merge the tickets into the specs because in a long term the ticket approach makes much more sense. Clients are gaining more and more storage and maintaining a session cache for all clients is a huge burden for the servers. Especially if you're running a huge server network.
The one big feature of = TLS 1.3 is PFS by default. It is hard to make tickets work with PFS, you ne= ed a synchronisation mechanism between servers one way or the other if you = want to retain PFS.

You can do tickets and not= do synchronisation, in effect destroying PFS efforts, while you can't do I= Ds without synchronisation, so making them PFS-retaining is relatively simp= le.

If anything, I'd say that we should drop t= ickets entirely from TLS 1.3, as the implementations don't implement them i= n a way that preserves general properties of protocol.

--
Regards,
Hubert Kario=
Quality Engineer, QE BaseOS Security team
Email: hkario@redhat.comWeb: www.cz.redhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612= 45, Brno, Czech Republic
------=_Part_42281154_1642475867.1409742902145-- From SRS0=Hg4p=54=acm.org=bmoeller@srs.kundenserver.de Wed Sep 3 04:02:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79EEE1A86F9 for ; Wed, 3 Sep 2014 04:02:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.104 X-Spam-Level: * X-Spam-Status: No, score=1.104 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yfNf8F0ZtWrZ for ; Wed, 3 Sep 2014 04:02:07 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 92DD61A8704 for ; Wed, 3 Sep 2014 04:02:06 -0700 (PDT) Received: from mail-yh0-f54.google.com (mail-yh0-f54.google.com [209.85.213.54]) by mrelayeu.kundenserver.de (node=mreue104) with ESMTP (Nemesis) id 0Lr24R-1Y2Ipc41FD-00eYo0; Wed, 03 Sep 2014 13:02:04 +0200 Received: by mail-yh0-f54.google.com with SMTP id b6so5159919yha.13 for ; Wed, 03 Sep 2014 04:02:02 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.37.3 with SMTP id x3mr11076115yha.111.1409742122752; Wed, 03 Sep 2014 04:02:02 -0700 (PDT) Received: by 10.170.129.17 with HTTP; Wed, 3 Sep 2014 04:02:02 -0700 (PDT) In-Reply-To: <5406D275.3010101@polarssl.org> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <5406D275.3010101@polarssl.org> Date: Wed, 3 Sep 2014 13:02:02 +0200 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=089e0115f7a473a3b80502272ab5 X-Provags-ID: V02:K0:ig6ZU79h113vwvEsLwy/azioeRgQ8WK5WurOZIZPfet TC70acAEatX92LJWrspi0NmVUvAzf16JtULlhJ8QuF9ssOB8h8 4HRjWGNVO+Tiqs5Whd/BwFvoNIfrPVQzoonpyBTJx0Wt0sjiFw NPh8Te5c23UDuZy23DuWztq0M74gBRy8OhXnWknmPvv13v2zNm cxvmGX38eD+VZexBif4TSHfdaJgE2m7iwwY2v7Xaum5TN4sqhn HckVrfiDarRG9zSghHP34pZx6cisuFf2UwfakGqo4Q20LW4RJ8 Yn6DmmI/p086oNXRUnBzLOFIALjjxeTkPW69BdyC4xq2CRwGDZ W+eRCph+NVYbV6uG55RteUZCAICQp846ZtqLOsRvpCQMChq6VV zPQwMvMMsK1zMTn8Uo95LrD+7+1vmU/y7BN4JXf1Y557XFDKFu Wg8NN X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/XaJQMF9fMCnGQL8QjgHWtxjUS7Q Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 11:24:51 -0000 --089e0115f7a473a3b80502272ab5 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Manuel P=C3=A9gouri=C3=A9-Gonnard : > On 03/09/2014 00:06, Bodo Moeller wrote: > > So maybe what TLS 1.3 should be doing is merge part of the TLS > session > > ticket spec into the main document, using the traditional session ID > fields > > for legacy cases only (i.e., ClientHello.session_id would be present fo= r > > backwards compatibility but always empty unless you're trying to resume= a > > <=3D TLS 1.2 session) > > Technical nitpick: currently a non-empty ClientHello.session_id can also > be used > with tickets: > > When presenting a ticket, the client MAY generate and include a > Session ID in the TLS ClientHello. If the server accepts the ticket > and the Session ID is not empty, then it MUST respond with the same > Session ID present in the ClientHello. This allows the client to > easily differentiate when the server is resuming a session from when > it is falling back to a full handshake. > Right -- as when resuming based on the traditional ClientHello.session_id (in which case the server responds with the same value in ServerHello.session_id to confirm session resumption), the TLS session ticket specification currently has the server mirror back a random "ID" optionally presented by the client to confirm ticket-based session resumption. Clients are not required to make use of this, but server-side support is mandated. It is useful to have *a* mechanism to explicitly confirm session resumption so that the client already knows what to expect after having seen the ServerHello, but I don't see a good reason to continue to overload ClientHello.session_id and ServerHello.session_id with this particular hack. If we remove the traditional semantics of ClientHello.session_id and ServerHello.session_id for the new protocol version, an always-empty ClientHello.session_id and a simple magic value in ServerHello.session_id confirming session resumption would do: having the client send a made-up session ID only adds overhead. (The reason to make use of ServerHello.session_id for the proposed magic value is that the field is already specified, and is related to session resumption; in principle, the signal could go elsewhere in the ServerHello message.) I'm guessing that the thinking underlying the specified use of the session_id fields in RFC 5077 is that this makes it easier for both ways of handling sessions to coexist (although based on code I've had to fix, I'm not sure that it succeeded). If traditional session IDs are no longer used (because even stateful session resumption can use "session ticket" mechanisms on the wire instead), that's no longer an issue. Bodo --089e0115f7a473a3b80502272ab5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Manu= el P=C3=A9gouri=C3=A9-Gonnard <mpg@polarssl.org>:
On 03/09/2014 00:06, Bodo Moeller wrote:
>=C2=A0 =C2=A0 =C2=A0 So maybe what TLS 1.3 should be doing is merge par= t of the TLS session
> ticket spec into the main document, using the traditional session ID f= ields
> for legacy cases only (i.e., ClientHello.session_id would be present f= or
> backwards compatibility but always empty unless you're trying to r= esume a
> <=3D TLS 1.2 session)

Technical nitpick: currently a non-empty ClientHello.session_id can a= lso be used
with tickets:

=C2=A0 =C2=A0When presenting a ticket, the client MAY generate and include = a
=C2=A0 =C2=A0Session ID in the TLS ClientHello.=C2=A0 If the server accepts= the ticket
=C2=A0 =C2=A0and the Session ID is not empty, then it MUST respond with the= same
=C2=A0 =C2=A0Session ID present in the ClientHello.=C2=A0 This allows the c= lient to
=C2=A0 =C2=A0easily differentiate when the server is resuming a session fro= m when
=C2=A0 =C2=A0it is falling back to a full handshake.
<= br>
Right -- as when resuming based on the traditional ClientHell= o.session_id (in which case the server responds with the same value in Serv= erHello.session_id to confirm session resumption), the TLS session ticket s= pecification currently has the server mirror back a random "ID" o= ptionally presented by the client to confirm ticket-based session resumptio= n. Clients are not required to make use of this, but server-side support is= mandated.

It is useful to have *a* mechanism to explicitly confir= m session resumption so that the client already knows what to expect after = having seen the ServerHello, but I don't see a good reason to continue = to overload ClientHello.session_id and ServerHello.session_id with this par= ticular hack. If we remove the traditional semantics of ClientHello.session= _id and ServerHello.session_id for the new protocol version, an always-empt= y ClientHello.session_id and a simple magic value in ServerHello.session_id= confirming session resumption would do: having the client send a made-up s= ession ID only adds overhead. (The reason to make use of ServerHello.sessio= n_id for the proposed magic value is that the field is already specified, a= nd is related to session resumption; in principle, the signal could go else= where in the ServerHello message.)

I'm guessing that the thinking underlying the= specified use of the session_id fields in=C2=A0RFC 5077=C2=A0is that this = makes it easier for both ways of handling sessions to coexist (although bas= ed on code I've had to fix, I'm not sure that it succeeded). =C2=A0= If traditional session IDs are no longer used (because even stateful sessio= n resumption can use "session ticket" mechanisms on the wire inst= ead), that's no longer an issue.

Bodo

--089e0115f7a473a3b80502272ab5-- From SRS0=Hg4p=54=acm.org=bmoeller@srs.kundenserver.de Wed Sep 3 04:24:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4469D1A8708 for ; Wed, 3 Sep 2014 04:24:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.596 X-Spam-Level: X-Spam-Status: No, score=-1.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EItm2XgF_D4K for ; Wed, 3 Sep 2014 04:24:38 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22F311A86FD for ; Wed, 3 Sep 2014 04:24:38 -0700 (PDT) Received: from mail-yk0-f174.google.com (mail-yk0-f174.google.com [209.85.160.174]) by mrelayeu.kundenserver.de (node=mreue105) with ESMTP (Nemesis) id 0MVd4p-1XudTv0EHf-00Z3CP; Wed, 03 Sep 2014 13:24:36 +0200 Received: by mail-yk0-f174.google.com with SMTP id 10so4969817ykt.19 for ; Wed, 03 Sep 2014 04:24:34 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.2.164 with SMTP id 24mr3430755yhf.126.1409743474839; Wed, 03 Sep 2014 04:24:34 -0700 (PDT) Received: by 10.170.129.17 with HTTP; Wed, 3 Sep 2014 04:24:34 -0700 (PDT) In-Reply-To: <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> Date: Wed, 3 Sep 2014 13:24:34 +0200 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=089e011823aa0ad9cf0502277b0c X-Provags-ID: V02:K0:mVw1sKzWeLncY0bavnLmTkNbaJ5IpBIwgKmLZaNrrgF IlE7LeVnrhNe3wfRbUZmFZE4kyzsqA72S0YzypTBEVx6VgyPpK +pWsjHYDFmYoFq3taD8YjDiUNCkn7f7weKiQAZttkWuTGEzul1 ctVpHsLX8SJFsXHBPVDRMwhTULM9gcmzz0kx/GctyiaEB0VdM6 ysRwo7D20a3hjpoWkAHDQiIDTZA7cc2EPwW9Dr0Z+M/tiDpyLP KkoHYrmsILGXups723mjPcTRT92gmPCILTZhzp7SXmbVE8T1eO wAE1yEV91+UoYlBATBAH+9Dvg8NjzoYjsgT6hand08sgp/bbqk bgnP96TxxWQG3Xd15IPXNo00x8xw0Cz/QkyaIviyT46BDuTUNE ZpgVJZ8EE6JL2FCgMPNLnwkRc2ogmvnn3x33Ig2w3317klOWYu CQPCL X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/W8CncWmffYIC88e0cMlOGTL9lPY Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 11:25:12 -0000 --089e011823aa0ad9cf0502277b0c Content-Type: text/plain; charset=UTF-8 Hubert Kario : > The one big feature of TLS 1.3 is PFS by default. It is hard to make > tickets work with PFS, you need a synchronisation mechanism between servers > one way or the other if you want to retain PFS. > > > You can do tickets and not do synchronisation, in effect destroying PFS > efforts, while you can't do IDs without synchronisation, so making them > PFS-retaining is relatively simple. > > If anything, I'd say that we should drop tickets entirely from TLS 1.3, as > the implementations don't implement them in a way that preserves general > properties of protocol. > > What I'm proposing is to only have the session ticket *protocol* in TLS 1.3, but having the main RFC describe how this can be used to handle session *IDs* (where session details are kept in server-side state). A companion RFC can explain how to use this protocol for encrypted tickets: this will need to include appropriate caveats for forward security. Bodo --089e011823aa0ad9cf0502277b0c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hube= rt Kario <hkario@redhat.com>:
The one big feature of TLS 1.3 is PFS by default. = It is hard to make tickets work with PFS, you need a synchronisation mechan= ism between servers one way or the other if you want to retain PFS.<= br>

You can do tickets and not do synchronisat= ion, in effect destroying PFS efforts, while you can't do IDs without s= ynchronisation, so making them PFS-retaining is relatively simple.

If anything, I'd say that we should drop tickets en= tirely from TLS 1.3, as the implementations don't implement them in a w= ay that preserves general properties of protocol.

What I= 9;m proposing is to only have the session ticket *protocol* in TLS 1.3, but= having the main RFC describe how this can be used to handle session *IDs* = (where session details are kept in server-side state). A companion RFC can = explain how to use this protocol for encrypted tickets: this will need to i= nclude appropriate caveats for forward security.

Bodo

--089e011823aa0ad9cf0502277b0c-- From nobody Wed Sep 3 04:40:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD831A8A49 for ; Wed, 3 Sep 2014 04:40:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.269 X-Spam-Level: X-Spam-Status: No, score=-3.269 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gntx37mQHmQq for ; Wed, 3 Sep 2014 04:40:32 -0700 (PDT) Received: from mx5-phx2.redhat.com (mx5-phx2.redhat.com [209.132.183.37]) by ietfa.amsl.com (Postfix) with ESMTP id E39C61A8A4C for ; Wed, 3 Sep 2014 04:40:31 -0700 (PDT) Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx5-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s83BeUkt015811; Wed, 3 Sep 2014 07:40:30 -0400 Date: Wed, 3 Sep 2014 07:40:30 -0400 (EDT) From: Hubert Kario To: Bodo Moeller Message-ID: <1408022371.42292099.1409744430634.JavaMail.zimbra@redhat.com> In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_42292098_1318447331.1409744430633" X-Originating-IP: [10.5.82.7] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922) Thread-Topic: tickets or sesssions or both (oh my) Thread-Index: Tfrb2o3AQV0+bV188aqvkbbapQZwXg== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2G0enrbt5tnJC63uZvc7PqD75X4 Cc: tls@ietf.org Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 11:40:34 -0000 ------=_Part_42292098_1318447331.1409744430633 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > From: "Bodo Moeller" > To: tls@ietf.org > Sent: Wednesday, September 3, 2014 1:24:34 PM > Subject: Re: [TLS] tickets or sesssions or both (oh my) > Hubert Kario < hkario@redhat.com > : > > > The one big feature of TLS 1.3 is PFS by default. It is hard to make > > > tickets > > > work with PFS, you need a synchronisation mechanism between servers o= ne > > > way > > > or the other if you want to retain PFS. > >=20 >=20 > > You can do tickets and not do synchronisation, in effect destroying PFS > > efforts, while you can't do IDs without synchronisation, so making them > > PFS-retaining is relatively simple. >=20 > > If anything, I'd say that we should drop tickets entirely from TLS 1.3,= as > > the implementations don't implement them in a way that preserves genera= l > > properties of protocol. >=20 > What I'm proposing is to only have the session ticket *protocol* in TLS 1= .3, > but having the main RFC describe how this can be used to handle session > *IDs* (where session details are kept in server-side state). A companion = RFC > can explain how to use this protocol for encrypted tickets: this will nee= d > to include appropriate caveats for forward security. What does re-purposing this filed give us (apart from confusion)? What can'= t be done by IDs?=20 I see potential for abuse (putting there real tickets, not IDs) with no cle= ar upside.=20 --=20 Regards,=20 Hubert Kario=20 Quality Engineer, QE BaseOS Security team=20 Email: hkario@redhat.com=20 Web: www.cz.redhat.com=20 Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic=20 ------=_Part_42292098_1318447331.1409744430633 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
From: "Bodo Moeller" <bmoeller@acm.org><= br>To: tls@ietf.org
Sent: Wednesday, September 3, 2014 1:2= 4:34 PM
Subject: Re: [TLS] tickets or sesssions or both (oh my)

Hubert Ka= rio <hkario@redhat.com>:
<= div>
The one big feature of TLS 1.3 is PFS by default. It is hard = to make tickets work with PFS, you need a synchronisation mechanism between= servers one way or the other if you want to retain PFS.

You can do tickets and not do synchronisation, in = effect destroying PFS efforts, while you can't do IDs without synchronisati= on, so making them PFS-retaining is relatively simple.

If anything, I'd say that we should drop tickets entirely from TLS= 1.3, as the implementations don't implement them in a way that preserves g= eneral properties of protocol.

=

What I'm proposing is t= o only have the session ticket *protocol* in TLS 1.3, but having the main R= FC describe how this can be used to handle session *IDs* (where session det= ails are kept in server-side state). A companion RFC can explain how to use= this protocol for encrypted tickets: this will need to include appropriate= caveats for forward security.



What does re-purposing this filed= give us (apart from confusion)? What can't be done by IDs?
<= br>
I see potential for abuse (putting there real tickets, not ID= s) with no clear upside.

--
Regards,
Hubert Kario
Quality Engineer, QE BaseOS Se= curity team
Email: hkario@redhat.com
Web: www.cz.redhat.com
Red Ha= t Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic
------=_Part_42292098_1318447331.1409744430633-- From nobody Wed Sep 3 05:04:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0BA41A00E2 for ; Wed, 3 Sep 2014 05:04:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.596 X-Spam-Level: X-Spam-Status: No, score=-1.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RC9YzX345Lsp for ; Wed, 3 Sep 2014 05:04:06 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94E7F1A008F for ; Wed, 3 Sep 2014 05:04:06 -0700 (PDT) Received: from mail-yh0-f41.google.com (mail-yh0-f41.google.com [209.85.213.41]) by mrelayeu.kundenserver.de (node=mreue006) with ESMTP (Nemesis) id 0MFVyq-1XbItb4992-00EQuI; Wed, 03 Sep 2014 14:04:04 +0200 Received: by mail-yh0-f41.google.com with SMTP id 29so5238769yhl.14 for ; Wed, 03 Sep 2014 05:04:00 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.190.133 with SMTP id e5mr59611630yhn.13.1409745840871; Wed, 03 Sep 2014 05:04:00 -0700 (PDT) Received: by 10.170.129.17 with HTTP; Wed, 3 Sep 2014 05:04:00 -0700 (PDT) In-Reply-To: <1408022371.42292099.1409744430634.JavaMail.zimbra@redhat.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> <1408022371.42292099.1409744430634.JavaMail.zimbra@redhat.com> Date: Wed, 3 Sep 2014 14:04:00 +0200 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=20cf30434bb8119fc80502280839 X-Provags-ID: V02:K0:lD1zLvn7MBimpz0Okrr+ukMSk2OLwNjZMZtQ8Nfl5z4 Mf36gNMTXYevzVkN2IXD+AdDWrRs6A7yD5ULo+8k6Cu0meDQyT t4c1LfeCl8RRBvxxG5VvV7RuE1aM/5Xsr2QMYnh4dEC5KkzaNg fekz4mf9o3IxemMwjh8W66T+OqwS5ewU9gmIjidYaIVRRrHoBy 0w5Vv80OG5aPrVXSRzBOM3d6P8WbgXLwpRLQcYE7hHDcaZIw83 KIiVXfvttJlW185JdCxP8+KvsJa4gwiZD/epdmzE2u3pwyxZn0 1bkk8zj4CdSRft14od1mxOPGBZ+QRV/OaxlfZIPNAoykmsubHW jzrl8O34ZJ+Xdv2+8V5iJ66MOkD3Z6P2EBgJ3LINlQEM7jd2xb 3/Clu53FMCrCCk5s82UA/5Z/2J1nrpnSida5WKG2qwWqPcVLzj cMVHO X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/n5HX3lZtUXoEbYqVCCZYbj2Ica4 Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 12:04:07 -0000 --20cf30434bb8119fc80502280839 Content-Type: text/plain; charset=UTF-8 Hubert Kario : > > What I'm proposing is to only have the session ticket *protocol* in TLS > 1.3, but having the main RFC describe how this can be used to handle > session *IDs* (where session details are kept in server-side state). A > companion RFC can explain how to use this protocol for encrypted tickets: > this will need to include appropriate caveats for forward security. > > What does re-purposing this filed give us (apart from confusion)? What > can't be done by IDs? > IDs, due to the size restriction, don't work if you really need tickets holding encrypted state. Repurposing the session-ticket wire protocol, then, *simplifies* the protocol by using a common protocol mechanism regardless of which approach to resumable sessions a given server employs (detailed server-side cached state, or tickets). I understand that you want to get rid of tickets entirely, which means that the session ID size restriction becomes a feature instead of a shortcoming. My goal, instead, is to specify the protocol such that it still *allows* servers to use tickets if they need to, while describing server-side cached state as the default model for session caching. Bodo --20cf30434bb8119fc80502280839 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hube= rt Kario <hkario@redhat.com>:
What I'm proposing is to only have the session ticket *protocol* in T= LS 1.3, but having the main RFC describe how this can be used to handle ses= sion *IDs* (where session details are kept in server-side state). A compani= on RFC can explain how to use this protocol for encrypted tickets: this wil= l need to include appropriate caveats for forward security.
What does re-purposing this filed give us = (apart from confusion)? What can't be done by IDs?

IDs, due to the size restriction, don'= t work if you really need tickets holding encrypted state. Repurposing the = session-ticket wire protocol, then, *simplifies* the protocol by using a co= mmon protocol mechanism regardless of which approach to resumable sessions = a given server employs (detailed server-side cached state, or tickets).

I understand that you want to get rid of tickets entire= ly, which means that the session ID size restriction becomes a feature inst= ead of a shortcoming. My goal, instead, is to specify the protocol such tha= t it still *allows* servers to use tickets if they need to, while describin= g server-side cached state as the default model for session caching.

Bodo

--20cf30434bb8119fc80502280839-- From nobody Wed Sep 3 05:04:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E68F1A010C for ; Wed, 3 Sep 2014 05:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0khjqUumjlm3 for ; Wed, 3 Sep 2014 05:04:39 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id A54711A008F for ; Wed, 3 Sep 2014 05:04:39 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 168E5475A4; Wed, 3 Sep 2014 12:04:39 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id 0A2044755F; Wed, 3 Sep 2014 12:04:39 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id EED182027; Wed, 3 Sep 2014 12:04:38 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.218]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Wed, 3 Sep 2014 08:04:38 -0400 From: "Salz, Rich" To: Bodo Moeller , "tls@ietf.org" Date: Wed, 3 Sep 2014 08:04:37 -0400 Thread-Topic: [TLS] tickets or sesssions or both (oh my) Thread-Index: Ac/HacFCZWqgJL1tTIegYvfWK9lYSAABWRvQ Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D12A96941@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0ViqCFFGZ6E9UGr7vbfX_SxSZAY Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 12:04:41 -0000 PiBXaGF0IEknbSBwcm9wb3NpbmcgaXMgdG8gb25seSBoYXZlIHRoZSBzZXNzaW9uIHRpY2tldCAq cHJvdG9jb2wqIGluIFRMUyAxLjMsIGJ1dCBoYXZpbmcgdGhlIG1haW4gUkZDIGRlc2NyaWJlIGhv dyB0aGlzIGNhbiBiZSB1c2VkIHRvIGhhbmRsZSBzZXNzaW9uICpJRHMqICh3aGVyZSBzZXNzaW9u IGRldGFpbHMgYXJlIGtlcHQgaW4gc2VydmVyLXNpZGUgc3RhdGUpLiBBIGNvbXBhbmlvbiBSRkMg Y2FuIGV4cGxhaW4gaG93IHRvIHVzZSB0aGlzIHByb3RvY29sIGZvciBlbmNyeXB0ZWQgdGlja2V0 czogdGhpcyB3aWxsIG5lZWQgdG8gaW5jbHVkZSBhcHByb3ByaWF0ZSBjYXZlYXRzIGZvciBmb3J3 YXJkIHNlY3VyaXR5Lg0KDQorMQ0KDQotLSAgDQpQcmluY2lwYWwgU2VjdXJpdHkgRW5naW5lZXIN CkFrYW1haSBUZWNobm9sb2dpZXMsIENhbWJyaWRnZSBNQQ0KSU06IHJzYWx6QGphYmJlci5tZSBU d2l0dGVyOiBSaWNoU2Fseg0KDQo= From nobody Wed Sep 3 05:48:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5304F1A028A for ; Wed, 3 Sep 2014 05:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.268 X-Spam-Level: X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sRXxdGs2RsJt for ; Wed, 3 Sep 2014 05:48:26 -0700 (PDT) Received: from mx6-phx2.redhat.com (mx6-phx2.redhat.com [209.132.183.39]) by ietfa.amsl.com (Postfix) with ESMTP id B44921A00F0 for ; Wed, 3 Sep 2014 05:48:26 -0700 (PDT) Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx6-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s83CmO1B001575; Wed, 3 Sep 2014 08:48:24 -0400 Date: Wed, 3 Sep 2014 08:48:24 -0400 (EDT) From: Hubert Kario To: Bodo Moeller Message-ID: <412891267.42325154.1409748504518.JavaMail.zimbra@redhat.com> In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> <1408022371.42292099.1409744430634.JavaMail.zimbra@redhat.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_42325153_74516324.1409748504516" X-Originating-IP: [10.5.82.7] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922) Thread-Topic: tickets or sesssions or both (oh my) Thread-Index: OAyccgBGNnZn8LDlL+KVD7I5BwpWbQ== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_kTlOKqXiQ7fMS0cBtJOLLp4JcY Cc: tls@ietf.org Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 12:48:28 -0000 ------=_Part_42325153_74516324.1409748504516 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > From: "Bodo Moeller" > To: tls@ietf.org > Sent: Wednesday, September 3, 2014 2:04:00 PM > Subject: Re: [TLS] tickets or sesssions or both (oh my) > Hubert Kario < hkario@redhat.com > : > > > What I'm proposing is to only have the session ticket *protocol* in T= LS > > > 1.3, > > > but having the main RFC describe how this can be used to handle sessi= on > > > *IDs* (where session details are kept in server-side state). A compan= ion > > > RFC > > > can explain how to use this protocol for encrypted tickets: this will > > > need > > > to include appropriate caveats for forward security. > >=20 >=20 > > What does re-purposing this filed give us (apart from confusion)? What > > can't > > be done by IDs? >=20 > IDs, due to the size restriction, don't work if you really need tickets > holding encrypted state. Repurposing the session-ticket wire protocol, th= en, > *simplifies* the protocol by using a common protocol mechanism regardless= of > which approach to resumable sessions a given server employs (detailed > server-side cached state, or tickets). > I understand that you want to get rid of tickets entirely, which means th= at > the session ID size restriction becomes a feature instead of a shortcomin= g. > My goal, instead, is to specify the protocol such that it still *allows* > servers to use tickets if they need to, while describing server-side cach= ed > state as the default model for session caching. I'm afraid that if clustering using a static encryption key for tickets is = the easiest way to do clustering (and also fastest, since you don't need an= y inter-host communication), this will be what *everybody* will do, thus ma= king the whole removal of kRSA ciphers for nought.=20 So yes, from this point of view the limitation of session ID size is a feat= ure.=20 Could you provide an example of system that "really need[s] tickets"?=20 --=20 Regards,=20 Hubert Kario=20 Quality Engineer, QE BaseOS Security team=20 Email: hkario@redhat.com=20 Web: www.cz.redhat.com=20 Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic=20 ------=_Part_42325153_74516324.1409748504516 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
From: "Bodo Moeller" <bmoeller@acm.org><= br>To: tls@ietf.org
Sent: Wednesday, September 3, 2014 2:0= 4:00 PM
Subject: Re: [TLS] tickets or sesssions or both (oh my)

Hubert Ka= rio <hkario@redhat.com>:
=
What I'm proposing is to only have the session ticket *protocol* in TLS = 1.3, but having the main RFC describe how this can be used to handle sessio= n *IDs* (where session details are kept in server-side state). A companion = RFC can explain how to use this protocol for encrypted tickets: this will n= eed to include appropriate caveats for forward security.
<= /div>
What does re-purposing this filed gi= ve us (apart from confusion)? What can't be done by IDs?

IDs, due to the size restriction, don't= work if you really need tickets holding encrypted state. Repurposing the s= ession-ticket wire protocol, then, *simplifies* the protocol by using a com= mon protocol mechanism regardless of which approach to resumable sessions a= given server employs (detailed server-side cached state, or tickets).

I understand that you want to get rid of tickets entir= ely, which means that the session ID size restriction becomes a feature ins= tead of a shortcoming. My goal, instead, is to specify the protocol such th= at it still *allows* servers to use tickets if they need to, while describi= ng server-side cached state as the default model for session caching.
=


I'm afrai= d that if clustering using a static encryption key for tickets is the easie= st way to do clustering (and also fastest, since you don't need any inter-h= ost communication), this will be what *everybody* will do, thus making the = whole removal of kRSA ciphers for nought.

So y= es, from this point of view the limitation of session ID size is a feature.=

Could you provide an example of system that "= really need[s] tickets"?

--
Regards,
Hubert Kario
Quality Engineer, QE BaseO= S Security team
Email: hkario@redhat.com
Web: www.cz.redhat.com
Re= d Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic
------=_Part_42325153_74516324.1409748504516-- From nobody Wed Sep 3 07:01:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8322E1A036A for ; Wed, 3 Sep 2014 07:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jiyDd8SJgIET for ; Wed, 3 Sep 2014 07:01:02 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 158E21A0367 for ; Wed, 3 Sep 2014 07:01:01 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id AD9892AB2BB; Wed, 3 Sep 2014 14:00:59 +0000 (UTC) Date: Wed, 3 Sep 2014 14:00:59 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140903140059.GW14392@mournblade.imrryr.org> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zoVutdr0p4qo3Up-TcQhFIBxVqo Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@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: Wed, 03 Sep 2014 14:01:05 -0000 On Wed, Sep 03, 2014 at 07:15:02AM -0400, Hubert Kario wrote: > The one big feature of TLS 1.3 is PFS by default. It is hard to > make tickets work with PFS, you need a synchronisation mechanism > between servers one way or the other if you want to retain PFS. Sorry, this seems rather non-obvious. How is stateless resumption less compatible with PFS than stateful resumption? What is this PFS obstacle you speak of. In Postfix PFS is on by default, as are session tickets. > You can do tickets and not do synchronisation, in effect destroying > PFS efforts, How so? And presumably one can do tickets and synchronize key rotation (at lower cost than synchronizing session state). > while you can't do IDs without synchronisation, so making them > PFS-retaining is relatively simple. Why is there any interlock between PFS and who stores the state for sessions? The client presents a ticket to the server, which is used to recover the server's session state. This is no different from recovering session state by any other means. > If anything, I'd say that we should drop tickets entirely from > TLS 1.3, as the implementations don't implement them in a way that > preserves general properties of protocol. Fix implementation defects. I am not aware of *any* intrinsic defects in tickets, and they solve a major scalability problem. This WG appears lately to be on a slash and burn campaign to reduce the broad applicability of TLS to just usability for certain types of web server deployments. This is troubling. -- Viktor. From nobody Wed Sep 3 07:03:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CF4B1A02F3 for ; Wed, 3 Sep 2014 07:03:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.596 X-Spam-Level: X-Spam-Status: No, score=-1.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qcft6L7oIf4y for ; Wed, 3 Sep 2014 07:03:02 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE9FC1A030C for ; Wed, 3 Sep 2014 07:03:01 -0700 (PDT) Received: from mail-yk0-f171.google.com (mail-yk0-f171.google.com [209.85.160.171]) by mrelayeu.kundenserver.de (node=mreue103) with ESMTP (Nemesis) id 0MFzpm-1XajsD2DGo-00Evdw; Wed, 03 Sep 2014 16:02:59 +0200 Received: by mail-yk0-f171.google.com with SMTP id 9so5089759ykp.2 for ; Wed, 03 Sep 2014 07:02:58 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.101.138 with SMTP id b10mr32591074yhg.91.1409752978492; Wed, 03 Sep 2014 07:02:58 -0700 (PDT) Received: by 10.170.129.17 with HTTP; Wed, 3 Sep 2014 07:02:58 -0700 (PDT) In-Reply-To: <412891267.42325154.1409748504518.JavaMail.zimbra@redhat.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> <1408022371.42292099.1409744430634.JavaMail.zimbra@redhat.com> <412891267.42325154.1409748504518.JavaMail.zimbra@redhat.com> Date: Wed, 3 Sep 2014 16:02:58 +0200 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=20cf301b606f811599050229b185 X-Provags-ID: V02:K0:Er6eNOSSfmVF8fQLfj9e3aSxwwL5ZIklHxtEuENuBmo TdEjX/M8HUalZ8I70K2Up/mHvsCuaRwbANDJ9VpV0ue+cLn+7x 1j8meJr5JUjqMCf1sHeAq8qmvkmFmRxg5l0PkJ3WrYT5OR2GiS x4hhohu6kJ+n2BEwmGr5q0wcigA9IpNR7eAqqsLRGu+xzT+EPy D+kbr0a4G1t/OXPic5cmS3o2DCh2B2xTxpd2Sn8IvBTGA+3KN2 bUWdTGhZsV2y4QS+NbViQwyf8eFLq3ddFYtiY1oomfIhHELhRw fvessa8aRUbfGL/Quo5fgUMVXH/axJRrWPS7g0IKoTK3LMDSEv 6FIMdh1ICHDCQvxG3UdlrGTEhCSUCQNMtn3SrK2mtvtESd6fyp zUlJJQPe6wnilxHuiK+gSyzb4Dbqe+wAEWJc8beWLPfMcZfpzB sBx2p X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Pl2cMzQsARYk2fsEmGmF7Vaapi0 Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 14:03:04 -0000 --20cf301b606f811599050229b185 Content-Type: text/plain; charset=UTF-8 Hubert Kario : Could you provide an example of system that "really need[s] tickets"? > Well, strictly speaking, no system really, really *needs* tickets because you could always start new sessions if a supposedly resumable session can't be found in the server's cache (at a computational cost, and at a latency cost). However, for any system that's large enough to require load balancing, a server-side session cache becomes unproportionally more expensive than in a single server, and makes denial-of-service problems more likely (badly behaved clients can fill up your session cache with unneeded entries, eventually forcing you to expire useful entries). Make the system global, and things get even worse: a session resumption request may be for a session that hasn't been negotiated in the same area, and might need to be fetched from elsewhere. At some point, building a system to rotate expiring session-ticket encryption keys just becomes a lot more attractive. I completely agree that using a fixed key for session-ticket encryption is not desirable, but deleting expired session-ticket encryption keys could even become much more practical than deleting lots of expiring sessions in a huge server-side session cache! Bodo --20cf301b606f811599050229b185 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hube= rt Kario <hkario@redhat.com>:

Could you provide an exa= mple of system that "really need[s] tickets"?

Well, strictly speaking, no system really,= really *needs* tickets because you could always start new sessions if a su= pposedly resumable session can't be found in the server's cache (at= a computational cost, and at a latency cost). However, for any system that= 's large enough to require load balancing, a server-side session cache = becomes unproportionally more expensive than in a single server, and makes = denial-of-service problems more likely (badly behaved clients can fill up y= our session cache with unneeded entries, eventually forcing you to expire u= seful entries). Make the system global, and things get even worse: a sessio= n resumption request may be for a session that hasn't been negotiated i= n the same area, and might need to be fetched from elsewhere.

At some point, building a system to rotate expiring ses= sion-ticket encryption keys just becomes a lot more attractive.
<= br>
I completely agree that using a fixed key for session-ticket = encryption is not desirable, but deleting expired session-ticket encryption= keys could even become much more practical than deleting lots of expiring = sessions in a huge server-side session cache!

Bodo

--20cf301b606f811599050229b185-- From nobody Wed Sep 3 07:11:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30C661A0331 for ; Wed, 3 Sep 2014 07:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6WTT8EMtJWf for ; Wed, 3 Sep 2014 07:11:51 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE8681A02FE for ; Wed, 3 Sep 2014 07:11:50 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id DC6032AB2BB; Wed, 3 Sep 2014 14:11:49 +0000 (UTC) Date: Wed, 3 Sep 2014 14:11:49 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140903141149.GX14392@mournblade.imrryr.org> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> <1408022371.42292099.1409744430634.JavaMail.zimbra@redhat.com> <412891267.42325154.1409748504518.JavaMail.zimbra@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <412891267.42325154.1409748504518.JavaMail.zimbra@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IssgpkyhS37XCX8AtbheKdsPdsY Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@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: Wed, 03 Sep 2014 14:11:52 -0000 On Wed, Sep 03, 2014 at 08:48:24AM -0400, Hubert Kario wrote: > I'm afraid that if clustering using a static encryption key for > tickets is the easiest way to do clustering (and also fastest, > since you don't need any inter-host communication), this will be > what *everybody* will do, thus making the whole removal of kRSA > ciphers for nought. The keys should NOT be static. The cluster can employ at any given time two keys, one used to encrypt new sessions, the other used to decrypted as yet unexpired older sessions. A new key is agreed periodically, by the cluster nodes, and then used to encrypt new sessions. Postfix already does this on the scale of hundreds of separate processes running on a single machine, extending this to multiple nodes is not a big deal. Let's fix the implementations by providing scalable technology for cluster key rotation in TLS toolkits. This will work *better* than current technologies for sharing server-side session state! Please DO NOT cripple TLS. -- Viktor. From nobody Wed Sep 3 07:13:45 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 684921A033C for ; Wed, 3 Sep 2014 07:13:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtSNjS2Ja-sY for ; Wed, 3 Sep 2014 07:13:42 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 498001A0331 for ; Wed, 3 Sep 2014 07:13:42 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id AFA752AB2BB; Wed, 3 Sep 2014 14:13:41 +0000 (UTC) Date: Wed, 3 Sep 2014 14:13:41 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140903141341.GY14392@mournblade.imrryr.org> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> <1408022371.42292099.1409744430634.JavaMail.zimbra@redhat.com> <412891267.42325154.1409748504518.JavaMail.zimbra@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AFgHNyv66OrQV45_aCMPojrXIe0 Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@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: Wed, 03 Sep 2014 14:13:43 -0000 On Wed, Sep 03, 2014 at 04:02:58PM +0200, Bodo Moeller wrote: > At some point, building a system to rotate expiring session-ticket > encryption keys just becomes a lot more attractive. > > I completely agree that using a fixed key for session-ticket encryption is > not desirable, but deleting expired session-ticket encryption keys could > even become much more practical than deleting lots of expiring sessions in > a huge server-side session cache! > > Bodo I am not in the habit of "+1" style responses. This is an exception: +100 -- Viktor. From nobody Wed Sep 3 07:15:24 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 150401A032F for ; Wed, 3 Sep 2014 07:15:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lhwfn1j3XnSk for ; Wed, 3 Sep 2014 07:15:16 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 68D911A031F for ; Wed, 3 Sep 2014 07:15:16 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id C50EF165741 for ; Wed, 3 Sep 2014 14:15:15 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id B9F3916573A for ; Wed, 3 Sep 2014 14:15:15 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id A20809803E for ; Wed, 3 Sep 2014 14:15:15 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.218]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Wed, 3 Sep 2014 10:15:14 -0400 From: "Salz, Rich" To: "tls@ietf.org" Date: Wed, 3 Sep 2014 10:15:13 -0400 Thread-Topic: [TLS] tickets or sesssions or both (oh my) Thread-Index: Ac/HgQU8XMB4m39QR7K0jTJH3esn8QAAFT/g Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D12A96A2D@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> <1408022371.42292099.1409744430634.JavaMail.zimbra@redhat.com> <412891267.42325154.1409748504518.JavaMail.zimbra@redhat.com> <20140903141149.GX14392@mournblade.imrryr.org> In-Reply-To: <20140903141149.GX14392@mournblade.imrryr.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gOzI9p7UhN3jUPQQDwRB4JPf0yY Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 14:15:21 -0000 > Postfix already does this on the scale of hundreds of separate processes > running on a single machine, extending this to multiple nodes is not a bi= g > deal. Okay, thanks, we're done here. No offense, but you don't know what you are= talking about. -- =20 Principal Security Engineer Akamai Technologies, Cambridge MA IM: rsalz@jabber.me Twitter: RichSalz From nobody Wed Sep 3 07:16:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 437DA1A033E for ; Wed, 3 Sep 2014 07:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DqWLNch9j6Ey for ; Wed, 3 Sep 2014 07:16:53 -0700 (PDT) Received: from mx207.easyname.com (mx207.easyname.com [212.232.25.163]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 296E11A031F for ; Wed, 3 Sep 2014 07:16:53 -0700 (PDT) Received: from 89-26-76-175.goll.dyn.salzburg-online.at ([89.26.76.175] helo=[192.168.0.11]) by mx.easyname.eu with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XPBMf-0003Ht-2E for tls@ietf.org; Wed, 03 Sep 2014 16:16:51 +0200 Message-ID: <540721A6.4030006@fussenegger.info> Date: Wed, 03 Sep 2014 16:11:50 +0200 From: "Richard Fussenegger, BSc" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: tls@ietf.org References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> <1408022371.42292099.1409744430634.JavaMail.zimbra@redhat.com> <412891267.42325154.1409748504518.JavaMail.zimbra@redhat.com> <20140903141149.GX14392@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C71D12A96A2D@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D12A96A2D@USMBX1.msg.corp.akamai.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/P6YWp-PVJO8hYbT1DA-Uyz5t-r8 Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 14:16:55 -0000 Could explain the exact problems to us? Richard On 9/3/2014 4:15 PM, Salz, Rich wrote: >> Postfix already does this on the scale of hundreds of separate processes >> running on a single machine, extending this to multiple nodes is not a big >> deal. > Okay, thanks, we're done here. No offense, but you don't know what you are talking about. > > -- > Principal Security Engineer > Akamai Technologies, Cambridge MA > IM: rsalz@jabber.me Twitter: RichSalz > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Sep 3 07:17:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A088F1A032F for ; Wed, 3 Sep 2014 07:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n-YXBvwddAOk for ; Wed, 3 Sep 2014 07:17:52 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 71CA11A031F for ; Wed, 3 Sep 2014 07:17:52 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B1F1647608 for ; Wed, 3 Sep 2014 14:17:51 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id A537A475C4 for ; Wed, 3 Sep 2014 14:17:51 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 9C83D80048 for ; Wed, 3 Sep 2014 14:17:51 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.218]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Wed, 3 Sep 2014 10:17:50 -0400 From: "Salz, Rich" To: "tls@ietf.org" Date: Wed, 3 Sep 2014 10:17:50 -0400 Thread-Topic: [TLS] tickets or sesssions or both (oh my) Thread-Index: Ac/Hf7I0Gv/WBbwrSXO5YyDVIF7DLgAAPbLw Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D12A96A31@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> <20140903140059.GW14392@mournblade.imrryr.org> In-Reply-To: <20140903140059.GW14392@mournblade.imrryr.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="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/R2XCAgnxV0KGR0c5WIYmVwtPMtk Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 14:17:53 -0000 > Fix implementation defects. I am not aware of *any* intrinsic defects in > tickets, and they solve a major scalability problem. I like tickets. I prefer the client to hold the state. Keeping PFS when a= single "server" is in fact multiple servers distributed globally, sometime= s in hostile countries, sometimes in racks that are owned by network operat= ors, brings issues to the table that are, perhaps, new to this group. =20 > This WG appears lately to be on a slash and burn campaign to reduce the > broad applicability of TLS to just usability for certain types of web ser= ver > deployments. This is troubling. I don't see that happening. Can you provide any examples? Complexity is p= roblematic, and people are looking for ways to reduce that. So far there ha= sn't been much action, just discussion; that seems right to me. And the big= gest discussion (client auth and renegotiation) was definitely about addres= sing concerns for OTHER than big web deployments. And even then, TLS 1.x i= sn't going away.=20 -- =20 Principal Security Engineer Akamai Technologies, Cambridge MA IM: rsalz@jabber.me Twitter: RichSalz From nobody Wed Sep 3 07:18:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 065FC1A033C for ; Wed, 3 Sep 2014 07:18:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXdJEBK0vWQl for ; Wed, 3 Sep 2014 07:18:55 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC711A032F for ; Wed, 3 Sep 2014 07:18:55 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id B849A47608; Wed, 3 Sep 2014 14:18:54 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id AA28B475E2; Wed, 3 Sep 2014 14:18:54 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub5.kendall.corp.akamai.com [172.27.105.21]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 83C8680048; Wed, 3 Sep 2014 14:18:54 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.218]) by USMA1EX-CASHUB5.kendall.corp.akamai.com ([172.27.105.21]) with mapi; Wed, 3 Sep 2014 10:18:53 -0400 From: "Salz, Rich" To: "Richard Fussenegger, BSc" , "tls@ietf.org" Date: Wed, 3 Sep 2014 10:18:53 -0400 Thread-Topic: [TLS] tickets or sesssions or both (oh my) Thread-Index: Ac/HgboOKC9xPSBrQ1ufX2PaeaJQXAAAC55g Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D12A96A35@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> <1408022371.42292099.1409744430634.JavaMail.zimbra@redhat.com> <412891267.42325154.1409748504518.JavaMail.zimbra@redhat.com> <20140903141149.GX14392@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C71D12A96A2D@USMBX1.msg.corp.akamai.com> <540721A6.4030006@fussenegger.info> In-Reply-To: <540721A6.4030006@fussenegger.info> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4xH1byYEohbXJZK6nazz4SBgWgA Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 14:18:57 -0000 > Could explain the exact problems to us? Let me know if my other note doesn't give enough explanation. -- =20 Principal Security Engineer Akamai Technologies, Cambridge MA IM: rsalz@jabber.me Twitter: RichSalz From nobody Wed Sep 3 07:20:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A86F1A0367 for ; Wed, 3 Sep 2014 07:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.596 X-Spam-Level: X-Spam-Status: No, score=-1.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RWIwhCdAXYcJ for ; Wed, 3 Sep 2014 07:20:33 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E55A1A035A for ; Wed, 3 Sep 2014 07:20:33 -0700 (PDT) Received: from mail-yh0-f48.google.com (mail-yh0-f48.google.com [209.85.213.48]) by mrelayeu.kundenserver.de (node=mreue104) with ESMTP (Nemesis) id 0MGi7V-1Xc5aJ2mAL-00DVou; Wed, 03 Sep 2014 16:20:31 +0200 Received: by mail-yh0-f48.google.com with SMTP id b6so5215072yha.7 for ; Wed, 03 Sep 2014 07:20:28 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.199.212 with SMTP id x60mr4593832yhn.127.1409754028623; Wed, 03 Sep 2014 07:20:28 -0700 (PDT) Received: by 10.170.129.17 with HTTP; Wed, 3 Sep 2014 07:20:28 -0700 (PDT) In-Reply-To: <20140903141149.GX14392@mournblade.imrryr.org> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> <1408022371.42292099.1409744430634.JavaMail.zimbra@redhat.com> <412891267.42325154.1409748504518.JavaMail.zimbra@redhat.com> <20140903141149.GX14392@mournblade.imrryr.org> Date: Wed, 3 Sep 2014 16:20:28 +0200 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=bcaec52c622318d132050229f006 X-Provags-ID: V02:K0:jyjlMEuxrT6FVWvdrvEFMqK283VI2jCeP4ulM3ckJw/ wzXMzG6qbd/XmgVnV7qcWXD2uFYya74W1F13fASiVq3Q3o+QL7 MeGjqwpxe+LtGyDzcuob1PIl0cIxMV8pV6G3chffKkLR2ZQsva 1BoFEJCc6pTUh1sfBRy1VSPvDJIjGAlH2B5ERg+6E9Y98L24nz zJ3Wq1L6Eu2PQev3TQ5TsBWZYlTwuIHoyf85jpy43+OC0zUpeb GbBZu9sOkW1ovnenRvb1b4X10jRHxsokrOnJlntcAIsIuoyAFW AdU8mnodF59Kg7w00vtIMzM3kPmfdcJXX/RrhdzWJNQN9vGGts WYb3bNktg8OUgg9K5xa+QI5O+J44+WC4R23XQ6j/ZBJrKt2MDG qTvtg0bgpKzU8oq866S8Gj1/v8VctghHwi9NXGkpXtDL7gwQdD dpOOM X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xlhwyBqP2yAqn_j_1OF9qvOJsAg Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 14:20:34 -0000 --bcaec52c622318d132050229f006 Content-Type: text/plain; charset=UTF-8 Viktor Dukhovni : The keys should NOT be static. Right. > The cluster can employ at any given > time two keys, one used to encrypt new sessions, the other used to > decrypted as yet unexpired older sessions. A new key is agreed > periodically, by the cluster nodes, and then used to encrypt new > sessions. This doesn't sound quite right, actually: generally, the new key must be ready everywhere to decrypt session tickets before the first server instance can actually start to use it to encrypt a session ticket. Bodo --bcaec52c622318d132050229f006 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Vikt= or Dukhovni <ietf-dane@dukhovni.org>:

The keys should NOT be static.

Right.
=C2=A0
The cluster can employ at any given
time two keys, one used to encrypt new sessions, the other used to
decrypted as yet unexpired older sessions.=C2=A0 A new key is agreed
periodically, by the cluster nodes, and then used to encrypt new
sessions.

This doesn't sound quite righ= t, actually: generally, the new key must be ready everywhere to decrypt ses= sion tickets before the first server instance can actually start to use it = to encrypt a session ticket.

Bodo

--bcaec52c622318d132050229f006-- From nobody Wed Sep 3 07:30:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCEE81A033C for ; Wed, 3 Sep 2014 07:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.27 X-Spam-Level: X-Spam-Status: No, score=-3.27 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsJOVZBXDxkh for ; Wed, 3 Sep 2014 07:30:01 -0700 (PDT) Received: from mx5-phx2.redhat.com (mx5-phx2.redhat.com [209.132.183.37]) by ietfa.amsl.com (Postfix) with ESMTP id 72AF01A031F for ; Wed, 3 Sep 2014 07:30:01 -0700 (PDT) Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx5-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s83EU0wU020960 for ; Wed, 3 Sep 2014 10:30:01 -0400 Date: Wed, 3 Sep 2014 10:30:00 -0400 (EDT) From: Hubert Kario To: tls@ietf.org Message-ID: <1243278676.42405953.1409754600887.JavaMail.zimbra@redhat.com> In-Reply-To: <20140903140059.GW14392@mournblade.imrryr.org> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> <20140903140059.GW14392@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.5.82.7] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922) Thread-Topic: tickets or sesssions or both (oh my) Thread-Index: HiF134xKQrfpAaxUYvYK5LO3EANGhA== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pNbywBZV20wbHB3W9HSWpL5Hdrg Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 14:30:08 -0000 ----- Original Message ----- > From: "Viktor Dukhovni" > To: tls@ietf.org > Sent: Wednesday, September 3, 2014 4:00:59 PM > Subject: Re: [TLS] tickets or sesssions or both (oh my) >=20 > On Wed, Sep 03, 2014 at 07:15:02AM -0400, Hubert Kario wrote: >=20 > > The one big feature of TLS 1.3 is PFS by default. It is hard to > > make tickets work with PFS, you need a synchronisation mechanism > > between servers one way or the other if you want to retain PFS. >=20 > Sorry, this seems rather non-obvious. How is stateless resumption > less compatible with PFS than stateful resumption? What is this > PFS obstacle you speak of. In Postfix PFS is on by default, as > are session tickets. Tickets are usually implemented as a session info (master secret) encrypted using a symmetric algorithm. If the symmetric algorithm key doesn't change, then the scalability is hige= r and ease of deployment is lower. You generate the ticket encryption key, copy it to all servers and you have scalability implemented, no need for servers to know about each other or have a common backend. If you want to retain PFS, you need to regenerate the keys on a semi-freque= nt basis (preferably less than 24h), which, from what I've been asking administrators around, few *know* about, let alone actually do. =20 > > You can do tickets and not do synchronisation, in effect destroying > > PFS efforts, >=20 > How so? And presumably one can do tickets and synchronize key > rotation (at lower cost than synchronizing session state). Because the ticket contains keys that can be used to decrypt communication. If the key used to encrypt the ticket is static, this key becomes the key to the kingdom. So while the PFS will appear to work (you get your ECDHE, keys regenerated for every new connection, etc.), the master secret will be encrypted always using the same key and conveniently exposed to attacker. > > while you can't do IDs without synchronisation, so making them > > PFS-retaining is relatively simple. >=20 > Why is there any interlock between PFS and who stores the state > for sessions? The client presents a ticket to the server, which > is used to recover the server's session state. This is no different > from recovering session state by any other means. If the session data is stored server side, then it is not exposed to the attacker, just a reference to it. So it doesn't need to be encrypted and because it needs to be stored on a low latency medium, it will be garbage collected relatively often, in effect, even server break will expose just most recent sessions, not all of them. > > If anything, I'd say that we should drop tickets entirely from > > TLS 1.3, as the implementations don't implement them in a way that > > preserves general properties of protocol. >=20 > Fix implementation defects. I am not aware of *any* intrinsic > defects in tickets, and they solve a major scalability problem. The whole idea behind the tickets is that every server in cluster has the key to the kingdom (past and future) so that it can decrypt any valid ticket presented by client. That is intrinsic problem with tickets-not-used-as-IDs. > This WG appears lately to be on a slash and burn campaign to reduce > the broad applicability of TLS to just usability for certain types > of web server deployments. This is troubling. This is applicable to all systems that can be clustered and can use session resumption. It applies just as much to SMTP as it does to HTTP. --=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email: hkario@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic From nobody Wed Sep 3 07:42:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B7961A0364 for ; Wed, 3 Sep 2014 07:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbHAlQ9Wabhx for ; Wed, 3 Sep 2014 07:42:42 -0700 (PDT) Received: from mx203.easyname.com (mx203.easyname.com [212.232.28.124]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0B661A036B for ; Wed, 3 Sep 2014 07:42:34 -0700 (PDT) Received: from 89-26-76-175.goll.dyn.salzburg-online.at ([89.26.76.175] helo=[192.168.0.11]) by mx.easyname.eu with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XPBlW-0005fw-5R for tls@ietf.org; Wed, 03 Sep 2014 16:42:33 +0200 Message-ID: <540728CE.6080305@fussenegger.info> Date: Wed, 03 Sep 2014 16:42:22 +0200 From: "Richard Fussenegger, BSc" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: tls@ietf.org References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> <20140903140059.GW14392@mournblade.imrryr.org> <1243278676.42405953.1409754600887.JavaMail.zimbra@redhat.com> In-Reply-To: <1243278676.42405953.1409754600887.JavaMail.zimbra@redhat.com> Content-Type: multipart/alternative; boundary="------------040901030104080906030903" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/CtrcV4BJFfkbyzIuDEPt0a34Qow Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 14:42:49 -0000 This is a multi-part message in MIME format. --------------040901030104080906030903 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit That's a very good explanation and perhaps admins should be more educated on this matter. But the problem here aren't the admins, the libraries are. They should take care to frequently rotate the keys like Twitter is doing it (by themselves): https://blog.twitter.com/2013/forward-secrecy-at-twitter It's really not that hard to implement, even for clusters as we an see from the Twitter example. Nginx is already offering key file support, but no rotation scheme for single installations. This means cluster support is given for people who know what they're doing. But the common admin is left alone in the dark, thinking PFS is working great (maybe even checked in with SSLLabs or something) and in reality it's not. This problem has to be fixed, but it's not a problem of the specs! I think (to add to Rich Salz's comment) that tickets are best suited for hostile servers. Because you can simply increase the rotation frequency and you only have a key for decryption. It's not said that you'll ever receive all those tickets from the clients afterwards. On the other hand with the sessions you'll have direct access to all those sessions. (Correct me if I'm wrong here.) Richard On 9/3/2014 4:30 PM, Hubert Kario wrote: > ----- Original Message ----- >> From: "Viktor Dukhovni" >> To: tls@ietf.org >> Sent: Wednesday, September 3, 2014 4:00:59 PM >> Subject: Re: [TLS] tickets or sesssions or both (oh my) >> >> On Wed, Sep 03, 2014 at 07:15:02AM -0400, Hubert Kario wrote: >> >>> The one big feature of TLS 1.3 is PFS by default. It is hard to >>> make tickets work with PFS, you need a synchronisation mechanism >>> between servers one way or the other if you want to retain PFS. >> Sorry, this seems rather non-obvious. How is stateless resumption >> less compatible with PFS than stateful resumption? What is this >> PFS obstacle you speak of. In Postfix PFS is on by default, as >> are session tickets. > Tickets are usually implemented as a session info (master secret) encrypted > using a symmetric algorithm. > > If the symmetric algorithm key doesn't change, then the scalability is higer > and ease of deployment is lower. You generate the ticket encryption key, > copy it to all servers and you have scalability implemented, no need for > servers to know about each other or have a common backend. > > If you want to retain PFS, you need to regenerate the keys on a semi-frequent > basis (preferably less than 24h), which, from what I've been asking > administrators around, few *know* about, let alone actually do. > >>> You can do tickets and not do synchronisation, in effect destroying >>> PFS efforts, >> How so? And presumably one can do tickets and synchronize key >> rotation (at lower cost than synchronizing session state). > Because the ticket contains keys that can be used to decrypt > communication. If the key used to encrypt the ticket is static, this key > becomes the key to the kingdom. > > So while the PFS will appear to work (you get your ECDHE, keys regenerated > for every new connection, etc.), the master secret will be encrypted always > using the same key and conveniently exposed to attacker. > >>> while you can't do IDs without synchronisation, so making them >>> PFS-retaining is relatively simple. >> Why is there any interlock between PFS and who stores the state >> for sessions? The client presents a ticket to the server, which >> is used to recover the server's session state. This is no different >> from recovering session state by any other means. > If the session data is stored server side, then it is not exposed > to the attacker, just a reference to it. So it doesn't need to be > encrypted and because it needs to be stored on a low latency > medium, it will be garbage collected relatively often, in effect, even > server break will expose just most recent sessions, not all of them. > >>> If anything, I'd say that we should drop tickets entirely from >>> TLS 1.3, as the implementations don't implement them in a way that >>> preserves general properties of protocol. >> Fix implementation defects. I am not aware of *any* intrinsic >> defects in tickets, and they solve a major scalability problem. > The whole idea behind the tickets is that every server in cluster has > the key to the kingdom (past and future) so that it can decrypt any > valid ticket presented by client. That is intrinsic problem with > tickets-not-used-as-IDs. > >> This WG appears lately to be on a slash and burn campaign to reduce >> the broad applicability of TLS to just usability for certain types >> of web server deployments. This is troubling. > This is applicable to all systems that can be clustered and can use > session resumption. It applies just as much to SMTP as it does to HTTP. > --------------040901030104080906030903 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit That's a very good explanation and perhaps admins should be more educated on this matter. But the problem here aren't the admins, the libraries are. They should take care to frequently rotate the keys like Twitter is doing it (by themselves):

https://blog.twitter.com/2013/forward-secrecy-at-twitter

It's really not that hard to implement, even for clusters as we an see from the Twitter example. Nginx is already offering key file support, but no rotation scheme for single installations. This means cluster support is given for people who know what they're doing. But the common admin is left alone in the dark, thinking PFS is working great (maybe even checked in with SSLLabs or something) and in reality it's not. This problem has to be fixed, but it's not a problem of the specs!

I think (to add to Rich Salz's comment) that tickets are best suited for hostile servers. Because you can simply increase the rotation frequency and you only have a key for decryption. It's not said that you'll ever receive all those tickets from the clients afterwards. On the other hand with the sessions you'll have direct access to all those sessions. (Correct me if I'm wrong here.)

Richard
On 9/3/2014 4:30 PM, Hubert Kario wrote:
----- Original Message -----

From: "Viktor Dukhovni" <ietf-dane@dukhovni.org>
To: tls@ietf.org
Sent: Wednesday, September 3, 2014 4:00:59 PM
Subject: Re: [TLS] tickets or sesssions or both (oh my)

On Wed, Sep 03, 2014 at 07:15:02AM -0400, Hubert Kario wrote:


The one big feature of TLS 1.3 is PFS by default. It is hard to
make tickets work with PFS, you need a synchronisation mechanism
between servers one way or the other if you want to retain PFS.

Sorry, this seems rather non-obvious.  How is stateless resumption
less compatible with PFS than stateful resumption?  What is this
PFS obstacle you speak of.  In Postfix PFS is on by default, as
are session tickets.

Tickets are usually implemented as a session info (master secret) encrypted
using a symmetric algorithm.

If the symmetric algorithm key doesn't change, then the scalability is higer
and ease of deployment is lower. You generate the ticket encryption key,
copy it to all servers and you have scalability implemented, no need for
servers to know about each other or have a common backend.

If you want to retain PFS, you need to regenerate the keys on a semi-frequent
basis (preferably less than 24h), which, from what I've been asking
administrators around, few *know* about, let alone actually do.
 

You can do tickets and not do synchronisation, in effect destroying
PFS efforts,

How so?  And presumably one can do tickets and synchronize key
rotation (at lower cost than synchronizing session state).

Because the ticket contains keys that can be used to decrypt
communication. If the key used to encrypt the ticket is static, this key
becomes the key to the kingdom.

So while the PFS will appear to work (you get your ECDHE, keys regenerated
for every new connection, etc.), the master secret will be encrypted always
using the same key and conveniently exposed to attacker.


while you can't do IDs without synchronisation, so making them
PFS-retaining is relatively simple.

Why is there any interlock between PFS and who stores the state
for sessions?  The client presents a ticket to the server, which
is used to recover the server's session state.   This is no different
from recovering session state by any other means.

If the session data is stored server side, then it is not exposed
to the attacker, just a reference to it. So it doesn't need to be
encrypted and because it needs to be stored on a low latency
medium, it will be garbage collected relatively often, in effect, even
server break will expose just most recent sessions, not all of them.


If anything, I'd say that we should drop tickets entirely from
TLS 1.3, as the implementations don't implement them in a way that
preserves general properties of protocol.

Fix implementation defects.  I am not aware of *any* intrinsic
defects in tickets, and they solve a major scalability problem.

The whole idea behind the tickets is that every server in cluster has
the key to the kingdom (past and future) so that it can decrypt any
valid ticket presented by client. That is intrinsic problem with
tickets-not-used-as-IDs.


This WG appears lately to be on a slash and burn campaign to reduce
the broad applicability of TLS to just usability for certain types
of web server deployments.  This is troubling.

This is applicable to all systems that can be clustered and can use
session resumption. It applies just as much to SMTP as it does to HTTP.

--------------040901030104080906030903-- From nobody Wed Sep 3 07:52:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A79CE1A0406 for ; Wed, 3 Sep 2014 07:52:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.397 X-Spam-Level: X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yzQ2uRlBEu2d for ; Wed, 3 Sep 2014 07:52:17 -0700 (PDT) Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3B5E1A6EF4 for ; Wed, 3 Sep 2014 07:51:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=UUIPucEPl7Og5Kkalg6mUSjD45KHdk/W1ge5jNkBwCE=; b=F83kOAcHqFOGYDalkcQ6N3VpvIY2vJbK0RXyBGamP6nDB8lYJBwhg3oaTxHZ4cQbPG4KKaI3k4pcISgrnUxSQSJye1IN88TFHA6mje1VfKgEQ4UIzwOso4AdMqtEWkTGvaiCXAXVHcQQEyXk/jjd+U5F0PXyXXKsqp2Z2Ct5LhM=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XPBtl-0000xM-J1; Wed, 03 Sep 2014 16:51:01 +0200 Message-ID: <54072AD2.6070705@polarssl.org> Date: Wed, 03 Sep 2014 16:50:58 +0200 From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Salz, Rich" , "tls@ietf.org" References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> <1408022371.42292099.1409744430634.JavaMail.zimbra@redhat.com> <412891267.42325154.1409748504518.JavaMail.zimbra@redhat.com> <20140903141149.GX14392@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C71D12A96A2D@USMBX1.msg.corp.akamai.com> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D12A96A2D@USMBX1.msg.corp.akamai.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.offspark.com) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eJSspT3YH5vVUR1VhSmXCGB4aP8 Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 14:52:19 -0000 On 03/09/2014 16:15, Salz, Rich wrote: >> Postfix already does this on the scale of hundreds of separate processes >> running on a single machine, extending this to multiple nodes is not a big >> deal. > > Okay, thanks, we're done here. No offense, but you don't know what you are > talking about. > I don't have any experience with large scale deployments, but it seems to me that sharing and syncing regularly rotated keys among nodes should not be harder than sharing a large cache of sessions, maybe even easier due to the smaller size of the data to share. With the experience you have, would you agree with this? If not, for my own education, I'd be curious to know why. It seems to me the main problem with tickets is that they are easier to deploy in a way that destroys PFS than to deploy in a way that preserves it. Being easier to deploy in an insecure way that will appear to "work" just fine is obviously an undesirable property. Just to be clear, I'm not saying this is a sufficient reason to drop session tickets, my humble opinion is they bring more good than potential issues. But if we want to be serious about PFS in TLS 1.3, what's currently 5.5 of RFC 5077 should probably be expanded, and the wording made stronger (eg "keys MUST be changed regularly"). Manuel. From nobody Wed Sep 3 07:57:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81ABD1A6F0D for ; Wed, 3 Sep 2014 07:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kl3EI9vy7T4m for ; Wed, 3 Sep 2014 07:57:08 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C492F1A0AD1 for ; Wed, 3 Sep 2014 07:55:54 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 232812AB2AA; Wed, 3 Sep 2014 14:55:54 +0000 (UTC) Date: Wed, 3 Sep 2014 14:55:54 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140903145553.GA14392@mournblade.imrryr.org> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> <20140903140059.GW14392@mournblade.imrryr.org> <1243278676.42405953.1409754600887.JavaMail.zimbra@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1243278676.42405953.1409754600887.JavaMail.zimbra@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DzVbI32q-usWWJ2tClThmpy-F94 Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@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: Wed, 03 Sep 2014 14:57:12 -0000 On Wed, Sep 03, 2014 at 10:30:00AM -0400, Hubert Kario wrote: > Tickets are usually implemented as a session info (master secret) encrypted > using a symmetric algorithm. > > If the symmetric algorithm key doesn't change, then the scalability is higer > and ease of deployment is lower. If the key is never changed, the implementation is flawed. This is not a TLS problem. > You generate the ticket encryption key, copy it to all servers and you > have scalability implemented, no need for servers to know about each > other or have a common backend. This is a poor server design. Not a TLS problem. > If you want to retain PFS, you need to regenerate the keys on a semi-frequent > basis (preferably less than 24h), Postfix rotates keys hourly by default, with two keys present at any time, the new encryption-and-decryption key plus old decryption-only key. The keys are managed by a shared back-end service, which holds them in memory, "cluster" nodes (smtpd processes) obtain the key from the back-end service on a cache lookup miss. To extend this to multiple nodes, just add authentication between the cluster node and the back-end service, and replicate the back-end service. > which, from what I've been asking > administrators around, few *know* about, let alone actually do. We need to provide them with better tools, not cripple TLS. > > How so? And presumably one can do tickets and synchronize key > > rotation (at lower cost than synchronizing session state). > > Because the ticket contains keys that can be used to decrypt > communication. If the key used to encrypt the ticket is static, this key > becomes the key to the kingdom. Not a TLS problem. The key should not be static. There are existing deployments in which keys are not static. > So while the PFS will appear to work (you get your ECDHE, keys regenerated > for every new connection, etc.), the master secret will be encrypted always > using the same key and conveniently exposed to attacker. Not a TLS problem. That's a problem for the vendors providing cluster HTTPS servers. This is an nginx, Apache, F5, ... problem. Write blogs exposing their negligence until they fix their problem. > If the session data is stored server side, then it is not exposed > to the attacker, just a reference to it. So it doesn't need to be > encrypted and because it needs to be stored on a low latency > medium, it will be garbage collected relatively often, in effect, even > server break will expose just most recent sessions, not all of them. With tickets, the same text applies to the session ticket keys, with s/session data/session ticket keys/g. The problem is lame implementations of session ticket with static keys. That's not a TLS problem. Let's solve the right problem. > > > Fix implementation defects. I am not aware of *any* intrinsic > > defects in tickets, and they solve a major scalability problem. > > The whole idea behind the tickets is that every server in cluster has > the key to the kingdom (past and future) so that it can decrypt any > valid ticket presented by client. That is intrinsic problem with > tickets-not-used-as-IDs. No, not "the key", rather "a current key", just as with "an unexpired session". With Postfix the lifetime (for encrypting) of session ticket keys is equal to the session lifetime, it then is retained that long again for decrypting older sessions while the new encryption key is young. This simplifies securing session data, because the session data need never hit a vulnerable shared store and the keys are only ever in memory. > > This WG appears lately to be on a slash and burn campaign to reduce > > the broad applicability of TLS to just usability for certain types > > of web server deployments. This is troubling. > > This is applicable to all systems that can be clustered and can use > session resumption. It applies just as much to SMTP as it does to HTTP. And yet, it does not apply to Postfix, where ticket key management is done right. -- Viktor. From nobody Wed Sep 3 08:00:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 806621A6F87 for ; Wed, 3 Sep 2014 08:00:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5utayOsmR5j for ; Wed, 3 Sep 2014 08:00:27 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E10E91A03F0 for ; Wed, 3 Sep 2014 07:59:45 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 1C8382AB2AA; Wed, 3 Sep 2014 14:59:45 +0000 (UTC) Date: Wed, 3 Sep 2014 14:59:45 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140903145944.GB14392@mournblade.imrryr.org> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> <1408022371.42292099.1409744430634.JavaMail.zimbra@redhat.com> <412891267.42325154.1409748504518.JavaMail.zimbra@redhat.com> <20140903141149.GX14392@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xhuTlaipKFULwZIE75upXz0xvcM Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@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: Wed, 03 Sep 2014 15:00:29 -0000 On Wed, Sep 03, 2014 at 04:20:28PM +0200, Bodo Moeller wrote: > > The cluster can employ at any given > > time two keys, one used to encrypt new sessions, the other used to > > decrypted as yet unexpired older sessions. A new key is agreed > > periodically, by the cluster nodes, and then used to encrypt new > > sessions. > > This doesn't sound quite right, actually: generally, the new key must be > ready everywhere to decrypt session tickets before the first server > instance can actually start to use it to encrypt a session ticket. Depends on the design, session tickets carry 16 byte key ids, and a cache-miss protocol can be used to fetch a key not yet present on a node, but there also other ways to do this. What I described works for a cluster of processes in Postfix, so it is not wrong, it is just simpler than a multi-node cluster, because authorization of key lookups is via unix-domain socket permissions, rather than something more complex. -- Viktor. From nobody Wed Sep 3 08:01:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3791A036E for ; Wed, 3 Sep 2014 08:01:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jK9Sh5ceVcm0 for ; Wed, 3 Sep 2014 08:01:36 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 059AF1A0378 for ; Wed, 3 Sep 2014 08:00:57 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 722EB2AB2AA; Wed, 3 Sep 2014 15:00:56 +0000 (UTC) Date: Wed, 3 Sep 2014 15:00:56 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140903150056.GC14392@mournblade.imrryr.org> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> <1408022371.42292099.1409744430634.JavaMail.zimbra@redhat.com> <412891267.42325154.1409748504518.JavaMail.zimbra@redhat.com> <20140903141149.GX14392@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C71D12A96A2D@USMBX1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D12A96A2D@USMBX1.msg.corp.akamai.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ig1lfJvLVqlyHDE1_dsr1GGKnqc Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@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: Wed, 03 Sep 2014 15:01:39 -0000 On Wed, Sep 03, 2014 at 10:15:13AM -0400, Salz, Rich wrote: > > Postfix already does this on the scale of hundreds of separate processes > > running on a single machine, extending this to multiple nodes is not a big > > deal. > > Okay, thanks, we're done here. No offense, but you don't know > what you are talking about. Or perhaps you don't know what I know. That kind of feedback is not appropriate on IETF lists I believe. -- Viktor. From nobody Wed Sep 3 08:09:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4740D1A6F84 for ; Wed, 3 Sep 2014 08:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.397 X-Spam-Level: X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M_ELoMArqNnB for ; Wed, 3 Sep 2014 08:09:10 -0700 (PDT) Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E3B51A8A7D for ; Wed, 3 Sep 2014 08:04:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=vCvRSXq79+w8ZgWkeIa5qIU0OAgXod4WnYiUN++xqtY=; b=I57z5DWZXJIHVN2rjhBgUh/adv2r+yYBVVO7dy6fnRSz9oJGa3heEIyu1w60/zzZkyk/C3Vz1FsXGd4LFpFGaWzVa2l7zJB7LxmTvKFueAXYlQ/43Efr8SYfBGIyI/aMmkbT4CgjUD0gDTnKmTtZEiEHjib0JLjzYpiCRCEi+yw=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XPC72-00013V-Gb; Wed, 03 Sep 2014 17:04:44 +0200 Message-ID: <54072E09.9010405@polarssl.org> Date: Wed, 03 Sep 2014 17:04:41 +0200 From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Bodo Moeller , "tls@ietf.org" References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <5406D275.3010101@polarssl.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.offspark.com) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OI9XDDz9RK2729_pQzuwKDKIdDE Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 15:09:11 -0000 On 03/09/2014 13:02, Bodo Moeller wrote: > It is useful to have *a* mechanism to explicitly confirm session resumption > so that the client already knows what to expect after having seen the > ServerHello, but I don't see a good reason to continue to overload > ClientHello.session_id and ServerHello.session_id with this particular > hack. Agreed. > If we remove the traditional semantics of ClientHello.session_id and > ServerHello.session_id for the new protocol version, an always-empty > ClientHello.session_id and a simple magic value in ServerHello.session_id > confirming session resumption would do: having the client send a made-up > session ID only adds overhead. (The reason to make use of > ServerHello.session_id for the proposed magic value is that the field is > already specified, and is related to session resumption; in principle, the > signal could go elsewhere in the ServerHello message.) > Another good place for that might be the SessionTicket extension in the ServerHello. (That would mean changing its current meaning obviously.) > I'm guessing that the thinking underlying the specified use of the > session_id fields in RFC 5077 is that this makes it easier for both ways of > handling sessions to coexist (although based on code I've had to fix, I'm > not sure that it succeeded). If traditional session IDs are no longer used > (because even stateful session resumption can use "session ticket" > mechanisms on the wire instead), that's no longer an issue. > I agree with that. Manuel. From nobody Wed Sep 3 08:19:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4A31A8795 for ; Wed, 3 Sep 2014 08:18:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.104 X-Spam-Level: * X-Spam-Status: No, score=1.104 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z-nCmrM5AA2P for ; Wed, 3 Sep 2014 08:18:58 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C69A11A8791 for ; Wed, 3 Sep 2014 08:12:26 -0700 (PDT) Received: from mail-yk0-f170.google.com (mail-yk0-f170.google.com [209.85.160.170]) by mrelayeu.kundenserver.de (node=mreue102) with ESMTP (Nemesis) id 0MduOr-1Xm5jW391J-00PgcM; Wed, 03 Sep 2014 17:12:24 +0200 Received: by mail-yk0-f170.google.com with SMTP id 142so5132074ykq.1 for ; Wed, 03 Sep 2014 08:12:22 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.87.100 with SMTP id x64mr62564427yhe.47.1409757142485; Wed, 03 Sep 2014 08:12:22 -0700 (PDT) Received: by 10.170.129.17 with HTTP; Wed, 3 Sep 2014 08:12:22 -0700 (PDT) In-Reply-To: <54072E09.9010405@polarssl.org> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <5406D275.3010101@polarssl.org> <54072E09.9010405@polarssl.org> Date: Wed, 3 Sep 2014 17:12:22 +0200 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=20cf300fb4f9b294ac05022aa9aa X-Provags-ID: V02:K0:+cCkpV88wCkuor0rduHs2WuuNGn7LGeC29sJkdmDJlu G0w8WsBoJP878WcBgv6QDVdBhcX4iNICAAgJ+5vfzdpB2TT8rc eQ1uL4gLCUmtggHPC6GETCY5PQEN/4EYemulJerPGuepbnjSMq q37sCjuCINUMjslUGmkUoJYREfgvdjKwz/c0ccCV3kHf2pQBeP 2w5OBPGMzb0EltXehu54IfT2g+xlIO4fUw7UCcNO9OuAylcu1O qWwtM45Rs3aRfHGy6DN1gaqcnqoqEGOlsu/Q1AsuPHrIY9m50C uwDhulBjVuN3WSw8+/UBz30FVAa3GdpEJsWT5YsPqTnz/NK63l szNMw5klgsDWjqbvZk1dp2Ild8i4dALu9VLiKO8fb372qUJdKo jdQxLCoZl0bbJiJgMsZvCs5MoJvfV6kpYTRefIpaQjvnwgwVcB gDSr4 X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ro_AhvMuA-21u9pqLHNVvMxIwPo Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 15:18:59 -0000 --20cf300fb4f9b294ac05022aa9aa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Manuel P=C3=A9gouri=C3=A9-Gonnard : > > If we remove the traditional semantics of ClientHello.session_id and > > ServerHello.session_id for the new protocol version, an always-empty > > ClientHello.session_id and a simple magic value in ServerHello.session_= id > > confirming session resumption would do: having the client send a made-u= p > > session ID only adds overhead. (The reason to make use of > > ServerHello.session_id for the proposed magic value is that the field i= s > > already specified, and is related to session resumption; in principle, > the > > signal could go elsewhere in the ServerHello message.) > > Another good place for that might be the SessionTicket extension in the > ServerHello. (That would mean changing its current meaning obviously.) Right, that was the specific other location within the ServerHello that I'd been thinking of :-) [However, if we're willing to make changes to the server's use of the SessionTicket extension, I think I'd instead argue in favor of omitting it entirely with the new protocol version, on the grounds that with the proposed protocol change, *all* servers would be required to support the protocol mechanism: Thus, there's no need to negotiate it explicitly. Similarly, the client's SessionTicket extension could be omitted if it's empty, except as required for backwards compatibility with earlier protocol versions.] Bodo --20cf300fb4f9b294ac05022aa9aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Manu= el P=C3=A9gouri=C3=A9-Gonnard <mpg@polarssl.org>:
=C2= =A0
> If we remove the traditional semantics of ClientHello.session_id and > ServerHello.session_id for the new protocol version, an always-empty > ClientHello.session_id and a simple magic value in ServerHello.session= _id
> confirming session resumption would do: having the client send a made-= up
> session ID only adds overhead. (The reason to make use of
> ServerHello.session_id for the proposed magic value is that the field = is
> already specified, and is related to session resumption; in principle,= the
> signal could go elsewhere in the ServerHello message.)
=C2=A0
Another good place for that might be the SessionTicket extension in t= he
ServerHello. (That would mean changing its current meaning obviously.)

Right, that was the specific other location wit= hin the ServerHello that I'd been thinking of :-)

[However, if we're willing to make changes to the server's use= of the SessionTicket extension, I think I'd instead argue in favor of = omitting it entirely with the new protocol version, on the grounds that wit= h the proposed protocol change, *all* servers would be required to support = the protocol mechanism: Thus, there's no need to negotiate it explicitl= y. Similarly, the client's SessionTicket extension could be omitted if = it's empty, except as required for backwards compatibility with earlier= protocol versions.]

Bodo


--20cf300fb4f9b294ac05022aa9aa-- From nobody Wed Sep 3 09:06:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93FB71A036F for ; Wed, 3 Sep 2014 09:06:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.27 X-Spam-Level: X-Spam-Status: No, score=-3.27 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YH9N0u0CRcfs for ; Wed, 3 Sep 2014 09:06:31 -0700 (PDT) Received: from mx6-phx2.redhat.com (mx6-phx2.redhat.com [209.132.183.39]) by ietfa.amsl.com (Postfix) with ESMTP id D767F1A035D for ; Wed, 3 Sep 2014 09:06:31 -0700 (PDT) Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx6-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s83G6Vtu014814 for ; Wed, 3 Sep 2014 12:06:31 -0400 Date: Wed, 3 Sep 2014 12:06:30 -0400 (EDT) From: Hubert Kario To: tls@ietf.org Message-ID: <855346194.42619687.1409760390854.JavaMail.zimbra@redhat.com> In-Reply-To: <20140903145553.GA14392@mournblade.imrryr.org> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> <20140903140059.GW14392@mournblade.imrryr.org> <1243278676.42405953.1409754600887.JavaMail.zimbra@redhat.com> <20140903145553.GA14392@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.5.82.7] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922) Thread-Topic: tickets or sesssions or both (oh my) Thread-Index: 9HdmQJ9/Rmp3v1y5XFNf5fTqCZHo1g== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8GspM49dwe7e7o6mb8OKzEuq4KY Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 16:06:33 -0000 ----- Original Message ----- > From: "Viktor Dukhovni" > To: tls@ietf.org > Sent: Wednesday, September 3, 2014 4:55:54 PM > Subject: Re: [TLS] tickets or sesssions or both (oh my) >=20 > On Wed, Sep 03, 2014 at 10:30:00AM -0400, Hubert Kario wrote: >=20 > > Tickets are usually implemented as a session info (master secret) encry= pted > > using a symmetric algorithm. > > > > If the symmetric algorithm key doesn't change, then the scalability is > > higer > > and ease of deployment is lower. >=20 > If the key is never changed, the implementation is flawed. This > is not a TLS problem. Protocol that is easy to get wrong *is* a bad protocol and it is a fault with protocol. For now, TLS 1.3 + session tickets ranks at 9 or 10 (at best) and realistically at 14 on Rusty's scale of good design[1], while ID's are at l= evel 5: 1 - https://lkml.org/lkml/2007/6/10/99 For a protocol that peoples lives will depend on it is not good enough. Session resumption is an optional functionality, and yet we're ready to forfeit PFS just for ease of implementation of it for big deployments. if you have a deployment big enough that scaling of memcached (or similar databases) becomes an issue, you certainly have load balancers and as such, can segregate users based on their session id's to specific "sub cluster" that can actually resume their session. On the the other hand static keys for tickets can impact the smallest deplo= yments. > > So while the PFS will appear to work (you get your ECDHE, keys regenera= ted > > for every new connection, etc.), the master secret will be encrypted al= ways > > using the same key and conveniently exposed to attacker. >=20 > Not a TLS problem. That's a problem for the vendors providing > cluster HTTPS servers. This is an nginx, Apache, F5, ... problem. > Write blogs exposing their negligence until they fix their problem. the problem is, that as a user, I can't detect if they do the right thing or not, the ticket is an opaque blob I have no way of knowing if they rotate keys or not (doubly so if the implementation saves time in ticket and refuses to resume old sessions, not because the key changed). --=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email: hkario@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic From nobody Wed Sep 3 09:11:44 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6F231A8A55 for ; Wed, 3 Sep 2014 09:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.867 X-Spam-Level: X-Spam-Status: No, score=-4.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9QjBvqkWUEjq for ; Wed, 3 Sep 2014 09:11:32 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id EB9421A882F for ; Wed, 3 Sep 2014 09:11:26 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s83GAntd024048; Wed, 3 Sep 2014 12:11:07 -0400 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: "Blumenthal, Uri - 0558 - MITLL" In-Reply-To: Date: Wed, 3 Sep 2014 12:10:47 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <3EB754B7-F6B2-4207-A2F0-E61F32EE1E40@ll.mit.edu> References: <54048985.1020005@net.in.tum.de> To: Yutaka OIWA X-Mailer: Apple Mail (2.1510) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.27, 0.0.0000 definitions=2014-09-03_07:2014-09-03,2014-09-03,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-1402240000 definitions=main-1409030169 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5mAbUXtEwE2ZXFkd0_FNV4--ZK8 Cc: tls@ietf.org Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 16:11:36 -0000 On Sep 3, 2014, at 06:34 , Yutaka OIWA wrote: > The document title is > "Recommendations for Secure Use of TLS and DTLS", > clearly applicable for the "Secure Uses". It also says > "These are minimum recommendations for the general use of TLS." ^^^^^^^^ Exactly. > For the purposes of such secure and general use cases, > NULL ciphers are clearly "MUST NOT" with no doubt. "Clearly" and "with no doubt"? With respect, this doesn't seem to be = your field of expertise. > If you have any "insecure", special (non-general) use cases of TLS, > the document do not forbid you to use it, > because the document is simply not applicable. > However, such special use cases shall not make any > hindrance for making a BCP document for general use cases. There can be no generic "secure" (or "insecure") - only "secure = regarding ...".=20 One implication is that unless threat to data confidentiality is a = concern, trying to make the data-in-transit confidential would be a = waste of resources and time. Not to mention that some admin domains = restrict the right to keep the data confidential.=20 Others made it clear that (a) it should be stated that NULL cipher = SHOULD NOT be enabled (by default, at least), but (b) it must not be = listed "MUST NOT". People would simply disregard (and justly so!) a = document that places such silly and unrealistic demands. I'm skipping the rest, as it doesn't seem that it needs an answer. From nobody Wed Sep 3 09:22:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A26CA1A0043 for ; Wed, 3 Sep 2014 09:22:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.269 X-Spam-Level: X-Spam-Status: No, score=-3.269 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gHDiZJL2PK-p for ; Wed, 3 Sep 2014 09:22:38 -0700 (PDT) Received: from mx5-phx2.redhat.com (mx5-phx2.redhat.com [209.132.183.37]) by ietfa.amsl.com (Postfix) with ESMTP id EE4B71A0167 for ; Wed, 3 Sep 2014 09:22:12 -0700 (PDT) Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx5-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s83GLxul014626; Wed, 3 Sep 2014 12:21:59 -0400 Date: Wed, 3 Sep 2014 12:21:58 -0400 (EDT) From: Hubert Kario To: "Richard Fussenegger, BSc" Message-ID: <1589581250.42632708.1409761318984.JavaMail.zimbra@redhat.com> In-Reply-To: <540728CE.6080305@fussenegger.info> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> <20140903140059.GW14392@mournblade.imrryr.org> <1243278676.42405953.1409754600887.JavaMail.zimbra@redhat.com> <540728CE.6080305@fussenegger.info> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_42632707_60275741.1409761318982" X-Originating-IP: [10.5.82.7] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922) Thread-Topic: tickets or sesssions or both (oh my) Thread-Index: QtnLj/oC9pl0JwGMuQHemTRdbT4NXw== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/a_JkekiGmwbzj-wI6gtkQ9bCpdI Cc: tls@ietf.org Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 16:22:42 -0000 ------=_Part_42632707_60275741.1409761318982 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Richard Fussenegger, BSc" > To: tls@ietf.org > Sent: Wednesday, September 3, 2014 4:42:22 PM > Subject: Re: [TLS] tickets or sesssions or both (oh my) > That's a very good explanation and perhaps admins should be more educated= on > this matter. But the problem here aren't the admins, the libraries are. T= hey > should take care to frequently rotate the keys like Twitter is doing it (= by > themselves): > https://blog.twitter.com/2013/forward-secrecy-at-twitter > It's really not that hard to implement, even for clusters as we an see fr= om > the Twitter example. Nginx is already offering key file support, but no > rotation scheme for single installations. This means cluster support is > given for people who know what they're doing. But the common admin is lef= t > alone in the dark, thinking PFS is working great (maybe even checked in w= ith > SSLLabs or something) and in reality it's not. This problem has to be fix= ed, > but it's not a problem of the specs! I'd love for the admins to be better educated, but considering that around = 0.5% of servers still are vulnerable to Hearbleed (over 700 machines verifi= ed), 7% vulnerable to the CCS issue (CVE-2014-0224), 20% of servers still e= nable SSLv2[1], over 3% enabling AECDH and 17% enabling single DES cipher s= uites[2], hoping for admins to do the right thing is bad idea. Many of them= will get it wrong as they have shown time and time again.=20 The point is that getting ID's correct is easy, getting tickets correct is = not obvious (most people won't even know there *is* a problem in the first = place) and requires "superfluous" code.=20 > I think (to add to Rich Salz's comment) that tickets are best suited for > hostile servers. Because you can simply increase the rotation frequency a= nd > you only have a key for decryption. It's not said that you'll ever receiv= e > all those tickets from the clients afterwards. On the other hand with the > sessions you'll have direct access to all those sessions. (Correct me if = I'm > wrong here.) If the remote server is compromised, how distributing "just" decryption key= s to it is not a problem from PFS point of view? This one server will have = the keys to the kingdom, even if they change often, they will allow you to = decrypt all communication to other servers from the point of compromise onw= ard. With IDs the server will start misbehaving (asking for more IDs than c= onnections, asking for all IDs, asking for IDs of connections that got term= inated some place else), with tickets, it will be invisible.=20 1 - https://www.trustworthyinternet.org/ssl-pulse/=20 2 - https://securitypitfalls.wordpress.com/2014/08/25/august-2014-scan-resu= lts/=20 --=20 Regards,=20 Hubert Kario=20 Quality Engineer, QE BaseOS Security team=20 Email: hkario@redhat.com=20 Web: www.cz.redhat.com=20 Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic=20 ------=_Part_42632707_60275741.1409761318982 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Fr= om: "Richard Fussenegger, BSc" <richard@fussenegger.info>
T= o: tls@ietf.org
Sent: Wednesday, September 3, 2014 4:42:22 PM=
Subject: Re: [TLS] tickets or sesssions or both (oh my)
=
That's a very good explanation and perhaps admins should be more educated on this matter. But the problem here aren't the admins, the libraries are. They should take care to frequently rotate the keys like Twitter is doing it (by themselves):

https://blog.twitter.com/= 2013/forward-secrecy-at-twitter

It's really not that hard to implement, even for clusters as we an see from the Twitter example. Nginx is already offering key file support, but no rotation scheme for single installations. This means cluster support is given for people who know what they're doing. But the common admin is left alone in the dark, thinking PFS is working great (maybe even checked in with SSLLabs or something) and in reality it's not. This problem has to be fixed, but it's not a problem of the specs!

I'd love for the admins to be better educated, but considering = that around 0.5% of servers still are vulnerable to Hearbleed (over 700 mac= hines verified), 7% vulnerable to the CCS issue (CVE-2014-0224), 20% of ser= vers still enable SSLv2[1], over 3% enabling AECDH and 17% enabling single = DES cipher suites[2], hoping for admins to do the right thing is bad idea. = Many of them will get it wrong as they have shown time and time again.

The point is that getting ID's correct is easy, getting tic= kets correct is not obvious (most people won't even know there *is* a probl= em in the first place) and requires "superfluous" code.


= I think (to add to Rich Salz's comment) that tickets are best suited for hostile servers. Because you can simply increase the rotation frequency and you only have a key for decryption. It's not said that you'll ever receive all those tickets from the clients afterwards. On the other hand with the sessions you'll have direct access to all those sessions. (Correct me if I'm wrong here.)

If the remote server is = compromised, how distributing "just" decryption keys to it is not a problem= from PFS point of view? This one server will have the keys to the kingdom,= even if they change often, they will allow you to decrypt all communicatio= n to other servers from the point of compromise onward. With IDs the server= will start misbehaving (asking for more IDs than connections, asking for a= ll IDs, asking for IDs of connections that got terminated some place else),= with tickets, it will be invisible.


 1 - https://www.tr= ustworthyinternet.org/ssl-pulse/
 2 = - https://securitypitfalls.wordpress.com/20= 14/08/25/august-2014-scan-results/
<= div>

--
= Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security tea= m
Email: hkario@redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.= r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic
------=_Part_42632707_60275741.1409761318982-- From nobody Wed Sep 3 09:40:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C1DC1A00B6 for ; Wed, 3 Sep 2014 09:40:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8OhLk4jkEYO for ; Wed, 3 Sep 2014 09:40:02 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27BBB1A0180 for ; Wed, 3 Sep 2014 09:39:51 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 511EA2AB2B7; Wed, 3 Sep 2014 16:39:49 +0000 (UTC) Date: Wed, 3 Sep 2014 16:39:49 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140903163948.GE14392@mournblade.imrryr.org> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> <20140903140059.GW14392@mournblade.imrryr.org> <1243278676.42405953.1409754600887.JavaMail.zimbra@redhat.com> <540728CE.6080305@fussenegger.info> <1589581250.42632708.1409761318984.JavaMail.zimbra@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1589581250.42632708.1409761318984.JavaMail.zimbra@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UkuvaGkPKg_5G_MmeROVCfTgtho Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@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: Wed, 03 Sep 2014 16:40:08 -0000 On Wed, Sep 03, 2014 at 12:21:58PM -0400, Hubert Kario wrote: > The point is that getting ID's correct is easy, getting tickets > correct is not obvious (most people won't even know there *is* a > problem in the first place) and requires "superfluous" code. In any cluster, sharing of keys and sharing of sessions are identical problems. The fact that some implementations have been sloppy in support for session tickets is solely a problem of those implementations. They probably don't have a shared backing store for sessions either. This is a poorly designed cluster. This problem has solutions, and session tickets avoid potential for all too easy denial of service on server-side session caches. Please do not cripple TLS. I don't want to have to disable TLSv1.3 support when TLSv1.3 appears. Session tickets do not compromise PFS. Many servers are not clustered, and work much better with session tickets than with a memory resident session cache. Please do not cripple TLS. That's all I have to say on this thread. Thanks for the bandwidth. -- Viktor. From nobody Wed Sep 3 09:47:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D2D91A0250 for ; Wed, 3 Sep 2014 09:47:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TCLlf13mjk98 for ; Wed, 3 Sep 2014 09:47:28 -0700 (PDT) Received: from mx203.easyname.com (mx203.easyname.com [212.232.28.124]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F7981A0125 for ; Wed, 3 Sep 2014 09:47:25 -0700 (PDT) Received: from 89-26-76-175.goll.dyn.salzburg-online.at ([89.26.76.175] helo=[192.168.0.11]) by mx.easyname.eu with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XPDiK-0001f7-Bv; Wed, 03 Sep 2014 18:47:23 +0200 Message-ID: <5407460F.1030707@fussenegger.info> Date: Wed, 03 Sep 2014 18:47:11 +0200 From: "Richard Fussenegger, BSc" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Hubert Kario References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> <20140903140059.GW14392@mournblade.imrryr.org> <1243278676.42405953.1409754600887.JavaMail.zimbra@redhat.com> <540728CE.6080305@fussenegger.info> <1589581250.42632708.1409761318984.JavaMail.zimbra@redhat.com> In-Reply-To: <1589581250.42632708.1409761318984.JavaMail.zimbra@redhat.com> Content-Type: multipart/alternative; boundary="------------080508070603050801070907" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZA7SiL9Zz-VWvjaV0UJGjlNJcs8 Cc: tls@ietf.org Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 16:47:32 -0000 This is a multi-part message in MIME format. --------------080508070603050801070907 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 9/3/2014 6:21 PM, Hubert Kario wrote: > > ------------------------------------------------------------------------ > > *From: *"Richard Fussenegger, BSc" > *To: *tls@ietf.org > *Sent: *Wednesday, September 3, 2014 4:42:22 PM > *Subject: *Re: [TLS] tickets or sesssions or both (oh my) > > That's a very good explanation and perhaps admins should be more > educated on this matter. But the problem here aren't the admins, > the libraries are. They should take care to frequently rotate the > keys like Twitter is doing it (by themselves): > > https://blog.twitter.com/2013/forward-secrecy-at-twitter > > It's really not that hard to implement, even for clusters as we an > see from the Twitter example. Nginx is already offering key file > support, but no rotation scheme for single installations. This > means cluster support is given for people who know what they're > doing. But the common admin is left alone in the dark, thinking > PFS is working great (maybe even checked in with SSLLabs or > something) and in reality it's not. This problem has to be fixed, > but it's not a problem of the specs! > > > I'd love for the admins to be better educated, but considering that > around 0.5% of servers still are vulnerable to Hearbleed (over 700 > machines verified), 7% vulnerable to the CCS issue (CVE-2014-0224), > 20% of servers still enable SSLv2[1], over 3% enabling AECDH and 17% > enabling single DES cipher suites[2], hoping for admins to do the > right thing is bad idea. Many of them will get it wrong as they have > shown time and time again. > > The point is that getting ID's correct is easy, getting tickets > correct is not obvious (most people won't even know there *is* a > problem in the first place) and requires "superfluous" code. > My point was that the admins aren't the people who are responsible for the defect, the library and software developers are. But they are ignoring it, even if tickets are created were users ask them to fix it. In case of nginx it's even more problematic because they have the flawed tickets activated by default. The burden to either configure them correctly (by e.g. restarting the server on a regular basis *hack*) or disable tickets is up to the admins. > > I think (to add to Rich Salz's comment) that tickets are best > suited for hostile servers. Because you can simply increase the > rotation frequency and you only have a key for decryption. It's > not said that you'll ever receive all those tickets from the > clients afterwards. On the other hand with the sessions you'll > have direct access to all those sessions. (Correct me if I'm wrong > here.) > > > If the remote server is compromised, how distributing "just" > decryption keys to it is not a problem from PFS point of view? This > one server will have the keys to the kingdom, even if they change > often, they will allow you to decrypt all communication to other > servers from the point of compromise onward. With IDs the server will > start misbehaving (asking for more IDs than connections, asking for > all IDs, asking for IDs of connections that got terminated some place > else), with tickets, it will be invisible. > Although you make a strong point here, you nullify it directly again by your own paragraph from above. You trust the same admins that aren't even able to simply update their OpenSSL library to implement some kind of intrusion detection for their session storage. Don't get me wrong, I understand your point and it seems quite right to me. Current implementations of session caches are also flawed. They are shared among many (virtual) hosts and the ID isn't validated against the requested host (well, at least as far as I know; again correct me). Also consider this, if current libraries wouldn't be correctly implementing the TTL of session caches, wouldn't this system face the same problem? Richard --------------080508070603050801070907 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit On 9/3/2014 6:21 PM, Hubert Kario wrote:

From: "Richard Fussenegger, BSc" <richard@fussenegger.info>
To: tls@ietf.org
Sent: Wednesday, September 3, 2014 4:42:22 PM
Subject: Re: [TLS] tickets or sesssions or both (oh my)

That's a very good explanation and perhaps admins should be more educated on this matter. But the problem here aren't the admins, the libraries are. They should take care to frequently rotate the keys like Twitter is doing it (by themselves):

https://blog.twitter.com/2013/forward-secrecy-at-twitter

It's really not that hard to implement, even for clusters as we an see from the Twitter example. Nginx is already offering key file support, but no rotation scheme for single installations. This means cluster support is given for people who know what they're doing. But the common admin is left alone in the dark, thinking PFS is working great (maybe even checked in with SSLLabs or something) and in reality it's not. This problem has to be fixed, but it's not a problem of the specs!

I'd love for the admins to be better educated, but considering that around 0.5% of servers still are vulnerable to Hearbleed (over 700 machines verified), 7% vulnerable to the CCS issue (CVE-2014-0224), 20% of servers still enable SSLv2[1], over 3% enabling AECDH and 17% enabling single DES cipher suites[2], hoping for admins to do the right thing is bad idea. Many of them will get it wrong as they have shown time and time again.

The point is that getting ID's correct is easy, getting tickets correct is not obvious (most people won't even know there *is* a problem in the first place) and requires "superfluous" code.

My point was that the admins aren't the people who are responsible for the defect, the library and software developers are. But they are ignoring it, even if tickets are created were users ask them to fix it. In case of nginx it's even more problematic because they have the flawed tickets activated by default. The burden to either configure them correctly (by e.g. restarting the server on a regular basis *hack*) or disable tickets is up to the admins.

I think (to add to Rich Salz's comment) that tickets are best suited for hostile servers. Because you can simply increase the rotation frequency and you only have a key for decryption. It's not said that you'll ever receive all those tickets from the clients afterwards. On the other hand with the sessions you'll have direct access to all those sessions. (Correct me if I'm wrong here.)

If the remote server is compromised, how distributing "just" decryption keys to it is not a problem from PFS point of view? This one server will have the keys to the kingdom, even if they change often, they will allow you to decrypt all communication to other servers from the point of compromise onward. With IDs the server will start misbehaving (asking for more IDs than connections, asking for all IDs, asking for IDs of connections that got terminated some place else), with tickets, it will be invisible.

Although you make a strong point here, you nullify it directly again by your own paragraph from above. You trust the same admins that aren't even able to simply update their OpenSSL library to implement some kind of intrusion detection for their session storage. Don't get me wrong, I understand your point and it seems quite right to me.

Current implementations of session caches are also flawed. They are shared among many (virtual) hosts and the ID isn't validated against the requested host (well, at least as far as I know; again correct me).

Also consider this, if current libraries wouldn't be correctly implementing the TTL of session caches, wouldn't this system face the same problem?

Richard
--------------080508070603050801070907-- From nobody Wed Sep 3 09:49:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E1671A00AB for ; Wed, 3 Sep 2014 09:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mzdILNUTpHDC for ; Wed, 3 Sep 2014 09:49:45 -0700 (PDT) Received: from mx204.easyname.com (mx204.easyname.com [212.232.28.125]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AB321A005F for ; Wed, 3 Sep 2014 09:49:45 -0700 (PDT) Received: from 89-26-76-175.goll.dyn.salzburg-online.at ([89.26.76.175] helo=[192.168.0.11]) by mx.easyname.eu with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XPDkb-0003VY-Pl for tls@ietf.org; Wed, 03 Sep 2014 18:49:43 +0200 Message-ID: <540746A1.9010903@fussenegger.info> Date: Wed, 03 Sep 2014 18:49:37 +0200 From: "Richard Fussenegger, BSc" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: tls@ietf.org References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> <20140903140059.GW14392@mournblade.imrryr.org> <1243278676.42405953.1409754600887.JavaMail.zimbra@redhat.com> <540728CE.6080305@fussenegger.info> <1589581250.42632708.1409761318984.JavaMail.zimbra@redhat.com> <20140903163948.GE14392@mournblade.imrryr.org> In-Reply-To: <20140903163948.GE14392@mournblade.imrryr.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BLakNd2uGlBBss34tiDPZfqSTyw Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 16:49:47 -0000 Full agreement here and it underlines what I've written in my last mail. Just because current implementations implemented session caches correctly but knowingly implemented tickets incorrectly doesn't make tickets incorrect or flawed. The topic on how we can easily detect compromised servers with either system is a different and very interesting discussion that I'd love to investigate further. Richard On 9/3/2014 6:39 PM, Viktor Dukhovni wrote: > On Wed, Sep 03, 2014 at 12:21:58PM -0400, Hubert Kario wrote: > >> The point is that getting ID's correct is easy, getting tickets >> correct is not obvious (most people won't even know there *is* a >> problem in the first place) and requires "superfluous" code. > In any cluster, sharing of keys and sharing of sessions are identical > problems. The fact that some implementations have been sloppy in > support for session tickets is solely a problem of those implementations. > > They probably don't have a shared backing store for sessions either. > This is a poorly designed cluster. This problem has solutions, > and session tickets avoid potential for all too easy denial of > service on server-side session caches. > > Please do not cripple TLS. I don't want to have to disable TLSv1.3 > support when TLSv1.3 appears. > > Session tickets do not compromise PFS. Many servers are not > clustered, and work much better with session tickets than with a > memory resident session cache. Please do not cripple TLS. > > That's all I have to say on this thread. Thanks for the bandwidth. > From nobody Wed Sep 3 09:57:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC69F1A035E for ; Wed, 3 Sep 2014 09:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.218 X-Spam-Level: X-Spam-Status: No, score=-7.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhQ785HZ_aL3 for ; Wed, 3 Sep 2014 09:57:22 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 495931A0154 for ; Wed, 3 Sep 2014 09:57:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,458,1406584800"; d="asc'?scan'208";a="92880212" Received: from d-burl-bng2-64-223-164-252.ngn.east.myfairpoint.net (HELO [10.0.1.2]) ([64.223.164.252]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 03 Sep 2014 18:57:20 +0200 From: Karthikeyan Bhargavan Content-Type: multipart/signed; boundary="Apple-Mail=_8D2CA437-3823-47BC-82D8-6ADB82FE82CA"; protocol="application/pgp-signature"; micalg=pgp-sha512 Message-Id: <18E884D9-204D-4D90-9DAF-3BFE8086732D@inria.fr> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Date: Wed, 3 Sep 2014 12:57:18 -0400 References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> <20140903140059.GW14392@mournblade.imrryr.org> <1243278676.42405953.1409754600887.JavaMail.zimbra@redhat.com> <540728CE.6080305@fussenegger.info> <1589581250.42632708.1409761318984.JavaMail.zimbra@redhat.com> <20140903163948.GE14392@mournblade.imrryr.org> To: tls@ietf.org In-Reply-To: <20140903163948.GE14392@mournblade.imrryr.org> X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nebvi5DjL8EZpwt84ZoGkiAM8Jg Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 16:57:24 -0000 --Apple-Mail=_8D2CA437-3823-47BC-82D8-6ADB82FE82CA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Forgetting about PFS for a minute, there is another trade-off on the = server-side session vs client-side ticket designs. The following may be dismissed as an application or API problem, but = we=92ve found it vexing in building and proving our TLS implementation. How is a client supposed to cache and reuse tickets? Does it store it = indexed by the hostname? + port? + ip address? + certificate? Obviously, if a client is given a ticket by one (malicious) TLS server = and incorrectly uses it with a different (honest) TLS server,=20 this breaks confidentiality for the resumed connection (since the = malicious server can read it.) Different client libraries and client applications (e.g. browsers) seem = to manage client-side caches differently.=20 If tickets make it into the TLS 1.3 spec, it would be great to give = strong recommendations on how to store tickets=20 at the client side and when the client should use a ticket it has stored = earlier.=20 (E.g. A client that uses a database of tickets indexed by IP address + = Port (only) when speaking to multiple servers does not provide = confidentiality for resumed connections.) On 03 Sep 2014, at 12:39, Viktor Dukhovni = wrote: > On Wed, Sep 03, 2014 at 12:21:58PM -0400, Hubert Kario wrote: >=20 >> The point is that getting ID's correct is easy, getting tickets >> correct is not obvious (most people won't even know there *is* a >> problem in the first place) and requires "superfluous" code. >=20 > In any cluster, sharing of keys and sharing of sessions are identical > problems. The fact that some implementations have been sloppy in > support for session tickets is solely a problem of those = implementations. >=20 > They probably don't have a shared backing store for sessions either. > This is a poorly designed cluster. This problem has solutions, > and session tickets avoid potential for all too easy denial of > service on server-side session caches. >=20 > Please do not cripple TLS. I don't want to have to disable TLSv1.3 > support when TLSv1.3 appears. >=20 > Session tickets do not compromise PFS. Many servers are not > clustered, and work much better with session tickets than with a > memory resident session cache. Please do not cripple TLS. >=20 > That's all I have to say on this thread. Thanks for the bandwidth. >=20 > --=20 > Viktor. >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_8D2CA437-3823-47BC-82D8-6ADB82FE82CA Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUB0huAAoJEB/WSo9veuUKy/gH/0MlVZELP2jrDw/8OvTlkIJQ UaRlqMXwpeHmae09WaEIpW03vTJR3vVOLsnnfzRi6VfWZ586ewg3eEmktAkl6iZG 7sBT17KsDCIOj1Cu2f5AwWjF6mSayHT+VwRyNUR/2XfkvUzKzcywIRJoTnc2y30q wvkMxwnHvBnmQ6wqGxubsWn58ZDiUoX3yEHxjyR48cFnopzrnGGDxFfdCgNUoI5v coksqWEQ8MU8FWc51gNBGOftEp1EmYlccP0ejQnivDY5+wdIJM6iw1LLHhUuTR9n wLOGmemDuwaIAqvf8zCER1Ywy08wO6Qo0jbfQqhbuNQo/zFw0nqS9m29UJdG2V4= =Db9H -----END PGP SIGNATURE----- --Apple-Mail=_8D2CA437-3823-47BC-82D8-6ADB82FE82CA-- From nobody Wed Sep 3 10:07:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B49F1A0391 for ; Wed, 3 Sep 2014 10:07:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.269 X-Spam-Level: X-Spam-Status: No, score=-3.269 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cpGXMPdii1fV for ; Wed, 3 Sep 2014 10:06:59 -0700 (PDT) Received: from mx5-phx2.redhat.com (mx5-phx2.redhat.com [209.132.183.37]) by ietfa.amsl.com (Postfix) with ESMTP id 35B741A0368 for ; Wed, 3 Sep 2014 10:05:59 -0700 (PDT) Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx5-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s83H5iEs023760; Wed, 3 Sep 2014 13:05:44 -0400 Date: Wed, 3 Sep 2014 13:05:44 -0400 (EDT) From: Hubert Kario To: "Richard Fussenegger, BSc" Message-ID: <1474051094.43389347.1409763944473.JavaMail.zimbra@redhat.com> In-Reply-To: <5407460F.1030707@fussenegger.info> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> <20140903140059.GW14392@mournblade.imrryr.org> <1243278676.42405953.1409754600887.JavaMail.zimbra@redhat.com> <540728CE.6080305@fussenegger.info> <1589581250.42632708.1409761318984.JavaMail.zimbra@redhat.com> <5407460F.1030707@fussenegger.info> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_43389346_1545887500.1409763944472" X-Originating-IP: [10.5.82.7] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922) Thread-Topic: tickets or sesssions or both (oh my) Thread-Index: kUuBllbw4vzLl2mPMVeYXx3JLZZoHw== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KUgeITBNoEajupBaum6jiiEh6Xg Cc: tls@ietf.org Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 17:07:10 -0000 ------=_Part_43389346_1545887500.1409763944472 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Richard Fussenegger, BSc" > To: "Hubert Kario" > Cc: tls@ietf.org > Sent: Wednesday, September 3, 2014 6:47:11 PM > Subject: Re: [TLS] tickets or sesssions or both (oh my) > On 9/3/2014 6:21 PM, Hubert Kario wrote: > > ----- Original Message ----- >=20 > > > From: "Richard Fussenegger, BSc" > >=20 >=20 > > > To: tls@ietf.org > >=20 >=20 > > > Sent: Wednesday, September 3, 2014 4:42:22 PM > >=20 >=20 > > > Subject: Re: [TLS] tickets or sesssions or both (oh my) > >=20 >=20 > > > That's a very good explanation and perhaps admins should be more educ= ated > > > on > > > this matter. But the problem here aren't the admins, the libraries ar= e. > > > They > > > should take care to frequently rotate the keys like Twitter is doing = it > > > (by > > > themselves): > >=20 >=20 > > > https://blog.twitter.com/2013/forward-secrecy-at-twitter > >=20 >=20 > > > It's really not that hard to implement, even for clusters as we an se= e > > > from > > > the Twitter example. Nginx is already offering key file support, but = no > > > rotation scheme for single installations. This means cluster support = is > > > given for people who know what they're doing. But the common admin is > > > left > > > alone in the dark, thinking PFS is working great (maybe even checked = in > > > with > > > SSLLabs or something) and in reality it's not. This problem has to be > > > fixed, > > > but it's not a problem of the specs! > >=20 >=20 > > I'd love for the admins to be better educated, but considering that aro= und > > 0.5% of servers still are vulnerable to Hearbleed (over 700 machines > > verified), 7% vulnerable to the CCS issue (CVE-2014-0224), 20% of serve= rs > > still enable SSLv2[1], over 3% enabling AECDH and 17% enabling single D= ES > > cipher suites[2], hoping for admins to do the right thing is bad idea. = Many > > of them will get it wrong as they have shown time and time again. >=20 > > The point is that getting ID's correct is easy, getting tickets correct= is > > not obvious (most people won't even know there *is* a problem in the fi= rst > > place) and requires "superfluous" code. >=20 > My point was that the admins aren't the people who are responsible for th= e > defect, the library and software developers are. yes and no. While the "obvious bad" implementation is the result of develop= ers, this implementations will stay like this because users will demand for= their flawed deployments to continue working. Without dropping support for= tickets, I don't think we can realistically get rid of the bad implementat= ions.=20 > > > I think (to add to Rich Salz's comment) that tickets are best suited = for > > > hostile servers. Because you can simply increase the rotation frequen= cy > > > and > > > you only have a key for decryption. It's not said that you'll ever > > > receive > > > all those tickets from the clients afterwards. On the other hand with= the > > > sessions you'll have direct access to all those sessions. (Correct me= if > > > I'm > > > wrong here.) > >=20 >=20 > > If the remote server is compromised, how distributing "just" decryption > > keys > > to it is not a problem from PFS point of view? This one server will hav= e > > the > > keys to the kingdom, even if they change often, they will allow you to > > decrypt all communication to other servers from the point of compromise > > onward. With IDs the server will start misbehaving (asking for more IDs > > than > > connections, asking for all IDs, asking for IDs of connections that got > > terminated some place else), with tickets, it will be invisible. >=20 > Although you make a strong point here, you nullify it directly again by y= our > own paragraph from above. You trust the same admins that aren't even able= to > simply update their OpenSSL library to implement some kind of intrusion > detection for their session storage. Don't get me wrong, I understand you= r > point and it seems quite right to me. This is a big vs single host deployment difference.=20 I can expect a big deployment to have proper monitoring. For single host ju= st key rotation or session cache lifetime matters.=20 > Current implementations of session caches are also flawed. They are share= d > among many (virtual) hosts and the ID isn't validated against the request= ed > host (well, at least as far as I know; again correct me). > Also consider this, if current libraries wouldn't be correctly implementi= ng > the TTL of session caches, wouldn't this system face the same problem? No - because if they didn't implement TTL for cache, they would quickly run= out of memory and stop working (probably trashing the whole server in proc= ess). That would be an obvious error.=20 It's hard to get IDs wrong. And if you do, you won't compromise PFS (short = of exporting master secret as the ID...).=20 It's easy to get tickets wrong. And if you do, you can hide it well enough = that without source code access you won't be able to detect it.=20 --=20 Regards,=20 Hubert Kario=20 Quality Engineer, QE BaseOS Security team=20 Email: hkario@redhat.com=20 Web: www.cz.redhat.com=20 Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic=20 ------=_Part_43389346_1545887500.1409763944472 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Fr= om: "Richard Fussenegger, BSc" <richard@fussenegger.info>
T= o: "Hubert Kario" <hkario@redhat.com>
Cc: tls@ietf.org<= br>Sent: Wednesday, September 3, 2014 6:47:11 PM
Subject: = Re: [TLS] tickets or sesssions or both (oh my)

=20 =20 =20 =20 On 9/3/2014 6:21 PM, Hubert Kario wrote:

From: "Richard Fussenegger, BSc" <richard@fussenegger.info>
To:= tls@ietf.org
Sent: Wednesday, September 3, 201= 4 4:42:22 PM
Subject: Re: [TLS] tickets or sesssions or both (oh my)

That's a very good explanation and perhaps admins should be more educated on this matter. But the problem here aren't the admins, the libraries are. They should take care to frequently rotate the keys like Twitter is doing it (by themselves):

https://blog.twitte= r.com/2013/forward-secrecy-at-twitter

It's really not that hard to implement, even for clusters as we an see from the Twitter example. Nginx is already offering key file support, but no rotation scheme for single installations. This means cluster support is given for people who know what they're doing. But the common admin is left alone in the dark, thinking PFS is working great (maybe even checked in with SSLLabs or something) and in reality it's not. This problem has to be fixed, but it's not a problem of the specs!

I'd love for the admins to be better educated, but considering that around 0.5% of servers still are vulnerable to Hearbleed (over 700 machines verified), 7% vulnerable to the CCS issue (CVE-2014-0224), 20% of servers still enable SSLv2[1], over 3% enabling AECDH and 17% enabling single DES cipher suites[2], hoping for admins to do the right thing is bad idea. Many of them will get it wrong as they have shown time and time again.

The point is that getting ID's correct is easy, getting tickets correct is not obvious (most people won't even know there *is* a problem in the first place) and requires "superfluous" code.

My point was that the admins aren't the people who are responsible for the defect, the library and software developers are.
yes and no. While the "obvious bad" implementation is the= result of developers, this implementations will stay like this because use= rs will demand for their flawed deployments to continue working. Without dr= opping support for tickets, I don't think we can realistically get rid of t= he bad implementations.



I = think (to add to Rich Salz's comment) that tickets are best suited for hostile servers. Because you can simply increase the rotation frequency and you only have a key for decryption. It's not said that you'll ever receive all those tickets from the clients afterwards. On the other hand with the sessions you'll have direct access to all those sessions. (Correct me if I'm wrong here.)

If the remote server= is compromised, how distributing "just" decryption keys to it is not a problem from PFS point of view? This one server will have the keys to the kingdom, even if they change often, they will allow you to decrypt all communication to other servers from the point of compromise onward. With IDs the server will start misbehaving (asking for more IDs than connections, asking for all IDs, asking for IDs of connections that got terminated some place else), with tickets, it will be invisible.

Although you make a strong point here, you nullify it directly again by your own paragraph from above. You trust the same admins that aren't even able to simply update their OpenSSL library to implement some kind of intrusion detection for their session storage. Don't get me wrong, I understand your point and it seems quite right to me.

This is a big vs single host deploy= ment difference.
I can expect a big deployment to have proper= monitoring. For single host just key rotation or session cache lifetime ma= tters.


Current implementations of session caches are also flawed. They are shared among many (virtual) hosts and the ID isn't validated against the requested host (well, at least as far as I know; again correct me).

Also consider this, if current libraries wouldn't be correctly implementing the TTL of session caches, wouldn't this system face the same problem?

No - because if they = didn't implement TTL for cache, they would quickly run out of memory and st= op working (probably trashing the whole server in process). That would be a= n obvious error.

It's hard to get IDs wrong. = And if you do, you won't compromise PFS (short of exporting master secret a= s the ID...).
It's easy to get tickets wrong. And if you do, = you can hide it well enough that without source code access you won't be ab= le to detect it.


--
<= div>Regards,
Hubert Kario
Quality Engineer, Q= E BaseOS Security team
Email: hkario@redhat.com
Web: www.cz.redhat.co= m
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republ= ic
------=_Part_43389346_1545887500.1409763944472-- From nobody Wed Sep 3 10:30:07 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2B531A00FE for ; Wed, 3 Sep 2014 10:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id po3tKIdnRuIl for ; Wed, 3 Sep 2014 10:30:02 -0700 (PDT) Received: from smtp.serverkommune.de (serverkommune.de [176.9.61.43]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C56AB1A005C for ; Wed, 3 Sep 2014 10:30:01 -0700 (PDT) Received: by smtp.serverkommune.de (Postfix, from userid 5001) id 3EDD6808FA; Wed, 3 Sep 2014 19:30:00 +0200 (CEST) Received: from [131.159.20.131] (ex6.serverkommune.de [176.9.61.43]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.serverkommune.de (Postfix) with ESMTPSA id F0FD380232; Wed, 3 Sep 2014 19:29:58 +0200 (CEST) Message-ID: <54075016.6040406@net.in.tum.de> Date: Wed, 03 Sep 2014 19:29:58 +0200 From: Ralph Holz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: "Blumenthal, Uri - 0558 - MITLL" , Yutaka OIWA References: <54048985.1020005@net.in.tum.de> <3EB754B7-F6B2-4207-A2F0-E61F32EE1E40@ll.mit.edu> In-Reply-To: <3EB754B7-F6B2-4207-A2F0-E61F32EE1E40@ll.mit.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.98.1 at ex6 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Qv5dUaT-PKAxgJ-uXw-wS563PlA Cc: tls@ietf.org Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 17:30:05 -0000 Good day, Please do not forget that the MUST NOT concerns a recommendation what to negotiate - it was only my impression that the current wording may lead implementers to drop it entirely. I have had some very good feedback on this list. In addition, I have been in touch with people who run Grid centres and solicited their opinion (they do have setups with NULL). My impression from all this is that the wording in the BCP should be slightly altered, to: "Deployments of TLS to secure application-layer protocols MUST NOT negotiate the NULL cipher. Note: TLS implementations MAY retain code for the NULL cipher for other specialised purposes like testing, etc." That will make it clear that implementers are free to retain NULL (and they will), but that the purpose of the BCP is to propose secure TLS configurations to protect application-layer protocols, and for those no deployment should ever negotiate NULL. This is particularly interesting if TLS 1.3 is going to drop NULL, too. The above is what I have suggested to the lead author, and it's what I am going to vote for. Ralph On 09/03/2014 06:10 PM, Blumenthal, Uri - 0558 - MITLL wrote: > On Sep 3, 2014, at 06:34 , Yutaka OIWA wrote: >> The document title is "Recommendations for Secure Use of TLS and >> DTLS", clearly applicable for the "Secure Uses". It also says >> "These are minimum recommendations for the general use of TLS." > ^^^^^^^^ Exactly. > >> For the purposes of such secure and general use cases, NULL ciphers >> are clearly "MUST NOT" with no doubt. > > "Clearly" and "with no doubt"? With respect, this doesn't seem to be > your field of expertise. > >> If you have any "insecure", special (non-general) use cases of >> TLS, the document do not forbid you to use it, because the document >> is simply not applicable. However, such special use cases shall not >> make any hindrance for making a BCP document for general use >> cases. > > There can be no generic "secure" (or "insecure") - only "secure > regarding ...". > > One implication is that unless threat to data confidentiality is a > concern, trying to make the data-in-transit confidential would be a > waste of resources and time. Not to mention that some admin domains > restrict the right to keep the data confidential. > > Others made it clear that (a) it should be stated that NULL cipher > SHOULD NOT be enabled (by default, at least), but (b) it must not be > listed "MUST NOT". People would simply disregard (and justly so!) a > document that places such silly and unrealistic demands. > > I'm skipping the rest, as it doesn't seem that it needs an answer. > > _______________________________________________ TLS mailing list > TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls > -- Ralph Holz I8 - Network Architectures and Services Technische Universitt Mnchen http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18043 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF From nobody Wed Sep 3 10:34:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8438A1A02A5 for ; Wed, 3 Sep 2014 10:34:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uNzHpzWZzreW for ; Wed, 3 Sep 2014 10:34:04 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D7E2E1A005C for ; Wed, 3 Sep 2014 10:34:03 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id gi9so10373298lab.0 for ; Wed, 03 Sep 2014 10:34:02 -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=2OZIa0UWEv2Yz3Zhgl9egVuII7UfNMJUARkinug82TY=; b=eaQN595VcI+cCPjBkyc9UwW2LTw5oU8/hxBj8mqhIb3aR4u9zIkMPFhMHDXSmlsid4 QiRFCWeMphc4cKebTcfjaYfprNxI/HtGP/cAvAbwy3q5eSHC9OLicHgLZ95Ln8+HxP7f hDbh4EeAx7AMiHQNbsaeymwe0KuTE3eDwI+7LaKla2QCCdElT6h5eMgxmgkZRyaNtwpo e7zZBruHiEW/Wn+NRgItno0RJ+5On36+XzfKz12j8gZFoPnFEBhhqJnOsLQSMLHLy7Vi jdChvIfhTXvyCRaXnbe7pf/tSaL9a8Q957zDoZjwkYjOtrZRY2Wxl18MrfzneWhufuZr xmBg== MIME-Version: 1.0 X-Received: by 10.152.21.168 with SMTP id w8mr28082708lae.53.1409765642160; Wed, 03 Sep 2014 10:34:02 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Wed, 3 Sep 2014 10:34:02 -0700 (PDT) In-Reply-To: <18E884D9-204D-4D90-9DAF-3BFE8086732D@inria.fr> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> <20140903140059.GW14392@mournblade.imrryr.org> <1243278676.42405953.1409754600887.JavaMail.zimbra@redhat.com> <540728CE.6080305@fussenegger.info> <1589581250.42632708.1409761318984.JavaMail.zimbra@redhat.com> <20140903163948.GE14392@mournblade.imrryr.org> <18E884D9-204D-4D90-9DAF-3BFE8086732D@inria.fr> Date: Wed, 3 Sep 2014 10:34:02 -0700 Message-ID: From: Martin Thomson To: Karthikeyan Bhargavan Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eMq6qWHzXbLuxH5v1DTocwsjRQI Cc: "tls@ietf.org" Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 17:34:09 -0000 On 3 September 2014 09:57, Karthikeyan Bhargavan wrote: > Obviously, if a client is given a ticket by one (malicious) TLS server and incorrectly uses it with a different (honest) TLS server, > this breaks confidentiality for the resumed connection (since the malicious server can read it.) As long as we address the master secret manipulation attack properly, the ability of an attacker to generate a ticket that is both a) accepted by the honest server and b) corresponds to the master (or pre-master) that both client and server will use, is limited. Add to that the fact that integrity and confidentiality protections on the ticket need to be adequate. That ensures that tickets can't be decrypted or synthesized. While I think that Bodo's suggestion regarding a single mechanism is basically OK, I don't think we should punt the description of tickets and these concerns to another document. I'd prefer if we pull all forms of resumption in to the main TLS 1.3 draft and have the considerations properly articulated there. It's not as though we don't have the information already at hand. From nobody Wed Sep 3 10:48:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398A71A03BF for ; Wed, 3 Sep 2014 10:48:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QCIClpyHJYCL for ; Wed, 3 Sep 2014 10:47:57 -0700 (PDT) Received: from mx203.easyname.com (mx203.easyname.com [212.232.28.124]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB7811A03B7 for ; Wed, 3 Sep 2014 10:47:56 -0700 (PDT) Received: from 89-26-76-175.goll.dyn.salzburg-online.at ([89.26.76.175] helo=[192.168.0.11]) by mx.easyname.eu with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XPEet-00017X-Jv; Wed, 03 Sep 2014 19:47:54 +0200 Message-ID: <5407543F.9020209@fussenegger.info> Date: Wed, 03 Sep 2014 19:47:43 +0200 From: "Richard Fussenegger, BSc" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Hubert Kario References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> <20140903140059.GW14392@mournblade.imrryr.org> <1243278676.42405953.1409754600887.JavaMail.zimbra@redhat.com> <540728CE.6080305@fussenegger.info> <1589581250.42632708.1409761318984.JavaMail.zimbra@redhat.com> <5407460F.1030707@fussenegger.info> <1474051094.43389347.1409763944473.JavaMail.zimbra@redhat.com> In-Reply-To: <1474051094.43389347.1409763944473.JavaMail.zimbra@redhat.com> Content-Type: multipart/alternative; boundary="------------010409080001020705050809" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sxhofMXDfzCsyf75NnUDjQ7PaiQ Cc: tls@ietf.org Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 17:48:08 -0000 This is a multi-part message in MIME format. --------------010409080001020705050809 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 9/3/2014 7:05 PM, Hubert Kario wrote: > > yes and no. While the "obvious bad" implementation is the result of > developers, this implementations will stay like this because users > will demand for their flawed deployments to continue working. Without > dropping support for tickets, I don't think we can realistically get > rid of the bad implementations. > Actually fixing current implementations wouldn't break anything, because the keys would simply start to rotate. Otherwise the admins wouldn't be able to restart their flawed web servers ever, as this would apparently break their complete deployment following your logic. So that's not a valid argument. > > This is a big vs single host deployment difference. > I can expect a big deployment to have proper monitoring. For single > host just key rotation or session cache lifetime matters. > No worries, I understood that. But the joke is, as soon as the software is fixed all small implementations are fixed (well, at least those that are updating and note that the ones that have a Heartbleed bug shouldn't even think about PFS). > > Current implementations of session caches are also flawed. They > are shared among many (virtual) hosts and the ID isn't validated > against the requested host (well, at least as far as I know; again > correct me). > > Also consider this, if current libraries wouldn't be correctly > implementing the TTL of session caches, wouldn't this system face > the same problem? > > > No - because if they didn't implement TTL for cache, they would > quickly run out of memory and stop working (probably trashing the > whole server in process). That would be an obvious error. > > It's hard to get IDs wrong. And if you do, you won't compromise PFS > (short of exporting master secret as the ID...). > It's easy to get tickets wrong. And if you do, you can hide it well > enough that without source code access you won't be able to detect it. > You're most certainly correct here with the memory limit regarding TTLs and I only meant it as a mind game and not like actually implementing it. Re-read it and you'll notice. ;-) But don't jump right over the Virtual Host Confusion [1] problem. That's a realistic problem for all and was used against Akamai [2], Pinterest [3], Dropbox [4], … which I assume using clusters. How can we detect it? Well, go over the source code. Same problem, different implementation. Richard [1] https://bh.ht.vc/vhost_confusion.pdf [2] https://www.youtube.com/watch?v=YKD-i4HbbGg [3] https://www.youtube.com/watch?v=h0VhFlTP2xw [4] https://www.youtube.com/watch?v=CkOGKi0pKdk --------------010409080001020705050809 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
On 9/3/2014 7:05 PM, Hubert Kario wrote:

yes and no. While the "obvious bad" implementation is the result of developers, this implementations will stay like this because users will demand for their flawed deployments to continue working. Without dropping support for tickets, I don't think we can realistically get rid of the bad implementations.

Actually fixing current implementations wouldn't break anything, because the keys would simply start to rotate. Otherwise the admins wouldn't be able to restart their flawed web servers ever, as this would apparently break their complete deployment following your logic. So that's not a valid argument.


This is a big vs single host deployment difference.
I can expect a big deployment to have proper monitoring. For single host just key rotation or session cache lifetime matters.

No worries, I understood that. But the joke is, as soon as the software is fixed all small implementations are fixed (well, at least those that are updating and note that the ones that have a Heartbleed bug shouldn't even think about PFS).


Current implementations of session caches are also flawed. They are shared among many (virtual) hosts and the ID isn't validated against the requested host (well, at least as far as I know; again correct me).

Also consider this, if current libraries wouldn't be correctly implementing the TTL of session caches, wouldn't this system face the same problem?

No - because if they didn't implement TTL for cache, they would quickly run out of memory and stop working (probably trashing the whole server in process). That would be an obvious error.

It's hard to get IDs wrong. And if you do, you won't compromise PFS (short of exporting master secret as the ID...).
It's easy to get tickets wrong. And if you do, you can hide it well enough that without source code access you won't be able to detect it.

You're most certainly correct here with the memory limit regarding TTLs and I only meant it as a mind game and not like actually implementing it. Re-read it and you'll notice. ;-)

But don't jump right over the Virtual Host Confusion [1] problem. That's a realistic problem for all and was used against Akamai [2], Pinterest [3], Dropbox [4], … which I assume using clusters. How can we detect it? Well, go over the source code.

Same problem, different implementation.

Richard

[1] https://bh.ht.vc/vhost_confusion.pdf
[2] https://www.youtube.com/watch?v=YKD-i4HbbGg
[3] https://www.youtube.com/watch?v=h0VhFlTP2xw
[4] https://www.youtube.com/watch?v=CkOGKi0pKdk
--------------010409080001020705050809-- From nobody Wed Sep 3 10:50:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D12381A0369 for ; Wed, 3 Sep 2014 10:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W7VPiGMca6-0 for ; Wed, 3 Sep 2014 10:49:59 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47AEC1A0235 for ; Wed, 3 Sep 2014 10:49:59 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 5A1762AB2B7; Wed, 3 Sep 2014 17:49:58 +0000 (UTC) Date: Wed, 3 Sep 2014 17:49:58 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140903174958.GF14392@mournblade.imrryr.org> References: <54048985.1020005@net.in.tum.de> <3EB754B7-F6B2-4207-A2F0-E61F32EE1E40@ll.mit.edu> <54075016.6040406@net.in.tum.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54075016.6040406@net.in.tum.de> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/wz7qgC-cGFSquoeou8nOCtG4XBM Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@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: Wed, 03 Sep 2014 17:50:01 -0000 On Wed, Sep 03, 2014 at 07:29:58PM +0200, Ralph Holz wrote: > "Deployments of TLS to secure application-layer protocols MUST NOT > negotiate the NULL cipher. Note: TLS implementations MAY retain code for > the NULL cipher for other specialised purposes like testing, etc." > > That will make it clear that implementers are free to retain NULL (and > they will), but that the purpose of the BCP is to propose secure TLS > configurations to protect application-layer protocols, and for those no > deployment should ever negotiate NULL. This is still too strong. Local MTA to Mail-Store LMTP is an application protocol. It is a fine use-case for NULL ciphers. What is much more reasonable is that initiators (clients) should refuse to negotiate (should suppress any configured) NULL cipher suites when any non NULL cipher suite is enabled. This prevents accidents, without breaking carefully considered NULL to NULL deployments. -- Viktor. From nobody Wed Sep 3 11:00:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFD141A041C for ; Wed, 3 Sep 2014 11:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iy-L4rp0JapP for ; Wed, 3 Sep 2014 11:00:46 -0700 (PDT) Received: from smtp.serverkommune.de (serverkommune.de [176.9.61.43]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FC4A1A0416 for ; Wed, 3 Sep 2014 11:00:45 -0700 (PDT) Received: by smtp.serverkommune.de (Postfix, from userid 5001) id 3143B80A11; Wed, 3 Sep 2014 20:00:44 +0200 (CEST) Received: from [131.159.20.131] (ex6.serverkommune.de [176.9.61.43]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.serverkommune.de (Postfix) with ESMTPSA id 53EC38090E for ; Wed, 3 Sep 2014 20:00:43 +0200 (CEST) Message-ID: <5407574B.5060708@net.in.tum.de> Date: Wed, 03 Sep 2014 20:00:43 +0200 From: Ralph Holz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: tls@ietf.org References: <54048985.1020005@net.in.tum.de> <3EB754B7-F6B2-4207-A2F0-E61F32EE1E40@ll.mit.edu> <54075016.6040406@net.in.tum.de> <20140903174958.GF14392@mournblade.imrryr.org> In-Reply-To: <20140903174958.GF14392@mournblade.imrryr.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.98.1 at ex6 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/tls/u9rwIhi8yIXBLrnXjSwPsBleDXA Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 18:00:48 -0000 >> That will make it clear that implementers are free to retain NULL (and >> they will), but that the purpose of the BCP is to propose secure TLS >> configurations to protect application-layer protocols, and for those no >> deployment should ever negotiate NULL. > > This is still too strong. Local MTA to Mail-Store LMTP is an > application protocol. It is a fine use-case for NULL ciphers. I hear you (and the others), but balancing the purpose of the BCP with such requirements as you mention leads me to believe we should favour the solution I proposed. I added one more thing, though: "Note: TLS implementations MAY retain code for the NULL cipher to allow specialised purposes like debugging, custom solutions, etc." That "custom solution" - to me - seems to address what you describe. I see no other way to balance the requirements. If the vote were black/white between dropping and keeping, I'd favour dropping, by the way. I'd rather protect the many. Ralph -- Ralph Holz I8 - Network Architectures and Services Technische Universitt Mnchen http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18043 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF From nobody Wed Sep 3 11:50:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 953BB1A06EE for ; Wed, 3 Sep 2014 11:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.867 X-Spam-Level: X-Spam-Status: No, score=-4.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUfnWoMxnYwS for ; Wed, 3 Sep 2014 11:50:46 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 2F0E91A04B9 for ; Wed, 3 Sep 2014 11:50:45 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s83Io3R1022762; Wed, 3 Sep 2014 14:50:23 -0400 Content-Type: multipart/signed; boundary="Apple-Mail=_943A533C-5F4D-4829-BE6A-D334C397AD0D"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Blumenthal, Uri - 0668 - MITLL" In-Reply-To: <5407574B.5060708@net.in.tum.de> Date: Wed, 3 Sep 2014 14:46:51 -0400 Message-ID: <9120B6EE-F023-4724-9116-A169993F58E8@ll.mit.edu> References: <54048985.1020005@net.in.tum.de> <3EB754B7-F6B2-4207-A2F0-E61F32EE1E40@ll.mit.edu> <54075016.6040406@net.in.tum.de> <20140903174958.GF14392@mournblade.imrryr.org> <5407574B.5060708@net.in.tum.de> To: Ralph Holz , "" X-Mailer: Apple Mail (2.1878.6) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.27, 0.0.0000 definitions=2014-09-03_08:2014-09-03,2014-09-03,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-1402240000 definitions=main-1409030197 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/iOVyjnq6KrDaSRzJu6VWiPFdXjE Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 18:50:48 -0000 --Apple-Mail=_943A533C-5F4D-4829-BE6A-D334C397AD0D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 3, 2014, at 14:00 , Ralph Holz wrote: >>> That will make it clear that implementers are free to retain NULL = (and >>> they will), but that the purpose of the BCP is to propose secure TLS >>> configurations to protect application-layer protocols, and for those = no >>> deployment should ever negotiate NULL. >>=20 >> This is still too strong. Local MTA to Mail-Store LMTP is an >> application protocol. It is a fine use-case for NULL ciphers. >=20 > I hear you (and the others), but balancing the purpose of the BCP with > such requirements as you mention leads me to believe we should favour > the solution I proposed. I added one more thing, though: >=20 > "Note: TLS implementations MAY retain code for the NULL cipher to = allow > specialised purposes like debugging, custom solutions, etc.=94 Guys,=20 Per RFC2119, certain words have certain meanings. :-) In particular, =93MUST NOT=94 means not that =93don=92t do that unless = you can claim an exception=94. It means =93don=92t do that as it is = absolutely prohibited by this spec, no exception=94. What you probably want to specify here is =93SHOULD NOT=94. Before replying - please check with RFC 2119. It=92s three pages long, = so wouldn=92t take much of your time. (P.S. I wish people got really familiar with the standard terminology = before trying to write/edit a standard.)= --Apple-Mail=_943A533C-5F4D-4829-BE6A-D334C397AD0D Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIITFzCCBLcw ggOfoAMCAQICARQwDQYJKoZIhvcNAQELBQAwVDELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBM aW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQGA1UEAxMNTUlUTEwgUm9vdCBDQTAe Fw0wOTEyMTQxMjAwMDBaFw0xNTEyMzEyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZN SVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTIw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnBMsjYUiH7DegMwcFYWZM6OknYzRgEO5g NgPE9JJnQgfDB+o1o1VTMBWcJYPXII4CyhLhDvSjfCvTPI4HmRDKIp5UX5N2BCzwu7BJJMwUJHFa S4RMAC7nvYh6MIEixpl2aWCpkYX74b2CeDDQriGlqXCvxmg2QhPlNmk4ONpL/80Kx9wKKhV/NThe 54sFzZ2pz9YUEX5DE0a52hFvA19EzGhv7fUcucUjKy0zXPQ70LYwOWXLlpxAolKcgwRVsS6/cse8 YH9fy8IAsXKAXikgQaFs5EJigLIDKPTKtRaf55yKsORSpoDrO1cvuntA5PnIH/qAFfACvGRTEK1R NLh9AgMBAAGjggGVMIIBkTASBgNVHRMBAf8ECDAGAQH/AgEAMB0GA1UdDgQWBBSOSn2JoWMXHIGI NFc3JkVeGYp+JDAfBgNVHSMEGDAWgBRnqnrP9AqmuXK1iqDSnfIQw0PtKTAOBgNVHQ8BAf8EBAMC AYYwYQYIKwYBBQUHAQEEVTBTMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0 dG8/TExSQ0EwIgYIKwYBBQUHMAGGFmh0dHA6Ly9vY3NwLmxsLm1pdC5lZHUwMwYDVR0fBCwwKjAo oCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0G CyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0GCyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJ MA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIBAwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIB AwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqGSIb3DQEBCwUAA4IBAQCIdwah0P1x/Augwi/nhBq6Ds8Q XAqkzSLZrL+DADWjk6HYFNo64x3Bo15c6oaW/GcTpZACt3StPa3OvsgAnKCtk81bQ0WV2MaL/0qm UYyN3bn1NiWrQD8aLAssv9aLY5dUylGOO1r37d9b3X+YtFytg0FRCfl5arYAYhU1SDCHwScD2o67 Is/qYBRGMIYcCcb7PH5UotBSwhO+1WCxIqD+YcRusyD3kEcc4dW6IG36YVhx7aIkw5AUmeFH7xl0 E1X+0I4Q+cmMNdMiArYx5rYG34AZB+f770fdjWPUUpTT82aphiiImutWyQpmoEWBsnsX3nVTRdHC Vi+Cf3Cx4YDWMIIEtzCCA5+gAwIBAgIBFDANBgkqhkiG9w0BAQsFADBUMQswCQYDVQQGEwJVUzEf MB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1N SVRMTCBSb290IENBMB4XDTA5MTIxNDEyMDAwMFoXDTE1MTIzMTIzNTk1OVowUTELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTETMBEGA1UE AxMKTUlUTEwgQ0EtMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKcEyyNhSIfsN6Az BwVhZkzo6SdjNGAQ7mA2A8T0kmdCB8MH6jWjVVMwFZwlg9cgjgLKEuEO9KN8K9M8jgeZEMoinlRf k3YELPC7sEkkzBQkcVpLhEwALue9iHowgSLGmXZpYKmRhfvhvYJ4MNCuIaWpcK/GaDZCE+U2aTg4 2kv/zQrH3AoqFX81OF7niwXNnanP1hQRfkMTRrnaEW8DX0TMaG/t9Ry5xSMrLTNc9DvQtjA5ZcuW nECiUpyDBFWxLr9yx7xgf1/LwgCxcoBeKSBBoWzkQmKAsgMo9Mq1Fp/nnIqw5FKmgOs7Vy+6e0Dk +cgf+oAV8AK8ZFMQrVE0uH0CAwEAAaOCAZUwggGRMBIGA1UdEwEB/wQIMAYBAf8CAQAwHQYDVR0O BBYEFI5KfYmhYxccgYg0VzcmRV4Zin4kMB8GA1UdIwQYMBaAFGeqes/0Cqa5crWKoNKd8hDDQ+0p MA4GA1UdDwEB/wQEAwIBhjBhBggrBgEFBQcBAQRVMFMwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwu bGwubWl0LmVkdS9nZXR0bz9MTFJDQTAiBggrBgEFBQcwAYYWaHR0cDovL29jc3AubGwubWl0LmVk dTAzBgNVHR8ELDAqMCigJqAkhiJodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0Y3JsP0xMUkNBMIGS BgNVHSAEgYowgYcwDQYLKoZIhvcSAgEDAQYwDQYLKoZIhvcSAgEDAQgwDQYLKoZIhvcSAgEDAQcw DQYLKoZIhvcSAgEDAQkwDQYLKoZIhvcSAgEDAQowDQYLKoZIhvcSAgEDAQswDQYLKoZIhvcSAgED AQ4wDQYLKoZIhvcSAgEDAQ8wDQYLKoZIhvcSAgEDARAwDQYJKoZIhvcNAQELBQADggEBAIh3BqHQ /XH8C6DCL+eEGroOzxBcCqTNItmsv4MANaOTodgU2jrjHcGjXlzqhpb8ZxOlkAK3dK09rc6+yACc oK2TzVtDRZXYxov/SqZRjI3dufU2JatAPxosCyy/1otjl1TKUY47Wvft31vdf5i0XK2DQVEJ+Xlq tgBiFTVIMIfBJwPajrsiz+pgFEYwhhwJxvs8flSi0FLCE77VYLEioP5hxG6zIPeQRxzh1bogbfph WHHtoiTDkBSZ4UfvGXQTVf7QjhD5yYw10yICtjHmtgbfgBkH5/vvR92NY9RSlNPzZqmGKIia61bJ CmagRYGyexfedVNF0cJWL4J/cLHhgNYwggTLMIIDs6ADAgECAgprseEhAAAAAJGUMA0GCSqGSIb3 DQEBCwUAMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxEzARBgNVBAMTCk1JVExMIENBLTIwHhcNMTQwMTI3MTYxODUyWhcNMTUwMTI3 MTYxODUyWjBhMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEP MA0GA1UECxMGUGVvcGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCCASIwDQYJ KoZIhvcNAQEBBQADggEPADCCAQoCggEBAIzNfYCBa2AInZUkF96JdSdHsUd+sKkSViXlqCSYoR7S Ru+UzVetWe8JvOBJfKI8P2kcCOP98TRcSMSAvLczeHofstfnTdfCiJwG1go745y4/pn9xu36YeVW lrnOtMG0d1vEz8ODcqbtS9Wp9WgJbgsnpgIfh4EaDj158pUNYTl9F473R9YBBBknii629iM8CVFW fYXSmvxGCHVJswYaz9uVw/0y/g8N+IjUOdP9/0sQ6CS+7NjcWaW0xtHwrRB4VUnLin1tgD8dNnBo sXidbz4dQL6f5EnUmLRYFbHrpHZWBYDnWhewe+DIgfvYtAv+xBVF64Sy2So52ZbT6Gq7MBcCAwEA AaOCAZMwggGPMB0GA1UdDgQWBBRY6DKabQEyN3hUnd9LmWBWVXWSIDAOBgNVHQ8BAf8EBAMCBsAw HwYDVR0jBBgwFoAUjkp9iaFjFxyBiDRXNyZFXhmKfiQwMwYDVR0fBCwwKjAooCagJIYiaHR0cDov L2NybC5sbC5taXQuZWR1L2dldGNybC9MTENBMjBiBggrBgEFBQcBAQRWMFQwLQYIKwYBBQUHMAKG IWh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXR0by9MTENBMjAjBggrBgEFBQcwAYYXaHR0cDovL29j c3AubGwubWl0LmVkdS8wDAYDVR0TAQH/BAIwADA9BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiD g+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAiBgNVHSUBAf8EGDAWBggrBgEFBQcD BAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBs bC5taXQuZWR1MA0GCSqGSIb3DQEBCwUAA4IBAQB49iH8xEg0Clzpf+p7WwMsdUCDERU3bH+HC7fx /5dQAti9u0gMu9i0cdfi3DoPvkuXOthNyPntL+SIvQ1WxSOEGzvrNFHeJqzEwLRDxHLp5O6axNz0 0z9J1+Ag4dlapsAPAL9Hd49jJlMv9VABTrXXmravswj/f5/G+a6X0FEC53cD4aDXCIjwWFTnJ0vz 3RuMZuwnZhUMzELrMwUFXhMkCWm+kgWLEAFVm58ROoQf/FEK2D4H98o52PMyY7CiWFxRMcmPwOK5 uOTJhvhG/K5bWS2MI+WVS90BSPme/LudJqH1TahQsynUNlLPanuYGVwU2WbtclylsjaSPPHyYVGw MIIEzjCCA7agAwIBAgIKPVEvPAAAAACTsDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEf MB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpN SVRMTCBDQS0yMB4XDTE0MDIxMjE4NTMwMVoXDTE1MDIxMjE4NTMwMVowYTELMAkGA1UEBhMCVVMx HzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UE AxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCKHhhu75bRiOvWhbZ//TxS76yI2d+rHN2s8bp8wxW8oMjmsaplLeGQusUFRyRNSkfYtdB4YApj nV6TCxS0Mqzly5BaoeZWoP+CbbMDNGYMszus9iFj22SSlTzGRo+gaL6rqsDKdwDOzs3CPYqh4Uu8 sLzEq+QD9rhqAuMJ76635JKWELxK0uDehpNBMCGqVeAY8ht5u2h4ojPdwiuDQDW2QxWRJjPDL8n1 JczuEHY71jHldER3b2+UhpDDYRQ9aVOiGCjW8BwJOruVsBfLNxyDxgffNQ1D1konuneMpL9H2S8c iHOdy5+Gi7snCQJ+7w30rIJ2NTldWaY6avZAaCa3AgMBAAGjggGWMIIBkjAdBgNVHQ4EFgQUZ7oG jnu6gWRmom/4UswgdVBW/3wwDgYDVR0PAQH/BAQDAgUgMB8GA1UdIwQYMBaAFI5KfYmhYxccgYg0 VzcmRV4Zin4kMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwv TExDQTIwYgYIKwYBBQUHAQEEVjBUMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUv Z2V0dG8vTExDQTIwIwYIKwYBBQUHMAGGF2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB /wQCMAAwPQYJKwYBBAGCNxUHBDAwLgYmKwYBBAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQ cIPr7SACAWQCAQQwJQYDVR0lBB4wHAYEVR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0g BBEwDzANBgsqhkiG9xICAQMBCDAZBgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0B AQsFAAOCAQEAJiU3WfJ9GvGJiDNPClLazyh252wxxOc/TmClMKtyqHnbFObDEoXAMaoHGxrvs+lU 8fU2F2ELpV8q8eYgqLLw7PG09z5s/GkajlxVZ/FHj/9hNHTfwlicrCRY3zrna1GbOMZgWFz8R6ak AoLKpqGulNrvjvU8c63U+JVmgJmBPCMv5JlH10m87+WPJ+ToK0m4XfZjl7n5OKDJ/hOyBwbBntc+ W2gDppfR1BCtDNfEG0+zHjFqF+Of1Q5NI5abhgvw5IEuVA1M4SV/utwmmdreBEv/YuLnDd/PhVgQ wp3LHGCXX1dANyiKso2aACl9jrkylq39cA/WgvAlS21w9vxVpDGCAskwggLFAgEBMF8wUTELMAkG A1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTET MBEGA1UEAxMKTUlUTEwgQ0EtMgIKa7HhIQAAAACRlDAJBgUrDgMCGgUAoIIBPzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA5MDMxODQ5MzNaMCMGCSqGSIb3DQEJ BDEWBBT0QDdotu5ghbv1fx5dh9QDtnScZTBuBgkrBgEEAYI3EAQxYTBfMFExCzAJBgNVBAYTAlVT MR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMT Ck1JVExMIENBLTICCj1RLzwAAAAAk7AwcAYLKoZIhvcNAQkQAgsxYaBfMFExCzAJBgNVBAYTAlVT MR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLEwNQS0kxEzARBgNVBAMT Ck1JVExMIENBLTICCj1RLzwAAAAAk7AwDQYJKoZIhvcNAQEBBQAEggEAQk6Y9TJ0a93yNNpK0pEm WwNiWyeGj5CRN5pTi+DMBIodu9gsCRw467QBqqwAwt8K6Y4d5WUbaDM76ciPh/VFQzICOjSvluUX R26/9EQ/SurI9qNIj1gl94UtRAADGrbMxP8LXUWQC4FryB7L5rDTiP3N5EG/dQGJA9CHyg2glDB4 OnPhdgqHX8uMTfiA8eL93+pU/QT0iHQ7tbcD3NtbmTjOe0vcjdywXKZgI6DVJmgQ3U76X2DOFIV1 Qs4lnAqpk2xR9r4gINj6w/sAqFklOKwdLoFLLgewzccy1o3r2A4QtEtTwk/jgF2oqUTLEquOOwg6 BQdiwo6G3f8itEOHsAAAAAAAAA== --Apple-Mail=_943A533C-5F4D-4829-BE6A-D334C397AD0D-- From nobody Wed Sep 3 11:52:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F1EF1A04F8 for ; Wed, 3 Sep 2014 11:52:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3z_iZtxeYqXj for ; Wed, 3 Sep 2014 11:52:45 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADDA51A04C5 for ; Wed, 3 Sep 2014 11:52:45 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id B7FFC2AAFE5; Wed, 3 Sep 2014 18:52:44 +0000 (UTC) Date: Wed, 3 Sep 2014 18:52:44 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140903185244.GV14392@mournblade.imrryr.org> References: <54048985.1020005@net.in.tum.de> <3EB754B7-F6B2-4207-A2F0-E61F32EE1E40@ll.mit.edu> <54075016.6040406@net.in.tum.de> <20140903174958.GF14392@mournblade.imrryr.org> <5407574B.5060708@net.in.tum.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5407574B.5060708@net.in.tum.de> User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/a8mZWJaqW2K7kDkjFAN5qdHLdBk Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@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: Wed, 03 Sep 2014 18:52:50 -0000 On Wed, Sep 03, 2014 at 08:00:43PM +0200, Ralph Holz wrote: > > This is still too strong. Local MTA to Mail-Store LMTP is an > > application protocol. It is a fine use-case for NULL ciphers. > > I hear you (and the others), but balancing the purpose of the BCP with > such requirements as you mention leads me to believe we should favour > the solution I proposed. I added one more thing, though: > > "Note: TLS implementations MAY retain code for the NULL cipher to allow > specialised purposes like debugging, custom solutions, etc." I can probably live with that. > That "custom solution" - to me - seems to address what you describe. I > see no other way to balance the requirements. > > If the vote were black/white between dropping and keeping, I'd favour > dropping, by the way. I'd rather protect the many. While probably not an issue in this case, we need to be careful when trying to "raise the bar" to "protect the many". If the bar is raised too high, the obvious operator solution is to switch to cleartext, no security impediments there. :-( Don't let the perfect be the enemy of the good. Ciao. -- Viktor. From nobody Wed Sep 3 11:53:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA9B1A04F8 for ; Wed, 3 Sep 2014 11:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.596 X-Spam-Level: X-Spam-Status: No, score=-1.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7j_x1KhZmbs for ; Wed, 3 Sep 2014 11:53:39 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0BB11A070C for ; Wed, 3 Sep 2014 11:53:37 -0700 (PDT) Received: from mail-yk0-f182.google.com (mail-yk0-f182.google.com [209.85.160.182]) by mrelayeu.kundenserver.de (node=mreue005) with ESMTP (Nemesis) id 0M6AEI-1YMBrZ3iPq-00yAzA; Wed, 03 Sep 2014 20:53:36 +0200 Received: by mail-yk0-f182.google.com with SMTP id 19so5347114ykq.13 for ; Wed, 03 Sep 2014 11:53:32 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.199.212 with SMTP id x60mr6491765yhn.127.1409770412553; Wed, 03 Sep 2014 11:53:32 -0700 (PDT) Received: by 10.170.129.17 with HTTP; Wed, 3 Sep 2014 11:53:32 -0700 (PDT) In-Reply-To: <855346194.42619687.1409760390854.JavaMail.zimbra@redhat.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> <20140903140059.GW14392@mournblade.imrryr.org> <1243278676.42405953.1409754600887.JavaMail.zimbra@redhat.com> <20140903145553.GA14392@mournblade.imrryr.org> <855346194.42619687.1409760390854.JavaMail.zimbra@redhat.com> Date: Wed, 3 Sep 2014 20:53:32 +0200 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=bcaec52c6223a7bdc705022dc04c X-Provags-ID: V02:K0:eIs837el9obglvsPXVmTpfydn7sn7QYlyKkeVuK9uHd Vsd5FyW/d5qRcGel+NJdARepcc/geXyai4xrIqxqf1iblWpmAQ DzB6LmjL2E2aMUJY7lXMSrIa36OtqKrckcwOrwrWJRwHrEVNM1 lwMQE2tqW9h5IvBarbxwQ1VtM4EeHc0a61iOt7yg1CSGnq2JCF UF4hkd3otE3zXnyKQ6RFQcCH2YOb1GnaFS/yqXEU/o12YtXcrC bE2qUy2RuEAa75by/u+DCs52PWxVRIqIUUzo5OD0Gm8w91Cs4k SVbGeemLjeIlnUJA65zCRr1yqGTP9jMlFHKFGjEsV5xE50KM7u 6M4h+zyPnKZ0LjO97Q5enLRY9mxQrxOwCTKxGLBduKkBZHJqlU H5A+jskIUfU15HsAFjSy0fCc3z1F/Pv2Bs3NdO5zO+c+lRLw/p PUbhT X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JHgchR4ak8WkbYyt3-pKgdQPQ_I Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 18:53:41 -0000 --bcaec52c6223a7bdc705022dc04c Content-Type: text/plain; charset=UTF-8 Hubert Kario : Session resumption is an optional functionality, and yet we're ready to > forfeit PFS just for ease of implementation of it for big deployments. I'm certainly not willing to forfeit forward secrecy (although I wouldn't want to call it "perfect" forward secrecy ever, and certainly not if we're allowing *any* kind of session caching); hence http://marc.info/?l=openssl-cvs&m=128283567020551, but of course, that one's not very practical for most use cases -- that's one tradeoff: encrypted session tickets are another. I do think that RFC 5077 is problematic in that it makes it too easy to get key management wrong, and has incomplete Security Considerations. That's among the reasons why I'd prefer to have a clearer separation between the wire protocol (which doesn't depend on "tickets" being tickets, as opposed to random IDs) and the actual ticket-encryption mechanism. Then protocol implementations would be able to use much of the same code with a server-side session cache (which generally seems to be the most reasonable default) and with encrypted session tickets (which generally require more of a set-up to use securely). Of course, it's also possible to lose forward secrecy via a server-side session cache. Maybe you're just not expiring entries properly, maybe your session store gets backed up daily, whatever. Avoiding session tickets is no panacea. Bodo --bcaec52c6223a7bdc705022dc04c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hube= rt Kario <hkario@redhat.com>:

Session resumption is an optional functionality, and yet we're ready to=
forfeit PFS just for ease of implementation of it for big deployments.

I'm certainly not willing to forfeit forwar= d secrecy (although I wouldn't want to call it "perfect" forw= ard secrecy ever, and certainly not if we're allowing *any* kind of ses= sion caching); hence http://marc.info/?l=3Dopenssl-cvs&m= =3D128283567020551, but of course, that one's not very practical fo= r most use cases -- that's one tradeoff: encrypted session tickets are = another.

I do think that RFC 5077 is problematic in that it make= s it too easy to get key management wrong, and has incomplete Security Cons= iderations. That's among the reasons why I'd prefer to have a clear= er separation between the wire protocol (which doesn't depend on "= tickets" being tickets, as opposed to random IDs) and the actual ticke= t-encryption mechanism. Then protocol implementations would be able to use = much of the same code with a server-side session cache (which generally see= ms to be the most reasonable default) and with encrypted session tickets (w= hich generally require more of a set-up to use securely).

Of course, it's also possible to lose forward secre= cy via a server-side session cache. Maybe you're just not expiring entr= ies properly, maybe your session store gets backed up daily, whatever. Avoi= ding session tickets is no panacea.

Bodo

--bcaec52c6223a7bdc705022dc04c-- From nobody Wed Sep 3 11:57:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D25F51A0709 for ; Wed, 3 Sep 2014 11:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.218 X-Spam-Level: X-Spam-Status: No, score=-7.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bWO1EsQesE2M for ; Wed, 3 Sep 2014 11:57:22 -0700 (PDT) Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2F241A06EE for ; Wed, 3 Sep 2014 11:57:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,459,1406584800"; d="asc'?scan'208";a="92892411" Received: from d-burl-bng2-64-223-164-252.ngn.east.myfairpoint.net (HELO [10.0.1.2]) ([64.223.164.252]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 03 Sep 2014 20:57:18 +0200 Content-Type: multipart/signed; boundary="Apple-Mail=_59A27FBB-C695-442C-A19B-ED3E8A215AC5"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Karthikeyan Bhargavan In-Reply-To: Date: Wed, 3 Sep 2014 14:57:14 -0400 Message-Id: References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> <20140903140059.GW14392@mournblade.imrryr.org> <1243278676.42405953.1409754600887.JavaMail.zimbra@redhat.com> <540728CE.6080305@fussenegger.info> <1589581250.42632708.1409761318984.JavaMail.zimbra@redhat.com> <20140903163948.GE14392@mournblade.imrryr.org> <18E884D9-204D-4D90-9DAF-3BFE8086732D@inria.fr> To: Martin Thomson X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vN6dRQpyGuh8_dIjsmqdtEF2pBs Cc: "tls@ietf.org" Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 18:57:25 -0000 --Apple-Mail=_59A27FBB-C695-442C-A19B-ED3E8A215AC5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > As long as we address the master secret manipulation attack properly, > the ability of an attacker to generate a ticket that is both a) > accepted by the honest server and b) corresponds to the master (or > pre-master) that both client and server will use, is limited. True, but if we use a 0RTT resumption scenario where the client starts=20= sending data immediately without waiting to see whether the server = accepted the ticket,=20 then this data is forfeit. >=20 > Add to that the fact that integrity and confidentiality protections on > the ticket need to be adequate. That ensures that tickets can't be > decrypted or synthesized. >=20 > While I think that Bodo's suggestion regarding a single mechanism is > basically OK, I don't think we should punt the description of tickets > and these concerns to another document. I'd prefer if we pull all > forms of resumption in to the main TLS 1.3 draft and have the > considerations properly articulated there. It's not as though we > don't have the information already at hand. --Apple-Mail=_59A27FBB-C695-442C-A19B-ED3E8A215AC5 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUB2SKAAoJEB/WSo9veuUKr6cIAIBlpd3LhEb50GimlSFB2uEU jWE8xG89vbKl5ic+ErerJKLirN99atByEViXLLWulewWq8Fzk3jXZnKrWXHiau4x 7+r6zeXYZygiEY32YTrnjh7NjkR/FV84DIMZs81OrSHA3zIRFZXGCHM4iKgX+cyU qKdC/OdAfsndR2kSACl2VDdTb0jIYstn0OE1fChaO9mG4bgPHDODi6kqJ+NgCS8j JwfWlnVfNiHlwrBWazE/eDSSqcH7tVom6ddqvwX7rZzz1Bt8LGY78McrcL0P3iVC D/Goy1iuSBIUsAtm0t/zHn3DZmJWG5vqSKpW0RVihmr4IPOmUMo799h6GQx3zvM= =a02p -----END PGP SIGNATURE----- --Apple-Mail=_59A27FBB-C695-442C-A19B-ED3E8A215AC5-- From nobody Wed Sep 3 12:00:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C9C61A0AED for ; Wed, 3 Sep 2014 12:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.569 X-Spam-Level: X-Spam-Status: No, score=-7.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ykuPIPwjtxLZ for ; Wed, 3 Sep 2014 12:00:49 -0700 (PDT) Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by ietfa.amsl.com (Postfix) with ESMTP id BA0F11A6EEF for ; Wed, 3 Sep 2014 12:00:45 -0700 (PDT) Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s83J0WdN008036; Wed, 3 Sep 2014 15:00:34 -0400 Date: Wed, 3 Sep 2014 15:00:32 -0400 (EDT) From: Hubert Kario To: "Richard Fussenegger, BSc" Message-ID: <15972987.43899141.1409770832774.JavaMail.zimbra@redhat.com> In-Reply-To: <5407543F.9020209@fussenegger.info> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <20140903140059.GW14392@mournblade.imrryr.org> <1243278676.42405953.1409754600887.JavaMail.zimbra@redhat.com> <540728CE.6080305@fussenegger.info> <1589581250.42632708.1409761318984.JavaMail.zimbra@redhat.com> <5407460F.1030707@fussenegger.info> <1474051094.43389347.1409763944473.JavaMail.zimbra@redhat.com> <5407543F.9020209@fussenegger.info> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_43899140_1949563959.1409770832773" X-Originating-IP: [10.5.82.7] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922) Thread-Topic: tickets or sesssions or both (oh my) Thread-Index: d7xIj4OFAaBlefIIDulx4bCj2OAPSw== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cGPZhpttW7ZLOzKhyO7gud6Bl7k Cc: tls@ietf.org Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 19:00:52 -0000 ------=_Part_43899140_1949563959.1409770832773 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Richard Fussenegger, BSc" > To: "Hubert Kario" > Cc: tls@ietf.org > Sent: Wednesday, September 3, 2014 7:47:43 PM > Subject: Re: [TLS] tickets or sesssions or both (oh my) > On 9/3/2014 7:05 PM, Hubert Kario wrote: > > yes and no. While the "obvious bad" implementation is the result of > > developers, this implementations will stay like this because users will > > demand for their flawed deployments to continue working. Without droppi= ng > > support for tickets, I don't think we can realistically get rid of the = bad > > implementations. >=20 > Actually fixing current implementations wouldn't break anything, because = the > keys would simply start to rotate. Otherwise the admins wouldn't be able = to > restart their flawed web servers ever, as this would apparently break the= ir > complete deployment following your logic. So that's not a valid argument. I'm not saying that we should remove tickets from TLS 1.2. There are many d= eployments that simply don't care for PFS, where the failures in ticket imp= lementations are actually features.=20 I'm talking about refusing to use tickets in TLS 1.3 context. If the server= negotiates TLS 1.3, I say it MUST NOT assign a ticket. Nothing would stop = working,=20 at worst for implementations that ignored IDs, the clients would just perfo= rm full handshake.=20 > > This is a big vs single host deployment difference. >=20 > > I can expect a big deployment to have proper monitoring. For single hos= t > > just > > key rotation or session cache lifetime matters. >=20 > No worries, I understood that. But the joke is, as soon as the software i= s > fixed all small implementations are fixed (well, at least those that are > updating and note that the ones that have a Heartbleed bug shouldn't even > think about PFS). The truth is that developers are lazy (and I include myself in this set too= ) and prefer not to touch code that works. If it is possible to move the ba= d code from TLS 1.2 to TLS 1.3 it will be reused this way. We have real wor= ld examples of people doing it wrong, while we can fix it for the OSS serve= rs, there will always be people that make their own servers (just because o= f NIH, if nothing else) and do it wrong.=20 I'd prefer if the "do it wrong" required more effort than "do it correctly"= .=20 > > > Current implementations of session caches are also flawed. They are > > > shared > > > among many (virtual) hosts and the ID isn't validated against the > > > requested > > > host (well, at least as far as I know; again correct me). > >=20 >=20 > > > Also consider this, if current libraries wouldn't be correctly > > > implementing > > > the TTL of session caches, wouldn't this system face the same problem= ? > >=20 >=20 > > No - because if they didn't implement TTL for cache, they would quickly= run > > out of memory and stop working (probably trashing the whole server in > > process). That would be an obvious error. >=20 > > It's hard to get IDs wrong. And if you do, you won't compromise PFS (sh= ort > > of > > exporting master secret as the ID...). >=20 > > It's easy to get tickets wrong. And if you do, you can hide it well eno= ugh > > that without source code access you won't be able to detect it. >=20 > You're most certainly correct here with the memory limit regarding TTLs a= nd I > only meant it as a mind game and not like actually implementing it. Re-re= ad > it and you'll notice. ;-) > But don't jump right over the Virtual Host Confusion [1] problem. That's = a > realistic problem for all and was used against Akamai [2], Pinterest [3], > Dropbox [4], =E2=80=A6 which I assume using clusters. How can we detect i= t? Well, go > over the source code. > Same problem, different implementation. > Richard > [1] https://bh.ht.vc/vhost_confusion.pdf > [2] https://www.youtube.com/watch?v=3DYKD-i4HbbGg > [3] https://www.youtube.com/watch?v=3Dh0VhFlTP2xw > [4] https://www.youtube.com/watch?v=3DCkOGKi0pKdk I haven't analysed the attack in detail, but wouldn't a straight forward im= plementation of tickets have the same issue?=20 --=20 Regards,=20 Hubert Kario=20 Quality Engineer, QE BaseOS Security team=20 Email: hkario@redhat.com=20 Web: www.cz.redhat.com=20 Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic=20 ------=_Part_43899140_1949563959.1409770832773 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


Fr= om: "Richard Fussenegger, BSc" <richard@fussenegger.info>
T= o: "Hubert Kario" <hkario@redhat.com>
Cc: tls@ietf.org<= br>Sent: Wednesday, September 3, 2014 7:47:43 PM
Subject: = Re: [TLS] tickets or sesssions or both (oh my)


On 9/3/2014 7:05 PM, Hubert Kario wrote:

yes and no. While the "ob= vious bad" implementation is the result of developers, this implementations will stay like this because users will demand for their flawed deployments to continue working. Without dropping support for tickets, I don't think we can realistically get rid of the bad implementations.

Actually fixing current implementations wouldn't break anything, because the keys would simply start to rotate. Otherwise the admins wouldn't be able to restart their flawed web servers ever, as this would apparently break their complete deployment following your logic. So that's not a valid argument.

= I'm not saying that we should remove tickets from TLS 1.2. There are many d= eployments that simply don't care for PFS, where the failures in ticket imp= lementations are actually features.

I'm talkin= g about refusing to use tickets in TLS 1.3 context. If the server negotiate= s TLS 1.3, I say it MUST NOT assign a ticket. Nothing would stop working,
at worst for implementations that ignored IDs, the clients wou= ld just perform full handshake.



This is a big = vs single host deployment difference.
I can expect a big depl= oyment to have proper monitoring. For single host just key rotation or session cache lifetime matters.

No worries, I understood that. But the joke is, as soon as the software is fixed all small implementations are fixed (well, at least those that are updating and note that the ones that have a Heartbleed bug shouldn't even think about PFS).

The truth is that developers are lazy (and I include myself in thi= s set too) and prefer not to touch code that works. If it is possible to mo= ve the bad code from TLS 1.2 to TLS 1.3 it will be reused this way. We have= real world examples of people doing it wrong, while we can fix it for the = OSS servers, there will always be people that make their own servers (just = because of NIH, if nothing else) and do it wrong.

<= div>I'd prefer if the "do it wrong" required more effort than "do it correc= tly".



Current implementations of session caches are also flawed. They are shared among many (virtual) hosts and the ID isn't validated against the requested host (well, at least as far as I know; again correct me).

Also consider this, if current libraries wouldn't be correctly implementing the TTL of session caches, wouldn't this system face the same problem?

No - becau= se if they didn't implement TTL for cache, they would quickly run out of memory and stop working (probably trashing the whole server in process). That would be an obvious error.

It's hard to get IDs = wrong. And if you do, you won't compromise PFS (short of exporting master secret as the ID...).
It's easy to get tickets wrong. And if you = do, you can hide it well enough that without source code access you won't be able to detect it.

You're most certainly correct here with the memory limit regarding TTLs and I only meant it as a mind game and not like actually implementing it. Re-read it and you'll notice. ;-)

But don't jump right over the Virtual Host Confusion [1] problem. That's a realistic problem for all and was used against Akamai [2], Pinterest [3], Dropbox [4], =E2=80=A6 which I assume using clusters. Ho= w can we detect it? Well, go over the source code.

Same problem, different implementation.

Richard

[1] https://bh.ht.vc/vhost_confusion.pdf [2] https://www.youtube.com/watch?v=3D= YKD-i4HbbGg
[3] https://www.youtube.com/watch?v=3D= h0VhFlTP2xw
[4] https://www.youtube.com/watch?v=3D= CkOGKi0pKdk

I haven't analysed the attack in d= etail, but wouldn't a straight forward implementation of tickets have the s= ame issue?

--
= Regards,
Hubert Kario
Quality Engineer, QE BaseOS Security tea= m
Email: hkario@redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.= r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic
------=_Part_43899140_1949563959.1409770832773-- From nobody Wed Sep 3 12:28:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D89D51A6EFC for ; Wed, 3 Sep 2014 12:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s9yyH7tsDDQj for ; Wed, 3 Sep 2014 12:28:53 -0700 (PDT) Received: from mx201.easyname.com (mx201.easyname.com [212.232.28.122]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F1FE1A0691 for ; Wed, 3 Sep 2014 12:28:53 -0700 (PDT) Received: from 89-26-76-175.goll.dyn.salzburg-online.at ([89.26.76.175] helo=[192.168.0.11]) by mx.easyname.eu with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XPGEb-0006fy-Ag; Wed, 03 Sep 2014 21:28:51 +0200 Message-ID: <54076BE7.7070500@fussenegger.info> Date: Wed, 03 Sep 2014 21:28:39 +0200 From: "Richard Fussenegger, BSc" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Hubert Kario References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <20140903140059.GW14392@mournblade.imrryr.org> <1243278676.42405953.1409754600887.JavaMail.zimbra@redhat.com> <540728CE.6080305@fussenegger.info> <1589581250.42632708.1409761318984.JavaMail.zimbra@redhat.com> <5407460F.1030707@fussenegger.info> <1474051094.43389347.1409763944473.JavaMail.zimbra@redhat.com> <5407543F.9020209@fussenegger.info> <15972987.43899141.1409770832774.JavaMail.zimbra@redhat.com> In-Reply-To: <15972987.43899141.1409770832774.JavaMail.zimbra@redhat.com> Content-Type: multipart/alternative; boundary="------------020607080602010209090405" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/A0tnu1gdWE7g-1-3IS9b5hfK2D4 Cc: tls@ietf.org Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 19:28:56 -0000 This is a multi-part message in MIME format. --------------020607080602010209090405 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 9/3/2014 9:00 PM, Hubert Kario wrote: > > I'm not saying that we should remove tickets from TLS 1.2. There are > many deployments that simply don't care for PFS, where the failures in > ticket implementations are actually features. > > I'm talking about refusing to use tickets in TLS 1.3 context. If the > server negotiates TLS 1.3, I say it MUST NOT assign a ticket. Nothing > would stop working, > at worst for implementations that ignored IDs, the clients would just > perform full handshake. > Got your point there, that's the main discussion here and I'm a friend of the ticket approach because it removes the burden from the servers to maintain a cache. But TLS 1.3 would have to be changed to say that keys MUST be rotated at least within 24 hours. This would be backwards compatible as well and ensure PFS. Of course the problem with a compromised server to which we sync the key is still in the room. As I said, I'd love to go into more detail on this topic. But the question here is more like “how can we detect that a server is compromised?” The same question in regards to session caches. If a compromised server doesn't start to behave totally weird it's going to be very hard to detect it. Plus, is this even a problem of TLS per se? What if the server maintaining the session cache is compromised, how do we tackle that (with TLS)? You'll notice that there are many questions that have nothing to do with the protocol. > > The truth is that developers are lazy (and I include myself in this > set too) and prefer not to touch code that works. If it is possible to > move the bad code from TLS 1.2 to TLS 1.3 it will be reused this way. > We have real world examples of people doing it wrong, while we can fix > it for the OSS servers, there will always be people that make their > own servers (just because of NIH, if nothing else) and do it wrong. > > I'd prefer if the "do it wrong" required more effort than "do it > correctly". > As I see it right now, both cache and tickets are easy to get wrong and the only thing that's currently implemented wrong in regards to tickets is the fact that servers aren't rotating them. So it's a minor fix and I'm currently looking into the nginx source code to see if I'm able to create a patch for it. > > I haven't analysed the attack in detail, but wouldn't a straight > forward implementation of tickets have the same issue? > Yes, both approaches have the same issue and it's something that developers have to fix in general. Just like the fail to implement rotation, but at least a tech savvy admin can fix the rotation problem (e.g. via a cron job that restarts the server, although loosing decryption capability for the last used key). Only the developers are able to fix the virtual host confusion problem. I may look into this as well, but I'm not a dedicated C developer and this looks like a bigger problem. Richard --------------020607080602010209090405 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit On 9/3/2014 9:00 PM, Hubert Kario wrote:

I'm not saying that we should remove tickets from TLS 1.2. There are many deployments that simply don't care for PFS, where the failures in ticket implementations are actually features.

I'm talking about refusing to use tickets in TLS 1.3 context. If the server negotiates TLS 1.3, I say it MUST NOT assign a ticket. Nothing would stop working,
at worst for implementations that ignored IDs, the clients would just perform full handshake.

Got your point there, that's the main discussion here and I'm a friend of the ticket approach because it removes the burden from the servers to maintain a cache. But TLS 1.3 would have to be changed to say that keys MUST be rotated at least within 24 hours. This would be backwards compatible as well and ensure PFS.

Of course the problem with a compromised server to which we sync the key is still in the room. As I said, I'd love to go into more detail on this topic. But the question here is more like “how can we detect that a server is compromised?” The same question in regards to session caches. If a compromised server doesn't start to behave totally weird it's going to be very hard to detect it. Plus, is this even a problem of TLS per se? What if the server maintaining the session cache is compromised, how do we tackle that (with TLS)? You'll notice that there are many questions that have nothing to do with the protocol.


The truth is that developers are lazy (and I include myself in this set too) and prefer not to touch code that works. If it is possible to move the bad code from TLS 1.2 to TLS 1.3 it will be reused this way. We have real world examples of people doing it wrong, while we can fix it for the OSS servers, there will always be people that make their own servers (just because of NIH, if nothing else) and do it wrong.

I'd prefer if the "do it wrong" required more effort than "do it correctly".

As I see it right now, both cache and tickets are easy to get wrong and the only thing that's currently implemented wrong in regards to tickets is the fact that servers aren't rotating them. So it's a minor fix and I'm currently looking into the nginx source code to see if I'm able to create a patch for it.


I haven't analysed the attack in detail, but wouldn't a straight forward implementation of tickets have the same issue?

Yes, both approaches have the same issue and it's something that developers have to fix in general. Just like the fail to implement rotation, but at least a tech savvy admin can fix the rotation problem (e.g. via a cron job that restarts the server, although loosing decryption capability for the last used key). Only the developers are able to fix the virtual host confusion problem. I may look into this as well, but I'm not a dedicated C developer and this looks like a bigger problem.

Richard
--------------020607080602010209090405-- From nobody Wed Sep 3 12:35:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 704931A065B for ; Wed, 3 Sep 2014 12:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W02EpLz5EBk6 for ; Wed, 3 Sep 2014 12:35:34 -0700 (PDT) Received: from dragaera.releasedominatrix.com (dragaera.releasedominatrix.com [216.129.105.14]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6081E1A6F91 for ; Wed, 3 Sep 2014 12:35:08 -0700 (PDT) Received: by dragaera.releasedominatrix.com (Postfix, from userid 501) id E5D9E33D0AA; Wed, 3 Sep 2014 19:35:03 +0000 (UTC) Sender: geoffk@localhost.localdomain To: "Blumenthal, Uri - 0558 - MITLL" References: <54048985.1020005@net.in.tum.de> <3EB754B7-F6B2-4207-A2F0-E61F32EE1E40@ll.mit.edu> From: Geoffrey Keating Date: 03 Sep 2014 12:35:03 -0700 In-Reply-To: <3EB754B7-F6B2-4207-A2F0-E61F32EE1E40@ll.mit.edu> Message-ID: Lines: 19 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Tv_qf-VED_qQvMQ7czehRknGoPg Cc: tls@ietf.org Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 19:35:36 -0000 "Blumenthal, Uri - 0558 - MITLL" writes: > On Sep 3, 2014, at 06:34 , Yutaka OIWA wrote: > > The document title is > > "Recommendations for Secure Use of TLS and DTLS", > > clearly applicable for the "Secure Uses". It also says > > "These are minimum recommendations for the general use of TLS." > ^^^^^^^^ > Exactly. > > > For the purposes of such secure and general use cases, > > NULL ciphers are clearly "MUST NOT" with no doubt. > > "Clearly" and "with no doubt"? With respect, this doesn't seem to be > your field of expertise. This is my field of expertise, and I agree that for the purpose of secure and general use cases, NULL ciphers are both clearly and without a doubt "MUST NOT". From nobody Wed Sep 3 12:36:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0DD51A0659 for ; Wed, 3 Sep 2014 12:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.866 X-Spam-Level: X-Spam-Status: No, score=-4.866 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xDy50JgoROpr for ; Wed, 3 Sep 2014 12:36:01 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 42E761A6F6B for ; Wed, 3 Sep 2014 12:35:59 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s83JZn3G019382; Wed, 3 Sep 2014 15:35:57 -0400 Content-Type: multipart/alternative; boundary="Apple-Mail=_D6A3ABD4-E15C-4169-8053-2E3A0AF450CE" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Blumenthal, Uri - 0668 - MITLL" In-Reply-To: <14f6960e-e625-4252-ad7d-2bf8295f71fc@email.android.com> Date: Wed, 3 Sep 2014 15:35:07 -0400 Message-ID: <9D33A9AF-5613-49DD-B024-DD5CDA49CFC9@ll.mit.edu> References: <54048985.1020005@net.in.tum.de> <3EB754B7-F6B2-4207-A2F0-E61F32EE1E40@ll.mit.edu> <54075016.6040406@net.in.tum.de> <20140903174958.GF14392@mournblade.imrryr.org> <5407574B.5060708@net.in.tum.de> <9120B6EE-F023-4724-9116-A169993F58E8@ll.mit.edu> <14f6960e-e625-4252-ad7d-2bf8295f71fc@email.android.com> To: Ralph Holz X-Mailer: Apple Mail (2.1878.6) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.27, 0.0.0000 definitions=2014-09-03_08:2014-09-03,2014-09-03,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-1402240000 definitions=main-1409030206 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/q_Am-hV9w05YtMu6e5QXNK860W0 Cc: "" Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 19:36:03 -0000 --Apple-Mail=_D6A3ABD4-E15C-4169-8053-2E3A0AF450CE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252" On Sep 3, 2014, at 15:23 , Ralph Holz wrote: > MUST NOT is correct. Nowhere does RFC2119 say that the term deployment = equals implementation in code. Misunderstanding of the RFC, IMHO. > You are welcome to bring up your strong feelings in UTA. I=92m doing that. 1. Draft is poorly written because terms like =93completely insecure=94 = without context of threats are completely meaningless (page 6, bottom). 2. Giving recommendations for =93secure use=94 without defining what the = goals are is again meaningless. But if you insist on making this document irrelevant - it=92s your right = to do so. > On 3 September 2014 20:46:51 CEST, "Blumenthal, Uri - 0668 - MITLL" = wrote: > On Sep 3, 2014, at 14:00 , Ralph Holz wrote: > That will make it clear that implementers are free to retain NULL = (and > they will), but that the purpose of the BCP is to propose secure TLS > configurations to protect application-layer protocols, and for those = no > deployment should ever negotiate NULL. > =20 > This is still too strong. Local MTA to Mail-Store LMTP is an > application protocol. It is a fine use-case for NULL ciphers. > =20 > I hear you (and the others), but balancing the purpose of the BCP = with > such > requirements as you mention leads me to believe we should favour > the solution I proposed. I added one more thing, though: > =20 > "Note: TLS implementations MAY retain code for the NULL cipher to = allow > specialised purposes like debugging, custom solutions, etc.=94 >=20 > Guys,=20 >=20 > Per RFC2119, certain words have certain meanings. :-) >=20 > In particular, =93MUST NOT=94 means not that =93don=92t do that unless = you can claim an exception=94. It means =93don=92t do that as it is = absolutely prohibited by this spec, no exception=94. >=20 > What you probably want to specify here is =93SHOULD NOT=94. >=20 > Before replying - please check with RFC 2119. It=92s three pages long, = so wouldn=92t take much of your time. >=20 > (P.S. I wish people got really familiar with the standard terminology = before trying to write/edit a standard.) >=20 > --=20 > Sent from my Android device with K-9 Mail. Please excuse my brevity. --Apple-Mail=_D6A3ABD4-E15C-4169-8053-2E3A0AF450CE Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="windows-1252" On Sep = 3, 2014, at 15:23 , Ralph Holz <ralph@ralphholz.de> = wrote:
MUST NOT is correct. Nowhere does = RFC2119 say that the term deployment equals implementation in = code.

Misunderstanding of the RFC, = IMHO.

You are welcome to bring up your strong = feelings in UTA.

I=92m doing = that.

1. Draft is poorly written because terms = like =93completely insecure=94 without context of threats are completely = meaningless (page 6, bottom).

2. Giving = recommendations for =93secure use=94 without defining what the goals are = is again meaningless.

But if you insist on = making this document irrelevant - it=92s your right to do = so.



On 3 September 2014 20:46:51 CEST, "Blumenthal, = Uri - 0668 - MITLL" <uri@ll.mit.edu> wrote:
On Sep 3, =
2014, at 14:00 , Ralph Holz <holz@net.in.tum.de> =
wrote:
 That will make it clear that implementers are free =
to retain NULL (and
 they will), but that the purpose of the BCP is =
to propose secure TLS
 configurations to protect application-layer =
protocols, and for those no
 deployment should ever negotiate =
NULL.
 
 This is still too strong.  Local MTA to =
Mail-Store LMTP is an
 application protocol.  It is a fine use-case =
for NULL ciphers.
 
 I hear you (and the others), but =
balancing the purpose of the BCP with
 such
requirements as you mention leads me to believe we should favour
 the =
solution I proposed. I added one more thing, though:
 
 "Note: TLS =
implementations MAY retain code for the NULL cipher to allow
 =
specialised purposes like debugging, custom solutions, =
etc.=94

Guys, 

Per RFC2119, certain words =
have certain meanings. :-)

In particular, =93MUST NOT=94 means =
not that =93don=92t do that unless you can claim an exception=94. It =
means =93don=92t do that as it is absolutely prohibited by this spec, no =
exception=94.

What you probably want to specify here is =93SHOULD =
NOT=94.

Before replying - please check with RFC 2119. It=92s =
three pages long, so wouldn=92t take much of your time.

(P.S. I =
wish people got really familiar with the standard terminology before =
trying to write/edit a standard.)

-- 
Sent from my Android = device with K-9 Mail. Please excuse my = brevity.

= --Apple-Mail=_D6A3ABD4-E15C-4169-8053-2E3A0AF450CE-- From nobody Wed Sep 3 12:41:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33BEF1A6F4B for ; Wed, 3 Sep 2014 12:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2rKJW1p4R9Dh for ; Wed, 3 Sep 2014 12:41:14 -0700 (PDT) Received: from smtp.serverkommune.de (serverkommune.de [176.9.61.43]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FA411A6F42 for ; Wed, 3 Sep 2014 12:41:14 -0700 (PDT) Received: by smtp.serverkommune.de (Postfix, from userid 5001) id 2270880243; Wed, 3 Sep 2014 21:41:13 +0200 (CEST) Received: from [192.168.178.34] (ex6.serverkommune.de [176.9.61.43]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.serverkommune.de (Postfix) with ESMTPSA id 6F486801AC for ; Wed, 3 Sep 2014 21:41:12 +0200 (CEST) Message-ID: <54076ED7.4010701@net.in.tum.de> Date: Wed, 03 Sep 2014 21:41:11 +0200 From: Ralph Holz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: tls@ietf.org References: <54048985.1020005@net.in.tum.de> <3EB754B7-F6B2-4207-A2F0-E61F32EE1E40@ll.mit.edu> <54075016.6040406@net.in.tum.de> <20140903174958.GF14392@mournblade.imrryr.org> <5407574B.5060708@net.in.tum.de> <9120B6EE-F023-4724-9116-A169993F58E8@ll.mit.edu> In-Reply-To: <9120B6EE-F023-4724-9116-A169993F58E8@ll.mit.edu> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.98.1 at ex6 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/tls/N0ob-QGmt8dQLy7Y2ZhbNFIiSss Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 19:41:16 -0000 Good day, MUST NOT is correct. Nowhere does RFC2119 say that the term deployment equals implementation in code. You are welcome to bring up your points in UTA. Ralph On 3 September 2014 20:46:51 CEST, "Blumenthal, Uri - 0668 - MITLL" wrote: >On Sep 3, 2014, at 14:00 , Ralph Holz wrote: >>>> That will make it clear that implementers are free to retain NULL >(and >>>> they will), but that the purpose of the BCP is to propose secure >TLS >>>> configurations to protect application-layer protocols, and for >those no >>>> deployment should ever negotiate NULL. >>> >>> This is still too strong. Local MTA to Mail-Store LMTP is an >>> application protocol. It is a fine use-case for NULL ciphers. >> >> I hear you (and the others), but balancing the purpose of the BCP >with >> such requirements as you mention leads me to believe we should favour >> the solution I proposed. I added one more thing, though: >> >> "Note: TLS implementations MAY retain code for the NULL cipher to >allow >> specialised purposes like debugging, custom solutions, etc.” > >Guys, > >Per RFC2119, certain words have certain meanings. :-) > >In particular, “MUST NOT” means not that “don’t do that unless you can >claim an exception”. It means “don’t do that as it is absolutely >prohibited by this spec, no exception”. > >What you probably want to specify here is “SHOULD NOT”. > >Before replying - please check with RFC 2119. It’s three pages long, so >wouldn’t take much of your time. > >(P.S. I wish people got really familiar with the standard terminology >before trying to write/edit a standard.) -- Sent from my Android device with K-9 Mail. Please excuse my brevity. -- Ralph Holz I8 - Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18043 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF From nobody Wed Sep 3 12:50:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 456261A6F79 for ; Wed, 3 Sep 2014 12:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyQy8Sonw2Fm for ; Wed, 3 Sep 2014 12:50:22 -0700 (PDT) Received: from smtp.serverkommune.de (serverkommune.de [176.9.61.43]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B3DB1A6F91 for ; Wed, 3 Sep 2014 12:49:55 -0700 (PDT) Received: by smtp.serverkommune.de (Postfix, from userid 5001) id A1FCF8053C; Wed, 3 Sep 2014 21:49:53 +0200 (CEST) Received: from [192.168.178.34] (ex6.serverkommune.de [176.9.61.43]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.serverkommune.de (Postfix) with ESMTPSA id DD7F58042F; Wed, 3 Sep 2014 21:49:51 +0200 (CEST) Message-ID: <540770DF.105@net.in.tum.de> Date: Wed, 03 Sep 2014 21:49:51 +0200 From: Ralph Holz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: "Blumenthal, Uri - 0668 - MITLL" References: <54048985.1020005@net.in.tum.de> <3EB754B7-F6B2-4207-A2F0-E61F32EE1E40@ll.mit.edu> <54075016.6040406@net.in.tum.de> <20140903174958.GF14392@mournblade.imrryr.org> <5407574B.5060708@net.in.tum.de> <9120B6EE-F023-4724-9116-A169993F58E8@ll.mit.edu> <14f6960e-e625-4252-ad7d-2bf8295f71fc@email.android.com> <9D33A9AF-5613-49DD-B024-DD5CDA49CFC9@ll.mit.edu> In-Reply-To: <9D33A9AF-5613-49DD-B024-DD5CDA49CFC9@ll.mit.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.98.1 at ex6 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AfPF5aWmd92M9K3Be7eEILJ9kz8 Cc: tls@ietf.org Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 19:50:23 -0000 Good day, >> MUST NOT is correct. Nowhere does RFC2119 say that the term >> deployment equals implementation in code. > > Misunderstanding of the RFC, IMHO. You will need to give evidence if you want others to follow your argument. >> You are welcome to bring up your strong feelings in UTA. > > Im doing that. If you want to, you need to write to the UTA list. Quite possibly, you'll also have to elaborate more than the simple two items you gave here. Ralph -- Ralph Holz I8 - Network Architectures and Services Technische Universitt Mnchen http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18043 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF From nobody Wed Sep 3 13:03:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 204691A0658 for ; Wed, 3 Sep 2014 13:03:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MgldEfRkAFhr for ; Wed, 3 Sep 2014 13:03:47 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 387CC1A6F12 for ; Wed, 3 Sep 2014 13:03:37 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id gl10so10538214lab.10 for ; Wed, 03 Sep 2014 13:03:35 -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=KXs00AizeXMYrEVXo0WQLEEHJnrpU/mtFAx/A8BG1l0=; b=O/gEhmkdD3QyhhgbOiLpZebWPq1DQ8i063Z+LxOEYl0CxWjYQXfirIi9mj/52bN/Ju YLq0aiXbLZ2wWKoW+fNGubJxPE2lIoKkkyZdtbdWZxoLiqyj2NWk1CLhqkFZoF9dOfb4 zpIe+JUuYgbAXYBUHsZgHJI9lSMB52fbhWF1vP2iQEFt8HE3blOYewxFuIhQB39d2LA4 fwVvYp8GrRBnyXhk7Mu0GSAJRzGOQ+l4i8SK5xHnYm4sWHCK4a/uQ0mAvdzl/dsHlhpT Hxi68/7mv/TsDC//1ftnPcyUFPl6+ahxgiUtYZMrtw95gmE8mMyM9RB6uvAmjCcc6hl2 SBKA== MIME-Version: 1.0 X-Received: by 10.152.42.209 with SMTP id q17mr6386440lal.13.1409774615578; Wed, 03 Sep 2014 13:03:35 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Wed, 3 Sep 2014 13:03:35 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> <20140903140059.GW14392@mournblade.imrryr.org> <1243278676.42405953.1409754600887.JavaMail.zimbra@redhat.com> <540728CE.6080305@fussenegger.info> <1589581250.42632708.1409761318984.JavaMail.zimbra@redhat.com> <20140903163948.GE14392@mournblade.imrryr.org> <18E884D9-204D-4D90-9DAF-3BFE8086732D@inria.fr> Date: Wed, 3 Sep 2014 13:03:35 -0700 Message-ID: From: Martin Thomson To: Karthikeyan Bhargavan Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HZ3Idk32UDMO4ffiPV_sWsf9bUE Cc: "tls@ietf.org" Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 20:03:50 -0000 On 3 September 2014 11:57, Karthikeyan Bhargavan wrote: > True, but if we use a 0RTT resumption scenario where the client starts > sending data immediately without waiting to see whether the server accepted the ticket, > then this data is forfeit. 0RTT creates some interesting side effects. I wouldn't have characterized the data as forfeit, just that there are certain considerations around the use of that first flight. The keys used to protect that data are different from the previous session, but they are derived from those previous keys. If we do some form of rekeying, I expect that the basis for the resumption keying material won't advance with any rekeying on the previous connection, so the lifetime of that data and corresponding potential for loss or exposure is greater. But the extent to which an attacker might be able to influence that data seems (at least intuitively) to be similar to the data sent on the previous connection. Resumption is less interesting in the 0RTT case than 0RTT without resumption, where the initial flight of data isn't protected with the server's new DH share. That is, it's basically not forward secure. That creates a reason to avoid sending or accepting that first flight. If by forfeit you mean that there is a risk that the data is not accepted by the server, that's a risk that I think is inherent in the design. In addition to the extra computation required to get 0RTT, the client will have to buffer and re-send data in some cases, paying the protection cost twice. Otherwise the API changes, and I don't think anyone wants that. From nobody Wed Sep 3 13:07:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4B81A6EFC for ; Wed, 3 Sep 2014 13:07:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNbwURdUDLLx for ; Wed, 3 Sep 2014 13:07:19 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 68A0E1A0658 for ; Wed, 3 Sep 2014 13:07:19 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 4628536006D for ; Wed, 3 Sep 2014 13:07:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=EcfRwkO/Yt630v0Vc+kv AdklOas=; b=AjfhzdXo83oWBUHAeUrvoKMMufC/qGMypOOoCVeLnqQEZ9DLVb3T jHs6tRH27SDtSt5DHbZI8FwPyOd97lkpKilcN02w8EeAW+91+60M09QFOjOHFfiZ 9EzLQTv5g7XCr5iNZo65HoyXADIOIBQcBFKGsQfit3wNJe94yI2xcwQ= Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPSA id E3E2F36006A for ; Wed, 3 Sep 2014 13:07:18 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id n3so1631354wiv.17 for ; Wed, 03 Sep 2014 13:07:17 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.75.17 with SMTP id y17mr37781613wiv.3.1409774837745; Wed, 03 Sep 2014 13:07:17 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Wed, 3 Sep 2014 13:07:17 -0700 (PDT) In-Reply-To: <540770DF.105@net.in.tum.de> References: <54048985.1020005@net.in.tum.de> <3EB754B7-F6B2-4207-A2F0-E61F32EE1E40@ll.mit.edu> <54075016.6040406@net.in.tum.de> <20140903174958.GF14392@mournblade.imrryr.org> <5407574B.5060708@net.in.tum.de> <9120B6EE-F023-4724-9116-A169993F58E8@ll.mit.edu> <14f6960e-e625-4252-ad7d-2bf8295f71fc@email.android.com> <9D33A9AF-5613-49DD-B024-DD5CDA49CFC9@ll.mit.edu> <540770DF.105@net.in.tum.de> Date: Wed, 3 Sep 2014 15:07:17 -0500 Message-ID: From: Nico Williams To: Ralph Holz Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9dXMt5Azf-Xo7yOPwjp4Ooq42GM Cc: "tls@ietf.org" Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 20:07:20 -0000 On Wed, Sep 3, 2014 at 2:49 PM, Ralph Holz wrote: > Good day, > >>> MUST NOT is correct. Nowhere does RFC2119 say that the term >>> deployment equals implementation in code. >> >> Misunderstanding of the RFC, IMHO. > > You will need to give evidence if you want others to follow your argument. Ralph, Uri is quite right. You really should read RFC2119. Here's the money quote: 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition of the specification. There is absolutely no hedging there. There is no more evidence to post, really. What more could you need? "absolute prohibition" is as clear as it gets. Nico -- From nobody Wed Sep 3 13:12:29 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 195E51A6EFC for ; Wed, 3 Sep 2014 13:12:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.218 X-Spam-Level: X-Spam-Status: No, score=-7.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EI8xisFsuH_4 for ; Wed, 3 Sep 2014 13:12:26 -0700 (PDT) Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 422251A6F25 for ; Wed, 3 Sep 2014 13:12:24 -0700 (PDT) X-IronPort-AV: E=Sophos;i="5.04,459,1406584800"; d="asc'?scan'208";a="77656189" Received: from d-burl-bng2-64-223-164-252.ngn.east.myfairpoint.net (HELO [10.0.1.2]) ([64.223.164.252]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 03 Sep 2014 22:12:21 +0200 Content-Type: multipart/signed; boundary="Apple-Mail=_CF829B1B-B311-422D-B28F-855556BE0322"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Karthikeyan Bhargavan In-Reply-To: Date: Wed, 3 Sep 2014 16:12:18 -0400 Message-Id: References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> <20140903140059.GW14392@mournblade.imrryr.org> <1243278676.42405953.1409754600887.JavaMail.zimbra@redhat.com> <540728CE.6080305@fussenegger.info> <1589581250.42632708.1409761318984.JavaMail.zimbra@redhat.com> <20140903163948.GE14392@mournblade.imrryr.org> <18E884D9-204D-4D90-9DAF-3BFE8086732D@inria.fr> To: Martin Thomson X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZUsfhU1CeaDGAwAXljywQU6L8nc Cc: "tls@ietf.org" Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 20:12:28 -0000 --Apple-Mail=_CF829B1B-B311-422D-B28F-855556BE0322 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I apologize for lack of clarity. By =93forfeit=94 I meant the following = scenario, where a malicious server gets to read data sent to an honest = server: Connection 1: C connects to malicious S=20 S sends it a session ticket T which C stores. Connection 2: C wants to connect to honest S=92. C (incorrectly) uses the session ticket T to initiate resumption. C optimistically encrypts sensitive data meant for S=92 (e.g. cookies) = under a key derived from (the master secret in) T. Result: S gets to read data that C was sending to S=92. Now, here, the fault is that C incorrectly cached T, so that it used T = with S=92 (whereas it should only be used with S). This can easily happen if e.g. C=92s client-side cache was indexed only = an IP address and port. The question is what is the identity of S that C should use when storing = the ticket? Can we give some recommendations? On 03 Sep 2014, at 16:03, Martin Thomson = wrote: > On 3 September 2014 11:57, Karthikeyan Bhargavan > wrote: >> True, but if we use a 0RTT resumption scenario where the client = starts >> sending data immediately without waiting to see whether the server = accepted the ticket, >> then this data is forfeit. >=20 > 0RTT creates some interesting side effects. I wouldn't have > characterized the data as forfeit, just that there are certain > considerations around the use of that first flight. The keys used to > protect that data are different from the previous session, but they > are derived from those previous keys. If we do some form of rekeying, > I expect that the basis for the resumption keying material won't > advance with any rekeying on the previous connection, so the lifetime > of that data and corresponding potential for loss or exposure is > greater. But the extent to which an attacker might be able to > influence that data seems (at least intuitively) to be similar to the > data sent on the previous connection. >=20 > Resumption is less interesting in the 0RTT case than 0RTT without > resumption, where the initial flight of data isn't protected with the > server's new DH share. That is, it's basically not forward secure. > That creates a reason to avoid sending or accepting that first flight. >=20 > If by forfeit you mean that there is a risk that the data is not > accepted by the server, that's a risk that I think is inherent in the > design. In addition to the extra computation required to get 0RTT, > the client will have to buffer and re-send data in some cases, paying > the protection cost twice. Otherwise the API changes, and I don't > think anyone wants that. --Apple-Mail=_CF829B1B-B311-422D-B28F-855556BE0322 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJUB3YiAAoJEB/WSo9veuUKBHoIAKAwNk+n8jbEAr80GCryvFKF iQ+tBCiIck4ncwsvIBAS+IojfZ3kDkDppvFL8lgn9u22qdTeBeFPtxGRAA7tCfjg 6ELwUvsz/hQlHGB0SVwULhv0/rRbADne2kFrfDb0+vX0J2GSmdEYmVqJRFkH7d9n Ym+7LtPXefwVPzV15WbTzwHhM3btdVJeMBQ+QN5B6CCH972SEjipWOFc7aGOJ+AG Rm7yPIDvuqs0cGE9WQe+JsJql2k5bbNKK4WymvgcQ7JhDcE1q4G+HOvL2RwEAQGb 39YD2e+O1BNrRH3iPlMRZqZ0gkS287uop3MwC0PIZS27TQpGe886Yzix4I4dmMg= =5eM6 -----END PGP SIGNATURE----- --Apple-Mail=_CF829B1B-B311-422D-B28F-855556BE0322-- From nobody Wed Sep 3 13:16:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 519FA1A6EFC for ; Wed, 3 Sep 2014 13:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r_yhMBsa4gKm for ; Wed, 3 Sep 2014 13:16:28 -0700 (PDT) Received: from smtp.serverkommune.de (serverkommune.de [176.9.61.43]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F05B1A6FB3 for ; Wed, 3 Sep 2014 13:15:59 -0700 (PDT) Received: by smtp.serverkommune.de (Postfix, from userid 5001) id 82D028063F; Wed, 3 Sep 2014 22:15:57 +0200 (CEST) Received: from [192.168.178.34] (ex6.serverkommune.de [176.9.61.43]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.serverkommune.de (Postfix) with ESMTPSA id D5B77801A6; Wed, 3 Sep 2014 22:15:56 +0200 (CEST) Message-ID: <540776FC.7030409@net.in.tum.de> Date: Wed, 03 Sep 2014 22:15:56 +0200 From: Ralph Holz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Nico Williams References: <54048985.1020005@net.in.tum.de> <3EB754B7-F6B2-4207-A2F0-E61F32EE1E40@ll.mit.edu> <54075016.6040406@net.in.tum.de> <20140903174958.GF14392@mournblade.imrryr.org> <5407574B.5060708@net.in.tum.de> <9120B6EE-F023-4724-9116-A169993F58E8@ll.mit.edu> <14f6960e-e625-4252-ad7d-2bf8295f71fc@email.android.com> <9D33A9AF-5613-49DD-B024-DD5CDA49CFC9@ll.mit.edu> <540770DF.105@net.in.tum.de> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.98.1 at ex6 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RaIPMHwaxgIpjeVGe8S0SF-O8vA Cc: "tls@ietf.org" Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 20:16:30 -0000 Hi Nico, > Ralph, > > Uri is quite right. You really should read RFC2119. Here's the money quote: > > 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the > definition is an absolute prohibition of the specification. > > There is absolutely no hedging there. There is no more evidence to > post, really. What more could you need? "absolute prohibition" is as > clear as it gets. Yes, I understand that, and apologies if that came out wrong. But the meaning of MUST NOT is not what I asked for - rather, the difference between "deployment" and "implementation". The reworded version in the BCP would say that "deployments" MUST NOT negotiate the cipher. E.g., the cipher string in your Apache must not contain NULL. The note following it then clarifies that the actual code (e.g. in the openssl library) is free to contain the cipher. If there is agreement that deployment = implementation, we'll need other words to express this. Hope that clears it up. Ralph -- Ralph Holz I8 - Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18043 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF From nobody Wed Sep 3 13:20:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24AE21A6F99 for ; Wed, 3 Sep 2014 13:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RV62FWOLlJZV for ; Wed, 3 Sep 2014 13:20:17 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F3F81A6F6D for ; Wed, 3 Sep 2014 13:20:07 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 02D082AB173; Wed, 3 Sep 2014 20:20:06 +0000 (UTC) Date: Wed, 3 Sep 2014 20:20:05 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140903202005.GX14392@mournblade.imrryr.org> References: <20140903140059.GW14392@mournblade.imrryr.org> <1243278676.42405953.1409754600887.JavaMail.zimbra@redhat.com> <540728CE.6080305@fussenegger.info> <1589581250.42632708.1409761318984.JavaMail.zimbra@redhat.com> <20140903163948.GE14392@mournblade.imrryr.org> <18E884D9-204D-4D90-9DAF-3BFE8086732D@inria.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fj6tz-7PY0TGySJniBKw8RadlWg Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@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: Wed, 03 Sep 2014 20:20:19 -0000 On Wed, Sep 03, 2014 at 04:12:18PM -0400, Karthikeyan Bhargavan wrote: > I apologize for lack of clarity. By "forfeit" I meant the following > scenario, where a malicious server gets to read data sent to an > honest server: > > Connection 1: > C connects to malicious S > S sends it a session ticket T which C stores. The malicious server failed to be authenticated, so the session in question (with which the ticket is associated) is unauthenticated. With or without tickets, clients that resume unauthenticated sessions are vulnerable to MiTM attacks. There's nothing new here. > Can we give some recommendations? Don't resume unauthenticated sessions when trying to connect to a service for which MiTM protection is wanted. -- Viktor. From nobody Wed Sep 3 13:25:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8AF1A6F99 for ; Wed, 3 Sep 2014 13:24:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wq9hpUrVHx_6 for ; Wed, 3 Sep 2014 13:24:51 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 074741A6F04 for ; Wed, 3 Sep 2014 13:24:51 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id 8BD5D20047B88 for ; Wed, 3 Sep 2014 13:24:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=XXxNgS923tfv6pulgXCa 1PLU/g0=; b=L8BlNX6epDNzCfcBLxWnG56+wpDl+mT59B26GWDaTv5w5T+E44K2 3XsHLF0oxAUhsMXyl2YKzWTH9epL+jJLUoihmC5EBCahA5V6BS/eznOSKEdiwlvY cpOHlmNpgV3FFVB/xkv4vAFZ2YKACW0g8pE1/hVjZgv/Q+Z+EJ5G6gc= Received: from mail-we0-f176.google.com (mail-we0-f176.google.com [74.125.82.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPSA id 3D4D620047B83 for ; Wed, 3 Sep 2014 13:24:50 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id q59so9177320wes.35 for ; Wed, 03 Sep 2014 13:24:49 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.13.195 with SMTP id j3mr1036316wic.70.1409775889057; Wed, 03 Sep 2014 13:24:49 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Wed, 3 Sep 2014 13:24:48 -0700 (PDT) In-Reply-To: <540776FC.7030409@net.in.tum.de> References: <54048985.1020005@net.in.tum.de> <3EB754B7-F6B2-4207-A2F0-E61F32EE1E40@ll.mit.edu> <54075016.6040406@net.in.tum.de> <20140903174958.GF14392@mournblade.imrryr.org> <5407574B.5060708@net.in.tum.de> <9120B6EE-F023-4724-9116-A169993F58E8@ll.mit.edu> <14f6960e-e625-4252-ad7d-2bf8295f71fc@email.android.com> <9D33A9AF-5613-49DD-B024-DD5CDA49CFC9@ll.mit.edu> <540770DF.105@net.in.tum.de> <540776FC.7030409@net.in.tum.de> Date: Wed, 3 Sep 2014 15:24:48 -0500 Message-ID: From: Nico Williams To: Ralph Holz Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6qpCKckheQAMqUXq77m4a5OBij4 Cc: "tls@ietf.org" Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 20:24:52 -0000 On Wed, Sep 3, 2014 at 3:15 PM, Ralph Holz wrote: >> Uri is quite right. You really should read RFC2119. Here's the money quote: >> >> 2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the >> definition is an absolute prohibition of the specification. >> >> There is absolutely no hedging there. There is no more evidence to >> post, really. What more could you need? "absolute prohibition" is as >> clear as it gets. > > Yes, I understand that, and apologies if that came out wrong. But the > meaning of MUST NOT is not what I asked for - rather, the difference > between "deployment" and "implementation". The reworded version in the > BCP would say that "deployments" MUST NOT negotiate the cipher. E.g., > the cipher string in your Apache must not contain NULL. This needs to apply to implementors. It's hard to tell sysadmins to not do certain things. You need to tell implementors what to allow for local policy. Nico -- From nobody Wed Sep 3 13:28:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35E9F1A0AE4 for ; Wed, 3 Sep 2014 13:27:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WrSe7WOnn4O3 for ; Wed, 3 Sep 2014 13:27:58 -0700 (PDT) Received: from mail-lb0-x229.google.com (mail-lb0-x229.google.com [IPv6:2a00:1450:4010:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE2F11A6F4B for ; Wed, 3 Sep 2014 13:27:55 -0700 (PDT) Received: by mail-lb0-f169.google.com with SMTP id l4so10335175lbv.14 for ; Wed, 03 Sep 2014 13:27:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=lnp8xioj0lKRNU8yZ7Nl25cDhb+PMdnjPs/F6KMIhqE=; b=B2JR9U7PQ+ymS0WLlFc0L7V/85J280RVSWM+vKiQ/umkMfk2gyuh8tX8iPKSYCOlEC /D5uONT8Hs2GS543hcTDuG8op+l+KJmUHbZUYUZ1GndwxPARFL1OvXfci1BRaKXBMveg 5xs/CCuudha1l+74pVdTBYF9ogeSKrdhLVnNm/2eeEQ8Idm/EKeXKBwa85CzYMY/UX1U vF+larnOYkTT0jaHWPJsFg8V1nSrjWregIxdp8Hf7SICFwPpxXjHdAHi7u7bjLkarGzB V3OJSIulYlGCepg7DQYLZNDZ8L9HVP9Rpljh2eNKiK7ZAr9FnOkvMtxtek/IzK2lAs1I olRA== MIME-Version: 1.0 X-Received: by 10.152.87.97 with SMTP id w1mr5282716laz.92.1409776074335; Wed, 03 Sep 2014 13:27:54 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Wed, 3 Sep 2014 13:27:54 -0700 (PDT) Date: Wed, 3 Sep 2014 13:27:54 -0700 Message-ID: From: Martin Thomson To: Karthikeyan Bhargavan Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bcS9z6bWJ-KsjsuJj-aPFVNwtAs Cc: "tls@ietf.org" Subject: [TLS] Ticket caching (was Re: tickets or sesssions or both (oh my)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 20:27:59 -0000 On 3 September 2014 13:12, Karthikeyan Bhargavan wrote: > The question is what is the identity of S that C should use when storing the ticket? > Can we give some recommendations? The only basis we really have is the identity that was originally sought. We still want to permit different certificates (if not different names), so knowing identity prior to committing the first flight is of marginal utility anyway. If an attacker can masquerade as a valid origin, then I don't think that we should be specifically concerned that it can produce tickets that cause it to access information. It's trivial to force that first flight to go anywhere, but you have to be able to decrypt it to gain any real advantage. The attack you describe requires one of a range of breaks: forcing identical master secrets, decrypting the session (not just finding a collision in the MAC), or breaking the previous session. From nobody Wed Sep 3 13:33:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 287AE1A6F70 for ; Wed, 3 Sep 2014 13:32:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxdNpWmfWBY3 for ; Wed, 3 Sep 2014 13:32:57 -0700 (PDT) Received: from smtp.serverkommune.de (serverkommune.de [176.9.61.43]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2230B1A0B0D for ; Wed, 3 Sep 2014 13:32:50 -0700 (PDT) Received: by smtp.serverkommune.de (Postfix, from userid 5001) id 9322980994; Wed, 3 Sep 2014 22:32:48 +0200 (CEST) Received: from [192.168.178.34] (ex6.serverkommune.de [176.9.61.43]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.serverkommune.de (Postfix) with ESMTPSA id AD396801EE; Wed, 3 Sep 2014 22:32:36 +0200 (CEST) Message-ID: <54077AE4.7050209@net.in.tum.de> Date: Wed, 03 Sep 2014 22:32:36 +0200 From: Ralph Holz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Nico Williams References: <54048985.1020005@net.in.tum.de> <3EB754B7-F6B2-4207-A2F0-E61F32EE1E40@ll.mit.edu> <54075016.6040406@net.in.tum.de> <20140903174958.GF14392@mournblade.imrryr.org> <5407574B.5060708@net.in.tum.de> <9120B6EE-F023-4724-9116-A169993F58E8@ll.mit.edu> <14f6960e-e625-4252-ad7d-2bf8295f71fc@email.android.com> <9D33A9AF-5613-49DD-B024-DD5CDA49CFC9@ll.mit.edu> <540770DF.105@net.in.tum.de> <540776FC.7030409@net.in.tum.de> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.98.1 at ex6 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Aj1aphm-OWIT4Ng7UikprGnQ_4k Cc: "tls@ietf.org" Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 20:32:59 -0000 Hi, >> Yes, I understand that, and apologies if that came out wrong. But the >> meaning of MUST NOT is not what I asked for - rather, the difference >> between "deployment" and "implementation". The reworded version in the >> BCP would say that "deployments" MUST NOT negotiate the cipher. E.g., >> the cipher string in your Apache must not contain NULL. > > This needs to apply to implementors. It's hard to tell sysadmins to > not do certain things. You need to tell implementors what to allow > for local policy. Is your argument thus that the BCP can only choose from two options? * Drop NULL in code * Retain NULL in code I don't think this is the case: "This document provides recommendations for improving the security of both software implementations and deployed services that use TLS and DTLS." (from the BCP) While you may be right with what you say about sysadmins, I think the suggested wording provides the right guidance for both deployment and implementation. Ralph -- Ralph Holz I8 - Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18043 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF From nobody Wed Sep 3 13:33:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9511A0655 for ; Wed, 3 Sep 2014 13:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUamKy1YdUdw for ; Wed, 3 Sep 2014 13:33:49 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 200A61A053B for ; Wed, 3 Sep 2014 13:33:49 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 01DAD54078 for ; Wed, 3 Sep 2014 13:33:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=V+hfc8YYFleKwj8e+Kwa CxWwM1A=; b=WvdXChxVffgVlOgsq0W/eNO4oOgB86QEkNHNdlxWcM64V6ypbOgn 45xWEDkVidlLN8ZK9QR1LGp9/jHPvIJlCzQ2F/+G5nuVzMODRA46seLpo4f9xXCy Otd5LfLvPMmkrlz90ZX5ZB6IcgmlcwJp49nXRfbMYXvB7hMz9bcqzQA= Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id AA02A54073 for ; Wed, 3 Sep 2014 13:33:48 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id m15so9075978wgh.35 for ; Wed, 03 Sep 2014 13:33:47 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.58.244 with SMTP id u20mr43020wjq.36.1409776427472; Wed, 03 Sep 2014 13:33:47 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Wed, 3 Sep 2014 13:33:47 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> Date: Wed, 3 Sep 2014 15:33:47 -0500 Message-ID: From: Nico Williams To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Jid0K7AscWyIVl4bSzr2oEB6qSU Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 20:33:50 -0000 Session tickets are a SINE QUA NON for future deployment. PFS or not is up to the client (and server). Remember, PFS is related to the start of a session -- once you have a long-lived session, those session keys could be stolen. If you'll allow long-lived sessions then you might as well allow session tickets. (And if you want to add periodic PFS to long-lived sessions then you need renego, no?) Anyways, the right thing to do is to REQUIRE frequent session ticket encryption rotation / short ticket lifetimes. Look, session tickets are an optimization, but a HUGE optimization at that. It's necessary. Nico -- From nobody Wed Sep 3 13:34:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96AD11A0655 for ; Wed, 3 Sep 2014 13:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B7pCztdi0BlX for ; Wed, 3 Sep 2014 13:34:36 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 751301A0B0D for ; Wed, 3 Sep 2014 13:34:35 -0700 (PDT) Received: from homiemail-a27.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTP id 4D49F59807A for ; Wed, 3 Sep 2014 13:34:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=txeSWs9E/+I136VtMVau zFKDKuM=; b=j1wwtqVVQKA53TUtkWigt8GUVpCzvQa5L8NsaLT8BMw3fsNwBg02 0+YLJ42jSR1W0nweRZqM+tXqpiGZA8l9QFc7uN7h6JAC2Y84lGu6pU9zwCofY8zg esHPSew9OsrI0wEQaJoBqHBU641/Lyts6lV2Lu5WDXA4gaXvH2pQKdI= Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a27.g.dreamhost.com (Postfix) with ESMTPSA id F159F59806A for ; Wed, 3 Sep 2014 13:34:34 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id z2so10574583wiv.15 for ; Wed, 03 Sep 2014 13:34:33 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.37.241 with SMTP id b17mr38250811wik.70.1409776473864; Wed, 03 Sep 2014 13:34:33 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Wed, 3 Sep 2014 13:34:33 -0700 (PDT) In-Reply-To: <54077AE4.7050209@net.in.tum.de> References: <54048985.1020005@net.in.tum.de> <3EB754B7-F6B2-4207-A2F0-E61F32EE1E40@ll.mit.edu> <54075016.6040406@net.in.tum.de> <20140903174958.GF14392@mournblade.imrryr.org> <5407574B.5060708@net.in.tum.de> <9120B6EE-F023-4724-9116-A169993F58E8@ll.mit.edu> <14f6960e-e625-4252-ad7d-2bf8295f71fc@email.android.com> <9D33A9AF-5613-49DD-B024-DD5CDA49CFC9@ll.mit.edu> <540770DF.105@net.in.tum.de> <540776FC.7030409@net.in.tum.de> <54077AE4.7050209@net.in.tum.de> Date: Wed, 3 Sep 2014 15:34:33 -0500 Message-ID: From: Nico Williams To: Ralph Holz Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bCcMs7Unj8uF5-v5iaum6bUBK0I Cc: "tls@ietf.org" Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 20:34:36 -0000 On Wed, Sep 3, 2014 at 3:32 PM, Ralph Holz wrote: >> This needs to apply to implementors. It's hard to tell sysadmins to >> not do certain things. You need to tell implementors what to allow >> for local policy. > > Is your argument thus that the BCP can only choose from two options? > > * Drop NULL in code > * Retain NULL in code No. I'm supporting Viktor's position. Nico -- From nobody Wed Sep 3 13:38:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C96B1A0655 for ; Wed, 3 Sep 2014 13:38:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tmuKSOvr2URp for ; Wed, 3 Sep 2014 13:38:02 -0700 (PDT) Received: from mx207.easyname.com (mx207.easyname.com [212.232.25.163]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3134C1A03C2 for ; Wed, 3 Sep 2014 13:38:02 -0700 (PDT) Received: from 89-26-76-175.goll.dyn.salzburg-online.at ([89.26.76.175] helo=[192.168.0.11]) by mx.easyname.eu with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XPHJW-0002ZX-45 for tls@ietf.org; Wed, 03 Sep 2014 22:38:00 +0200 Message-ID: <54077C1C.4020108@fussenegger.info> Date: Wed, 03 Sep 2014 22:37:48 +0200 From: "Richard Fussenegger, BSc" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: tls@ietf.org References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Oyt9NuxSHcZzZIl6fUqC6b-UTx8 Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 20:38:04 -0000 +1 What would be an appropriate rotation cycle? 24 hours was already coined as a maximum and is also often stated in existing RFCs. I think that this is sufficient for most applications in regards to security. Of course more secure applications need to lower this to something like one hour or even less. Richard On 9/3/2014 10:33 PM, Nico Williams wrote: > Session tickets are a SINE QUA NON for future deployment. > > PFS or not is up to the client (and server). Remember, PFS is related > to the start of a session -- once you have a long-lived session, those > session keys could be stolen. If you'll allow long-lived sessions > then you might as well allow session tickets. > > (And if you want to add periodic PFS to long-lived sessions then you > need renego, no?) > > Anyways, the right thing to do is to REQUIRE frequent session ticket > encryption rotation / short ticket lifetimes. Look, session tickets > are an optimization, but a HUGE optimization at that. It's necessary. > > Nico > -- > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Sep 3 13:39:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 120011A068A for ; Wed, 3 Sep 2014 13:39:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FEyXT3JI_72O for ; Wed, 3 Sep 2014 13:39:02 -0700 (PDT) Received: from smtp.serverkommune.de (serverkommune.de [176.9.61.43]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E17D1A0AEA for ; Wed, 3 Sep 2014 13:39:01 -0700 (PDT) Received: by smtp.serverkommune.de (Postfix, from userid 5001) id 3506480994; Wed, 3 Sep 2014 22:39:00 +0200 (CEST) Received: from [192.168.178.34] (ex6.serverkommune.de [176.9.61.43]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.serverkommune.de (Postfix) with ESMTPSA id 493DE8092A; Wed, 3 Sep 2014 22:38:59 +0200 (CEST) Message-ID: <54077C63.90806@net.in.tum.de> Date: Wed, 03 Sep 2014 22:38:59 +0200 From: Ralph Holz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Nico Williams References: <54048985.1020005@net.in.tum.de> <3EB754B7-F6B2-4207-A2F0-E61F32EE1E40@ll.mit.edu> <54075016.6040406@net.in.tum.de> <20140903174958.GF14392@mournblade.imrryr.org> <5407574B.5060708@net.in.tum.de> <9120B6EE-F023-4724-9116-A169993F58E8@ll.mit.edu> <14f6960e-e625-4252-ad7d-2bf8295f71fc@email.android.com> <9D33A9AF-5613-49DD-B024-DD5CDA49CFC9@ll.mit.edu> <540770DF.105@net.in.tum.de> <540776FC.7030409@net.in.tum.de> <54077AE4.7050209@net.in.tum.de> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.98.1 at ex6 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fDcxCRM_Nnls6-4wlbMyKmytfQo Cc: "tls@ietf.org" Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 20:39:03 -0000 On 09/03/2014 10:34 PM, Nico Williams wrote: > On Wed, Sep 3, 2014 at 3:32 PM, Ralph Holz wrote: >>> This needs to apply to implementors. It's hard to tell sysadmins to >>> not do certain things. You need to tell implementors what to allow >>> for local policy. >> >> Is your argument thus that the BCP can only choose from two options? >> >> * Drop NULL in code >> * Retain NULL in code > > No. I'm supporting Viktor's position. Sorry, can't follow. Viktor said he could live with the new wording? Does this mean you agree with it? Ralph -- Ralph Holz I8 - Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18043 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF From nobody Wed Sep 3 13:41:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 331121A6F70 for ; Wed, 3 Sep 2014 13:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27-Ei_fC3e9c for ; Wed, 3 Sep 2014 13:41:33 -0700 (PDT) Received: from mx203.easyname.com (mx203.easyname.com [212.232.28.124]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E954B1A6F4D for ; Wed, 3 Sep 2014 13:41:32 -0700 (PDT) Received: from 89-26-76-175.goll.dyn.salzburg-online.at ([89.26.76.175] helo=[192.168.0.11]) by mx.easyname.eu with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XPHMv-0007cT-Ma for tls@ietf.org; Wed, 03 Sep 2014 22:41:31 +0200 Message-ID: <54077CF2.9040106@fussenegger.info> Date: Wed, 03 Sep 2014 22:41:22 +0200 From: "Richard Fussenegger, BSc" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: tls@ietf.org References: <20140903140059.GW14392@mournblade.imrryr.org> <1243278676.42405953.1409754600887.JavaMail.zimbra@redhat.com> <540728CE.6080305@fussenegger.info> <1589581250.42632708.1409761318984.JavaMail.zimbra@redhat.com> <20140903163948.GE14392@mournblade.imrryr.org> <18E884D9-204D-4D90-9DAF-3BFE8086732D@inria.fr> <20140903202005.GX14392@mournblade.imrryr.org> In-Reply-To: <20140903202005.GX14392@mournblade.imrryr.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/OYvGyYy4rVddcYZ7RHgaSqQrNWQ Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 20:41:35 -0000 On 9/3/2014 10:20 PM, Viktor Dukhovni wrote: > On Wed, Sep 03, 2014 at 04:12:18PM -0400, Karthikeyan Bhargavan wrote: > >> Can we give some recommendations? > Don't resume unauthenticated sessions when trying to connect to a > service for which MiTM protection is wanted. > Also storing by IP is pretty impossible with SNI. A cache has to include at least the FQDN for SNI. Richard From nobody Wed Sep 3 13:47:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95CE31A6FBE for ; Wed, 3 Sep 2014 13:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.867 X-Spam-Level: X-Spam-Status: No, score=-4.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jUu0X15BLTJb for ; Wed, 3 Sep 2014 13:47:18 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 096251A036C for ; Wed, 3 Sep 2014 13:47:17 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s83KkvLB007241; Wed, 3 Sep 2014 16:47:14 -0400 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Blumenthal, Uri - 0668 - MITLL" In-Reply-To: Date: Wed, 3 Sep 2014 16:46:27 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: <1DAFD0E6-37A6-4FEB-AC54-D4E80721D92A@ll.mit.edu> References: <54048985.1020005@net.in.tum.de> <3EB754B7-F6B2-4207-A2F0-E61F32EE1E40@ll.mit.edu> <54075016.6040406@net.in.tum.de> <20140903174958.GF14392@mournblade.imrryr.org> <5407574B.5060708@net.in.tum.de> <9120B6EE-F023-4724-9116-A169993F58E8@ll.mit.edu> <14f6960e-e625-4252-ad7d-2bf8295f71fc@email.android.com> <9D33A9AF-5613-49DD-B024-DD5CDA49CFC9@ll.mit.edu> <540770DF.105@net.in.tum.de> <540776FC.7030409@net.in.tum.de> <54077AE4.7050209@net.in.tum.de> To: Nico Williams , Ralph Holz X-Mailer: Apple Mail (2.1878.6) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.27, 0.0.0000 definitions=2014-09-03_08:2014-09-03,2014-09-03,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-1402240000 definitions=main-1409030222 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dPSdvEiKCtUzrLcg2Ft_uwc3oEY Cc: "tls@ietf.org" Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 20:47:22 -0000 On Sep 3, 2014, at 16:34 , Nico Williams wrote: > On Wed, Sep 3, 2014 at 3:32 PM, Ralph Holz wrote: >>> This needs to apply to implementors. It's hard to tell sysadmins to >>> not do certain things. You need to tell implementors what to allow >>> for local policy. >>=20 >> Is your argument thus that the BCP can only choose from two options? >>=20 >> * Drop NULL in code >> * Retain NULL in code >=20 > No. I'm supporting Viktor's position. If the implementors are told =93MUST NOT=94 and comply with it - there = would be no code to support NULL cipher, because if they leave the code = in - they wouldn=92t be compliant with the standard any more. It would = be pointless to add =93=85implementations MAY retain=85=94, as the two = statements directly contradict each other. Do you not see this = contradiction? (Treat this as a =93legal" document, not a publication = or an article.) Again, if what you mean to state is =93Don=92t do this. But as an = exception, in some (undesirable) cases you may.=94, then =93SHOULD NOT=94 = is what the BCP should say. Viktor said (Sep 2, 2014): While I agree that NULL ciphers should not be enabled *by default*, making NULL ciphers a "MUST NOT" seems rather too strong. Also, I=92d pay heed to what Nikos said: Putting such strong wording there is a recipe for the document's advices to be ignored. A "MUST NOT" in a document like that will not prevent me from using that ciphersuite if I need it, and most probably neutralize every other positive advice given by that draft. "MUST NOT" must be really "must not", not "some people don't have a use case for it". From nobody Wed Sep 3 13:49:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45B441A6FD0 for ; Wed, 3 Sep 2014 13:49:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.868 X-Spam-Level: X-Spam-Status: No, score=-4.868 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dN8FLJ5gOcDI for ; Wed, 3 Sep 2014 13:49:32 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id EBC131A6F3E for ; Wed, 3 Sep 2014 13:49:17 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BA0652861D; Wed, 3 Sep 2014 20:49:16 +0000 (GMT) Received: from prod-mail-relay07.akamai.com (prod-mail-relay07.akamai.com [172.17.121.112]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id A0B88285C9; Wed, 3 Sep 2014 20:49:16 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay07.akamai.com (Postfix) with ESMTP id 96C6080065; Wed, 3 Sep 2014 20:49:16 +0000 (GMT) Received: from Tereva.local (172.19.40.187) by usma1ex-cashub6.kendall.corp.akamai.com (172.27.105.22) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 3 Sep 2014 16:49:15 -0400 From: Brian Sniffen To: Nico Williams , "Salz, Rich" In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-apple-darwin12.3.0) Date: Wed, 3 Sep 2014 16:49:14 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rUrbCza0hX_vOZWlVSoTdVNvW0U Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 20:49:34 -0000 Nico Williams writes: > Session tickets are a SINE QUA NON for future deployment. > > PFS or not is up to the client (and server). Remember, PFS is related > to the start of a session -- once you have a long-lived session, those > session keys could be stolen. If you'll allow long-lived sessions > then you might as well allow session tickets. Yes. > (And if you want to add periodic PFS to long-lived sessions then you > need renego, no?) > > Anyways, the right thing to do is to REQUIRE frequent session ticket > encryption rotation / short ticket lifetimes. Look, session tickets > are an optimization, but a HUGE optimization at that. It's necessary. What about making session tickets optional? Clients or servers that want PFS can then decline to accept or generate tickets. -Brian -- Brian Sniffen "I reserve the right to evolve my views, and state that views I previously expressed may have been somehere along the spectrum from insufficiently nuanced through ill-informed to dead wrong." From nobody Wed Sep 3 13:54:44 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A2B41A069C for ; Wed, 3 Sep 2014 13:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmJNF1e2Xkwv for ; Wed, 3 Sep 2014 13:54:41 -0700 (PDT) Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5F801A6FCC for ; Wed, 3 Sep 2014 13:54:12 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id q1so1995661lam.40 for ; Wed, 03 Sep 2014 13:54:11 -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=jTetWXyQH4OQc9bvRflTI27st6MQi8FL2mlO+8SCIxw=; b=rDeIdh63emH9z+44XYZy4WlJpjGcqUitV8gblC0W0rgW+vH74tSiw8PXDuF1DWZ2hy yOXNEuszZSB5Rv+1hMMMiLPoczk4tBDx9AFruKa4aO8jwEu874rNXO3tCxwGLogav2Sb 6mNc8OyAn1EiWGiXzcZ9MLfWfI3FbrvTs3bOXOkGey87BjGEwz+FTYwRO5933SaUi4KF u7p/Ds063mvMb0dMj8EMqSIobVuG4xq5467oe8Vl6opmoPgPMbVNklruW/cjpcATmNtm gV+JZ2475PEjJZMVDdguolMOwifyJCsnprd58CHI5SradqHcUu+MYgXabahu2g2oxkrD c0sg== MIME-Version: 1.0 X-Received: by 10.152.121.37 with SMTP id lh5mr107476lab.43.1409777651023; Wed, 03 Sep 2014 13:54:11 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Wed, 3 Sep 2014 13:54:10 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> Date: Wed, 3 Sep 2014 13:54:10 -0700 Message-ID: From: Martin Thomson To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/_BZsH3XTNShTdVy3iLrdzFgaJZQ Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 20:54:43 -0000 On 3 September 2014 13:33, Nico Williams wrote: > (And if you want to add periodic PFS to long-lived sessions then you > need renego, no?) Not strictly, though it can get almost as complicated as renegotiation. But you don't have to change all the session parameters, just the keys. You can rekey with material that is derived from the old material and prevent a future break from compromising session history back past the rekeying point. Or you can do a full or partial DH round without any of the other renego baggage, which ensures that any break is limited in access to the plaintext up to the DH in both directions. The latter is pretty complicated to get right when it comes to synchronization. From nobody Wed Sep 3 13:55:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61D381A710D for ; Wed, 3 Sep 2014 13:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2hezJaZ1wzCF for ; Wed, 3 Sep 2014 13:55:24 -0700 (PDT) Received: from smtp.serverkommune.de (serverkommune.de [176.9.61.43]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46CCA1A70FD for ; Wed, 3 Sep 2014 13:54:37 -0700 (PDT) Received: by smtp.serverkommune.de (Postfix, from userid 5001) id DC22B80886; Wed, 3 Sep 2014 22:54:35 +0200 (CEST) Received: from [192.168.178.34] (ex6.serverkommune.de [176.9.61.43]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.serverkommune.de (Postfix) with ESMTPSA id 59C8280869; Wed, 3 Sep 2014 22:54:34 +0200 (CEST) Message-ID: <5407800A.20100@net.in.tum.de> Date: Wed, 03 Sep 2014 22:54:34 +0200 From: Ralph Holz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: "Blumenthal, Uri - 0668 - MITLL" , Nico Williams References: <54048985.1020005@net.in.tum.de> <3EB754B7-F6B2-4207-A2F0-E61F32EE1E40@ll.mit.edu> <54075016.6040406@net.in.tum.de> <20140903174958.GF14392@mournblade.imrryr.org> <5407574B.5060708@net.in.tum.de> <9120B6EE-F023-4724-9116-A169993F58E8@ll.mit.edu> <14f6960e-e625-4252-ad7d-2bf8295f71fc@email.android.com> <9D33A9AF-5613-49DD-B024-DD5CDA49CFC9@ll.mit.edu> <540770DF.105@net.in.tum.de> <540776FC.7030409@net.in.tum.de> <54077AE4.7050209@net.in.tum.de> <1DAFD0E6-37A6-4FEB-AC54-D4E80721D92A@ll.mit.edu> In-Reply-To: <1DAFD0E6-37A6-4FEB-AC54-D4E80721D92A@ll.mit.edu> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.98.1 at ex6 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2_kTXgpd7rTtVPiKflpeZ6DBdPA Cc: "tls@ietf.org" Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 20:55:25 -0000 Hi Uri, I still think there is a difference between a deployment and an actual library, and re-reading the definition of BCP, I would arrive at the conclusion it's possible to word it like I did. But I recognise your position, and I will forward this. Ralph > If the implementors are told MUST NOT and comply with it - there > would be no code to support NULL cipher, because if they leave the > code in - they wouldnt be compliant with the standard any more. It > would be pointless to add implementations MAY retain, as the two > statements directly contradict each other. Do you not see this > contradiction? (Treat this as a legal" document, not a publication > or an article.) > > Again, if what you mean to state is Dont do this. But as an > exception, in some (undesirable) cases you may., then SHOULD NOT > is what the BCP should say. > > Viktor said (Sep 2, 2014): > > While I agree that NULL ciphers should not be enabled *by default*, > making NULL ciphers a "MUST NOT" seems rather too strong. > > Also, Id pay heed to what Nikos said: > > Putting such strong wording there is a recipe for the document's > advices to be ignored. A "MUST NOT" in a document like that will not > prevent me from using that ciphersuite if I need it, and most > probably neutralize every other positive advice given by that draft. > "MUST NOT" must be really "must not", not "some people don't have a > use case for it". > -- Ralph Holz I8 - Network Architectures and Services Technische Universitt Mnchen http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18043 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF From nobody Wed Sep 3 13:55:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6002F1A8708 for ; Wed, 3 Sep 2014 13:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uQD0ddWaCxVo for ; Wed, 3 Sep 2014 13:55:38 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 25DFE1A6FFC for ; Wed, 3 Sep 2014 13:54:57 -0700 (PDT) Received: from homiemail-a96.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTP id BD8363B8072 for ; Wed, 3 Sep 2014 13:54:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=FAI6foIaMJHphWeXCPRp 3Cx7fLA=; b=jEJSe5Do04U2TXyhGNFbpHNwL+o45ObOGRim/MnpnFLZHfiEvSzr 03uPTbeofcXVh5hDSx/b3XCeaXkvaGsr7efe5c+TuC5W8j1zdb3aHDH/qScBPm1V 2V1aulqbU1UAPcqsadkhiYfgo9Y9gyMt72fx1r9P6d7+ELhX+Zvgiac= Received: from mail-wi0-f176.google.com (mail-wi0-f176.google.com [209.85.212.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a96.g.dreamhost.com (Postfix) with ESMTPSA id 6A87C3B805C for ; Wed, 3 Sep 2014 13:54:56 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id bs8so1717364wib.9 for ; Wed, 03 Sep 2014 13:54:55 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.77.243 with SMTP id v19mr50497wjw.18.1409777695171; Wed, 03 Sep 2014 13:54:55 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Wed, 3 Sep 2014 13:54:55 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> Date: Wed, 3 Sep 2014 15:54:55 -0500 Message-ID: From: Nico Williams To: Brian Sniffen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ugHqFjaN5d0VLDu8FbFpGDDv0FI Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 20:55:40 -0000 On Wed, Sep 3, 2014 at 3:49 PM, Brian Sniffen wrote: > What about making session tickets optional? Clients or servers that > want PFS can then decline to accept or generate tickets. They are optional. The problem is that if you ever use a ticket once and the server doesn't rotate its keys (or in the non-ticket resumption case, flush its session cache) then the resumed connections can be compromised later. But... so what? This is a problem for *running* connections anyways. If an attacker can compromise the server's keys, it can probably compromise the server completely and access running connections' session keys. This is about trade-offs. Proposals to get rid of sessions because of concerns about PFS are just throwing the baby out with the bathwater; such proposals are just not serious, and -if adopted- risk leading to TLS 1.3's failure. Nico -- From nobody Wed Sep 3 13:56:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28A741A701F for ; Wed, 3 Sep 2014 13:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XKbH7foGZ_SJ for ; Wed, 3 Sep 2014 13:56:33 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2E311A8713 for ; Wed, 3 Sep 2014 13:55:46 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id ty20so10524269lab.2 for ; Wed, 03 Sep 2014 13:55:45 -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=zcSOkX6vTqaO3CrC9VKKG4OChvvQIp9f+P0r+DrLJ5o=; b=WZCkkHFOzUwRFxRcycpc++jqRt5UtPc+fS1X98WVGejUY+N0XotHIUgyFgKscz0G3e NO8j8lOskNSzLrEr6QjZIPcbmQR4KWv9k7FImLOe14mhaPXUGWqETf6MhvdVKeDgDSlC EK9vl/elQgeJ3qyOB5M1rlgavwoTZ6o/ilLhRnW0zSK9E6VdvTPwOhFE69uX2MQv8Qep uGqznKKisBc17xbeBeD+rt62S//M/GKJgegVmqQ77QpC8XsBjWOJtpfCZ9iWESMEReQ+ w8MS4ccMtZEJNQBy3JAUtxQssmd13G4Bmo0ZDGMl3L+0InOR/hKCb7Ur7Y3sW2UNcWs5 TO5Q== MIME-Version: 1.0 X-Received: by 10.152.163.199 with SMTP id yk7mr107598lab.85.1409777745369; Wed, 03 Sep 2014 13:55:45 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Wed, 3 Sep 2014 13:55:45 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> Date: Wed, 3 Sep 2014 13:55:45 -0700 Message-ID: From: Martin Thomson To: Brian Sniffen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qA8wM4ewNssjkZXdC-lEQF7rils Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 20:56:35 -0000 On 3 September 2014 13:49, Brian Sniffen wrote: > What about making session tickets optional? Clients or servers that > want PFS can then decline to accept or generate tickets. That's certainly already the case. I'm fairly sure that we'd want to keep that flexibility. Certainly, we have to allow for a ticket to be invalid, so the server always has some discretion regarding whether it honours a ticket. From nobody Wed Sep 3 13:56:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 796BF1A6F9E for ; Wed, 3 Sep 2014 13:56:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dBQ2UemQIwEG for ; Wed, 3 Sep 2014 13:56:38 -0700 (PDT) Received: from mx207.easyname.com (mx207.easyname.com [212.232.25.163]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 351201A8714 for ; Wed, 3 Sep 2014 13:55:53 -0700 (PDT) Received: from 89-26-76-175.goll.dyn.salzburg-online.at ([89.26.76.175] helo=[192.168.0.11]) by mx.easyname.eu with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XPHan-0000UB-5n for tls@ietf.org; Wed, 03 Sep 2014 22:55:51 +0200 Message-ID: <5407804F.7030803@fussenegger.info> Date: Wed, 03 Sep 2014 22:55:43 +0200 From: "Richard Fussenegger, BSc" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: tls@ietf.org References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BMPmrZRyijsTEFIwCpm9unpJDfI Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 20:56:40 -0000 On 9/3/2014 10:49 PM, Brian Sniffen wrote: > Nico Williams writes: > >> (And if you want to add periodic PFS to long-lived sessions then you >> need renego, no?) >> >> Anyways, the right thing to do is to REQUIRE frequent session ticket >> encryption rotation / short ticket lifetimes. Look, session tickets >> are an optimization, but a HUGE optimization at that. It's necessary. > What about making session tickets optional? Clients or servers that > want PFS can then decline to accept or generate tickets. > > -Brian > One can use session tickets together with PFS if rotation works. Of course one could simply deactivate them to add a layer of paranoia but one would have to disable session IDs as well because those could be compromised too. Yes, looking at current implementations it's no paranoia layer. But the spec has to be sure to mark any non-rotating implementation as not RFC compliant by changing the rotation to MUST. Also don't forget that tickets are already optional as it is now and I'd keep that dual system at least for TLS 1.3, as I said earlier. Otherwise nobody will adopt the new protocol because of lack of support on client and server side. But the next incarnation could drop one or the other. Richard From nobody Wed Sep 3 13:57:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE9C71A871A for ; Wed, 3 Sep 2014 13:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTNAu9BCVxKu for ; Wed, 3 Sep 2014 13:57:06 -0700 (PDT) Received: from homiemail-a112.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0465A1A6FD3 for ; Wed, 3 Sep 2014 13:56:20 -0700 (PDT) Received: from homiemail-a112.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a112.g.dreamhost.com (Postfix) with ESMTP id DAD842007871A for ; Wed, 3 Sep 2014 13:56:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=ZnVrfCSlYScDWjtt1ZRS s0w2FWo=; b=JkSGvM4PJraheapHbtrxpDXzYZg7FwmxkudO4bxz6jr73ukUmiI1 GVMPRVWe6UIzyHIb5LSONpUNByxo9BjsR2RowO38qJ5Et7OvBemdGZ/VFdoL3bGc Nq8FJjFceoRbviUKAKt5UkpAw20V9tFkaqYLQGrPtcGaIuPWf94SlRw= Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a112.g.dreamhost.com (Postfix) with ESMTPSA id 9078C20078717 for ; Wed, 3 Sep 2014 13:56:19 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id n12so9077530wgh.19 for ; Wed, 03 Sep 2014 13:56:18 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.13.195 with SMTP id j3mr145382wic.70.1409777778552; Wed, 03 Sep 2014 13:56:18 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Wed, 3 Sep 2014 13:56:18 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> Date: Wed, 3 Sep 2014 15:56:18 -0500 Message-ID: From: Nico Williams To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QR9wTtGt4JT0Z5DKx01kJVmMIlE Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 20:57:07 -0000 On Wed, Sep 3, 2014 at 3:54 PM, Martin Thomson wrote: > On 3 September 2014 13:33, Nico Williams wrote: >> (And if you want to add periodic PFS to long-lived sessions then you >> need renego, no?) > > Not strictly, though it can get almost as complicated as > renegotiation. But you don't have to change all the session > parameters, just the keys. > > You can rekey with material that is derived from the old material and > prevent a future break from compromising session history back past the > rekeying point. Or you can do a full or partial DH round without any > of the other renego baggage, which ensures that any break is limited > in access to the plaintext up to the DH in both directions. The > latter is pretty complicated to get right when it comes to > synchronization. Nothing short of a new (possibly asynchronous) DH exchange will prevent compromise of the past for connections still live at the time of compromise. Nico -- From nobody Wed Sep 3 13:58:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0BA61A6FFC for ; Wed, 3 Sep 2014 13:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q_Tu9_b2g0a3 for ; Wed, 3 Sep 2014 13:58:15 -0700 (PDT) Received: from hapkido.dreamhost.com (hapkido.dreamhost.com [66.33.216.122]) by ietfa.amsl.com (Postfix) with ESMTP id 8418E1A701F for ; Wed, 3 Sep 2014 13:57:25 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by hapkido.dreamhost.com (Postfix) with ESMTP id 3B23495766 for ; Wed, 3 Sep 2014 13:57:25 -0700 (PDT) Received: from homiemail-a105.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTP id 1B8932007D810 for ; Wed, 3 Sep 2014 13:56:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=tM/cxtxLqzWQbb+Wsvco C6MDz9k=; b=gHWqfnhl0SP66N8QL1VPzxIR/VI3KXuwHgAD/crD5KlFtd3jljpp WM7esRLQrayk7g7zIm5kHcaVOPY/IjK5cd+btUbIF3NOIlmDX/MgXvnAOtT52dYB DsvOfP4wGCBqTwyCqHe59IHWCgq54r0NOsvEk+cNrtqZGWAHISoInHw= Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a105.g.dreamhost.com (Postfix) with ESMTPSA id C33792007D80D for ; Wed, 3 Sep 2014 13:56:54 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id z2so10617135wiv.9 for ; Wed, 03 Sep 2014 13:56:53 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.37.241 with SMTP id b17mr33895wik.70.1409777813763; Wed, 03 Sep 2014 13:56:53 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Wed, 3 Sep 2014 13:56:53 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> Date: Wed, 3 Sep 2014 15:56:53 -0500 Message-ID: From: Nico Williams To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Zo1Ht8BeMFMAjODZn-tyIW0aa-E Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 20:58:17 -0000 On Wed, Sep 3, 2014 at 3:55 PM, Martin Thomson wrote: > On 3 September 2014 13:49, Brian Sniffen wrote: >> What about making session tickets optional? Clients or servers that >> want PFS can then decline to accept or generate tickets. > > That's certainly already the case. I'm fairly sure that we'd want to > keep that flexibility. Certainly, we have to allow for a ticket to > be invalid, so the server always has some discretion regarding whether > it honours a ticket. This is *already* so today. Nico -- From nobody Wed Sep 3 14:11:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 050EF1A87BC for ; Wed, 3 Sep 2014 14:11:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZxfItdteUfS for ; Wed, 3 Sep 2014 14:11:40 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0AB6B1A8883 for ; Wed, 3 Sep 2014 14:04:16 -0700 (PDT) Received: from homiemail-a70.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTP id 7BFFC768064 for ; Wed, 3 Sep 2014 14:04:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=thMIxoZjd1V9HLxIieb9 KVPrAK4=; b=rdW2XxBbLMQJMaefVZGnYBsKNY4b3McEsCxUde2CVmGmPpl5vIlG ChgyE6a84Q357nnjS8tyAQrsmSA5oP82XHNLwoHu7YIkReLXsSHXIw6G1L+XRsii WfexWevVkmB7nFw1FZUXb5K0/2gYXNzqgqYj9HEdb72PpF1mpUBow9I= Received: from mail-wi0-f177.google.com (mail-wi0-f177.google.com [209.85.212.177]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a70.g.dreamhost.com (Postfix) with ESMTPSA id 29782768061 for ; Wed, 3 Sep 2014 14:04:16 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id cc10so10592586wib.10 for ; Wed, 03 Sep 2014 14:04:15 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.208.111 with SMTP id md15mr183048wic.3.1409778255115; Wed, 03 Sep 2014 14:04:15 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Wed, 3 Sep 2014 14:04:14 -0700 (PDT) In-Reply-To: <5407804F.7030803@fussenegger.info> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <5407804F.7030803@fussenegger.info> Date: Wed, 3 Sep 2014 16:04:14 -0500 Message-ID: From: Nico Williams To: "Richard Fussenegger, BSc" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/i_BAEHGmZHVQQD0t3GrC1CKEC3o Cc: "tls@ietf.org" Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 21:11:41 -0000 On Wed, Sep 3, 2014 at 3:55 PM, Richard Fussenegger, BSc wrote: > Also don't forget that tickets are already optional as it is now and I'd > keep that dual system at least for TLS 1.3, as I said earlier. Otherwise > nobody will adopt the new protocol because of lack of support on client and > server side. But the next incarnation could drop one or the other. Opaque session tickets of any length >> session IDs. The server can always use session IDs as the ticket. IIRC this is Bodo's suggestion for simplifying the protocol, and I agree. There's really no need to say anything normative about server-side resumption state vs. stateless resumption tickets -- it's an implementation detail. Losing the distinction on the wire should help simplify things. The key is to require resumption state -whether stored on the server or on the client with an encrypted session ticket- to be deleted/expired periodically. For session tickets that's done by rotating keys. For server-side state it's done by expunging expired sessions from the cache. Either way the effect is the same. Advice can be given about not storing these things on long-lived storage (disk, ssd), just memory (e.g., tmpfs, ramdisk, whatever). The where-is-the-state-stored distinction is not (should not be) relevant to the protocol though. Nico -- From nobody Wed Sep 3 14:20:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03D8D1A8837 for ; Wed, 3 Sep 2014 14:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b4epaKenTxqr for ; Wed, 3 Sep 2014 14:20:43 -0700 (PDT) Received: from homiemail-a112.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 22BDC1A87E6 for ; Wed, 3 Sep 2014 14:12:25 -0700 (PDT) Received: from homiemail-a112.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a112.g.dreamhost.com (Postfix) with ESMTP id 046B120078714 for ; Wed, 3 Sep 2014 14:12:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=3JWGRtU58qfmRFl3SqMk YZIN9yo=; b=q6kpRE0fR2BboGNpst0erNfWANLoSNAZ0YDEzocOq4jWHGAYi/I/ 8SzhhHEDhpFE0BON70sczphiYseHTX4vnAXONLvW3brzu5L52ffyQenzZX7QteF3 GVjyG3L8aJQvd9qAJ4kd7a91g3hs+LeIWlxS4NXtv9HcZREKFHdQiqw= Received: from mail-wg0-f50.google.com (mail-wg0-f50.google.com [74.125.82.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a112.g.dreamhost.com (Postfix) with ESMTPSA id AD8FB20078710 for ; Wed, 3 Sep 2014 14:12:24 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id x12so9102751wgg.33 for ; Wed, 03 Sep 2014 14:12:23 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.77.243 with SMTP id v19mr155970wjw.18.1409778743687; Wed, 03 Sep 2014 14:12:23 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Wed, 3 Sep 2014 14:12:23 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Sep 2014 16:12:23 -0500 Message-ID: From: Nico Williams To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gtqXspdCU6nDgZZEUROuEd0chI8 Cc: "tls@ietf.org" Subject: Re: [TLS] Ticket caching (was Re: tickets or sesssions or both (oh my)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 21:20:44 -0000 On Wed, Sep 3, 2014 at 3:27 PM, Martin Thomson wrote: > On 3 September 2014 13:12, Karthikeyan Bhargavan > wrote: >> The question is what is the identity of S that C should use when storing the ticket? >> Can we give some recommendations? > > The only basis we really have is the identity that was originally > sought. We still want to permit different certificates (if not > different names), so knowing identity prior to committing the first > flight is of marginal utility anyway. > > If an attacker can masquerade as a valid origin, then I don't think > that we should be specifically concerned that it can produce tickets > that cause it to access information. > > It's trivial to force that first flight to go anywhere, but you have > to be able to decrypt it to gain any real advantage. The attack you > describe requires one of a range of breaks: forcing identical master > secrets, decrypting the session (not just finding a collision in the > MAC), or breaking the previous session. Almost the exact same words can be said, and definitely the exact same semantics can be expressed, about stateful session resumption. That a ticket is small (a small integer index into server-side cache containing session keys) or large (possibly a session cache entry encrypted in a server secret key) is an implementation detail that is *almost* completely irrelevant to the security properties desired here. I say "almost" because there is one benefit to encrypted session tickets: there is but one small key (O(1) storage) to protect/keep/wipe/rotate/watch on the server side, compared to N cache entries otherwise, which are O(N) for storage and might well spill over to swap space and so on. On the whole encrypted session resumption tickets are much better than the alternative. Not having any kind of session resumption would be disastrous if adopted, surely leading to failure to adopt. Nico -- From nobody Wed Sep 3 14:24:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB1051A6FF2 for ; Wed, 3 Sep 2014 14:24:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFdeeBalZHx2 for ; Wed, 3 Sep 2014 14:24:35 -0700 (PDT) Received: from mx205.easyname.com (mx205.easyname.com [212.232.28.126]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58B131A86F2 for ; Wed, 3 Sep 2014 14:19:25 -0700 (PDT) Received: from 89-26-76-175.goll.dyn.salzburg-online.at ([89.26.76.175] helo=[192.168.0.11]) by mx.easyname.eu with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XPHxZ-0006eQ-HS; Wed, 03 Sep 2014 23:19:23 +0200 Message-ID: <540785D0.3080404@fussenegger.info> Date: Wed, 03 Sep 2014 23:19:12 +0200 From: "Richard Fussenegger, BSc" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Nico Williams References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <5407804F.7030803@fussenegger.info> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qLF03EL9qNQDxPDDfrGsLNu0vuI Cc: "tls@ietf.org" Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 21:24:38 -0000 On 9/3/2014 11:04 PM, Nico Williams wrote: > On Wed, Sep 3, 2014 at 3:55 PM, Richard Fussenegger, BSc > wrote: >> Also don't forget that tickets are already optional as it is now and I'd >> keep that dual system at least for TLS 1.3, as I said earlier. Otherwise >> nobody will adopt the new protocol because of lack of support on client and >> server side. But the next incarnation could drop one or the other. > Opaque session tickets of any length >> session IDs. The server can > always use session IDs as the ticket. IIRC this is Bodo's suggestion > for simplifying the protocol, and I agree. > > There's really no need to say anything normative about server-side > resumption state vs. stateless resumption tickets -- it's an > implementation detail. Losing the distinction on the wire should help > simplify things. > > The key is to require resumption state -whether stored on the server > or on the client with an encrypted session ticket- to be > deleted/expired periodically. For session tickets that's done by > rotating keys. For server-side state it's done by expunging expired > sessions from the cache. Either way the effect is the same. > > Advice can be given about not storing these things on long-lived > storage (disk, ssd), just memory (e.g., tmpfs, ramdisk, whatever). > > The where-is-the-state-stored distinction is not (should not be) > relevant to the protocol though. > > Nico > -- +1 seems like the best solution to me. Dissecting current implementation flaws isn't going to lead us anywhere. The developers simply have to fix them. Richard From nobody Wed Sep 3 14:33:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9776B1A6FC0 for ; Wed, 3 Sep 2014 14:33:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jjJ1O0navB9C for ; Wed, 3 Sep 2014 14:33:00 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 98B851A6F9E for ; Wed, 3 Sep 2014 14:29:42 -0700 (PDT) Received: from homiemail-a103.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTP id 741A820047B85 for ; Wed, 3 Sep 2014 14:29:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=rXkujOOnauM8lBZRFoNP NtqZLe4=; b=BYR1CP95iw6H2q1NHyhSUtVU+IrmM3o3Ha1ytrLQr5hmVPMjwi34 2+pm0c5WHGsHZufSKorD3B0y29I+cJSk++lB5Tu1oleTkZVNgMBpcCpk9i+UF5hN CJfbiBFRd1/IRe67z8u/pisO/ru8S/ZuYQHuRZyrePALfu/8Ej1s0Mo= Received: from mail-wi0-f171.google.com (mail-wi0-f171.google.com [209.85.212.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a103.g.dreamhost.com (Postfix) with ESMTPSA id 1D3CA20047B83 for ; Wed, 3 Sep 2014 14:29:41 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hi2so1767613wib.10 for ; Wed, 03 Sep 2014 14:29:40 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.58.244 with SMTP id u20mr234077wjq.36.1409779780888; Wed, 03 Sep 2014 14:29:40 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Wed, 3 Sep 2014 14:29:40 -0700 (PDT) In-Reply-To: <540785D0.3080404@fussenegger.info> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <5407804F.7030803@fussenegger.info> <540785D0.3080404@fussenegger.info> Date: Wed, 3 Sep 2014 16:29:40 -0500 Message-ID: From: Nico Williams To: "Richard Fussenegger, BSc" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DxvrufIm8USTC81595WVY4SoBiA Cc: "tls@ietf.org" Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 21:33:00 -0000 On Wed, Sep 3, 2014 at 4:19 PM, Richard Fussenegger, BSc wrote: > +1 seems like the best solution to me. Dissecting current implementation > flaws isn't going to lead us anywhere. The developers simply have to fix > them. +1 to that. From nobody Wed Sep 3 14:38:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE1741A0B0D for ; Wed, 3 Sep 2014 14:38:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.866 X-Spam-Level: X-Spam-Status: No, score=-4.866 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l0IUDdPfh2TQ for ; Wed, 3 Sep 2014 14:38:20 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 857F61A6F9E for ; Wed, 3 Sep 2014 14:37:15 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s83Laplx025795; Wed, 3 Sep 2014 17:37:12 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: Ralph Holz , Nico Williams Thread-Topic: [TLS] NULL cipher to become a MUST NOT in UTA BCP Thread-Index: AQHPxfjrFyzs0NTAq0uDUGuetkiK35vvfEyAgABeDoCAABYgAIAABZYAgAADAYCAAAzkgIAACkQAgAADOICAAAQegIAABN+AgAACagCAAAJ7AIAAAi4AgAAAi4CAAANTgIAAAkUA///Io4A= Date: Wed, 3 Sep 2014 21:37:02 +0000 Message-ID: References: <54048985.1020005@net.in.tum.de> <3EB754B7-F6B2-4207-A2F0-E61F32EE1E40@ll.mit.edu> <54075016.6040406@net.in.tum.de> <20140903174958.GF14392@mournblade.imrryr.org> <5407574B.5060708@net.in.tum.de> <9120B6EE-F023-4724-9116-A169993F58E8@ll.mit.edu> <14f6960e-e625-4252-ad7d-2bf8295f71fc@email.android.com> <9D33A9AF-5613-49DD-B024-DD5CDA49CFC9@ll.mit.edu> <540770DF.105@net.in.tum.de> <540776FC.7030409@net.in.tum.de> <54077AE4.7050209@net.in.tum.de> <1DAFD0E6-37A6-4FEB-AC54-D4E80721D92A@ll.mit.edu> <5407800A.20100@net.in.tum.de> In-Reply-To: <5407800A.20100@net.in.tum.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [172.25.177.187] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3492610585_31376239" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.27, 0.0.0000 definitions=2014-09-03_08:2014-09-03,2014-09-03,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-1402240000 definitions=main-1409030230 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FKTDKJ2yKm5-SltZkRhx8m7q8BE Cc: "tls@ietf.org" Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 21:38:23 -0000 --B_3492610585_31376239 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On 9/3/14, 16:54 , "Ralph Holz" wrote: >Hi Uri, > >I still think there is a difference between a deployment and an actual >library, and re-reading the definition of BCP, I would arrive at the >conclusion it's possible to word it like I did. Based on my experience with IETF and its practices (which included writing RFC=E2=80=99s and getting them through the process :), I disagree. >But I recognise your position, and I will forward this. Thank you! >>If the implementors are told =E2=80=9CMUST NOT=E2=80=9D and comply with it - there >> would be no code to support NULL cipher, because if they leave the >> code in - they wouldn=E2=80=99t be compliant with the standard any more. It >> would be pointless to add =E2=80=9C=E2=80=A6implementations MAY retain=E2=80=A6=E2=80=9D, as the= two >> statements directly contradict each other. Do you not see this >> contradiction? (Treat this as a =E2=80=9Clegal" document, not a publication >> or an article.) >>=20 >> Again, if what you mean to state is =E2=80=9CDon=E2=80=99t do this. But as an >> exception, in some (undesirable) cases you may.=E2=80=9D, then =E2=80=9CSHOULD NOT=E2=80= =9D >> is what the BCP should say. >>=20 >> Viktor said (Sep 2, 2014): >>=20 >> While I agree that NULL ciphers should not be enabled *by default*, >> making NULL ciphers a "MUST NOT" seems rather too strong. >>=20 >> Also, I=E2=80=99d pay heed to what Nikos said: >>=20 >> Putting such strong wording there is a recipe for the document's >> advices to be ignored. A "MUST NOT" in a document like that will not >> prevent me from using that ciphersuite if I need it, and most >> probably neutralize every other positive advice given by that draft. >> "MUST NOT" must be really "must not", not "some people don't have a >> use case for it". >>=20 > > >--=20 >Ralph Holz >I8 - Network Architectures and Services >Technische Universit=C3=A4t M=C3=BCnchen >http://www.net.in.tum.de/de/mitarbeiter/holz/ >Phone +49.89.289.18043 >PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF --B_3492610585_31376239 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUOAYJKoZIhvcNAQcCoIIUKTCCFCUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghIHMIIE6jCCA9KgAwIBAgIKH0XZoAAAAAABzTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE0MDQxNjIxNTMwMloXDTE1MDQxNjIxNTMwMlow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCx/gK75UYos2g8JavX0BVfe3TCGsmjQY34z9ZVeucP 8dGtqRA8T5i1OKdf++Jd81a0/qQA6mIGyzTW6lOtY+77qKUJtEeLM5URd+iv2EejAwxsa2B5 pMq9L9qWuVokR1rTEfEcuUeKR1Kko6xmRE/y6AzBnUhTvHx2X9F6JSVdR36Lx3R62CNeQqFi ZDeHuTI8AhRY4UdPkri1FTDxV6gLYaLKxsGIurrL/6EzdlkX8ImTcxKzEmxX1VjTPy9ZRNYj akDGcJF9clCfcwbq3DI3gAUkVxXf+UbHEjzOCVNQcoga7bYbBUuDpN25Lc86P9RaOiiICtyu ZZP2P/2kkKYRAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUEN9QHIi9GvlGjs9Th46jrfPir+Uw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAL2kCh9ovO8AbHgAVU6T eH5qRmKnOrfTUfn9JnHzkspdWMQA1IdtftSpiZZ7C3lCmblSDCgPqbQl4zMZxXeTgxnQsB6m 1LA6uDHM/0G27RcOJH4OTN9sQ0/2CKb4JPIXXIps1z+s8XjSRzPJZuD8fPC8R8QWvOH3owL2 BLzZebZTOMa5yws3kohY02vP/Clv0KQXYVzUZUYXoYmhUSYmQ1UZZZSFJ2rNdgNn0z8fPrUQ NIYlVaJV0kKQYjlHWTfomVapLEfIY7xRHZy9g997IjYReD0t9IZd6tTwcJES+2ijFM8l/fxk u/cQ4WCYyI+58DaBaV9p68/AC147b0HhvLUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIEzjCCA7agAwIBAgIK PVEvPAAAAACTsDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0y MB4XDTE0MDIxMjE4NTMwMVoXDTE1MDIxMjE4NTMwMVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCKHhhu75bRiOvWhbZ//TxS76yI2d+rHN2s8bp8wxW8oMjmsaplLeGQusUFRyRNSkfYtdB4 YApjnV6TCxS0Mqzly5BaoeZWoP+CbbMDNGYMszus9iFj22SSlTzGRo+gaL6rqsDKdwDOzs3C PYqh4Uu8sLzEq+QD9rhqAuMJ76635JKWELxK0uDehpNBMCGqVeAY8ht5u2h4ojPdwiuDQDW2 QxWRJjPDL8n1JczuEHY71jHldER3b2+UhpDDYRQ9aVOiGCjW8BwJOruVsBfLNxyDxgffNQ1D 1konuneMpL9H2S8ciHOdy5+Gi7snCQJ+7w30rIJ2NTldWaY6avZAaCa3AgMBAAGjggGWMIIB kjAdBgNVHQ4EFgQUZ7oGjnu6gWRmom/4UswgdVBW/3wwDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUHAQEEVjBUMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIwIwYIKwYBBQUHMAGGF2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUHBDAwLgYmKwYB BAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYE VR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAZ BgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0BAQsFAAOCAQEAJiU3WfJ9GvGJ iDNPClLazyh252wxxOc/TmClMKtyqHnbFObDEoXAMaoHGxrvs+lU8fU2F2ELpV8q8eYgqLLw 7PG09z5s/GkajlxVZ/FHj/9hNHTfwlicrCRY3zrna1GbOMZgWFz8R6akAoLKpqGulNrvjvU8 c63U+JVmgJmBPCMv5JlH10m87+WPJ+ToK0m4XfZjl7n5OKDJ/hOyBwbBntc+W2gDppfR1BCt DNfEG0+zHjFqF+Of1Q5NI5abhgvw5IEuVA1M4SV/utwmmdreBEv/YuLnDd/PhVgQwp3LHGCX X1dANyiKso2aACl9jrkylq39cA/WgvAlS21w9vxVpDGCAfUwggHxAgEBMF8wUTELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTET MBEGA1UEAxMKTUlUTEwgQ0EtMwIKH0XZoAAAAAABzTANBglghkgBZQMEAgEFAKBpMC8GCSqG SIb3DQEJBDEiBCB/bj8KoAPprMS/2g+yXZXRBe6EBMNjYCrZJ5lmpWdUxjAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA5MDMyMTM2MjVaMA0GCSqGSIb3 DQEBAQUABIIBAKC2ZC6PBHhNRhwX7xk+8aFeOxiNZuhreypyYUFjvEQhDsRhC0PL/ukdME0W wOFw2aP+mVpWkvMZRVvswFtr0k4/uvbtig8q570SYp1i+LluSosPe91uN+juK7f+Of8Sn8EA zQQC4I2QU5TTccp1w7WHDq2QGYX6lhP7c92WQhvnHRZB7vTlqrxunJ2RJE6bomeMTg6zHQ4V UYBJX+FhupUjiqUoI9swNv5x9SleuhNyCOiX9yK6kn1HfpQlYtzXiBcjpkzu8l0X5MgpWr1h D0IeEoOks5n/TieaAHMWCdo8NBNs0uadaY+Q7sv+dFdzWo68VgUbQDlmp8cmb8tmEs4= --B_3492610585_31376239-- From nobody Wed Sep 3 14:51:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFEB01A06EF for ; Wed, 3 Sep 2014 14:51:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.596 X-Spam-Level: X-Spam-Status: No, score=-1.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id veRjP8AzUWU2 for ; Wed, 3 Sep 2014 14:51:52 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAF481A06E0 for ; Wed, 3 Sep 2014 14:51:51 -0700 (PDT) Received: from mail-yk0-f173.google.com (mail-yk0-f173.google.com [209.85.160.173]) by mrelayeu.kundenserver.de (node=mreue006) with ESMTP (Nemesis) id 0LsJno-1YR39x1zvk-011yDH; Wed, 03 Sep 2014 23:51:49 +0200 Received: by mail-yk0-f173.google.com with SMTP id 20so5485796yks.18 for ; Wed, 03 Sep 2014 14:51:48 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.0.136 with SMTP id 8mr230032yhb.27.1409781108167; Wed, 03 Sep 2014 14:51:48 -0700 (PDT) Received: by 10.170.129.17 with HTTP; Wed, 3 Sep 2014 14:51:47 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <5407804F.7030803@fussenegger.info> Date: Wed, 3 Sep 2014 23:51:47 +0200 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=089e0163506229eb6a0502303e74 X-Provags-ID: V02:K0:4CdYSG2ZHgqOA/r/MMBO80nOAiAumTmigEADc1q3xfC PO+lBl/iKFikIBiTVlOnV5OrhuIkEWnXc32p6mFBDeAPdJD152 k3TeU07iLMMq1kduQB85zSDkr+Vz25jdOF94X7W7eb0IkkD3iN jhJ6BcAvExRy9ama5/Fa4MYAJN99Rugjgl626TZahbnEefiHoU xzctv6ot98MHAnzwHifMdT6EZU35/+2a4riwbv6h+jkA0XDNMl gCjGrqZU4airqOoebEw4pVUrC0dW+cWLiXSaZM2poOlqYLdE9e w8O+eSnWIBMx34Fzx0DFmNeASBfVVVfso3kbzGPokj0nkAZeF6 6kA/p0IUkjxu14JC21KPHhULrOkufPsqqDXpkBdHyW03vLKZ/4 AnJA9BV/LT8hNJaVjgorPGkmGRvbMlfBOHHKQhoAQ0d6NHoCh5 Kfhy5 X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1Rk5f5Raih7sB8rdeR4zhdZklwI Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 21:51:53 -0000 --089e0163506229eb6a0502303e74 Content-Type: text/plain; charset=UTF-8 Nico Williams : The key is to require resumption state -whether stored on the server > or on the client with an encrypted session ticket- to be > deleted/expired periodically. For session tickets that's done by > rotating keys. For server-side state it's done by expunging expired > sessions from the cache. Either way the effect is the same. Yes, I completely agree. Bodo --089e0163506229eb6a0502303e74 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Nico= Williams <nico@cryptonector.com>:

The key is to require resumption state -whether stored on the server
or on the client with an encrypted session ticket- to be
deleted/expired periodically.=C2=A0 For session tickets that's done by<= br> rotating keys.=C2=A0 For server-side state it's done by expunging expir= ed
sessions from the cache.=C2=A0 Either way the effect is the same.

Yes, I completely agree.

Bo= do
=C2=A0
--089e0163506229eb6a0502303e74-- From nobody Wed Sep 3 15:15:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EAF9C1A0685 for ; Wed, 3 Sep 2014 15:15:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tG6i3s6aPI9h for ; Wed, 3 Sep 2014 15:15:07 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D5E31A0649 for ; Wed, 3 Sep 2014 15:15:07 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id pn19so10666249lab.4 for ; Wed, 03 Sep 2014 15:15:05 -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=sqE2C9D66VZ0WzIJAAb4nINs/4KEdWFwp5n5/1fkUXI=; b=Ymm0unZWe3+WjNlwVW2QD9yCSxB87UTyWbZhSQBhHiK5d0AScFOKnlCgr5ntmZNEYQ Edj1LQGWnfIKVEfQke5wOoiHivHcl7V1N/8Wj+NlpH4I7ZVwdtR3Ib08BqzdlENAsT7C wJbQQkpm1Sux1Mduq4GQy27VLOj0QcrhJg2nmb+wMNPvmMRaM3Lh8UsCSJBZEkMFcBSC S0fHaWQo2Sj+kf4xWFmT+enNYAZFgNh+Nw+kXmD/9kJ7zWuz/rnTopeVFBkSgSNnRYfP ptYX23rmvmg5ODDsnmX/v67oZ4lgXCMTstnL5P5MJ12O2x9R8aVDbiwUQy8tyiPMCHJ2 v31Q== MIME-Version: 1.0 X-Received: by 10.112.201.133 with SMTP id ka5mr185710lbc.61.1409782505775; Wed, 03 Sep 2014 15:15:05 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Wed, 3 Sep 2014 15:15:05 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Sep 2014 15:15:05 -0700 Message-ID: From: Martin Thomson To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AN9VTkPOG-BHJ4zqFqa5nxHWVzk Cc: "tls@ietf.org" Subject: Re: [TLS] Ticket caching (was Re: tickets or sesssions or both (oh my)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 22:15:09 -0000 On 3 September 2014 14:12, Nico Williams wrote: > I say "almost" because there is one benefit to encrypted session > tickets: there is but one small key (O(1) storage) to > protect/keep/wipe/rotate/watch on the server side, compared to N cache > entries otherwise, which are O(N) for storage and might well spill > over to swap space and so on. Well, the information is out there, so there is always the (hopefully remote) chance that the ticket itself could be decrypted, which wouldn't be possible if a reference were used. Not sure that that's much of a distinction either. > Not having any kind of session resumption would be disastrous if > adopted, surely leading to failure to adopt. There was some early talk about whether it might be needed, but it's been clear to me at least for some time now that we need resumption. And tickets do have scaling characteristics that are very appealing. From nobody Wed Sep 3 15:23:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87AF91A06E3 for ; Wed, 3 Sep 2014 15:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ioORXAWB5Oga for ; Wed, 3 Sep 2014 15:23:22 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27C261A0707 for ; Wed, 3 Sep 2014 15:23:20 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id 10so1876772lbg.2 for ; Wed, 03 Sep 2014 15:23:19 -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=FdYYFkpixduZq8VzzH1f/qn8f+4ysGD9jlS3JXPkqFs=; b=xZ9eyc1IOozgslIFn7dpMD5UtYYAh4SRDiPgVvTuOasJ8INRUbdSrSXbEVqYLr4RqG KA7rUhdKTmoF4f3Bccn3idzAlrvfe2PHixsW3asBoFz2HYYMp3vHJVOTLAzlDTPcO66n JkYhAv8YI1Rk0UEu0cKYCLJfbOgKYwsdgIYihM9XFeBXwIsg6J8UWriM2KIsKqkpIs2u 2VRzv4Wspgbvx4z95BgrUGnXXAEtc75VJpeGgH7Ope6TP2UukDOYzWx+7CgQmam1MdnN jj8KwKvvUxkx3dz2Akcan6dQMQ2zVNooHrW8vXXNG8y6GAk1awFsoQSPlNibNQBuYnhy OpJQ== MIME-Version: 1.0 X-Received: by 10.152.42.209 with SMTP id q17mr282516lal.13.1409782999418; Wed, 03 Sep 2014 15:23:19 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Wed, 3 Sep 2014 15:23:19 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> Date: Wed, 3 Sep 2014 15:23:19 -0700 Message-ID: From: Martin Thomson To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WBFkI58J43pTBDiEZy7X3iGHW_c Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 22:23:23 -0000 On 3 September 2014 13:56, Nico Williams wrote: > Nothing short of a new (possibly asynchronous) DH exchange will > prevent compromise of the past for connections still live at the time > of compromise. Maybe I'm not that smart, but I don't get that. The scheme I originally proposed had the master secret fed into the PRF in order to generate a new master secret, with the old master secret ultimately being discarded. Once the old MS is gone, I don't see how an attacker can recover plaintext prior to the rekeying that preceded the break. That is, without a preimage attack on the hash function being used. From nobody Wed Sep 3 15:30:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CDE21A6FD2 for ; Wed, 3 Sep 2014 15:30:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-_38kCU_l4p for ; Wed, 3 Sep 2014 15:30:07 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D73C1A6FE5 for ; Wed, 3 Sep 2014 15:30:01 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 485142AAFE5; Wed, 3 Sep 2014 22:30:00 +0000 (UTC) Date: Wed, 3 Sep 2014 22:30:00 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140903222959.GA14392@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/inCnWytZUxsxcwhCuw3JgwRzc6U Subject: Re: [TLS] Ticket caching (was Re: tickets or sesssions or both (oh my)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@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: Wed, 03 Sep 2014 22:30:09 -0000 On Wed, Sep 03, 2014 at 03:15:05PM -0700, Martin Thomson wrote: > On 3 September 2014 14:12, Nico Williams wrote: > > I say "almost" because there is one benefit to encrypted session > > tickets: there is but one small key (O(1) storage) to > > protect/keep/wipe/rotate/watch on the server side, compared to N cache > > entries otherwise, which are O(N) for storage and might well spill > > over to swap space and so on. > > Well, the information is out there, so there is always the (hopefully > remote) chance that the ticket itself could be decrypted, which > wouldn't be possible if a reference were used. Not sure that that's > much of a distinction either. If the encryption algorithm is not weak, the public exposure of ciphertext encrypted with a secret key subject to periodic rotation and disposal, is not significantly different from secret plaintext subject to periodic rotation and disposal. The difference is historical implementation shortcuts, dating back to a kinder/gentler Internet where PFS was rarely used and was not considered important, or simply not prioritized by the developers. The shortcuts can and should be addressed, but *outside* the TLS protocol. When I get a chance later this year, I'd like to contribute some of the Postfix key rotation code to OpenSSL, making it much easier for applications to implement key rotation correctly. Obviously the communication with some sort of cluster-wide store would still need to be abstracted via a callback, but the logic of when to rotate keys, caching the current and previous key, ... can be implemented in a generic way. -- Viktor. From nobody Wed Sep 3 15:55:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E387C1A078D for ; Wed, 3 Sep 2014 15:55:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id repDHCMbt3lv for ; Wed, 3 Sep 2014 15:55:54 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 443431A0665 for ; Wed, 3 Sep 2014 15:55:54 -0700 (PDT) Received: from homiemail-a54.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTP id A6F754012D697 for ; Wed, 3 Sep 2014 15:55:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=ySsZ+zUV9nqyqSqfP6UM 2X2fJUI=; b=aUMzkF37gp9fD8RRe2KMiboHSWcAVXDnR4JrGZo2D0i4hohcqCaA Rh2Nk5iNoGKi75yDULVt4pupJEb8wbv0em9E19WZsIxDSXcya/TsTfuoeQv1PNKu v4ZVdsW01dOQ+A/jjxVOTOFAHchpzuzNkIqrZ2R8870Z3r5xsd+YwX4= Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a54.g.dreamhost.com (Postfix) with ESMTPSA id 588854012D696 for ; Wed, 3 Sep 2014 15:55:53 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id n12so9259740wgh.7 for ; Wed, 03 Sep 2014 15:55:52 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.75.17 with SMTP id y17mr624050wiv.3.1409784952085; Wed, 03 Sep 2014 15:55:52 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Wed, 3 Sep 2014 15:55:51 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> Date: Wed, 3 Sep 2014 17:55:51 -0500 Message-ID: From: Nico Williams To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/sccTj9cBaITTTQueT5yD26razt8 Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 22:55:55 -0000 On Wed, Sep 3, 2014 at 5:23 PM, Martin Thomson wrote: > On 3 September 2014 13:56, Nico Williams wrote: >> Nothing short of a new (possibly asynchronous) DH exchange will >> prevent compromise of the past for connections still live at the time >> of compromise. > > Maybe I'm not that smart, but I don't get that. The scheme I > [...] No, it's I who brainfarted. But even so, if you are paranoid enough you'll want to do a PFS DH exchange often. You might fear, for example, that the server doesn't expunge old secrets often enough (considering the level of paranoia we're showing as a group, this is not too farfetched). Nico -- From nobody Wed Sep 3 16:01:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F3A61A6F0A for ; Wed, 3 Sep 2014 16:01:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27J9gMjDpC9G for ; Wed, 3 Sep 2014 16:00:59 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id C50791A0921 for ; Wed, 3 Sep 2014 16:00:59 -0700 (PDT) Received: from homiemail-a33.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTP id A057559405E for ; Wed, 3 Sep 2014 16:00:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=Q9d+iX6kG/vj01z75byJ 4WEvrnI=; b=eAJjpBY8JAPAm4aM2+6DaV3L4bpdSMVbUu0eaY2B6Ep0jdoaOUUj CW7IR1RsPaxXrvDUEkPu0VNZrxn35H7EgmD0lnqy/04mYPEAlkEOu+tS/EcwTZTR BsOLj9elZwAaDmVk6NcfEgqOszfb8digyI0LRZ4z5sFQsz+/5yLVQOY= Received: from mail-wg0-f48.google.com (mail-wg0-f48.google.com [74.125.82.48]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a33.g.dreamhost.com (Postfix) with ESMTPSA id 4EAC5594058 for ; Wed, 3 Sep 2014 16:00:59 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id n12so9199748wgh.19 for ; Wed, 03 Sep 2014 16:00:58 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.123.1 with SMTP id lw1mr783452wjb.4.1409785258145; Wed, 03 Sep 2014 16:00:58 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Wed, 3 Sep 2014 16:00:58 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Sep 2014 18:00:58 -0500 Message-ID: From: Nico Williams To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-knkB8zs52Jy4VeXcW-6JS7Wga4 Cc: "tls@ietf.org" Subject: Re: [TLS] Ticket caching (was Re: tickets or sesssions or both (oh my)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 23:01:00 -0000 On Wed, Sep 3, 2014 at 5:15 PM, Martin Thomson wrote: > On 3 September 2014 14:12, Nico Williams wrote: >> I say "almost" because there is one benefit to encrypted session >> tickets: there is but one small key (O(1) storage) to >> protect/keep/wipe/rotate/watch on the server side, compared to N cache >> entries otherwise, which are O(N) for storage and might well spill >> over to swap space and so on. > > Well, the information is out there, so there is always the (hopefully > remote) chance that the ticket itself could be decrypted, which > wouldn't be possible if a reference were used. Not sure that that's > much of a distinction either. That's just as true of any other ciphertext, including the entire TLS connection's. We have no choice but to trust our ciphers, otherwise we're done here. (Well, we always have one more choice: design new ciphers. But let's not go there.) The point is that the session tickets, if encrypted with a decent cipher (and mode) should be as secure as all TLS ciphertext. And tickets are no more appealing a target of cryptanalysis than, say, the TLS handshake. We have to trust the crypto from this point of view. (While where we're working on the crypto algs we must work to make them strong enough to be so trusted.) >> Not having any kind of session resumption would be disastrous if >> adopted, surely leading to failure to adopt. > > There was some early talk about whether it might be needed, but it's > been clear to me at least for some time now that we need resumption. > And tickets do have scaling characteristics that are very appealing. Exactly. Nico -- From nobody Wed Sep 3 17:29:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A75421A0692 for ; Wed, 3 Sep 2014 17:29:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otKuMG0IuWUZ for ; Wed, 3 Sep 2014 17:29:03 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AFFD1A0BEA for ; Wed, 3 Sep 2014 17:29:03 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id b17so11001571lan.27 for ; Wed, 03 Sep 2014 17:29:01 -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=EiyAXmyAzsx8azf9eYbp8CJpncUBjLy1x8ARssNhI+s=; b=a+vLmWbmnu8YTcEQGNwEBHC65xSwbmPOtzGB6qH4Eurl/rNWV879OABPC7jjAUUAKI /JidJrCp2DbP7EfBx/bbpC7kOl1qhPHHm8zqhXnb8Hd/y/kPUfRod9IVuz6XIMEdeyQk 9dfcsdlJ7PfnRT/HEkru+trObGmK+kdld7eL8ggiriF9WUNFVkJqzbkLFfxjoF7puWXO 5ajbB0D3skDSrckLg1OtJjh8R7M/QcpsWXhVm1IFOO8T+DcHuUoH+nY32eCQIL1tHaOn G4EsYCUJ2bzAzM+f9Mb4RPZMcZrDl3I9BbmAMy1C09ibIx3J1X4S3pUz9OrGxaKpnNXY C7fw== MIME-Version: 1.0 X-Received: by 10.112.199.161 with SMTP id jl1mr666595lbc.59.1409790541625; Wed, 03 Sep 2014 17:29:01 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Wed, 3 Sep 2014 17:29:01 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Sep 2014 17:29:01 -0700 Message-ID: From: Martin Thomson To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Wff39eXTSFJmWBwDL7lHJHjuMR8 Cc: "tls@ietf.org" Subject: Re: [TLS] Ticket caching (was Re: tickets or sesssions or both (oh my)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 04 Sep 2014 00:29:04 -0000 On 3 September 2014 16:00, Nico Williams wrote: > The point is that the session tickets, if encrypted with a decent > cipher (and mode) should be as secure as all TLS ciphertext. And > tickets are no more appealing a target of cryptanalysis than, say, the > TLS handshake. We have to trust the crypto from this point of view. > (While where we're working on the crypto algs we must work to make > them strong enough to be so trusted.) Generally, I agree. The only difference here being that there is no agreement. The client has essentially no say on what level of protection is employed. From nobody Wed Sep 3 17:30:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 507971A0B79 for ; Wed, 3 Sep 2014 17:30:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dZH8sfQUMWU1 for ; Wed, 3 Sep 2014 17:30:48 -0700 (PDT) Received: from mail-lb0-x232.google.com (mail-lb0-x232.google.com [IPv6:2a00:1450:4010:c04::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EC05C1A0692 for ; Wed, 3 Sep 2014 17:30:47 -0700 (PDT) Received: by mail-lb0-f178.google.com with SMTP id v6so10685544lbi.9 for ; Wed, 03 Sep 2014 17:30:46 -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=5W104Yi/C6+A9qOX36BPVpHcFeEP5M8V+UmjTsTODtE=; b=z/Fq0vSp1Ae27yZRXN3F/MNNnNJO+N5IdsxAHfXNseZ5kyJgYmt4bs8GBqJ+Uh73mP UDPsL2Z7Cs96ucQqC0kWrpVVW0+dl3oXQqo2sdm8KgpKYE8G0AmHpDH8yDEK7iMWne2N KsbisA1F1U8kIBZ68CUQ4MSBqMsI+fIsl3Ow4tq4A7TgKE1Rz3ebKCf+6W1kerAart3x YNqND/G2nKLwvSwAN6phs8+sqdEpd+vXNRjkBJrBB8DiYjPhknlWUnwraJrkix7psiw3 TjKV+aqIW3OC+6+AXqj96d7/XFsyVvNTzMfj9fdx9tguAhvkDz16ckM2Qi5U5Z38cfwt cgRg== MIME-Version: 1.0 X-Received: by 10.112.199.161 with SMTP id jl1mr672401lbc.59.1409790646132; Wed, 03 Sep 2014 17:30:46 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Wed, 3 Sep 2014 17:30:45 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> Date: Wed, 3 Sep 2014 17:30:45 -0700 Message-ID: From: Martin Thomson To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fjmlBF4sK7tbolS1zrTeYJt4dXU Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 04 Sep 2014 00:30:49 -0000 On 3 September 2014 15:55, Nico Williams wrote: > But even so, if you are paranoid enough you'll want to do a PFS DH > exchange often. You might fear, for example, that the server doesn't > expunge old secrets often enough (considering the level of paranoia > we're showing as a group, this is not too farfetched). My conversations indicate that there is little willingness to incur much complexity cost here. New connections are relatively cheap after all. At least we know that new connections will have forward secrecy (if you don't resume, that is). From nobody Wed Sep 3 17:34:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5A11A0692 for ; Wed, 3 Sep 2014 17:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CWmiIGijnS9S for ; Wed, 3 Sep 2014 17:34:37 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 4798F1A0390 for ; Wed, 3 Sep 2014 17:34:37 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTP id E5BA920047B6A for ; Wed, 3 Sep 2014 17:34:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=tBeOIGn9PopC40bBGmbT b42p3yY=; b=pYSurwuINiY6ZiffiREB9O6q1lSJFN2XWwXrl7oZz4ec/9Deknkg 4IFZU1ANy7Z81lhODKgiBzM+27dwfWYWYLxoaZ/3LWUhCQ97u5KFdhvTYaROj1ZC 26dMs/9BNh1WyYD4z2aRwwuzAL/YivpiJg/fNipHiiZj92xxdoev+hk= Received: from mail-wi0-f179.google.com (mail-wi0-f179.google.com [209.85.212.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTPSA id 9970920047B5D for ; Wed, 3 Sep 2014 17:34:36 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id q5so151938wiv.12 for ; Wed, 03 Sep 2014 17:34:35 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.75.17 with SMTP id y17mr1113878wiv.3.1409790875578; Wed, 03 Sep 2014 17:34:35 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Wed, 3 Sep 2014 17:34:35 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> Date: Wed, 3 Sep 2014 19:34:35 -0500 Message-ID: From: Nico Williams To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2W6xR0pThWSqn2S7eFYcIjrJ2UU Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 04 Sep 2014 00:34:38 -0000 On Wed, Sep 3, 2014 at 7:30 PM, Martin Thomson wrote: > On 3 September 2014 15:55, Nico Williams wrote: >> But even so, if you are paranoid enough you'll want to do a PFS DH >> exchange often. You might fear, for example, that the server doesn't >> expunge old secrets often enough (considering the level of paranoia >> we're showing as a group, this is not too farfetched). > > My conversations indicate that there is little willingness to incur > much complexity cost here. New connections are relatively cheap after > all. At least we know that new connections will have forward secrecy > (if you don't resume, that is). I agree. But I was making a point. The point is: there's nothing wrong with session resumption as such. Servers should rotate session ticket encryption keys / expire / expunge cached sessions frequently -- that should be enough. Nico -- From nobody Wed Sep 3 17:35:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD8661A0692 for ; Wed, 3 Sep 2014 17:35:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNnIRZ049lsg for ; Wed, 3 Sep 2014 17:35:35 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 33A5B1A0390 for ; Wed, 3 Sep 2014 17:35:35 -0700 (PDT) Received: from homiemail-a35.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTP id 0F65B54058 for ; Wed, 3 Sep 2014 17:35:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=y3w4de1O3sB8X9QW820I 0qA5wWI=; b=nXh3ZSJO4WYVp20T/1ck0e1np0l4Woa+CG65CHsRd174tOTmrrob bSZ9QETUtA61kgSChWATyob1KSsSE+zD1z+a40qUHfZuNK4F87/Kg+nU2Jg84P5C 8lb/1xzci0HAIqLttanLkDAILX5gvG84I0/9dRm+AEo/kH1nixTNn6s= Received: from mail-we0-f169.google.com (mail-we0-f169.google.com [74.125.82.169]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a35.g.dreamhost.com (Postfix) with ESMTPSA id B90C054057 for ; Wed, 3 Sep 2014 17:35:34 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id k48so9492980wev.0 for ; Wed, 03 Sep 2014 17:35:33 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.87.66 with SMTP id v2mr1178105wiz.28.1409790933592; Wed, 03 Sep 2014 17:35:33 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Wed, 3 Sep 2014 17:35:33 -0700 (PDT) In-Reply-To: References: Date: Wed, 3 Sep 2014 19:35:33 -0500 Message-ID: From: Nico Williams To: Martin Thomson Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DWaADBrRvvNGEqvFFI9MJYZFTsk Cc: "tls@ietf.org" Subject: Re: [TLS] Ticket caching (was Re: tickets or sesssions or both (oh my)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 04 Sep 2014 00:35:35 -0000 On Wed, Sep 3, 2014 at 7:29 PM, Martin Thomson wrote: > On 3 September 2014 16:00, Nico Williams wrote: >> The point is that the session tickets, if encrypted with a decent >> cipher (and mode) should be as secure as all TLS ciphertext. And >> tickets are no more appealing a target of cryptanalysis than, say, the >> TLS handshake. We have to trust the crypto from this point of view. >> (While where we're working on the crypto algs we must work to make >> them strong enough to be so trusted.) > > Generally, I agree. > > The only difference here being that there is no agreement. The client > has essentially no say on what level of protection is employed. The client also expects the server not to betray it in a myriad other ways. Nico -- From nobody Wed Sep 3 19:03:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 247EF1A87EF for ; Wed, 3 Sep 2014 19:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V80lLrEVxr0J for ; Wed, 3 Sep 2014 19:03:51 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (prod-mail-xrelay06.akamai.com [96.6.114.98]) by ietfa.amsl.com (Postfix) with ESMTP id 51E8E1A87EE for ; Wed, 3 Sep 2014 19:03:51 -0700 (PDT) Received: from prod-mail-xrelay06.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 866331657B7; Thu, 4 Sep 2014 02:03:48 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay06.akamai.com (Postfix) with ESMTP id 7BB891657B6; Thu, 4 Sep 2014 02:03:48 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub6.kendall.corp.akamai.com [172.27.105.22]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 5BED498041; Thu, 4 Sep 2014 02:03:48 +0000 (GMT) Received: from Tereva.local (172.19.45.178) by usma1ex-cashub6.kendall.corp.akamai.com (172.27.105.22) with Microsoft SMTP Server (TLS) id 8.3.348.2; Wed, 3 Sep 2014 22:03:47 -0400 From: Brian Sniffen To: Nico Williams , Martin Thomson In-Reply-To: References: User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-apple-darwin12.3.0) Date: Wed, 3 Sep 2014 22:03:46 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/tls/C8KNf1vWbjP11_imFbILb0ia5hk Cc: "tls@ietf.org" Subject: Re: [TLS] Ticket caching (was Re: tickets or sesssions or both (oh my)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 04 Sep 2014 02:03:55 -0000 > The point is that the session tickets, if encrypted with a decent > cipher (and mode) should be as secure as all TLS ciphertext. And > tickets are no more appealing a target of cryptanalysis than, say, the > TLS handshake. We have to trust the crypto from this point of view. That's true for a secrecy goal. But is it the same for privacy? Does it matter that a browser will retain tickets, which identify conversational partners, for a while---and even if the browser cache, DNS cache, cookie store, etc., are cleared? -Brian -- Brian Sniffen "I reserve the right to evolve my views, and state that views I previously expressed may have been somehere along the spectrum from insufficiently nuanced through ill-informed to dead wrong." From nobody Wed Sep 3 19:16:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C48101A882D for ; Wed, 3 Sep 2014 19:16:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yc6d8OiKez3j for ; Wed, 3 Sep 2014 19:16:24 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 033E31A882F for ; Wed, 3 Sep 2014 19:16:24 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 2E9872AB2D0; Thu, 4 Sep 2014 02:16:22 +0000 (UTC) Date: Thu, 4 Sep 2014 02:16:22 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140904021621.GC14392@mournblade.imrryr.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/toRcYAqZJAqDa3OV17gPXlX4l8M Subject: Re: [TLS] Ticket caching (was Re: tickets or sesssions or both (oh my)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@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: Thu, 04 Sep 2014 02:16:26 -0000 On Wed, Sep 03, 2014 at 10:03:46PM -0400, Brian Sniffen wrote: > > The point is that the session tickets, if encrypted with a decent > > cipher (and mode) should be as secure as all TLS ciphertext. And > > tickets are no more appealing a target of cryptanalysis than, say, the > > TLS handshake. We have to trust the crypto from this point of view. > > That's true for a secrecy goal. But is it the same for privacy? > > Does it matter that a browser will retain tickets, which identify > conversational partners, for a while---and even if the browser cache, > DNS cache, cookie store, etc., are cleared? Tickets are I expect typically just part of the cached client-side session object, at least with OpenSSL, they are not cached explicitly. There's a lot more of value in the rest of the client-side session than the ticket. In fact the ticket is the least interesting part of client-side state, it does not even contain the identity of the peer, just an iv, key-id and some ciphertext. All the fun bits are encrypted by a key available only to the server. -- Viktor. From nobody Wed Sep 3 21:39:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70FDF1A029F for ; Wed, 3 Sep 2014 21:39:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BA4gE4a7DFrm for ; Wed, 3 Sep 2014 21:39:36 -0700 (PDT) Received: from na3sys010aog114.obsmtp.com (na3sys010aog114.obsmtp.com [74.125.245.96]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E8461A0296 for ; Wed, 3 Sep 2014 21:39:36 -0700 (PDT) Received: from mail-vc0-f181.google.com ([209.85.220.181]) (using TLSv1) by na3sys010aob114.postini.com ([74.125.244.12]) with SMTP ID DSNKVAftCBoah7Sp/gQ1Uvplu8JR9mSTg9Bg@postini.com; Wed, 03 Sep 2014 21:39:36 PDT Received: by mail-vc0-f181.google.com with SMTP id ij19so10084777vcb.12 for ; Wed, 03 Sep 2014 21:39:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=CX7wSBPj1HlRYjeM8gKaS+cA+N90TlrG9S6C24RVrEk=; b=NzgcQoRUNW5rUjpYeNIvA+6SyADCKssPiWCNZfVvle3PIRKizrvlaNXh4Fboi8EA57 nmneeK8BJNt1HMyj2pJn/It2SWI0ICJ43+AsNc+grpudxMSuoFkg3FU0Sq0KWiYDb51O ZuKR8OyYB9lbIpy4DDd/7P2DAijSuhQvSWFWo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type:content-transfer-encoding; bh=CX7wSBPj1HlRYjeM8gKaS+cA+N90TlrG9S6C24RVrEk=; b=HWCQQPYeU9nqv2ZuJI28vcaeyXgAfqHMhXy24dCp8TLIpp+zj1i8UvSijyE06UL3yU kzUGozvtvTaz8+DVDGalptM6xjt1HHFJeSFxbsqk7tabxoBsCCEheiGra2aUUOOFJ55R GlOqD9hCmetoazaYm3sR1PzhbOQj3ZfcEh6hrjFysYa6/18mbG+sayUoQPCtD8xTXsR9 eUkWpEODmyePfxj7ijrgRVLm6i5+c7HM9ohw0LbuUWgk9SsooLQVlQLFR0HWPjzzg8DA OrGeetNEKd52rywQmYVbcew9/ds+B7vdoy9Xb/5LY2y7pip9u2rlVLW1GO7WRpeDL8e5 YMgA== X-Gm-Message-State: ALoCoQmor6wEidwQeWl2WgYHufPVeaFMH+W8WnCWOAuQP4ZxEGvTj7C7ddWNEsF2/vi4E00E0G1dYOBAgZVRPxi0WNTYDdyJiKi5B74iG+430rOyCtJBnGCyQPYuYkTTnZgDgLcdZqND X-Received: by 10.52.249.66 with SMTP id ys2mr1163216vdc.41.1409805575552; Wed, 03 Sep 2014 21:39:35 -0700 (PDT) X-Received: by 10.52.249.66 with SMTP id ys2mr1163208vdc.41.1409805575435; Wed, 03 Sep 2014 21:39:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.134.70 with HTTP; Wed, 3 Sep 2014 21:39:15 -0700 (PDT) In-Reply-To: <9120B6EE-F023-4724-9116-A169993F58E8@ll.mit.edu> References: <54048985.1020005@net.in.tum.de> <3EB754B7-F6B2-4207-A2F0-E61F32EE1E40@ll.mit.edu> <54075016.6040406@net.in.tum.de> <20140903174958.GF14392@mournblade.imrryr.org> <5407574B.5060708@net.in.tum.de> <9120B6EE-F023-4724-9116-A169993F58E8@ll.mit.edu> From: Yutaka OIWA Date: Thu, 4 Sep 2014 13:39:15 +0900 Message-ID: To: "Blumenthal, Uri - 0668 - MITLL" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DI1NafLl0c0KoOPQHUsmaONgCUA Cc: "" Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 04 Sep 2014 04:39:38 -0000 > What you probably want to specify here is =E2=80=9CSHOULD NOT=E2=80=9D. In my opinion, it shall absolutely be "MUST NOT" for "generic use cases" for which the document is applicable. The possible problem is that it lacks the definition of "general use cases", but at least for over-Internet general communications like https or STARTTLS, it's MUST-NOT, not even SHOULD-NOT. All exceptional cases proposed on this topic seems to be, in my opinion, better treated as a "special use cases" not the target of this document. We may clarify its applicable scopes, of course. If the document were belonging to TLS WG, it were on the standards track, and looked like RFC 6176 (applicable for all use cases), I could agree that it shall be "SHOULD NOT". But it's UTA BCP document, and it's very important to say "MUST NOT for general applications" here. 2014-09-04 3:46 GMT+09:00 Blumenthal, Uri - 0668 - MITLL : > On Sep 3, 2014, at 14:00 , Ralph Holz wrote: >>>> That will make it clear that implementers are free to retain NULL (and >>>> they will), but that the purpose of the BCP is to propose secure TLS >>>> configurations to protect application-layer protocols, and for those n= o >>>> deployment should ever negotiate NULL. >>> >>> This is still too strong. Local MTA to Mail-Store LMTP is an >>> application protocol. It is a fine use-case for NULL ciphers. >> >> I hear you (and the others), but balancing the purpose of the BCP with >> such requirements as you mention leads me to believe we should favour >> the solution I proposed. I added one more thing, though: >> >> "Note: TLS implementations MAY retain code for the NULL cipher to allow >> specialised purposes like debugging, custom solutions, etc.=E2=80=9D > > Guys, > > Per RFC2119, certain words have certain meanings. :-) > > In particular, =E2=80=9CMUST NOT=E2=80=9D means not that =E2=80=9Cdon=E2= =80=99t do that unless you can claim an exception=E2=80=9D. It means =E2=80= =9Cdon=E2=80=99t do that as it is absolutely prohibited by this spec, no ex= ception=E2=80=9D. > > What you probably want to specify here is =E2=80=9CSHOULD NOT=E2=80=9D. > > Before replying - please check with RFC 2119. It=E2=80=99s three pages lo= ng, so wouldn=E2=80=99t take much of your time. > > (P.S. I wish people got really familiar with the standard terminology bef= ore trying to write/edit a standard.) > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --=20 Yutaka OIWA, Ph.D. Leader, System Life-cycle Research Group Research Institute for Secure Systems (RISEC= ) National Institute of Advanced Industrial Science and Technology (AIST= ) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5= ] From nobody Wed Sep 3 22:38:21 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F10E1A066A for ; Wed, 3 Sep 2014 22:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NoDudnNp6NxX for ; Wed, 3 Sep 2014 22:38:17 -0700 (PDT) Received: from mail-we0-x236.google.com (mail-we0-x236.google.com [IPv6:2a00:1450:400c:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D96B1A0669 for ; Wed, 3 Sep 2014 22:38:17 -0700 (PDT) Received: by mail-we0-f182.google.com with SMTP id w62so9717357wes.27 for ; Wed, 03 Sep 2014 22:38:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=hTpkz4jGVBrnajKgrHO4ohLCHrDLq5oUNClYwiaLSAg=; b=LNI+BIsFwHVMK/VCjZKuLI+Nnf2Z3bnWacEDhAzs8zs1/0N7OdieIvXPRnx7KubjTP LLB4qCpIFmXc7gl58nLYfqU4ZVDmgeJpsWYIvjhQtO9EVIs1HBY+lY6+m+JPuG8rI735 nHoqjn3i26a/NU+5CP20Xo0OaJN7HWQLYjqqOAxrkDGXVxrj59s2aZUc4tKQ7DB3msRG UnI9/0QSHTJa+q8EVjYMmtAnAUIq9xtumPnpfy/Uxgeu+lC+JVdSoMIg7gwHcTJRkKDS 504gN0r0o6QapBShYQbvuCtyEHtrPGoU/kl9PpwzV0aixiiBQlLBU379VkGV6Z+DFuiL ICNw== X-Received: by 10.194.81.230 with SMTP id d6mr2776321wjy.49.1409809095741; Wed, 03 Sep 2014 22:38:15 -0700 (PDT) Received: from [10.0.0.8] (bzq-79-180-189-16.red.bezeqint.net. [79.180.189.16]) by mx.google.com with ESMTPSA id s1sm141422wiw.6.2014.09.03.22.38.14 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 Sep 2014 22:38:15 -0700 (PDT) Message-ID: <5407FAC2.6090601@gmail.com> Date: Thu, 04 Sep 2014 08:38:10 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Karthikeyan Bhargavan , Martin Thomson References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> <20140903140059.GW14392@mournblade.imrryr.org> <1243278676.42405953.1409754600887.JavaMail.zimbra@redhat.com> <540728CE.6080305@fussenegger.info> <1589581250.42632708.1409761318984.JavaMail.zimbra@redhat.com> <20140903163948.GE14392@mournblade.imrryr.org> <18E884D9-204D-4D90-9DAF-3BFE8086732D@inria.fr> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/CC8JVGGeNo_CoctOjKVU_KO0EyQ Cc: "tls@ietf.org" Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 04 Sep 2014 05:38:19 -0000 Hi Kathik, You are implying that this attack only applies to session tickets and not to "regular" session caches, and I don't see why. Even if the client only sends a session ID, not a full ticket, but it associates the same ID incorrectly with both S and S', it will encrypt the first flight to S' with a master key that's known to S. Am I missing anything? I agree that TLS 1.3 should specify the scope of session identities, and thus, client-side behavior. Thanks, Yaron On 09/03/2014 11:12 PM, Karthikeyan Bhargavan wrote: > I apologize for lack of clarity. By forfeit I meant the following scenario, where a malicious server gets to read data sent to an honest server: > > Connection 1: > C connects to malicious S > S sends it a session ticket T which C stores. > > Connection 2: > C wants to connect to honest S. > C (incorrectly) uses the session ticket T to initiate resumption. > C optimistically encrypts sensitive data meant for S (e.g. cookies) under a key derived from (the master secret in) T. > > Result: > S gets to read data that C was sending to S. > Now, here, the fault is that C incorrectly cached T, so that it used T with S (whereas it should only be used with S). > This can easily happen if e.g. Cs client-side cache was indexed only an IP address and port. > > The question is what is the identity of S that C should use when storing the ticket? > Can we give some recommendations? > > > On 03 Sep 2014, at 16:03, Martin Thomson wrote: > >> On 3 September 2014 11:57, Karthikeyan Bhargavan >> wrote: >>> True, but if we use a 0RTT resumption scenario where the client starts >>> sending data immediately without waiting to see whether the server accepted the ticket, >>> then this data is forfeit. >> >> 0RTT creates some interesting side effects. I wouldn't have >> characterized the data as forfeit, just that there are certain >> considerations around the use of that first flight. The keys used to >> protect that data are different from the previous session, but they >> are derived from those previous keys. If we do some form of rekeying, >> I expect that the basis for the resumption keying material won't >> advance with any rekeying on the previous connection, so the lifetime >> of that data and corresponding potential for loss or exposure is >> greater. But the extent to which an attacker might be able to >> influence that data seems (at least intuitively) to be similar to the >> data sent on the previous connection. >> >> Resumption is less interesting in the 0RTT case than 0RTT without >> resumption, where the initial flight of data isn't protected with the >> server's new DH share. That is, it's basically not forward secure. >> That creates a reason to avoid sending or accepting that first flight. >> >> If by forfeit you mean that there is a risk that the data is not >> accepted by the server, that's a risk that I think is inherent in the >> design. In addition to the extra computation required to get 0RTT, >> the client will have to buffer and re-send data in some cases, paying >> the protection cost twice. Otherwise the API changes, and I don't >> think anyone wants that. > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Wed Sep 3 22:46:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12BDC1A067F for ; Wed, 3 Sep 2014 22:46:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ob8OASIstLts for ; Wed, 3 Sep 2014 22:46:44 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0B1E31A066F for ; Wed, 3 Sep 2014 22:46:43 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id CEFAE2AB2C5; Thu, 4 Sep 2014 05:46:42 +0000 (UTC) Date: Thu, 4 Sep 2014 05:46:42 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140904054642.GV14392@mournblade.imrryr.org> References: <54048985.1020005@net.in.tum.de> <3EB754B7-F6B2-4207-A2F0-E61F32EE1E40@ll.mit.edu> <54075016.6040406@net.in.tum.de> <20140903174958.GF14392@mournblade.imrryr.org> <5407574B.5060708@net.in.tum.de> <9120B6EE-F023-4724-9116-A169993F58E8@ll.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Fr1rxtaGyQkJAkOXnMw2C0CYkkU Subject: [TLS] uta-tls-bcp-02 thoughts (was: NULL cipher to become a MUST NOT in UTA BCP) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@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: Thu, 04 Sep 2014 05:46:46 -0000 On Thu, Sep 04, 2014 at 01:39:15PM +0900, Yutaka OIWA wrote: > > What you probably want to specify here is ?SHOULD NOT?. > > In my opinion, it shall absolutely be "MUST NOT" for > "generic use cases" for which the document is applicable. > > But it's UTA BCP document, and it's very important to > say "MUST NOT for general applications" here. I'd like to respond to the UTA draft more broadly, please feel free to forward or not to the UTA list (sorry, no cycles to actively engage in yet another IETF list). I am perplexed by the following from the draft's introduction: The recommendations herein take into consideration the security of various mechanisms, their technical maturity and interoperability, and their prevalence in implementations at the time of writing. These recommendations apply to both TLS and DTLS. TLS 1.3, when it is standardized and deployed in the field, should resolve the current vulnerabilities while providing significantly better functionality, and will very likely obsolete this document. If the document provides only "general application" guidance, that does not cover all TLS use-cases, then likely TLS 1.3 will include features that fall outside the general use-cases, and thus the document would continue to provide relevant general-case guidelines even with TLS 1.3 widely deployed. The introduction then goes on to state: These are minimum recommendations for the general use of TLS. Individual specifications may have stricter requirements related to one or more aspects of the protocol, based on their particular circumstances. When that is the case, implementers MUST adhere to those stricter requirements. What about specifications that might call for less strict requirements? In section 3.5 I am puzzled by the following text: If TLS session resumption is used, care ought to be taken to do so safely. In particular, the resumption information (either session IDs [RFC5246] or session tickets [RFC5077]) MUST be authenticated and encrypted to prevent modification or eavesdropping by an attacker. I am entirely unaware of the practice of encryption and authentication of session IDs. What is this about? Even session tickets are not "authenticated", rather they might be vended by a server as part of an authenticated session. Returning to session IDs, these are just server-side nonces, what does it mean that they should be authenticated, and are they in fact (with TLS <= 1.2) even encrypted? The recommendations for session ticket key rotation are I think too meek. They seem to be predicated on the notion that such rotation is some sort of externally managed task, automated via something akin to a cron job, where weekly rotation is about the right granularity. I'd like to suggest that session ticket key rotation SHOULD be a fully automated intrinsic component of the server application and server keys should not last much longer than sessions, a matter of minutes or hours not days. Key rotation should happen transparently while the application is running, without requiring restarts, and ideally without ever explicitly writing keys to persistent storage. Yes, this would be an aspirational part of the BCP, as few applications have this capability at present. For section 4.1, in light of the scope of section 4, the simplest solution is to suppress NULL cipher suites when any non-NULL cipher suites are configured. This avoids accidents, without prohibiting deliberate NULL-only configurations. For SMTP, RC4-SHA and RC4-MD5 is the only cipher suites that interoperate with Exchange 2003 servers, which are still handling mail for a small, but non-negligible number of domains. In fact these same servers only work if RC4 is among the first 64 cipher suites sent by the client, but with TLS 1.2, and all its new cipher suites that's often not the case. Are we really better off prohibiting RC4? Would it not suffice for servers to stop preferring RC4 (as was common with many HTTPS servers), and then stronger choices are automatically selected except with sites that only support RC4? It would be more helpful (and more interoperable) to specify a short list of "must implement" cipher suites, which SHOULD be preferred over the legacy ones, than to try to prohibit weaker cipher suites that are required for interoperability with older systems. Thus also MUST NOT or SHOULD NOT with EXPORT and 3DES cipher suites is less useful than promoting more secure alternatives. The draft in fact recommends four best practice cipher suites which should be preferred over the NOT RECOMMENDED weaker options. In section 6.1, the draft refers hostname verification to 6125, but 6125 contains little useful guidance for application protocols in which the server hostname is obtained indirectly via typically unauthenticated DNS SRV or MX records. In such protocols, the server name is not a viable reference identity. Some mention of the issue may be appropriate. http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-12#section-1.3.2 -- Viktor. From SRS0=0KKr=55=acm.org=bmoeller@srs.kundenserver.de Thu Sep 4 00:48:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3DEB81A6EF7 for ; Thu, 4 Sep 2014 00:48:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.596 X-Spam-Level: X-Spam-Status: No, score=-1.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tqlqm_0pNK_n for ; Thu, 4 Sep 2014 00:48:42 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B6521A6F62 for ; Thu, 4 Sep 2014 00:48:41 -0700 (PDT) Received: from mail-yh0-f42.google.com (mail-yh0-f42.google.com [209.85.213.42]) by mrelayeu.kundenserver.de (node=mreue004) with ESMTP (Nemesis) id 0Lxbix-1YSHgT3zPH-017A2n; Thu, 04 Sep 2014 09:48:39 +0200 Received: by mail-yh0-f42.google.com with SMTP id v1so6139104yhn.15 for ; Thu, 04 Sep 2014 00:48:37 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.14.130 with SMTP id d2mr3677943yhd.120.1409816917635; Thu, 04 Sep 2014 00:48:37 -0700 (PDT) Received: by 10.170.129.17 with HTTP; Thu, 4 Sep 2014 00:48:37 -0700 (PDT) In-Reply-To: <20140903145944.GB14392@mournblade.imrryr.org> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> <1408022371.42292099.1409744430634.JavaMail.zimbra@redhat.com> <412891267.42325154.1409748504518.JavaMail.zimbra@redhat.com> <20140903141149.GX14392@mournblade.imrryr.org> <20140903145944.GB14392@mournblade.imrryr.org> Date: Thu, 4 Sep 2014 09:48:37 +0200 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=089e0115eec892fc500502389459 X-Provags-ID: V02:K0:wrsMwIn80ijRFnW46gK83Yieuvo0oJeHf1lAmMdDViP HuZp3Mj9q537V9i82Fl3q5k/71HzkgTAT2LMKGPI8Hl53YN/eh uasdpBqyYS8oov1zaBZ68VGAjSmBj4z5jXy3bQ1fy+Gz+W/UP9 RIcNvTD/WyWr5xDPHxPNP6+XdkXruaJ/4BOk/jHliVkKAGVPOj YmQqFNVdUaI9+q60bHaDBr14RM1r6Z5lY++efe3GRYblOynMcj LVQyzgG9PnKdIkkInwcO83IlsHl6lLXzkZnDmBC/WGNWB6fTRy wpbGhbwHaOSwPHQ9esQP8CDQacelrWD3bwx5D/9EN29KHPospf m5R1kEa4qMa5EPsdKlI1JC+muvxUpACs9tmWtjUt6RSCXjieKU vXoTpQ+uyVO5lCiTWMdQeXDgxZQ+JTbi7NMxVQL5F/0VQk5V1F Lb+GP X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1gE5WnOXKM6t8Wtu6YFxUCETVkY Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 04 Sep 2014 08:05:43 -0000 --089e0115eec892fc500502389459 Content-Type: text/plain; charset=UTF-8 Viktor Dukhovni : > > > The cluster can employ at any given > > > time two keys, one used to encrypt new sessions, the other used to > > > decrypted as yet unexpired older sessions. A new key is agreed > > > periodically, by the cluster nodes, and then used to encrypt new > > > sessions. > > > > This doesn't sound quite right, actually: generally, the new key must be > > ready everywhere to decrypt session tickets before the first server > > instance can actually start to use it to encrypt a session ticket. > > Depends on the design, session tickets carry 16 byte key ids, and > a cache-miss protocol can be used to fetch a key not yet present > on a node, This may work well enough for a single cluster, but in general it would be better to make sure you distribute the new key *before* active use starts, thus avoiding the need for global synchronization from cache-miss situations. Bodo --089e0115eec892fc500502389459 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Vikt= or Dukhovni <ietf-dane@dukhovni.org>:
=C2=A0
> > The cluster can employ at any given
> > time two keys, one used to encrypt new sessions, the other used t= o
> > decrypted as yet unexpired older sessions.=C2=A0 A new key is agr= eed
> > periodically, by the cluster nodes, and then used to encrypt new<= br> > > sessions.
>
> This doesn't sound quite right, actually: generally, the new key m= ust be
> ready everywhere to decrypt session tickets before the first server > instance can actually start to use it to encrypt a session ticket.

Depends on the design, session tickets carry 16 byte key ids, and
a cache-miss protocol can be used to fetch a key not yet present
on a node,

This may work well enough for a = single cluster, but in general it would be better to make sure you distribu= te the new key *before* active use starts, thus avoiding the need for globa= l synchronization from cache-miss situations.

Bodo


--089e0115eec892fc500502389459-- From nobody Thu Sep 4 01:17:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A77301A6F8A for ; Thu, 4 Sep 2014 01:17:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XLOkaOrbJmgp for ; Thu, 4 Sep 2014 01:17:40 -0700 (PDT) Received: from mx205.easyname.com (mx205.easyname.com [212.232.28.126]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6812D1A6FBC for ; Thu, 4 Sep 2014 01:17:35 -0700 (PDT) Received: from 89-26-76-175.goll.dyn.salzburg-online.at ([89.26.76.175] helo=[192.168.0.11]) by mx.easyname.eu with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XPSES-0007Gg-SS for tls@ietf.org; Thu, 04 Sep 2014 10:17:34 +0200 Message-ID: <5408200B.2030104@fussenegger.info> Date: Thu, 04 Sep 2014 10:17:15 +0200 From: "Richard Fussenegger, BSc" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: tls@ietf.org References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> <1408022371.42292099.1409744430634.JavaMail.zimbra@redhat.com> <412891267.42325154.1409748504518.JavaMail.zimbra@redhat.com> <20140903141149.GX14392@mournblade.imrryr.org> <20140903145944.GB14392@mournblade.imrryr.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030700050903020809000400" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yQoqG18jOlgseOaPOMtH6zBDAXY Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 04 Sep 2014 08:17:45 -0000 This is a multi-part message in MIME format. --------------030700050903020809000400 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 9/4/2014 9:48 AM, Bodo Moeller wrote: > Viktor Dukhovni >: > > > > The cluster can employ at any given > > > time two keys, one used to encrypt new sessions, the other used to > > > decrypted as yet unexpired older sessions. A new key is agreed > > > periodically, by the cluster nodes, and then used to encrypt new > > > sessions. > > > > This doesn't sound quite right, actually: generally, the new key > must be > > ready everywhere to decrypt session tickets before the first server > > instance can actually start to use it to encrypt a session ticket. > > Depends on the design, session tickets carry 16 byte key ids, and > a cache-miss protocol can be used to fetch a key not yet present > on a node, > > > This may work well enough for a single cluster, but in general it > would be better to make sure you distribute the new key *before* > active use starts, thus avoiding the need for global synchronization > from cache-miss situations. > > Bodo > Twitter is doing that, they use a 20 minute timeout. But of course other tactics are also possible. Richard --------------030700050903020809000400 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit On 9/4/2014 9:48 AM, Bodo Moeller wrote:
Viktor Dukhovni <ietf-dane@dukhovni.org>:
> > The cluster can employ at any given
> > time two keys, one used to encrypt new sessions, the other used to
> > decrypted as yet unexpired older sessions. A new key is agreed
> > periodically, by the cluster nodes, and then used to encrypt new
> > sessions.
>
> This doesn't sound quite right, actually: generally, the new key must be
> ready everywhere to decrypt session tickets before the first server
> instance can actually start to use it to encrypt a session ticket.

Depends on the design, session tickets carry 16 byte key ids, and
a cache-miss protocol can be used to fetch a key not yet present
on a node,

This may work well enough for a single cluster, but in general it would be better to make sure you distribute the new key *before* active use starts, thus avoiding the need for global synchronization from cache-miss situations.

Bodo

Twitter is doing that, they use a 20 minute timeout. But of course other tactics are also possible.

Richard
--------------030700050903020809000400-- From nobody Thu Sep 4 01:31:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4A181A6FBA for ; Thu, 4 Sep 2014 01:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.596 X-Spam-Level: X-Spam-Status: No, score=-1.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9VnAA6vUL4U for ; Thu, 4 Sep 2014 01:31:39 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B219A1A6FAE for ; Thu, 4 Sep 2014 01:31:38 -0700 (PDT) Received: from mail-yk0-f178.google.com (mail-yk0-f178.google.com [209.85.160.178]) by mrelayeu.kundenserver.de (node=mreue102) with ESMTP (Nemesis) id 0LpfUc-1Y4rY12Icg-00fQ1a; Thu, 04 Sep 2014 10:31:35 +0200 Received: by mail-yk0-f178.google.com with SMTP id q200so5816819ykb.37 for ; Thu, 04 Sep 2014 01:31:34 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.43.203 with SMTP id l51mr3640747yhb.155.1409819494448; Thu, 04 Sep 2014 01:31:34 -0700 (PDT) Received: by 10.170.129.17 with HTTP; Thu, 4 Sep 2014 01:31:34 -0700 (PDT) In-Reply-To: References: <54048985.1020005@net.in.tum.de> <3EB754B7-F6B2-4207-A2F0-E61F32EE1E40@ll.mit.edu> <54075016.6040406@net.in.tum.de> <20140903174958.GF14392@mournblade.imrryr.org> <5407574B.5060708@net.in.tum.de> <9120B6EE-F023-4724-9116-A169993F58E8@ll.mit.edu> Date: Thu, 4 Sep 2014 10:31:34 +0200 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=089e0158bb482a066b0502392ed6 X-Provags-ID: V02:K0:LJrYUbsGbTvNugeFyph6g6eGC6fuLYbUTL9LrKd9DCN 2g3GpJh0ZXevIy58zr1dkOLuuuJHl41x9RQzMKXtZrjTk5iiAF JI399mXcKgkqt5l1c9ZJJarsaP7j6d7UjR8Tsbi3IlVTeAxqPm z+y3Oe9tQVjfXn9K/hH1adc9SD3nMsr817J7qHom8EqP4AjYsU N1x0GioQbMLNGaxfZHyTSc54/XWVV8BY/Wd/Eg93psHllfxZf7 OgmY3GIbRBiPYWMfmVGw8jeSA1sHT3+I1E8erT1Po06BLcwhqr D251kqrvEA6qYMJXMKCAqoXtyDsiTxrdDreN5bwVsHQezyh3gn 5SPBKtES1wLngLIpQTg4Zi2XT8jOeMWSVrOf4CpfptVuChaIns QWRtKs5ZORrFNaE3bKlEQzWczqBtuuNrwu8ldtEI9ocp9TQnX1 YHn+D X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xm1SAWZ637DJDavhavcqRHKDmvA Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 04 Sep 2014 08:31:40 -0000 --089e0158bb482a066b0502392ed6 Content-Type: text/plain; charset=UTF-8 Yutaka OIWA : If the document were belonging to TLS WG, > it were on the standards track, > and looked like RFC 6176 (applicable for all use cases), > I could agree that it shall be "SHOULD NOT". > It certainly can't matter which Working Group the document came from. Also, I don't think that issuing a BCP instead of a Proposed Standard means you can use "MUST NOT" willy-nilly. However, I think a major problem in this case it that draft-ietf-uta-tls-bcp-02 isn't actually clear about its intended scope: what does "secure use" actually mean? As pointed out before, the document uses the term "completely insecure" in a very fuzzy (and wrong) way -- authentication and integrity assurance without confidentiality isn't "completely" insecure: it obviously won't give you confidentiality, but still achieves other security notions. "Securing application-layer protocols" versus "specialized purposes" doesn't appear to be a very useful distinction for standardization purposes (*everything* that runs on top of TLS is an "application-layer protocol", as far as TLS is concerned anyway), so I essentially agree to Uri -- this looks like an attempt of ending up somewhere in between "MUST NOT" and "SHOULD NOT", and is not really acceptable. Also, those using integrity-only cipher suites clearly *do* want to secure their application-layer protocols, which takes us back to the problem about fuzzy "security" terminology in this I-D. So shouldn't the BCP document clarify its scope by being explicit that the recommendations only apply if your security goals do include confidentiality? In TLS 1.2, confidentiality very clearly is *intentionally* optional. If you create recommendations for its use and change this underlying assumption, you should be very clear about the scope of your recommendations. Bodo --089e0158bb482a066b0502392ed6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Yuta= ka OIWA <y.oiwa@aist.go.jp>:

If the document were belonging to TLS WG,
it were on the standards track,
and looked like RFC 6176 (applicable for all use cases),
I could agree that it shall be "SHOULD NOT".

It certainly can't matter which Working Group the docum= ent came from. Also, I don't think that issuing a BCP instead of a Prop= osed Standard means you can use "MUST NOT" willy-nilly.

However, I think a major problem in this case it that= =C2=A0draft-ietf-uta-tls-bcp-02 isn't actually clear about its intended= scope: what does "secure use" actually mean? As pointed out befo= re, the document uses the term "completely insecure" in a very fu= zzy (and wrong) way -- authentication and integrity assurance without confi= dentiality isn't "completely" insecure: it obviously won'= t give you confidentiality, but still achieves other security notions.

"Securing=C2=A0application-layer protocols" versus "spe= cialized purposes" doesn't appear to be a very useful distinction = for standardization purposes (*everything* that runs on top of TLS is an &q= uot;application-layer protocol", as far as TLS is concerned anyway), s= o I essentially agree to Uri -- this looks like an attempt of ending up som= ewhere in between "MUST NOT" and "SHOULD NOT", and is n= ot really acceptable. Also, those using integrity-only cipher suites clearl= y *do* want to secure their application-layer protocols, which takes us bac= k to the problem about fuzzy "security" terminology in this I-D.<= /span>

So = shouldn't the BCP document clarify its scope by being explicit that the= recommendations only apply=C2=A0if your security goals do include confidentiality?= =C2=A0In TLS 1.2, confidentiality very clearly is *intentionally* optional= . =C2=A0If you create recommendations for its use and change this underlyin= g assumption, you should be very clear about the scope of your recommendati= ons.

Bodo

--089e0158bb482a066b0502392ed6-- From nobody Thu Sep 4 02:10:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10A0E1A00EB for ; Thu, 4 Sep 2014 02:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.679 X-Spam-Level: X-Spam-Status: No, score=-3.679 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HFNjRdEZlhMt for ; Thu, 4 Sep 2014 02:10:46 -0700 (PDT) Received: from na3sys010aog113.obsmtp.com (na3sys010aog113.obsmtp.com [74.125.245.94]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5EF891A06BC for ; Thu, 4 Sep 2014 02:10:44 -0700 (PDT) Received: from mail-vc0-f174.google.com ([209.85.220.174]) (using TLSv1) by na3sys010aob113.postini.com ([74.125.244.12]) with SMTP ID DSNKVAgsk8qk9IxuKlbmFSYqlR7kqak3dNWg@postini.com; Thu, 04 Sep 2014 02:10:44 PDT Received: by mail-vc0-f174.google.com with SMTP id hy4so10243022vcb.19 for ; Thu, 04 Sep 2014 02:10:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aist.go.jp; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=CtBO099GTwqsTW3EYkZRELPNX7Zt6N7RUjGsEvLs0bw=; b=Of0v3ek1YGCgZqVDRLFjQcOc3GQOkRJ004RS9gqfwfAq2V6NochxMQv1LNlEOwG4sk z2RAePlVxPv0BUF/GOot+vAX3EVCyo32aPZWSu/gxtMfg9Gy2p6nYh9MLvbHroQGBY4V wfRNBXWNFaJAeK7n7tZHaa1snYC9Jgd19Uwc8= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=CtBO099GTwqsTW3EYkZRELPNX7Zt6N7RUjGsEvLs0bw=; b=H9n5FhpzvC0uZlb4b6UycGnbOlbcWxGHMIWZRGGCEo7t50YI+8SOb606OWZNkC3bTY AuVGn7TiMuhXlh/Bg4Fm2SVesMA4y9lMNUlzhBtTF1+GepHkY6zMjiX3pgQhvObm4YAQ 1bi0qOlTfvIl5/SM44wjitfE5S8QNYzX2PyXvRl7GcVaRaQNOcejpgWpifm5COtJws1c Gs5vmFG0CL0+Ficgq054dnWiTxAQ/zkLI+4gnqR8OKWZV+ZeB42+Sz655q+439Yp92sa lR+eumx8KgBAy4rLlrF6J3w1VEwVbQGSW57UjiUXB1aYrWWygt9Vn1aGjulhW6/PHYV5 yFig== X-Gm-Message-State: ALoCoQmowMn86NsZP0s9o287/+926PSv7cvtqcqMCHHaiTSZzic1CL7PtxDQ3BbKmwZQX27NjvJNLAr5aJefsEMHomXJuwvrcd34OVTgV20oAWWhOZmtjt+PC3h2lx7NFeXddUbGWsSU X-Received: by 10.52.129.165 with SMTP id nx5mr1125762vdb.25.1409821843062; Thu, 04 Sep 2014 02:10:43 -0700 (PDT) X-Received: by 10.52.129.165 with SMTP id nx5mr1125755vdb.25.1409821842973; Thu, 04 Sep 2014 02:10:42 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.134.70 with HTTP; Thu, 4 Sep 2014 02:10:22 -0700 (PDT) In-Reply-To: References: <54048985.1020005@net.in.tum.de> <3EB754B7-F6B2-4207-A2F0-E61F32EE1E40@ll.mit.edu> <54075016.6040406@net.in.tum.de> <20140903174958.GF14392@mournblade.imrryr.org> <5407574B.5060708@net.in.tum.de> <9120B6EE-F023-4724-9116-A169993F58E8@ll.mit.edu> From: Yutaka OIWA Date: Thu, 4 Sep 2014 18:10:22 +0900 Message-ID: To: Bodo Moeller Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DiyUIti8YrrPr4aTzhKaDKbl7O0 Cc: "tls@ietf.org" Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 04 Sep 2014 09:10:53 -0000 Dear Bodo, I agree, the most important point in my previous mail is whether the document is applicable for all use cases. Tracks and WG are not definitive regarding this. Sorry for any uncleanness. # The intention of me to include these words was # just to guess the document's intentions. So, the most important point I think is that we have a fairly broad range of "general use cases" which need a common strong BCP for TLS configurations. Current TLS 1.2 specification is too relaxed about this (intentionally, to support other use cases as well). In other words, the UTA draft is actually defining a secure restricted subset of TLS 1.2 (and 1.3+) for some subclass of use cases, and intend to force such restriction to "such use cases" on the Internet, using a "MUST-NOT" requirement term. I think it's quite important to clarify in which class of use cases UTA is intended to apply such a restriction. Currently "general use cases" is not well-defined and may misguide readers (including implementors) that NULL ciphers are forbidden in ALL use cases of TLS 1.2. 2014-09-04 17:31 GMT+09:00 Bodo Moeller : > Yutaka OIWA : > >> If the document were belonging to TLS WG, >> it were on the standards track, >> and looked like RFC 6176 (applicable for all use cases), >> I could agree that it shall be "SHOULD NOT". > > > It certainly can't matter which Working Group the document came from. Also, > I don't think that issuing a BCP instead of a Proposed Standard means you > can use "MUST NOT" willy-nilly. > > However, I think a major problem in this case it that > draft-ietf-uta-tls-bcp-02 isn't actually clear about its intended scope: > what does "secure use" actually mean? As pointed out before, the document > uses the term "completely insecure" in a very fuzzy (and wrong) way -- > authentication and integrity assurance without confidentiality isn't > "completely" insecure: it obviously won't give you confidentiality, but > still achieves other security notions. > > "Securing application-layer protocols" versus "specialized purposes" doesn't > appear to be a very useful distinction for standardization purposes > (*everything* that runs on top of TLS is an "application-layer protocol", as > far as TLS is concerned anyway), so I essentially agree to Uri -- this looks > like an attempt of ending up somewhere in between "MUST NOT" and "SHOULD > NOT", and is not really acceptable. Also, those using integrity-only cipher > suites clearly *do* want to secure their application-layer protocols, which > takes us back to the problem about fuzzy "security" terminology in this I-D. > > So shouldn't the BCP document clarify its scope by being explicit that the > recommendations only apply if your security goals do include > confidentiality? In TLS 1.2, confidentiality very clearly is > *intentionally* optional. If you create recommendations for its use and > change this underlying assumption, you should be very clear about the scope > of your recommendations. > > Bodo > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- Yutaka OIWA, Ph.D. Leader, System Life-cycle Research Group Research Institute for Secure Systems (RISEC) National Institute of Advanced Industrial Science and Technology (AIST) Mail addresses: , OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 46B5] From nobody Thu Sep 4 03:57:45 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7F81A024E for ; Thu, 4 Sep 2014 03:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.569 X-Spam-Level: X-Spam-Status: No, score=-7.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NDTd8TizP0g1 for ; Thu, 4 Sep 2014 03:57:42 -0700 (PDT) Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by ietfa.amsl.com (Postfix) with ESMTP id 7988D1A6F27 for ; Thu, 4 Sep 2014 03:57:42 -0700 (PDT) Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s84AvU4t027468; Thu, 4 Sep 2014 06:57:31 -0400 Date: Thu, 4 Sep 2014 06:57:29 -0400 (EDT) From: Hubert Kario To: "Richard Fussenegger, BSc" Message-ID: <2001913258.501023.1409828249685.JavaMail.zimbra@redhat.com> In-Reply-To: <54076BE7.7070500@fussenegger.info> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <540728CE.6080305@fussenegger.info> <1589581250.42632708.1409761318984.JavaMail.zimbra@redhat.com> <5407460F.1030707@fussenegger.info> <1474051094.43389347.1409763944473.JavaMail.zimbra@redhat.com> <5407543F.9020209@fussenegger.info> <15972987.43899141.1409770832774.JavaMail.zimbra@redhat.com> <54076BE7.7070500@fussenegger.info> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_501022_871021030.1409828249684" X-Originating-IP: [10.5.82.7] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922) Thread-Topic: tickets or sesssions or both (oh my) Thread-Index: gEcEU01CniHfwm/hZVhLMaxyrlWzWQ== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nhSrp3HMjidBjyW92LDZJRxfS6E Cc: tls@ietf.org Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 04 Sep 2014 10:57:44 -0000 ------=_Part_501022_871021030.1409828249684 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable ----- Original Message ----- > From: "Richard Fussenegger, BSc" > To: "Hubert Kario" > Cc: tls@ietf.org > Sent: Wednesday, September 3, 2014 9:28:39 PM > Subject: Re: [TLS] tickets or sesssions or both (oh my) > On 9/3/2014 9:00 PM, Hubert Kario wrote: > > I haven't analysed the attack in detail, but wouldn't a straight forwar= d > > implementation of tickets have the same issue? >=20 > Yes, both approaches have the same issue and it's something that develope= rs > have to fix in general. Just like the fail to implement rotation, but at > least a tech savvy admin can fix the rotation problem (e.g. via a cron jo= b > that restarts the server, although loosing decryption capability for the > last used key). Only the developers are able to fix the virtual host > confusion problem. I may look into this as well, but I'm not a dedicated = C > developer and this looks like a bigger problem. actually, from what I read, current upstream Apache does save the ticket en= cryption key to disk, so it is persistent across restarts of service=20 --=20 Regards,=20 Hubert Kario=20 Quality Engineer, QE BaseOS Security team=20 Email: hkario@redhat.com=20 Web: www.cz.redhat.com=20 Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic=20 ------=_Part_501022_871021030.1409828249684 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable


From= : "Richard Fussenegger, BSc" <richard@fussenegger.info>
To:= "Hubert Kario" <hkario@redhat.com>
Cc: tls@ietf.orgSent: Wednesday, September 3, 2014 9:28:39 PM
Subject: Re= : [TLS] tickets or sesssions or both (oh my)

On 9/3/2014 = 9:00 PM, Hubert Kario wrote:

I haven't analysed the attack in detail, but wouldn't a straight forw= ard implementation of tickets have the same issue?

Yes, both approaches have the same issue and it's something that de= velopers have to fix in general. Just like the fail to implement rotation, = but at least a tech savvy admin can fix the rotation problem (e.g. via a cr= on job that restarts the server, although loosing decryption capability for= the last used key). Only the developers are able to fix the virtual host c= onfusion problem. I may look into this as well, but I'm not a dedicated C d= eveloper and this looks like a bigger problem.


actually, from what I read, current upstream Apa= che does save the ticket encryption key to disk, so it is persistent across= restarts of service



--
Regards,
Hubert Kario
Quality Eng= ineer, QE BaseOS Security team
Email: hkario@redhat.com
Web: www.cz.r= edhat.com
Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czec= h Republic
------=_Part_501022_871021030.1409828249684-- From nobody Thu Sep 4 04:13:11 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C70811A067F for ; Thu, 4 Sep 2014 04:13:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.57 X-Spam-Level: X-Spam-Status: No, score=-7.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmLrS9YqE7tU for ; Thu, 4 Sep 2014 04:13:05 -0700 (PDT) Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) by ietfa.amsl.com (Postfix) with ESMTP id D67391A029C for ; Thu, 4 Sep 2014 04:13:05 -0700 (PDT) Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s84BD52H029938 for ; Thu, 4 Sep 2014 07:13:05 -0400 Date: Thu, 4 Sep 2014 07:13:05 -0400 (EDT) From: Hubert Kario To: tls@ietf.org Message-ID: <73876119.516276.1409829185555.JavaMail.zimbra@redhat.com> In-Reply-To: <5407804F.7030803@fussenegger.info> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <5407804F.7030803@fussenegger.info> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.5.82.7] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922) Thread-Topic: tickets or sesssions or both (oh my) Thread-Index: aR0nqhMYK+N3hs+BbBNnqZRZO5LIxQ== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AIw3-H99dzjd0yd_hG3LfCs4grc Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 04 Sep 2014 11:13:08 -0000 ----- Original Message ----- > From: "Richard Fussenegger, BSc" > To: tls@ietf.org > Sent: Wednesday, September 3, 2014 10:55:43 PM > Subject: Re: [TLS] tickets or sesssions or both (oh my) >=20 >=20 > On 9/3/2014 10:49 PM, Brian Sniffen wrote: > > Nico Williams writes: > > > >> (And if you want to add periodic PFS to long-lived sessions then you > >> need renego, no?) > >> > >> Anyways, the right thing to do is to REQUIRE frequent session ticket > >> encryption rotation / short ticket lifetimes. Look, session tickets > >> are an optimization, but a HUGE optimization at that. It's necessary. > > What about making session tickets optional? Clients or servers that > > want PFS can then decline to accept or generate tickets. > > > > -Brian > > > One can use session tickets together with PFS if rotation works. Of > course one could simply deactivate them to add a layer of paranoia but > one would have to disable session IDs as well because those could be > compromised too. I would go a step further: clients MUST NOT update the session cache TTL upon receiving a new ticket from a resumed connection. So that the client will force the server to perform full negotiation on a schedule established by the ticket hint. This will not help against compromised ticket encryption key, but will help for PFS in general. As for 24h limit on ticket lifetime: just a bit over 3.5% of https servers advertise longer lived tickets, and basically all of those use a 28h lifetime (less than 0.1% use longer than 28h).[1] 1 - http://wp.me/p4BPwe-1M --=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email: hkario@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic From nobody Thu Sep 4 04:19:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49E7D1A6FEF for ; Thu, 4 Sep 2014 04:19:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.57 X-Spam-Level: X-Spam-Status: No, score=-7.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y5eDoPDgVrt6 for ; Thu, 4 Sep 2014 04:19:53 -0700 (PDT) Received: from mx3-phx2.redhat.com (mx3-phx2.redhat.com [209.132.183.24]) by ietfa.amsl.com (Postfix) with ESMTP id E77031A6FE8 for ; Thu, 4 Sep 2014 04:19:52 -0700 (PDT) Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx3-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s84BJaV1030052; Thu, 4 Sep 2014 07:19:36 -0400 Date: Thu, 4 Sep 2014 07:19:36 -0400 (EDT) From: Hubert Kario To: Nico Williams Message-ID: <110869983.521310.1409829576818.JavaMail.zimbra@redhat.com> In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <5407804F.7030803@fussenegger.info> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Originating-IP: [10.5.82.7] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF31 (Linux)/8.0.6_GA_5922) Thread-Topic: tickets or sesssions or both (oh my) Thread-Index: 3QCOMeyMJt6bG0CtoyQrdyuFFhfsBw== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8elpTp45ATjKJoPgxEMk6_i_Jwc Cc: tls@ietf.org Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 04 Sep 2014 11:19:54 -0000 ----- Original Message ----- > From: "Nico Williams" > To: "Richard Fussenegger, BSc" > Cc: tls@ietf.org > Sent: Wednesday, September 3, 2014 11:04:14 PM > Subject: Re: [TLS] tickets or sesssions or both (oh my) >=20 > On Wed, Sep 3, 2014 at 3:55 PM, Richard Fussenegger, BSc > wrote: > > Also don't forget that tickets are already optional as it is now and I'= d > > keep that dual system at least for TLS 1.3, as I said earlier. Otherwis= e > > nobody will adopt the new protocol because of lack of support on client= and > > server side. But the next incarnation could drop one or the other. >=20 > Opaque session tickets of any length >> session IDs. The server can > always use session IDs as the ticket. IIRC this is Bodo's suggestion > for simplifying the protocol, and I agree. >=20 > There's really no need to say anything normative about server-side > resumption state vs. stateless resumption tickets -- it's an > implementation detail. Losing the distinction on the wire should help > simplify things. >=20 > The key is to require resumption state -whether stored on the server > or on the client with an encrypted session ticket- to be > deleted/expired periodically. For session tickets that's done by > rotating keys. For server-side state it's done by expunging expired > sessions from the cache. Either way the effect is the same. >=20 > Advice can be given about not storing these things on long-lived > storage (disk, ssd), just memory (e.g., tmpfs, ramdisk, whatever). >=20 > The where-is-the-state-stored distinction is not (should not be) > relevant to the protocol though. Session tickets do introduce parallel key schedule (even if implicitly), for a protocol that aims to provide PFS that makes them relevant. In the static key case, it will allow you to decrypt all of communication, future and past. Compromising the session cache requires you to keep it compromised to be able to decrypt future communication (and hope old sessions didn't get garbage collected to decrypt past communication). If the decision is to keep tickets, we need to be explicit about their use, acceptable practices, etc. Otherwise they will be the weakest link for the protocol. --=20 Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email: hkario@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky=C5=88ova 99/71, 612 45, Brno, Czech Republic From nobody Thu Sep 4 04:28:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F18D21A7033 for ; Thu, 4 Sep 2014 04:28:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fxbE79b2gIJ8 for ; Thu, 4 Sep 2014 04:28:32 -0700 (PDT) Received: from mx205.easyname.com (mx205.easyname.com [212.232.28.126]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C822E1A702D for ; Thu, 4 Sep 2014 04:28:31 -0700 (PDT) Received: from 89-26-76-175.goll.dyn.salzburg-online.at ([89.26.76.175] helo=[192.168.0.11]) by mx.easyname.eu with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XPVDH-00007D-Q5; Thu, 04 Sep 2014 13:28:30 +0200 Message-ID: <54084CCD.3020307@fussenegger.info> Date: Thu, 04 Sep 2014 13:28:13 +0200 From: "Richard Fussenegger, BSc" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Hubert Kario References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <540728CE.6080305@fussenegger.info> <1589581250.42632708.1409761318984.JavaMail.zimbra@redhat.com> <5407460F.1030707@fussenegger.info> <1474051094.43389347.1409763944473.JavaMail.zimbra@redhat.com> <5407543F.9020209@fussenegger.info> <15972987.43899141.1409770832774.JavaMail.zimbra@redhat.com> <54076BE7.7070500@fussenegger.info> <2001913258.501023.1409828249685.JavaMail.zimbra@redhat.com> In-Reply-To: <2001913258.501023.1409828249685.JavaMail.zimbra@redhat.com> Content-Type: multipart/alternative; boundary="------------020508090505030204060100" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/D9l3GJQ2OrJzTPmBtYRuf89-rC8 Cc: tls@ietf.org Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 04 Sep 2014 11:28:34 -0000 This is a multi-part message in MIME format. --------------020508090505030204060100 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 9/4/2014 12:57 PM, Hubert Kario wrote: > > > ------------------------------------------------------------------------ > > *From: *"Richard Fussenegger, BSc" > *To: *"Hubert Kario" > *Cc: *tls@ietf.org > *Sent: *Wednesday, September 3, 2014 9:28:39 PM > *Subject: *Re: [TLS] tickets or sesssions or both (oh my) > > On 9/3/2014 9:00 PM, Hubert Kario wrote: > > > I haven't analysed the attack in detail, but wouldn't a > straight forward implementation of tickets have the same issue? > > Yes, both approaches have the same issue and it's something that > developers have to fix in general. Just like the fail to implement > rotation, but at least a tech savvy admin can fix the rotation > problem (e.g. via a cron job that restarts the server, although > loosing decryption capability for the last used key). Only the > developers are able to fix the virtual host confusion problem. I > may look into this as well, but I'm not a dedicated C developer > and this looks like a bigger problem. > > > > actually, from what I read, current upstream Apache does save the > ticket encryption key to disk, so it is persistent across restarts of > service > I was of course mainly referring to nginx. I have absolutely no experience with Apache httpd in the last two years. I guess the Apache devs wanted the ability to decrypt old tickets upon restart. Something the nginx devs haven't given any thought as it seems. The complete nginx ticket system is fully built upon the provided OpenSSL functionality. Although a file based ticket key system found it's way to the mainline version. Richard --------------020508090505030204060100 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit
On 9/4/2014 12:57 PM, Hubert Kario wrote:


From: "Richard Fussenegger, BSc" <richard@fussenegger.info>
To: "Hubert Kario" <hkario@redhat.com>
Cc: tls@ietf.org
Sent: Wednesday, September 3, 2014 9:28:39 PM
Subject: Re: [TLS] tickets or sesssions or both (oh my)

On 9/3/2014 9:00 PM, Hubert Kario wrote:


I haven't analysed the attack in detail, but wouldn't a straight forward implementation of tickets have the same issue?

Yes, both approaches have the same issue and it's something that developers have to fix in general. Just like the fail to implement rotation, but at least a tech savvy admin can fix the rotation problem (e.g. via a cron job that restarts the server, although loosing decryption capability for the last used key). Only the developers are able to fix the virtual host confusion problem. I may look into this as well, but I'm not a dedicated C developer and this looks like a bigger problem.



actually, from what I read, current upstream Apache does save the ticket encryption key to disk, so it is persistent across restarts of service

I was of course mainly referring to nginx. I have absolutely no experience with Apache httpd in the last two years. I guess the Apache devs wanted the ability to decrypt old tickets upon restart. Something the nginx devs haven't given any thought as it seems. The complete nginx ticket system is fully built upon the provided OpenSSL functionality. Although a file based ticket key system found it's way to the mainline version.

Richard
--------------020508090505030204060100-- From nobody Thu Sep 4 04:42:36 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B1B1A8717 for ; Thu, 4 Sep 2014 04:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SABt7O9WrpQS for ; Thu, 4 Sep 2014 04:42:32 -0700 (PDT) Received: from mx203.easyname.com (mx203.easyname.com [212.232.28.124]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80D7F1A8549 for ; Thu, 4 Sep 2014 04:42:32 -0700 (PDT) Received: from 89-26-76-175.goll.dyn.salzburg-online.at ([89.26.76.175] helo=[192.168.0.11]) by mx.easyname.eu with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XPVQo-0000dK-3i for tls@ietf.org; Thu, 04 Sep 2014 13:42:30 +0200 Message-ID: <54085015.3020203@fussenegger.info> Date: Thu, 04 Sep 2014 13:42:13 +0200 From: "Richard Fussenegger, BSc" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: tls@ietf.org References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <5407804F.7030803@fussenegger.info> <73876119.516276.1409829185555.JavaMail.zimbra@redhat.com> In-Reply-To: <73876119.516276.1409829185555.JavaMail.zimbra@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kUcAaZxU_Apt2IN1dKv96A1Acm4 Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 04 Sep 2014 11:42:34 -0000 On 9/4/2014 1:13 PM, Hubert Kario wrote: > ----- Original Message ----- >> From: "Richard Fussenegger, BSc" >> To: tls@ietf.org >> Sent: Wednesday, September 3, 2014 10:55:43 PM >> Subject: Re: [TLS] tickets or sesssions or both (oh my) >> >> >> On 9/3/2014 10:49 PM, Brian Sniffen wrote: >>> Nico Williams writes: >>> >>>> (And if you want to add periodic PFS to long-lived sessions then you >>>> need renego, no?) >>>> >>>> Anyways, the right thing to do is to REQUIRE frequent session ticket >>>> encryption rotation / short ticket lifetimes. Look, session tickets >>>> are an optimization, but a HUGE optimization at that. It's necessary. >>> What about making session tickets optional? Clients or servers that >>> want PFS can then decline to accept or generate tickets. >>> >>> -Brian >>> >> One can use session tickets together with PFS if rotation works. Of >> course one could simply deactivate them to add a layer of paranoia but >> one would have to disable session IDs as well because those could be >> compromised too. > I would go a step further: clients MUST NOT update the session cache TTL > upon receiving a new ticket from a resumed connection. So that the client > will force the server to perform full negotiation on a schedule established > by the ticket hint. > > This will not help against compromised ticket encryption key, but will > help for PFS in general. > > As for 24h limit on ticket lifetime: just a bit over 3.5% of https servers > advertise longer lived tickets, and basically all of those use a 28h > lifetime (less than 0.1% use longer than 28h).[1] > > > 1 - http://wp.me/p4BPwe-1M Thanks for this info, much appreciated. I'd say that we define a 24h maximum limit for the server ticket encryption key (48h [or in other words ttl * 2] in total for decrypt only keys). Additionally we should define that clients remember the creation time of a new ticket and will automatically drop it, if it's older than 48h (or of course TTL is reached). I think it's important to define such times in the specs because otherwise you'll get confused admins and devs who don't know how to handle it. This will destroy the ability for long lived session tickets without PFS. But this isn't an issue if PFS is going to be mandatory for TLS 1.3 (which has my full support). If someone really needs long lived tickets for a custom server-client-app nothing holds them back from not being RFC compliant and thus remove PFS entirely. Richard From nobody Thu Sep 4 06:58:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 637A81A88C9 for ; Thu, 4 Sep 2014 06:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KE7mOzq_PU3o for ; Thu, 4 Sep 2014 06:58:05 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 876E71A0338 for ; Thu, 4 Sep 2014 06:58:05 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id z11so1201968lbi.38 for ; Thu, 04 Sep 2014 06:58:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=FcroHUtMJufXi7N7n1aS+YE/92rFcT1yYCyD0h+Bqtw=; b=jTLfgneBvet58fskh2uxxqRjviExtPxq9LBbidVXO2BqE7oWCp4vsvL1Xo1coMVt8b u13XcVVXzUgY3MPoo/IyLqd6ECMx4XY3ZZtwRvVROf9VOSL4gUi5lHeC7va+yi9yeSDu 7RQAMH0ETFQ6e3bQthLnhT3VDiu4/3U0BDvLHkXwRSldiVS4/hUT/ZrNh6JYEaDytkek i+XXJiDJFd4DFqUxUN0dy+UbxqvyJCQWO/6jVpJ2kxqq7TPQahb1RrdkNky+sO9f2hW+ 3g0u6IZFnkf4Cwl1u+GtJAEuRCdwg78mwMXv4reVj/wWgc9ahJwxvw4vdFmvn8tMFmdV YTGA== MIME-Version: 1.0 X-Received: by 10.152.20.71 with SMTP id l7mr166175lae.4.1409839083778; Thu, 04 Sep 2014 06:58:03 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.122.50 with HTTP; Thu, 4 Sep 2014 06:58:03 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> Date: Thu, 4 Sep 2014 09:58:03 -0400 X-Google-Sender-Auth: ugmPoeSKPjXu8lFG_DjUjVFJrQw Message-ID: From: Phillip Hallam-Baker To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mUQi2heuU9iIxLFF35E6lbAAVWE Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 04 Sep 2014 13:58:07 -0000 On Tue, Sep 2, 2014 at 1:05 PM, Salz, Rich wrote: > Right now we have sessions (server-side, possible scalability issues) and > tickets (client-side, hard to make work well with PFS). > > A poll for this community: is one likely to be more strategic, or are both > likely to be important in the near term (say within two years after TLS 1.3 > is done). Since the technical difference between the two is merely that a ticket is large enough for the server to embed encrypted notes to self, tickets are obviously the way to go. I don't see the issue with PFS and tickets. Tickets are a good way to implement PFS, you just need to be careful about how you separate your credentials. My view is that for TLS next generation, what we should do is to separate out key negotiation, forward secrecy and applying keys to transport. The Key Negotiation module can then be applied at any layer that we need it - Packet, Transport or Application. The output of the Key Negotiation mechanism is a set of cryptographic parameters (algorithms, shared key(s)) and an opaque session identifier whose internal structure does not need to be understood by any party other than the one that generated it. If we have that as a separate module in our toolbox, the application to DNS, TCP/IP, HTTP etc. becomes very straightforward. Instead of IPSEC being a whole different stack it is just a different application of TLS. Layering DNS security on top of TLS or DTLS makes no sense. You start off with a huge stack and make it larger. The larger the stack the larger the number of security holes are going to arise out of unexpected interactions. To achieve forward secrecy we simply have two levels of tickets. The top level negotiation returns a ticket and session ID that is then used to encrypt/authenticate parameters for a PFS exchange. Turning everything into tickets is astonishingly powerful. I have been using that a while and I encourage people to do the same. A lot of problems that seem hard, like encrypting SNI become a lot easier. It is much better for IETF as well, Kerberos and PKI are no longer polar opposites. Good forward planning for quantum computing if it ever arrives. From nobody Thu Sep 4 07:26:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAAEA1A88EB for ; Thu, 4 Sep 2014 07:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.678 X-Spam-Level: X-Spam-Status: No, score=-1.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J-yGSwc7hXQJ for ; Thu, 4 Sep 2014 07:26:12 -0700 (PDT) Received: from mail-oa0-f42.google.com (mail-oa0-f42.google.com [209.85.219.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 291B11A88D1 for ; Thu, 4 Sep 2014 07:26:12 -0700 (PDT) Received: by mail-oa0-f42.google.com with SMTP id m1so7294962oag.15 for ; Thu, 04 Sep 2014 07:26:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=tfckEPOnSQdmWP0hhb7wlhaIWuNy9kMl9W/8VNn4Sws=; b=j9QiN1gNgkUtuCDZRWmvCJrJ//Jn+HKZ4gEdcg6Sfab5iHt1b+j1rx7uglnq9RSkZo 610echwI+8mDgTpxDdk26kOSbbXC3qsBC2oy5getEucqqEExxABau4OKu6J0OGs+15yr +PMmO4tV2UESeQPyF9sd9BjWRm/Fgc0rn5Sn+gfG1awyJqf3GL60RkRAvgoDT4FMZ7vt h0gS0w3/81yqiMzHZJzn5UitKA6tegqh6UDU8U5GlFz8jRu2DKm2eG3lz3z208pgfC1C huOso1eRfiX232FZKybFHM+T82AeVkkmgJLdlZnTL3z/zWVlIwfYU1o+gK9HPtZONnrm nXfg== X-Gm-Message-State: ALoCoQn9oTyw9eZNYfhKT8gXkGvBETkB/4afWEm44Q5HDfOvZtcAOYOeCKXizRt3Vq9534X++61c MIME-Version: 1.0 X-Received: by 10.60.176.138 with SMTP id ci10mr5334667oec.55.1409840771105; Thu, 04 Sep 2014 07:26:11 -0700 (PDT) Received: by 10.76.110.206 with HTTP; Thu, 4 Sep 2014 07:26:10 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> Date: Thu, 4 Sep 2014 07:26:10 -0700 Message-ID: From: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/1Rgq8r4izUiFSNul3IvZ-nsvTCo Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 04 Sep 2014 14:26:13 -0000 On Thu, Sep 4, 2014 at 6:58 AM, Phillip Hallam-Baker wrote: > I don't see the issue with PFS and tickets. Tickets are a good way to > implement PFS, you just need to be careful about how you separate your > credentials. Can you explain that some more? If the credential protecting the ticket is compromised, or if the ticket encryption is cracked, then the session key is available to a MITM. That's very different from DHE, where the session key is derived from materials that never cross the wire. -- Colm From nobody Thu Sep 4 07:42:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0258E1A88F6 for ; Thu, 4 Sep 2014 07:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FAxsEtaVEoZo for ; Thu, 4 Sep 2014 07:42:24 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C17EF1A88FE for ; Thu, 4 Sep 2014 07:42:22 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id c11so3379485lbj.31 for ; Thu, 04 Sep 2014 07:42:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=7y7liqjKJAyoM43HZoudKGCMBmQLNs77o5C58h3LQmY=; b=xTUwqHDfPQer9QHdfWvRsSrVXeBpTBzkGZz2bEtRPlRqQIkcc8tGqKrKGfMl6EHMvi 3JsVQ+w4/NoSJ+RLKHzZ6GOZtZzVH8zWE+iGqjKnl5djFHFUFpZ6nOhVknff9wOoBK1I M+3aLzj4HBjuBg12/B6qh9I44C4cVFh41fJ7IAaseicU2dqgFG5pVtWgv4COZbyNb47h IIRLz7KSEuCHFA9wYJnO1FSGhI9OF2S7XNFVKcaMVpr7OaE91BkmMF57hDcPVCMWc66r OErGBTu5N/2tmf2P5isQqKxjZa58MHO+a/rO9ogMkNfAwl5cPnbKGnG3AoBGM3kY4B8/ o5zA== MIME-Version: 1.0 X-Received: by 10.152.20.71 with SMTP id l7mr470400lae.4.1409841740968; Thu, 04 Sep 2014 07:42:20 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.122.50 with HTTP; Thu, 4 Sep 2014 07:42:20 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> Date: Thu, 4 Sep 2014 10:42:20 -0400 X-Google-Sender-Auth: Ps2hSg0LmY4vCCFHTOLgDwZkiEE Message-ID: From: Phillip Hallam-Baker To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uAV-4rbQKmMj8nuBoMi-lN2IZY8 Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 04 Sep 2014 14:42:26 -0000 Meta point: Quite a few people need to STFU about what people's lives depend on. IF you have direct experience of working with dissident groups then sure, speak up. There are people who do in fact specialize in that area who attend IETF. If you don't know who they are then you almost certainly don't understand the real requirements. As a general rule, if we have a cluster of computers spread over international borders and any part of that cluster is compromised by an attacker then that attacker will always be able to perform a downgrade attack on any party they can MITM simply by directing traffic to the part of that cluster they control. On Wed, Sep 3, 2014 at 4:33 PM, Nico Williams wrote: > Session tickets are a SINE QUA NON for future deployment. +1 The argument that some people can't write code is never a good reason to cripple implementations. We don't have to do TLS 1.3. We could do TLS 2.0 instead. In fact most of the conversations suggests to me that is what we are already planning but not admitting the fact. > PFS or not is up to the client (and server). Remember, PFS is related > to the start of a session -- once you have a long-lived session, those > session keys could be stolen. If you'll allow long-lived sessions > then you might as well allow session tickets. > > (And if you want to add periodic PFS to long-lived sessions then you > need renego, no?) The way I see it, once we have a secure connection to a server we should never speak to that server en-clair ever again for any reason. > Anyways, the right thing to do is to REQUIRE frequent session ticket > encryption rotation / short ticket lifetimes. Look, session tickets > are an optimization, but a HUGE optimization at that. It's necessary. More than an optimization, they let us apply multiple layers of security which is essential if we are going to properly solve problems like leaking SNI data. One of the things that makes this discussion hard to follow is that a lot of people are conflating characteristics of particular implementations with architectural choices. We do not remove features from IETF protocols because some people don't like some implementations. We have a number of security requirements and we have tools for achieving those requirements that come with costs. Checking cert chains has a high cost Performing static key negotiation has a cost Performing ephemeral key negotiation has a cost The security requirements for session keys are essentially that people want to limit the vulnerability window in various ways, these include time and number of machines affected and data that is disclosed. Just because the SSL 1.x spec tells us that a ticket is bound to data encryption and authentication keys does not mean we have to stick with that architecture for TLS-TNG. The biggest cost in the TLS key negotiation process is that certificate chain validation thing. And that is always going to be the case because certificates are always going to have the biggest keys and there are multiple certs in a chain (minimum of one KSC these days so two signatures to validate). So using a ticket to validate an ephemeral key exchange over some fast ECC curve would make a lot of sense. From nobody Thu Sep 4 08:00:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F07471A88FD for ; Thu, 4 Sep 2014 08:00:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.978 X-Spam-Level: X-Spam-Status: No, score=-0.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4MXt3vkZP2XO for ; Thu, 4 Sep 2014 08:00:46 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B12521A88FB for ; Thu, 4 Sep 2014 08:00:45 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id 10so3023137lbg.16 for ; Thu, 04 Sep 2014 08:00:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=zJH3nMextYBuJfvQnkXI7lvNBiATYSueRGER6vrdPpE=; b=W1l++89JwnnxN1hX/AsuIxOKcCMu+RrHUzPWYq4Nm1N20BESUgeWVcuuqAe8zCx+9E kTJc7dNj0xSYvizB0h5UWkzvHeUVUT4RDhpmKkP/EK2sLssSYeCk4SGocoFMdi5mZBuc sZZFb/ks0oTZqpWYnT4KTqOfMoCyRWJlDKDI8ftOKQ4BsD78ljUrCJ25bIbCfN7YO0PL MUPWTSe4tVR69pKXEG5k+heHyIDeWRoG3pWrEd0OZ6ucq7Q+j3bWKdTKuOKecu6AfdQe 1mtM/G+ZL2V/FxMyVS2z+tiLl7IHcLbEv67xiZygRuor3w4SBlkRqVY1LaKP0qZyqrad oPjA== MIME-Version: 1.0 X-Received: by 10.152.20.71 with SMTP id l7mr581279lae.4.1409842843699; Thu, 04 Sep 2014 08:00:43 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.122.50 with HTTP; Thu, 4 Sep 2014 08:00:43 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> Date: Thu, 4 Sep 2014 11:00:43 -0400 X-Google-Sender-Auth: DL2T4YDaCmg5n2QP5KRXCAzShKQ Message-ID: From: Phillip Hallam-Baker To: =?UTF-8?Q?Colm_MacC=C3=A1rthaigh?= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/wznOiJk2jQi2uI0R0dztb3SUM0g Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 04 Sep 2014 15:00:48 -0000 On Thu, Sep 4, 2014 at 10:26 AM, Colm MacC=C3=A1rthaigh = wrote: > On Thu, Sep 4, 2014 at 6:58 AM, Phillip Hallam-Baker > wrote: >> I don't see the issue with PFS and tickets. Tickets are a good way to >> implement PFS, you just need to be careful about how you separate your >> credentials. > > Can you explain that some more? If the credential protecting the > ticket is compromised, or if the ticket encryption is cracked, then > the session key is available to a MITM. That's very different from > DHE, where the session key is derived from materials that never cross > the wire. We are talking about TLS-TNG so forget all the existing TLS baggage, in particular the notion that Tickets are only bound to data keys. The scheme I am describing is currently implemented as a Web Service security layer but it can be applied in TLS just as well. I have a key exchange service that performs a certificate chain validation, algorithm negotiation and returns an opaque ticket and a set of crypto parameters (algorithm, security policy, secret keys k_a, k_e). So one option is that we just use the keys to encrypt and authenticate the data channel. Another option is that we use the keys bound to that ticket to authenticate (and why not also encrypt) an ephemeral key exchange: Client->Server =3D X_c, MAC (X_c, k_a) Server->Client =3D X_s, MAC (X_s, k_a) Now derive new keys for use in this session: k_tm =3D H (DH_ECC (X_c, X_s), k_e) k_te =3D F1 (k_tm) k_ta=3D F2 (k_tm) [OK I am simplifying as I usually make the keys different in different directions.] Note here that the PFS key is a mix in, not a replacement. I notice a lot of designs where the output of the PFS exchange replaces the negotiation parameters completely so if there is a weak PFS scheme (e.g. a weak RNG) then the channel is compromised. This approach is a bit slower than using secret keys bound to a ticket directly on the channel. But it is a heck of a lot faster than performing a full cert chain validation and key exchange. We can also use a faster algorithm. If we are using AES 128 then there is obviously no particular need to use a curve larger than 256 bits, so we might use Curve 25519 for the PFS exchange even though the certificates are using 512 bit curves. But with the mix in approach we might still use Curve 25519 for the PFS mixin even if we were using AES 256. From nobody Thu Sep 4 08:32:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D4811A892B for ; Thu, 4 Sep 2014 08:32:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4VMY0zWjqHn for ; Thu, 4 Sep 2014 08:32:17 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF971A8905 for ; Thu, 4 Sep 2014 08:32:17 -0700 (PDT) Received: from homiemail-a106.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTP id 137262005D00A for ; Thu, 4 Sep 2014 08:32:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=v0FqIGmX/u5zdnaGY976 drrQVGk=; b=h+TDSIEBhDbMAKM0pt2FzEOgd6zWeuBfIjVNIPmO2NhL1zjTbRDx G48CUX+Fhf/pM/1yy0CU5FbSL/JZwPBLY2ZBfz41CPbWvihGmH80Y0AfkHteRI91 6G5B4b83eNsWnm5UwIQML4Q9yCgpI+Uyib7gcyOeZSKqi16F8N3lNt8= Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a106.g.dreamhost.com (Postfix) with ESMTPSA id BA9642005D008 for ; Thu, 4 Sep 2014 08:32:16 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id z2so1350929wiv.15 for ; Thu, 04 Sep 2014 08:32:15 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.13.20 with SMTP id d20mr6991547wic.28.1409844735396; Thu, 04 Sep 2014 08:32:15 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Thu, 4 Sep 2014 08:32:15 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> Date: Thu, 4 Sep 2014 10:32:15 -0500 Message-ID: From: Nico Williams To: Phillip Hallam-Baker Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/MqGvRuwlrZ27-YUmXYtegipXHs4 Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 04 Sep 2014 15:32:18 -0000 On Thu, Sep 4, 2014 at 9:42 AM, Phillip Hallam-Baker wrote: > The argument that some people can't write code is never a good reason > to cripple implementations. Indeed, and if we take it to the limit it's an argument for giving up (and certainly for abandoning TLS). From nobody Thu Sep 4 08:40:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F9C71A8905 for ; Thu, 4 Sep 2014 08:40:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFyhRuxxyQOT for ; Thu, 4 Sep 2014 08:40:14 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 1AE901A034A for ; Thu, 4 Sep 2014 08:40:14 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id EF59D438080 for ; Thu, 4 Sep 2014 08:40:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=rzD0alCAx9s6JW1mO+/6 fATjDk0=; b=EnKjufYgGillGfwNs7xtrp0dxRhbmaFgKI/G8bTP33kE5Oh/s+yq gfpvn/2zuVsmicNjo32LcP9YAjPsepxrfWeumdPJGBNLIx03ZdePfOi5ya5AsmFz jev/emD25j8LGpTjiLAd9L13GaHS5uxpP+ydtEQJ1SWc+xCJj9h7d2w= Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPSA id A29FC43806C for ; Thu, 4 Sep 2014 08:40:13 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id r20so1368141wiv.11 for ; Thu, 04 Sep 2014 08:40:12 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.77.243 with SMTP id v19mr7083262wjw.18.1409845212565; Thu, 04 Sep 2014 08:40:12 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Thu, 4 Sep 2014 08:40:12 -0700 (PDT) In-Reply-To: References: <54048985.1020005@net.in.tum.de> <3EB754B7-F6B2-4207-A2F0-E61F32EE1E40@ll.mit.edu> <54075016.6040406@net.in.tum.de> <20140903174958.GF14392@mournblade.imrryr.org> <5407574B.5060708@net.in.tum.de> <9120B6EE-F023-4724-9116-A169993F58E8@ll.mit.edu> Date: Thu, 4 Sep 2014 10:40:12 -0500 Message-ID: From: Nico Williams To: Bodo Moeller Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/iwXczMDH8Ktpvcm1OatrH5mYTiY Cc: "tls@ietf.org" Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 04 Sep 2014 15:40:14 -0000 On Thu, Sep 4, 2014 at 3:31 AM, Bodo Moeller wrote: > "Securing application-layer protocols" versus "specialized purposes" doesn't > appear to be a very useful distinction for standardization purposes > [...] +1. From nobody Thu Sep 4 08:46:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFC191A89C1 for ; Thu, 4 Sep 2014 08:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.866 X-Spam-Level: X-Spam-Status: No, score=-4.866 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jKcw_W7H9_d for ; Thu, 4 Sep 2014 08:46:16 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id B29311A897B for ; Thu, 4 Sep 2014 08:45:11 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s84FhvIf014863; Thu, 4 Sep 2014 11:44:51 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: Yutaka OIWA , Bodo Moeller Thread-Topic: [TLS] NULL cipher to become a MUST NOT in UTA BCP Thread-Index: AQHPxfjrFyzs0NTAq0uDUGuetkiK35vvfEyAgABeDoCAABYgAIAABZYAgAADAYCAAAzkgIAApYOAgABA6QCAAArXAIAAKpkA Date: Thu, 4 Sep 2014 15:43:33 +0000 Message-ID: References: <54048985.1020005@net.in.tum.de> <3EB754B7-F6B2-4207-A2F0-E61F32EE1E40@ll.mit.edu> <54075016.6040406@net.in.tum.de> <20140903174958.GF14392@mournblade.imrryr.org> <5407574B.5060708@net.in.tum.de> <9120B6EE-F023-4724-9116-A169993F58E8@ll.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [172.25.177.187] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3492675770_35237119" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.27, 0.0.0000 definitions=2014-09-04_03:2014-09-04,2014-09-04,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-1402240000 definitions=main-1409040142 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/F_ZnsJl4thY8bVF2Tr08fAGh_w8 Cc: "tls@ietf.org" Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 04 Sep 2014 15:46:19 -0000 --B_3492675770_35237119 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On 9/4/14, 5:10 , "Yutaka OIWA" wrote: >I agree, the most important point in my previous mail is whether the >document is applicable for all use cases. Tracks and WG are not >definitive regarding this. Sorry for any uncleanness. ># The intention of me to include these words was ># just to guess the document's intentions. I=E2=80=99m afraid this goal has not been achieved. >So, the most important point I think is that we have a fairly broad range >of "general use cases=E2=80=9D which need a common strong BCP for TLS >configurations. Current TLS 1.2 specification is too relaxed about this >(intentionally, to support other use cases as well). The problem is you have not defined what =E2=80=9Cuse cases=E2=80=9D your document applies, and what cases it does not. >In other words, the UTA draft is actually defining a secure restricted >subset of TLS 1.2 (and 1.3+) for some subclass of use cases, and intend >to force such restriction to "such use cases" on the Internet, using a >"MUST-NOT" requirement term. Again, the problem is the document does not define this subclass. It does some hand-waving about =E2=80=9Cgeneric=E2=80=9D, =E2=80=9Cgood for majority=E2=80=9D, etc. IMHO th= is is absolutely not acceptable. >I think it's quite important to clarify in which class of use cases UTA >is intended to apply such a restriction. Currently "general use cases" is >not well-defined and may misguide readers (including implementors) that >NULL ciphers are forbidden in ALL use cases of TLS 1.2. YES!! =E2=80=9CNot too well defined=E2=80=9D is =E2=80=9Cstating it too mildly=E2=80=9D. In fact, the way these things are currently specified in this draft - I=E2=80=99m strongly against its publication/advancement. At least until they are rectified. >2014-09-04 17:31 GMT+09:00 Bodo Moeller : >> Yutaka OIWA : >> >>> If the document were belonging to TLS WG, >>> it were on the standards track, >>> and looked like RFC 6176 (applicable for all use cases), >>> I could agree that it shall be "SHOULD NOT". >> >> >> It certainly can't matter which Working Group the document came from. >>Also, >> I don't think that issuing a BCP instead of a Proposed Standard means >>you >> can use "MUST NOT" willy-nilly. >> >> However, I think a major problem in this case it that >> draft-ietf-uta-tls-bcp-02 isn't actually clear about its intended scope: >> what does "secure use" actually mean? As pointed out before, the >>document >> uses the term "completely insecure" in a very fuzzy (and wrong) way -- >> authentication and integrity assurance without confidentiality isn't >> "completely" insecure: it obviously won't give you confidentiality, but >> still achieves other security notions. >> >> "Securing application-layer protocols" versus "specialized purposes" >>doesn't >> appear to be a very useful distinction for standardization purposes >> (*everything* that runs on top of TLS is an "application-layer >>protocol", as >> far as TLS is concerned anyway), so I essentially agree to Uri -- this >>looks >> like an attempt of ending up somewhere in between "MUST NOT" and "SHOULD >> NOT", and is not really acceptable. Also, those using integrity-only >>cipher >> suites clearly *do* want to secure their application-layer protocols, >>which >> takes us back to the problem about fuzzy "security" terminology in this >>I-D. >> >> So shouldn't the BCP document clarify its scope by being explicit that >>the >> recommendations only apply if your security goals do include >> confidentiality? In TLS 1.2, confidentiality very clearly is >> *intentionally* optional. If you create recommendations for its use and >> change this underlying assumption, you should be very clear about the >>scope >> of your recommendations. >> >> Bodo >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > > >--=20 >Yutaka OIWA, Ph.D. Leader, System Life-cycle Research >Group > Research Institute for Secure Systems >(RISEC) > National Institute of Advanced Industrial Science and Technology >(AIST) > Mail addresses: , > >OpenPGP: id[440546B5] fp[7C9F 723A 7559 3246 229D 3139 8677 9BD2 4405 >46B5] > >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls --B_3492675770_35237119 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUOAYJKoZIhvcNAQcCoIIUKTCCFCUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghIHMIIE6jCCA9KgAwIBAgIKH0XZoAAAAAABzTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE0MDQxNjIxNTMwMloXDTE1MDQxNjIxNTMwMlow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCx/gK75UYos2g8JavX0BVfe3TCGsmjQY34z9ZVeucP 8dGtqRA8T5i1OKdf++Jd81a0/qQA6mIGyzTW6lOtY+77qKUJtEeLM5URd+iv2EejAwxsa2B5 pMq9L9qWuVokR1rTEfEcuUeKR1Kko6xmRE/y6AzBnUhTvHx2X9F6JSVdR36Lx3R62CNeQqFi ZDeHuTI8AhRY4UdPkri1FTDxV6gLYaLKxsGIurrL/6EzdlkX8ImTcxKzEmxX1VjTPy9ZRNYj akDGcJF9clCfcwbq3DI3gAUkVxXf+UbHEjzOCVNQcoga7bYbBUuDpN25Lc86P9RaOiiICtyu ZZP2P/2kkKYRAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUEN9QHIi9GvlGjs9Th46jrfPir+Uw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAL2kCh9ovO8AbHgAVU6T eH5qRmKnOrfTUfn9JnHzkspdWMQA1IdtftSpiZZ7C3lCmblSDCgPqbQl4zMZxXeTgxnQsB6m 1LA6uDHM/0G27RcOJH4OTN9sQ0/2CKb4JPIXXIps1z+s8XjSRzPJZuD8fPC8R8QWvOH3owL2 BLzZebZTOMa5yws3kohY02vP/Clv0KQXYVzUZUYXoYmhUSYmQ1UZZZSFJ2rNdgNn0z8fPrUQ NIYlVaJV0kKQYjlHWTfomVapLEfIY7xRHZy9g997IjYReD0t9IZd6tTwcJES+2ijFM8l/fxk u/cQ4WCYyI+58DaBaV9p68/AC147b0HhvLUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIEzjCCA7agAwIBAgIK PVEvPAAAAACTsDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0y MB4XDTE0MDIxMjE4NTMwMVoXDTE1MDIxMjE4NTMwMVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCKHhhu75bRiOvWhbZ//TxS76yI2d+rHN2s8bp8wxW8oMjmsaplLeGQusUFRyRNSkfYtdB4 YApjnV6TCxS0Mqzly5BaoeZWoP+CbbMDNGYMszus9iFj22SSlTzGRo+gaL6rqsDKdwDOzs3C PYqh4Uu8sLzEq+QD9rhqAuMJ76635JKWELxK0uDehpNBMCGqVeAY8ht5u2h4ojPdwiuDQDW2 QxWRJjPDL8n1JczuEHY71jHldER3b2+UhpDDYRQ9aVOiGCjW8BwJOruVsBfLNxyDxgffNQ1D 1konuneMpL9H2S8ciHOdy5+Gi7snCQJ+7w30rIJ2NTldWaY6avZAaCa3AgMBAAGjggGWMIIB kjAdBgNVHQ4EFgQUZ7oGjnu6gWRmom/4UswgdVBW/3wwDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUHAQEEVjBUMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIwIwYIKwYBBQUHMAGGF2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUHBDAwLgYmKwYB BAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYE VR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAZ BgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0BAQsFAAOCAQEAJiU3WfJ9GvGJ iDNPClLazyh252wxxOc/TmClMKtyqHnbFObDEoXAMaoHGxrvs+lU8fU2F2ELpV8q8eYgqLLw 7PG09z5s/GkajlxVZ/FHj/9hNHTfwlicrCRY3zrna1GbOMZgWFz8R6akAoLKpqGulNrvjvU8 c63U+JVmgJmBPCMv5JlH10m87+WPJ+ToK0m4XfZjl7n5OKDJ/hOyBwbBntc+W2gDppfR1BCt DNfEG0+zHjFqF+Of1Q5NI5abhgvw5IEuVA1M4SV/utwmmdreBEv/YuLnDd/PhVgQwp3LHGCX X1dANyiKso2aACl9jrkylq39cA/WgvAlS21w9vxVpDGCAfUwggHxAgEBMF8wUTELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTET MBEGA1UEAxMKTUlUTEwgQ0EtMwIKH0XZoAAAAAABzTANBglghkgBZQMEAgEFAKBpMC8GCSqG SIb3DQEJBDEiBCCNw3PMsawqSecQDOKix/sAmQaOZ08JWwrqEC4A2HuTHTAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA5MDQxNTQyNTBaMA0GCSqGSIb3 DQEBAQUABIIBAKUHuCb3N5X8PpOxeWydRI1FKPTDKNcYm/dTVoVMBcKGcMWEIxXhvURPwOW5 u4BtB6o4X0bJD5qQNxXSUJGTeIU2YJvK411JCnYk9MnxXdvdmBpkFb8kkYNBESwFzeBjfD0C X1wYS1KUXBuywVX3uV0ZNmF9cGhCpjggtAXV/lWnhBkKO+3nx/CZgoRFEMbbNTpW/j86+a7r WyxaKNGGgRboJRxQ/3v5mo+ghc1YLGX1ZY5/OQ8u7oBb3XzCGXpbhfViWg61bWV4MGUyCtaR 2tvYHClSB2M4LrDHMjQ0iYjySXq0NhYTo3fYu3XNwsG3K67L+LcS/9YI7BRTZAg09vc= --B_3492675770_35237119-- From nobody Thu Sep 4 08:58:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAA741A048E for ; Thu, 4 Sep 2014 08:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.866 X-Spam-Level: X-Spam-Status: No, score=-4.866 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RG_hHucju-Dv for ; Thu, 4 Sep 2014 08:58:46 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0181A898C for ; Thu, 4 Sep 2014 08:58:37 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s84Fw6DT031746; Thu, 4 Sep 2014 11:58:35 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: "tls@ietf.org" Thread-Topic: [TLS] uta-tls-bcp-02 thoughts (was: NULL cipher to become a MUST NOT in UTA BCP) Thread-Index: AQHPyAOfhY9yOKVSV0esrbBtR0n385vxIcGA Date: Thu, 4 Sep 2014 15:57:55 +0000 Message-ID: References: <54048985.1020005@net.in.tum.de> <3EB754B7-F6B2-4207-A2F0-E61F32EE1E40@ll.mit.edu> <54075016.6040406@net.in.tum.de> <20140903174958.GF14392@mournblade.imrryr.org> <5407574B.5060708@net.in.tum.de> <9120B6EE-F023-4724-9116-A169993F58E8@ll.mit.edu> <20140904054642.GV14392@mournblade.imrryr.org> In-Reply-To: <20140904054642.GV14392@mournblade.imrryr.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [172.25.177.187] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3492676633_35324046" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.27, 0.0.0000 definitions=2014-09-04_03:2014-09-04,2014-09-04,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-1402240000 definitions=main-1409040145 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qdhyR9V1QH2T7zoQ0gN_JGF8PqY Cc: "barryleiba@computer.org" Subject: Re: [TLS] uta-tls-bcp-02 thoughts (was: NULL cipher to become a MUST NOT in UTA BCP) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 04 Sep 2014 15:58:49 -0000 --B_3492676633_35324046 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable YES to what Viktor said. And I think this draft shows systemic problems. Instead of trying (and IMHO failing) to define configurations for some questionable =E2=80=9Cbroad, generic=E2=80=9D etc., it would be FAR better to define SPECIFIC cases where your this document=E2=80=99s recommendations DO apply. IMHO this document will NOT be useful otherwise, and SHOULD NOT be published without such a change. --=20 Regards, Uri Blumenthal Voice: (781) 981-1638 On 9/4/14, 1:46 , "Viktor Dukhovni" wrote: >On Thu, Sep 04, 2014 at 01:39:15PM +0900, Yutaka OIWA wrote: > >> > What you probably want to specify here is ?SHOULD NOT?. >>=20 >> In my opinion, it shall absolutely be "MUST NOT" for >> "generic use cases" for which the document is applicable. >>=20 >> But it's UTA BCP document, and it's very important to >> say "MUST NOT for general applications" here. > >I'd like to respond to the UTA draft more broadly, please feel free >to forward or not to the UTA list (sorry, no cycles to actively >engage in yet another IETF list). > >I am perplexed by the following from the draft's introduction: > > The recommendations herein take into consideration the security of > various mechanisms, their technical maturity and interoperability, > and their prevalence in implementations at the time of writing. > These recommendations apply to both TLS and DTLS. TLS 1.3, when it > is standardized and deployed in the field, should resolve the current > vulnerabilities while providing significantly better functionality, > and will very likely obsolete this document. > >If the document provides only "general application" guidance, that >does not cover all TLS use-cases, then likely TLS 1.3 will include >features that fall outside the general use-cases, and thus the >document would continue to provide relevant general-case guidelines >even with TLS 1.3 widely deployed. > >The introduction then goes on to state: > > These are minimum recommendations for the general use of TLS. > Individual specifications may have stricter requirements related to > one or more aspects of the protocol, based on their particular > circumstances. When that is the case, implementers MUST adhere to > those stricter requirements. > >What about specifications that might call for less strict requirements? > >In section 3.5 I am puzzled by the following text: > > If TLS session resumption is used, care ought to be taken to do so > safely. In particular, the resumption information (either session > IDs [RFC5246] or session tickets [RFC5077]) MUST be authenticated and > encrypted to prevent modification or eavesdropping by an attacker. > >I am entirely unaware of the practice of encryption and authentication >of session IDs. What is this about? Even session tickets are not >"authenticated", rather they might be vended by a server as part >of an authenticated session. Returning to session IDs, these are just >server-side nonces, what does it mean that they should be authenticated, >and are they in fact (with TLS <=3D 1.2) even encrypted? > >The recommendations for session ticket key rotation are I think >too meek. They seem to be predicated on the notion that such >rotation is some sort of externally managed task, automated via >something akin to a cron job, where weekly rotation is about the >right granularity. I'd like to suggest that session ticket key >rotation SHOULD be a fully automated intrinsic component of the >server application and server keys should not last much longer than >sessions, a matter of minutes or hours not days. Key rotation >should happen transparently while the application is running, >without requiring restarts, and ideally without ever explicitly >writing keys to persistent storage. Yes, this would be an aspirational >part of the BCP, as few applications have this capability at present. > >For section 4.1, in light of the scope of section 4, the simplest >solution is to suppress NULL cipher suites when any non-NULL cipher >suites are configured. This avoids accidents, without prohibiting >deliberate NULL-only configurations. > >For SMTP, RC4-SHA and RC4-MD5 is the only cipher suites that >interoperate with Exchange 2003 servers, which are still handling >mail for a small, but non-negligible number of domains. In fact >these same servers only work if RC4 is among the first 64 cipher >suites sent by the client, but with TLS 1.2, and all its new cipher >suites that's often not the case. Are we really better off >prohibiting RC4? Would it not suffice for servers to stop preferring >RC4 (as was common with many HTTPS servers), and then stronger >choices are automatically selected except with sites that only >support RC4? > >It would be more helpful (and more interoperable) to specify a >short list of "must implement" cipher suites, which SHOULD be >preferred over the legacy ones, than to try to prohibit weaker >cipher suites that are required for interoperability with older >systems. Thus also MUST NOT or SHOULD NOT with EXPORT and 3DES >cipher suites is less useful than promoting more secure alternatives. > >The draft in fact recommends four best practice cipher suites which >should be preferred over the NOT RECOMMENDED weaker options. > >In section 6.1, the draft refers hostname verification to 6125, >but 6125 contains little useful guidance for application protocols >in which the server hostname is obtained indirectly via typically >unauthenticated DNS SRV or MX records. In such protocols, the >server name is not a viable reference identity. Some mention of >the issue may be appropriate. > > =20 >http://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-12#section-1.3.2 > >--=20 > Viktor. > >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls --B_3492676633_35324046 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUOAYJKoZIhvcNAQcCoIIUKTCCFCUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghIHMIIE6jCCA9KgAwIBAgIKH0XZoAAAAAABzTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE0MDQxNjIxNTMwMloXDTE1MDQxNjIxNTMwMlow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCx/gK75UYos2g8JavX0BVfe3TCGsmjQY34z9ZVeucP 8dGtqRA8T5i1OKdf++Jd81a0/qQA6mIGyzTW6lOtY+77qKUJtEeLM5URd+iv2EejAwxsa2B5 pMq9L9qWuVokR1rTEfEcuUeKR1Kko6xmRE/y6AzBnUhTvHx2X9F6JSVdR36Lx3R62CNeQqFi ZDeHuTI8AhRY4UdPkri1FTDxV6gLYaLKxsGIurrL/6EzdlkX8ImTcxKzEmxX1VjTPy9ZRNYj akDGcJF9clCfcwbq3DI3gAUkVxXf+UbHEjzOCVNQcoga7bYbBUuDpN25Lc86P9RaOiiICtyu ZZP2P/2kkKYRAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUEN9QHIi9GvlGjs9Th46jrfPir+Uw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAL2kCh9ovO8AbHgAVU6T eH5qRmKnOrfTUfn9JnHzkspdWMQA1IdtftSpiZZ7C3lCmblSDCgPqbQl4zMZxXeTgxnQsB6m 1LA6uDHM/0G27RcOJH4OTN9sQ0/2CKb4JPIXXIps1z+s8XjSRzPJZuD8fPC8R8QWvOH3owL2 BLzZebZTOMa5yws3kohY02vP/Clv0KQXYVzUZUYXoYmhUSYmQ1UZZZSFJ2rNdgNn0z8fPrUQ NIYlVaJV0kKQYjlHWTfomVapLEfIY7xRHZy9g997IjYReD0t9IZd6tTwcJES+2ijFM8l/fxk u/cQ4WCYyI+58DaBaV9p68/AC147b0HhvLUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIEzjCCA7agAwIBAgIK PVEvPAAAAACTsDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0y MB4XDTE0MDIxMjE4NTMwMVoXDTE1MDIxMjE4NTMwMVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCKHhhu75bRiOvWhbZ//TxS76yI2d+rHN2s8bp8wxW8oMjmsaplLeGQusUFRyRNSkfYtdB4 YApjnV6TCxS0Mqzly5BaoeZWoP+CbbMDNGYMszus9iFj22SSlTzGRo+gaL6rqsDKdwDOzs3C PYqh4Uu8sLzEq+QD9rhqAuMJ76635JKWELxK0uDehpNBMCGqVeAY8ht5u2h4ojPdwiuDQDW2 QxWRJjPDL8n1JczuEHY71jHldER3b2+UhpDDYRQ9aVOiGCjW8BwJOruVsBfLNxyDxgffNQ1D 1konuneMpL9H2S8ciHOdy5+Gi7snCQJ+7w30rIJ2NTldWaY6avZAaCa3AgMBAAGjggGWMIIB kjAdBgNVHQ4EFgQUZ7oGjnu6gWRmom/4UswgdVBW/3wwDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUHAQEEVjBUMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIwIwYIKwYBBQUHMAGGF2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUHBDAwLgYmKwYB BAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYE VR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAZ BgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0BAQsFAAOCAQEAJiU3WfJ9GvGJ iDNPClLazyh252wxxOc/TmClMKtyqHnbFObDEoXAMaoHGxrvs+lU8fU2F2ELpV8q8eYgqLLw 7PG09z5s/GkajlxVZ/FHj/9hNHTfwlicrCRY3zrna1GbOMZgWFz8R6akAoLKpqGulNrvjvU8 c63U+JVmgJmBPCMv5JlH10m87+WPJ+ToK0m4XfZjl7n5OKDJ/hOyBwbBntc+W2gDppfR1BCt DNfEG0+zHjFqF+Of1Q5NI5abhgvw5IEuVA1M4SV/utwmmdreBEv/YuLnDd/PhVgQwp3LHGCX X1dANyiKso2aACl9jrkylq39cA/WgvAlS21w9vxVpDGCAfUwggHxAgEBMF8wUTELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTET MBEGA1UEAxMKTUlUTEwgQ0EtMwIKH0XZoAAAAAABzTANBglghkgBZQMEAgEFAKBpMC8GCSqG SIb3DQEJBDEiBCAgL9gimhke52BC1juxuxviJQfhAOubsLweFmsYT3MjfTAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA5MDQxNTU3MTNaMA0GCSqGSIb3 DQEBAQUABIIBAK5Jjxi8IiLnn8hcgA3gK4zh5L7AX+zbpqXHPPHr3FLpa0pTmvImgsXSYRVK A+btzjbfsu4hvHczkvWayYPg+Zwkxs051YLOUmRf2/FAgWNotcGGzYkT/j8qMDziR0harWYw jgMtcYC5+z5KuCflT2VECeOkBTqMMh6nwFHqaknfmKKvXQJdUW5n2SQ2xR3zLFzS6cy7TuBa zww+Fbobxp/KNEiWxyaggMBIzMo/uSkCHOB1XkWrQotDQQYgqA+C1RAbclglnXYpQ26pN+qQ WQFIEFy0VXkqppealOvqN+2Klq5u+IHSwD5ior0PkjiQiWku+AtA7mjMWRW5wXOzVzU= --B_3492676633_35324046-- From nobody Thu Sep 4 09:09:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACE3B1A03ED for ; Thu, 4 Sep 2014 09:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bifTaKnWqzLv for ; Thu, 4 Sep 2014 09:09:26 -0700 (PDT) Received: from homiemail-a112.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 13D701A0380 for ; Thu, 4 Sep 2014 09:09:26 -0700 (PDT) Received: from homiemail-a112.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a112.g.dreamhost.com (Postfix) with ESMTP id D206B20078714 for ; Thu, 4 Sep 2014 09:09:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=p/Fnd9OD6qzCxHKdWh+bSPMv1AQ=; b=USNWqur4BdR SvBiRBfrqzWerkMAEA8znI83bP0+Ak634xz/BKDvQVCAFSM8oMrjvx93q1xGt7R5 mG3ibmfiWk/Fj+CjB94SVEDFJRg1joTDdvH/YtYAPkdeSzxVcRJEkTpBQuLjbA2P U6hyO8KIm5sBJBRnDnBAEfvlcL8sI5Cs= Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a112.g.dreamhost.com (Postfix) with ESMTPSA id 870202007871B for ; Thu, 4 Sep 2014 09:09:25 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id l18so10209281wgh.34 for ; Thu, 04 Sep 2014 09:09:22 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.180.208.111 with SMTP id md15mr6821324wic.3.1409846962638; Thu, 04 Sep 2014 09:09:22 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Thu, 4 Sep 2014 09:09:22 -0700 (PDT) In-Reply-To: References: <54048985.1020005@net.in.tum.de> <3EB754B7-F6B2-4207-A2F0-E61F32EE1E40@ll.mit.edu> <54075016.6040406@net.in.tum.de> <20140903174958.GF14392@mournblade.imrryr.org> <5407574B.5060708@net.in.tum.de> <9120B6EE-F023-4724-9116-A169993F58E8@ll.mit.edu> <20140904054642.GV14392@mournblade.imrryr.org> Date: Thu, 4 Sep 2014 11:09:22 -0500 Message-ID: From: Nico Williams To: "Blumenthal, Uri - 0558 - MITLL" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2-7_uhzltWOLcWv7CgdF7T01QLM Cc: "barryleiba@computer.org" , "tls@ietf.org" Subject: Re: [TLS] uta-tls-bcp-02 thoughts (was: NULL cipher to become a MUST NOT in UTA BCP) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 04 Sep 2014 16:09:26 -0000 On Thu, Sep 4, 2014 at 10:57 AM, Blumenthal, Uri - 0558 - MITLL wrote: > YES to what Viktor said. > > And I think this draft shows systemic problems. Instead of trying (and > IMHO failing) to define configurations for some questionable =E2=80=9Cbro= ad, > generic=E2=80=9D etc., it would be FAR better to define SPECIFIC cases wh= ere your > this document=E2=80=99s recommendations DO apply. Or make the advice useful enough for all cases. For example, Viktor's proposal as to when NULL ciphers should be allowed is quite sensible. Nico -- From nobody Thu Sep 4 09:24:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4711A03CB for ; Thu, 4 Sep 2014 09:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.866 X-Spam-Level: X-Spam-Status: No, score=-4.866 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8UskQGSEQVfr for ; Thu, 4 Sep 2014 09:24:43 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 8390B1A0305 for ; Thu, 4 Sep 2014 09:24:42 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s84GOcBH032306; Thu, 4 Sep 2014 12:24:39 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: Nico Williams Thread-Topic: [TLS] uta-tls-bcp-02 thoughts (was: NULL cipher to become a MUST NOT in UTA BCP) Thread-Index: AQHPyAOfhY9yOKVSV0esrbBtR0n385vxIcGAgABGcwD//8CdAA== Date: Thu, 4 Sep 2014 16:23:14 +0000 Message-ID: References: <54048985.1020005@net.in.tum.de> <3EB754B7-F6B2-4207-A2F0-E61F32EE1E40@ll.mit.edu> <54075016.6040406@net.in.tum.de> <20140903174958.GF14392@mournblade.imrryr.org> <5407574B.5060708@net.in.tum.de> <9120B6EE-F023-4724-9116-A169993F58E8@ll.mit.edu> <20140904054642.GV14392@mournblade.imrryr.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [172.25.177.187] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3492678150_35385043" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.27, 0.0.0000 definitions=2014-09-04_03:2014-09-04,2014-09-04,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-1402240000 definitions=main-1409040151 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UgOthC6pU2_RO9f7ILHBPMIejuc Cc: "tls@ietf.org" Subject: Re: [TLS] uta-tls-bcp-02 thoughts (was: NULL cipher to become a MUST NOT in UTA BCP) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 04 Sep 2014 16:24:45 -0000 --B_3492678150_35385043 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On 9/4/14, 12:09 , "Nico Williams" wrote: >On Thu, Sep 4, 2014 at 10:57 AM wrote: >> YES to what Viktor said. >> >> And I think this draft shows systemic problems. Instead of trying (and >> IMHO failing) to define configurations for some questionable =E2=80=9Cbroad, >> generic=E2=80=9D etc., it would be FAR better to define SPECIFIC cases where >>your >> this document=E2=80=99s recommendations DO apply. > >Or make the advice useful enough for all cases. For example, Viktor's >proposal as to when NULL ciphers should be allowed is quite sensible. Yes. But the tone of the discussion that=E2=80=99s been going on so far makes me fairly certain that it is impossible to get the authors to agree to make this document useful for all cases. Which is why I hope instead that the WG can convince them to define what [sub]classes or what *specific* use cases their recommendations do apply. IMHO, in any case (no pun intended :) it is {much better & much safer & technically more appropriate} to define what conditions something applies to/can be used in, rather than trying to define all the exceptions. --B_3492678150_35385043 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUOAYJKoZIhvcNAQcCoIIUKTCCFCUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghIHMIIE6jCCA9KgAwIBAgIKH0XZoAAAAAABzTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE0MDQxNjIxNTMwMloXDTE1MDQxNjIxNTMwMlow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCx/gK75UYos2g8JavX0BVfe3TCGsmjQY34z9ZVeucP 8dGtqRA8T5i1OKdf++Jd81a0/qQA6mIGyzTW6lOtY+77qKUJtEeLM5URd+iv2EejAwxsa2B5 pMq9L9qWuVokR1rTEfEcuUeKR1Kko6xmRE/y6AzBnUhTvHx2X9F6JSVdR36Lx3R62CNeQqFi ZDeHuTI8AhRY4UdPkri1FTDxV6gLYaLKxsGIurrL/6EzdlkX8ImTcxKzEmxX1VjTPy9ZRNYj akDGcJF9clCfcwbq3DI3gAUkVxXf+UbHEjzOCVNQcoga7bYbBUuDpN25Lc86P9RaOiiICtyu ZZP2P/2kkKYRAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUEN9QHIi9GvlGjs9Th46jrfPir+Uw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAL2kCh9ovO8AbHgAVU6T eH5qRmKnOrfTUfn9JnHzkspdWMQA1IdtftSpiZZ7C3lCmblSDCgPqbQl4zMZxXeTgxnQsB6m 1LA6uDHM/0G27RcOJH4OTN9sQ0/2CKb4JPIXXIps1z+s8XjSRzPJZuD8fPC8R8QWvOH3owL2 BLzZebZTOMa5yws3kohY02vP/Clv0KQXYVzUZUYXoYmhUSYmQ1UZZZSFJ2rNdgNn0z8fPrUQ NIYlVaJV0kKQYjlHWTfomVapLEfIY7xRHZy9g997IjYReD0t9IZd6tTwcJES+2ijFM8l/fxk u/cQ4WCYyI+58DaBaV9p68/AC147b0HhvLUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIEzjCCA7agAwIBAgIK PVEvPAAAAACTsDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0y MB4XDTE0MDIxMjE4NTMwMVoXDTE1MDIxMjE4NTMwMVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCKHhhu75bRiOvWhbZ//TxS76yI2d+rHN2s8bp8wxW8oMjmsaplLeGQusUFRyRNSkfYtdB4 YApjnV6TCxS0Mqzly5BaoeZWoP+CbbMDNGYMszus9iFj22SSlTzGRo+gaL6rqsDKdwDOzs3C PYqh4Uu8sLzEq+QD9rhqAuMJ76635JKWELxK0uDehpNBMCGqVeAY8ht5u2h4ojPdwiuDQDW2 QxWRJjPDL8n1JczuEHY71jHldER3b2+UhpDDYRQ9aVOiGCjW8BwJOruVsBfLNxyDxgffNQ1D 1konuneMpL9H2S8ciHOdy5+Gi7snCQJ+7w30rIJ2NTldWaY6avZAaCa3AgMBAAGjggGWMIIB kjAdBgNVHQ4EFgQUZ7oGjnu6gWRmom/4UswgdVBW/3wwDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUHAQEEVjBUMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIwIwYIKwYBBQUHMAGGF2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUHBDAwLgYmKwYB BAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYE VR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAZ BgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0BAQsFAAOCAQEAJiU3WfJ9GvGJ iDNPClLazyh252wxxOc/TmClMKtyqHnbFObDEoXAMaoHGxrvs+lU8fU2F2ELpV8q8eYgqLLw 7PG09z5s/GkajlxVZ/FHj/9hNHTfwlicrCRY3zrna1GbOMZgWFz8R6akAoLKpqGulNrvjvU8 c63U+JVmgJmBPCMv5JlH10m87+WPJ+ToK0m4XfZjl7n5OKDJ/hOyBwbBntc+W2gDppfR1BCt DNfEG0+zHjFqF+Of1Q5NI5abhgvw5IEuVA1M4SV/utwmmdreBEv/YuLnDd/PhVgQwp3LHGCX X1dANyiKso2aACl9jrkylq39cA/WgvAlS21w9vxVpDGCAfUwggHxAgEBMF8wUTELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTET MBEGA1UEAxMKTUlUTEwgQ0EtMwIKH0XZoAAAAAABzTANBglghkgBZQMEAgEFAKBpMC8GCSqG SIb3DQEJBDEiBCBv4JIJ2NRfKZFVrOWTerlXg9MDHJqkx6xy/FIFVhVrJDAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA5MDQxNjIyMzBaMA0GCSqGSIb3 DQEBAQUABIIBACnS5UdQP4AW1W6DcfFamjOZYFvbntfFUoU6jHq6ECRlN54x6ZQT3AixccP7 wnt8+1jHEZENyqw9ssE3nzYy9IgCk6R29BQQLa4TcuE1VBqOdQ6HDr3wtOe+O9me2Q8aY8oy 2+W/eHD3i+vupg/FFQPXHGT6E72NyFHL8w8B/l7VK/iO6Dgm9EtynVYnMd0COpvnhd4lVICs KolXyuNgqGSUAkaTh0YgOivMngkB48bUUXbb+VwyXVVuFjiWdj4JdaRPXB8SRkbDJn0O/MgU TJsR8B24e9bSQJQdGk9Y0KAeuwWJVdhtW4Tn5QO5OW4+ZoHEsczNoQOEnIz09Cl2WVo= --B_3492678150_35385043-- From nobody Thu Sep 4 10:43:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BA5D1A00F5 for ; Thu, 4 Sep 2014 10:43:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xExAVxtc7iHT for ; Thu, 4 Sep 2014 10:42:58 -0700 (PDT) Received: from smtp.serverkommune.de (serverkommune.de [176.9.61.43]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FBEA1A00E0 for ; Thu, 4 Sep 2014 10:42:57 -0700 (PDT) Received: by smtp.serverkommune.de (Postfix, from userid 5001) id 739C08053C; Thu, 4 Sep 2014 19:42:55 +0200 (CEST) Received: from [131.159.20.131] (ex6.serverkommune.de [176.9.61.43]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.serverkommune.de (Postfix) with ESMTPSA id BC87080060; Thu, 4 Sep 2014 19:42:52 +0200 (CEST) Message-ID: <5408A49C.6070801@net.in.tum.de> Date: Thu, 04 Sep 2014 19:42:52 +0200 From: Ralph Holz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: "Blumenthal, Uri - 0558 - MITLL" , Nico Williams References: <54048985.1020005@net.in.tum.de> <3EB754B7-F6B2-4207-A2F0-E61F32EE1E40@ll.mit.edu> <54075016.6040406@net.in.tum.de> <20140903174958.GF14392@mournblade.imrryr.org> <5407574B.5060708@net.in.tum.de> <9120B6EE-F023-4724-9116-A169993F58E8@ll.mit.edu> <20140904054642.GV14392@mournblade.imrryr.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.98.1 at ex6 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/tls/k4XUL0eIp6QOJHza18-TaIpb-cs Cc: "tls@ietf.org" Subject: Re: [TLS] uta-tls-bcp-02 thoughts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 04 Sep 2014 17:43:00 -0000 >> Or make the advice useful enough for all cases. For example, Viktor's >> proposal as to when NULL ciphers should be allowed is quite sensible. > > Yes. But the tone of the discussion thats been going on so far makes me > fairly certain that it is impossible to get the authors to agree to make > this document useful for all cases. I think that would be a most unfruitful endeavour as the resulting document would benefit no-one. There is always a use case that requires the lowest possible security settings. > Which is why I hope instead that the WG can convince them to define what > [sub]classes or what *specific* use cases their recommendations do apply. I would support such a clarification and will talk to the other authors. Ralph -- Ralph Holz I8 - Network Architectures and Services Technische Universitt Mnchen http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18043 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF From nobody Thu Sep 4 10:50:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 821A71A0113 for ; Thu, 4 Sep 2014 10:50:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.866 X-Spam-Level: X-Spam-Status: No, score=-4.866 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XAZO96PUWaiN for ; Thu, 4 Sep 2014 10:50:28 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 6FA321A010A for ; Thu, 4 Sep 2014 10:50:28 -0700 (PDT) Received: from LLE2K10-HUB02.mitll.ad.local (LLE2K10-HUB02.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s84HoNXx020614; Thu, 4 Sep 2014 13:50:24 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: Ralph Holz , Nico Williams Thread-Topic: [TLS] uta-tls-bcp-02 thoughts Thread-Index: AQHPyGesl7HEQ8AMHEieovTIuGxju5vxQEAA Date: Thu, 4 Sep 2014 17:49:55 +0000 Message-ID: References: <54048985.1020005@net.in.tum.de> <3EB754B7-F6B2-4207-A2F0-E61F32EE1E40@ll.mit.edu> <54075016.6040406@net.in.tum.de> <20140903174958.GF14392@mournblade.imrryr.org> <5407574B.5060708@net.in.tum.de> <9120B6EE-F023-4724-9116-A169993F58E8@ll.mit.edu> <20140904054642.GV14392@mournblade.imrryr.org> <5408A49C.6070801@net.in.tum.de> In-Reply-To: <5408A49C.6070801@net.in.tum.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.3.140616 x-originating-ip: [172.25.177.187] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3492683350_35711157" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.27, 0.0.0000 definitions=2014-09-04_03:2014-09-04,2014-09-04,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-1402240000 definitions=main-1409040161 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Pf8bhuPTxEdndqJk0g_X8IT_nkg Cc: "tls@ietf.org" Subject: Re: [TLS] uta-tls-bcp-02 thoughts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 04 Sep 2014 17:50:30 -0000 --B_3492683350_35711157 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On 9/4/14, 13:42 , "Ralph Holz" wrote: >>> Or make the advice useful enough for all cases. For example, Viktor's >>> proposal as to when NULL ciphers should be allowed is quite sensible. >>=20 >> Yes. But the tone of the discussion that=E2=80=99s been going on so far makes = me >> fairly certain that it is impossible to get the authors to agree to make >> this document useful for all cases. > >I think that would be a most unfruitful endeavour as the resulting >document would benefit no-one. There is always a use case that requires >the lowest possible security settings. The problem is not =E2=80=9Clowest security settings=E2=80=9D, but lack of stringent definition what EACH (not just the lowest) described setting is good for, what it protects against, and when it should AND SHOULD NOT be used. This is exactly what the current draft is missing. >>Which is why I hope instead that the WG can convince them to define what >> [sub]classes or what *specific* use cases their recommendations do >>apply. > >I would support such a clarification and will talk to the other authors. Needless to say, I would support it too. P.S. I wouldn=E2=80=99t call it =E2=80=9Cclarification=E2=80=9D - you cannot clarify what has= n=E2=80=99t been defined at all yet. :-) --B_3492683350_35711157 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUOAYJKoZIhvcNAQcCoIIUKTCCFCUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghIHMIIE6jCCA9KgAwIBAgIKH0XZoAAAAAABzTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE0MDQxNjIxNTMwMloXDTE1MDQxNjIxNTMwMlow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCx/gK75UYos2g8JavX0BVfe3TCGsmjQY34z9ZVeucP 8dGtqRA8T5i1OKdf++Jd81a0/qQA6mIGyzTW6lOtY+77qKUJtEeLM5URd+iv2EejAwxsa2B5 pMq9L9qWuVokR1rTEfEcuUeKR1Kko6xmRE/y6AzBnUhTvHx2X9F6JSVdR36Lx3R62CNeQqFi ZDeHuTI8AhRY4UdPkri1FTDxV6gLYaLKxsGIurrL/6EzdlkX8ImTcxKzEmxX1VjTPy9ZRNYj akDGcJF9clCfcwbq3DI3gAUkVxXf+UbHEjzOCVNQcoga7bYbBUuDpN25Lc86P9RaOiiICtyu ZZP2P/2kkKYRAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUEN9QHIi9GvlGjs9Th46jrfPir+Uw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAL2kCh9ovO8AbHgAVU6T eH5qRmKnOrfTUfn9JnHzkspdWMQA1IdtftSpiZZ7C3lCmblSDCgPqbQl4zMZxXeTgxnQsB6m 1LA6uDHM/0G27RcOJH4OTN9sQ0/2CKb4JPIXXIps1z+s8XjSRzPJZuD8fPC8R8QWvOH3owL2 BLzZebZTOMa5yws3kohY02vP/Clv0KQXYVzUZUYXoYmhUSYmQ1UZZZSFJ2rNdgNn0z8fPrUQ NIYlVaJV0kKQYjlHWTfomVapLEfIY7xRHZy9g997IjYReD0t9IZd6tTwcJES+2ijFM8l/fxk u/cQ4WCYyI+58DaBaV9p68/AC147b0HhvLUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIEzjCCA7agAwIBAgIK PVEvPAAAAACTsDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0y MB4XDTE0MDIxMjE4NTMwMVoXDTE1MDIxMjE4NTMwMVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCKHhhu75bRiOvWhbZ//TxS76yI2d+rHN2s8bp8wxW8oMjmsaplLeGQusUFRyRNSkfYtdB4 YApjnV6TCxS0Mqzly5BaoeZWoP+CbbMDNGYMszus9iFj22SSlTzGRo+gaL6rqsDKdwDOzs3C PYqh4Uu8sLzEq+QD9rhqAuMJ76635JKWELxK0uDehpNBMCGqVeAY8ht5u2h4ojPdwiuDQDW2 QxWRJjPDL8n1JczuEHY71jHldER3b2+UhpDDYRQ9aVOiGCjW8BwJOruVsBfLNxyDxgffNQ1D 1konuneMpL9H2S8ciHOdy5+Gi7snCQJ+7w30rIJ2NTldWaY6avZAaCa3AgMBAAGjggGWMIIB kjAdBgNVHQ4EFgQUZ7oGjnu6gWRmom/4UswgdVBW/3wwDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUHAQEEVjBUMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIwIwYIKwYBBQUHMAGGF2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUHBDAwLgYmKwYB BAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYE VR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAZ BgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0BAQsFAAOCAQEAJiU3WfJ9GvGJ iDNPClLazyh252wxxOc/TmClMKtyqHnbFObDEoXAMaoHGxrvs+lU8fU2F2ELpV8q8eYgqLLw 7PG09z5s/GkajlxVZ/FHj/9hNHTfwlicrCRY3zrna1GbOMZgWFz8R6akAoLKpqGulNrvjvU8 c63U+JVmgJmBPCMv5JlH10m87+WPJ+ToK0m4XfZjl7n5OKDJ/hOyBwbBntc+W2gDppfR1BCt DNfEG0+zHjFqF+Of1Q5NI5abhgvw5IEuVA1M4SV/utwmmdreBEv/YuLnDd/PhVgQwp3LHGCX X1dANyiKso2aACl9jrkylq39cA/WgvAlS21w9vxVpDGCAfUwggHxAgEBMF8wUTELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTET MBEGA1UEAxMKTUlUTEwgQ0EtMwIKH0XZoAAAAAABzTANBglghkgBZQMEAgEFAKBpMC8GCSqG SIb3DQEJBDEiBCDMei1FVyLKGj0ufT4pwqz3TR8i6s7oWe+ioL7HI3VFGzAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA5MDQxNzQ5MTBaMA0GCSqGSIb3 DQEBAQUABIIBAEOFaLxhM6z7JYH7Rh8EhIQMHGYKuqu2zoJUAyknLZIkh0D9n3eJChgYxf8o eHFHxqezw/IXpMjadTuOlufQtuhATm7yEUzCw9z+C0JZQ1x4OTFnBXyBdOuR5LLGqnRi6+jW 0rrIVSLkQGCR2DQIkxSCpAbie+JbNN/Ld3K1liENddTsfmcdF9+4hpWIsuMnbeFto2v4Ibol 2XJkmAbPwMkGTmUlSY6r4TO8QT8b60hsUbUnzpT3OQOL4QaqPGp6emyg7RV3WHFa8jH0EWM1 M+yyMKQlYaa2BbRSOXqjPjMAe+/jA4BwjqXWHb9+2D7lCuikuQk/P2WJGoz/SyXzmVc= --B_3492683350_35711157-- From nobody Thu Sep 4 10:53:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8451A0190 for ; Thu, 4 Sep 2014 10:53:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nYyN8pLKX9z1 for ; Thu, 4 Sep 2014 10:53:13 -0700 (PDT) Received: from smtp.serverkommune.de (serverkommune.de [176.9.61.43]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 859831A0171 for ; Thu, 4 Sep 2014 10:53:13 -0700 (PDT) Received: by smtp.serverkommune.de (Postfix, from userid 5001) id 2BD8080770; Thu, 4 Sep 2014 19:53:12 +0200 (CEST) Received: from [131.159.20.131] (ex6.serverkommune.de [176.9.61.43]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.serverkommune.de (Postfix) with ESMTPSA id E817E80041; Thu, 4 Sep 2014 19:53:09 +0200 (CEST) Message-ID: <5408A705.3060603@net.in.tum.de> Date: Thu, 04 Sep 2014 19:53:09 +0200 From: Ralph Holz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: "Blumenthal, Uri - 0558 - MITLL" , Nico Williams References: <54048985.1020005@net.in.tum.de> <3EB754B7-F6B2-4207-A2F0-E61F32EE1E40@ll.mit.edu> <54075016.6040406@net.in.tum.de> <20140903174958.GF14392@mournblade.imrryr.org> <5407574B.5060708@net.in.tum.de> <9120B6EE-F023-4724-9116-A169993F58E8@ll.mit.edu> <20140904054642.GV14392@mournblade.imrryr.org> <5408A49C.6070801@net.in.tum.de> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.98.1 at ex6 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-lybQmxqY04JrkN8601tdYw6dK0 Cc: "tls@ietf.org" Subject: Re: [TLS] uta-tls-bcp-02 thoughts X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 04 Sep 2014 17:53:15 -0000 Hi, >> I think that would be a most unfruitful endeavour as the resulting >> document would benefit no-one. There is always a use case that requires >> the lowest possible security settings. > > The problem is not “lowest security settings”, but lack of stringent > definition what EACH (not just the lowest) described setting is good for, > what it protects against, and when it should AND SHOULD NOT be used. This > is exactly what the current draft is missing. Do you mean a general discussion in a new half-page/one-page section by that? Ralph -- Ralph Holz I8 - Network Architectures and Services Technische Universität München http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18043 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF From nobody Thu Sep 4 11:12:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0709E1A0021 for ; Thu, 4 Sep 2014 11:12:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5XUAIoWGCU3 for ; Thu, 4 Sep 2014 11:12:36 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CCDA1A00CA for ; Thu, 4 Sep 2014 11:12:21 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id mc6so12345044lab.37 for ; Thu, 04 Sep 2014 11:12:20 -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=s5HKmGK3JYBbc1dsoDZ2syD75WmebkdHRVYVwrCVuB8=; b=iB2RY8j4M0yX1WomwgdJQTCDQbKbPZ6X2YYJqu55tK/32+RBa9fqZG2t1eyOwbPuSo Oa0j5H78AuhWxY4hoJZSMtE9+GalwL/olKL5XD9E3v1d/i0Na4QlxUfZRp1+Dh/2ArsM kCN10p/fqz/f33S1ihtBEK4hTPpAl6rUh04KLlo0iFatl5r3QeE8eoQ/YgfplqA7KpM/ +8EEHdl12OP0lmmPy9Mwo8VLAOgp4bdxDmQT31oVJP00a+MV03Xqz3bdlDMgSagJra6B p5IiBCMB3suFX8cxwplFaMyya9EDJ+OdudkfF7Ovr8SRbFPSxHRTEIWWRqqUUr9l0U6e umww== MIME-Version: 1.0 X-Received: by 10.112.199.161 with SMTP id jl1mr5788217lbc.59.1409854339130; Thu, 04 Sep 2014 11:12:19 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Thu, 4 Sep 2014 11:12:19 -0700 (PDT) In-Reply-To: References: Date: Thu, 4 Sep 2014 11:12:19 -0700 Message-ID: From: Martin Thomson To: Brian Sniffen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xMJJlqNFIUnMBJE9H5vRTOxl5yA Cc: "tls@ietf.org" Subject: Re: [TLS] Ticket caching (was Re: tickets or sesssions or both (oh my)) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 04 Sep 2014 18:12:39 -0000 On 3 September 2014 19:03, Brian Sniffen wrote: > Does it matter that a browser will retain tickets, which identify > conversational partners, for a while---and even if the browser cache, > DNS cache, cookie store, etc., are cleared? Yes, it can (and does) matter. But I'm also interested in making progress on one thing at a time ;) From nobody Thu Sep 4 11:20:44 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CC91A024C for ; Thu, 4 Sep 2014 11:20:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4KLsnV9l73b for ; Thu, 4 Sep 2014 11:20:39 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFB071A023F for ; Thu, 4 Sep 2014 11:20:38 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id gi9so801101lab.24 for ; Thu, 04 Sep 2014 11:20:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=zdgU9DZa2bIxAcngkzCan6Yo6Ie8pDL1B3d6BfV+8Z4=; b=j6DadW1CuXzmqlGyqjTD3cv98NRsOmGj5XjskLqRwdc5i8v7BReKjGRQfswfRnkP5+ 6LXHCEcdSrkLJ/QQiJWsWJAVoouBR63Ihcm3N+wZEpsy2H9VMRRB+5fLXEgKrQjSv4Hx Hg2XfHKS3no/qokucF5h2ermkuOKinJDAwCTzP34bM7YKWhKR9Amd8n2B5x4eaGpVya1 5mD6BhrB7Gb2ZqzBxHc4sOno6D+Yx3+PfiaH3j4HNbocS/t+lblPC4Qm9F7Qox8f6gGo /rp8tu1npt3JSEZLHwldtS49ihP5GtLzeQuRFlqIbpe/huSVBY2k99pmWKIpdPY3YYYu qhNA== MIME-Version: 1.0 X-Received: by 10.112.8.99 with SMTP id q3mr6058531lba.85.1409854837010; Thu, 04 Sep 2014 11:20:37 -0700 (PDT) Sender: barryleiba@gmail.com Received: by 10.152.1.106 with HTTP; Thu, 4 Sep 2014 11:20:36 -0700 (PDT) In-Reply-To: References: <54048985.1020005@net.in.tum.de> <3EB754B7-F6B2-4207-A2F0-E61F32EE1E40@ll.mit.edu> <54075016.6040406@net.in.tum.de> <20140903174958.GF14392@mournblade.imrryr.org> <5407574B.5060708@net.in.tum.de> <9120B6EE-F023-4724-9116-A169993F58E8@ll.mit.edu> <20140904054642.GV14392@mournblade.imrryr.org> Date: Thu, 4 Sep 2014 21:20:36 +0300 X-Google-Sender-Auth: _Lnv3tXBn7VeI5C7cw8jzZ5gf2s Message-ID: From: Barry Leiba To: Nico Williams Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BMZFcC37ahbKXngsDOnU16i3VRc Cc: "tls@ietf.org" Subject: Re: [TLS] uta-tls-bcp-02 thoughts (was: NULL cipher to become a MUST NOT in UTA BCP) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 04 Sep 2014 18:20:40 -0000 (1) Why are these messages not on the UTA list? I strongly suggest that they be repeated there. (2) Uri, why did you specifically send this to me? Barry On Thu, Sep 4, 2014 at 7:09 PM, Nico Williams wrote: > On Thu, Sep 4, 2014 at 10:57 AM, Blumenthal, Uri - 0558 - MITLL > wrote: >> YES to what Viktor said. >> >> And I think this draft shows systemic problems. Instead of trying (and >> IMHO failing) to define configurations for some questionable "broad, >> generic" etc., it would be FAR better to define SPECIFIC cases where your >> this document's recommendations DO apply. > > Or make the advice useful enough for all cases. For example, Viktor's > proposal as to when NULL ciphers should be allowed is quite sensible. > > Nico > -- From nobody Thu Sep 4 12:22:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F68C1A03F4; Thu, 4 Sep 2014 12:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xPS6GJEhYDQC; Thu, 4 Sep 2014 12:22:21 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 035991A03F2; Thu, 4 Sep 2014 12:22:21 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: IETF Announcement List X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140904192221.9668.41197.idtracker@ietfa.amsl.com> Date: Thu, 04 Sep 2014 12:22:21 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IPrzHz8is-Tf8PtXTkg_TWNNaqs Cc: tls@ietf.org Subject: [TLS] TLS WG Interim Meeting, 21-22 October 2014 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 04 Sep 2014 19:22:22 -0000 The TLS working group will hold a face-to-face interim in Paris, France on 21-22 October 2014. Date: 21-22 October 2014 Time: 9am-5pm Location: INRIA 23 Avenue d'Italie, 75013 Paris, France Wiki: https://wiki.inria.fr/prosecco/IETF_TLS_Interim_October_2014 Additional information will be announced on the TLS WG mailing list: http://www.ietf.org/mail-archive/web/tls/current/maillist.html From nobody Thu Sep 4 14:41:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00C401A02A0 for ; Thu, 4 Sep 2014 14:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.807 X-Spam-Level: ** X-Spam-Status: No, score=2.807 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FSL_HELO_BARE_IP_2=1.674, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6-UDJcs2ezK5 for ; Thu, 4 Sep 2014 14:41:05 -0700 (PDT) Received: from gateway15.websitewelcome.com (gateway15.websitewelcome.com [69.41.255.11]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56A3C1A028A for ; Thu, 4 Sep 2014 14:41:05 -0700 (PDT) Received: by gateway15.websitewelcome.com (Postfix, from userid 5007) id 263F54991E613; Thu, 4 Sep 2014 16:41:04 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway15.websitewelcome.com (Postfix) with ESMTP id 14D284991E5F2 for ; Thu, 4 Sep 2014 16:41:04 -0500 (CDT) Received: from [96.231.227.95] (port=62498 helo=192.168.1.6) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XPem7-00043r-IZ for tls@ietf.org; Thu, 04 Sep 2014 16:41:03 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <20140904192221.9668.41197.idtracker@ietfa.amsl.com> Date: Thu, 4 Sep 2014 17:40:58 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140904192221.9668.41197.idtracker@ietfa.amsl.com> To: "TLS@ietf.org (tls@ietf.org)" X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.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-IP: 96.231.227.95 X-Exim-ID: 1XPem7-00043r-IZ X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.6) [96.231.227.95]:62498 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 3 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0GEg4laK9AXwx5IOr9YyDHuhxU0 Subject: Re: [TLS] TLS WG Interim Meeting, 21-22 October 2014 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 04 Sep 2014 21:41:07 -0000 On Sep 04, 2014, at 15:22, IESG Secretary = wrote: > The TLS working group will hold a face-to-face interim in Paris, = France=20 > on 21-22 October 2014. >=20 > Date: 21-22 October 2014 > Time: 9am-5pm > Location: INRIA > 23 Avenue d'Italie, > 75013 Paris, > France > Wiki: https://wiki.inria.fr/prosecco/IETF_TLS_Interim_October_2014 >=20 > Additional information will be announced on the TLS WG mailing list: > http://www.ietf.org/mail-archive/web/tls/current/maillist.html >=20 Some additional information: Registration: If you did not fill out the doodle poll please send the = TLS chairs an email at tls-chairs@tools.ietf.org. If you did fill out = the doodle poll and are not planning to attend please send the TLS = chairs an email letting us know. We need a list of attendees for admin = reasons. Remote Participation: (tentatively) via Webex Lodging: Individual responsibility, but we=92re working on getting a = list of hotels nearby to INRIA. spt= From nobody Thu Sep 4 18:50:44 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9BD61A02FE for ; Thu, 4 Sep 2014 18:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.266 X-Spam-Level: X-Spam-Status: No, score=-0.266 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OR6GCBj1JdQJ for ; Thu, 4 Sep 2014 18:50:43 -0700 (PDT) Received: from homiemail-a67.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id F16441A02F8 for ; Thu, 4 Sep 2014 18:50:42 -0700 (PDT) Received: from homiemail-a67.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTP id 6F6CB27BC073; Thu, 4 Sep 2014 18:50:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sleevi.com; h=message-id :in-reply-to:references:date:subject:from:to:cc:reply-to :mime-version:content-type:content-transfer-encoding; s= sleevi.com; bh=4hlqu24bFPsyts4Zs7O3RWIqObg=; b=JfhaxKLOB8r4AZT3f RWOh1j0qooVYHOmc3LCNq5dk9kGHI7ZeztStVkGwICsoSRINVvAnKalIVXeui857 Iu9B4mSHuC6QixHqTQqn2eDPsmUFEO6aqLPhTErCoVJPbxSx1QRlia7Vt0frU+gz bz+Jpdyvb4ngbM1xd2XB88t8NE= Received: from webmail.dreamhost.com (caiajhbihbdd.dreamhost.com [208.97.187.133]) (Authenticated sender: ryan@sleevi.com) by homiemail-a67.g.dreamhost.com (Postfix) with ESMTPA id 221BD27BC06F; Thu, 4 Sep 2014 18:50:42 -0700 (PDT) Received: from 173.8.157.162 (proxying for 173.8.157.162) (SquirrelMail authenticated user ryan@sleevi.com) by webmail.dreamhost.com with HTTP; Thu, 4 Sep 2014 18:50:41 -0700 Message-ID: In-Reply-To: <462E2EC4-A285-4D02-9156-D8C94D6BE107@cisco.com> References: <462E2EC4-A285-4D02-9156-D8C94D6BE107@cisco.com> Date: Thu, 4 Sep 2014 18:50:41 -0700 From: "Ryan Sleevi" To: "Joseph Salowey (jsalowey)" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/75QZ2iM_3bpJXunN9wmLiB7VBL4 Cc: tls@ietf.org Subject: Re: [TLS] Early code-point assignment for draft-ietf-tls-session-hash X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: ryan-ietftls@sleevi.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: Fri, 05 Sep 2014 01:50:44 -0000 On Wed, August 20, 2014 10:06 pm, Joseph Salowey (jsalowey) wrote: > We have a request for early code point assignment for the > extended_master_secret extension in draft-ietf-tls-session-hash. I've > asked the authors to update the draft with an IANA section including t= he > details. If anyone has a concern with early code point assignment for > this draft, please respond to the list by September 3, 2014. > > Thanks, > > J&S > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > Hi Joe, Eric, Any chance that an early code point has been assigned now that the period for discussion/concerns has closed? It would be great to be able to begin implementing and avoiding interoperability issues. From nobody Thu Sep 4 21:06:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF081A03F1 for ; Thu, 4 Sep 2014 21:06:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-oyBloYtCmT for ; Thu, 4 Sep 2014 21:06:41 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id E77341A03EA for ; Thu, 4 Sep 2014 21:06:40 -0700 (PDT) Received: from [173.75.83.99] (helo=Williams-MacBook-Pro.local) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1XPknC-00047f-LV; Fri, 05 Sep 2014 00:06:34 -0400 Date: Thu, 4 Sep 2014 21:06:29 -0700 From: Bill Frantz To: Nico Williams , tls@ietf.org X-Priority: 3 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: Mailsmith 2.3.1 (422) X-ELNK-Trace: 3a5e54fa03f1b3e21aa676d7e74259b7b3291a7d08dfec7990ec918d5196f5733baf7fed44bbc0f5350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 173.75.83.99 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kT5ye__ZrfdfcYCsyeFlvoKn8Cs Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 05 Sep 2014 04:06:45 -0000 On 9/3/14 at 1:24 PM, nico@cryptonector.com (Nico Williams) wrote: >This needs to apply to implementors. It's hard to tell sysadmins to >not do certain things. You need to tell implementors what to allow >for local policy. I really like Victor's suggestion that implementations MUST NOT=20 present both encryption and NULL cypher suites on a connection.=20 They could either refuse to start up when configured with both,=20 or they could silently remove the NULL cypher suites. Cheers - Bill --------------------------------------------------------------------------- Bill Frantz |"We used to quip that "password" is the most common 408-356-8506 | password. Now it's 'password1.' Who said=20 users haven't www.pwpconsult.com | learned anything about security?" -- Bruce Schneier From nobody Thu Sep 4 22:03:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AAF21A0302 for ; Thu, 4 Sep 2014 22:03:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4 X-Spam-Level: X-Spam-Status: No, score=-4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, GB_I_LETTER=-2, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T8dWkm1nUbx9 for ; Thu, 4 Sep 2014 22:03:38 -0700 (PDT) Received: from mail-yh0-x22e.google.com (mail-yh0-x22e.google.com [IPv6:2607:f8b0:4002:c01::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC7761A01E7 for ; Thu, 4 Sep 2014 22:03:38 -0700 (PDT) Received: by mail-yh0-f46.google.com with SMTP id t59so7022597yho.5 for ; Thu, 04 Sep 2014 22:03:38 -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 :content-type; bh=5iS6140CwG6cEz7Y2jJiXFx6GsDG54R38x6/keM2A10=; b=ubfqHeJABkOe3puwU4jV+sBMcGv730FxEGj/HiZE3AX7gV8Iv6wzqRyoOAFFjUoKt6 ZJZpAGnapgVIj7VvtaMfSH+JscFDuGFbwS9naWeS1fIfLAK/3XWpAc/tznr28vlxsRqW weRNQQpQccwqxpwcNTiL/U7r/E0qSzMKpa1q68gF7KX3YX3Xyn0fLeTXnweD7c4jhmZf Ou0DEhSufk1RcKV41J+kq3SVzfieMs739Jv7VFp0oBOQMSM8b7W+2kIT7kVTZvfqrUOD ATcZ27myI8JF7sFevSBbHExMl4MspgTTLFUkBGD0uLA543pDASxb3iWYzGAl1ca3tkol gWrA== MIME-Version: 1.0 X-Received: by 10.236.137.195 with SMTP id y43mr11327246yhi.114.1409893418049; Thu, 04 Sep 2014 22:03:38 -0700 (PDT) Received: by 10.170.202.2 with HTTP; Thu, 4 Sep 2014 22:03:37 -0700 (PDT) In-Reply-To: References: Date: Thu, 4 Sep 2014 22:03:37 -0700 Message-ID: From: Watson Ladd To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7DZQRuUfEkZyMi3qYDrh9Ofh4Ss Subject: [TLS] Fwd: Why we have a BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 05 Sep 2014 05:03:42 -0000 I thought we had a UTA list to discuss the UTA draft. Apparently I was wrong: we have the TLS list instead. ---------- Forwarded message ---------- From: Watson Ladd Date: Thu, Sep 4, 2014 at 5:51 PM Subject: Why we have a BCP To: "uta@ietf.org" Dear all, At least 99% of the time, traffic goes over TLS to protect it from prying eyes. And very often, this is not the case because of various failures: from the lack of hostname validation, to the misuse of ciphers in old versions, or the use of non-PFS suites and eventual key compromise. This BCP exists to guide administrators and developers in using TLS correctly to achieve the goals that they almost certainly have. Yet, people object to recommendations being made in this BCP on the basis that they don't actually want to protect their data from prying eyes, and thus the configurations they use won't fit into the framework for those who actually want to protect their data. This is exactly what the BCP is intended to do: exclude uses that are likely to violate the expectations the naive sysadmin has of TLS. Particularly pernicious is the argument that implementations might ensure that all data sent through them is protected, and thus these implementations will not permit unprotected data to go through them. I am unsure of what the problem is with this idea: such an implementation would eliminate a vast class of problems. Simply put the BCP was intended to offer guidance on how to use TLS securely: insecure configurations are outside its remit. It appears that many members of the WG (or a few vocal ones) wish to offer instead halfhearted alternatives to ensure the continued befuddlement of those tasked with securing data in transit. I want a document I can point to and say "go do that" and rest assured that it comprehensively addresses the issues that could prevent a TLS deployment from meeting the security notions that we expect from our data. Making it possible to plead compliance to the letter while dispensing with the spirit would make this reliance impossible. To the extent that it is necessary to limit the scope of applicability, I would prefer that this be done by stating that these are Best Current Practices for ensuring the confidentiality and integrity of data via TLS, and that you probably are looking into TLS to deliver that, rather than carving out exceptions for uses that don't ensure the confidentiality and integrity of data sent via TLS. Sincerely, Watson From SRS0=3ycO=56=acm.org=bmoeller@srs.kundenserver.de Thu Sep 4 22:37:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5FF51A0414; Thu, 4 Sep 2014 22:37:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mqxWsGrfUfiF; Thu, 4 Sep 2014 22:37:12 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.187]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 884351A0413; Thu, 4 Sep 2014 22:37:12 -0700 (PDT) Received: from mail-yk0-f169.google.com (mail-yk0-f169.google.com [209.85.160.169]) by mrelayeu.kundenserver.de (node=mreue005) with ESMTP (Nemesis) id 0LsMjU-1YNGgv3ZEG-0122XA; Fri, 05 Sep 2014 07:37:10 +0200 Received: by mail-yk0-f169.google.com with SMTP id q200so6813085ykb.0 for ; Thu, 04 Sep 2014 22:37:07 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.38.225 with SMTP id a61mr11494314yhb.35.1409895427467; Thu, 04 Sep 2014 22:37:07 -0700 (PDT) Received: by 10.170.129.17 with HTTP; Thu, 4 Sep 2014 22:37:07 -0700 (PDT) Received: by 10.170.129.17 with HTTP; Thu, 4 Sep 2014 22:37:07 -0700 (PDT) In-Reply-To: References: Date: Fri, 5 Sep 2014 07:37:07 +0200 Message-ID: From: Bodo Moeller To: uta@ietf.org, tls@ietf.org Content-Type: multipart/alternative; boundary=089e01634dec1ff6b505024adc83 X-Provags-ID: V02:K0:P4qBybuuEsiRlaup7+F+coNgNRh/AjI6Nni7GxdbKzi Zv0FweONCAkUQpqQzHnklXYtzrewrmH/6G/RRlf2oByTNCreDj 2Lpo91rNtI3+b+zJMoFZDXLauPwuZcV3XKKUwvqdKbDl6DAufD qfet16K6QwqdS7k7C53O4e0di7w8hC8HFfx94XIvs5a5Q//G1l gdEJBZ06ipE247nVX6rdJKeFRK8z2pOxZ4zNV26kc96VmZfxtB PKO3V8KrYYz/hg+gA3WAQ/j80uhk9g2xLMSh0e8avl4k703yQ2 0NK34V0QB3W0mhj6iGgWlU67xc06kxiSOogo6sdRfpqFd/yUau O7Hqn5yhoza42eAcfxcKxUfPH5soOw9fprH64T1WZfu8mnoVG5 lpmG9liEFwEMUa18ruiIAJVyrxskUOauQJyfCmu3kb9jDeMAY4 sLI2h X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/knqSq6MGshjVMplhc3yoR1L8_QE Subject: Re: [TLS] Why we have a BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 05 Sep 2014 05:39:15 -0000 --089e01634dec1ff6b505024adc83 Content-Type: text/plain; charset=UTF-8 I think some of us said exactly that (with fewer snide remarks). Bodo --089e01634dec1ff6b505024adc83 Content-Type: text/html; charset=UTF-8

I think some of us said exactly that (with fewer snide remarks).

Bodo

--089e01634dec1ff6b505024adc83-- From nobody Fri Sep 5 01:03:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02751A0545 for ; Fri, 5 Sep 2014 01:03:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.219 X-Spam-Level: X-Spam-Status: No, score=-2.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLuPYV-HfkeV for ; Fri, 5 Sep 2014 01:03:24 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3384B1A053B for ; Fri, 5 Sep 2014 01:03:24 -0700 (PDT) Received: from [192.168.1.200] (p54819F96.dip0.t-ipconnect.de [84.129.159.150]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id B94331C104E61 for ; Fri, 5 Sep 2014 10:03:20 +0200 (CEST) From: Michael Tuexen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <7B4ACD49-BDE3-49B9-873A-84F31FDD3359@lurchi.franken.de> Date: Fri, 5 Sep 2014 10:03:18 +0200 To: TLS Mailing List Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/M4TnB_z0aujXKKdOzoh6l3GOxTc Subject: [TLS] (D)TLS record size limits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 05 Sep 2014 08:03:26 -0000 Dear all, when using DTLS over SCTP the message size is limited to 16KB, since = DTLS uses the same record size limit as TLS, which is 16KB. The length field = in the record layer would support up to 64KB. What is the reason for the 16 = KB limit? The reason for the question is that Diameter can be used over DTLS/SCTP = and there seems to be a use case (in mobile networks) which exceeds 16 KB, but stays below 64KB. With the upcoming interleaving extension, the support for large user = messages in SCTP is improved and it would even make sense for DTLS 1.3 (or so) to support even record sizes over 64KB. Does this "only" require a change of the record layer or are there also some security related issues which doesn't allow to support larger = messages? Best regards Michael= From nobody Fri Sep 5 01:23:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26DB11A064B for ; Fri, 5 Sep 2014 01:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.521 X-Spam-Level: X-Spam-Status: No, score=-1.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vV-b-WxE6Y0W for ; Fri, 5 Sep 2014 01:23:31 -0700 (PDT) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 872CB1A064A for ; Fri, 5 Sep 2014 01:23:31 -0700 (PDT) Received: from [10.170.248.44] (85-76-53-173-nat.elisa-mobile.fi [85.76.53.173]) by gw02.mail.saunalahti.fi (Postfix) with ESMTP id 194AD4005C; Fri, 5 Sep 2014 11:23:26 +0300 (EEST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: =?utf-8?Q?Juho_V=C3=A4h=C3=A4-Herttua?= X-Mailer: iPhone Mail (11D257) In-Reply-To: <7B4ACD49-BDE3-49B9-873A-84F31FDD3359@lurchi.franken.de> Date: Fri, 5 Sep 2014 11:23:25 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7B4ACD49-BDE3-49B9-873A-84F31FDD3359@lurchi.franken.de> To: Michael Tuexen Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ndHTTQ_EXH62KDh1QDyZcv3WtUY Cc: "" Subject: Re: [TLS] (D)TLS record size limits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 05 Sep 2014 08:23:33 -0000 > On 5.9.2014, at 11.03, Michael Tuexen w= rote: >=20 > Dear all, >=20 > when using DTLS over SCTP the message size is limited to 16KB, since DTLS > uses the same record size limit as TLS, which is 16KB. The length field in= > the record layer would support up to 64KB. What is the reason for the 16 K= B limit? As far as I know, the length is 2^14 to leave space for compression and encr= yption overheads, which are both 1024 bytes. Another benefit would be to kee= p the encryption/decryption buffers reasonable sized for constrained environ= ments. There has been discussions on this list about increasing the limit, but so f= ar there has not been a valid use case for that. Seems like you would have o= ne potential use case here. Juho From nobody Fri Sep 5 04:12:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4237D1A069D for ; Fri, 5 Sep 2014 04:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9535If7sr0PQ for ; Fri, 5 Sep 2014 04:12:27 -0700 (PDT) Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29B0B1A066A for ; Fri, 5 Sep 2014 04:12:27 -0700 (PDT) Received: from [192.168.1.200] (p54819AA2.dip0.t-ipconnect.de [84.129.154.162]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id CE0EF1C0E96AC; Fri, 5 Sep 2014 13:12:24 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Michael Tuexen In-Reply-To: Date: Fri, 5 Sep 2014 13:12:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7B4ACD49-BDE3-49B9-873A-84F31FDD3359@lurchi.franken.de> To: =?iso-8859-1?Q?Juho_V=E4h=E4-Herttua?= X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ubVUXl_iwmWlkEvnNBeq_C6dcs0 Cc: "" Subject: Re: [TLS] (D)TLS record size limits X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 05 Sep 2014 11:12:33 -0000 On 05 Sep 2014, at 10:23, Juho V=E4h=E4-Herttua wrote: >=20 >> On 5.9.2014, at 11.03, Michael Tuexen = wrote: >>=20 >> Dear all, >>=20 >> when using DTLS over SCTP the message size is limited to 16KB, since = DTLS >> uses the same record size limit as TLS, which is 16KB. The length = field in >> the record layer would support up to 64KB. What is the reason for the = 16 KB limit? >=20 > As far as I know, the length is 2^14 to leave space for compression = and encryption overheads, which are both 1024 bytes. Another benefit = would be to keep the encryption/decryption buffers reasonable sized for = constrained environments. I do understand that we might want to leave some space for overhead... = Regarding the limitation of receive buffers, an implementation could use the extension http://tools.ietf.org/html/rfc6066#section-4 to indicate this. One could also say that the default record size limit is 16 KB, and = allow to use an option similar to http://tools.ietf.org/html/rfc6066#section-4 to negotiate a limit which is larger than 16 KB. Something like enum{ 2^9(1), 2^10(2), 2^11(3), 2^12(4), 2^13(5), 2^14(6), 2^15(7), = 2^16-1(8), (255) } MaxFragmentLength; However, supporting values larger than 2^16 would require a new record = layer format with a length field of 24 or 32 bit (or whatever). With these larger fields an = appropriate extended max_fragment_length options would be necessary. >=20 > There has been discussions on this list about increasing the limit, = but so far there has not been a valid use case for that. Seems like you = would have one potential use case here. I think use cases come from datagram oriented transport layers (UDP, = DCCP, SCTP) which support fragmentation and reassembly (which limits the list to SCTP). For DCCP and UDP, you = would be limited by the path MTU, since you want to avoid IP level fragmentation. Best regards Michael >=20 >=20 > Juho >=20 >=20 From nobody Fri Sep 5 06:07:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 701F01A06A0 for ; Fri, 5 Sep 2014 06:07:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v_nO_kiKXyCa for ; Fri, 5 Sep 2014 06:07:49 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id C4A611A016A for ; Fri, 5 Sep 2014 06:07:49 -0700 (PDT) Received: from [10.70.10.54] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 3C32FF984; Fri, 5 Sep 2014 09:07:46 -0400 (EDT) Message-ID: <5409B592.7070801@fifthhorseman.net> Date: Fri, 05 Sep 2014 09:07:30 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Icedove/32.0 MIME-Version: 1.0 To: Bill Frantz , Nico Williams , tls@ietf.org References: In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="FP7F8leO26Qhv3GmE8VibEk9L2VmENJjI" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/k5J-bjuN9gfGEYFJgP0DfWGdzbc Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 05 Sep 2014 13:07:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --FP7F8leO26Qhv3GmE8VibEk9L2VmENJjI Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 09/05/2014 12:06 AM, Bill Frantz wrote: > I really like Victor's suggestion that implementations MUST NOT present= > both encryption and NULL cypher suites on a connection.=20 I like this suggestion as well, and think it does fit as a MUST NOT here -- none of the edge use cases for NULL ciphersuites that i've heard mentioned would run afoul of it. > They could > either refuse to start up when configured with both, or they could > silently remove the NULL cypher suites. Or *not-so-silently* remove the NULL cipher suites -- warnings that point to a rationale for refusing misconfiguration are helpful to the sysadmin :) Are there any objections to including Victor's suggestion in the draft? --dkg --FP7F8leO26Qhv3GmE8VibEk9L2VmENJjI Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJUCbWTXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcm7MP/1eQpIdptay+ojRsBIPImU3m P+5MRrH+BN3WVoDu9b97Q7PE9XBqCB8VlJqSSiJeEjHLLp0S9dNt0nnGz+i1kLYI WR6v5C0KGZ0mt+vF3hFMTYa4A6OOuFv6EovgGUvHKk7Td2g3pYGKrycqCAT6iULe x23VqyLXmtxBvbu7qUQOLnwx8ntPmoI8xBrhn/KvM+6cch7srz/TE+/tTY270Hfu YN7yyr6e0uYFmfGal5/oCl6aXVpypAxaUP9+ZdJ0GzGnyILAdg8Bm5mE1hbQ4Fp9 rPBiqwEENq4uMcTaZy9MXYuJrrWPjeE4Gam533afwGrEQCGl6sIRVqjuvTKsNVNx OLdFda2r4yhhKQAjAZfyfYgLCDIQromGrhGdueoDPot5vbZJzUpuZnuBejeXKQPH YJl3GhnWu4Z1ZTUF+weOGhGzIG4mIFZYHlQhcVtbGBYATBaLs8qdDHf+ehUMn4Iv PZ2Zje9zkY6VyiS5iTzM3C/VSzqgglOHlyApKHGQa8X1hmzlpjucf8MqtgMiWXxV 3+IB6zay5iG9420eLnVqqnyV8wWDle6xkV0t/5OyE4WaV7DwEX0d3yDjIBauXtQi tKKYuBS+zf/NUGw5tNpA5N8mXuYUxQfC/gj7kg0FVpNs+Pw9vgV/kjt3cKRc+yI9 MglbR84nM+dIfqVZbPbZ =s0JU -----END PGP SIGNATURE----- --FP7F8leO26Qhv3GmE8VibEk9L2VmENJjI-- From nobody Fri Sep 5 06:31:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDF331A06B8 for ; Fri, 5 Sep 2014 06:31:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.196 X-Spam-Level: X-Spam-Status: No, score=-0.196 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yrSQDIoyXDtl for ; Fri, 5 Sep 2014 06:31:01 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE4721A06B4 for ; Fri, 5 Sep 2014 06:31:00 -0700 (PDT) Received: from mail-yh0-f43.google.com (mail-yh0-f43.google.com [209.85.213.43]) by mrelayeu.kundenserver.de (node=mreue104) with ESMTP (Nemesis) id 0Lz2g4-1YTlw110Oe-014Eta; Fri, 05 Sep 2014 15:30:57 +0200 Received: by mail-yh0-f43.google.com with SMTP id f73so7487273yha.30 for ; Fri, 05 Sep 2014 06:30:56 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.0.136 with SMTP id 8mr14874702yhb.27.1409923856027; Fri, 05 Sep 2014 06:30:56 -0700 (PDT) Received: by 10.170.129.17 with HTTP; Fri, 5 Sep 2014 06:30:55 -0700 (PDT) In-Reply-To: <5409B592.7070801@fifthhorseman.net> References: <5409B592.7070801@fifthhorseman.net> Date: Fri, 5 Sep 2014 15:30:55 +0200 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=089e01635062995a1b0502517a56 X-Provags-ID: V02:K0:mVLVAqlsnElJ+xTPwhaqC+j+Huxy09uT9kT6X03H93L 8GSutdwEtkkXA1ElZYS/SY6Te7dksZrydJ/8lnWHMYtShhVxsc CQ2vLTR91lbTzRakd/y/VzQTfiWnqYt3eOA9xln3e4FN98CrjT lepTHPsQ89pd+g0HuTcmf8F98QUiHXzI8+Y7QFTL4VbWdjCMhr OU4kUgnJd6IwgGb736TA3V39fbn7igvJwcXUukwRyokCqlezip 5tyI4re3SyAAq/giOh7IGBTNE5ZDZfs76WgupR62ibWjbhIPai I4MJrWNpQU6fINEkLrN8bSDClEme/4YZq+gpHgl7F0z8ATZuvY 65T3c8jg4B3LtCkNk/EUy+wD4EJS9Jkjhvt3G7lk3d3ZwRrySx FcGPlZXKCawG3ZIMf2hM8BH44qganeJwgmPrAr7gh69mmzP5un eXJLf X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8xCKMEsaEmV9EXDgHp1WK5r2MGA Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 05 Sep 2014 13:31:01 -0000 --089e01635062995a1b0502517a56 Content-Type: text/plain; charset=UTF-8 Daniel Kahn Gillmor : Are there any objections to including Victor's suggestion in the draft? I actually think it would be more appropriate for the UTA BCP to expressly confine itself to making recommendations for applications that *do* have a desire for confidentiality, rather than trying to also regulate the wider area of applications with more esoteric needs. If NULL encryption cipher suites can't be enabled together with non-NULL encryption cipher suites, you'd break any server that attempts to allow NULL encryption for clients that decide they don't need encryption (e.g., because they're connecting to localhost) while supporting non-NULL ciphers for clients that don't offer NULL encryption for whatever reason (e.g., because the implementor just doesn't like NULL encryption, which I think is a position worthy of support). Same for clients. I'd rather prefer for the BCP to avoid this quagmire entirely. Bodo --089e01635062995a1b0502517a56 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dani= el Kahn Gillmor <dkg@fifthhorseman.net>:=C2=A0

Are there any objections to including Victor's suggestion in the draft?=

I actually think it would be more appropri= ate for the UTA BCP to expressly confine itself to making recommendations f= or applications that *do* have a desire for confidentiality, rather than tr= ying to also regulate the wider area of applications with more esoteric nee= ds.

If NULL encryption cipher suites can't be = enabled together with non-NULL encryption cipher suites, you'd break an= y server that attempts to allow NULL encryption for clients that decide the= y don't need encryption (e.g., because they're connecting to localh= ost) while supporting non-NULL ciphers for clients that don't offer NUL= L encryption for whatever reason (e.g., because the implementor just doesn&= #39;t like NULL encryption, which I think is a position worthy of support).= =C2=A0Same for clients. =C2=A0I'd rather prefer for the BCP to avoid t= his quagmire entirely.

Bodo

--089e01635062995a1b0502517a56-- From nobody Fri Sep 5 06:33:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C62471A06BC for ; Fri, 5 Sep 2014 06:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XE9WkiA2Xe0C for ; Fri, 5 Sep 2014 06:33:34 -0700 (PDT) Received: from smtp.serverkommune.de (serverkommune.de [176.9.61.43]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C01D1A06BD for ; Fri, 5 Sep 2014 06:33:34 -0700 (PDT) Received: by smtp.serverkommune.de (Postfix, from userid 5001) id 4D9C68096A; Fri, 5 Sep 2014 15:33:32 +0200 (CEST) Received: from [131.159.20.131] (ex6.serverkommune.de [176.9.61.43]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.serverkommune.de (Postfix) with ESMTPSA id 4B9B6802B1; Fri, 5 Sep 2014 15:33:28 +0200 (CEST) Message-ID: <5409BBA8.70507@net.in.tum.de> Date: Fri, 05 Sep 2014 15:33:28 +0200 From: Ralph Holz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Bodo Moeller , "tls@ietf.org" References: <5409B592.7070801@fifthhorseman.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.98.1 at ex6 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jhiVPEUfXuB-Av0lPNKjklrDLm4 Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 05 Sep 2014 13:33:36 -0000 On 09/05/2014 03:30 PM, Bodo Moeller wrote: > Daniel Kahn Gillmor >: > > Are there any objections to including Victor's suggestion in the draft? > > > I actually think it would be more appropriate for the UTA BCP to > expressly confine itself to making recommendations for applications that > *do* have a desire for confidentiality, rather than trying to also > regulate the wider area of applications with more esoteric needs. I agree with Bodo. Ralph -- Ralph Holz I8 - Network Architectures and Services Technische Universitt Mnchen http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18043 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF From nobody Fri Sep 5 06:48:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A621A06BF for ; Fri, 5 Sep 2014 06:48:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.397 X-Spam-Level: X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U_odMAUD5tZM for ; Fri, 5 Sep 2014 06:48:09 -0700 (PDT) Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 563351A06B5 for ; Fri, 5 Sep 2014 06:48:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=ebCmq4a4No7S7EH78qshyhIFzw0zXCsVKh4+zKuijgc=; b=GHO7HhHnF1V9uD+WusC6Fr3f6792OXLoDleQp9/kVV4JUJ8j663B5fI9lH6RENMX+B3V2ZFOFjyNWfwLA5s4yMTwe0SCWAhkMCgkw/blEvgHjT3xa5CdYGHjqNwsrxwmlM6psl2NS5pUknGMkEbXptEqFkNV4UUe+8udUDTqIXw=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XPtrx-0004qB-NI; Fri, 05 Sep 2014 15:48:05 +0200 Message-ID: <5409BF15.4030505@polarssl.org> Date: Fri, 05 Sep 2014 15:48:05 +0200 From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Bodo Moeller , "tls@ietf.org" References: <5409B592.7070801@fifthhorseman.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.offspark.com) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ILqt0fjDQx76F-MQyuFBI0dO6Ls Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 05 Sep 2014 13:48:10 -0000 On 05/09/2014 15:30, Bodo Moeller wrote: > If NULL encryption cipher suites can't be enabled together with non-NULL > encryption cipher suites, you'd break any server that attempts to allow > NULL encryption for clients that decide they don't need encryption (e.g., > because they're connecting to localhost) while supporting non-NULL ciphers > for clients that don't offer NULL encryption for whatever reason (e.g., > because the implementor just doesn't like NULL encryption, which I think is > a position worthy of support). I think Viktor's suggestion was that *clients* MUST NOT offer both NULL and non-NULL ciphersuites (and perhaps that servers SHOULD (or even MUST?) reject ClientHellos containing a mixture of NULL and non-NULL), but that servers are free to have both types of suites enabled at the same time. I don't have an opinion on whether this is an appropriate option for the BCP document, IMO it depends on how its scope will be defined, but I just wanted to clarify. Manuel. From nobody Fri Sep 5 06:49:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DEDF1A06C6 for ; Fri, 5 Sep 2014 06:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cZaAVzCjq94S for ; Fri, 5 Sep 2014 06:49:51 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC4E91A06BF for ; Fri, 5 Sep 2014 06:49:50 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E59132AB2CF; Fri, 5 Sep 2014 13:49:48 +0000 (UTC) Date: Fri, 5 Sep 2014 13:49:48 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140905134948.GK26920@mournblade.imrryr.org> References: <5409B592.7070801@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Umid-x2igTjCBadAIZMU7D7ysLQ Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@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, 05 Sep 2014 13:49:52 -0000 On Fri, Sep 05, 2014 at 03:30:55PM +0200, Bodo Moeller wrote: > If NULL encryption cipher suites can't be enabled together with non-NULL > encryption cipher suites, you'd break any server that attempts to allow > NULL encryption for clients that decide they don't need encryption (e.g., > because they're connecting to localhost) while supporting non-NULL ciphers > for clients that don't offer NULL encryption for whatever reason (e.g., > because the implementor just doesn't like NULL encryption, which I think is > a position worthy of support). Same for clients. I'd rather prefer for > the BCP to avoid this quagmire entirely. This is why my suggestion was specifically about the initiator (client): What is much more reasonable is that initiators (clients) should refuse to negotiate (should suppress any configured) NULL cipher suites when any non NULL cipher suite is enabled. This prevents accidents, without breaking carefully considered NULL to NULL deployments. It leaves room for dual-purpose servers. -- Viktor. From nobody Fri Sep 5 06:57:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D47541A06CC for ; Fri, 5 Sep 2014 06:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.397 X-Spam-Level: X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oeIw0Secw2W2 for ; Fri, 5 Sep 2014 06:57:31 -0700 (PDT) Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1B691A06C3 for ; Fri, 5 Sep 2014 06:57:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=c3gC8qqkEOF6GZaR7Cudj7zfTGPkfY/bko8yW3nGtX4=; b=MzaqWudoZ4ZIzT7+vknTY3yo2Ae9YW6cW/EHxeg44apfovEQ+G1JBGzIORixxYrQZeRBGt/QiY9DsWaWt6DzP6umv9y1OkBnpWwm4G/5Kz/rLyVcOdEe//lnv++LOO87rhkixe5/xWgCJYzTUrmduu8WzXyiEFTTJwDVhYWVrG0=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XPu13-0004wT-U4 for tls@ietf.org; Fri, 05 Sep 2014 15:57:30 +0200 Message-ID: <5409C149.1090402@polarssl.org> Date: Fri, 05 Sep 2014 15:57:29 +0200 From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: tls@ietf.org References: <54048985.1020005@net.in.tum.de> <20140902152308.GB14392@mournblade.imrryr.org> In-Reply-To: <20140902152308.GB14392@mournblade.imrryr.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.offspark.com) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/k9ciVfZTRmu1jict07ozY_AlmSc Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 05 Sep 2014 13:57:33 -0000 On 02/09/2014 17:23, Viktor Dukhovni wrote: > Postfix supports authenticated NULL ciphers for communication > between an MTA and local (127.0.0.1 or ::1) LMTP server. Encrypting > local IPC is just a waste of CPU. Yes, this is a specialized use-case. > I realise encrypting local communications looks like a waste, but I'm curious if we can make this assertion more quantitative. With a typical workload, do you have any idea how much more CPU would be used by starting to encrypt these communications? (Eg with AES-GCM, both with and without hardware support.) What would be an acceptable performance penalty? Manuel. From nobody Fri Sep 5 07:17:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 668031A06EE for ; Fri, 5 Sep 2014 07:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uJ51CZsMAj_q for ; Fri, 5 Sep 2014 07:16:58 -0700 (PDT) Received: from smtp.serverkommune.de (serverkommune.de [176.9.61.43]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BC6B1A06ED for ; Fri, 5 Sep 2014 07:16:58 -0700 (PDT) Received: by smtp.serverkommune.de (Postfix, from userid 5001) id 0009A807CF; Fri, 5 Sep 2014 16:16:55 +0200 (CEST) Received: from [131.159.20.131] (ex6.serverkommune.de [176.9.61.43]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.serverkommune.de (Postfix) with ESMTPSA id 1DEC980770 for ; Fri, 5 Sep 2014 16:16:55 +0200 (CEST) Message-ID: <5409C5D6.4040909@net.in.tum.de> Date: Fri, 05 Sep 2014 16:16:54 +0200 From: Ralph Holz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: tls@ietf.org References: <5409B592.7070801@fifthhorseman.net> <20140905134948.GK26920@mournblade.imrryr.org> In-Reply-To: <20140905134948.GK26920@mournblade.imrryr.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.98.1 at ex6 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PuYvTn8RnZGZ6NcsGvxs-gnOZYU Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 05 Sep 2014 14:17:02 -0000 Hi, > This is why my suggestion was specifically about the initiator > (client): > > What is much more reasonable is that initiators (clients) should > refuse to negotiate (should suppress any configured) NULL cipher > suites when any non NULL cipher suite is enabled. This prevents > accidents, without breaking carefully considered NULL to NULL > deployments. > > It leaves room for dual-purpose servers. > I am opposed to such a definition - I think it would a) be too hard to describe the rationale and why it should apply b) lead to insecure configurations because there is Yet Another Cornercase We Didn't Think Of and c) is better caught with a refined purpose statement/statement of applicability. Ralph -- Ralph Holz I8 - Network Architectures and Services Technische Universitt Mnchen http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18043 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF From nobody Fri Sep 5 07:18:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD9A1A06EE for ; Fri, 5 Sep 2014 07:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.099 X-Spam-Level: * X-Spam-Status: No, score=1.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLXxDrJwZpcf for ; Fri, 5 Sep 2014 07:18:24 -0700 (PDT) Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53ED01A06ED for ; Fri, 5 Sep 2014 07:18:24 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id DBA60699AD; Fri, 5 Sep 2014 17:18:21 +0300 (EEST) Date: Fri, 5 Sep 2014 17:18:21 +0300 From: Ilari Liusvaara To: Manuel =?utf-8?B?UMOpZ291cmnDqS1Hb25uYXJk?= Message-ID: <20140905141821.GA8893@LK-Perkele-VII> References: <54048985.1020005@net.in.tum.de> <20140902152308.GB14392@mournblade.imrryr.org> <5409C149.1090402@polarssl.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <5409C149.1090402@polarssl.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/tls/v219AV6Ky3R2Eh3vVaS3eNa8CKU Cc: tls@ietf.org Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 05 Sep 2014 14:18:26 -0000 On Fri, Sep 05, 2014 at 03:57:29PM +0200, Manuel Pégourié-Gonnard wrote: > > I realise encrypting local communications looks like a waste, but I'm curious if > we can make this assertion more quantitative. With a typical workload, do you > have any idea how much more CPU would be used by starting to encrypt these > communications? (Eg with AES-GCM, both with and without hardware support.) AES128-GCM with hardware support would use _less_ CPU (without it would use more) than any current NULL ciphersuite (NULL_SHA1 is the fastest). -Ilari From nobody Fri Sep 5 07:30:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7344B1A06ED for ; Fri, 5 Sep 2014 07:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.656 X-Spam-Level: * X-Spam-Status: No, score=1.656 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-R2PerVSvdy for ; Fri, 5 Sep 2014 07:30:23 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 90A5A1A06E4 for ; Fri, 5 Sep 2014 07:30:20 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id 10923360072 for ; Fri, 5 Sep 2014 07:30:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type:content-transfer-encoding; s= cryptonector.com; bh=S3+fw1aCEtI7qPEqWbW6px/Aag4=; b=k6X/1/fDepJ S/nFUEUflKCgQgGRlSamu2DIJzhrFb6eA9GX2f2w5VZ4pCjfd0/sUbyHOE/cFJMc ksZb+ZNOC7NBGT0OkDij48ZWGuZESij211eECY0CFs4KK8t80aKIetS5KUur+OOH dpvOh4HDD7AtjzOUNxEiKCRhfjIy2Il0= Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPSA id B47ED36006A for ; Fri, 5 Sep 2014 07:30:19 -0700 (PDT) Received: by mail-we0-f180.google.com with SMTP id w61so11938158wes.11 for ; Fri, 05 Sep 2014 07:30:18 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.58.244 with SMTP id u20mr15546696wjq.36.1409927418140; Fri, 05 Sep 2014 07:30:18 -0700 (PDT) Received: by 10.216.231.131 with HTTP; Fri, 5 Sep 2014 07:30:17 -0700 (PDT) In-Reply-To: <20140905141821.GA8893@LK-Perkele-VII> References: <54048985.1020005@net.in.tum.de> <20140902152308.GB14392@mournblade.imrryr.org> <5409C149.1090402@polarssl.org> <20140905141821.GA8893@LK-Perkele-VII> Date: Fri, 5 Sep 2014 09:30:17 -0500 Message-ID: From: Nico Williams To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0mf9ocolMIufJrINGWDXHv-15Bo Cc: =?UTF-8?Q?Manuel_P=C3=A9gouri=C3=A9=2DGonnard?= , "tls@ietf.org" Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 05 Sep 2014 14:30:24 -0000 On Fri, Sep 5, 2014 at 9:18 AM, Ilari Liusvaara wrote: > On Fri, Sep 05, 2014 at 03:57:29PM +0200, Manuel P=C3=A9gouri=C3=A9-Gonna= rd wrote: >> >> I realise encrypting local communications looks like a waste, but I'm cu= rious if >> we can make this assertion more quantitative. With a typical workload, d= o you >> have any idea how much more CPU would be used by starting to encrypt the= se >> communications? (Eg with AES-GCM, both with and without hardware support= .) > > AES128-GCM with hardware support would use _less_ CPU (without it would u= se > more) than any current NULL ciphersuite (NULL_SHA1 is the fastest). But where are your numbers? That's what Manuel asked for. And anyways, "CPU cycles" aren't what matters here. Throughput and latency are, as well as overall power. Nico -- From nobody Fri Sep 5 07:45:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 010B31A06F6 for ; Fri, 5 Sep 2014 07:44:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.867 X-Spam-Level: X-Spam-Status: No, score=-4.867 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oFXjmGoZ3HUW for ; Fri, 5 Sep 2014 07:44:56 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 646501A02D1 for ; Fri, 5 Sep 2014 07:44:56 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s85EiYwP002865 for ; Fri, 5 Sep 2014 10:44:55 -0400 Content-Type: text/plain; charset="windows-1252" MIME-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Blumenthal, Uri - 0668 - MITLL" In-Reply-To: <20140905141821.GA8893@LK-Perkele-VII> Date: Fri, 5 Sep 2014 10:41:57 -0400 Content-Transfer-Encoding: quoted-printable Message-ID: References: <54048985.1020005@net.in.tum.de> <20140902152308.GB14392@mournblade.imrryr.org> <5409C149.1090402@polarssl.org> <20140905141821.GA8893@LK-Perkele-VII> To: "" X-Mailer: Apple Mail (2.1878.6) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.27, 0.0.0000 definitions=2014-09-05_03:2014-09-05,2014-09-05,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-1402240000 definitions=main-1409050159 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AV06pdCwWFstsDZp1UEbWDTxJp8 Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 05 Sep 2014 14:44:59 -0000 >> This is why my suggestion was specifically about the initiator >> (client): >>=20 >> What is much more reasonable is that initiators (clients) should >> refuse to negotiate (should suppress any configured) NULL cipher >> suites when any non NULL cipher suite is enabled. This prevents >> accidents, without breaking carefully considered NULL to NULL >> deployments. >>=20 >> It leaves room for dual-purpose servers. >=20 > I am opposed to such a definition - I think it would a) be too hard to > describe the rationale and why it should apply b) lead to insecure > configurations because there is Yet Another Cornercase We Didn't Think > Of and c) is better caught with a refined purpose statement/statement = of > applicability. I would support such a definition as the preferred way of dealing with = this issue, but can accept a refined crystal-clear statement of = applicability (*) that crisply defines(**) what specific use case(s) = this draft is covering.=20 As for =93too hard to describe=94 - you don=92t need to dive into = rationale of =93why the user may want to apply this protection, or = disable that one=94. Just clearly state in layman=92s terms what a given = protection - and its lack - would result in. Then there would be no = corner cases. It is up to the domain owner to decide what protection is = required. You/we cannot (and shouldn't try to) think for all of them. (*) I would make clear that this BCP applies _only_ to deployment = configuration, and _not_ as an implementation guide. (**) =93Crisply=94 implies avoiding Watson=92s =93at least 99%", "almost = certainly have=94, and other similar =93scientific=94 terms. -- Regards, Uri From nobody Fri Sep 5 08:06:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41C991A6F70; Wed, 3 Sep 2014 13:40:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kSO14xLiJ0Nj; Wed, 3 Sep 2014 13:40:32 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99F881A6F4B; Wed, 3 Sep 2014 13:40:31 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id w7so10434379lbi.29 for ; Wed, 03 Sep 2014 13:40:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:content-type; bh=k7mf6ZGiKFJuClCfo00bxu+mqAVqa8OdK/y8+Ry7Fik=; b=Fp45XBdNmQtWnJZdRu5CjjOAs0zXlgvsQjjXRYp7BRANGKznB0NBeMciAPwb6Ubhfq dKprlsI41j9qOmY29JD4yRzm6trycFGPJa/6eUgxLXtRG1Arscn4BW4PU55Bl336uqB8 C+7sZHNQMX/KPHPV9lPtLn89IiIMAjIA0JTrobL5j2qCq9tzkhhaWciPfwcnIKGdNLG5 e2X303URHZ33NLiAKcvGT1EcXEeuZarQALlm5dAW9SpeQsmVOkjgSv1Zc3D38qVIsFK3 o/nD+RzdPTEZkOVWXOe16120QEpvMoCXMtIpfzllm2umcDoRaw09hlIm1cd4lw6z8yL3 irOw== MIME-Version: 1.0 X-Received: by 10.112.24.104 with SMTP id t8mr59348lbf.46.1409776829146; Wed, 03 Sep 2014 13:40:29 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.122.50 with HTTP; Wed, 3 Sep 2014 13:40:29 -0700 (PDT) Date: Wed, 3 Sep 2014 16:40:29 -0400 X-Google-Sender-Auth: DswLygbgt_s08DkC_Xi5W9trigA Message-ID: From: Phillip Hallam-Baker To: "pkix@ietf.org" , "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ic4Wbeqi09CmQR-BRDTxJNO--Rw X-Mailman-Approved-At: Fri, 05 Sep 2014 08:06:13 -0700 Subject: [TLS] New version of the TLS feature draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 03 Sep 2014 20:40:33 -0000 This draft is just a bit of wiring that allows TLS clients to make intelligent and efficient hardfail decisions when a TLS server supports OCSP stapling. OCSP stapling has been supported for some time and when supported by a server allows a client to obtain OCSP status information direct from the server rather than going hunting for it from a distribution point. What makes OCSP stapling rather less useful than it should be is that a TLS client does not know whether it should expect a TLS token or not. So the absence of an OCSP token could be because the server does not support stapling or could be because the CA has revoked the certificate with extreme prejudice because it is being used to commit fraud against people visiting the corresponding Web site. The TLS feature extension allows a certificate to state which TLS features a server using the cert MUST support. This closes the door on the downgrade attack. If the certificate specifies 'server always staples' and the server does not offer stapling, the client has a very strong signal that something is wrong and it should either abort the connection immediately or take some other corrective action. This version of the document just updates the spec to change the proposed OID as the one specified previously had been used in an April Fools RFC and fixes the text accordingly. A new version of I-D, draft-hallambaker-tlsfeature-05.txt has been successfully submitted by Phillip Hallam-Baker and posted to the IETF repository. Name: draft-hallambaker-tlsfeature Revision: 05 Title: X.509v3 TLS Feature Extension Document date: 2014-09-03 Group: Individual Submission Pages: 8 URL: http://www.ietf.org/internet-drafts/draft-hallambaker-tlsfeature-05.txt Status: https://datatracker.ietf.org/doc/draft-hallambaker-tlsfeature/ Htmlized: http://tools.ietf.org/html/draft-hallambaker-tlsfeature-05 Diff: http://www.ietf.org/rfcdiff?url2=draft-hallambaker-tlsfeature-05 From nobody Fri Sep 5 08:10:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ABC61A071C for ; Fri, 5 Sep 2014 08:10:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.55 X-Spam-Level: X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnJrTtVWjA1p for ; Fri, 5 Sep 2014 08:10:51 -0700 (PDT) Received: from smtp.serverkommune.de (serverkommune.de [176.9.61.43]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53AB01A0713 for ; Fri, 5 Sep 2014 08:10:51 -0700 (PDT) Received: by smtp.serverkommune.de (Postfix, from userid 5001) id 77A6C80390; Fri, 5 Sep 2014 17:10:49 +0200 (CEST) Received: from [131.159.20.131] (ex6.serverkommune.de [176.9.61.43]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.serverkommune.de (Postfix) with ESMTPSA id 9ADDC801FE for ; Fri, 5 Sep 2014 17:10:48 +0200 (CEST) Message-ID: <5409D278.5020504@net.in.tum.de> Date: Fri, 05 Sep 2014 17:10:48 +0200 From: Ralph Holz User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: tls@ietf.org References: <54048985.1020005@net.in.tum.de> <20140902152308.GB14392@mournblade.imrryr.org> <5409C149.1090402@polarssl.org> <20140905141821.GA8893@LK-Perkele-VII> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.98.1 at ex6 X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BfMwFBr2Zld61h223D1nsyYIMWU Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 05 Sep 2014 15:10:53 -0000 Hi, >>> What is much more reasonable is that initiators (clients) should >>> refuse to negotiate (should suppress any configured) NULL cipher >>> suites when any non NULL cipher suite is enabled. This prevents >>> accidents, without breaking carefully considered NULL to NULL >>> deployments. >>> >>> It leaves room for dual-purpose servers. >> >> I am opposed to such a definition - I think it would a) be too hard >> to describe the rationale and why it should apply b) lead to >> insecure configurations because there is Yet Another Cornercase We >> Didn't Think Of and c) is better caught with a refined purpose >> statement/statement of applicability. [...] > As for too hard to describe - you dont need to dive into rationale > of why the user may want to apply this protection, or disable that > one. Just clearly state in laymans terms what a given protection - > and its lack - would result in. Then there would be no corner cases. I think such a description can be added as half a section/page. Would you be willing to contribute it? Ralph -- Ralph Holz I8 - Network Architectures and Services Technische Universitt Mnchen http://www.net.in.tum.de/de/mitarbeiter/holz/ Phone +49.89.289.18043 PGP: A805 D19C E23E 6BBB E0C4 86DC 520E 0C83 69B0 03EF From nobody Fri Sep 5 08:34:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1259E1A0739; Fri, 5 Sep 2014 08:34:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.57 X-Spam-Level: X-Spam-Status: No, score=-7.57 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OGKEqXiJtkbh; Fri, 5 Sep 2014 08:34:50 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1E0B1A071D; Fri, 5 Sep 2014 08:34:50 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s85FYjqM032302 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 5 Sep 2014 11:34:45 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s85FYhx8022346 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 5 Sep 2014 11:34:44 -0400 Message-ID: <1409931283.1731.16.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Phillip Hallam-Baker Date: Fri, 05 Sep 2014 17:34:43 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gvugTT5LgQWF_GUpX4eZgTPa9a4 Cc: "pkix@ietf.org" , "tls@ietf.org" Subject: Re: [TLS] New version of the TLS feature draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 05 Sep 2014 15:34:52 -0000 On Wed, 2014-09-03 at 16:40 -0400, Phillip Hallam-Baker wrote: > This draft is just a bit of wiring that allows TLS clients to make > intelligent and efficient hardfail decisions when a TLS server > supports OCSP stapling. > > OCSP stapling has been supported for some time and when supported by a > server allows a client to obtain OCSP status information direct from > the server rather than going hunting for it from a distribution point. > > What makes OCSP stapling rather less useful than it should be is that > a TLS client does not know whether it should expect a TLS token or > not. So the absence of an OCSP token could be because the server does > not support stapling or could be because the CA has revoked the > certificate with extreme prejudice because it is being used to commit > fraud against people visiting the corresponding Web site. > The TLS feature extension allows a certificate to state which TLS > features a server using the cert MUST support. This closes the door on > the downgrade attack. I don't see how it does close the door. What should the client do if the server administrator sets up an old version of a valid ocsp staple? This case is not discussed in the security considerations at all. regards, Nikos From nobody Fri Sep 5 09:09:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 753D41A0739 for ; Fri, 5 Sep 2014 09:09:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08QbI6hUe0-P for ; Fri, 5 Sep 2014 09:09:03 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 840B51A034D for ; Fri, 5 Sep 2014 09:09:03 -0700 (PDT) Received: from [10.70.10.54] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 2BF70F984; Fri, 5 Sep 2014 12:08:59 -0400 (EDT) Message-ID: <5409E00D.1070703@fifthhorseman.net> Date: Fri, 05 Sep 2014 12:08:45 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Icedove/32.0 MIME-Version: 1.0 To: Markulf Kohlweiss , "tls@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/KUcz5L9X0R4R-c6n9NEHP4olqPo Subject: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 05 Sep 2014 16:09:06 -0000 Hi Markulf-- Thanks for your post encouraging ongoing collaboration between the theoretical and engineering sides of the security community. This is a worthwhile goal. Can you provide clarification on this point below? On 09/02/2014 11:03 AM, Markulf Kohlweiss wrote: > * To remove distraction and be closer to standard models like Bellare > & Rogaway, we would prefer unencrypted finished messages. In > practice this means that the finished message should be sent before > the ChangeCipherSuite message. I understand that the goal here is to be able to improve cryptanalysis of the confidentiality guarantees provided to the application data stream. Does this mean that the finished message needs to be unencrypted, or does it just mean that the finished message (and/or other parts of the handshake) should not be encrypted using the same keying material/session as the application data? That is, would the cryptanalytic side of the community be OK with having the handshake messages encrypted as long as they were using keys/session material that are distinct from the keys/session material used for the application data? Part of the TLS WG's charter for 1.3 is to encrypt as much of the handshake data as possible. I don't want that goal to interfere with theoretical cryptanalysis, but there are serious privacy concerns related to the handshake data that is sent in the clear in TLS 1.2 and below. If the cryptanalysis community insists on entirely cleartext handshake data, that will be in direct opposition to one of the two major prongs of the TLS charter. (as an aside, it would be nice to get some cryptanalytic review of any confidentiality/integrity we attempt to provide for the handshake material itself, though i understand this may be a separate question from the confidentiality/integrity guarantees we strive for in the application data) Regards, --dkg From nobody Fri Sep 5 11:06:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0059A1A6EE8 for ; Fri, 5 Sep 2014 11:06:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PCOxYqyZvfY2 for ; Fri, 5 Sep 2014 11:06:27 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F78D1A6F03 for ; Fri, 5 Sep 2014 11:05:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1007; q=dns/txt; s=iport; t=1409940359; x=1411149959; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7+1SYnO3EeKUFxzp/Ix/cEqmlLh/GV5OTB1oGtNFyJk=; b=lfjRIJf2vzI1kWefIKQPAQGxOWJkGJhbo5WJZguJsucM60jH9zyLBwuu N/RYgDtUyGoPKmwkdtYdMg/ZnN6R4X6AHgdJMKNSiTIBaoyRWjZMb73Is cXqcfiSCXRZEbnz7yYTBe1dVAVj0Kjwfvz+UwtJ1vxeTQW358gVrv1kgS 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAKL6CVStJV2R/2dsb2JhbABagw1TVwTIfwqHTAGBCBZ3hAMBAQEDAQEBAWsLBQsCAQgYLicLJQIEDgWIOggNvycBEwSPTQeDL4EdBYp4hkaLLpUmgWkcgVxsgUiBBwEBAQ X-IronPort-AV: E=Sophos;i="5.04,474,1406592000"; d="scan'208";a="75354417" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-6.cisco.com with ESMTP; 05 Sep 2014 18:05:58 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s85I5wJA031989 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Sep 2014 18:05:58 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.15]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0195.001; Fri, 5 Sep 2014 13:05:58 -0500 From: "Joseph Salowey (jsalowey)" To: "ryan-ietftls@sleevi.com" Thread-Topic: [TLS] Early code-point assignment for draft-ietf-tls-session-hash Thread-Index: AQHPvP2i8FmE+xBKU0OpoHZGpRLOTpvyMW+AgAEQewA= Date: Fri, 5 Sep 2014 18:05:57 +0000 Message-ID: <1D2C7BAF-A3EF-45B8-87EB-EB4DFD2C3C7F@cisco.com> References: <462E2EC4-A285-4D02-9156-D8C94D6BE107@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.24] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6FoTgzu6N4l4mczKpbeTDIESEwQ Cc: "tls@ietf.org" Subject: Re: [TLS] Early code-point assignment for draft-ietf-tls-session-hash X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 05 Sep 2014 18:06:35 -0000 I've sent off a request to start the process of the assignment. =20 Cheers, Joe On Sep 4, 2014, at 6:50 PM, Ryan Sleevi wrote: > On Wed, August 20, 2014 10:06 pm, Joseph Salowey (jsalowey) wrote: >> We have a request for early code point assignment for the >> extended_master_secret extension in draft-ietf-tls-session-hash. I've >> asked the authors to update the draft with an IANA section including the >> details. If anyone has a concern with early code point assignment for >> this draft, please respond to the list by September 3, 2014. >>=20 >> Thanks, >>=20 >> J&S >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >>=20 >=20 > Hi Joe, Eric, >=20 > Any chance that an early code point has been assigned now that the period > for discussion/concerns has closed? It would be great to be able to begin > implementing and avoiding interoperability issues. >=20 From nobody Fri Sep 5 14:27:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78CD81A0305 for ; Fri, 5 Sep 2014 14:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.596 X-Spam-Level: X-Spam-Status: No, score=-1.596 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7tNTAflNygU for ; Fri, 5 Sep 2014 14:27:32 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 256701A030C for ; Fri, 5 Sep 2014 14:27:32 -0700 (PDT) Received: from mail-yk0-f181.google.com (mail-yk0-f181.google.com [209.85.160.181]) by mrelayeu.kundenserver.de (node=mreue006) with ESMTP (Nemesis) id 0M0oNX-1YFdao3ynP-00v3yV; Fri, 05 Sep 2014 23:27:30 +0200 Received: by mail-yk0-f181.google.com with SMTP id 131so7331773ykp.40 for ; Fri, 05 Sep 2014 14:27:27 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.206.166 with SMTP id l26mr18543032yho.18.1409952447524; Fri, 05 Sep 2014 14:27:27 -0700 (PDT) Received: by 10.170.129.17 with HTTP; Fri, 5 Sep 2014 14:27:27 -0700 (PDT) In-Reply-To: <20140905134948.GK26920@mournblade.imrryr.org> References: <5409B592.7070801@fifthhorseman.net> <20140905134948.GK26920@mournblade.imrryr.org> Date: Fri, 5 Sep 2014 23:27:27 +0200 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=bcaec508f272c8f90e050258220a X-Provags-ID: V02:K0:wYA2fs5NfA9OJzCAj6n1UPrfg45qoLeivx+t2Ks/AwJ ACu+BV+II3Jr22RtMEEWadjNn2TBt6ITRddY9bRujPitELoWZu KD4ULd2wQ+F+oSQoyQj11hSJ/YrNZ6JR6dIduua9gKwctK3/Mo FSrmY65O5+qPCC7fsCb2Gt8r+O2nCrgTdu3yyGO0aSPc0gcSVA uG99m+mzPdecxkjfFWdQgJZHRCgIvySVPll1QQG6IqJdrAoaBV CPLCDZx4TukiQOD1sCCdlqtMwLqaR/pMIYw+21S3gmfuDLjNh0 GhOlErPKLgA9l6qztDs2abpAsQgXLksaB/mzOfAYeCr/1q/R5I LjFFOS4rxlkFCmm/5abwc+MkXQ+QK1KvYmNMEw6TNBW59p/Eds C0pqdnvN5OUVMYJHWw5QComxIhsWt/iBZl41q10eZs+UruK2WO RBo1c X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YzC3rBNioBLo8Bq3A_iKwQXmanw Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 05 Sep 2014 21:27:33 -0000 --bcaec508f272c8f90e050258220a Content-Type: text/plain; charset=UTF-8 > > > If NULL encryption cipher suites can't be enabled together with non-NULL > > encryption cipher suites, you'd break any server that attempts to allow > > NULL encryption for clients that decide they don't need encryption (e.g., > > because they're connecting to localhost) while supporting non-NULL > ciphers > > for clients that don't offer NULL encryption for whatever reason (e.g., > > because the implementor just doesn't like NULL encryption, which I think > is > > a position worthy of support). Same for clients. I'd rather prefer for > > the BCP to avoid this quagmire entirely. > > This is why my suggestion was specifically about the initiator > (client): > > What is much more reasonable is that initiators (clients) should > refuse to negotiate (should suppress any configured) NULL cipher > suites when any non NULL cipher suite is enabled. This prevents > accidents, without breaking carefully considered NULL to NULL > deployments. > > It leaves room for dual-purpose servers. > Thanks for the clarification -- so I should have expanded the very terse "Same for clients": A client content with NULL encryption may want to offer non-NULL cipher suites in the same ClientHello in case the server doesn't accept NULL encryption for whatever reason (e.g., because the implementor doesn't like NULL encryption). As noted before, I think the BCP doesn't have to deal with issues like this, and instead should provide recommendations just for applications that want to achieve confidentiality. Bodo --bcaec508f272c8f90e050258220a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> If NULL encryption cipher suites can'= ;t be enabled together with non-NULL
> encryption cipher suites, you'd break any server that attempts to = allow
> NULL encryption for clients that decide they don't need encryption= (e.g.,
> because they're connecting to localhost) while supporting non-NULL= ciphers
> for clients that don't offer NULL encryption for whatever reason (= e.g.,
> because the implementor just doesn't like NULL encryption, which I= think is
> a position worthy of support).=C2=A0 Same for clients.=C2=A0 I'd r= ather prefer for
> the BCP to avoid this quagmire entirely.
= =C2=A0
This is why my suggestion was specifically about the initiator
(client):

=C2=A0 =C2=A0 What is much more reasonable is that initiators (clients) sho= uld
=C2=A0 =C2=A0 refuse to negotiate (should suppress any configured) NULL cip= her
=C2=A0 =C2=A0 suites when any non NULL cipher suite is enabled.=C2=A0 This = prevents
=C2=A0 =C2=A0 accidents, without breaking carefully considered NULL to NULL=
=C2=A0 =C2=A0 deployments.

It leaves room for dual-purpose servers.

Thanks for the clarification -- so I should have expanded the very= terse "Sa= me for clients":=C2=A0A client content with NULL encryption may want to offer non-NULL cipher= suites in the same ClientHello in case the server doesn't accept NULL = encryption for whatever reason (e.g., because the implementor doesn't l= ike NULL encryption).

As noted before, I think the BCP doesn't have to deal with issues like= this, and instead should provide recommendations just for applications tha= t want to achieve confidentiality.


<= div>
--bcaec508f272c8f90e050258220a-- From nobody Fri Sep 5 14:49:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2416E1A02E7 for ; Fri, 5 Sep 2014 14:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNDLI9NfzlPQ for ; Fri, 5 Sep 2014 14:49:12 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41ED41A0144 for ; Fri, 5 Sep 2014 14:49:12 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id 857BF2AB2C0; Fri, 5 Sep 2014 21:49:09 +0000 (UTC) Date: Fri, 5 Sep 2014 21:49:09 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140905214909.GZ26920@mournblade.imrryr.org> References: <5409B592.7070801@fifthhorseman.net> <20140905134948.GK26920@mournblade.imrryr.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FFPkDZD_I6_YqzBAinn9uNiwrgo Subject: Re: [TLS] NULL cipher to become a MUST NOT in UTA BCP X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@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, 05 Sep 2014 21:49:14 -0000 On Fri, Sep 05, 2014 at 11:27:27PM +0200, Bodo Moeller wrote: > > This is why my suggestion was specifically about the initiator > > (client): > > > > What is much more reasonable is that initiators (clients) should > > refuse to negotiate (should suppress any configured) NULL cipher > > suites when any non NULL cipher suite is enabled. This prevents > > accidents, without breaking carefully considered NULL to NULL > > deployments. > > > > It leaves room for dual-purpose servers. > > > > Thanks for the clarification -- so I should have expanded the very terse "Same > for clients": A client content with NULL encryption may want to offer > non-NULL cipher suites in the same ClientHello in case the server doesn't > accept NULL encryption for whatever reason (e.g., because the implementor > doesn't like NULL encryption). My thinking is that clients SHOULD NOT offer NULL, unless they explicitly want NULL and know that it will be excepted. Clients that are laissez-faire about whether they get no encryption or not seem negligent to me. If they don't need whatever performance or transparency for troubleshoots they might get from NULL, they should just always go with non-NULL. This is not a proof that the mixed case has no compelling scenarios, just can't think of any as yet. > As noted before, I think the BCP doesn't have to deal with issues like > this, and instead should provide recommendations just for applications that > want to achieve confidentiality. That's fine too. I was mostly trying to non-destructively accommodate the impulse to do something normative along the lines of the original proposal. -- Viktor. From nobody Mon Sep 8 11:41:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18EAB1A02F2 for ; Mon, 8 Sep 2014 11:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.655 X-Spam-Level: X-Spam-Status: No, score=-106.655 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zH-zRkg4tTsw for ; Mon, 8 Sep 2014 11:41:06 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 7436E1A02EE for ; Mon, 8 Sep 2014 11:41:06 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 35089180015; Mon, 8 Sep 2014 11:40:58 -0700 (PDT) To: ekr@rtfm.com, nagendra@cs.stanford.edu, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, turners@ieca.com, jsalowey@cisco.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140908184058.35089180015@rfc-editor.org> Date: Mon, 8 Sep 2014 11:40:58 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6PrAKG_QSF5nS3fY2_NIMTCe4PY Cc: mpg@polarssl.org, tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] [Technical Errata Reported] RFC6347 (4103) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 08 Sep 2014 18:41:08 -0000 The following errata report has been submitted for RFC6347, "Datagram Transport Layer Security Version 1.2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6347&eid=4103 -------------------------------------- Type: Technical Reported by: Manuel Pégourié-Gonnard Section: 4.2.1 Original Text ------------- [p. 15] DTLS 1.2 server implementations SHOULD use DTLS version 1.0 regardless of the version of TLS that is expected to be negotiated. [p. 16] The server MUST use the same version number in the HelloVerifyRequest that it would use when sending a ServerHello. [p. 15] DTLS 1.2 and 1.0 clients MUST use the version solely to indicate packet formatting (which is the same in both DTLS 1.2 and 1.0) and not as part of version negotiation. In particular, DTLS 1.2 clients MUST NOT assume that because the server uses version 1.0 in the HelloVerifyRequest that the server is not DTLS 1.2 or that it will eventually negotiate DTLS 1.0 rather than DTLS 1.2. [p. 16] Upon receipt of the ServerHello, the client MUST verify that the server version values match. Corrected Text -------------- [p. 15] DTLS 1.2 server implementations MAY use DTLS version 1.0 regardless of the version of TLS that is expected to be negotiated, or the version that is expected to be negotiated. [p. 15] DTLS 1.2 and 1.0 clients MUST use the version solely to indicate packet formatting (which is the same in both DTLS 1.2 and 1.0) and not as part of version negotiation. In particular, DTLS 1.2 clients MUST NOT assume that because the server uses version 1.0 in the HelloVerifyRequest that the server is not DTLS 1.2 or that it will eventually negotiate DTLS 1.0 rather than DTLS 1.2. [p. 16] [Delete text relating to HelloVerifyRequest.server_version] Notes ----- The statements on the bottom of page 15 and on the top of page 16 are mutually contradictory. It looks like the statements on page 16 were copied from RFC 4347, but the intention was to replace them with the version from page 15 in this revision of the standard. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6347 (draft-ietf-tls-rfc4347-bis-06) -------------------------------------- Title : Datagram Transport Layer Security Version 1.2 Publication Date : January 2012 Author(s) : E. Rescorla, N. Modadugu Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Mon Sep 8 11:45:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C3851A02EE for ; Mon, 8 Sep 2014 11:45:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.554 X-Spam-Level: X-Spam-Status: No, score=-108.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z6CMHH99PDR1 for ; Mon, 8 Sep 2014 11:45:07 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 917BD1A02C2 for ; Mon, 8 Sep 2014 11:45:07 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 4113B180015; Mon, 8 Sep 2014 11:44:59 -0700 (PDT) To: ekr@rtfm.com, nagendra@cs.stanford.edu, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, turners@ieca.com, jsalowey@cisco.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140908184459.4113B180015@rfc-editor.org> Date: Mon, 8 Sep 2014 11:44:59 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GEohpqG08F2afa8JhSCQVHnMLvk Cc: mpg@polarssl.org, tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] [Editorial Errata Reported] RFC6347 (4104) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 08 Sep 2014 18:45:09 -0000 The following errata report has been submitted for RFC6347, "Datagram Transport Layer Security Version 1.2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6347&eid=4104 -------------------------------------- Type: Editorial Reported by: Manuel Pégourié-Gonnard Section: 4.1 Original Text ------------- [Page 8] In order to ensure that any given sequence/epoch pair is unique, implementations MUST NOT allow the same epoch value to be reused within two times the TCP maximum segment lifetime. In practice, TLS implementations rarely rehandshake; therefore, we do not expect this to be a problem. Corrected Text -------------- [Delete these two sentences.] Notes ----- Page 9 starts with: "Similarly, implementations MUST NOT allow the epoch to wrap" which is a stronger requirement (not allowing to wrap at all vs not allowing reuse within some period), so the weaker requirement should be eliminated to avoid confusion. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6347 (draft-ietf-tls-rfc4347-bis-06) -------------------------------------- Title : Datagram Transport Layer Security Version 1.2 Publication Date : January 2012 Author(s) : E. Rescorla, N. Modadugu Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Mon Sep 8 12:21:07 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7BCEC1A02C1 for ; Mon, 8 Sep 2014 12:21:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.554 X-Spam-Level: X-Spam-Status: No, score=-103.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A4OvjIB17jcD for ; Mon, 8 Sep 2014 12:21:04 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id F04011A001B for ; Mon, 8 Sep 2014 12:21:03 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9556D180015; Mon, 8 Sep 2014 12:20:55 -0700 (PDT) To: ekr@rtfm.com, nagendra@cs.stanford.edu, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, turners@ieca.com, jsalowey@cisco.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140908192055.9556D180015@rfc-editor.org> Date: Mon, 8 Sep 2014 12:20:55 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nSHNMGrAnjFzuRwjxbqjcBSyeGE Cc: mpg@polarssl.org, tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] [Editorial Errata Reported] RFC6347 (4105) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 08 Sep 2014 19:21:05 -0000 The following errata report has been submitted for RFC6347, "Datagram Transport Layer Security Version 1.2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6347&eid=4105 -------------------------------------- Type: Editorial Reported by: Manuel Pégourié-Gonnard Section: 4.1.2.1 Original Text ------------- In DTLS, the receiving implementation MAY simply discard the offending record and continue with the connection. This change is possible because DTLS records are not dependent on each other in the way that TLS records are. In general, DTLS implementations SHOULD silently discard records with bad MACs or that are otherwise invalid. They MAY log an error. If a DTLS implementation chooses to generate an alert when it receives a message with an invalid MAC, it MUST generate a bad_record_mac alert with level fatal and terminate its connection state. Note that because errors do not cause connection termination, DTLS stacks are more efficient error type oracles than TLS stacks. Thus, it is especially important that the advice in Section 6.2.3.2 of [TLS12] be Corrected Text -------------- See section 4.1.2.7. [And merge the last two sentences above in section 4.1.2.7.] Notes ----- Some text is duplicated between 4.1.2.1 and 4.1.2.7, which my cause confusion or give rise to diverging updates in future revisions of this document. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6347 (draft-ietf-tls-rfc4347-bis-06) -------------------------------------- Title : Datagram Transport Layer Security Version 1.2 Publication Date : January 2012 Author(s) : E. Rescorla, N. Modadugu Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Tue Sep 9 12:26:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A05081A019C for ; Tue, 9 Sep 2014 12:25:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bH9VdJDwVD8p for ; Tue, 9 Sep 2014 12:25:56 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8AA0C1A011B for ; Tue, 9 Sep 2014 12:25:56 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 3EF53BE88; Tue, 9 Sep 2014 20:25:53 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mpiVLVYs4JvK; Tue, 9 Sep 2014 20:25:51 +0100 (IST) Received: from [10.87.48.8] (unknown [86.41.50.1]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 5C3B0BE02; Tue, 9 Sep 2014 20:25:51 +0100 (IST) Message-ID: <540F543E.8080505@cs.tcd.ie> Date: Tue, 09 Sep 2014 20:25:50 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" , "ryan-ietftls@sleevi.com" References: <462E2EC4-A285-4D02-9156-D8C94D6BE107@cisco.com> <1D2C7BAF-A3EF-45B8-87EB-EB4DFD2C3C7F@cisco.com> In-Reply-To: <1D2C7BAF-A3EF-45B8-87EB-EB4DFD2C3C7F@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xiKnzvnKvjtc7cf5vm6PLYqAXFI Cc: "tls@ietf.org" Subject: Re: [TLS] Early code-point assignment for draft-ietf-tls-session-hash X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 09 Sep 2014 19:25:59 -0000 Hi all, I've now gotten to that and plan to approve this early allocation. Be great if the wg can finish up the draft soon too - there's a 1 year timer that starts when IANA do the allocation. Cheers, S. On 05/09/14 19:05, Joseph Salowey (jsalowey) wrote: > I've sent off a request to start the process of the assignment. > > Cheers, > > Joe > On Sep 4, 2014, at 6:50 PM, Ryan Sleevi wrote: > >> On Wed, August 20, 2014 10:06 pm, Joseph Salowey (jsalowey) wrote: >>> We have a request for early code point assignment for the >>> extended_master_secret extension in draft-ietf-tls-session-hash. I've >>> asked the authors to update the draft with an IANA section including the >>> details. If anyone has a concern with early code point assignment for >>> this draft, please respond to the list by September 3, 2014. >>> >>> Thanks, >>> >>> J&S >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>> >> >> Hi Joe, Eric, >> >> Any chance that an early code point has been assigned now that the period >> for discussion/concerns has closed? It would be great to be able to begin >> implementing and avoiding interoperability issues. >> > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > From nobody Tue Sep 9 18:37:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754EB1A03F3 for ; Tue, 9 Sep 2014 18:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WPqXuCFC4Osr for ; Tue, 9 Sep 2014 18:37:49 -0700 (PDT) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A9C31A0337 for ; Tue, 9 Sep 2014 18:37:49 -0700 (PDT) Received: by mail-yk0-f171.google.com with SMTP id 79so2563519ykr.30 for ; Tue, 09 Sep 2014 18:37:48 -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=GCGxn5tSUbWxqnhPHi6H1Pb2v4Nd+DhHVLHlUS06DBw=; b=mYxg/b/sSFe/Zrx/muycMfKeJ4Nsb+qv4K9vmInbGbIPROMBMk+4yEoebm7C+TEF1F pH6JK4QUZRyBnbuU4oMyUFMCHyAw4J27xMB0i+Hq5cnDedH8AkNcpInVcgPd6UM/gbOb XOB6aw/2IArE+yWnDSHLNA/UY9rjHnSPoOZlpgXmzWdMUgpI6kvVtCeozyIXCk+g79hI VuBqmV76krbf+zOQdVxCPC3SAv0w7sRqCYLYe6dUedSYLtTGvp//jpsMIpllMbuSOAv8 MJkXF0ynBQSo5q+pRcgHKJNGEjeeeE/UnkQF1pBunAdgZgh9UuNq+ZyrMoDPIfxUusYi oN4Q== MIME-Version: 1.0 X-Received: by 10.236.199.115 with SMTP id w79mr53712769yhn.36.1410313068340; Tue, 09 Sep 2014 18:37:48 -0700 (PDT) Received: by 10.170.207.216 with HTTP; Tue, 9 Sep 2014 18:37:48 -0700 (PDT) In-Reply-To: <5409E00D.1070703@fifthhorseman.net> References: <5409E00D.1070703@fifthhorseman.net> Date: Tue, 9 Sep 2014 18:37:48 -0700 Message-ID: From: Watson Ladd To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Y5Hr2EtF-Jnm6rbkz5srKEaw3Hs Cc: Markulf Kohlweiss , "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 10 Sep 2014 01:37:51 -0000 On Fri, Sep 5, 2014 at 9:08 AM, Daniel Kahn Gillmor wrote: > Hi Markulf-- > > Thanks for your post encouraging ongoing collaboration between the > theoretical and engineering sides of the security community. This is a > worthwhile goal. > > Can you provide clarification on this point below? > > On 09/02/2014 11:03 AM, Markulf Kohlweiss wrote: >> >> * To remove distraction and be closer to standard models like Bellare >> & Rogaway, we would prefer unencrypted finished messages. In >> practice this means that the finished message should be sent before >> the ChangeCipherSuite message. > > > I understand that the goal here is to be able to improve cryptanalysis of > the confidentiality guarantees provided to the application data stream. > Does this mean that the finished message needs to be unencrypted, or does it > just mean that the finished message (and/or other parts of the handshake) > should not be encrypted using the same keying material/session as the > application data? If TLS is going over an encrypted channel, that doesn't change the security of TLS. Rather the issue is the use of the master secret to encrypt a finished message also derived from the master secret, and then using the same keys to encrypt everything else. The solution is to do what IKEv2 did: adopt wholesale a correct solution to the problem. > > That is, would the cryptanalytic side of the community be OK with having the > handshake messages encrypted as long as they were using keys/session > material that are distinct from the keys/session material used for the > application data? Maybe! It really depends on the details of what is going on. Look at the history of Kerberos to see how subtle these issues can be. > > Part of the TLS WG's charter for 1.3 is to encrypt as much of the handshake > data as possible. I don't want that goal to interfere with theoretical > cryptanalysis, but there are serious privacy concerns related to the > handshake data that is sent in the clear in TLS 1.2 and below. If the > cryptanalysis community insists on entirely cleartext handshake data, that > will be in direct opposition to one of the two major prongs of the TLS > charter. > > (as an aside, it would be nice to get some cryptanalytic review of any > confidentiality/integrity we attempt to provide for the handshake material > itself, though i understand this may be a separate question from the > confidentiality/integrity guarantees we strive for in the application data) Review is not enough: Triple Handshake was missed for how long? Rather we need design that makes useful proofs possible. Occasionally this can mean doing things that don't "make sense" or seem "unnecessary" but let the proof go through. Sincerely, Watson Ladd > > Regards, > > --dkg > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Tue Sep 9 19:21:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72DAF1A02EC for ; Tue, 9 Sep 2014 19:21:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[AC_BR_BONANZA=0.001, BAYES_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id du5yEefC8pRU for ; Tue, 9 Sep 2014 19:21:17 -0700 (PDT) Received: from smtp3.pacifier.net (smtp3.pacifier.net [64.255.237.177]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B8ED1A016A for ; Tue, 9 Sep 2014 19:21:17 -0700 (PDT) Received: from Philemon (unknown [50.38.74.159]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jimsch@nwlink.com) by smtp3.pacifier.net (Postfix) with ESMTPSA id 0F36038F16; Tue, 9 Sep 2014 19:21:15 -0700 (PDT) From: "Jim Schaad" To: "'Alfredo Pironti'" References: <00d201cfc63b$1c48b1d0$54da1570$@augustcellars.com> In-Reply-To: Date: Tue, 9 Sep 2014 19:18:48 -0700 Message-ID: <002301cfcc9d$91f6b4f0$b5e41ed0$@augustcellars.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0024_01CFCC62.E59BFBA0" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQIwHqUJraTjtsmZk4/IhubD8nADKwIfYFE7myfyXzA= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7ih5b1aOD4cDSZwZF8fRsyFWSQU Cc: tls@ietf.org Subject: Re: [TLS] Master Secret Computation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 10 Sep 2014 02:21:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0024_01CFCC62.E59BFBA0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable As I said in my message, I believe that these issues apply both the TLS = 1.3 document and to the session hash document. The questions that I = would have for the session hash document are: =20 1. Why is there not a justification of stopping the hash before = the CertVerify handshake message rather than before the Finish message = which is more logical. 2. From the table that I included: Does the use of the = CertificateURL message cause a problem which has not been looked at. = Since this may not include any client specific data (the client = certificate is not sent), we are not back into a situation where the = client identity and identity key are not included as part of the = computation for the master secret. I can=E2=80=99t find it on a fast = scan, but I believe that you have stated that hashing the client = identity into the handshake messages is of importance. This would = appear to argue for hashing the CertificateVerify handshake message = since it would be a unique value for the client and associated with the = client certificate in this case. (Another way would be to hash in the = result of getting the certificate from the URL but that is probably not = desirable.) 3. I don=E2=80=99t believe that there are any implications that = come from the use of the Supplemental Data and New Session Ticket = handshake messages, however it would be good to state that this is the = case. I would note that in the case of the New Session Ticket messages, = the one sent from the server to the client can occur only after the = client finish message has been received so it cannot be part of the = context used to build the master secret. =20 Jim =20 =20 From: Alfredo Pironti [mailto:alfredo@pironti.eu]=20 Sent: Wednesday, September 03, 2014 1:45 AM To: Jim Schaad Cc: tls@ietf.org Subject: Re: [TLS] Master Secret Computation =20 =20 =20 On Tue, Sep 2, 2014 at 1:18 AM, Jim Schaad = wrote: This message applies to both the 1.3 TLS document and to the session = hash document. I have not ever implemented TLS, so I have been spending some time = reading the documents to try and figure out how things are going to work. Based = on mail see, I have assumed that 1.3 is going to adopt the extended hash computation for the master secret and have created my table based on = this. (If this is not the case then I think it needs to be argued.) As part of putting together the attacked picture, I read a number of different TLS documents which are not part of the core spec. It is = possible that some of these are no longer needed and should be ruled out as = possible extensions to the TLS 1.3 document, but would be relevant to the = extension for the 1.2 (and prior) documents. Notes on the picture that I have included: Items tagged with [1] are sent only in the event that the server does = not want to have a client certificate. Items tagged with [2] are sent only in the event that the a) there is a client certificate or b) the new session ticket extension is being used. Items tagged with [3] are sent in the event that a restart is made = because of a mismatch of key agree groups. I am not clear if the use of the Supplemental Data extension means that = the server Finish message cannot be sent before receiving the response from = the client. The new session ticket extension requires that the client finish message = be validated before it can be sent to the client, thus it falls into the = [2] grouping. The green means that the handshake message is part of the hash = computation. The yellow means that it would be part of the computation for [2] but = not for [1]. The "pink" is part of my assumption that a the hashing should include the failed early handshake message. The current hashing document says that the hash would not include the CertificateVerify message (for the client). I am assuming that this is because there is a large presumption that the hash that is used for the = PRF function and the hash that the client would use in computing the CertificateVerify message is going to same. This presumption should probably be documented. =20 The hash used for signature and the one used for the PRF can indeed be = different. The reason why we left CertificateVerify out from the session_hash is = that the master_secret computation depends on session_hash. In turn, in = SSL 3.0, the computation of CertificateVerify depends on the = master_secret. This could be relaxed for later TLS versions, where the master_secret is = not used in the computation of the CertificateVerify message. However, = since CertificateVerify does not alter the state of the session, we left = it out for all TLS versions, to ease implementation of the extension. This choice is documented in the implementation note of section 3 of the = current session-hash draft. But if the text doesn't read clear enough, = we can try to improve it. =20 I am unsure what the correct behavior should be in the event that the SupplementalData extension is used, but the client certificate message = is not used. Should this be part of the master secret hash or not? In looking at the sequence, doing a re-negotiation would seem to have a = bad property of going from the cipher suite which uses the hash of the = handshake to one that just uses the keys and the randoms part way through the re-negotiation process. This means that any application data sent = between the first and the second change_cipher_suite messages would potentially = not be as well protected. This could be fixed by not having the first pair = of change_cipher_suite messages in the event of a re-negotiation as there = is no need to go from a NULL_NULL cipher suite to one which has encryption. =20 As discussed in the session-hash call for adoption thread [1], the = session-hash extension is mainly intended as a fix for TLS <=3D 1.2; = whereas the fix should be an integral part of TLS 1.3 (and how this is = precisely achieved is still under design). Best, Alfredo [1] http://www.ietf.org/mail-archive/web/tls/current/msg13173.html=20 =20 Jim _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls =20 ------=_NextPart_000_0024_01CFCC62.E59BFBA0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

As I said in my message, I believe that these issues apply both the = TLS 1.3 document and to the session hash document.=C2=A0 The questions = that I would have for the session hash document = are:

 

1.       = =C2=A0Why is there not a justification of stopping the hash before = the CertVerify handshake message rather than before the Finish message = which is more logical.

2.       = From the table that I included:=C2=A0 Does the use of the = CertificateURL message cause a problem which has not been looked = at.=C2=A0 Since this may not include any client specific data (the = client certificate is not sent), we are not back into a situation where = the client identity and identity key are not included as part of the = computation for the master secret. =C2=A0=C2=A0I can=E2=80=99t find it = on a fast scan, but I believe that you have stated that hashing the = client identity into the handshake messages is of importance.=C2=A0 This = would appear to argue for hashing the CertificateVerify handshake = message since it would be a unique value for the client and associated = with the client certificate in this case.=C2=A0 (Another way would be to = hash in the result of getting the certificate from the URL but that is = probably not desirable.)

3.       = I don=E2=80=99t believe that there are any implications that come = from the use of the Supplemental Data and New Session Ticket handshake = messages, however it would be good to state that this is the case.=C2=A0 = I would note that in the case of the New Session Ticket messages, the = one sent from the server to the client can occur only after the client = finish message has been received so it cannot be part of the context = used to build the master secret.

 

Jim

 

 

From:= = Alfredo Pironti [mailto:alfredo@pironti.eu]
Sent: Wednesday, = September 03, 2014 1:45 AM
To: Jim Schaad
Cc: = tls@ietf.org
Subject: Re: [TLS] Master Secret = Computation

 

 

 

On Tue, Sep 2, 2014 at 1:18 AM, Jim Schaad <ietf@augustcellars.com> wrote:

This message applies to both the 1.3 TLS document and = to the session hash
document.


I have not ever implemented = TLS, so I have been spending some time reading
the documents to try = and figure out how things are going to work.  Based on
mail see, = I have assumed that 1.3 is going to adopt the extended = hash
computation for the master secret and have created my table = based on this.
(If this is not the case then I think it needs to be = argued.)

As part of putting together the attacked picture, I read = a number of
different TLS documents which are not part of the core = spec.  It is possible
that some of these are no longer needed = and should be ruled out as possible
extensions to the TLS 1.3 = document, but would be relevant to the extension
for the 1.2 (and = prior) documents.

Notes on the picture that I have = included:

Items tagged with [1] are sent only in the event that = the server does not
want to have a client certificate.
Items = tagged with [2] are sent only in the event that the a) there is = a
client certificate or b) the new session ticket extension is being = used.
Items tagged with [3] are sent in the event that a restart is = made because
of a mismatch of key agree groups.

I am not clear = if the use of the Supplemental Data extension means that the
server = Finish message cannot be sent before receiving the response from = the
client.
The new session ticket extension requires that the = client finish message be
validated before it can be sent to the = client, thus it falls into the [2]
grouping.

The green means = that the handshake message is part of the hash computation.
The = yellow means that it would be part of the computation for [2] but = not
for [1].  The "pink" is part of my assumption that = a the hashing should
include the failed early handshake = message.

The current hashing document says that the hash would = not include the
CertificateVerify message (for the client).  I = am assuming that this is
because there is a large presumption that = the hash that is used for the PRF
function and the hash that the = client would use in computing the
CertificateVerify message is going = to same.  This presumption should
probably be = documented.

 

The hash used for signature and the one used for the = PRF can indeed be different.
The reason why we left CertificateVerify = out from the session_hash is that the master_secret computation depends = on session_hash. In turn, in SSL 3.0, the computation of = CertificateVerify depends on the master_secret.
This could be relaxed = for later TLS versions, where the master_secret is not used in the = computation of the CertificateVerify message. However, since = CertificateVerify does not alter the state of the session, we left it = out for all TLS versions, to ease implementation of the = extension.
This choice is documented in the implementation note of = section 3 of the current session-hash draft. But if the text doesn't = read clear enough, we can try to improve it.

 


I am = unsure what the correct behavior should be in the event that = the
SupplementalData extension is used, but the client certificate = message is
not used.  Should this be part of the master secret = hash or not?

In looking at the sequence, doing a re-negotiation = would seem to have a bad
property of going from the cipher suite = which uses the hash of the handshake
to one that just uses the keys = and the randoms part way through the
re-negotiation process.  = This means that any application data sent between
the first and the = second change_cipher_suite messages would potentially not
be as well = protected.  This could be fixed by not having the first pair = of
change_cipher_suite messages in the event of a re-negotiation as = there is no
need to go from a NULL_NULL cipher suite to one which has = encryption.

 

As discussed in the session-hash call for adoption = thread [1], the session-hash extension is mainly intended as a fix for = TLS <=3D 1.2; whereas the fix should be an integral part of TLS 1.3 = (and how this is precisely achieved is still under = design).

Best,
Alfredo

[1] h= ttp://www.ietf.org/mail-archive/web/tls/current/msg13173.html =

 



Jim











































=

















<= br>



















































=

















<= br>



















































=

















<= br>



















































=

















<= br>



















































=

















<= br>



















































=

















<= br>



















































=

















<= br>



















































=

















<= br>



















































=

















<= br>



















































=

















<= br>



































_______________________________________________
TLS = mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

 

------=_NextPart_000_0024_01CFCC62.E59BFBA0-- From nobody Wed Sep 10 03:56:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C43B71A6F47 for ; Wed, 10 Sep 2014 03:56:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B69SUfDefhaf for ; Wed, 10 Sep 2014 03:56:37 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0708.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::708]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12E841A6F32 for ; Wed, 10 Sep 2014 03:56:37 -0700 (PDT) Received: from BN3PR0301CA0023.namprd03.prod.outlook.com (25.160.180.161) by BLUPR03MB245.namprd03.prod.outlook.com (10.255.213.13) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Wed, 10 Sep 2014 10:56:14 +0000 Received: from BN1AFFO11FD019.protection.gbl (2a01:111:f400:7c10::188) by BN3PR0301CA0023.outlook.office365.com (2a01:111:e400:4000::33) with Microsoft SMTP Server (TLS) id 15.0.1024.12 via Frontend Transport; Wed, 10 Sep 2014 10:56:14 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD019.mail.protection.outlook.com (10.58.52.79) with Microsoft SMTP Server (TLS) id 15.0.1019.14 via Frontend Transport; Wed, 10 Sep 2014 10:56:13 +0000 Received: from 064-smtp-out.microsoft.com (141.251.33.16) by TK5EX14HUBC106.redmond.corp.microsoft.com (157.54.80.61) with Microsoft SMTP Server (TLS) id 14.3.195.2; Wed, 10 Sep 2014 10:56:00 +0000 Received: from AMSPRD3001MB017.064d.mgd.msft.net ([169.254.8.57]) by AMSPRD3001HT003.064d.mgd.msft.net ([141.251.33.16]) with mapi id 14.16.0466.000; Wed, 10 Sep 2014 10:55:53 +0000 From: Markulf Kohlweiss To: Daniel Kahn Gillmor , "tls@ietf.org" Thread-Topic: cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: [TLS] Simplifying the proof] Thread-Index: AQHPySPDfXANLq+QVUq/ICcRHd7S25v4qURA Date: Wed, 10 Sep 2014 10:55:52 +0000 Message-ID: References: <5409E00D.1070703@fifthhorseman.net> In-Reply-To: <5409E00D.1070703@fifthhorseman.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [141.251.33.4] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019019)(6009001)(438002)(24454002)(189002)(13464003)(479174003)(377454003)(199003)(84676001)(2656002)(107046002)(64706001)(87936001)(46102001)(74502001)(95666004)(99396002)(86146001)(31966008)(74662001)(85306004)(16796002)(2501002)(20776003)(107886001)(97736003)(4396001)(47776003)(79102001)(80022001)(66066001)(21056001)(55846006)(76482001)(106466001)(81156004)(81342001)(19580395003)(26826002)(19580405001)(69596002)(81542001)(68736004)(83322001)(6806004)(44976005)(77982001)(106116001)(92566001)(85852003)(50986999)(54356999)(92726001)(76176999)(86362001)(33656002)(90102001)(23676002)(77096002)(86612001)(50466002)(83072002); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR03MB245; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 033054F29A Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=markulf@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/F-4NNZPPRmIyi_r-cHFy1NvrTIU Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 10 Sep 2014 10:56:39 -0000 SGkgRGFuaWVsLA0KDQpUaGFua3MgYSBsb3QgZm9yIHRoZSBkaXNjdXNzaW9uLiANCg0KMSkgV2Ug c2hvdWxkIGJlIHZlcnkgY2xlYXIgYWJvdXQgd2hhdCBzaG91bGQgYmUgZG9uZSBieSBUTFMgYW5k IHdoYXQgYnkgYXBwbGljYXRpb24gcHJvdG9jb2xzLCBhbmQgaG93IHRoZSB0d28gaW50ZXJhY3Qu IEEgZ29vZCBleGFtcGxlIGZvciB0aGlzIGFyZSBDaGFubmVsIElEIGFuZCBUb2tlbiBCaW5kaW5n LiBUaHVzIG91ciBjYWxsIGZvciBzdGFuZGFyZGl6aW5nIGEgVExTIEFQSS4NCg0KMikgQWZ0ZXIg YSBzZWN1cmUgZW5vdWdoIHNlc3Npb24gaGFzIGJlZW4gZXN0YWJsaXNoZWQsIGEgc2VwYXJhdGUg a2V5IGNvdWxkIGJlIHVzZWQgdG8gcHJvdGVjdCBhZGRpdGlvbmFsIGhhbmRzaGFrZSBtZXNzYWdl cy4gQXMgdXN1YWwgdGhlIGNvbmNlcm4gaXMgd2l0aCB0aGUgc2FtZSBrZXkgYmVpbmcgdXNlZCBm b3IgZGlmZmVyZW50IHB1cnBvc2VzLiBJIGRvbid0IHRoaW5rIHRoZSBjcnlwdGFuYWx5c2lzIGNv bW11bml0eSB3b3VsZCBiZSBjb25jZXJuZWQgYnkgc2VwYXJhdGUga2V5cyBpbiBwcmluY2lwbGUu IA0KDQpIaWRpbmcgd2hpY2ggYXBwbGljYXRpb24gcHJvdG9jb2xzIGFyZSBiZWluZyBuZWdvdGlh dGVkIChhbmQgd2hpY2gga2V5cyB0aGV5IHNob3VsZCB1c2UpIGNvdWxkIGJlIG9uZSBvZiB0aGUg bGVnaXRpbWF0ZSB1c2UtY2FzZXMgZm9yIHRoaXMsIGNmLiB0aGUgZGlzY3Vzc2lvbiBhcm91bmQg TlBOIHZzIEFMUE4uIFRob3VnaCB0aGVyZSBhcmUgcHJvYmFibHkgbWFueSBvdGhlcnMgdGhhdCBJ IGFtIG5vdCBhd2FyZSBvZiwgYW5kIG1ha2luZyB0aGUgaGFuZHNoYWtlIGxvb2sgYXMgdW5pZm9y bSBhcyBwb3NzaWJsZSBmb3Igb3V0c2lkZXJzIGlzIGdvb2QgZm9yIHByaXZhY3kuDQoNCjMpIFdp dGggdGhlIHBvc3NpYmlsaXR5IG9mIHJlLW5lZ290aWF0aW9uIGJlaW5nIGFib2xpc2hlZCBhbmQg a2V5IGdlbmVyYXRpb24gYmVpbmcgc3RyZW5ndGhlbmVkLCB0aGUgbmVlZCBmb3IgZmluaXNoZWQg bWVzc2FnZXMgbWF5IGRlY3JlYXNlLiBCdXQgSSB3b3VsZCBiZSB2ZXJ5IGNhcmVmdWwgYmVmb3Jl IGFib2xpc2hpbmcgdGhlbS4NCg0KVGhlc2UgYXJlIGdyZWF0IGV4YW1wbGVzIGZvciBxdWVzdGlv bnMgZm9yIHdoaWNoIGEgZm9ybWFsIG1vZGVsbGluZyBvZiB0aGUgaGFuZHNoYWtlIGNhbiBjcmVh dGUgbmV3IGluc2lnaHRzLiANCg0KQmVzdCwNCg0KTWFya3VsZg0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogRGFuaWVsIEthaG4gR2lsbG1vciBbbWFpbHRvOmRrZ0BmaWZ0aGhv cnNlbWFuLm5ldF0gDQpTZW50OiAwNSBTZXB0ZW1iZXIgMjAxNCAxNzowOQ0KVG86IE1hcmt1bGYg S29obHdlaXNzOyB0bHNAaWV0Zi5vcmcNClN1YmplY3Q6IGNyeXB0YW5hbHlzaXMgdnMuIGVuY3J5 cHRlZCBwYXJ0cyBvZiB0aGUgVExTIGhhbmRzaGFrZSBbd2FzOiBSZTogW1RMU10gU2ltcGxpZnlp bmcgdGhlIHByb29mXQ0KDQpIaSBNYXJrdWxmLS0NCg0KVGhhbmtzIGZvciB5b3VyIHBvc3QgZW5j b3VyYWdpbmcgb25nb2luZyBjb2xsYWJvcmF0aW9uIGJldHdlZW4gdGhlIHRoZW9yZXRpY2FsIGFu ZCBlbmdpbmVlcmluZyBzaWRlcyBvZiB0aGUgc2VjdXJpdHkgY29tbXVuaXR5LiAgVGhpcyBpcyBh IHdvcnRod2hpbGUgZ29hbC4NCg0KQ2FuIHlvdSBwcm92aWRlIGNsYXJpZmljYXRpb24gb24gdGhp cyBwb2ludCBiZWxvdz8NCg0KT24gMDkvMDIvMjAxNCAxMTowMyBBTSwgTWFya3VsZiBLb2hsd2Vp c3Mgd3JvdGU6DQo+ICogVG8gcmVtb3ZlIGRpc3RyYWN0aW9uIGFuZCBiZSBjbG9zZXIgdG8gc3Rh bmRhcmQgbW9kZWxzIGxpa2UgQmVsbGFyZQ0KPiAgICAmIFJvZ2F3YXksIHdlIHdvdWxkIHByZWZl ciB1bmVuY3J5cHRlZCBmaW5pc2hlZCBtZXNzYWdlcy4gSW4NCj4gICAgcHJhY3RpY2UgdGhpcyBt ZWFucyB0aGF0IHRoZSBmaW5pc2hlZCBtZXNzYWdlIHNob3VsZCBiZSBzZW50IGJlZm9yZQ0KPiAg ICB0aGUgQ2hhbmdlQ2lwaGVyU3VpdGUgbWVzc2FnZS4NCg0KSSB1bmRlcnN0YW5kIHRoYXQgdGhl IGdvYWwgaGVyZSBpcyB0byBiZSBhYmxlIHRvIGltcHJvdmUgY3J5cHRhbmFseXNpcyBvZiB0aGUg Y29uZmlkZW50aWFsaXR5IGd1YXJhbnRlZXMgcHJvdmlkZWQgdG8gdGhlIGFwcGxpY2F0aW9uIGRh dGEgc3RyZWFtLiAgRG9lcyB0aGlzIG1lYW4gdGhhdCB0aGUgZmluaXNoZWQgbWVzc2FnZSBuZWVk cyB0byBiZSB1bmVuY3J5cHRlZCwgb3IgZG9lcyBpdCBqdXN0IG1lYW4gdGhhdCB0aGUgZmluaXNo ZWQgbWVzc2FnZSAoYW5kL29yIG90aGVyIHBhcnRzIG9mIHRoZSBoYW5kc2hha2UpIHNob3VsZCBu b3QgYmUgZW5jcnlwdGVkIHVzaW5nIHRoZSBzYW1lIGtleWluZyBtYXRlcmlhbC9zZXNzaW9uIGFz IHRoZSBhcHBsaWNhdGlvbiBkYXRhPw0KDQpUaGF0IGlzLCB3b3VsZCB0aGUgY3J5cHRhbmFseXRp YyBzaWRlIG9mIHRoZSBjb21tdW5pdHkgYmUgT0sgd2l0aCBoYXZpbmcgdGhlIGhhbmRzaGFrZSBt ZXNzYWdlcyBlbmNyeXB0ZWQgYXMgbG9uZyBhcyB0aGV5IHdlcmUgdXNpbmcga2V5cy9zZXNzaW9u IG1hdGVyaWFsIHRoYXQgYXJlIGRpc3RpbmN0IGZyb20gdGhlIGtleXMvc2Vzc2lvbiBtYXRlcmlh bCB1c2VkIGZvciB0aGUgYXBwbGljYXRpb24gZGF0YT8NCg0KUGFydCBvZiB0aGUgVExTIFdHJ3Mg Y2hhcnRlciBmb3IgMS4zIGlzIHRvIGVuY3J5cHQgYXMgbXVjaCBvZiB0aGUgaGFuZHNoYWtlIGRh dGEgYXMgcG9zc2libGUuICBJIGRvbid0IHdhbnQgdGhhdCBnb2FsIHRvIGludGVyZmVyZSB3aXRo IHRoZW9yZXRpY2FsIGNyeXB0YW5hbHlzaXMsIGJ1dCB0aGVyZSBhcmUgc2VyaW91cyBwcml2YWN5 IGNvbmNlcm5zIHJlbGF0ZWQgdG8gdGhlIGhhbmRzaGFrZSBkYXRhIHRoYXQgaXMgc2VudCBpbiB0 aGUgY2xlYXIgaW4gVExTIDEuMiBhbmQgYmVsb3cuICBJZiB0aGUgY3J5cHRhbmFseXNpcyBjb21t dW5pdHkgaW5zaXN0cyBvbiBlbnRpcmVseSBjbGVhcnRleHQgaGFuZHNoYWtlIGRhdGEsIHRoYXQg d2lsbCBiZSBpbiBkaXJlY3Qgb3Bwb3NpdGlvbiB0byBvbmUgb2YgdGhlIHR3byBtYWpvciBwcm9u Z3Mgb2YgdGhlIFRMUyBjaGFydGVyLg0KDQooYXMgYW4gYXNpZGUsIGl0IHdvdWxkIGJlIG5pY2Ug dG8gZ2V0IHNvbWUgY3J5cHRhbmFseXRpYyByZXZpZXcgb2YgYW55IGNvbmZpZGVudGlhbGl0eS9p bnRlZ3JpdHkgd2UgYXR0ZW1wdCB0byBwcm92aWRlIGZvciB0aGUgaGFuZHNoYWtlIG1hdGVyaWFs IGl0c2VsZiwgdGhvdWdoIGkgdW5kZXJzdGFuZCB0aGlzIG1heSBiZSBhIHNlcGFyYXRlIHF1ZXN0 aW9uIGZyb20gdGhlIGNvbmZpZGVudGlhbGl0eS9pbnRlZ3JpdHkgZ3VhcmFudGVlcyB3ZSBzdHJp dmUgZm9yIGluIHRoZSBhcHBsaWNhdGlvbiBkYXRhKQ0KDQpSZWdhcmRzLA0KDQoJLS1ka2cNCg== From nobody Wed Sep 10 07:19:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 058EA1A00D1 for ; Wed, 10 Sep 2014 07:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mH3BsCZUuBTw for ; Wed, 10 Sep 2014 07:19:34 -0700 (PDT) Received: from mail-pa0-x22a.google.com (mail-pa0-x22a.google.com [IPv6:2607:f8b0:400e:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BC531A02D7 for ; Wed, 10 Sep 2014 07:19:34 -0700 (PDT) Received: by mail-pa0-f42.google.com with SMTP id lj1so6445211pab.29 for ; Wed, 10 Sep 2014 07:19:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=tzGM3COO1A9sdB0du9NfN886rnzz75E0dU5sJyfWsk0=; b=Ni807BlMTzoeXycHA7SkulwKhtz99K1VMtarLrVapt5KpF5tbqtYPMzf1A2zeUHM68 1IRQyKQ+eu6kykT1JYqNyOzFS/20XAW7/qc6JIDd/BYmy8TKDDnc6v2JuHYCbQY1c+6T tWFGfqIsgV9c2VPM+q5BtQr2jQgkqkH/8qQX8LK8q9+9YJIt+oWfqO3Ed3YZ+uQ+Ft0R gBkLcZcU7hF3qcDZd3IwXS4cfrEoJ5EuA1DQK5OpkmFgQl3gOJrGB//MIDUsl9vyw9dT pG0fFGSdxlEFnyaE3LveAwWSEZ6hJ7SEACNp2UXi5/LfRQM6LXVQfF6t0A/LpDCJ94AV IEow== X-Received: by 10.66.186.167 with SMTP id fl7mr65671312pac.14.1410358774284; Wed, 10 Sep 2014 07:19:34 -0700 (PDT) Received: from [17.244.46.100] ([17.244.46.100]) by mx.google.com with ESMTPSA id aj3sm14630469pbc.92.2014.09.10.07.19.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Sep 2014 07:19:32 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Fabrice X-Mailer: iPhone Mail (12A365) In-Reply-To: Date: Wed, 10 Sep 2014 07:19:31 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <820915CA-29BE-4274-92C2-45688AA1F6E0@gmail.com> References: <5409E00D.1070703@fifthhorseman.net> To: Markulf Kohlweiss Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2VJdocJSQW3hBEVz2Cgk_qCEBd0 Cc: "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 10 Sep 2014 14:19:36 -0000 > On Sep 10, 2014, at 03:55, Markulf Kohlweiss wrote= : >=20 > Hi Daniel, >=20 > Thanks a lot for the discussion.=20 >=20 > 1) We should be very clear about what should be done by TLS and what by ap= plication protocols, and how the two interact. A good example for this are C= hannel ID and Token Binding. Thus our call for standardizing a TLS API. Regarding that specific point: Is the IETF an appropriate forum to standardi= ze APIs, and has it successfully done so in other areas? I'm also curious in what form a standard API would be defined, and how far y= ou would go in standardizing it.=20 For example, would you have the API specify how the data flow between the "c= onnection", the TLS implementation and the application, or would you limit t= his API to interactions between the handshake implementation and the applica= tion ? -- Fabrice= From nobody Wed Sep 10 09:07:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424141A8764 for ; Wed, 10 Sep 2014 09:07:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JRkE5uqVOFZC for ; Wed, 10 Sep 2014 09:07:32 -0700 (PDT) Received: from mail-yh0-x234.google.com (mail-yh0-x234.google.com [IPv6:2607:f8b0:4002:c01::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF0A61A876A for ; Wed, 10 Sep 2014 09:07:32 -0700 (PDT) Received: by mail-yh0-f52.google.com with SMTP id f73so2291093yha.11 for ; Wed, 10 Sep 2014 09:07:32 -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 :content-type; bh=07zR08gCup5MdHj/w35fG9B8jcsswwuB/4ZbsAQVEqk=; b=RciVTCrkM/R8b8VmCgfhAeqcaY4iQQaEnNysvWepzI06xDXxsEGU5uU58ryFJ5gFv0 6PWqvWYhyBrSiFeMTfRS4yAdydcTb9Q1VyvXHxOK1BjO04Rw0mAQWHa1A3ImNgZxQftc vRbLDkkUklKs/pBhawI7bqMCt452G3MRfxBPCzYwrpynIdy1J0gXIXSeDCGtEYoZGGT3 KVCkypGywdJDpayb14Hq73V92JROoLKL/J7U7JPePTQK8z+Y+jMxsdjDdDXZsnWtbK2v UGyaOZtHR9rk+MEDbJAvp65X2hh+uLjr16SEMh6iSgSHcFggIFK5ht6iitSYrCakFsfD 3h1g== MIME-Version: 1.0 X-Received: by 10.236.147.34 with SMTP id s22mr1208235yhj.172.1410365252071; Wed, 10 Sep 2014 09:07:32 -0700 (PDT) Received: by 10.170.207.216 with HTTP; Wed, 10 Sep 2014 09:07:32 -0700 (PDT) Received: by 10.170.207.216 with HTTP; Wed, 10 Sep 2014 09:07:32 -0700 (PDT) In-Reply-To: References: Date: Wed, 10 Sep 2014 09:07:32 -0700 Message-ID: From: Watson Ladd To: tls@ietf.org Content-Type: multipart/alternative; boundary=20cf303a337dda761b0502b83f42 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/d2gTGqfCj_kxcxhX0TTvKWIw9xc Subject: Re: [TLS] [tls13-spec] Require support for compressed point format (#80) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 10 Sep 2014 16:07:40 -0000 --20cf303a337dda761b0502b83f42 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Sep 10, 2014 8:50 AM, "Henrik Grubbstr=C3=B6m (Grubba)" < notifications@github.com> wrote: > > AFAIK the compressed format has issues with patents (eg US patent 6141420 and US patent 6252960) and is not supported by some ECC-libraries. > > Note though that according to djb those patents are likely to be invalid = ( http://cr.yp.to/ecdh/patents.html). They expired a month ago iirc. > > Note also that it is the uncompressed format that is the required format in RFC 4492. Because of the patents. There are security issues I have exploited in software that result from use of an uncompressed format. > > =E2=80=94 > Reply to this email directly or view it on GitHub. --20cf303a337dda761b0502b83f42 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sep 10, 2014 8:50 AM, "Henrik Grubbstr=C3=B6m (Grubba)" <notifications@github.com> = wrote:
>
> AFAIK the compressed format has issues with patents (eg US patent 6141= 420 and US patent 6252960) and is not supported by some ECC-libraries.
>
> Note though that according to djb those patents are likely to be inval= id (http://cr.yp.to/ecdh/pate= nts.html).

They expired a month ago iirc.
>
> Note also that it is the uncompressed format that is the required form= at in RFC 4492.

Because of the patents. There are security issues I have exp= loited in software that result from use of an uncompressed format.
>
> =E2=80=94
> Reply to this email directly or view it on GitHub.

--20cf303a337dda761b0502b83f42-- From nobody Wed Sep 10 09:19:10 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 730C91A8764 for ; Wed, 10 Sep 2014 09:19:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 48ylJDEwaJ_g for ; Wed, 10 Sep 2014 09:19:07 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0743.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:743]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCE741A88CE for ; Wed, 10 Sep 2014 09:19:06 -0700 (PDT) Received: from BY2PR03CA041.namprd03.prod.outlook.com (10.141.249.14) by BY2PR0301MB0760.namprd03.prod.outlook.com (25.160.63.24) with Microsoft SMTP Server (TLS) id 15.0.1019.16; Wed, 10 Sep 2014 16:18:44 +0000 Received: from BY2FFO11FD060.protection.gbl (2a01:111:f400:7c0c::196) by BY2PR03CA041.outlook.office365.com (2a01:111:e400:2c5d::14) with Microsoft SMTP Server (TLS) id 15.0.1024.12 via Frontend Transport; Wed, 10 Sep 2014 16:18:43 +0000 Received: from mail.microsoft.com (131.107.125.37) by BY2FFO11FD060.mail.protection.outlook.com (10.1.15.184) with Microsoft SMTP Server (TLS) id 15.0.1019.14 via Frontend Transport; Wed, 10 Sep 2014 16:18:43 +0000 Received: from 064-smtp-out.microsoft.com (141.251.33.15) by TK5EX14HUBC107.redmond.corp.microsoft.com (157.54.80.67) with Microsoft SMTP Server (TLS) id 14.3.195.2; Wed, 10 Sep 2014 16:18:27 +0000 Received: from AMSPRD3001MB017.064d.mgd.msft.net ([169.254.8.57]) by AMSPRD3001HT002.064d.mgd.msft.net ([141.251.33.15]) with mapi id 14.16.0466.000; Wed, 10 Sep 2014 16:18:24 +0000 From: Markulf Kohlweiss To: Fabrice Thread-Topic: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] Thread-Index: AQHPzQJuUdyFbomVM0iZeFx5dppDY5v6hYXA Date: Wed, 10 Sep 2014 16:18:24 +0000 Message-ID: References: <5409E00D.1070703@fifthhorseman.net> <820915CA-29BE-4274-92C2-45688AA1F6E0@gmail.com> In-Reply-To: <820915CA-29BE-4274-92C2-45688AA1F6E0@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [141.251.33.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019019)(6009001)(438002)(24454002)(51704005)(199003)(189002)(13464003)(20776003)(26826002)(21056001)(4396001)(33656002)(47776003)(85852003)(66066001)(92566001)(46102001)(2656002)(84676001)(64706001)(80022001)(86146001)(77096002)(15975445006)(86612001)(23726002)(87936001)(77982001)(92726001)(110136001)(68736004)(6806004)(69596002)(81156004)(81542001)(44976005)(97756001)(54356999)(31966008)(19580395003)(83322001)(19580405001)(99396002)(90102001)(50986999)(85306004)(93886004)(16796002)(76176999)(74502001)(106466001)(74662001)(50466002)(46406003)(79102001)(107046002)(76482001)(55846006)(83072002)(86362001)(106116001)(97736003)(95666004)(81342001); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR0301MB0760; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 033054F29A Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=markulf@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AVFysDO5zHNBcrNbPMGX9Abm8Q4 Cc: "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 10 Sep 2014 16:19:09 -0000 Short answer: I don't know. Long answer:=20 API's are standardized for cryptographic primitives, though maybe not syste= matically, and what the inputs and outputs of an algorithm are may seem obv= ious. The most explicit check for this are test vectors. I would be a big f= an of formal security definitions for primitives in standards. There is a recommendation document for the secure use of TLS: https://tools= .ietf.org/html/draft-ietf-uta-tls-bcp-02 . A good API would attempt to enforce the UTA guidelines unless the applicati= on insists otherwise. --Markulf -----Original Message----- From: Fabrice [mailto:fabrice.gautier@gmail.com]=20 Sent: 10 September 2014 15:20 To: Markulf Kohlweiss Cc: Daniel Kahn Gillmor; tls@ietf.org Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [= was: Re: Simplifying the proof] > On Sep 10, 2014, at 03:55, Markulf Kohlweiss wrot= e: >=20 > Hi Daniel, >=20 > Thanks a lot for the discussion.=20 >=20 > 1) We should be very clear about what should be done by TLS and what by a= pplication protocols, and how the two interact. A good example for this are= Channel ID and Token Binding. Thus our call for standardizing a TLS API. Regarding that specific point: Is the IETF an appropriate forum to standard= ize APIs, and has it successfully done so in other areas? I'm also curious in what form a standard API would be defined, and how far = you would go in standardizing it.=20 For example, would you have the API specify how the data flow between the "= connection", the TLS implementation and the application, or would you limit= this API to interactions between the handshake implementation and the appl= ication ? -- Fabrice From nobody Wed Sep 10 09:21:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0950E1A88D2 for ; Wed, 10 Sep 2014 09:21:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCTNg5bLEBVj for ; Wed, 10 Sep 2014 09:21:48 -0700 (PDT) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC4C31A88CE for ; Wed, 10 Sep 2014 09:21:48 -0700 (PDT) Received: by mail-pa0-f43.google.com with SMTP id fa1so7298204pad.16 for ; Wed, 10 Sep 2014 09:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=lwlNOKUfyfeKknT7XGbNFq+fARDJsw9ljx8jGSAKE9A=; b=D2Aeu2BG2PmbzPos39BX1Q85eXD/sqDgP8fGyEuHwTtRM2Et3AqXbmHCX5gxY2z1+P CNblz1OaBosNHu+9NUDAAkrc1q/5qIzPfb1hTLgEKTRCBZuzC0hurd7gdzXg7q5tjEXO Bsmn172Y73mYyOUMCL2qQzTSIJhai1W326IYa1jeGnSI1Cpi6q2vVcVBXgSl1mBEsj5H w5mTZCUcBQQHKpvBNUqTxVb7891rUz2/T0Crt0jZV2hIHcYibtW3ckQ6W0w6froGD7N/ bQYjJsuPHr2dbSHj/2Wo23Gyg//r9y+qaRqY7HAsdBcFiOHEJSgxuyGLoapws11p2AtZ 3Z8A== MIME-Version: 1.0 X-Received: by 10.68.219.102 with SMTP id pn6mr40315632pbc.135.1410366108517; Wed, 10 Sep 2014 09:21:48 -0700 (PDT) Received: by 10.70.39.5 with HTTP; Wed, 10 Sep 2014 09:21:48 -0700 (PDT) Date: Wed, 10 Sep 2014 09:21:48 -0700 Message-ID: From: Peter Bowen To: "tls@ietf.org" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vEHPsBMhE5Sz5jOIi3wBv3V8M3E Subject: [TLS] signature_algorithms extension definition X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 10 Sep 2014 16:21:50 -0000 The TLS 1.2 RFC is a little ambiguous on the meaning of the contents of the signature_algorithms extension when included in a ClientHello message. It says "pairs [which] may be used in digital signatures" and "pair[s] that the client is willing to verify". Later on it says "If the client provided a 'signature_algorithms' extension, then all certificates provided by the server MUST be signed by a hash/signature algorithm pair that appears in that extension." What is unclear is whether the client MUST be willing and able to verify _certificates_ signed with any of the pairs that it specifies. There are popular clients that support one set of pairs for signing TLS messages (digitally-signed structs) but that support a different set for signing certificates. For example, they support sha256/rsa and sha1/rsa for TLS signing but only sha1/rsa for certificate signing. Is the intent that a peer which sends the signature_algorithms extension must be willing to validate certificates signatures using any of the pairs in the extension? If not, should TLS 1.3 add a flag to indicate which pairs are valid for which types of signatures? Thanks, Peter From nobody Wed Sep 10 09:32:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08B21A89F9 for ; Wed, 10 Sep 2014 09:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmbnTJ7dxTEK for ; Wed, 10 Sep 2014 09:32:06 -0700 (PDT) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9AD501A8A08 for ; Wed, 10 Sep 2014 09:32:06 -0700 (PDT) Received: by mail-qc0-f171.google.com with SMTP id x3so19707914qcv.16 for ; Wed, 10 Sep 2014 09:32:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=DQt5Ao18i7y8ui6re7tz+LucKTqfI6rBYFSCbU+fOmY=; b=j/ncd4FMlY4CrZtYOIHwJDNO/Iv/QqtsJ7SDIjEyqyboen41liFQVvEZToDHTb2uwE lnI3j6iYDGWmQI9cDiq8Z3N8PKidF1AhKEij3XRRX8O/xuEAWihXGL9916a996GH3m61 LpVCte1pLShE0DwVn3n5CetRjSskz4MMJm+7LtKw/vQ1bv0vOvqAz6KdavS/hKXGuNsY Chad7x+bAkC7ORGoQBnrnQekDe8xN8HasVcBnO8TEkQNzLzbDQhWXQRvFShCstP4z1yn Nkaqmj6Uvc2WK7tPQjJUFUtJpF/R76QV3uymV1OXuRbi4IvoQNftw01W8uJPiVIDPcH7 5QOg== X-Gm-Message-State: ALoCoQm5T/eZwQj6G9hWNTu2Yy1i11AwQlfEdSEUgRk7PYq30P19F2FKpZaeFekWvn1iJgyxeKe3 MIME-Version: 1.0 X-Received: by 10.140.38.114 with SMTP id s105mr4799643qgs.4.1410366725740; Wed, 10 Sep 2014 09:32:05 -0700 (PDT) Received: by 10.224.67.133 with HTTP; Wed, 10 Sep 2014 09:32:05 -0700 (PDT) In-Reply-To: References: Date: Wed, 10 Sep 2014 09:32:05 -0700 Message-ID: From: Brian Smith To: "" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2eeAHickua7fmnVTm-VQh4ydZBQ Subject: Re: [TLS] signature_algorithms extension definition X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 10 Sep 2014 16:32:07 -0000 On Wed, Sep 10, 2014 at 9:21 AM, Peter Bowen wrote: > What is unclear is whether the client MUST be willing and able to > verify _certificates_ signed with any of the pairs that it specifies. Effectively, yes, it should, because the server is allowed to choose certificates that use any of the signature algorithms listed. If the algorithm list in signature_algorithms is misleading, then the client risks interoperability issues. In practice, a client should list only algorithms that it supports for BOTH the ServerKeyExchange message AND certificates. > Is the intent that a peer which sends the signature_algorithms > extension must be willing to validate certificates signatures using > any of the pairs in the extension? If not, should TLS 1.3 add a flag > to indicate which pairs are valid for which types of signatures? This is already a known issue. My idea is to have a certificate_signature_algorithms extension, with the same syntax as signature_algorithms. When certificate_signature_algorithms is present in the ClientHello, the algorithms in signature_algorithms are only for the ServerKeyExchange signature, and the algorithms in certificate_signature_algorithms are used for certificates. When certificate_signature_algorithms is missing, then the server uses signature_algorithms for both. This way, only the clients actually affected by this issue need to do any new work. Cheers, Brian From nobody Wed Sep 10 09:43:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729F81A8A07 for ; Wed, 10 Sep 2014 09:43:13 -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=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X6JIAq-6PyQS for ; Wed, 10 Sep 2014 09:43:11 -0700 (PDT) Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B68B41A8A0B for ; Wed, 10 Sep 2014 09:43:10 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id em10so2387809wid.5 for ; Wed, 10 Sep 2014 09:43:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=0yNiBEB18HgzgYwxqU2klCSc2ytJK0ttf3USAAbnwZY=; b=izOWR2Wzns7OevBAt98X9fWAlrOnuj/5UvupimBJT5nC5ARKU202keYb2B4CjWGxjm k2IoCimqjRTdT33Mv3chFYzh9YlqxzRACEgTuPbJJUW2M5rUTTHryacrTGRsnPL+rr5a OBSCe2xwTalM6hC8L/b7tF+ffKqu8Oyy87gJE3+CYir2YI6GTc0WNmvYQFDQF3CZh7d4 5zoZyfu4YONby+X8DCNTD5II7YgVOtXI5qvK84mHI5xqoM4EmLKKuSBd9X/3NmqK0VNf fabcBNQayIhgJC+qOTxc9cqY0oV3w14IPM/RTe4aNX7ObKHBhsISb+tjx4/R54g63v0S LfcQ== X-Gm-Message-State: ALoCoQmkqeGFlJYBc4Bwz/o0HDDp1e/E6fWCLSeqNXdZcymqjJs214Qh5rMJE2mRvwqtJHST+85P X-Received: by 10.194.59.244 with SMTP id c20mr50940149wjr.59.1410367389119; Wed, 10 Sep 2014 09:43:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.146.194 with HTTP; Wed, 10 Sep 2014 09:42:29 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 10 Sep 2014 09:42:29 -0700 Message-ID: To: Peter Bowen Content-Type: multipart/alternative; boundary=047d7ba977e83b4ca50502b8bf09 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/n2CpItluwbpiJu9GjnolfTVN2pE Cc: "tls@ietf.org" Subject: Re: [TLS] signature_algorithms extension definition X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 10 Sep 2014 16:43:13 -0000 --047d7ba977e83b4ca50502b8bf09 Content-Type: text/plain; charset=UTF-8 On Wed, Sep 10, 2014 at 9:21 AM, Peter Bowen wrote: > The TLS 1.2 RFC is a little ambiguous on the meaning of the contents > of the signature_algorithms extension when included in a ClientHello > message. It says "pairs [which] may be used in digital signatures" > and "pair[s] that the client is willing to verify". Later on it says > "If the client provided a 'signature_algorithms' extension, then all > certificates provided by the server MUST be signed by a hash/signature > algorithm pair that appears in that extension." > > What is unclear is whether the client MUST be willing and able to > verify _certificates_ signed with any of the pairs that it specifies. > There are popular clients that support one set of pairs for signing > TLS messages (digitally-signed structs) but that support a different > set for signing certificates. For example, they support sha256/rsa > and sha1/rsa for TLS signing but only sha1/rsa for certificate > signing. > Yes. > Is the intent that a peer which sends the signature_algorithms > extension must be willing to validate certificates signatures using > any of the pairs in the extension? If not, should TLS 1.3 add a flag > to indicate which pairs are valid for which types of signatures? > I'd be interested in hearing if this is a problem for a significant number of clients. -Ekr > > --047d7ba977e83b4ca50502b8bf09 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Sep 10, 2014 at 9:21 AM, Peter Bowen <pzbowen@gmail.com>= ; wrote:
The TLS 1.2 RFC is a litt= le ambiguous on the meaning of the contents
of the signature_algorithms extension when included in a ClientHello
message.=C2=A0 It says "pairs [which] may be used in digital signature= s"
and "pair[s] that the client is willing to verify".=C2=A0 Later o= n it says
"If the client provided a 'signature_algorithms' extension, th= en all
certificates provided by the server MUST be signed by a hash/signature
algorithm pair that appears in that extension."

What is unclear is whether the client MUST be willing and able to
verify _certificates_ signed with any of the pairs that it specifies.
There are popular clients that support one set of pairs for signing
TLS messages (digitally-signed structs) but that support a different
set for signing certificates.=C2=A0 For example, they support sha256/rsa and sha1/rsa for TLS signing but only sha1/rsa for certificate
signing.

Yes.

= =C2=A0
Is the intent that a peer which sends the signature_algorithms
extension must be willing to validate certificates signatures using
any of the pairs in the extension?=C2=A0 If not, should TLS 1.3 add a flag<= br> to indicate which pairs are valid for which types of signatures?

I'd be interested in hearing if this is a pro= blem for a significant number of
clients.

-Ekr

--047d7ba977e83b4ca50502b8bf09-- From nobody Wed Sep 10 09:47:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A79D1A8A7D for ; Wed, 10 Sep 2014 09:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XMjWX0T5V893 for ; Wed, 10 Sep 2014 09:47:55 -0700 (PDT) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B99051A8A7B for ; Wed, 10 Sep 2014 09:47:55 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id x12so17494997qac.6 for ; Wed, 10 Sep 2014 09:47:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=7FAsnZEZXkcRmb/gFFzzuxpZia211xIY7Nrg8ehxcqw=; b=TCKg4pxMmv36vFmXmZUUfk1EsKc96xHXee9+yOUSqLo8nvDE4htqWEBJGGfX5KTG63 hL6CeewYQ8RI5HgB1pmuRa+SRc3vNO0vZF9SUzXRtj7bItXAOHIGdl2SdpVngSoFGWUJ WKk2R4dJ3WsbbPtrNu2yqmdO/SFZZ3dClbh5DiQ4GljIUV6XcIk0B6hgF9Vpa+qNtIYa jgmRF4YDt6pwBBukUpjvL2CZaBpBDxF2OPxvNIH6w2GP9eAvHPPMBGRKOEcgJ0X00aTm k78HCKxmNLKGr57nms74Se2O4ADc7bThdtovpNE+ZeVfLKdU0MRDWzFMVCypXveCvKAy B7Eg== X-Gm-Message-State: ALoCoQkmzOYNm7cT1Db5au0+9OOJhnGF9CyCPKFlcbyxNtud0ZoDz+dNXPDSM+pe2PIJcOVMQZcw X-Received: by 10.140.47.108 with SMTP id l99mr31179066qga.45.1410367674800; Wed, 10 Sep 2014 09:47:54 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:344:75b6:a881:65fb:420d? ([2601:a:2a00:344:75b6:a881:65fb:420d]) by mx.google.com with ESMTPSA id a17sm12712465qgf.12.2014.09.10.09.47.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Sep 2014 09:47:54 -0700 (PDT) Message-ID: <541080BD.8030306@nthpermutation.com> Date: Wed, 10 Sep 2014 12:47:57 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tls@ietf.org References: <5409E00D.1070703@fifthhorseman.net> <820915CA-29BE-4274-92C2-45688AA1F6E0@gmail.com> In-Reply-To: <820915CA-29BE-4274-92C2-45688AA1F6E0@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/bsVT5RGGoHgdSklqw5AvAQZZguM Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 10 Sep 2014 16:47:57 -0000 On 9/10/2014 10:19 AM, Fabrice wrote: >> On Sep 10, 2014, at 03:55, Markulf Kohlweiss wrote: >> >> Hi Daniel, >> >> Thanks a lot for the discussion. >> >> 1) We should be very clear about what should be done by TLS and what by application protocols, and how the two interact. A good example for this are Channel ID and Token Binding. Thus our call for standardizing a TLS API. > Regarding that specific point: Is the IETF an appropriate forum to standardize APIs, and has it successfully done so in other areas? > > I'm also curious in what form a standard API would be defined, and how far you would go in standardizing it. *IF* we do this, I'd recommend using the model from the original TCP documents. They specified a service interface above and a required service interface below without getting into system specific "API"s See specifically section 3.8 of RFC793. Note that it describes BOTH interfaces - the one used by applications to talk to TCP, and the minimum one needed by TCP to talk to the LLP (in this case IP). > > For example, would you have the API specify how the data flow between the "connection", the TLS implementation and the application, or would you limit this API to interactions between the handshake implementation and the application ? > > -- Fabrice > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Wed Sep 10 09:48:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D2C41A88D0 for ; Wed, 10 Sep 2014 09:48:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, LOTS_OF_MONEY=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6uBGsY8YzTYY for ; Wed, 10 Sep 2014 09:48:21 -0700 (PDT) Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 428B31A01F2 for ; Wed, 10 Sep 2014 09:48:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:To:MIME-Version:From:Date:Message-ID; bh=9+VKOeAOjpnxmwC5H+WfF69rK23WREdWXjYO8LXYrnQ=; b=gaDflMiuJhyNKjTrJgc5Ojvw7bOG8b879KWjyMu8rjjJSy8WIRwBjOrkl29ldx5Jn8kl1aLRS0Pnsl/k2fnZi6sCroday55uOgLrcp6MMUB4mtfaIR248RrHC5RluBFdvFzcP2O1YqKTN/mubQwUVW1ml4t2ods5C8IKZTVLtrM=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XRl46-0007Fk-Hk; Wed, 10 Sep 2014 18:48:18 +0200 Message-ID: <541080C5.50806@polarssl.org> Date: Wed, 10 Sep 2014 18:48:05 +0200 From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.0 MIME-Version: 1.0 To: Watson Ladd , tls@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.offspark.com) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xAQofLEzzxuMgjIwZsR9MVmgvLs Subject: Re: [TLS] [tls13-spec] Require support for compressed point format (#80) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 10 Sep 2014 16:48:22 -0000 On 10/09/2014 18:07, Watson Ladd wrote: > On Sep 10, 2014 8:50 AM, "Henrik Grubbstrm (Grubba)" < > notifications@github.com> wrote: >> >> AFAIK the compressed format has issues with patents (eg US patent 6141420 >> and US patent 6252960) and is not supported by some ECC-libraries. > > They expired a month ago iirc. The first one [1] expired a month ago. The second one [2] expires in 4 years, but describes a different method of point compression that the one used in TLS (and PKIX). TLS uses the full X coordinate plus one bit of Y, while the goal of the second patent is to get rid of that bit of Y by reusing a redundant bit of the encoding of X. [1] https://www.google.com/patents/US6141420 [2] https://www.google.com/patents/US6252960 > Because of the patents. There are security issues I have exploited in > software that result from use of an uncompressed format. Is that just invalid curve attacks due to the implementation failing to check that the point is on the expected curve, or are there other kind of attacks that rely on uncompressed format? Manuel. From nobody Wed Sep 10 09:57:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCFCB1A9125 for ; Wed, 10 Sep 2014 09:57:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VenclFna99JC for ; Wed, 10 Sep 2014 09:57:56 -0700 (PDT) Received: from mail-pd0-x236.google.com (mail-pd0-x236.google.com [IPv6:2607:f8b0:400e:c02::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B8A71A911E for ; Wed, 10 Sep 2014 09:57:56 -0700 (PDT) Received: by mail-pd0-f182.google.com with SMTP id w10so6647523pde.41 for ; Wed, 10 Sep 2014 09:57:56 -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=oHn3zGhsEQO28w8mdKOx822ONkKWb5h8yLpKebHd3jc=; b=e7+29f3NOF2KuxNLTCBLVxF38dCgulEAb8In08dBNln2tTC3EMDwW6E39mUAQ6HXdP B0nRQY7EVZOtITciKO13xnaVIqqALVc23AhgiFF03l8njuJGjpJXpEES/RYx5iGQTL0t N3foQI68/2OOcwAUUMHF0zSJ6wUZMB9VqD6dvpzD59iPpIS9GMDHtCyJtm96itjeU8oa y8A0GtT6QgwHlz06ijruaVlRtZex3qU1OW4iog6/N5erOOH0UsZUMmTyuNO9yhetnHUh CzxreocHmTbyzoRwaVB0J+wxcuLfu6mY6PT/GXN/cdBo5oVmD1nIqYzRR/52fVe5kvkF z99w== MIME-Version: 1.0 X-Received: by 10.70.53.65 with SMTP id z1mr69159192pdo.74.1410368276178; Wed, 10 Sep 2014 09:57:56 -0700 (PDT) Received: by 10.70.39.5 with HTTP; Wed, 10 Sep 2014 09:57:56 -0700 (PDT) In-Reply-To: References: Date: Wed, 10 Sep 2014 09:57:56 -0700 Message-ID: From: Peter Bowen To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZHOcFiuP6FXBTcJLWiza_ZCZYM0 Cc: "tls@ietf.org" Subject: Re: [TLS] signature_algorithms extension definition X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 10 Sep 2014 16:57:58 -0000 On Wed, Sep 10, 2014 at 9:42 AM, Eric Rescorla wrote: > On Wed, Sep 10, 2014 at 9:21 AM, Peter Bowen wrote: >> What is unclear is whether the client MUST be willing and able to >> verify _certificates_ signed with any of the pairs that it specifies. >> There are popular clients that support one set of pairs for signing >> TLS messages (digitally-signed structs) but that support a different >> set for signing certificates. For example, they support sha256/rsa >> and sha1/rsa for TLS signing but only sha1/rsa for certificate >> signing. > > Yes. > >> Is the intent that a peer which sends the signature_algorithms >> extension must be willing to validate certificates signatures using >> any of the pairs in the extension? If not, should TLS 1.3 add a flag >> to indicate which pairs are valid for which types of signatures? > > I'd be interested in hearing if this is a problem for a significant number > of clients. Google Chrome/Chromium is one notable client. It uses an internal TLS implementation but uses the OS crypto stack for certificate validation, resulting in situations where different algorithm pairs are supported in different contexts. Thanks, Peter From nobody Wed Sep 10 10:01:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA7571A913D for ; Wed, 10 Sep 2014 10:01:51 -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=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXjqqiSeDmHV for ; Wed, 10 Sep 2014 10:01:46 -0700 (PDT) Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 67D261A9136 for ; Wed, 10 Sep 2014 10:01:46 -0700 (PDT) Received: by mail-wg0-f49.google.com with SMTP id m15so4783783wgh.8 for ; Wed, 10 Sep 2014 10:01:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Bnl10MdaFOOOk4CaGY1vrM7/+PmRToD60IN3x4tK128=; b=cgmJH1V5PY90LRC5jfM8EMVsUfGcKS7my7+s0I919i8g/AtFOV99r0L/QDbB27rYXS 5Htvg3Smskzo+UWpL1cVK5HkWxC8uz4FDaCDPsAg3ufoXLUcUaHxwNrycy+5kPZA6LYG 2moms74SOhlk7IacCL1fcVpCCBhkBYQYceZXQyL1D0Wcf0Mu3TTodjghk5HFHsUpoO89 Ewidy08KiNhNRtC41qt5A7p3G1BLS6xM6B1dWYdJAR+ZjZ4AYE7pmONa3lhKF0w6+s8V e9gbmOOAORkIO+rB2FhwynaC25sf2tV0mSgWFTDTA6PcUEnf2yV+oByaBfT4x+Tmsob9 548Q== X-Gm-Message-State: ALoCoQmGUJ7fqKB0ZiI1gaFxr5WhiUhkOAAt6ecJikqtUEkDHXCIXdkr/+/601KozWof8/+8j7ON X-Received: by 10.194.185.81 with SMTP id fa17mr4497531wjc.114.1410368505070; Wed, 10 Sep 2014 10:01:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.146.194 with HTTP; Wed, 10 Sep 2014 10:01:05 -0700 (PDT) In-Reply-To: References: From: Eric Rescorla Date: Wed, 10 Sep 2014 10:01:05 -0700 Message-ID: To: Peter Bowen Content-Type: multipart/alternative; boundary=047d7bae4956bf572f0502b90143 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Z6X6tdDZP9HOaouKTIeqi9Tk2Zk Cc: "tls@ietf.org" Subject: Re: [TLS] signature_algorithms extension definition X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 10 Sep 2014 17:01:51 -0000 --047d7bae4956bf572f0502b90143 Content-Type: text/plain; charset=UTF-8 On Wed, Sep 10, 2014 at 9:57 AM, Peter Bowen wrote: > On Wed, Sep 10, 2014 at 9:42 AM, Eric Rescorla wrote: > > On Wed, Sep 10, 2014 at 9:21 AM, Peter Bowen wrote: > >> What is unclear is whether the client MUST be willing and able to > >> verify _certificates_ signed with any of the pairs that it specifies. > >> There are popular clients that support one set of pairs for signing > >> TLS messages (digitally-signed structs) but that support a different > >> set for signing certificates. For example, they support sha256/rsa > >> and sha1/rsa for TLS signing but only sha1/rsa for certificate > >> signing. > > > > Yes. > > > >> Is the intent that a peer which sends the signature_algorithms > >> extension must be willing to validate certificates signatures using > >> any of the pairs in the extension? If not, should TLS 1.3 add a flag > >> to indicate which pairs are valid for which types of signatures? > > > > I'd be interested in hearing if this is a problem for a significant > number > > of clients. > > Google Chrome/Chromium is one notable client. It uses an internal TLS > implementation but uses the OS crypto stack for certificate > validation, resulting in situations where different algorithm pairs > are supported in different contexts. Hmm... It seems like Chrome could just offer the intersection of the algorithms, as NSS/OpenSSL will generally have a superset of the OS algorithms. -Ekr --047d7bae4956bf572f0502b90143 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Sep 10, 2014 at 9:57 AM, Peter Bowen <pzbowen@gmail.com>= ; wrote:
On Wed, = Sep 10, 2014 at 9:42 AM, Eric Rescorla <= ekr@rtfm.com> wrote:
> On Wed, Sep 10, 2014 at 9:21 AM, Peter Bowen <pzbowen@gmail.com> wrote:
>> What is unclear is whether the client MUST= be willing and able to
>> verify _certificates_ signed with any of the pairs that it specifi= es.
>> There are popular clients that support one set of pairs for signin= g
>> TLS messages (digitally-signed structs) but that support a differe= nt
>> set for signing certificates.=C2=A0 For example, they support sha2= 56/rsa
>> and sha1/rsa for TLS signing but only sha1/rsa for certificate
>> signing.
>
> Yes.
>
>> Is the intent that a peer which sends the signature_algorithms
>> extension must be willing to validate certificates signatures usin= g
>> any of the pairs in the extension?=C2=A0 If not, should TLS 1.3 ad= d a flag
>> to indicate which pairs are valid for which types of signatures? >
> I'd be interested in hearing if this is a problem for a significan= t number
> of clients.

Google Chrome/Chromium is one notable client.=C2=A0 It uses an inter= nal TLS
implementation but uses the OS crypto stack for certificate
validation, resulting in situations where different algorithm pairs
are supported in different contexts.

Hmm...= It seems like Chrome could just offer the intersection of the algorithms,<= /div>
as NSS/OpenSSL will generally have a superset of the OS algorithm= s.

-Ekr
=C2=A0

--047d7bae4956bf572f0502b90143-- From nobody Wed Sep 10 10:11:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6D211A913A for ; Wed, 10 Sep 2014 10:11:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxttFcCZFayY for ; Wed, 10 Sep 2014 10:10:59 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 819EC1A914E for ; Wed, 10 Sep 2014 10:10:48 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id ge10so756199lab.41 for ; Wed, 10 Sep 2014 10:10:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=wZY5QPxddTQbOQyYFYV7HkoRFOQoZx80eeOHmywu5mE=; b=s+ej28U4jhWKPL4b8h1YHWwNccAkvZYzNbJ0kMm7g6Xf5JfYWOPetsDlJWKITgnxGE 5HzEcBJPnFZFyYW8WqcNMFn7GNDoTItPO/Fk8kyS3ZNDNeAmpaeFnkM3N+JTlvQdlrnX mj9gL4TQBISj0d3679BjKJGSUMnJHf6dMx0E8mRAcfZr5ECBjbKf21a+Ca3ALtgiMF9L xlBxOIy9Y8l5PrUG1G9zd0Fi1bDvFMaGzbRRpGyCFTqhZ7rjqF0atZ7oR0oZC7/OkbgB WjD47jLciq38wpFun3J5K02xL0q5dH+ZRCHbUgFHXDMkhYlyLZQh8BBtSIesFSwPq4hH Mf5g== MIME-Version: 1.0 X-Received: by 10.112.14.33 with SMTP id m1mr41507426lbc.16.1410369046850; Wed, 10 Sep 2014 10:10:46 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.170.37 with HTTP; Wed, 10 Sep 2014 10:10:46 -0700 (PDT) In-Reply-To: References: Date: Wed, 10 Sep 2014 10:10:46 -0700 X-Google-Sender-Auth: _WJJCoW73OlYOTkreCo5Tm8kXAk Message-ID: From: Adam Langley To: Eric Rescorla Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/mDYhpyOogDgYa7dY8IuWYdNmO64 Cc: "tls@ietf.org" Subject: Re: [TLS] signature_algorithms extension definition X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 10 Sep 2014 17:11:01 -0000 On Wed, Sep 10, 2014 at 10:01 AM, Eric Rescorla wrote: > Hmm... It seems like Chrome could just offer the intersection of the > algorithms, > as NSS/OpenSSL will generally have a superset of the OS algorithms. We will. I just didn't realise that the signature_algorithms extension was supposed to apply to more than just the TLS handshake. It's https://code.google.com/p/chromium/issues/detail?id=409901. It *should* be done for Chrome 39. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Wed Sep 10 22:14:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DDCE1A03C8 for ; Wed, 10 Sep 2014 22:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id daAh-BH6PyPn for ; Wed, 10 Sep 2014 22:14:49 -0700 (PDT) Received: from mail-pa0-x233.google.com (mail-pa0-x233.google.com [IPv6:2607:f8b0:400e:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DCFD1A03BB for ; Wed, 10 Sep 2014 22:14:49 -0700 (PDT) Received: by mail-pa0-f51.google.com with SMTP id kx10so9094561pab.24 for ; Wed, 10 Sep 2014 22:14:48 -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=f6mKClNCXAF1RAXhAvijxrm76SEJZaGOzrfK06AQwZ4=; b=xdCqedQwXAR+8lRDw06GD85mGZ0AfPcoFyXvFEqOgERnk/PR5+a8iqzICY/Q8nDKBq fVeuEjFuF62KZmHVSVxsmnIrk5FDRGaq0Bo84iGHyidZvVplmwBtn8/AKvxuUa1armvt X1eRow6zbG3j6K6ZvSQTHWSaRhwjQu2fFpYFFXb4avKn/ktiaU+v9B7hTQ+raP7/aiPn BR578N/6eCeM+ejYWLcpoDEbaWiR/7l7cOLlMQ9YyG9OWNfI9pKAzO811TS2ogmHJSmP YgruXHbBOkU5pQCnFMe8W89yuNOBGehaDsVJxEK6UzTlM8JdrpzcmEzX5LXpcDcaEa/V 1oSQ== MIME-Version: 1.0 X-Received: by 10.68.182.67 with SMTP id ec3mr44318855pbc.74.1410412488715; Wed, 10 Sep 2014 22:14:48 -0700 (PDT) Received: by 10.70.39.5 with HTTP; Wed, 10 Sep 2014 22:14:48 -0700 (PDT) In-Reply-To: References: Date: Wed, 10 Sep 2014 22:14:48 -0700 Message-ID: From: Peter Bowen To: Adam Langley Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/C7M7agXm1RRxMzs-rSRCMeJCbSk Cc: "tls@ietf.org" Subject: Re: [TLS] signature_algorithms extension definition X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 11 Sep 2014 05:14:52 -0000 On Wed, Sep 10, 2014 at 10:10 AM, Adam Langley wrote: > On Wed, Sep 10, 2014 at 10:01 AM, Eric Rescorla wrote: >> Hmm... It seems like Chrome could just offer the intersection of the >> algorithms, >> as NSS/OpenSSL will generally have a superset of the OS algorithms. > > We will. I just didn't realise that the signature_algorithms extension > was supposed to apply to more than just the TLS handshake. Should this get called out in 1.3 to make it clearer? Should there be an erratum for 1.2? From nobody Thu Sep 11 02:16:07 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32F431A0694 for ; Thu, 11 Sep 2014 02:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.553 X-Spam-Level: X-Spam-Status: No, score=-8.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ctY7YHXc2IaU for ; Thu, 11 Sep 2014 02:16:04 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9BEFA1A0666 for ; Thu, 11 Sep 2014 02:16:01 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8B9FxkJ027409 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 11 Sep 2014 05:15:59 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8B9FvGC022431 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 11 Sep 2014 05:15:59 -0400 Message-ID: <1410426957.17386.9.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Peter Bowen Date: Thu, 11 Sep 2014 11:15:57 +0200 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yrkbkBIVaG8nKjOggQB3hZ0GsNY Cc: "tls@ietf.org" Subject: Re: [TLS] signature_algorithms extension definition X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 11 Sep 2014 09:16:05 -0000 On Wed, 2014-09-10 at 09:21 -0700, Peter Bowen wrote: > The TLS 1.2 RFC is a little ambiguous on the meaning of the contents > of the signature_algorithms extension when included in a ClientHello > message. It says "pairs [which] may be used in digital signatures" > and "pair[s] that the client is willing to verify". Later on it says > "If the client provided a 'signature_algorithms' extension, then all > certificates provided by the server MUST be signed by a hash/signature > algorithm pair that appears in that extension." The second sentence is ignored by implementations, as there is no way to enforce it. The server has no way to switch the signatures in his certificates. The certificates are provided by a third party (the CA), which is not participating in the handshake in order to modify the certificates. It would be a good thing if the latter sentence was dropped in the new TLS 1.3 specification, or at least switched to MAY. regards, Nikos From nobody Thu Sep 11 07:26:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9DE1A6F2D for ; Thu, 11 Sep 2014 07:26:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aKH--qK5kBzw for ; Thu, 11 Sep 2014 07:26:54 -0700 (PDT) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 118D01A0AE7 for ; Thu, 11 Sep 2014 07:26:54 -0700 (PDT) Received: by mail-pa0-f45.google.com with SMTP id rd3so9384181pab.4 for ; Thu, 11 Sep 2014 07:26:53 -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=zaeiUOuC3fhGYfCvCCyFIjrm+WcIkSxgX+W02x1fiuM=; b=HAC7QUuG5pGVg1jxHiQtKhB4JRJcG1oQw7VaX32zlKycxnaz5TvDpq2TjCAVKOiI+Q Hs1cKNCVckw1ElAZXUIqnqd1jXHp2HJ4IP7ylGo3vy7Any9quBqc3sBIg6vMHVOqTeHC 9+Mo08PVmwkjj/TBg6YzDpkBH0IH6UqP009OjswmqHZFm6+2Dw9hpgyTl+ZJUnnwvCGx t4HQgs71+RI1ACO+NW1qYzZ5rnu+qAlTiHZbVydLojt+4mRFRGJy/dvQZqC1M5reCwju rsoUQdr/2JSO144AvP+XfTCD79FpXJfsVoK3VNJ0iwtJxkzjVwmTVGWrzibQ9chiw2GB sGcQ== MIME-Version: 1.0 X-Received: by 10.66.196.65 with SMTP id ik1mr2094704pac.154.1410445612932; Thu, 11 Sep 2014 07:26:52 -0700 (PDT) Received: by 10.70.39.5 with HTTP; Thu, 11 Sep 2014 07:26:52 -0700 (PDT) In-Reply-To: <1410426957.17386.9.camel@dhcp-2-127.brq.redhat.com> References: <1410426957.17386.9.camel@dhcp-2-127.brq.redhat.com> Date: Thu, 11 Sep 2014 07:26:52 -0700 Message-ID: From: Peter Bowen To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HUKNJAd4RwI_E8kobC0hKtgNsNQ Cc: "tls@ietf.org" Subject: Re: [TLS] signature_algorithms extension definition X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 11 Sep 2014 14:26:55 -0000 On Thu, Sep 11, 2014 at 2:15 AM, Nikos Mavrogiannopoulos wrote: > On Wed, 2014-09-10 at 09:21 -0700, Peter Bowen wrote: >> The TLS 1.2 RFC is a little ambiguous on the meaning of the contents >> of the signature_algorithms extension when included in a ClientHello >> message. It says "pairs [which] may be used in digital signatures" >> and "pair[s] that the client is willing to verify". Later on it says >> "If the client provided a 'signature_algorithms' extension, then all >> certificates provided by the server MUST be signed by a hash/signature >> algorithm pair that appears in that extension." > > The second sentence is ignored by implementations, as there is no way to > enforce it. The server has no way to switch the signatures in his > certificates. The certificates are provided by a third party (the CA), > which is not participating in the handshake in order to modify the > certificates. It would be a good thing if the latter sentence was > dropped in the new TLS 1.3 specification, or at least switched to MAY. Why do you say it is ignored? This whole extension is critical to implementing certificate agility (multiple certificates for the same name). Agreed the CA is not in the handshake, but the server is and may already have multiple certificates from the CA. Thanks, Peter From nobody Thu Sep 11 07:38:48 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF47B1A6F8C for ; Thu, 11 Sep 2014 07:38:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2fU8O4pOzAW for ; Thu, 11 Sep 2014 07:38:35 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 898C01A6F7F for ; Thu, 11 Sep 2014 07:38:34 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 09F9348550 for ; Thu, 11 Sep 2014 14:38:34 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id E92EF4853A for ; Thu, 11 Sep 2014 14:38:33 +0000 (GMT) Received: from usma1ex-cashub.kendall.corp.akamai.com (usma1ex-cashub7.kendall.corp.akamai.com [172.27.105.23]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id C33F698042 for ; Thu, 11 Sep 2014 14:38:33 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.1.218]) by usma1ex-cashub7.kendall.corp.akamai.com ([172.27.105.23]) with mapi; Thu, 11 Sep 2014 10:38:33 -0400 From: "Salz, Rich" To: "TLS@ietf.org (tls@ietf.org)" Date: Thu, 11 Sep 2014 10:38:32 -0400 Thread-Topic: Which browsers support signature_algorithms? Thread-Index: Ac/NzbD1bLCRSXePSzSwu3U2DursIg== Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D130E9F55@USMBX1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C71D130E9F55USMBX1msgcorp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HYbHkCC5M1PFNHLknYdfif_BqmM Subject: [TLS] Which browsers support signature_algorithms? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 11 Sep 2014 14:38:44 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C71D130E9F55USMBX1msgcorp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My employer will have to support dual-chains for some of our customers who = want to support both current browsers and older embedded devices. We're try= ing to figure out how to know when to present SHA-256 vs SHA-1 cert chain, = and signature_algorithms seems like the cleanest way to do that. Google ho= pes to have it shortly, but what about FF, IE, Opera, etc? Replies to me will be summarized for the list. Thanks. -- Principal Security Engineer, Akamai Technologies IM: rsalz@jabber.me Twitter: RichSalz --_000_2A0EFB9C05D0164E98F19BB0AF3708C71D130E9F55USMBX1msgcorp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

My employer will= have to support dual-chains for some of our customers who want to support = both current browsers and older embedded devices. We’re trying to fig= ure out how to know when to present SHA-256 vs SHA-1 cert chain, and signat= ure_algorithms seems like the cleanest way to do that.  Google hopes t= o have it shortly, but what about FF, IE, Opera, etc?

 

Replies to me will = be summarized for the list.

 <= /o:p>

Thanks.

 

-- 

Principal Security Engineer, Akamai Technologies

IM: rsalz@jabber.me Twitter: RichSalz

 

= --_000_2A0EFB9C05D0164E98F19BB0AF3708C71D130E9F55USMBX1msgcorp_-- From nobody Thu Sep 11 07:47:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C09E1A6FCA for ; Thu, 11 Sep 2014 07:47:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FQKWIYt-BULm for ; Thu, 11 Sep 2014 07:47:09 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id C3FB11A00C6 for ; Thu, 11 Sep 2014 07:47:08 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s8BEl4wb002955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Sep 2014 16:47:04 +0200 (MEST) In-Reply-To: <1410426957.17386.9.camel@dhcp-2-127.brq.redhat.com> To: Nikos Mavrogiannopoulos Date: Thu, 11 Sep 2014 16:47:04 +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: <20140911144704.6F4571AE3F@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yvHpbjgrwcTUZGbRVbGF29EwqdE Cc: "tls@ietf.org" Subject: Re: [TLS] signature_algorithms extension definition X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 11 Sep 2014 14:47:11 -0000 Nikos Mavrogiannopoulos wrote: > On Wed, 2014-09-10 at 09:21 -0700, Peter Bowen wrote: > > The TLS 1.2 RFC is a little ambiguous on the meaning of the contents > > of the signature_algorithms extension when included in a ClientHello > > message. It says "pairs [which] may be used in digital signatures" > > and "pair[s] that the client is willing to verify". Later on it says > > "If the client provided a 'signature_algorithms' extension, then all > > certificates provided by the server MUST be signed by a hash/signature > > algorithm pair that appears in that extension." > > The second sentence is ignored by implementations, as there is no way to > enforce it. The server has no way to switch the signatures in his > certificates. The certificates are provided by a third party (the CA), > which is not participating in the handshake in order to modify the > certificates. It would be a good thing if the latter sentence was > dropped in the new TLS 1.3 specification, or at least switched to MAY. +1 Similar to the TLS server_name_indication extension, the signature algorithms listed in the signature algorithms extension should be merely a hint for the server to select the _best_fit_ server certificate (chains) from those server certificates that it has available (which may be few, or just one). If the TLS client has specific (policy) requirements on acceptable algorithms, the client will have to perform his own checks in any case, and it would be entirely unreasonable for the server to preempt the clients decision whether to continue (best effort style), with or without confirmation from an interactive user at the client. -Martin From nobody Thu Sep 11 08:18:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5DBC1A6FCB for ; Thu, 11 Sep 2014 08:18:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EiVQp33g6eS6 for ; Thu, 11 Sep 2014 08:18:40 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 285F91A6FC2 for ; Thu, 11 Sep 2014 08:18:40 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id E320C604CB; Thu, 11 Sep 2014 17:18:06 +0200 (CEST) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id F2FC7422AA; Thu, 11 Sep 2014 17:18:37 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id EBED41AE40; Thu, 11 Sep 2014 17:18:37 +0200 (CEST) In-Reply-To: To: Watson Ladd Date: Thu, 11 Sep 2014 17:18:37 +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: <20140911151837.EBED41AE40@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/v_JXchevTW0mTFNMQmXeeBebhWw Cc: Markulf Kohlweiss , "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 11 Sep 2014 15:18:43 -0000 Watson Ladd wrote: > On Fri, Sep 5, 2014 at 9:08 AM, Daniel Kahn Gillmor > wrote: > > Hi Markulf-- > > > > Thanks for your post encouraging ongoing collaboration between the > > theoretical and engineering sides of the security community. This is a > > worthwhile goal. > > > > Can you provide clarification on this point below? > > > > On 09/02/2014 11:03 AM, Markulf Kohlweiss wrote: > >> > >> * To remove distraction and be closer to standard models like Bellare > >> & Rogaway, we would prefer unencrypted finished messages. In > >> practice this means that the finished message should be sent before > >> the ChangeCipherSuite message. > > > > > > I understand that the goal here is to be able to improve cryptanalysis of > > the confidentiality guarantees provided to the application data stream. > > Does this mean that the finished message needs to be unencrypted, or does it > > just mean that the finished message (and/or other parts of the handshake) > > should not be encrypted using the same keying material/session as the > > application data? > > If TLS is going over an encrypted channel, that doesn't change the > security of TLS. Rather the issue is the use of the master secret to > encrypt a finished message also derived from the master secret, and > then using the same keys to encrypt everything else. I'm sorry, but to me this discussion/argument look fairly bogus. The TLS master secret is never used to encrypt anything, and sending the finished messages in the clear would allow an attacker to make *EVERY* TLS handshake complete successfully, i.e. seriouly weaken TLS. I also don't understand why the fact that TLS finished messages are encrypted would make any proof harder. I believe that to be untrue. Think of the TLS master secret to be the (initial) entropy pool of something like the Hash_DRBG of HMAC_DRBG from NIST SP 800-90A. A problem would exit only if the TLS PRF construct would kill the cryptographic hash properties of the underlying hash -- or if the Hash_DRBG / HMAC_DRBG from NIST SP800-90A cryptographic random number generators would have a serious problem by themselves. For the AES-GCM TLS cipher suites, the encryption and MAC keys are also derived from the same master secret, and GHASH itself does not have cryptographic hash properties (i.e. it is invertible). The entire security of the AES-GCM is based on the assumption that the final encryption or the GHASH output saves the day. So the security of the existing TLS handshake with the encrypted finished handshake messages will always be stronger than the security of AES-GCM TLS cipher suites. -Martin From nobody Thu Sep 11 09:16:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50C4C1ACC8F for ; Thu, 11 Sep 2014 09:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xheI0PArJYvy for ; Thu, 11 Sep 2014 09:16:21 -0700 (PDT) Received: from mail-yk0-x231.google.com (mail-yk0-x231.google.com [IPv6:2607:f8b0:4002:c07::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D4791A89C6 for ; Thu, 11 Sep 2014 09:16:12 -0700 (PDT) Received: by mail-yk0-f177.google.com with SMTP id 79so4852828ykr.8 for ; Thu, 11 Sep 2014 09:16:11 -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=ka+ECRsi/6ufp//WiLyNKvIPNQonMDy0uDzpsZ0UCeM=; b=QMvMRrOWw3zX1ZxmvOtvZa+QZdJbhvHHNb5kzHHAip73T1jJRIpBzcb82ApoZyQ2xI g/6gju7O+iCQn3Q+pgpt8eKiVaOJLoWXPMJoIC5y5mxrlkz8UPma+Tu12xuaZopz6biI 3mIRtP/4ynmoqyTafrdHLFQ0hS4N4c+2E5Prdo6K6iEo7gr7zqASsoOnQ56NMez6CCGZ huSzyaco1Spv4cz3txC7NQZ1SRYef5N4kiLzQTE3EzvqzPyeDQc6xHObrmODURXaA4Xe bAJfH0Epd1s7Wwqtfwz8c5Kaazum/38fSVfv58A/lmJyt1z1KoWS38Yvc92GzB+NkCcE 08UA== MIME-Version: 1.0 X-Received: by 10.236.125.164 with SMTP id z24mr2530600yhh.138.1410452171561; Thu, 11 Sep 2014 09:16:11 -0700 (PDT) Received: by 10.170.207.216 with HTTP; Thu, 11 Sep 2014 09:16:11 -0700 (PDT) In-Reply-To: <20140911151837.EBED41AE40@ld9781.wdf.sap.corp> References: <20140911151837.EBED41AE40@ld9781.wdf.sap.corp> Date: Thu, 11 Sep 2014 09:16:11 -0700 Message-ID: From: Watson Ladd To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/HBVe3zRHT_F96H09axQUdAcYfRM Cc: Markulf Kohlweiss , "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 11 Sep 2014 16:16:23 -0000 On Thu, Sep 11, 2014 at 8:18 AM, Martin Rex wrote: > Watson Ladd wrote: >> On Fri, Sep 5, 2014 at 9:08 AM, Daniel Kahn Gillmor >> wrote: >> > Hi Markulf-- >> > >> > Thanks for your post encouraging ongoing collaboration between the >> > theoretical and engineering sides of the security community. This is a >> > worthwhile goal. >> > >> > Can you provide clarification on this point below? >> > >> > On 09/02/2014 11:03 AM, Markulf Kohlweiss wrote: >> >> >> >> * To remove distraction and be closer to standard models like Bellare >> >> & Rogaway, we would prefer unencrypted finished messages. In >> >> practice this means that the finished message should be sent before >> >> the ChangeCipherSuite message. >> > >> > >> > I understand that the goal here is to be able to improve cryptanalysis of >> > the confidentiality guarantees provided to the application data stream. >> > Does this mean that the finished message needs to be unencrypted, or does it >> > just mean that the finished message (and/or other parts of the handshake) >> > should not be encrypted using the same keying material/session as the >> > application data? >> >> If TLS is going over an encrypted channel, that doesn't change the >> security of TLS. Rather the issue is the use of the master secret to >> encrypt a finished message also derived from the master secret, and >> then using the same keys to encrypt everything else. > > > I'm sorry, but to me this discussion/argument look fairly bogus. > > The TLS master secret is never used to encrypt anything, and > sending the finished messages in the clear would allow an attacker > to make *EVERY* TLS handshake complete successfully, i.e. seriouly > weaken TLS. I don't understand how this claimed attack supposed to work: the finished messages in each direction are distinct, preventing replay. > > I also don't understand why the fact that TLS finished messages are > encrypted would make any proof harder. I believe that to be untrue. Have you tried to prove TLS secure? It's a very subtle issue related to the usual definitions. Dealing with it is painful. > > > Think of the TLS master secret to be the (initial) entropy pool of > something like the Hash_DRBG of HMAC_DRBG from NIST SP 800-90A. > > A problem would exit only if the TLS PRF construct would kill the > cryptographic hash properties of the underlying hash -- or if the > Hash_DRBG / HMAC_DRBG from NIST SP800-90A cryptographic random > number generators would have a serious problem by themselves. The problem is close to that caused by key-dependent encryption: you can have a cipher that is a PRP, but that fails on key-dependent messages. Yes, this seems like it shouldn't matter. Intuition is not a reliable guide to protocol security: did you discover Triple Handshake? The reason we want to change features that are hard to deal with isn't because they are necessarily insecure, but that the protocol may have other problems which doing the proof may uncover. This is exactly how Triple Handshake was discovered, and the issues in Kerberos v4, IPsec, etc. were discovered through similar means. IPsec was completely revamped, tossing IKEv1 and using a design by Hugo Krawczyk for IKEv2 that was proven secure. Why aren't we doing the same? > > > For the AES-GCM TLS cipher suites, the encryption and MAC keys are also > derived from the same master secret, and GHASH itself does not have > cryptographic hash properties (i.e. it is invertible). The entire security > of the AES-GCM is based on the assumption that the final encryption or the > GHASH output saves the day. So the security of the existing TLS handshake > with the encrypted finished handshake messages will always be stronger > than the security of AES-GCM TLS cipher suites. You're dead wrong, because AES-GCM meets its security definition, and the existing TLS handshake doesn't. This should indicate something is wrong with your argument. Sincerely, Watson Ladd > > > -Martin -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Sep 11 10:07:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58DED1A88CE for ; Thu, 11 Sep 2014 10:07:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.552 X-Spam-Level: X-Spam-Status: No, score=-6.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a_Xv8ifYLrEy for ; Thu, 11 Sep 2014 10:07:07 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED4D1A6FDA for ; Thu, 11 Sep 2014 10:07:07 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s8BH73JG014327 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 11 Sep 2014 19:07:03 +0200 (MEST) In-Reply-To: To: Watson Ladd Date: Thu, 11 Sep 2014 19:07:03 +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: <20140911170703.86F1A1AE40@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/e2xYHCIgNmiM6Uzg_bjgnexUydY Cc: Markulf Kohlweiss , "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 11 Sep 2014 17:07:09 -0000 Watson Ladd wrote: > > The problem is close to that caused by key-dependent encryption: you > can have a cipher that is a PRP, but that fails on key-dependent > messages. This doesn't apply to the TLS handshake, though. As I wrote, this would similarily break the Hash_DRBG and HMAC_DRBG designs from NIST SP800-90A if it did. > > Yes, this seems like it shouldn't matter. Intuition is not > a reliable guide to protocol security: did you discover Triple > Handshake? The triple handshake problem would have been fairly impossible to miss, if one really cared to look for it. The problem with the TLS spec is that information is scattered out all over the place, which makes it much more difficult to see its real properties. Such as the problem that the TLS master secret is computed from only the three inputs "premaster_secret", "ClientHello.random" and "ServerHello.random" and not cryptographically bound to the handshake (message hash) or the identities exchanged/established during the handshake. The original TLS renegotiation problem was a lack of cryptographic binding, and it was unnecessary to perform any kind of formal proofs to see the problem and its consequences. Collecting the snippets from various places of the TLS spec, writing it down and looking at it for an hour was perfectly sufficient to realize the problem. -Martin From nobody Thu Sep 11 10:28:19 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1B5E1A894A for ; Thu, 11 Sep 2014 10:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8OWyGESjLaUo for ; Thu, 11 Sep 2014 10:28:15 -0700 (PDT) Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5EE31A8968 for ; Thu, 11 Sep 2014 10:26:47 -0700 (PDT) Received: by mail-yh0-f44.google.com with SMTP id a41so12308950yho.31 for ; Thu, 11 Sep 2014 10:26:47 -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=WPNuRgNizoocyMFwdsyVmCBG/nvr6/KEAF8pLOFkD2M=; b=tCIdmOwQ10qhWVA4zMDIdlKyeod39V2K9srxb8/umD1c5yCpFT14zpID3vHCcLWX4F 8bvCDSuYg8WW1HlQk7n3UZxg1o255xOvZLpchvQ6p0dT2xb3DwfLpr0W5eOoyXFR7qYn 8nm3ZJsLXkdTk8ppGsOtuxqzCxTQdyhmr/OUTlNthtdI3eYVIRWuxxTFoM26yOJEatd9 VfyTxNNvMmvGZ4MpddnlpZIp+mb1JuCrk0wHIojlWyKFQPiSj0Pmn91b8Oino+Ay1UQg OhzSNR4zY5zO5n9Ms3PmkqaOQ1LBA63+MvK5dMHc/hyIAzwzeLHitSW7udXxFocjiN/J o0ZQ== MIME-Version: 1.0 X-Received: by 10.236.172.161 with SMTP id t21mr3024602yhl.65.1410456406969; Thu, 11 Sep 2014 10:26:46 -0700 (PDT) Received: by 10.170.207.216 with HTTP; Thu, 11 Sep 2014 10:26:46 -0700 (PDT) Received: by 10.170.207.216 with HTTP; Thu, 11 Sep 2014 10:26:46 -0700 (PDT) In-Reply-To: <20140911170703.86F1A1AE40@ld9781.wdf.sap.corp> References: <20140911170703.86F1A1AE40@ld9781.wdf.sap.corp> Date: Thu, 11 Sep 2014 10:26:46 -0700 Message-ID: From: Watson Ladd To: mrex@sap.com Content-Type: multipart/alternative; boundary=20cf304273e01bd51e0502cd7919 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qaAbIDNqTGQY5QlxrMWHntn6NRk Cc: Markulf Kohlweiss , tls@ietf.org Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 11 Sep 2014 17:28:16 -0000 --20cf304273e01bd51e0502cd7919 Content-Type: text/plain; charset=UTF-8 On Sep 11, 2014 10:07 AM, "Martin Rex" wrote: > > Watson Ladd wrote: > > > > The problem is close to that caused by key-dependent encryption: you > > can have a cipher that is a PRP, but that fails on key-dependent > > messages. > > This doesn't apply to the TLS handshake, though. As I wrote, this would > similarily break the Hash_DRBG and HMAC_DRBG designs from NIST SP800-90A > if it did. The issue is that the obvious proof method doesn't work. Obviously as we have a proof, this is not fatal to security. As for the Hash DRBG, details matter. > > > > > > Yes, this seems like it shouldn't matter. Intuition is not > > a reliable guide to protocol security: did you discover Triple > > Handshake? > > The triple handshake problem would have been fairly impossible to miss, > if one really cared to look for it. The problem with the TLS spec is > that information is scattered out all over the place, which makes it > much more difficult to see its real properties. > Such as the problem that the TLS master secret is computed from only > the three inputs "premaster_secret", "ClientHello.random" and > "ServerHello.random" and not cryptographically bound to the handshake > (message hash) or the identities exchanged/established during the > handshake. Why didn't you find it then? This is another problem which frustrates analysis which should be fixed. > > The original TLS renegotiation problem was a lack of cryptographic > binding, and it was unnecessary to perform any kind of formal proofs > to see the problem and its consequences. > Collecting the snippets from various places of the TLS spec, writing > it down and looking at it for an hour was perfectly sufficient to > realize the problem. Which you did the first time, but not the second. > > > -Martin --20cf304273e01bd51e0502cd7919 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sep 11, 2014 10:07 AM, "Martin Rex" <mrex@sap.com> wrote:
>
> Watson Ladd wrote:
> >
> > The problem is close to that caused by key-dependent encryption: = you
> > can have a cipher that is a PRP, but that fails on key-dependent<= br> > > messages.
>
> This doesn't apply to the TLS handshake, though.=C2=A0 As I wrote,= this would
> similarily break the Hash_DRBG and HMAC_DRBG designs from NIST SP800-9= 0A
> if it did.

The issue is that the obvious proof method doesn't work.= Obviously as we have a proof, this is not fatal to security.

As for the Hash DRBG, details matter.
>
>
> >
> > Yes, this seems like it shouldn't matter. Intuition is not > > a reliable guide to protocol security: did you discover Triple > > Handshake?
>
> The triple handshake problem would have been fairly impossible to miss= ,
> if one really cared to look for it.=C2=A0 The problem with the TLS spe= c is
> that information is scattered out all over the place, which makes it > much more difficult to see its real properties.
> Such as the problem that the TLS master secret is computed from only > the three inputs "premaster_secret", "ClientHello.rando= m" and
> "ServerHello.random" and not cryptographically bound to the = handshake
> (message hash) or the identities exchanged/established during the
> handshake.

Why didn't you find it then? This is another problem whi= ch frustrates analysis which should be fixed.

>
> The original TLS renegotiation problem was a lack of cryptographic
> binding, and it was unnecessary to perform any kind of formal proofs > to see the problem and its consequences.
> Collecting the snippets from various places of the TLS spec, writing > it down and looking at it for an hour was perfectly sufficient to
> realize the problem.

Which you did the first time, but not the second.
>
>
> -Martin

--20cf304273e01bd51e0502cd7919-- From nobody Thu Sep 11 10:28:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4960C1A8978 for ; Thu, 11 Sep 2014 10:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qy9X6QPDHvMV for ; Thu, 11 Sep 2014 10:28:44 -0700 (PDT) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 248911A89E0 for ; Thu, 11 Sep 2014 10:27:43 -0700 (PDT) Received: by mail-qc0-f178.google.com with SMTP id x13so21392475qcv.23 for ; Thu, 11 Sep 2014 10:27:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=7Sut6J4qdcxMzX31CLhvIH8aindjEfwBSdzISiWD0n4=; b=BHOkjnyff4q6FyNOhcEGrl5pp67xjB4O70or4PIDl91mpPVeIFPYCIWcjkQ85/kN4O jO4R80Zf+VVr9dj4piYgYkXJNGWXK71qqvzJXHsT9oe0KqeWruzZyFEyxL+IiN6grB3l 6uNG9GagGRZcqrDhsOfoMbsiSXoCzmC+U0SIpMvApnTOxXY7yhb9WnyMKxLFkptIar0u UHtGcY42BHiY/DF6mkk5YwdHpx0bnrS2pkLvw0RAZKQhtRFchpFyn/DQ6hO0GY/p8xbQ C+cbW6aqfwKcnhlgcbX3Nur6M0IWpzhwhnmWOLCbhTTl8is3VeYimIYwqEskuDc708Z7 8yNw== X-Gm-Message-State: ALoCoQkJfnrYUmtR+4ukhm1ODxpWpP0vgmCiLm5+xn0pnObEtaupc5z57XtQg6xuKeJR+at/mGGA MIME-Version: 1.0 X-Received: by 10.140.90.42 with SMTP id w39mr3515169qgd.88.1410456461951; Thu, 11 Sep 2014 10:27:41 -0700 (PDT) Received: by 10.224.67.133 with HTTP; Thu, 11 Sep 2014 10:27:41 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D130E9F55@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D130E9F55@USMBX1.msg.corp.akamai.com> Date: Thu, 11 Sep 2014 10:27:41 -0700 Message-ID: From: Brian Smith To: "Salz, Rich" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/VaeWIa_0ENkRb97cOyVnTEIkSxU Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] Which browsers support signature_algorithms? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 11 Sep 2014 17:28:46 -0000 On Thu, Sep 11, 2014 at 7:38 AM, Salz, Rich wrote: > My employer will have to support dual-chains for some of our customers wh= o > want to support both current browsers and older embedded devices. We=E2= =80=99re > trying to figure out how to know when to present SHA-256 vs SHA-1 cert > chain, and signature_algorithms seems like the cleanest way to do that. > Google hopes to have it shortly, but what about FF, IE, Opera, etc? I think it is safe to assume that no major browser will drop support for SHA-1-based signatures without advertising support for the signature_algorithms extension in its TLS 1.2 ClientHello. The thing that you are trying to implement has been discussed pretty extensively. See [1][2][3][4][5] in particular, but you should probably read that whole thread. Cheers, Brian [1] https://groups.google.com/a/chromium.org/d/msg/security-dev/2-R4XziFc7A= /mlf3RVmioCAJ [2] https://groups.google.com/a/chromium.org/d/msg/security-dev/2-R4XziFc7A= /TZyFYctjSy4J [3] https://groups.google.com/a/chromium.org/d/msg/security-dev/2-R4XziFc7A= /CvjBXJcCWa0J [4] https://groups.google.com/a/chromium.org/d/msg/security-dev/2-R4XziFc7A= /GHOe5sSteEcJ [5] https://code.google.com/p/chromium/issues/detail?id=3D409901 From nobody Thu Sep 11 10:29:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1D211A6F85 for ; Thu, 11 Sep 2014 10:29:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.044 X-Spam-Level: X-Spam-Status: No, score=-1.044 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o4E635KuI9za for ; Thu, 11 Sep 2014 10:29:03 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 3917A1A8960 for ; Thu, 11 Sep 2014 10:28:03 -0700 (PDT) Received: from homiemail-a30.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTP id B797221DE65 for ; Thu, 11 Sep 2014 10:28:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h= mime-version:in-reply-to:references:date:message-id:subject:from :to:cc:content-type; s=cryptonector.com; bh=dkd2OmuNQopM2cyCLMdD mFwnLHg=; b=SZ/9Hbj2AkARv9y0JHiVfzYebzRaRdjBMVoXal9OScGLgO26wiVE Z8+awCWH8hZy0jo7dfvGkxVDjkA6s2PIw5ZQSv4QV7OXPocB3reLGkKdSBuEZPq/ yiKpXlMG+WjngddLqe9veU6IdNkVTKX4lcn/gY9pAhhlAkQz5rJ3lzw= Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a30.g.dreamhost.com (Postfix) with ESMTPSA id 6369B21DE58 for ; Thu, 11 Sep 2014 10:28:02 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id k14so5529531wgh.10 for ; Thu, 11 Sep 2014 10:28:01 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.58.244 with SMTP id u20mr3663349wjq.36.1410456481117; Thu, 11 Sep 2014 10:28:01 -0700 (PDT) Received: by 10.216.52.8 with HTTP; Thu, 11 Sep 2014 10:28:01 -0700 (PDT) In-Reply-To: <5409E00D.1070703@fifthhorseman.net> References: <5409E00D.1070703@fifthhorseman.net> Date: Thu, 11 Sep 2014 12:28:01 -0500 Message-ID: From: Nico Williams To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nFd8CTuyiDwVuAq1XX6ebYvxrNY Cc: Markulf Kohlweiss , "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 11 Sep 2014 17:29:03 -0000 TLS should be secure with Finished messages sent unencrypted. That should be a goal for the design of the Finished message construction. That said, once that is so I fail to see how encrypting them can weaken the protocol. And if the Finished messages are entirely pseudo-random (e.g., a cryptographic authentication tag) then I fail to see how encrypting them strengthens the protocol either. Therefore to me this is neither here nor there. That said, not encrypting the Finished messages has a small performance benefit; it's probably worthwhile for that reason. Count me as in favor of not encrypting then, with the above [non-controversial, right?] caveats. Nico -- From nobody Thu Sep 11 10:37:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F4B1A89A3 for ; Thu, 11 Sep 2014 10:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jAKIzmtqFQAn for ; Thu, 11 Sep 2014 10:37:03 -0700 (PDT) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49BDD1A8987 for ; Thu, 11 Sep 2014 10:37:01 -0700 (PDT) Received: by mail-yk0-f173.google.com with SMTP id 19so3183656ykq.18 for ; Thu, 11 Sep 2014 10:37:00 -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=KvuKghDK+CsGpI1PRRDah6/LqQx2lguIwENGHEaB914=; b=f1Ru4FO6+iL1pPvQlldRqJd2jztKYlrofHmguI95rozkn+zHVS4uCtCMl8KUsj9drD iX5dF44m6K/H6UhzegDYzAFTN6BPUwlK1lWV02C0NCDGllAjfKt0Unex05j1Mr5z8/Px 4X5I2w++GSuCIUJe3BzNNkmjWaVToX+GA1SAc8fa7Z71AaN9CV0dcezUKkmUR123ZPYH BJc92Dla2kfVoU7iQL7lQt8nrd+wjRjCspF/OtQAK5wG+thsyud60b24soDO1w9zCvui 7+3GrkfxB2qkVTmSdGMieV+QpgvL2ifprQHknuueOarumsTJjW4c/tsVjD2s6qWM09b+ 7j2Q== MIME-Version: 1.0 X-Received: by 10.236.147.34 with SMTP id s22mr2579694yhj.172.1410457020644; Thu, 11 Sep 2014 10:37:00 -0700 (PDT) Received: by 10.170.207.216 with HTTP; Thu, 11 Sep 2014 10:37:00 -0700 (PDT) Received: by 10.170.207.216 with HTTP; Thu, 11 Sep 2014 10:37:00 -0700 (PDT) In-Reply-To: References: <5409E00D.1070703@fifthhorseman.net> Date: Thu, 11 Sep 2014 10:37:00 -0700 Message-ID: From: Watson Ladd To: Nico Williams Content-Type: multipart/alternative; boundary=20cf303a337dafc2c90502cd9d6e Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-zKNO4gU1HtShM9e08WGEtNP3uw Cc: Markulf Kohlweiss , tls@ietf.org Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 11 Sep 2014 17:37:05 -0000 --20cf303a337dafc2c90502cd9d6e Content-Type: text/plain; charset=UTF-8 On Sep 11, 2014 10:29 AM, "Nico Williams" wrote: > > TLS should be secure with Finished messages sent unencrypted. That > should be a goal for the design of the Finished message construction. > > That said, once that is so I fail to see how encrypting them can > weaken the protocol. And if the Finished messages are entirely > pseudo-random (e.g., a cryptographic authentication tag) then I fail > to see how encrypting them strengthens the protocol either. It's not about the security of TLS, but the relevance of the usual key agreement definition to TLS. I used to think that it didn't matter. Then someone asked me to prove that it didn't matter. > > Therefore to me this is neither here nor there. > > That said, not encrypting the Finished messages has a small > performance benefit; it's probably worthwhile for that reason. Count > me as in favor of not encrypting then, with the above > [non-controversial, right?] caveats. > > Nico > -- > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls --20cf303a337dafc2c90502cd9d6e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sep 11, 2014 10:29 AM, "Nico Williams" <nico@cryptonector.com> wrote:
>
> TLS should be secure with Finished messages sent unencrypted.=C2=A0 Th= at
> should be a goal for the design of the Finished message construction.<= br> >
> That said, once that is so I fail to see how encrypting them can
> weaken the protocol.=C2=A0 And if the Finished messages are entirely > pseudo-random (e.g., a cryptographic authentication tag) then I fail > to see how encrypting them strengthens the protocol either.

It's not about the security of TLS, but the relevance of= the usual key agreement definition to TLS. I used to think that it didn= 9;t matter. Then someone asked me to prove that it didn't matter.

>
> Therefore to me this is neither here nor there.
>
> That said, not encrypting the Finished messages has a small
> performance benefit; it's probably worthwhile for that reason.=C2= =A0 Count
> me as in favor of not encrypting then, with the above
> [non-controversial, right?] caveats.
>
> Nico
> --
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf= .org/mailman/listinfo/tls

--20cf303a337dafc2c90502cd9d6e-- From nobody Thu Sep 11 11:11:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264C41A8F4F for ; Thu, 11 Sep 2014 11:11:48 -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=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2B1xHI8Y3M9M for ; Thu, 11 Sep 2014 11:11:46 -0700 (PDT) Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FD1D1A9172 for ; Thu, 11 Sep 2014 11:05:29 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id cc10so1546342wib.2 for ; Thu, 11 Sep 2014 11:05:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=IL7/EtKfpz3XuDM6MkfIfDQL5Hkh98z6SzAzSY5RiRQ=; b=kAHu2WHvOIlE5PQ9VwLoRMmu9i96DQ+8+k79wMRnpUoXeTbw3q9qiEelmfreih+Fxp r1tmOQMxmI6sk5jSDsVKpUs6yY51S6QAExh9cAQc0e6SbROUwTL1bMp/K5wrqGCcJ+vt Z4cYoMh/n1NwzFg3itPi3tlQgX6EyWF2nin39wAx49rbOyRxqBCdeOiliKRjAy49dKnL MDEPuQPZ8YWXRqaEkU95Zrus96uykck4lPIurZW8jj0TtUWw9OKC+QrR9nnJgIB8Ugt1 S577LmANX4mTVlkejTaQc5S5wavcwS+mzzZn03c0Cp8LZN9JRkswGFwyl6VlVICSxPQS GGgg== X-Gm-Message-State: ALoCoQlg1KQDEYlNMeVc3ywRJQiLPWCOeorMsOPDFAZOiYe6U7YMzo5zw6Lin3TgMFQK6jhOdQZD X-Received: by 10.194.184.166 with SMTP id ev6mr3578695wjc.61.1410458723002; Thu, 11 Sep 2014 11:05:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.146.194 with HTTP; Thu, 11 Sep 2014 11:04:42 -0700 (PDT) In-Reply-To: References: <5409E00D.1070703@fifthhorseman.net> From: Eric Rescorla Date: Thu, 11 Sep 2014 11:04:42 -0700 Message-ID: To: Nico Williams Content-Type: multipart/alternative; boundary=047d7bae493227c5030502ce03a0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BFuN9p0CSCc5U1l11N_h8b6CxN0 Cc: Markulf Kohlweiss , "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 11 Sep 2014 18:11:48 -0000 --047d7bae493227c5030502ce03a0 Content-Type: text/plain; charset=UTF-8 On Thu, Sep 11, 2014 at 10:28 AM, Nico Williams wrote: > TLS should be secure with Finished messages sent unencrypted. That > should be a goal for the design of the Finished message construction. > > That said, once that is so I fail to see how encrypting them can > weaken the protocol. And if the Finished messages are entirely > pseudo-random (e.g., a cryptographic authentication tag) then I fail > to see how encrypting them strengthens the protocol either. > > Therefore to me this is neither here nor there. > > That said, not encrypting the Finished messages has a small > performance benefit; it's probably worthwhile for that reason. Count > me as in favor of not encrypting then, with the above > [non-controversial, right?] caveats. Given that we are encrypting the rest of the handshake in TLS 1.3, exempting just Finished seems problematic. In Toronto we discussed deriving different keys for handshake encryption and application data encryption. Would that also resolve the issue here? -Ekr --047d7bae493227c5030502ce03a0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Sep 11, 2014 at 10:28 AM, Nico Williams <<= a href=3D"mailto:nico@cryptonector.com" target=3D"_blank">nico@cryptonector= .com> wrote:
TLS should be = secure with Finished messages sent unencrypted.=C2=A0 That
should be a goal for the design of the Finished message construction.

That said, once that is so I fail to see how encrypting them can
weaken the protocol.=C2=A0 And if the Finished messages are entirely
pseudo-random (e.g., a cryptographic authentication tag) then I fail
to see how encrypting them strengthens the protocol either.

Therefore to me this is neither here nor there.

That said, not encrypting the Finished messages has a small
performance benefit; it's probably worthwhile for that reason.=C2=A0 Co= unt
me as in favor of not encrypting then, with the above
[non-controversial, right?] caveats.

Given = that we are encrypting the rest of the handshake in TLS 1.3, exempting
just Finished seems problematic. In Toronto we discussed deriving dif= ferent
keys for handshake encryption and application data encrypt= ion. Would that
also resolve the issue here?

-Ekr

--047d7bae493227c5030502ce03a0-- From nobody Thu Sep 11 11:37:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00F3B1A797C for ; Thu, 11 Sep 2014 11:37:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9yQfFB-y1bd7 for ; Thu, 11 Sep 2014 11:37:14 -0700 (PDT) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B24D91A7030 for ; Thu, 11 Sep 2014 11:37:14 -0700 (PDT) Received: by mail-pa0-f54.google.com with SMTP id lj1so11283071pab.27 for ; Thu, 11 Sep 2014 11:37:14 -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:content-transfer-encoding; bh=Ko9uTle0aeJA7SDq386i2+S9AOHH0Q9DroqFV5k3p38=; b=dqXgdNETEP/ldE8gJBRFdHf8nwn7A8mgfUGisIuofcksKso1F6g1mnqRNSo6H/zBRs CyfoyONX19kWKH+41QzGInswb5Y5JiG9NCvcMHM+7hbZNV8qsk4t0aho9HqsDKlvsb8S MXR1IL8IB2JXD81QhU4dJne7xmUNbNTaDR0y27m3KVss6Vi49i5AdY5cajRifnChEIY1 70hXPoq7K2i8MeuA85eMg8pA9faBqr7Zva98A7otZcpmUA/j8hjbZFQ1TIxas6Ucccrr cG51HPYJAcFHjSW3KUXaN/IRpV+5oCJ+JJ8Dc2ZXt64H8Zd1lniCiGBkaAVcugS72Khi mmyQ== MIME-Version: 1.0 X-Received: by 10.68.219.102 with SMTP id pn6mr4021693pbc.135.1410460634219; Thu, 11 Sep 2014 11:37:14 -0700 (PDT) Received: by 10.70.39.5 with HTTP; Thu, 11 Sep 2014 11:37:14 -0700 (PDT) In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C71D130E9F55@USMBX1.msg.corp.akamai.com> Date: Thu, 11 Sep 2014 11:37:14 -0700 Message-ID: From: Peter Bowen To: Brian Smith Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QOucSQqAIWw6rb3VpF-4f2hWsgc Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] Which browsers support signature_algorithms? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 11 Sep 2014 18:37:18 -0000 I would also suggest looking at http://rt.openssl.org/Ticket/Display.html?id=3D3068&user=3Dguest&pass=3Dgue= st for another client bug related to certificate selection. Thanks, Peter On Thu, Sep 11, 2014 at 10:27 AM, Brian Smith wrote: > On Thu, Sep 11, 2014 at 7:38 AM, Salz, Rich wrote: >> My employer will have to support dual-chains for some of our customers w= ho >> want to support both current browsers and older embedded devices. We=E2= =80=99re >> trying to figure out how to know when to present SHA-256 vs SHA-1 cert >> chain, and signature_algorithms seems like the cleanest way to do that. >> Google hopes to have it shortly, but what about FF, IE, Opera, etc? > > I think it is safe to assume that no major browser will drop support > for SHA-1-based signatures without advertising support for the > signature_algorithms extension in its TLS 1.2 ClientHello. > > The thing that you are trying to implement has been discussed pretty > extensively. See [1][2][3][4][5] in particular, but you should > probably read that whole thread. > > Cheers, > Brian > > [1] https://groups.google.com/a/chromium.org/d/msg/security-dev/2-R4XziFc= 7A/mlf3RVmioCAJ > [2] https://groups.google.com/a/chromium.org/d/msg/security-dev/2-R4XziFc= 7A/TZyFYctjSy4J > [3] https://groups.google.com/a/chromium.org/d/msg/security-dev/2-R4XziFc= 7A/CvjBXJcCWa0J > [4] https://groups.google.com/a/chromium.org/d/msg/security-dev/2-R4XziFc= 7A/GHOe5sSteEcJ > [5] https://code.google.com/p/chromium/issues/detail?id=3D409901 > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Thu Sep 11 13:33:09 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3C61A0117 for ; Thu, 11 Sep 2014 13:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.149 X-Spam-Level: X-Spam-Status: No, score=-5.149 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Syhefcvf4nnt for ; Thu, 11 Sep 2014 13:33:06 -0700 (PDT) Received: from EX10ED02.qut.edu.au (ex10ed02.qut.edu.au [131.181.191.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EF461A0054 for ; Thu, 11 Sep 2014 13:33:04 -0700 (PDT) Received: from EX10HT05.qut.edu.au (131.181.108.103) by EX10ED02.qut.edu.au (131.181.191.15) with Microsoft SMTP Server (TLS) id 14.3.174.1; Fri, 12 Sep 2014 06:33:02 +1000 Received: from EX10MB4.qut.edu.au ([169.254.6.189]) by EX10HT05.qut.edu.au ([131.181.108.103]) with mapi id 14.03.0158.001; Fri, 12 Sep 2014 06:33:02 +1000 From: Douglas Stebila To: Eric Rescorla Thread-Topic: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] Thread-Index: AQHPySPClMXPKrMRzEqZH42PBVv6YZv7xT0A Date: Thu, 11 Sep 2014 20:33:02 +0000 Message-ID: References: <5409E00D.1070703@fifthhorseman.net> In-Reply-To: <5409E00D.1070703@fifthhorseman.net> Accept-Language: en-CA, en-AU, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [131.181.118.225] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AduCGJak7R30nDiorKbToGzggdU Cc: Markulf Kohlweiss , "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 11 Sep 2014 20:33:08 -0000 On Sep 2, 2014, at 11:03 AM, Markulf Kohlweiss wrot= e: > * To remove distraction and be closer to standard models like Bellare & R= ogaway, we would prefer unencrypted finished messages. In practice this mea= ns that the finished message should be sent before the ChangeCipherSuite me= ssage. On Sep 11, 2014, at 8:04 PM, Eric Rescorla wrote: > Given that we are encrypting the rest of the handshake in TLS 1.3, exempt= ing just Finished seems problematic. I see no strong reason, cryptographically, to prefer unencrypted or encrypt= ed Finished messages either way. It's true that unencrypted Finished messa= ges make it easier to prove a secure channel property by using the traditio= nal cryptographic approach of concatenating key exchange and authenticated = encryption. But that is just one way to build a secure channel, and we now= know how to prove TLS is a secure channel even without the clear separatio= n between the handshake and the channel encryption. So with our current st= ate of the art proof techniques, encrypted Finished messages are now a rela= tively minor inconvenience in proofs. Normal key exchange security definitions rely on indistinguishability of th= e session key: once the key exchange is complete, if you give the adversary= either the real session key or a random one, can she tell which she was gi= ven? The encrypted Finished messages make it tricky because the Finished m= essage has a recognizable format: the first byte of the Finished message is= the TLS content type, for example. Decryption using a random key would wi= th high probability yield something not in that format. Exempting the Fini= shed message but encrypting other parts of the handshake with the session k= ey would not fix the problem, as the other handshake messages would still h= ave a recognizable format. To me, there is far more benefit gained from encrypting handshake messages = compared to the minor inconvenience to cryptographers trying to prove secur= ity. On Sep 11, 2014, at 8:04 PM, Eric Rescorla wrote: > In Toronto we discussed deriving different keys for handshake encryption = and application data encryption. Would that also resolve the issue here? Unclear to me. My gut tells me the proof would probably go through either = way, but I'd have to check. It's also unclear to me whether this offers an= y benefit -- intuitively it feels like there's a nice "functional separatio= n" that comes from encrypting application data with a separate key from han= dshake data, but cryptographically there's probably not much difference sin= ce they both are derived from the same master secret key. =20 If I were to make two changes in TLS 1.3 for the purposes of improving cryp= tographic proofs, they would be 1) to include the hash of the transcript in the derivation of the master se= cret as has already been proposed (so that something can be proved about se= ssion resumption), and 2) to fix the signature in signed-DH by signing the full transcript (fixing= the Mavrogiannopoulos cross-ciphersuite attack) and moving the server sign= ature to a separate CertificateVerify message just before the [ChangeCipher= Spec] (getting rid of the pesky Oracle-DH assumption in the proofs). Douglas= From nobody Thu Sep 11 13:37:48 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ECA71A010F for ; Thu, 11 Sep 2014 13:37:45 -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=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id geW3HpyD8SU2 for ; Thu, 11 Sep 2014 13:37:41 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09C141A0135 for ; Thu, 11 Sep 2014 13:37:40 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id e4so1768329wiv.9 for ; Thu, 11 Sep 2014 13:37:36 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=kcOriID2VcDo0rLXJpovUi3AyHA+6rESW0oPR5ffXuE=; b=N7KlrdOLQh5+V5lUI3JGN6g4F3wAjlf4Z8BvIoQZ+RNdmw09GBlqY4xnMJpe153tLl E7E0jsOL7UY+4U/HhwxZKAJbf424e2gfQaS6UfTWPsfzLqCwOnD03V/tX+na09BtB++W wsopmE0rG07+dOCP8qgJFUdvJRaAMYQC54tUUDwhVDhQWOTQE1OktH+qaBZU+bkRZi0I e1cIxNoRX1IDzfTn7xjFph1NeuLnN5/n3UJ2PmST/O8/d9K6vMVEVLrgjWfIAah+lWqE pP7G9LsbToddig4+64OT4/OGRYJFc0rQkxjBIGnEatMMM5sKfZV9/ILYeCl6mzWHPYuB 8ftQ== X-Gm-Message-State: ALoCoQl53VdQRXx6W1CINxAkh0l3Kqyx+Ly2xhYFvc4LNQPOLVi28Fl9nz595Porb/0AusWifS7O X-Received: by 10.194.185.81 with SMTP id fa17mr5008181wjc.114.1410467856582; Thu, 11 Sep 2014 13:37:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.146.194 with HTTP; Thu, 11 Sep 2014 13:36:56 -0700 (PDT) In-Reply-To: References: <5409E00D.1070703@fifthhorseman.net> From: Eric Rescorla Date: Thu, 11 Sep 2014 13:36:56 -0700 Message-ID: To: Douglas Stebila Content-Type: multipart/alternative; boundary=047d7bae49568f102d0502d02380 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/tUJbeRPJxggFZYzwkxu_hxfngq0 Cc: Markulf Kohlweiss , "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 11 Sep 2014 20:37:45 -0000 --047d7bae49568f102d0502d02380 Content-Type: text/plain; charset=UTF-8 On Thu, Sep 11, 2014 at 1:33 PM, Douglas Stebila wrote: > On Sep 2, 2014, at 11:03 AM, Markulf Kohlweiss > wrote: > > * To remove distraction and be closer to standard models like Bellare & > Rogaway, we would prefer unencrypted finished messages. In practice this > means that the finished message should be sent before the ChangeCipherSuite > message. > > On Sep 11, 2014, at 8:04 PM, Eric Rescorla wrote: > > Given that we are encrypting the rest of the handshake in TLS 1.3, > exempting just Finished seems problematic. > > I see no strong reason, cryptographically, to prefer unencrypted or > encrypted Finished messages either way. It's true that unencrypted > Finished messages make it easier to prove a secure channel property by > using the traditional cryptographic approach of concatenating key exchange > and authenticated encryption. But that is just one way to build a secure > channel, and we now know how to prove TLS is a secure channel even without > the clear separation between the handshake and the channel encryption. So > with our current state of the art proof techniques, encrypted Finished > messages are now a relatively minor inconvenience in proofs. > > Normal key exchange security definitions rely on indistinguishability of > the session key: once the key exchange is complete, if you give the > adversary either the real session key or a random one, can she tell which > she was given? The encrypted Finished messages make it tricky because the > Finished message has a recognizable format: the first byte of the Finished > message is the TLS content type, for example. Decryption using a random > key would with high probability yield something not in that format. > Exempting the Finished message but encrypting other parts of the handshake > with the session key would not fix the problem, as the other handshake > messages would still have a recognizable format. > > To me, there is far more benefit gained from encrypting handshake messages > compared to the minor inconvenience to cryptographers trying to prove > security. > > On Sep 11, 2014, at 8:04 PM, Eric Rescorla wrote: > > In Toronto we discussed deriving different keys for handshake encryption > and application data encryption. Would that also resolve the issue here? > > Unclear to me. My gut tells me the proof would probably go through either > way, but I'd have to check. It's also unclear to me whether this offers > any benefit -- intuitively it feels like there's a nice "functional > separation" that comes from encrypting application data with a separate key > from handshake data, but cryptographically there's probably not much > difference since they both are derived from the same master secret key. > > If I were to make two changes in TLS 1.3 for the purposes of improving > cryptographic proofs, they would be > 1) to include the hash of the transcript in the derivation of the master > secret as has already been proposed (so that something can be proved about > session resumption), and > I believe (and the WG chairs can correct me) that this change has consensus and there is a Github issue to make the change. 2) to fix the signature in signed-DH by signing the full transcript (fixing > the Mavrogiannopoulos cross-ciphersuite attack) and moving the server > signature to a separate CertificateVerify message just before the > [ChangeCipherSpec] (getting rid of the pesky Oracle-DH assumption in the > proofs). A version of this change is already there. However CertificateVerify now comes *after* CCS because otherwise we can't encrypt the certificate. -Ekr > > Douglas --047d7bae49568f102d0502d02380 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Sep 11, 2014 at 1:33 PM, Douglas Stebila <= stebila@qut.edu.au<= /a>> wrote:
On= Sep 2, 2014, at 11:03 AM, Markulf Kohlweiss <markulf@microsoft.com> wrote:
> * To remove distraction and be closer to standard models like Bellare = & Rogaway, we would prefer unencrypted finished messages. In practice t= his means that the finished message should be sent before the ChangeCipherS= uite message.

On Sep 11, 2014, at 8:04 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> Given that we are encrypting the rest of the handshake in TLS 1.3, exe= mpting just Finished seems problematic.

I see no strong reason, cryptographically, to prefer unencrypted or = encrypted Finished messages either way.=C2=A0 It's true that unencrypte= d Finished messages make it easier to prove a secure channel property by us= ing the traditional cryptographic approach of concatenating key exchange an= d authenticated encryption.=C2=A0 But that is just one way to build a secur= e channel, and we now know how to prove TLS is a secure channel even withou= t the clear separation between the handshake and the channel encryption.=C2= =A0 So with our current state of the art proof techniques, encrypted Finish= ed messages are now a relatively minor inconvenience in proofs.

Normal key exchange security definitions rely on indistinguishability of th= e session key: once the key exchange is complete, if you give the adversary= either the real session key or a random one, can she tell which she was gi= ven?=C2=A0 The encrypted Finished messages make it tricky because the Finis= hed message has a recognizable format: the first byte of the Finished messa= ge is the TLS content type, for example.=C2=A0 Decryption using a random ke= y would with high probability yield something not in that format.=C2=A0 Exe= mpting the Finished message but encrypting other parts of the handshake wit= h the session key would not fix the problem, as the other handshake message= s would still have a recognizable format.

To me, there is far more benefit gained from encrypting handshake messages = compared to the minor inconvenience to cryptographers trying to prove secur= ity.

On Sep 11, 2014, at 8:04 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> In Toronto we discussed deriving different keys for handshake encrypti= on and application data encryption. Would that also resolve the issue here?=

Unclear to me.=C2=A0 My gut tells me the proof would probably go thr= ough either way, but I'd have to check.=C2=A0 It's also unclear to = me whether this offers any benefit -- intuitively it feels like there's= a nice "functional separation" that comes from encrypting applic= ation data with a separate key from handshake data, but cryptographically t= here's probably not much difference since they both are derived from th= e same master secret key.

If I were to make two changes in TLS 1.3 for the purposes of improving cryp= tographic proofs, they would be
1) to include the hash of the transcript in the derivation of the master se= cret as has already been proposed (so that something can be proved about se= ssion resumption), and

I believe (and t= he WG chairs can correct me) that this change has consensus
and t= here is a Github issue to make the change.


2) to fix the signature in signed-DH by signing the full transcript (fixing= the Mavrogiannopoulos cross-ciphersuite attack) and moving the server sign= ature to a separate CertificateVerify message just before the [ChangeCipher= Spec] (getting rid of the pesky Oracle-DH assumption in the proofs).

A version of this change is already there. Howeve= r CertificateVerify now
comes *after* CCS because otherwise we ca= n't encrypt the certificate.

-Ekr
= =C2=A0

Douglas

--047d7bae49568f102d0502d02380-- From nobody Thu Sep 11 14:32:07 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53FE01A02E0 for ; Thu, 11 Sep 2014 14:32:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kpItldP8fY0P for ; Thu, 11 Sep 2014 14:32:03 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E83DB1A029C for ; Thu, 11 Sep 2014 14:32:02 -0700 (PDT) Received: from latte.josefsson.org ([IPv6:2001:16d8:cca1:0:f5e7:75f1:56cd:f062]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id s8BLVwEl016123 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 11 Sep 2014 23:31:59 +0200 X-Hashcash: 1:22:140911:tls@ietf.org::YFZnCyofIBONaC3M:JalQ From: Simon Josefsson To: tls@ietf.org OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt Date: Thu, 11 Sep 2014 23:31:57 +0200 Message-ID: <87k359rghe.fsf@latte.josefsson.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.4 at duva.sjd.se X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6CVwWXENFKj2tZ4da0UciJ1268U Subject: [TLS] Additional ECC curves X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 11 Sep 2014 21:32:05 -0000 --=-=-= Content-Type: text/plain Hi all, I've updated our "additional curves" document to cover registration of all Safe Curves currently listed on DJBs page. While I have only seen genuine interest for a couple of these for TLS, I think it will drive more experimentation if they are all included in a single document. The list of supported curves are now: M-221 (aka Curve2213), E-222, Curve1174, E-382, M-383, Curve383187, Curve41417 (aka Curve3617), Ed448-Goldilocks, M-511 (aka Curve511187), and E-521. Remember, Curve25519 is covered by my other draft. http://tools.ietf.org/html/draft-josefsson-tls-additional-curves-01 /Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJUEhTNAAoJEIYLf7sy+BGdBCAH/0P1bdIqaiqcq0IEgvuElpAx wonoPoqWsN3Lb1eo3hDlVPSeMkd2VbpNvLh3TDo94uqkli1yDyVhC8mIUvEICLMl ndu69V5cCU8UekmXxq9B/p1P/a9oRuA7YM0drkhy8RcPs5ruxZQNNrRJDPMxKpIO hRQYKJ/UIZkwbB9cRsBWC81p1Wsxuw0zMbosYZ+YG561eI+G5wPQMJwofeJtMv/O o6wfWnjfQ4dmmGKvSUUV6AI7xpIkrORB+GYL4ylvJKI35V+jkOIwwcRDuEG61Bs5 dpjmpyczXCqDUglsJfaKzvgzdlMKn1N0ObW89x1P2KbB51NCnmUsVWqHk/z0m4g= =shgE -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Sep 11 14:47:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A8541A02D6 for ; Thu, 11 Sep 2014 14:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H2KKTTy3BiUW for ; Thu, 11 Sep 2014 14:47:22 -0700 (PDT) Received: from duva.sjd.se (duva.sjd.se [IPv6:2001:9b0:1:1702::100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 463871A02FF for ; Thu, 11 Sep 2014 14:47:05 -0700 (PDT) Received: from latte.josefsson.org ([IPv6:2001:16d8:cca1:0:f5e7:75f1:56cd:f062]) (authenticated bits=0) by duva.sjd.se (8.14.4/8.14.4/Debian-4) with ESMTP id s8BLl0K4017573 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 11 Sep 2014 23:47:03 +0200 X-Hashcash: 1:22:140911:tls@ietf.org::glSgFHF774R+fz4G:2zLr From: Simon Josefsson To: tls@ietf.org OpenPGP: id=54265E8C; url=http://josefsson.org/54265e8c.txt Date: Thu, 11 Sep 2014 23:46:59 +0200 Message-ID: <878ulprfsc.fsf@latte.josefsson.org> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" X-Virus-Scanned: clamav-milter 0.98.4 at duva.sjd.se X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4sv_zlhx7yoC-l-eVlp2nNtE944 Subject: [TLS] Curve25519 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 11 Sep 2014 21:47:22 -0000 --=-=-= Content-Type: text/plain Hi again, I've updated our TLS-Curve25519 document to reference the recent draft-turner-thecurve25519function document. https://tools.ietf.org/html/draft-josefsson-tls-curve25519-06 I encourage implementers to let everyone know what their status is. Thanks, Simon --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJUEhhTAAoJEIYLf7sy+BGdVIcH/15spD6tHqfXFlr6zK0e3dZb ddUzuiYivdlWTskdI4thZG0mgtPzid68x6JV5sSrVO8Dr0Zmi6zFoqfb3DXJTnnV a285e3W4g0N9mc04dLOh6nxt4HZDKwFCjRHzJNU04vi/NAaSLPul7TCvsAjUfa6T 6P6wHuYCEwuScS95pAYQec0s4AWzzQ9atGEnQIosM4nnkzJoO5Cr79mzy+SXzxJt M4eka3wxDH3UxSSwhyjqnX2cccCRpFnCYQ+VcBins0uDXtNR6kBbW4EGK9uhIj4a Zmk3+pK+yCXkbzed8lN58GhNNvM7iZ9O6MxoX6HN7QLEUTOl+/ZeioR1dUiHPrE= =EY1X -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Sep 11 20:12:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44A091A0364 for ; Thu, 11 Sep 2014 20:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TKPLYa44sPJ for ; Thu, 11 Sep 2014 20:12:17 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAD181A0368 for ; Thu, 11 Sep 2014 20:12:16 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id mc6so135994lab.31 for ; Thu, 11 Sep 2014 20:12:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Vmk3jPQBL5nWjMufK4TAtW11mSU27mps3G3B61B+yAU=; b=fKv2QybnL4l/Dqei7Ex9d432ncc34uIjiiv6EQBMkFseV74+cUJdtN8rVl5bdORSYN yVqU9jjMk4YklIgoJLsJIXMc3zml7fwYPKsy4GPIhT7feQzPDvDeuhk3nBiSCPQVrQ/N JwRP+LkvMiPE5OII7kiIyokTv9VnunStuHF5bcBm3EhWpBQyCUnEDyPntPjAMvciu7fz I80eYgdI3N2djHm2yAjFggozJ2JOWsjBawcVnS3SZ9ueXI/SnwtWD/0F0Z63rqNkToOW lSyvwk1gTBjP7PH9QKh8D9wyxi9SaK1CAayUTXG+aQlUFU1jTMvAWWjUkmRCwso/tVVI yvOw== X-Received: by 10.152.8.165 with SMTP id s5mr5550905laa.3.1410491534887; Thu, 11 Sep 2014 20:12:14 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.16.135 with HTTP; Thu, 11 Sep 2014 20:11:44 -0700 (PDT) In-Reply-To: References: <5409E00D.1070703@fifthhorseman.net> From: Hugo Krawczyk Date: Thu, 11 Sep 2014 23:11:44 -0400 X-Google-Sender-Auth: UhQZpr3Wm1WKyrNyYBkBAhMJ1pI Message-ID: To: Eric Rescorla Content-Type: multipart/alternative; boundary=089e0153807ae554850502d5a632 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/m564kruHYrm6oFpHmyk_4IOqcvI Cc: Markulf Kohlweiss , "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 12 Sep 2014 03:12:21 -0000 --089e0153807ae554850502d5a632 Content-Type: text/plain; charset=UTF-8 Sorry for the long post. Beyond the specifics of the changes for TLS 1.3, I want to address the question of to-encrypt-or-not encrypt the Finish message. The question is not just a philosophical, stylistic or indicating how lazy cryptographers are when coming to analyze a protocol (it sounds like that from some of the "inconvenience" comments), but it rather touches on fundamental approaches to designing secure protocols (and systems). There is no problem encrypting the Finish msgs with a key derived from the master secret for that purpose AS LONG AS the key for encrypting application data is also derived from the master secret ms in a "computationally independent" way (i.e., in both cases you use ms as a PRF key but the inputs for deriving each type of key are different). What if Finish is encrypted under the same key as used for application data? Depending on how you do it, it can be fine or it can break security. What is surely broken is *modularity*. In a modular design you design a key exchange protocol (KEP) responsible for creating, sharing, and deriving keys for the endpoints to the communication. Then these keys are used to encrypt/authenticate application data. If the KEP is (generically) secure then you can design the application layer security under the abstraction than the parties start with a fresh secure shared key. This separation helps design, analysis, protocol maintenance and, very importantly, robustness. That is, better resistance to future changes in the protocol. When both KEP and application protocol are dependent in the details of each other, it is easy to break security and TLS has a great track record doing that. Let me exemplify how encrypting the Finish message breaks the generic security of the protocol, hence also its modularity. By generic security I mean that you can use the key output by the KEP with any security application without regards to what that application does. All you need to know is that the application is secure if the parties use a secret pre-shared key. So consider the following application: Alice and Bob exchange a key which is then used for triggering some action at Bob (attack, buy, sell, go to sleep, etc.). The trigger for Bob is defined as getting a message that is encrypted and authenticated with the key shared with Alice, regardless of the plaintext in that message. If such a msg is received by Bob, it takes the action. This is perfectly secure since only Alice can send such a message and which message she sends is immaterial as long as it is authenticated by the shared key. If the KEP that was used to share the key was generically secure, then the composition of KEP and this application is secure. In turn, if it was a protocol utilizing the application's key to also encrypt one of the KEP messages (e.g. TLS's Finish) then the protocol is fully insecure. Indeed, the attacker can replay the encrypted Finish (which is also authenticated) and trigger Bob's action even if Alice did not intend to do so. I can hear some voices: that's nice but this is not TLS. Correct. But also correct is that generic security is lost. There is necessarily a dependency between the KEP and the specifics of the application protocol. You change one, you need to re-assess security and maybe change the other. You want to add some functionality to the shared key, you need to re-assess security. You want to generate further keys, you need to check for dependencies. And guess what, all the works analyzing TLS do all these things one way or the other. Sometimes taking care of the dependencies; sometimes modeling things in a way that breaks dependent stuff into separate pieces and showing that these pieces interact nicely; sometimes just ignoring some details too complex for correct modeling, etc. It is all the product of non-generic security, of broken modularity. It is a design that invites shortcuts, patches, confusion, failures. What is the upside? So beyond the encrypt-or-not-encrypt dilemma what this shows is that one needs a clean modular cryptographic design and an equally clean proof. Design from scratch, not by patch. Ouch. Hugo On Thu, Sep 11, 2014 at 4:36 PM, Eric Rescorla wrote: > > > On Thu, Sep 11, 2014 at 1:33 PM, Douglas Stebila > wrote: > >> On Sep 2, 2014, at 11:03 AM, Markulf Kohlweiss >> wrote: >> > * To remove distraction and be closer to standard models like Bellare & >> Rogaway, we would prefer unencrypted finished messages. In practice this >> means that the finished message should be sent before the ChangeCipherSuite >> message. >> >> On Sep 11, 2014, at 8:04 PM, Eric Rescorla wrote: >> > Given that we are encrypting the rest of the handshake in TLS 1.3, >> exempting just Finished seems problematic. >> >> I see no strong reason, cryptographically, to prefer unencrypted or >> encrypted Finished messages either way. It's true that unencrypted >> Finished messages make it easier to prove a secure channel property by >> using the traditional cryptographic approach of concatenating key exchange >> and authenticated encryption. But that is just one way to build a secure >> channel, and we now know how to prove TLS is a secure channel even without >> the clear separation between the handshake and the channel encryption. So >> with our current state of the art proof techniques, encrypted Finished >> messages are now a relatively minor inconvenience in proofs. >> >> Normal key exchange security definitions rely on indistinguishability of >> the session key: once the key exchange is complete, if you give the >> adversary either the real session key or a random one, can she tell which >> she was given? The encrypted Finished messages make it tricky because the >> Finished message has a recognizable format: the first byte of the Finished >> message is the TLS content type, for example. Decryption using a random >> key would with high probability yield something not in that format. >> Exempting the Finished message but encrypting other parts of the handshake >> with the session key would not fix the problem, as the other handshake >> messages would still have a recognizable format. >> >> To me, there is far more benefit gained from encrypting handshake >> messages compared to the minor inconvenience to cryptographers trying to >> prove security. >> >> On Sep 11, 2014, at 8:04 PM, Eric Rescorla wrote: >> > In Toronto we discussed deriving different keys for handshake >> encryption and application data encryption. Would that also resolve the >> issue here? >> >> Unclear to me. My gut tells me the proof would probably go through >> either way, but I'd have to check. It's also unclear to me whether this >> offers any benefit -- intuitively it feels like there's a nice "functional >> separation" that comes from encrypting application data with a separate key >> from handshake data, but cryptographically there's probably not much >> difference since they both are derived from the same master secret key. >> >> If I were to make two changes in TLS 1.3 for the purposes of improving >> cryptographic proofs, they would be >> 1) to include the hash of the transcript in the derivation of the master >> secret as has already been proposed (so that something can be proved about >> session resumption), and >> > > I believe (and the WG chairs can correct me) that this change has consensus > and there is a Github issue to make the change. > > > 2) to fix the signature in signed-DH by signing the full transcript >> (fixing the Mavrogiannopoulos cross-ciphersuite attack) and moving the >> server signature to a separate CertificateVerify message just before the >> [ChangeCipherSpec] (getting rid of the pesky Oracle-DH assumption in the >> proofs). > > > A version of this change is already there. However CertificateVerify now > comes *after* CCS because otherwise we can't encrypt the certificate. > > -Ekr > > >> >> Douglas > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --089e0153807ae554850502d5a632 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sorry for the long post.

Beyond the spec= ifics of the changes for TLS 1.3, I want to address the question of to-encr= ypt-or-not encrypt the Finish message. The question is not just a philosoph= ical, stylistic or indicating how lazy cryptographers are when coming to an= alyze a protocol (it sounds like that from some of the "inconvenience&= quot; comments), but it rather touches on fundamental approaches to designi= ng secure protocols (and systems).

There is no problem encrypting th= e Finish msgs with a key derived from the master secret for that purpose AS= LONG AS the key for encrypting application data is also derived from the m= aster secret ms in a "computationally independent" way (i.e., in = both cases you use ms as a PRF key but the inputs for deriving each type of= key are different). What if Finish is encrypted under the same key as used= for application data? Depending on how you do it, it can be fine or it can= break security. What is surely broken is *modularity*.

In a modula= r design you design a key exchange protocol (KEP) responsible for creating,= sharing, and deriving keys for the endpoints to the communication. Then th= ese keys are used to encrypt/authenticate application data. If the KEP is (= generically) secure then you can design the application layer security unde= r the abstraction than the parties start with a fresh secure shared key. Th= is separation helps design, analysis, protocol maintenance and, very import= antly, robustness. That is, better resistance to future changes in the prot= ocol. When both KEP and application protocol are dependent in the details o= f each other, it is easy to break security and TLS has a great track record= doing that.

Let me exemplify how encrypting the Fi= nish message breaks the generic security of the protocol, hence also its mo= dularity.
By generic security I mean that you can use t= he key output by the KEP with any security application without regards to w= hat that application does. All you need to know is that the application is = secure if the parties use a secret pre-shared key.

So consider the f= ollowing application: Alice and Bob exchange a key which is then used for t= riggering some action at Bob (attack, buy, sell, go to sleep, etc.). The tr= igger for Bob is defined as getting a message that is encrypted and authent= icated with the key shared with Alice, regardless of the plaintext in that = message. If such a msg is received by Bob, it takes the action. This is per= fectly secure since only Alice can send such a message and which message sh= e sends is immaterial as long as it is authenticated by the shared key. If = the KEP that was used to share the key was generically secure, then the com= position of KEP and this application is secure. In turn, if it was a protoc= ol utilizing the application's key to also encrypt one of the KEP messa= ges (e.g. TLS's Finish) then the protocol is fully insecure. Indeed, th= e attacker can replay the encrypted Finish (which is also authenticated) an= d trigger Bob's action even if Alice did not intend to do so.

I can hear some voices: that's nice but this is not TLS.= Correct. But also correct is that generic security is lost. There is neces= sarily a dependency between the KEP and the specifics of the application pr= otocol. You change one, you need to re-assess security and maybe change the= other. You want to add some functionality to the shared key, you need to r= e-assess security. You want to generate further keys, you need to check for= dependencies. And guess what, all the works analyzing TLS do all these thi= ngs one way or the other. Sometimes taking care of the dependencies; someti= mes modeling things in a way that breaks dependent stuff into separate piec= es and showing that these pieces interact nicely; sometimes just ignoring s= ome details too complex for correct modeling, etc. It is all the product of= non-generic security, of broken modularity. It is a design that invites sh= ortcuts, patches, confusion, failures. What is the upside?

So beyond the encrypt-or-not-encrypt dilemma what this shows is tha= t one needs a clean modular cryptographic design and an equally clean proof= .

Design from scratch, not by patch. Ouch.

=
Hugo



On Thu, Sep 11, 2014 at 4:36 P= M, Eric Rescorla <ekr@rtfm.com> wrote:


On Thu, Sep 11, 2014 at 1:33 PM, Douglas Stebi= la <stebila@qut.edu.au> wrote:
On Sep 2, 2014, at 11:03 AM, Markulf Kohlweiss <markulf@microsoft.com>= ; wrote:
> * To remove distraction and be closer to standard models like Bellare = & Rogaway, we would prefer unencrypted finished messages. In practice t= his means that the finished message should be sent before the ChangeCipherS= uite message.

On Sep 11, 2014, at 8:04 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> Given that we are encrypting the rest of the handshake in TLS 1.3, exe= mpting just Finished seems problematic.

I see no strong reason, cryptographically, to prefer unencrypted or = encrypted Finished messages either way.=C2=A0 It's true that unencrypte= d Finished messages make it easier to prove a secure channel property by us= ing the traditional cryptographic approach of concatenating key exchange an= d authenticated encryption.=C2=A0 But that is just one way to build a secur= e channel, and we now know how to prove TLS is a secure channel even withou= t the clear separation between the handshake and the channel encryption.=C2= =A0 So with our current state of the art proof techniques, encrypted Finish= ed messages are now a relatively minor inconvenience in proofs.

Normal key exchange security definitions rely on indistinguishability of th= e session key: once the key exchange is complete, if you give the adversary= either the real session key or a random one, can she tell which she was gi= ven?=C2=A0 The encrypted Finished messages make it tricky because the Finis= hed message has a recognizable format: the first byte of the Finished messa= ge is the TLS content type, for example.=C2=A0 Decryption using a random ke= y would with high probability yield something not in that format.=C2=A0 Exe= mpting the Finished message but encrypting other parts of the handshake wit= h the session key would not fix the problem, as the other handshake message= s would still have a recognizable format.

To me, there is far more benefit gained from encrypting handshake messages = compared to the minor inconvenience to cryptographers trying to prove secur= ity.

On Sep 11, 2014, at 8:04 PM, Eric Rescorla <ekr@rtfm.com> wrote:
> In Toronto we discussed deriving different keys for handshake encrypti= on and application data encryption. Would that also resolve the issue here?=

Unclear to me.=C2=A0 My gut tells me the proof would probably go thr= ough either way, but I'd have to check.=C2=A0 It's also unclear to = me whether this offers any benefit -- intuitively it feels like there's= a nice "functional separation" that comes from encrypting applic= ation data with a separate key from handshake data, but cryptographically t= here's probably not much difference since they both are derived from th= e same master secret key.

If I were to make two changes in TLS 1.3 for the purposes of improving cryp= tographic proofs, they would be
1) to include the hash of the transcript in the derivation of the master se= cret as has already been proposed (so that something can be proved about se= ssion resumption), and

I believe= (and the WG chairs can correct me) that this change has consensus
and there is a Github issue to make the change.


2) to fix the signature in signed-DH by signing the full transcript (fixing= the Mavrogiannopoulos cross-ciphersuite attack) and moving the server sign= ature to a separate CertificateVerify message just before the [ChangeCipher= Spec] (getting rid of the pesky Oracle-DH assumption in the proofs).

A version of this change is already there.= However CertificateVerify now
comes *after* CCS because otherwis= e we can't encrypt the certificate.

-Ekr
=
=C2=A0

Douglas


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


--089e0153807ae554850502d5a632-- From nobody Thu Sep 11 20:35:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4DDB1A03A2 for ; Thu, 11 Sep 2014 20:35:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.554 X-Spam-Level: X-Spam-Status: No, score=-103.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DGn3awhKg8Yf for ; Thu, 11 Sep 2014 20:35:23 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7CA1A039C for ; Thu, 11 Sep 2014 20:35:23 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 24D7F180015; Thu, 11 Sep 2014 20:35:04 -0700 (PDT) To: tim@dierks.org, ekr@rtfm.com, stephen.farrell@cs.tcd.ie, Kathleen.Moriarty.ietf@gmail.com, turners@ieca.com, jsalowey@cisco.com X-PHP-Originating-Script: 6000:errata_mail_lib.php From: RFC Errata System Message-Id: <20140912033504.24D7F180015@rfc-editor.org> Date: Thu, 11 Sep 2014 20:35:04 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-0KLXAq59gELMy8JlPAj9IfESw4 Cc: rfc-editor@rfc-editor.org, radix@twistedmatrix.com, tls@ietf.org Subject: [TLS] [Technical Errata Reported] RFC5246 (4109) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 12 Sep 2014 03:35:25 -0000 The following errata report has been submitted for RFC5246, "The Transport Layer Security (TLS) Protocol Version 1.2". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=5246&eid=4109 -------------------------------------- Type: Technical Reported by: Christopher Armstrong Section: A.4.2 Original Text ------------- opaque ASN.1Cert<2^24-1>; Corrected Text -------------- opaque ASN.1Cert<1..2^24-1>; Notes ----- The appendix definition of ASN.1Cert leaves out the floor of the variable-length vector, which must be specified according to the vector syntax specification in section 4.3. Fortunately, the original definition of ASN.1Cert in section 7.4.2 does specify the floor as 1, so the definition in A.4.2 should be updated to match. Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC5246 (draft-ietf-tls-rfc4346-bis-10) -------------------------------------- Title : The Transport Layer Security (TLS) Protocol Version 1.2 Publication Date : August 2008 Author(s) : T. Dierks, E. Rescorla Category : PROPOSED STANDARD Source : Transport Layer Security Area : Security Stream : IETF Verifying Party : IESG From nobody Thu Sep 11 21:01:36 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383DA1A036B for ; Thu, 11 Sep 2014 21:01:35 -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=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igfcnKPeYA4y for ; Thu, 11 Sep 2014 21:01:33 -0700 (PDT) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CD001A0262 for ; Thu, 11 Sep 2014 21:01:33 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id e4so266786wiv.3 for ; Thu, 11 Sep 2014 21:01:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=gn2Bcgj0Q8Esbyn//sKua/9TcO4uaHMPtX2F1BwIk08=; b=ljkaiRiuOwzZ/HcHkDW1AXbDsvIxhxvyJ28j4DbxsXcbqZiXGDAg28WGhRma/QJnp5 i3sbpFQV0yAcSBuQptUAawIIO7Uz2xPvsrJLckrY4EbvTr8MofNPXIp/7IzVT4WE6WEs 2Qvuzn0h4HI89VA2dW9rfeFZ6SK01PPQCd0/cL5ESJTj9J0PL8U+/Zks/oAIRkPq5vC6 JPnXMKK6OKAiMHp2D1GxZE/Q7HMHHBwgRB6cMSIFoohBxi+ZwfF8o95EeHt6bLhoyUU1 PDpX15EBcuA4CA1uuMSjnwbAcX6rK18pZ0RnT6CwUs+BpALQ29yVwXXeAr5wYaFxb6Hy pZRQ== X-Gm-Message-State: ALoCoQmTdzDLLYPO1hjS4SmS3WLq7rjL0TgL6ZMS2OGknF09gZ2MfD5QQXCmQf9jp2let9fu0qID X-Received: by 10.194.205.102 with SMTP id lf6mr7194849wjc.112.1410494491864; Thu, 11 Sep 2014 21:01:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.146.194 with HTTP; Thu, 11 Sep 2014 21:00:51 -0700 (PDT) In-Reply-To: References: <5409E00D.1070703@fifthhorseman.net> From: Eric Rescorla Date: Thu, 11 Sep 2014 21:00:51 -0700 Message-ID: To: Hugo Krawczyk Content-Type: multipart/alternative; boundary=047d7bb03d802543f10502d657ac Archived-At: http://mailarchive.ietf.org/arch/msg/tls/azyX81r4HgXLfBRFf7GvsnU760k Cc: Markulf Kohlweiss , "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 12 Sep 2014 04:01:35 -0000 --047d7bb03d802543f10502d657ac Content-Type: text/plain; charset=UTF-8 On Thu, Sep 11, 2014 at 8:11 PM, Hugo Krawczyk wrote: > Sorry for the long post. > > Beyond the specifics of the changes for TLS 1.3, I want to address the > question of to-encrypt-or-not encrypt the Finish message. The question is > not just a philosophical, stylistic or indicating how lazy cryptographers > are when coming to analyze a protocol (it sounds like that from some of the > "inconvenience" comments), but it rather touches on fundamental approaches > to designing secure protocols (and systems). > > There is no problem encrypting the Finish msgs with a key derived from the > master secret for that purpose AS LONG AS the key for encrypting > application data is also derived from the master secret ms in a > "computationally independent" way (i.e., in both cases you use ms as a PRF > key but the inputs for deriving each type of key are different). What if > Finish is encrypted under the same key as used for application data? > Depending on how you do it, it can be fine or it can break security. What > is surely broken is *modularity*. > Hugo, thanks for your message.... FWIW, I don't see an inherent with problem with changing TLS to use separate key for encrypting the handshake messages from the application layer messages. -Ekr --047d7bb03d802543f10502d657ac Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Sep 11, 2014 at 8:11 PM, Hugo Krawczyk <hugo@ee.technion.= ac.il> wrote:
Sorry for= the long post.

Beyond the specifics of the changes for TLS 1.3, I w= ant to address the question of to-encrypt-or-not encrypt the Finish message= . The question is not just a philosophical, stylistic or indicating how laz= y cryptographers are when coming to analyze a protocol (it sounds like that= from some of the "inconvenience" comments), but it rather touche= s on fundamental approaches to designing secure protocols (and systems).
There is no problem encrypting the Finish msgs with a key derived from= the master secret for that purpose AS LONG AS the key for encrypting appli= cation data is also derived from the master secret ms in a "computatio= nally independent" way (i.e., in both cases you use ms as a PRF key bu= t the inputs for deriving each type of key are different). What if Finish i= s encrypted under the same key as used for application data? Depending on h= ow you do it, it can be fine or it can break security. What is surely broke= n is *modularity*.

Hugo, t= hanks for your message....

FWIW, I don't see a= n inherent with problem with changing TLS to use
separate key= for encrypting the handshake messages from the
application layer= messages.

-Ekr

--047d7bb03d802543f10502d657ac-- From nobody Thu Sep 11 23:17:07 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D88E1A064C for ; Thu, 11 Sep 2014 23:17:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MVQMv9vhRY-R for ; Thu, 11 Sep 2014 23:17:03 -0700 (PDT) Received: from mail-oi0-x22e.google.com (mail-oi0-x22e.google.com [IPv6:2607:f8b0:4003:c06::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83B921A0459 for ; Thu, 11 Sep 2014 23:17:03 -0700 (PDT) Received: by mail-oi0-f46.google.com with SMTP id g201so188509oib.33 for ; Thu, 11 Sep 2014 23:17:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Bri+kWBsOu7Z7u0RDtzjVJeukwIdqDzsoOr2Qn+Y0f4=; b=OzS7+WN0MBsmPk4aWHkav6ZCDXiLAPy2QpXCfXOErCC+eXSayeNS1xQEnLiUf0CvYX +kKblPgWk7SsByKlya/2RMWFEUPHko6jHDZmA6qIXEGO6faP2klT7/dzMFfVZ8sZw7CE vvYiRvsqmhWMaEkY8KdKDHmyIHblkfv44jUEQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Bri+kWBsOu7Z7u0RDtzjVJeukwIdqDzsoOr2Qn+Y0f4=; b=kyqs36smMvPOnk0Ftr9IAhyU4OLSRcA2cRXtc0FOjFbTd7qkN4XxStesEoj9BvWrQr Yiv7xAkwe3TajUcxWVijpsHPkfGHt1rS+pvpcXiD/e7Bz3gV8FKeYLRQf6+xoYhenG5l jxyLZ43+4c/O374fFKNxk+AmbzQCWBN2oWKMvXsejAJb9EGLjWv/bhCxkUk0etl0bTOy l46ESbU2w6CCqqL8e6DAtKM/Er63HCnKeghEiHC24mPKU4KEUdRo/Vv8IjuLMXQF75CQ QvWdiVXwrc1b9X7SPvUCuXPChy+HGkO9Cy1GRMg0rbx2UQw41LqlhXcpOyiIouF+C2Q2 Xtvw== X-Gm-Message-State: ALoCoQkT9gaqPSkFnh3ItiypWZMPZOqRufXAxPSJslNAjUz8ZuzKhXfsnuslJ6DPcPPSAZTcikBh MIME-Version: 1.0 X-Received: by 10.60.78.132 with SMTP id b4mr6151047oex.21.1410502622776; Thu, 11 Sep 2014 23:17:02 -0700 (PDT) Received: by 10.76.90.168 with HTTP; Thu, 11 Sep 2014 23:17:02 -0700 (PDT) X-Originating-IP: [82.224.193.99] In-Reply-To: References: <5409E00D.1070703@fifthhorseman.net> Date: Fri, 12 Sep 2014 08:17:02 +0200 Message-ID: From: Alfredo Pironti To: Eric Rescorla Content-Type: multipart/alternative; boundary=089e0111d7d2c929360502d83b02 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QnyW20h-w34MeapbO8JFph8z9jI Cc: Markulf Kohlweiss , "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 12 Sep 2014 06:17:05 -0000 --089e0111d7d2c929360502d83b02 Content-Type: text/plain; charset=UTF-8 Using different encryption keys for application data and handshake messages gives the attacker a distinguishability argument, especially if we go for the content type encryption. The TLS record layer is a protocol that multiplexes several streams (handsake, alerts, app data...). In isolation, it does it correctly (when a proper AEAD scheme is used). This is a valuable feature of the protocol that gives us a chance to get more privacy, and we should not give it up using different keys for each stream. What has historically been wrong in TLS is that it uses the record layer keys too early, before the Finished messages confirm them. So, it's more important to define different keys for messages sent before (and crucially including) the Finished message, and different, confirmed keys for all the record layer encryption than comes afterward. In TLS <= 1.2 this is easy to do: move the finish messages before CCS (hence the first set of keys is the NULL key for the first handshake). >From my understanding of the current TLS 1.3 draft: the server and client key exchange messages are used to derive ephemeral keys to protect the first handshake; hence one should derive and use different record layer encryption keys after the finished messages are exchanged (and yes, such keys should depend on the full transcript of the handshake) Alfredo On Fri, Sep 12, 2014 at 6:00 AM, Eric Rescorla wrote: > > > On Thu, Sep 11, 2014 at 8:11 PM, Hugo Krawczyk > wrote: > >> Sorry for the long post. >> >> Beyond the specifics of the changes for TLS 1.3, I want to address the >> question of to-encrypt-or-not encrypt the Finish message. The question is >> not just a philosophical, stylistic or indicating how lazy cryptographers >> are when coming to analyze a protocol (it sounds like that from some of the >> "inconvenience" comments), but it rather touches on fundamental approaches >> to designing secure protocols (and systems). >> >> There is no problem encrypting the Finish msgs with a key derived from >> the master secret for that purpose AS LONG AS the key for encrypting >> application data is also derived from the master secret ms in a >> "computationally independent" way (i.e., in both cases you use ms as a PRF >> key but the inputs for deriving each type of key are different). What if >> Finish is encrypted under the same key as used for application data? >> Depending on how you do it, it can be fine or it can break security. What >> is surely broken is *modularity*. >> > > Hugo, thanks for your message.... > > FWIW, I don't see an inherent with problem with changing TLS to use > separate key for encrypting the handshake messages from the > application layer messages. > > -Ekr > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --089e0111d7d2c929360502d83b02 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Using different encryption keys f= or application data and handshake messages gives the attacker a distinguish= ability argument, especially if we go for the content type encryption.
<= br>
The TLS record layer is a protocol that multiplexes several stream= s (handsake, alerts, app data...). In isolation, it does it correctly (when= a proper AEAD scheme is used). This is a valuable feature of the protocol = that gives us a chance to get more privacy, and we should not give it up us= ing different keys for each stream.

What has historically been= wrong in TLS is that it uses the record layer keys too early, before the F= inished messages confirm them. So, it's more important to define differ= ent keys for messages sent before (and crucially including) the Finished me= ssage, and different, confirmed keys for all the record layer encryption th= an comes afterward.

In TLS <=3D 1.2 this is easy to do: mov= e the finish messages before CCS (hence the first set of keys is the NULL k= ey for the first handshake).

From my understanding of the curr= ent TLS 1.3 draft: the server and client key exchange messages are used to = derive ephemeral keys to protect the first handshake; hence one should deri= ve and use different record layer encryption keys after the finished messag= es are exchanged (and yes, such keys should depend on the full transcript o= f the handshake)

Alfredo
<= br>
On Fri, Sep 12, 2014 at 6:00 AM, Eric Rescorl= a <e= kr@rtfm.com> wrote:


On Thu, Sep 11, 2014 at 8:11 PM, Hugo Krawczyk <hugo@ee= .technion.ac.il> wrote:
Sorry for the long post.

Beyond the specifics of the changes for TL= S 1.3, I want to address the question of to-encrypt-or-not encrypt the Fini= sh message. The question is not just a philosophical, stylistic or indicati= ng how lazy cryptographers are when coming to analyze a protocol (it sounds= like that from some of the "inconvenience" comments), but it rat= her touches on fundamental approaches to designing secure protocols (and sy= stems).

There is no problem encrypting the Finish msgs with a key de= rived from the master secret for that purpose AS LONG AS the key for encryp= ting application data is also derived from the master secret ms in a "= computationally independent" way (i.e., in both cases you use ms as a = PRF key but the inputs for deriving each type of key are different). What i= f Finish is encrypted under the same key as used for application data? Depe= nding on how you do it, it can be fine or it can break security. What is su= rely broken is *modularity*.

Hugo, thanks for your message....

FWIW, = I don't see an inherent with problem with changing TLS to use
=
separate key for encrypting the handshake messages from the
= application layer messages.

-Ekr


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


--089e0111d7d2c929360502d83b02-- From nobody Fri Sep 12 06:11:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E4E41A02B9 for ; Fri, 12 Sep 2014 06:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.953 X-Spam-Level: X-Spam-Status: No, score=-3.953 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eE48gEugr7xw for ; Fri, 12 Sep 2014 06:11:35 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52E911A0298 for ; Fri, 12 Sep 2014 06:11:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1410527497; x=1442063497; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=E05wGgoMO+67APqPj7WBS2BlHGPHGNuCmEF52iAdPOE=; b=oxIGRFjrmTNygrW5geJgn9u9VkUGQGEosNazZsoh7rHnbaZjnKjihTlx 0QMmk/DVnetjyCYhKfcNYBMbfcRtCsIZ6AiA47/4iNzwGnmVHtjqqgCo/ fso7Lf2nJSHpBs5qQT1Js2syfIPrcwitFhCqqlVFQnO7v0YY4WYP0r+oP Y=; X-IronPort-AV: E=Sophos;i="5.04,513,1406548800"; d="scan'208";a="275663916" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.106 - Outgoing - Outgoing Received: from uxchange10-fe2.uoa.auckland.ac.nz ([130.216.4.106]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 13 Sep 2014 01:11:34 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.70]) by uxchange10-fe2.UoA.auckland.ac.nz ([169.254.27.86]) with mapi id 14.03.0174.001; Sat, 13 Sep 2014 01:11:32 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] signature_algorithms extension definition Thread-Index: Ac/OixGVj+194Y2CSPW8EKrfJVNMYg== Date: Fri, 12 Sep 2014 13:11:30 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9AFFE3@uxcn10-tdc05.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2sX9zerfeKpFlsYV1DSe-eAf0c4 Subject: Re: [TLS] signature_algorithms extension definition X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 12 Sep 2014 13:11:40 -0000 Adam Langley writes:=0A= =0A= >I just didn't realise that the signature_algorithms extension was supposed= to=0A= >apply to more than just the TLS handshake.=0A= =0A= This issue already came up several years ago, triggered by a comment by Mar= tin=0A= Rex:=0A= =0A= >It is *MUCH* worse than that.=0A= >=0A= >TLSv1.2 goes as far as _requiring_ that if the signature_algorithm extensi= on=0A= >is sent, that the receiver MUST ensure that all certificates in the chain = are=0A= >from the signature_algorithm set.=0A= >=0A= >That is not just shooting yourself in the foot, that is shooting "the whol= e=0A= >nine yards" (the entire ammunition belt) in your foot.=0A= =0A= My response was:=0A= =0A= >Just out of interest, how are other implemeters dealing with this? I look= ed=0A= >at that requirement in the spec, decided it was totally crazy, and ignored= =0A= >it. So far I haven't found any other TLS 1.2 implementation (of the very = few=0A= >that are around) that has any problems with this, so my guess is everyone= =0A= >else is ignoring it as well.=0A= =0A= Of the implementers who responded to this at the time, all of them took the= =0A= very sensible step of ignoring the requirement. Quoting Martin Rex again:= =0A= =0A= >[TLS 1.2] adds several undue limitations and interop problems to the proto= col=0A= >that did not exist in TLSv1.0 and v1.1, that are technically inappropriate= ,=0A= >completely unnecessary and in massive conflict with rfc-2119 section 6.=0A= >=0A= >The TLS spec should not mess around with PKI and X.509 issues. Negotiation= of=0A= >the algorithm used for the "digitally signed" struct ought to be _complete= ly_=0A= >seperate from characteristics of certificates.=0A= =0A= Given that there's no obvious positive contribution provided by this=0A= requirement and serious interop problems added if you adhere to it, ignorin= g=0A= it, as implementers at the time indicated they were doing, seems like the= =0A= sensible approach.=0A= =0A= Peter.= From nobody Fri Sep 12 06:15:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED011A023F for ; Fri, 12 Sep 2014 06:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lxvZfEzileVA for ; Fri, 12 Sep 2014 06:15:24 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6062E1A0298 for ; Fri, 12 Sep 2014 06:15:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1410527725; x=1442063725; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=5a6ZVnyhwzRynFouqUcBcezpP2sfSooRO5YWYZ1ek04=; b=e5M8Mo7PAdzzhhz01FDB8GCDHbsMu1cnH6kMhaKD6pn4z7CDUnTBEKls h7raPkaaFgxoE9nHnJy5nuY/hsTnrx9dR3Fc60XmGrv+A6rRL7RQ6cdcA ciBwdPkgtz5eEqrz/+PMr7Z2of5k66MLUCIS76UOtQUAuuRcPxrpADKFw o=; X-IronPort-AV: E=Sophos;i="5.04,513,1406548800"; d="scan'208";a="275664197" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.125 - Outgoing - Outgoing Received: from uxchange10-fe3.uoa.auckland.ac.nz ([130.216.4.125]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 13 Sep 2014 01:15:23 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.70]) by uxchange10-fe3.UoA.auckland.ac.nz ([130.216.4.125]) with mapi id 14.03.0174.001; Sat, 13 Sep 2014 01:15:21 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] signature_algorithms extension definition Thread-Index: Ac/Oi5qbV6KhVPwdQ0uXse2UT67a0g== Date: Fri, 12 Sep 2014 13:15:20 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9AFFF8@uxcn10-tdc05.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YnsU9heSmEHIa-CjIeYy3Rp9lCE Subject: Re: [TLS] signature_algorithms extension definition X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 12 Sep 2014 13:15:25 -0000 Peter Bowen writes:=0A= =0A= >Why do you say it is ignored?=0A= =0A= See my previous message, when this last came up all of the implemeters who= =0A= responded said they ignored it because it made no sense and hindered=0A= interoperability.=0A= =0A= Peter.=0A= From nobody Fri Sep 12 06:46:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E03CE1A6F03 for ; Fri, 12 Sep 2014 06:46:37 -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=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQXXdezhGltH for ; Fri, 12 Sep 2014 06:46:35 -0700 (PDT) Received: from mail-wg0-f51.google.com (mail-wg0-f51.google.com [74.125.82.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDA221A6EFC for ; Fri, 12 Sep 2014 06:46:26 -0700 (PDT) Received: by mail-wg0-f51.google.com with SMTP id k14so751348wgh.22 for ; Fri, 12 Sep 2014 06:46:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=aULgtqQRdKeQK3VkUSCJy9eliWnHwCkU0hs4ga/KnWM=; b=iwxRUPQp7XVe/E5L67UE7Xxv4mhHmqKGAt4dmby0IGASXcnY0okFht12ZjZy+Ai3a4 TefWeI+JDReZBU9t0LhUPTaFvBOtpbG7nUVa+D5cv3bc8QRs8TCr32eWarVef5LHy6VW M4Q4K4n69P1abNI7kj20wBwxHgxvFQ9JRFxTDTUlTq2L+2e9SflchfJl8WaSiqrpOWAd op+WB4yhbySk92ZktsM0yfq4CFQeMv6NViUIdji9i/J9TPxVOkcvKjqYqAoW7vTZAAxb iNn5paeX7yyTx38rRVvKHOnX9VbtqoKCef4Za58WUsp+zSlYGqOuBtXFe+fGdZh4gqp0 6cpg== X-Gm-Message-State: ALoCoQnNKBmtD4FkMHNrFXOCwJGwU02fr9egq/W4zxDLhq8brNHzZ6LirZXIWH+BfQHdrS3mSIWO X-Received: by 10.180.189.14 with SMTP id ge14mr2592982wic.36.1410529578069; Fri, 12 Sep 2014 06:46:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.146.194 with HTTP; Fri, 12 Sep 2014 06:45:37 -0700 (PDT) In-Reply-To: <20140911144704.6F4571AE3F@ld9781.wdf.sap.corp> References: <1410426957.17386.9.camel@dhcp-2-127.brq.redhat.com> <20140911144704.6F4571AE3F@ld9781.wdf.sap.corp> From: Eric Rescorla Date: Fri, 12 Sep 2014 06:45:37 -0700 Message-ID: To: "mrex@sap.com" Content-Type: multipart/alternative; boundary=001a11c22852724dc60502de8276 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/izEuAijCbMd2liHIAPmU3EU7L5M Cc: "tls@ietf.org" Subject: Re: [TLS] signature_algorithms extension definition X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 12 Sep 2014 13:46:38 -0000 --001a11c22852724dc60502de8276 Content-Type: text/plain; charset=UTF-8 On Thu, Sep 11, 2014 at 7:47 AM, Martin Rex wrote: > Nikos Mavrogiannopoulos wrote: > > On Wed, 2014-09-10 at 09:21 -0700, Peter Bowen wrote: > > > The TLS 1.2 RFC is a little ambiguous on the meaning of the contents > > > of the signature_algorithms extension when included in a ClientHello > > > message. It says "pairs [which] may be used in digital signatures" > > > and "pair[s] that the client is willing to verify". Later on it says > > > "If the client provided a 'signature_algorithms' extension, then all > > > certificates provided by the server MUST be signed by a hash/signature > > > algorithm pair that appears in that extension." > > > > The second sentence is ignored by implementations, as there is no way to > > enforce it. The server has no way to switch the signatures in his > > certificates. The certificates are provided by a third party (the CA), > > which is not participating in the handshake in order to modify the > > certificates. It would be a good thing if the latter sentence was > > dropped in the new TLS 1.3 specification, or at least switched to MAY. > > +1 > > Similar to the TLS server_name_indication extension, the signature > algorithms listed in the signature algorithms extension should be > merely a hint for the server to select the _best_fit_ server certificate > (chains) from those server certificates that it has available (which > may be few, or just one). > > If the TLS client has specific (policy) requirements on acceptable > algorithms, the client will have to perform his own checks in any > case, and it would be entirely unreasonable for the server to > preempt the clients decision whether to continue (best effort style), > with or without confirmation from an interactive user at the client. > It's important to distinguish between requirements on the server and requirements on the client: - The point of the extension is to guide certificate selection on the server (or the client in the case of client Certificates) so it's appropriate to have a normative requirement encouraging the server to conform. In the current text this is a MUST but if there's some good reason to relax it to a SHOULD we could certainly do so. It's not clear to me what that reason is, though. Modulo bugs is there some reason why a client would advertise support for signature algorithms X and Y when it actually supports X, Y, and Z? - I agree that it's probably not necessary for the client to enforce the server's conformance with the extension. However -- and maybe I'm missing something here -- I don't see where in the text it is required to do so. A requirement that the server MUST do something is not a requirement that the client check it. For instance, it's quite common to have reserved fields which must be set to a given value but ignored on the other side, as in [0]. -Ekr [0] http://tools.ietf.org/html/rfc4733#section-2.3.3 --001a11c22852724dc60502de8276 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Sep 11, 2014 at 7:47 AM, Martin Rex <mrex@sap.com> wr= ote:
Nikos Mavrogiannopoulos wrote: > On Wed, 2014-09-10 at 09:21 -0700, Peter Bowen wrote:
> > The TLS 1.2 RFC is a little ambiguous on the meaning of the conte= nts
> > of the signature_algorithms extension when included in a ClientHe= llo
> > message.=C2=A0 It says "pairs [which] may be used in digital= signatures"
> > and "pair[s] that the client is willing to verify".=C2= =A0 Later on it says
> > "If the client provided a 'signature_algorithms' ext= ension, then all
> > certificates provided by the server MUST be signed by a hash/sign= ature
> > algorithm pair that appears in that extension."
>
> The second sentence is ignored by implementations, as there is no way = to
> enforce it. The server has no way to switch the signatures in his
> certificates. The certificates are provided by a third party (the CA),=
> which is not participating in the handshake in order to modify the
> certificates. It would be a good thing if the latter sentence was
> dropped in the new TLS 1.3 specification, or at least switched to MAY.=

+1

Similar to the TLS server_name_indication extension, the signature
algorithms listed in the signature algorithms extension should be
merely a hint for the server to select the _best_fit_ server certificate (chains) from those server certificates that it has available (which
may be few, or just one).

If the TLS client has specific (policy) requirements on acceptable
algorithms, the client will have to perform his own checks in any
case, and it would be entirely unreasonable for the server to
preempt the clients decision whether to continue (best effort style),
with or without confirmation from an interactive user at the client.

It's important to distinguish between req= uirements on the server and
requirements on the client:

- The point of the extension is to guide certificate select= ion on the server
=C2=A0 (or the client in the case of client Cer= tificates) so it's appropriate to have
=C2=A0 a normative req= uirement encouraging the server to conform. In the current
=C2=A0= text this is a MUST but if there's some good reason to relax it to a S= HOULD
=C2=A0 we could certainly do so. It's not clear to me w= hat that reason is, though.
=C2=A0 Modulo bugs is there some reas= on why a client would advertise support
=C2=A0 for signature algo= rithms X and Y when it actually supports X, Y, and Z?

<= div>- I agree that it's probably not necessary for the client to enforc= e the
=C2=A0 server's conformance with the extension. However= -- and maybe I'm
=C2=A0 missing something here -- I don'= t see where in the text it is required
=C2=A0 to do so. A require= ment that the server MUST do something is not a
=C2=A0 requiremen= t that the client check it. For instance, it's quite common
= =C2=A0 to have reserved fields which must be set to a given value but
=
=C2=A0 ignored on the other side, as in [0].

= -Ekr

--001a11c22852724dc60502de8276-- From nobody Fri Sep 12 07:04:46 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D29B51A6F2A for ; Fri, 12 Sep 2014 07:04:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6rmdID6lLAsq for ; Fri, 12 Sep 2014 07:04:39 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [72.246.2.115]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9121A6ED8 for ; Fri, 12 Sep 2014 07:04:39 -0700 (PDT) Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id CC559476B5; Fri, 12 Sep 2014 14:04:38 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id BCA15476B4; Fri, 12 Sep 2014 14:04:38 +0000 (GMT) Received: from ustx2ex-cashub.dfw01.corp.akamai.com (ustx2ex-cashub2.dfw01.corp.akamai.com [172.27.25.76]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id A16902054; Fri, 12 Sep 2014 14:04:38 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.2.28]) by ustx2ex-cashub2.dfw01.corp.akamai.com ([172.27.25.76]) with mapi; Fri, 12 Sep 2014 09:04:37 -0500 From: "Salz, Rich" To: Peter Gutmann , "" Date: Fri, 12 Sep 2014 09:04:37 -0500 Thread-Topic: [TLS] signature_algorithms extension definition Thread-Index: Ac/Oi5qbV6KhVPwdQ0uXse2UT67a0gABq4tQ Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D2E1B065A@USMBX1.msg.corp.akamai.com> References: <9A043F3CF02CD34C8E74AC1594475C739B9AFFF8@uxcn10-tdc05.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9AFFF8@uxcn10-tdc05.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/CX6KST02lMT2Jk6TqVYOBomHYQw Subject: Re: [TLS] signature_algorithms extension definition X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 12 Sep 2014 14:04:44 -0000 =20 > See my previous message, when this last came up all of the implemeters > who responded said they ignored it because it made no sense and hindered > interoperability. Times change, and I think Google is now forcing the issue because of their = SHA1 deprecation. At least those of us who serve old and new clients need h= ints on which cert chains to serve. From nobody Fri Sep 12 07:13:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC23A1A0686 for ; Fri, 12 Sep 2014 07:13:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.554 X-Spam-Level: X-Spam-Status: No, score=-8.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtsDMVxbjK07 for ; Fri, 12 Sep 2014 07:13:34 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0B321A006A for ; Fri, 12 Sep 2014 07:13:33 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8CEDVtS021846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 12 Sep 2014 10:13:31 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8CEDT8i020074 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 12 Sep 2014 10:13:30 -0400 Message-ID: <1410531209.2594.22.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: "Salz, Rich" Date: Fri, 12 Sep 2014 16:13:29 +0200 In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D2E1B065A@USMBX1.msg.corp.akamai.com> References: <9A043F3CF02CD34C8E74AC1594475C739B9AFFF8@uxcn10-tdc05.UoA.auckland.ac.nz> <2A0EFB9C05D0164E98F19BB0AF3708C71D2E1B065A@USMBX1.msg.corp.akamai.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SyqGiX7WdCZrtK93MmOH7w-v4Cw Cc: tls@ietf.org Subject: Re: [TLS] signature_algorithms extension definition X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 12 Sep 2014 14:13:38 -0000 On Fri, 2014-09-12 at 09:04 -0500, Salz, Rich wrote: > > See my previous message, when this last came up all of the implemeters > > who responded said they ignored it because it made no sense and hindered > > interoperability. > > Times change, and I think Google is now forcing the issue because of their SHA1 deprecation. At least those of us who serve old and new clients need hints on which cert chains to serve. I believe that the comments were on the "MUST" requirement, and the fact that it is ignored. Having it as a SHOULD or MAY may be a good thing, as the servers with choice could select, but having a MUST requirement for servers with no choice is pointless. regards, Nikos From nobody Fri Sep 12 07:26:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 198841A00AB for ; Fri, 12 Sep 2014 07:26:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYwFkh9_viUw for ; Fri, 12 Sep 2014 07:26:13 -0700 (PDT) Received: from mx2.auckland.ac.nz (mx2.auckland.ac.nz [130.216.125.245]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDE4F1A0054 for ; Fri, 12 Sep 2014 07:26:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=auckland.ac.nz; i=@auckland.ac.nz; q=dns/txt; s=uoa; t=1410531973; x=1442067973; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=Uu0yiEWVDRAW0xS5pwVnbMUrTaFwO3B8Joc8PFxZ+p8=; b=bre/5IahpQVlLr5FIL3I7js0VHvIBhPKic/WjfUNbniSEwl6VebrSGi0 XglxKvvZ7nVseegq68Ib/4Ga2fw0sSyB/yiKd9QMfgydVGwCG9cgou7lS gpZpFDkW6BRmM/sOOV2MDH2sgzwsdgIHC6xHP02cMjSl6qqFoK3CCjsYE M=; X-IronPort-AV: E=Sophos;i="5.04,513,1406548800"; d="scan'208";a="275669702" X-Ironport-HAT: MAIL-SERVERS - $RELAYED X-Ironport-Source: 130.216.4.171 - Outgoing - Outgoing Received: from uxchange10-fe4.uoa.auckland.ac.nz ([130.216.4.171]) by mx2-int.auckland.ac.nz with ESMTP/TLS/AES128-SHA; 13 Sep 2014 02:26:07 +1200 Received: from UXCN10-TDC05.UoA.auckland.ac.nz ([169.254.9.70]) by uxchange10-fe4.UoA.auckland.ac.nz ([169.254.109.63]) with mapi id 14.03.0174.001; Sat, 13 Sep 2014 02:26:07 +1200 From: Peter Gutmann To: "" Thread-Topic: [TLS] signature_algorithms extension definition Thread-Index: Ac/OlX2l3P3EbzKQTcm8sqt9PPSm/A== Date: Fri, 12 Sep 2014 14:26:07 +0000 Message-ID: <9A043F3CF02CD34C8E74AC1594475C739B9B0085@uxcn10-tdc05.UoA.auckland.ac.nz> Accept-Language: en-NZ, en-GB, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [130.216.158.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gxCokThqRQsINJjp-o_qI-0JV3Q Subject: Re: [TLS] signature_algorithms extension definition X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 12 Sep 2014 14:26:16 -0000 "Salz, Rich" writes:=0A= =0A= >Times change, and I think Google is now forcing the issue because of their= =0A= >SHA1 deprecation. At least those of us who serve old and new clients need= =0A= >hints on which cert chains to serve.=0A= =0A= But in that case it's a hint, not a MUST. At most it should be a MAY, alon= g=0A= with a note saying what its intended purpose is (in other words to clarify= =0A= that there's some intent there, rather than just "here's an arbitrary silly= -=0A= walk that you need to perform to claim compliance with the spec"). Given= =0A= without any explanation as it currently is, it just looks like a=0A= pointless/illogical requirement that should be ignored.=0A= =0A= Even if a client says "I only want to do SHA256", if I've only got a SHA1 c= ert=0A= I'm going to go ahead and serve that because it's better than the alternati= ve,=0A= which is not interoperating. Presumably the immediate next step will be th= e=0A= client reconnecting in plaintext-only because "there's a problem with the= =0A= server, TLS doesn't work".=0A= =0A= Peter.= From nobody Fri Sep 12 07:55:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1815D1A006A for ; Fri, 12 Sep 2014 07:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.852 X-Spam-Level: X-Spam-Status: No, score=-5.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ly8Z8IpmtbHP for ; Fri, 12 Sep 2014 07:55:55 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (prod-mail-xrelay02.akamai.com [72.246.2.14]) by ietfa.amsl.com (Postfix) with ESMTP id 8C5781A6F14 for ; Fri, 12 Sep 2014 07:55:54 -0700 (PDT) Received: from prod-mail-xrelay02.akamai.com (localhost [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id BE0DC285C8; Fri, 12 Sep 2014 14:55:53 +0000 (GMT) Received: from prod-mail-relay06.akamai.com (prod-mail-relay06.akamai.com [172.17.120.126]) by prod-mail-xrelay02.akamai.com (Postfix) with ESMTP id AA6DD28558; Fri, 12 Sep 2014 14:55:53 +0000 (GMT) Received: from ustx2ex-cashub.dfw01.corp.akamai.com (ustx2ex-cashub7.dfw01.corp.akamai.com [172.27.25.73]) by prod-mail-relay06.akamai.com (Postfix) with ESMTP id 8FBDB204F; Fri, 12 Sep 2014 14:55:53 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.2.28]) by ustx2ex-cashub7.dfw01.corp.akamai.com ([172.27.25.73]) with mapi; Fri, 12 Sep 2014 09:55:52 -0500 From: "Salz, Rich" To: Peter Gutmann , "" Date: Fri, 12 Sep 2014 09:55:52 -0500 Thread-Topic: [TLS] signature_algorithms extension definition Thread-Index: Ac/OlX2l3P3EbzKQTcm8sqt9PPSm/AABBddg Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D2E1B06A0@USMBX1.msg.corp.akamai.com> References: <9A043F3CF02CD34C8E74AC1594475C739B9B0085@uxcn10-tdc05.UoA.auckland.ac.nz> In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C739B9B0085@uxcn10-tdc05.UoA.auckland.ac.nz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qkRnvEJL_m6OkqMdZJF5MVzYVOI Subject: Re: [TLS] signature_algorithms extension definition X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 12 Sep 2014 14:55:56 -0000 > But in that case it's a hint, not a MUST. At most it should be a MAY, al= ong Sure, I'm fine with that.=20 -- =20 Principal Security Engineer, Akamai Technologies IM: rsalz@jabber.me Twitter: RichSalz From nobody Fri Sep 12 08:00:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F6381A6F52 for ; Fri, 12 Sep 2014 08:00:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.554 X-Spam-Level: X-Spam-Status: No, score=-8.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KLapk0zCVZOw for ; Fri, 12 Sep 2014 08:00:46 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 680D11A06D8 for ; Fri, 12 Sep 2014 08:00:39 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8CF0bKY020757 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 12 Sep 2014 11:00:38 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8CF0Zam014276 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Fri, 12 Sep 2014 11:00:36 -0400 Message-ID: <1410534034.2594.27.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Eric Rescorla Date: Fri, 12 Sep 2014 17:00:34 +0200 In-Reply-To: References: <1410426957.17386.9.camel@dhcp-2-127.brq.redhat.com> <20140911144704.6F4571AE3F@ld9781.wdf.sap.corp> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JKcHhZQvBGZv-rWOJMoOZSNTOK4 Cc: "tls@ietf.org" Subject: Re: [TLS] signature_algorithms extension definition X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 12 Sep 2014 15:00:48 -0000 On Fri, 2014-09-12 at 06:45 -0700, Eric Rescorla wrote: > > > On Thu, Sep 11, 2014 at 7:47 AM, Martin Rex wrote: > Nikos Mavrogiannopoulos wrote: > > On Wed, 2014-09-10 at 09:21 -0700, Peter Bowen wrote: > > > The TLS 1.2 RFC is a little ambiguous on the meaning of > the contents > > > of the signature_algorithms extension when included in a > ClientHello > > > message. It says "pairs [which] may be used in digital > signatures" > > > and "pair[s] that the client is willing to verify". Later > on it says > > > "If the client provided a 'signature_algorithms' > extension, then all > > > certificates provided by the server MUST be signed by a > hash/signature > > > algorithm pair that appears in that extension." > > > > The second sentence is ignored by implementations, as there > is no way to > > enforce it. The server has no way to switch the signatures > in his > > certificates. The certificates are provided by a third party > (the CA), > > which is not participating in the handshake in order to > modify the > > certificates. It would be a good thing if the latter > sentence was > > dropped in the new TLS 1.3 specification, or at least > switched to MAY. > > +1 > > Similar to the TLS server_name_indication extension, the > signature > algorithms listed in the signature algorithms extension should > be > merely a hint for the server to select the _best_fit_ server > certificate > (chains) from those server certificates that it has available > (which > may be few, or just one). > > If the TLS client has specific (policy) requirements on > acceptable > algorithms, the client will have to perform his own checks in > any > case, and it would be entirely unreasonable for the server to > preempt the clients decision whether to continue (best effort > style), > with or without confirmation from an interactive user at the > client. > It's important to distinguish between requirements on the server and > requirements on the client: > - The point of the extension is to guide certificate selection on the > server > (or the client in the case of client Certificates) so it's > appropriate to have > a normative requirement encouraging the server to conform. In the > current > text this is a MUST but if there's some good reason to relax it to a > SHOULD > we could certainly do so. It's not clear to me what that reason is, > though. A scenario where the MUST would have have prevented interoperation: "A client which supports SHA256 and SHA1 is configured to ask RSA-SHA1 as signature algorithm. It connects to the server. The server's certificate is signed with SHA256. According to the text above the server shouldn't send his certificate to the client, as he cannot comply with the MUST. So the server terminates the handshake to comply with the spec, even though the client could have been able to verify the certificate." regards, Nikos From nobody Fri Sep 12 08:26:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A7C01A0721 for ; Fri, 12 Sep 2014 08:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BMLuYnPAIVGo for ; Fri, 12 Sep 2014 08:25:57 -0700 (PDT) Received: from mail-yk0-x22d.google.com (mail-yk0-x22d.google.com [IPv6:2607:f8b0:4002:c07::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28BFF1A6F14 for ; Fri, 12 Sep 2014 08:25:56 -0700 (PDT) Received: by mail-yk0-f173.google.com with SMTP id 19so501446ykq.32 for ; Fri, 12 Sep 2014 08:25:56 -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=DstmRNPzsyQj6RGh8FmDuEYLWsPORvlD1Fa1MhsuvXw=; b=XjGbb6Obeyi3SgQTXtNdXp6ePP4alhPiHxRoTnZzSczVTFW6IxfN6gHVC9ZLXZx1CC N1cShPBcbguEwRyfw3C9FGOecCk9bIYr91DLL+UpAJK14/K0vM/KibhLY+EDx/Y0iJMc R5RHHV6Ov51Yj51Q5aRQe/ILDELqm7sCOf+ThW+qCzpfa7YYa3esT8TLR9tF2J31g3/6 3WLyq2WpMRVQQ0tB6m4uTXVxUno8SQtd2LiHZEZL08yrvrJAfVTHwO/jysZvA0GsF/Vf B+0HRM3n6HyUpEGiVhJz1wHAEke+6+tMp90q8nqVrZsTtyLjESGLkg2ABSIG/hU7TZ77 c9sw== MIME-Version: 1.0 X-Received: by 10.236.26.196 with SMTP id c44mr10674206yha.15.1410535556084; Fri, 12 Sep 2014 08:25:56 -0700 (PDT) Received: by 10.170.207.216 with HTTP; Fri, 12 Sep 2014 08:25:55 -0700 (PDT) In-Reply-To: References: <5409E00D.1070703@fifthhorseman.net> Date: Fri, 12 Sep 2014 08:25:55 -0700 Message-ID: From: Watson Ladd To: Hugo Krawczyk Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/4Gw-2TU4qrxYKmewPygfyhCasb4 Cc: Markulf Kohlweiss , "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 12 Sep 2014 15:26:00 -0000 On Thu, Sep 11, 2014 at 8:11 PM, Hugo Krawczyk wrote: > Sorry for the long post. The S/N ratio more than justifies the consumption of bandwidth. > > I can hear some voices: that's nice but this is not TLS. Correct. But also > correct is that generic security is lost. There is necessarily a dependency > between the KEP and the specifics of the application protocol. You change > one, you need to re-assess security and maybe change the other. You want to > add some functionality to the shared key, you need to re-assess security. > You want to generate further keys, you need to check for dependencies. And > guess what, all the works analyzing TLS do all these things one way or the > other. Sometimes taking care of the dependencies; sometimes modeling things > in a way that breaks dependent stuff into separate pieces and showing that > these pieces interact nicely; sometimes just ignoring some details too > complex for correct modeling, etc. It is all the product of non-generic > security, of broken modularity. It is a design that invites shortcuts, > patches, confusion, failures. What is the upside? Let me note that some IETF protocols do exactly this: RFC 5764 comes to mind. I don't think the security analysis was redone for it. Furthermore, there are a bunch of interactions with GSSAPI that are non-obvious. Channel binding and connection-specific cookies also come to mind as features that require more thought than was put into them the first time. Furthermore, it's not just TLS 1.3 we need to get right. It's TLS 1.3 plus this little-known extension that does X, plus this one that does Y, minus this other extension doing Z. There is no reason we cannot meet the privacy and round-trip goals while maintaining modularity. Modularity will also make things like post-quantum enhancements much easier than they would be today: the current proofs rely on nonstandard assumptions, which may or may not be true for primitives meeting standard assumptions, so any change requires some nasty analysis. > > So beyond the encrypt-or-not-encrypt dilemma what this shows is that one > needs a clean modular cryptographic design and an equally clean proof. > > Design from scratch, not by patch. Ouch. Or just go take one of the many, many, authenticated key agreement protocols from the literature and use it. > > Hugo > > Sincerely, Watson Ladd > > On Thu, Sep 11, 2014 at 4:36 PM, Eric Rescorla wrote: >> >> >> >> On Thu, Sep 11, 2014 at 1:33 PM, Douglas Stebila >> wrote: >>> >>> On Sep 2, 2014, at 11:03 AM, Markulf Kohlweiss >>> wrote: >>> > * To remove distraction and be closer to standard models like Bellare & >>> > Rogaway, we would prefer unencrypted finished messages. In practice this >>> > means that the finished message should be sent before the ChangeCipherSuite >>> > message. >>> >>> On Sep 11, 2014, at 8:04 PM, Eric Rescorla wrote: >>> > Given that we are encrypting the rest of the handshake in TLS 1.3, >>> > exempting just Finished seems problematic. >>> >>> I see no strong reason, cryptographically, to prefer unencrypted or >>> encrypted Finished messages either way. It's true that unencrypted Finished >>> messages make it easier to prove a secure channel property by using the >>> traditional cryptographic approach of concatenating key exchange and >>> authenticated encryption. But that is just one way to build a secure >>> channel, and we now know how to prove TLS is a secure channel even without >>> the clear separation between the handshake and the channel encryption. So >>> with our current state of the art proof techniques, encrypted Finished >>> messages are now a relatively minor inconvenience in proofs. >>> >>> Normal key exchange security definitions rely on indistinguishability of >>> the session key: once the key exchange is complete, if you give the >>> adversary either the real session key or a random one, can she tell which >>> she was given? The encrypted Finished messages make it tricky because the >>> Finished message has a recognizable format: the first byte of the Finished >>> message is the TLS content type, for example. Decryption using a random key >>> would with high probability yield something not in that format. Exempting >>> the Finished message but encrypting other parts of the handshake with the >>> session key would not fix the problem, as the other handshake messages would >>> still have a recognizable format. >>> >>> To me, there is far more benefit gained from encrypting handshake >>> messages compared to the minor inconvenience to cryptographers trying to >>> prove security. >>> >>> On Sep 11, 2014, at 8:04 PM, Eric Rescorla wrote: >>> > In Toronto we discussed deriving different keys for handshake >>> > encryption and application data encryption. Would that also resolve the >>> > issue here? >>> >>> Unclear to me. My gut tells me the proof would probably go through >>> either way, but I'd have to check. It's also unclear to me whether this >>> offers any benefit -- intuitively it feels like there's a nice "functional >>> separation" that comes from encrypting application data with a separate key >>> from handshake data, but cryptographically there's probably not much >>> difference since they both are derived from the same master secret key. >>> >>> If I were to make two changes in TLS 1.3 for the purposes of improving >>> cryptographic proofs, they would be >>> 1) to include the hash of the transcript in the derivation of the master >>> secret as has already been proposed (so that something can be proved about >>> session resumption), and >> >> >> I believe (and the WG chairs can correct me) that this change has >> consensus >> and there is a Github issue to make the change. >> >> >>> 2) to fix the signature in signed-DH by signing the full transcript >>> (fixing the Mavrogiannopoulos cross-ciphersuite attack) and moving the >>> server signature to a separate CertificateVerify message just before the >>> [ChangeCipherSpec] (getting rid of the pesky Oracle-DH assumption in the >>> proofs). >> >> >> A version of this change is already there. However CertificateVerify now >> comes *after* CCS because otherwise we can't encrypt the certificate. >> >> -Ekr >> >>> >>> >>> Douglas >> >> >> >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls >> > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Fri Sep 12 08:31:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BDAC1A6F17 for ; Fri, 12 Sep 2014 08:31:14 -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=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7T2Yjaw9uMg3 for ; Fri, 12 Sep 2014 08:31:12 -0700 (PDT) Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36F251A0AA3 for ; Fri, 12 Sep 2014 08:31:12 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id n12so876354wgh.17 for ; Fri, 12 Sep 2014 08:31:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=Ba92IG+s1767dk9OXRBd7bN5cUJlFF6SngXZ9SAkut4=; b=g95hDwapJFp62dZDtV0BSyG9VMyuG43jaPOudw4DbDOZoP/b8dbUHSa9V+4HdtktlY 7e6s2Prq4vI7VQ4SN7OhQTJQ3XBdynKD6pMuSuWfH/vB/y+0gCdqMX/mqrDv49/VbGey xpKfyGPhq40m40A4YT3ldteaoisaW8gPokwixLjH6SoAXHuZTZBBGtiYXBrSgbX13E5C 8TTzfpkE27yqmhYaQIje3Q0Wt5AHQlaEaEKwuVW+vgtMmGpb6xbwhYGWs+GDfLhfRRcD 0hx8/lL4rOUeRtsStBiHljChs/7IHbJWFKFcVzGe6lYF1x4C17ln6TGavm8s50OLuQin EY2g== X-Gm-Message-State: ALoCoQmDEV2rvRpuPFbgtDUbLxcPlPBRIwEgsKeHCsYL3cyrt9yLI8LcBVodDxuTcX9+7oHQQcKm X-Received: by 10.194.185.81 with SMTP id fa17mr12407418wjc.114.1410535869081; Fri, 12 Sep 2014 08:31:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.146.194 with HTTP; Fri, 12 Sep 2014 08:30:28 -0700 (PDT) In-Reply-To: <1410534034.2594.27.camel@dhcp-2-127.brq.redhat.com> References: <1410426957.17386.9.camel@dhcp-2-127.brq.redhat.com> <20140911144704.6F4571AE3F@ld9781.wdf.sap.corp> <1410534034.2594.27.camel@dhcp-2-127.brq.redhat.com> From: Eric Rescorla Date: Fri, 12 Sep 2014 08:30:28 -0700 Message-ID: To: Nikos Mavrogiannopoulos Content-Type: multipart/alternative; boundary=047d7bae49566b84fe0502dff927 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-v7Fw4eMCYfKZScgqOJ2Q-Cdk68 Cc: "tls@ietf.org" Subject: Re: [TLS] signature_algorithms extension definition X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 12 Sep 2014 15:31:14 -0000 --047d7bae49566b84fe0502dff927 Content-Type: text/plain; charset=UTF-8 On Fri, Sep 12, 2014 at 8:00 AM, Nikos Mavrogiannopoulos wrote: > > A scenario where the MUST would have have prevented interoperation: > "A client which supports SHA256 and SHA1 is configured to ask RSA-SHA1 > as signature algorithm. It connects to the server. The server's > certificate is signed with SHA256. According to the text above the > server shouldn't send his certificate to the client, as he cannot comply > with the MUST. So the server terminates the handshake to comply with the > spec, even though the client could have been able to verify the > certificate." > Can you help me understand how we get into that scenario? I.e., why did the client send RSA-SHA1 if it supported SHA256? I'm trying to figure out what the general governing principle is here. For instance, RFC 4492 requires that the server respect the client's supported curve extension http://tools.ietf.org/html/rfc4492#section-5.3: " The server constructs an appropriate certificate chain and conveys it to the client in the Certificate message. If the client has used a Supported Elliptic Curves Extension, the public key in the server's certificate MUST respect the client's choice of elliptic curves; in particular, the public key MUST employ a named curve (not the same curve as an explicit curve) unless the client has indicated support for explicit curves of the appropriate type. If the client has used a Supported Point Formats Extension, both the server's public key point and (in the case of an explicit curve) the curve's base point MUST respect the client's choice of point formats. (A server that cannot satisfy these requirements MUST NOT choose an ECC cipher suite in its ServerHello message.)" Do you believe that these MUSTs and MUST NOTs are inappropriate? If not, can you explain what the difference is here? Thanks, -Ekr --047d7bae49566b84fe0502dff927 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Sep 12, 2014 at 8:00 AM, Nikos Mavrogiannopoulos <nmav@redhat.co= m> wrote:

A scenario where the MUST would have have prevented interoperat= ion:
"A client which supports SHA256 and SHA1 is configured to ask RSA-SHA1=
as signature algorithm. It connects to the server. The server's
certificate is signed with SHA256. According to the text above the
server shouldn't send his certificate to the client, as he cannot compl= y
with the MUST. So the server terminates the handshake to comply with the spec, even though the client could have been able to verify the
certificate."

Can you help me unde= rstand how we get into that scenario? I.e., why did the
client se= nd RSA-SHA1 if it supported SHA256?


I'm trying to figure out what the general governing principle is here.= For
instance, RFC 4492 requires that the server respect the clie= nt's supported

" The server constructs= an appropriate certificate chain and conveys it
   to the client in the=
 Certificate message.  If the client has used a
   Supported Elliptic Curves Extension, the public key in the server's
   certificate MUST respect the client's choice of elliptic curves; in
   particular, the public key MUST employ a named curve (not the same
   curve as an explicit curve) unless the client has indicated support
   for explicit curves of the appropriate type.  If the client has used
   a Supported Point Formats Extension, both the server's public key
   point and (in the case of an explicit curve) the curve's base point
   MUST respect the client's choice of point formats.  (A server that
   cannot satisfy these requirements MUST NOT choose an ECC cipher suite
   in its ServerHello message.)"

= 
Do you believe t=
hat these MUSTs and MUST NOTs are inappropriate?
If not, can you explain what t=
he difference is here?

Thanks,
-Ekr

--047d7bae49566b84fe0502dff927-- From nobody Fri Sep 12 09:01:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D999C1A00A3 for ; Fri, 12 Sep 2014 09:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zH3nr4ptiXzY for ; Fri, 12 Sep 2014 09:01:03 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99F371A06B0 for ; Fri, 12 Sep 2014 09:01:03 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 0CA6570451; Fri, 12 Sep 2014 18:01:00 +0200 (CEST) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 48AC74247C; Fri, 12 Sep 2014 18:01:01 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 41BA11AE42; Fri, 12 Sep 2014 18:01:01 +0200 (CEST) In-Reply-To: To: Watson Ladd Date: Fri, 12 Sep 2014 18:01:01 +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: <20140912160101.41BA11AE42@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/9EMkl3qnejEMaS2CpLWH30skNHE Cc: Markulf Kohlweiss , tls@ietf.org Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 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: Fri, 12 Sep 2014 16:01:06 -0000 Watson Ladd wrote: > "Martin Rex" wrote: >>> >>> Yes, this seems like it shouldn't matter. Intuition is not >>> a reliable guide to protocol security: did you discover Triple >>> Handshake? >> >> The triple handshake problem would have been fairly impossible to miss, >> if one really cared to look for it. The problem with the TLS spec is >> that information is scattered out all over the place, which makes it >> much more difficult to see its real properties. >> Such as the problem that the TLS master secret is computed from only >> the three inputs "premaster_secret", "ClientHello.random" and >> "ServerHello.random" and not cryptographically bound to the handshake >> (message hash) or the identities exchanged/established during the >> handshake. > > Why didn't you find it then? Because I never looked for such problems in the first place! I was _not_ doing any kind of review of the TLS protocol (of which I knew fairly little back then) when I noticed the MITM susceptibility of the TLS renegotiation handshake. It was a simply by-product of the discussion of TLS channel bindings on the TLS mailing list, after I had collected and wrote down that there was exactly no cryptographic binding between the Connection state (aka traffic protection keys) of the existing TLS session and the Connection state of the newly renegotiated session. After writing that down and looking at what I wrote, the issue and its consequences jumped right at me. At that point, I hadn't looked at the details of the computation of the TLS master secret, and wasn't aware of a similar lack of binding of the master secret to the handshake (message hash) and the resulting consequences of that shortcoming. In the TLS implementation for which I had maintenance responsibility, I hardwired renegotiation attemps to a fatal handshake failure on the server side back then (I had never exposed that possibility to applications, because I had never felt comfortable with this significantly underspecified TLS protocol feature, so I could easily remove it without paperwork.) -Martin From nobody Fri Sep 12 09:18:24 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A591A00A3 for ; Fri, 12 Sep 2014 09:18: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=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Aaa5YKxzw-m for ; Fri, 12 Sep 2014 09:18:17 -0700 (PDT) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93CE71A6F82 for ; Fri, 12 Sep 2014 09:18:15 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id r5so976835qcx.40 for ; Fri, 12 Sep 2014 09:18:11 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=ay5K9LA4xhibthWVeKV9aXGE6a8QF6P3Am3s77ff7wE=; b=Z0jak7pacGdlJ7oftU9KUWeEggQBewRVQKscGuioqcrR+aD+7sUcC0XoFQIwOIWb6x 1j35Vycms57ddXmbt9fBZqtzDVmbf36ky8lJdlXxuvXFwZdf35Jnk+lpyYoEfZF/HdXg pFWgj0QWO1QUiwH8UYFut8v8FQF3Edif/ML3HlzpIwWe7MFyUQQ3Muf9oSoez7EyUbNX beE4IPLnRwlqsgEAOI3TUC5tfy2+K1eOjDW/hnT+mwGsvszHx6nZ9txd6pTyAji/LYSt aRU+0DNAzSgnuh+qWIo4+L7o8ojj44/bhwLFAWwVsnLwoV6/KvGNvFsMypEmWVCM0rs8 H+lg== X-Gm-Message-State: ALoCoQmCRtJVmJ4eYUX0o6R4OEDrn2Bax0Pt12/UOh1sW6ttg5ziqzTXTShevzg6cs7PfNBlLeKn X-Received: by 10.140.98.196 with SMTP id o62mr11313650qge.0.1410538691530; Fri, 12 Sep 2014 09:18:11 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:344:89e:cb5c:8383:fa82? ([2601:a:2a00:344:89e:cb5c:8383:fa82]) by mx.google.com with ESMTPSA id l46sm3275173qgd.27.2014.09.12.09.18.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Sep 2014 09:18:11 -0700 (PDT) Message-ID: <54131CC5.5060103@nthpermutation.com> Date: Fri, 12 Sep 2014 12:18:13 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: tls@ietf.org References: <20140912160101.41BA11AE42@ld9781.wdf.sap.corp> In-Reply-To: <20140912160101.41BA11AE42@ld9781.wdf.sap.corp> Content-Type: multipart/alternative; boundary="------------070505050307000100040501" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ZX-GdO0axRNtm6ZJaqJx7ZIWEfk Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 12 Sep 2014 16:18:21 -0000 This is a multi-part message in MIME format. --------------070505050307000100040501 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 9/12/2014 12:01 PM, Martin Rex wrote: > At that point, I hadn't looked at the details of the computation of the > TLS master secret, and wasn't aware of a similar lack of binding > of the master secret to the handshake (message hash) and the > resulting consequences of that shortcoming. I'm probably missing something in the above, but I would say the master secret was bound to the handshake: the handshake is hashed, and that hash is signed by the master secret. If you mean that the traffic keys aren't bound to the handshake, I think that would be a more correct statement. E.g. 1. the master secret is used to sign/verify the handshake, and to create the traffic keys; 2. the handshake hash used to verify the handshake (finished message) includes data from the authentication process, but that data is not brought forward to the derivation of the traffic keys (until draft-bhargavan-tls-session-hash changes the process if adopted) Probably a nit, but important to get it right if its to be fixed efficiently and correctly. Mike --------------070505050307000100040501 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 9/12/2014 12:01 PM, Martin Rex wrote:
At that point, I hadn't looked at the details of the computation of the
TLS master secret, and wasn't aware of a similar lack of binding
of the master secret to the handshake (message hash) and the
resulting consequences of that shortcoming.

I'm probably missing something in the above, but I would say the master secret was bound to the handshake:  the handshake is hashed, and that hash is signed by the master secret.  If you mean that the traffic keys aren't bound to the handshake, I think that would be a more correct statement.  E.g.
  1. the master secret is used to sign/verify the handshake, and to create the traffic keys;
  2. the handshake hash used to verify the handshake (finished message) includes data from the authentication process, but that data is not brought forward to the derivation of the traffic keys (until draft-bhargavan-tls-session-hash changes the process if adopted)
Probably a nit, but important to get it right if its to be fixed efficiently and correctly.

Mike


--------------070505050307000100040501-- From nobody Fri Sep 12 12:22:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 324E01A802F for ; Fri, 12 Sep 2014 12:22:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZHSpv6xG_Vx for ; Fri, 12 Sep 2014 12:22:24 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 41D7A1A86E2 for ; Fri, 12 Sep 2014 12:22:22 -0700 (PDT) Received: from homiemail-a64.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTP id C818F43807C; Fri, 12 Sep 2014 12:22:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=hhHrn7thQoRtMV gEJ1llzy0KqbY=; b=WBxd1odUBClR09nkm7xu+I5LCpw0VlSBFAcmCJbbkS4kBS s8TGknhLbTkq8Lsbyd+bXBlgX0bCgG3i5/IRbBLdVF/c1E8lYQ0UINNDxm7/ADeC 3D3XxAYxjW3Etd5kputn9NkPbSzAOiGJCujCuRmrjFNniLOx+hiVMsvFoac2Y= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a64.g.dreamhost.com (Postfix) with ESMTPA id 61443438079; Fri, 12 Sep 2014 12:22:21 -0700 (PDT) Date: Fri, 12 Sep 2014 14:22:20 -0500 From: Nico Williams To: Hugo Krawczyk Message-ID: <20140912192219.GA16660@localhost> References: <5409E00D.1070703@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Uwa7LS64WRt8cMGdYgEenkOyGGU Cc: Markulf Kohlweiss , "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 12 Sep 2014 19:22:26 -0000 On Thu, Sep 11, 2014 at 11:11:44PM -0400, Hugo Krawczyk wrote: > [...]. Indeed, the attacker can replay the encrypted > Finish (which is also authenticated) and trigger Bob's action even if > Alice did not intend to do so. The key word here is "replay". Both TLS and DTLS are intended to detect replays and must continue to for other reasons anyways. Don't misunderstand me though: I'm all for key hygiene and modularity. I agree with you; I'm only picking... the nit you predicted we'd pick :) More seriously, I have a concrete example of how encrypting the Finished messages has complicated security analysis in the past. Back when we put together RFC5929 (channel binding to TLS) some reviewers argued that using unencrypted Finished messages was a bad idea because doing so might leak important information. It didn't take too much effort to put that concern to rest, but it was surprising that there was no need to encrypt them Finished messages and yet, they were. Encrypting the Finished messages may well have been a psychological crutch: a device to avoid having to prove that the Finished messages as-is were good enough. We should not have such crutches. > Design from scratch, not by patch. Ouch. I agree with this sentiment. It's not always practical though. Nico -- From nobody Fri Sep 12 12:35:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2DE1A8782 for ; Fri, 12 Sep 2014 12:35:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gAXvl4WX19Zj for ; Fri, 12 Sep 2014 12:35:34 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 30AF91A877B for ; Fri, 12 Sep 2014 12:35:31 -0700 (PDT) Received: from homiemail-a86.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTP id E665936006D; Fri, 12 Sep 2014 12:35:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=FYWaszY92+FYek uxKezcguzoSbs=; b=wlAda0Hmu2l+srXPdzP/WVDlcuDanocppUlwOhifpUm1Bj 8HD3twxweFeDvA4p9N8WvyI52BO6QkWyRylzkiCMGDf9QZRp03WMnHoHpaXJUqNK EhBDKRUcX6tYZvE4JcaxXsoTk1wKBHe+JQDedqhpZ77WrpDOrlpPEtqMz2t9I= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a86.g.dreamhost.com (Postfix) with ESMTPA id 7B046360075; Fri, 12 Sep 2014 12:35:30 -0700 (PDT) Date: Fri, 12 Sep 2014 14:35:30 -0500 From: Nico Williams To: Watson Ladd Message-ID: <20140912193528.GB16660@localhost> References: <5409E00D.1070703@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UJc619tzO5RiqBdBxqAXQQqbtgw Cc: Markulf Kohlweiss , "tls@ietf.org" Subject: [TLS] CB cryptanalysis (Re: cryptanalysis vs. encrypted parts of the TLS handshake) [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 12 Sep 2014 19:35:34 -0000 On Fri, Sep 12, 2014 at 08:25:55AM -0700, Watson Ladd wrote: > Furthermore, there are a bunch of interactions with GSSAPI that are > non-obvious. Channel binding and connection-specific cookies also come I'm not sure if you have any concerns re: GSS beyond channel bindings. Please clarify. GSS is really just an API. You might have issues with the mechanisms, such as Kerberos and ABFAB. Or you might think the API itself has issues such that it isn't possible to produce a GSS mechanism that we can analyze easily or at all, or that can be secure. Either way I would like to hear your concerns. > to mind as features that require more thought than was put into them > the first time. Furthermore, it's not just TLS 1.3 we need to get > right. It's TLS 1.3 plus this little-known extension that does X, plus > this one that does Y, minus this other extension doing Z. RFC5929 was and is fine as-is. What wasn't fine was the lack of binding in TLS session resumption and renegotiation. It *is* true that we could have noticed the problems with TLS session resumption and renegotiation _then_, but we failed to analyze TLS session resumption and renegotiation. We assumed modularity. TLS failed to provide the semantics we thought it did. This is a great example of why modularity helps where we really do have it. If you have _other_ concerns about CB, we need to hear those too! Whether in the specific details of RFC5929 (TLS CB) or in general with RFC5056, your concerns will be of great interest. Nico -- From nobody Fri Sep 12 12:58:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAF8D1A0032 for ; Fri, 12 Sep 2014 12:58:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 70JukGWsvLEh for ; Fri, 12 Sep 2014 12:58:51 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 989AB1A0040 for ; Fri, 12 Sep 2014 12:58:51 -0700 (PDT) Received: from homiemail-a24.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTP id 7105C2C806D; Fri, 12 Sep 2014 12:58:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=LdovkSa6PvOK4P AubHNpxUQSrX4=; b=x8jMUI9ZxSzXUXIGnspJmgncxB8xS7rjBwuVWPzortT9UL 3rLA5g3yCGlKFniZac8O0eAsYxedG1CXtxC/pVlgnp9/l/wqS4w4lZO+VGK3izEh QKSq2Zzz/fgJIb7fg0bekXd3cwFh/944bx9LOEIfqsJKI+X0sHINdN95TEQ6w= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a24.g.dreamhost.com (Postfix) with ESMTPA id F3BEE2C8056; Fri, 12 Sep 2014 12:58:50 -0700 (PDT) Date: Fri, 12 Sep 2014 14:58:50 -0500 From: Nico Williams To: Alfredo Pironti Message-ID: <20140912195849.GC16660@localhost> References: <5409E00D.1070703@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2tGbKAlPc5kXdF_lnf65p3Vl-rI Cc: Markulf Kohlweiss , "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 12 Sep 2014 19:58:52 -0000 On Fri, Sep 12, 2014 at 08:17:02AM +0200, Alfredo Pironti wrote: > Using different encryption keys for application data and handshake messages > gives the attacker a distinguishability argument, especially if we go for > the content type encryption. The record type goes in the clear in TLS 1.2 and less anyways. Encrypted handshake messages are *already* distinguishable from application data. That is something we absolutely should change in 1.3. In any case, encrypted messages have to be of a form like: or . The cipher and authentication had better be indistinguishable when using the same key but different plaintext, or just plain different keys. If it is then we have a problem. There have been proposals for encrypting parts of the handshake. For such proposals we'll need to derive a different key for those encrypted handshake records. Nico -- From nobody Fri Sep 12 13:03:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1893C1A00EA for ; Fri, 12 Sep 2014 13:03:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MjF6-dng7OQZ for ; Fri, 12 Sep 2014 13:03:53 -0700 (PDT) Received: from homiemail-a104.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 0F09F1A00E8 for ; Fri, 12 Sep 2014 13:03:52 -0700 (PDT) Received: from homiemail-a104.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTP id E489920047B8F; Fri, 12 Sep 2014 13:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=iWbdrI/UPonlg5 6dhkFdB59NUGk=; b=bA1EDW872rU0037nXw6m3Zu5gj2/M3y1N+LdPMaKOigz4l IHJa8NbHkStwB9sfzTTlRmHiqhojEqRlySjYueNdmKUNWO+S38Ud1EuHsoLwpYke Wa7pnytJBQ8wXnKA7S0POfYHiKgJcUtA56TSXwk59tiGO4l3sP5/GTIIUpC0w= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a104.g.dreamhost.com (Postfix) with ESMTPA id 7FE2920047B8C; Fri, 12 Sep 2014 13:03:51 -0700 (PDT) Date: Fri, 12 Sep 2014 15:03:51 -0500 From: Nico Williams To: Watson Ladd Message-ID: <20140912200349.GD16660@localhost> References: <5409E00D.1070703@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BgLLplWbfMjSPTwIfuGRIBBiGqk Cc: Markulf Kohlweiss , "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 12 Sep 2014 20:03:54 -0000 On Tue, Sep 09, 2014 at 06:37:48PM -0700, Watson Ladd wrote: > On Fri, Sep 5, 2014 at 9:08 AM, Daniel Kahn Gillmor > wrote: > > That is, would the cryptanalytic side of the community be OK with having the > > handshake messages encrypted as long as they were using keys/session > > material that are distinct from the keys/session material used for the > > application data? > > Maybe! It really depends on the details of what is going on. Look at > the history of Kerberos to see how subtle these issues can be. Certainly Hugo K. indicated that he'd be fine with that. Can you expand on the Kerberos issues? Kerberos has had (and in some cases still has) issues with: too much plaintext, the Ticket in KDC responses not being sent within nor bound into the encrypted payload of the KDC response, poor ciphers (1DES with CRC... RC4...)... But Kerberos at least does nowadays have good key hygiene, deriving sub-keys for different purposes. Nico -- From nobody Fri Sep 12 13:06:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F48D1A0068 for ; Fri, 12 Sep 2014 13:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4TPSeXfDLqXk for ; Fri, 12 Sep 2014 13:06:10 -0700 (PDT) Received: from homiemail-a110.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9BC1A00E8 for ; Fri, 12 Sep 2014 13:06:10 -0700 (PDT) Received: from homiemail-a110.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTP id EB1302007F12C; Fri, 12 Sep 2014 13:06:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=BONf+9HWvadyXI 0ta36q09ssibg=; b=uv9+JZuE70CjNrJcZarkiD70keljv/xuhvPBUZs6PhySnn QTVIdEzxmtMwwWOjhyQayIL7CI9a+BW3kDdN3SJZ4Y8ULwMGgSNymQEUjQD0RVzh 1CE4lH5q3J+4uXOqHNi61jJOIJzy2AQ3oJHFc2cbG+raSF47uH0h2n4ZL/Ows= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a110.g.dreamhost.com (Postfix) with ESMTPA id 810E72007F128; Fri, 12 Sep 2014 13:06:09 -0700 (PDT) Date: Fri, 12 Sep 2014 15:06:09 -0500 From: Nico Williams To: Martin Rex Message-ID: <20140912200607.GE16660@localhost> References: <20140911151837.EBED41AE40@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140911151837.EBED41AE40@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/q8CBx6i8_ZkqKsBF5mssAZP7YW0 Cc: Markulf Kohlweiss , "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 12 Sep 2014 20:06:11 -0000 On Thu, Sep 11, 2014 at 05:18:37PM +0200, Martin Rex wrote: > I also don't understand why the fact that TLS finished messages are > encrypted would make any proof harder. I believe that to be untrue. Hugo K.'s rationale is that you then need to have replay protection. We need replay protection anyways, but if you're only analyzing the handshake then it helps to not have to include subsequent replay protection in the analysis. Nico -- From nobody Fri Sep 12 17:19:50 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70E921A010F for ; Fri, 12 Sep 2014 17:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GIlFamFxVmr for ; Fri, 12 Sep 2014 17:19:46 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E76281A00EC for ; Fri, 12 Sep 2014 17:19:45 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id A596770E71; Sat, 13 Sep 2014 02:19:42 +0200 (CEST) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 77A59420EA; Sat, 13 Sep 2014 02:19:43 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 6EE211AE43; Sat, 13 Sep 2014 02:19:43 +0200 (CEST) In-Reply-To: To: Hugo Krawczyk Date: Sat, 13 Sep 2014 02:19:43 +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: <20140913001943.6EE211AE43@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/MqlSlVntxbW9t8yRLNTE6rmIEfE Cc: Markulf Kohlweiss , "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 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: Sat, 13 Sep 2014 00:19:48 -0000 Hugo Krawczyk wrote: > > Let me exemplify how encrypting the Finish message breaks the generic > security of the protocol, hence also its modularity. While I think that your modularity argument has a little merit, I do not buy the "generic security" idea at all, which I liken to what Jeff Schiller used to call "magic security pixie dust", because it is what has caused by far the most security goofs over the past decades. Apps can't wait to get their hands on "generic security" stuff, a number of folks seem to assume that TLS was/is/or should be the IETFs magic security pixie dust. But I do not believe you could design such a thing (at least not one that is practical to the real world IETF audience), even when starting from scratch. IPsec originally went overboard with modularization and offered integrity and confidentiality as seperate and indendent services. Maybe you should re-check how that ended. There is no such thing as generic security, and being greedy on security does not pay off. Deploying the fully backwards compatible 1/(n-1) TLS record splitting countermeasure for the paranoids that misunderstand the BEAST as a practical attack/vulnerability, would not have been possible if TLSv1.0 had not been encrypting the MAC. I've seen an implementation bug vaguely similar to OpenSSL CVE-2014-0224 (premature ChangeCipherSpec), but where the fact that the TLS finished messages are encrypted prevented that bug from becoming exploitable (because traffic protection keys computed from an empty premaster secret were only used on one of the communication directions, they keys for the other direction were properly computed. I consider using seperate/independent keys for handshake and app data a bad idea, because it will significatly increase protocol and implementation complexity _without_ adding value. And you should keep in mind just how many serious and silly bugs already affect implementations of the current TLS protocol versions in the real world. One of the downsides of spartanic theoretic cryptography is that it is often hard to support and brittle like hell. We need less of the cryptoglycerin stuff, not more of it, and stuff that is easy to implement, test and support, rather than complex stuff where the result of (interop) failures is an opaque "failed". (did you ever have to help app folks troubleshooting app bugs or weird network data corruptions that make xmldsig signature verifications fail? You might start to appreciate the properties of RSA PKCS#1 v1.5 signatures over other signature schemes). -Martin From nobody Fri Sep 12 18:35:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7601A01E6 for ; Fri, 12 Sep 2014 18:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2a6YHfagsuGI for ; Fri, 12 Sep 2014 18:35:26 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 132731A01E0 for ; Fri, 12 Sep 2014 18:35:26 -0700 (PDT) Received: by mail-yk0-f182.google.com with SMTP id 131so877554ykp.13 for ; Fri, 12 Sep 2014 18:35:25 -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=bhzsCfkQmJ4NYMjVazrTMg/TiG63Hs4693P6EBtr9m4=; b=T8zvVqeb5TsfylgOzhzR3x1D8YKs79v0tkNSNocrwaI6txqJNYQGaw9lZIQRSxzDUi fE0u0jx1Ls26hYemnYF4fKnRrL58uVAzwcxVovamL1XEDAuYNin77uLSxpbU870Q4b8G 5izM5/nJupjtgogs75wv54Eu5NtdV1dR6sZLqdlykjJq+S6qoNRdjmDBnlaQkSlrgX5B ldQ2gwBPlJsr6G91+Kg9v4ajqxa6VP8cVofWAMITZRHwQTfc2wn3ZwuIAkV6fCSTnqO3 7cCL5VV/ViGfgNY1qhixyn5k0SlE9NbVtEtKtc8h15Z79lsN7DtebUUCfBdk4iNO7UHI y+Ig== MIME-Version: 1.0 X-Received: by 10.236.111.38 with SMTP id v26mr13011744yhg.46.1410572125358; Fri, 12 Sep 2014 18:35:25 -0700 (PDT) Received: by 10.170.207.216 with HTTP; Fri, 12 Sep 2014 18:35:25 -0700 (PDT) In-Reply-To: <20140913001943.6EE211AE43@ld9781.wdf.sap.corp> References: <20140913001943.6EE211AE43@ld9781.wdf.sap.corp> Date: Fri, 12 Sep 2014 18:35:25 -0700 Message-ID: From: Watson Ladd To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kqzYB5G5FrdkuzL0jmvfpeFJFzA Cc: Markulf Kohlweiss , "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 13 Sep 2014 01:35:28 -0000 On Fri, Sep 12, 2014 at 5:19 PM, Martin Rex wrote: > Hugo Krawczyk wrote: >> >> Let me exemplify how encrypting the Finish message breaks the generic >> security of the protocol, hence also its modularity. > > While I think that your modularity argument has a little merit, > I do not buy the "generic security" idea at all, which I liken to > what Jeff Schiller used to call "magic security pixie dust", > because it is what has caused by far the most security goofs > over the past decades. TLS and SSH are the only IETF standards that provide anything close to a secure channel for applications to use. We've known what a secure key exchange should be since 1992. We've known how to compose MACs+encryption correctly since 1995. In 2014, we still can't put the two together. "Generic security" is a technical term: it means that you have a set of definitions for each component to meet, such that the composition is secure. The point Hugo is making is that the TLS does not provide a key: rather it provides a secure channel, and any application (like RFC 5764) which doesn't use the channel makes life annoying for anyone interested in analyzing the result. Furthermore, making extensions to TLS becomes something of a black art: as Douglas Stebila noted (on a different but related point) the assumptions needed are highly nonstandard, and could be weakened with very minor changes. > > Apps can't wait to get their hands on "generic security" stuff, > a number of folks seem to assume that TLS was/is/or should be the > IETFs magic security pixie dust. But I do not believe you could > design such a thing (at least not one that is practical to the > real world IETF audience), even when starting from scratch. Hugo Krawczyk is the designer of IKEv2, which does meet the generic security definition for an authenticated key exchange, and certainly is deployed. The authors of RFC5764 went out and used TLS as a key agreement protocol. It's clear that secure channels, which we /haven't/ actually provided, are of interest. Furthermore, some applications want their own transport protocols, and want a key agreement for use with them. > > > IPsec originally went overboard with modularization and offered > integrity and confidentiality as seperate and indendent services. > Maybe you should re-check how that ended. > > There is no such thing as generic security, and being greedy on > security does not pay off. > > Deploying the fully backwards compatible 1/(n-1) TLS record splitting > countermeasure for the paranoids that misunderstand the BEAST as a > practical attack/vulnerability, would not have been possible if > TLSv1.0 had not been encrypting the MAC. Wrong: see my reply to Adam Langley on this mailing list about this point: 1/n-1 record splitting is sufficient even if there is no MAC in the record layer. Of course, I tend to think an attack that steals credit card information, demoed live and onstage, is a problem, but you and I can just disagree on this point. > > I've seen an implementation bug vaguely similar to OpenSSL CVE-2014-0224 > (premature ChangeCipherSpec), but where the fact that the TLS finished > messages are encrypted prevented that bug from becoming exploitable > (because traffic protection keys computed from an empty premaster secret > were only used on one of the communication directions, they keys for > the other direction were properly computed. > > > I consider using seperate/independent keys for handshake and app data > a bad idea, because it will significatly increase protocol and implementation > complexity _without_ adding value. And you should keep in mind > just how many serious and silly bugs already affect implementations > of the current TLS protocol versions in the real world. How much complexity is another CCS message and PRF invocation? > > > One of the downsides of spartanic theoretic cryptography is that it > is often hard to support and brittle like hell. We need less > of the cryptoglycerin stuff, not more of it, and stuff that is easy > to implement, test and support, rather than complex stuff where > the result of (interop) failures is an opaque "failed". The current TLS spec is not easy to implement, nor test, nor support. I don't see how a hypothetical simplification with stronger security guarantees would necessarily be worse from this perspective. > > (did you ever have to help app folks troubleshooting app bugs or weird network > data corruptions that make xmldsig signature verifications fail? > You might start to appreciate the properties of RSA PKCS#1 v1.5 signatures > over other signature schemes). How does v1.5 vs PSS affect debugging?. Sincerely, Watson Ladd > > > -Martin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Sat Sep 13 03:37:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87BC1A883F for ; Sat, 13 Sep 2014 03:37:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.35 X-Spam-Level: X-Spam-Status: No, score=-1.35 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FUZZY_AMBIEN=0.552, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WqpXp9zzp6PZ for ; Sat, 13 Sep 2014 03:37:34 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0737.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::737]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC6451A066C for ; Sat, 13 Sep 2014 03:37:33 -0700 (PDT) Received: from BN3PR0301CA0009.namprd03.prod.outlook.com (25.160.180.147) by DM2PR0301MB0845.namprd03.prod.outlook.com (25.160.215.143) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Sat, 13 Sep 2014 10:37:12 +0000 Received: from BN1AFFO11FD022.protection.gbl (2a01:111:f400:7c10::161) by BN3PR0301CA0009.outlook.office365.com (2a01:111:e400:4000::19) with Microsoft SMTP Server (TLS) id 15.0.1024.12 via Frontend Transport; Sat, 13 Sep 2014 10:37:10 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1AFFO11FD022.mail.protection.outlook.com (10.58.52.82) with Microsoft SMTP Server (TLS) id 15.0.1019.14 via Frontend Transport; Sat, 13 Sep 2014 10:37:10 +0000 Received: from 064-smtp-out.microsoft.com (141.251.33.15) by TK5EX14HUBC101.redmond.corp.microsoft.com (157.54.7.153) with Microsoft SMTP Server (TLS) id 14.3.195.2; Sat, 13 Sep 2014 10:36:57 +0000 Received: from AMSPRD3001MB017.064d.mgd.msft.net ([169.254.8.57]) by AMSPRD3001HT002.064d.mgd.msft.net ([141.251.33.15]) with mapi id 14.16.0466.000; Sat, 13 Sep 2014 10:36:55 +0000 From: Markulf Kohlweiss To: Nico Williams , Hugo Krawczyk Thread-Topic: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] Thread-Index: AQHPzf/IWdAFGyx4AUS/92hB+VEU+5v8ZEEAgABuTwCAAQ8uAIAA8X0w Date: Sat, 13 Sep 2014 10:36:55 +0000 Message-ID: References: <5409E00D.1070703@fifthhorseman.net> <20140912192219.GA16660@localhost> In-Reply-To: <20140912192219.GA16660@localhost> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.29.122.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(199003)(13464003)(24454002)(189002)(46102001)(21056001)(81156004)(106116001)(106466001)(64706001)(33656002)(92566001)(92726001)(55846006)(86362001)(76482001)(23726002)(95666004)(77096002)(107046002)(83322001)(85852003)(99396002)(31966008)(69596002)(44976005)(90102001)(19580405001)(83072002)(19580395003)(68736004)(6806004)(4396001)(79102001)(77982001)(2656002)(50986999)(74662001)(97756001)(54356999)(76176999)(16796002)(85306004)(93886004)(87936001)(74502001)(81542001)(66066001)(86612001)(80022001)(97736003)(81342001)(46406003)(84676001)(86146001)(50466002)(20776003)(47776003)(26826002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0301MB0845; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 03333C607F Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=markulf@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Yun6nCxei2by1mVyZBEai18a3V0 Cc: "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 13 Sep 2014 10:37:36 -0000 This is in reply to the whole encrypted finished message & modularity discu= ssion. As I said before, I am all for removing distraction and focusing on the cle= ar analysis of an as simple as possible (but not simpler) design. Right now I fear that we are getting distracted again. Let me nevertheless = try to advertise (once more, see footnote) a nice feature of our modular an= alysis of TLS in miTLS: We do not have to model Record "replay" detection a= s part of our Handshake analysis. In our Handshake model Finished messages = are not encrypted. Thus they cannot be "replayed" as application data. We have unencrypted finished messages, that get encrypted only by the Recor= d protocol which anyway multiplexes several streams (Handshake, Alerts, App= Data...) as already pointed out by Alfredo Pironti. So in a sense we have "generic" composition between the Handshake and the R= ecord. But its "generic" composition for a key exchange model that releases= keys before they are confirmed good with a symmetric key model that can re= quest and deliver Finished messages. The latter can use keys, e.g., to encr= ypt the finished message, but at its own danger (i.e., it has to implement = its own replay detection), and most Handshake security guarantees hold only= after successful Finished message verification. In my opinion the issue is=20 - *not* one of "replay" and keys becoming distinguishable from random by en= crypting a Handshake message, as it is often construed, and the current dis= cussion is a good example,=20 - *but* one of using keys before they are confirmed as good by verifying th= e Finished. The latter is not the greatest idea for application data (pace = FalseStart), it's also not great for Handshake and Alert messages. Conseque= ntly restricted key exchange models like Bellare & Rogaway that do not allo= w for such an early key release may be preferable. I would prefer to shift the discussion towards ensuring that keys are good = as early as possible. The extended master secret is a step in the right dir= ection. Is there a plan for extended record keys? >> Design from scratch, not by patch. Ouch. > I agree with this sentiment. It's not always practical though. If we are modular, or if (de-)construct a legacy protocol into plausible mo= dules, we can at least redesign each module at a time from scratch, even if= we can never pull the whole ship into the dry dock to rebuild it completel= y from scratch.=20 Markulf=20 PS Footnote: Maybe it's enlightening, though many found it confusing in the= past. -----Original Message----- From: Nico Williams [mailto:nico@cryptonector.com]=20 Sent: 12 September 2014 20:22 To: Hugo Krawczyk Cc: Eric Rescorla; Markulf Kohlweiss; tls@ietf.org Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [= was: Re: Simplifying the proof] On Thu, Sep 11, 2014 at 11:11:44PM -0400, Hugo Krawczyk wrote: > [...]. Indeed, the attacker can replay the encrypted=20 > Finish (which is also authenticated) and trigger Bob's action even if=20 > Alice did not intend to do so. The key word here is "replay". Both TLS and DTLS are intended to detect re= plays and must continue to for other reasons anyways. Don't misunderstand = me though: I'm all for key hygiene and modularity. I agree with you; I'm o= nly picking... the nit you predicted we'd pick :) More seriously, I have a concrete example of how encrypting the Finished me= ssages has complicated security analysis in the past. Back when we put together RFC5929 (channel binding to TLS) some reviewers a= rgued that using unencrypted Finished messages was a bad idea because doing= so might leak important information. It didn't take too much effort to pu= t that concern to rest, but it was surprising that there was no need to enc= rypt them Finished messages and yet, they were. Encrypting the Finished messages may well have been a psychological crutch: a device to avoid having to prove that the Finished messages as-is = were good enough. We should not have such crutches. > Design from scratch, not by patch. Ouch. I agree with this sentiment. It's not always practical though. Nico --=20 From nobody Sat Sep 13 05:30:12 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CB8F1A0552 for ; Sat, 13 Sep 2014 05:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vjGTmhEJvkA8 for ; Sat, 13 Sep 2014 05:30:09 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0109.outbound.protection.outlook.com [65.55.169.109]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 515091A8862 for ; Sat, 13 Sep 2014 05:30:09 -0700 (PDT) Received: from BN3PR0301MB0835.namprd03.prod.outlook.com (25.160.154.145) by BN3PR0301MB0852.namprd03.prod.outlook.com (25.160.154.15) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Sat, 13 Sep 2014 12:30:07 +0000 Received: from BN3PR0301CA0051.namprd03.prod.outlook.com (25.160.152.147) by BN3PR0301MB0835.namprd03.prod.outlook.com (25.160.154.145) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Sat, 13 Sep 2014 12:30:06 +0000 Received: from BN1BFFO11FD037.protection.gbl (2a01:111:f400:7c10::1:102) by BN3PR0301CA0051.outlook.office365.com (2a01:111:e400:401e::19) with Microsoft SMTP Server (TLS) id 15.0.1029.13 via Frontend Transport; Sat, 13 Sep 2014 12:30:06 +0000 Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD037.mail.protection.outlook.com (10.58.144.100) with Microsoft SMTP Server (TLS) id 15.0.1019.14 via Frontend Transport; Sat, 13 Sep 2014 12:30:05 +0000 Received: from 064-smtp-out.microsoft.com (141.251.33.16) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.3.195.2; Sat, 13 Sep 2014 12:29:42 +0000 Received: from AMSPRD3001MB017.064d.mgd.msft.net ([169.254.8.57]) by AMSPRD3001HT003.064d.mgd.msft.net ([141.251.33.16]) with mapi id 14.16.0466.000; Sat, 13 Sep 2014 12:29:39 +0000 From: Markulf Kohlweiss To: Nico Williams , Alfredo Pironti Thread-Topic: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] Thread-Index: AQHPzf/IWdAFGyx4AUS/92hB+VEU+5v8ZEEAgABuTwCAAA25gIAAJgwAgADlnACAAQz3oA== Date: Sat, 13 Sep 2014 12:29:38 +0000 Message-ID: References: <5409E00D.1070703@fifthhorseman.net> <20140912195849.GC16660@localhost> In-Reply-To: <20140912195849.GC16660@localhost> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.29.122.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(189002)(13464003)(24454002)(199003)(44976005)(33656002)(6806004)(26826002)(86612001)(85852003)(83072002)(106116001)(19580405001)(83322001)(19580395003)(106466001)(97756001)(81156004)(87936001)(90102001)(68736004)(85306004)(69596002)(107046002)(4396001)(55846006)(46406003)(84676001)(77982001)(93886004)(97736003)(79102001)(86146001)(31966008)(2656002)(86362001)(50986999)(54356999)(77096002)(46102001)(76176999)(95666004)(99396002)(16796002)(92566001)(76482001)(92726001)(21056001)(50466002)(81342001)(20776003)(80022001)(47776003)(66066001)(74662001)(74502001)(23726002)(81542001)(64706001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB0835; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:;UriScan:; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 03333C607F Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=markulf@microsoft.com; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AUfcA46nqp-ebh_xZGXiSECj2XU Cc: "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 13 Sep 2014 12:30:11 -0000 Just using different keys for the Handshake and the Record, isn't quite tha= t simple, especially if one wants to interleave Handshake and Record messag= es. In current TLS terminology one should probably say for Handshake and Ap= pData (what about Alert?). Record messages wrap the messages for all three = of these protocols. The property that a ciphertext does not reveal which key it was generated w= ith, or that two ciphertexts of the same key cannot be linked is formalized= as key privacy. It holds if ciphertexts are indistinguishable from random = bytes, but is not implied by plaintext indistinguishability. In general this has a performance impact as in order to determine the key w= ith which to decrypt one has to try all possible keys. Specialized schemes = can make this more efficient, or one could use a fragment header that is al= ways encrypted with yet another key. I haven't thought about the details, a= nd maybe there are already good proposals for this, but yes, there is some = complexity.=20 A different question is the extent to which interleaving Handshake and Reco= rd messages is necessary in TLS 1.3? I expect that there are good use cases= for this. One question is whether these use cases can be separated in a mo= dular way from the core key exchange functionality, e.g. Token Binding, but= this may be hard for certain purposes, like protecting the confidentiality= of certificates. Markulf=20 -----Original Message----- From: Nico Williams [mailto:nico@cryptonector.com]=20 Sent: 12 September 2014 20:59 To: Alfredo Pironti Cc: Eric Rescorla; Markulf Kohlweiss; tls@ietf.org Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [= was: Re: Simplifying the proof] On Fri, Sep 12, 2014 at 08:17:02AM +0200, Alfredo Pironti wrote: > Using different encryption keys for application data and handshake=20 > messages gives the attacker a distinguishability argument, especially=20 > if we go for the content type encryption. The record type goes in the clear in TLS 1.2 and less anyways. Encrypted handshake messages are *already* distinguishable from application= data. That is something we absolutely should change in 1.3. In any case, encrypted messages have to be of a form like: or . The cipher and authentication had better be indistinguishable when using th= e same key but different plaintext, or just plain different keys. If it is= then we have a problem. There have been proposals for encrypting parts of the handshake. For such = proposals we'll need to derive a different key for those encrypted handshak= e records. Nico --=20 From nobody Sat Sep 13 07:46:47 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D761A06F7 for ; Sat, 13 Sep 2014 07:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.397 X-Spam-Level: X-Spam-Status: No, score=0.397 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4BbmMw4MnvEM for ; Sat, 13 Sep 2014 07:46:44 -0700 (PDT) Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 816DC1A06D9 for ; Sat, 13 Sep 2014 07:46:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To:References:CC:To:MIME-Version:From:Date:Message-ID; bh=b81p59TCOMd3aKbJmhOG+hSDA/YMwcYNEa0WWr0teA8=; b=T0fhBIuFDUk6bBt6hjCc6EaVRChX4M0a09BsSCe1OaJDVviglUf+AFIUH/9jOt02S9qciCDiWrkUpA+qPJWeKsOmdzKJQAuWCzKvT/0aX6wEOCIepgWk/ZuwcPPGy7RcBXKDZbV+qoFchrd6Vae0R7vZJvTFjj2xVxOTM4amDaU=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XSob2-0005es-BY; Sat, 13 Sep 2014 16:46:40 +0200 Message-ID: <541458C9.7090106@polarssl.org> Date: Sat, 13 Sep 2014 16:46:33 +0200 From: =?windows-1252?Q?Manuel_P=E9gouri=E9-Gonnard?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: Nico Williams , Hugo Krawczyk References: <5409E00D.1070703@fifthhorseman.net> <20140912192219.GA16660@localhost> In-Reply-To: <20140912192219.GA16660@localhost> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.offspark.com) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/BXeBpGpoJeEFQMZKWfOO-mZOVUo Cc: Markulf Kohlweiss , "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 13 Sep 2014 14:46:45 -0000 On 12/09/2014 21:22, Nico Williams wrote: > On Thu, Sep 11, 2014 at 11:11:44PM -0400, Hugo Krawczyk wrote: >> [...]. Indeed, the attacker can replay the encrypted >> Finish (which is also authenticated) and trigger Bob's action even if >> Alice did not intend to do so. > > The key word here is "replay". Both TLS and DTLS are intended to detect > replays and must continue to for other reasons anyways. As a matter of fact, replay detection is optional in DTLS, quoting RFC 6347 section 3.3: "DTLS optionally supports record replay detection". Manuel. From nobody Sat Sep 13 15:10:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2232B1A00AA for ; Sat, 13 Sep 2014 15:10:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FfbLrvbmF8en for ; Sat, 13 Sep 2014 15:10:21 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8111A00DC for ; Sat, 13 Sep 2014 15:10:21 -0700 (PDT) Received: from homiemail-a29.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTP id D11D8674058; Sat, 13 Sep 2014 15:10:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=K7XycDRx1KeylE dGKCLoINvzREk=; b=qF9BvuK/bV1pTuRqqO1HyR9DZku/dXIwClAvVg+65xx3IN LlybL0RyAiQ3nOL404zw6S7EKy5obOekvE0V/5TzbpweMRsGikfxd+hRb7zsfPUb E2JexcHSXhwGpPaPJ4mLhBzsV1LL+9z1FBsmoy+WvkUMhv/hq+VEXoDLBJdWQ= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a29.g.dreamhost.com (Postfix) with ESMTPA id 6114F674057; Sat, 13 Sep 2014 15:10:20 -0700 (PDT) Date: Sat, 13 Sep 2014 17:10:19 -0500 From: Nico Williams To: Watson Ladd Message-ID: <20140913221017.GI16660@localhost> References: <20140913001943.6EE211AE43@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ObbtLQ7JstXaf2PsddcZUVbcMsk Cc: Markulf Kohlweiss , "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 13 Sep 2014 22:10:22 -0000 On Fri, Sep 12, 2014 at 06:35:25PM -0700, Watson Ladd wrote: > TLS and SSH are the only IETF standards that provide anything close to > a secure channel for applications to use. There's also IPsec w/ connection latching (RFC5660, though sadly unimplemented). Without that IPsec doesn't provide anything like a secure channel, not without having to manually inspect and manage the configuration of IPsec befure establishing the channel and throughout the channel's lifetime (indeed, this is what connection latching does, in an automated way). Nico -- From nobody Sat Sep 13 15:14:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 504D01A00F1 for ; Sat, 13 Sep 2014 15:14:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ROkZdPtxdIU for ; Sat, 13 Sep 2014 15:14:30 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id A92971A00E6 for ; Sat, 13 Sep 2014 15:14:30 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id 884F82007F005; Sat, 13 Sep 2014 15:14:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=y25ijQMqbTJha7 4QEkd04yH05CE=; b=xIEPOud85HjYbgpjsDxOHIU7EV4kLoRBSIq6dkAStCfyuo fZS61nnT/8cDCZqdC2GZ6RT5h88kCugRjvr6ShbvwZqrvaHie+cFR7SbImbhRpOq PRSrNbu1CVB7wVy7mPnFNmV1H37fcSTCkz44HjwtO/7e4C1cfsv1GWu+9PkXA= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPA id 24E9C2007F003; Sat, 13 Sep 2014 15:14:30 -0700 (PDT) Date: Sat, 13 Sep 2014 17:14:29 -0500 From: Nico Williams To: Markulf Kohlweiss Message-ID: <20140913221428.GJ16660@localhost> References: <5409E00D.1070703@fifthhorseman.net> <20140912195849.GC16660@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/liKW9wVnfbAqYOieumBGWJCnrGM Cc: "tls@ietf.org" , Alfredo Pironti Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 13 Sep 2014 22:14:31 -0000 On Sat, Sep 13, 2014 at 12:29:38PM +0000, Markulf Kohlweiss wrote: > Just using different keys for the Handshake and the Record, isn't > quite that simple, especially if one wants to interleave Handshake and > Record messages. In current TLS terminology one should probably say > for Handshake and AppData (what about Alert?). Record messages wrap > the messages for all three of these protocols. For synchronoush handshake messages it's not problem at all. For async handshake messages we must rely on replay protection (which we needed anyways) and we can't use different keys, indeed. > A different question is the extent to which interleaving Handshake and > Record messages is necessary in TLS 1.3? I expect that there are good > use cases for this. One question is whether these use cases can be > separated in a modular way from the core key exchange functionality, > e.g. Token Binding, but this may be hard for certain purposes, like > protecting the confidentiality of certificates. If you want any kind of re-keying at anything other than deterministically pre-selected points in a connection's lifetime, or if you want to have any kind of alerts (e.g., disconnect), then we need to be able to interleave control and data. That means either that the record type must go in the clear, that we use the same keys for all records, or that receivers must try all possible sub-keys. Nico -- From nobody Sat Sep 13 15:28:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E2911A00F5 for ; Sat, 13 Sep 2014 15:28:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lppydsbWUFbV for ; Sat, 13 Sep 2014 15:28:29 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0105.outbound.protection.outlook.com [207.46.100.105]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C28561A00F2 for ; Sat, 13 Sep 2014 15:28:29 -0700 (PDT) Received: from BN3PR0301CA0044.namprd03.prod.outlook.com (25.160.152.140) by BN3PR0301MB0834.namprd03.prod.outlook.com (25.160.154.144) with Microsoft SMTP Server (TLS) id 15.0.1029.13; Sat, 13 Sep 2014 22:28:27 +0000 Received: from BL2FFO11FD047.protection.gbl (2a01:111:f400:7c09::184) by BN3PR0301CA0044.outlook.office365.com (2a01:111:e400:401e::12) with Microsoft SMTP Server (TLS) id 15.0.1029.13 via Frontend Transport; Sat, 13 Sep 2014 22:28:27 +0000 Received: from mail.microsoft.com (131.107.125.37) by BL2FFO11FD047.mail.protection.outlook.com (10.173.161.209) with Microsoft SMTP Server (TLS) id 15.0.1019.14 via Frontend Transport; Sat, 13 Sep 2014 22:28:26 +0000 Received: from 064-smtp-out.microsoft.com (141.251.33.16) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.3.195.2; Sat, 13 Sep 2014 22:27:50 +0000 Received: from AMSPRD3001MB017.064d.mgd.msft.net ([169.254.8.57]) by AMSPRD3001HT003.064d.mgd.msft.net ([141.251.33.16]) with mapi id 14.16.0466.000; Sat, 13 Sep 2014 22:27:47 +0000 From: Markulf Kohlweiss To: Nico Williams Thread-Topic: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] Thread-Index: AQHPzf/IWdAFGyx4AUS/92hB+VEU+5v8ZEEAgABuTwCAAA25gIAAJgwAgADlnACAAQz3oIAAq0SAgAACLeA= Date: Sat, 13 Sep 2014 22:27:46 +0000 Message-ID: References: <5409E00D.1070703@fifthhorseman.net> <20140912195849.GC16660@localhost> <20140913221428.GJ16660@localhost> In-Reply-To: <20140913221428.GJ16660@localhost> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [86.29.122.57] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(438002)(13464003)(189002)(24454002)(199003)(90102001)(81156004)(81342001)(66066001)(20776003)(80022001)(87936001)(31966008)(64706001)(106466001)(92566001)(107046002)(50466002)(69596002)(81542001)(110136001)(4396001)(95666004)(46102001)(84676001)(19580405001)(99396002)(85306004)(83322001)(6806004)(86612001)(76482001)(46406003)(97756001)(50986999)(26826002)(47776003)(54356999)(77096002)(44976005)(2656002)(86146001)(93886004)(92726001)(16796002)(106116001)(21056001)(55846006)(83072002)(79102001)(74662001)(97736003)(23726002)(76176999)(86362001)(74502001)(19580395003)(85852003)(68736004)(33656002)(77982001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0301MB0834; H:mail.microsoft.com; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;UriScan:; X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY) X-Forefront-PRVS: 03333C607F Received-SPF: Pass (protection.outlook.com: domain of microsoft.com designates 131.107.125.37 as permitted sender) receiver=protection.outlook.com; client-ip=131.107.125.37; helo=mail.microsoft.com; Authentication-Results: spf=pass (sender IP is 131.107.125.37) smtp.mailfrom=markulf@microsoft.com; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/iJyTQkAS9BiaariAVPU3ePMBvtY Cc: "tls@ietf.org" , Alfredo Pironti Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 13 Sep 2014 22:28:32 -0000 To be more efficient than full trial decryption, one can use pseudo-random = values (pre-)computed for all possible keys to detect the key of a cipherte= xt. =20 Do we know of other systems that designed, implemented, and tested such a m= echanism? -----Original Message----- From: Nico Williams [mailto:nico@cryptonector.com]=20 Sent: 13 September 2014 23:14 To: Markulf Kohlweiss Cc: Alfredo Pironti; Eric Rescorla; tls@ietf.org Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [= was: Re: Simplifying the proof] On Sat, Sep 13, 2014 at 12:29:38PM +0000, Markulf Kohlweiss wrote: > Just using different keys for the Handshake and the Record, isn't=20 > quite that simple, especially if one wants to interleave Handshake and=20 > Record messages. In current TLS terminology one should probably say=20 > for Handshake and AppData (what about Alert?). Record messages wrap=20 > the messages for all three of these protocols. For synchronoush handshake messages it's not problem at all. For async handshake messages we must rely on replay protection (which we ne= eded anyways) and we can't use different keys, indeed. > A different question is the extent to which interleaving Handshake and=20 > Record messages is necessary in TLS 1.3? I expect that there are good=20 > use cases for this. One question is whether these use cases can be=20 > separated in a modular way from the core key exchange functionality,=20 > e.g. Token Binding, but this may be hard for certain purposes, like=20 > protecting the confidentiality of certificates. If you want any kind of re-keying at anything other than deterministically = pre-selected points in a connection's lifetime, or if you want to have any = kind of alerts (e.g., disconnect), then we need to be able to interleave co= ntrol and data. That means either that the record type must go in the clea= r, that we use the same keys for all records, or that receivers must try al= l possible sub-keys. Nico --=20 From nobody Sat Sep 13 18:20:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A99BA1A0162 for ; Sat, 13 Sep 2014 18:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.779 X-Spam-Level: X-Spam-Status: No, score=-0.779 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_24=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MIQIYa-A5bPh for ; Sat, 13 Sep 2014 18:20:51 -0700 (PDT) Received: from mail-ig0-x22f.google.com (mail-ig0-x22f.google.com [IPv6:2607:f8b0:4001:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49CE21A015F for ; Sat, 13 Sep 2014 18:20:51 -0700 (PDT) Received: by mail-ig0-f175.google.com with SMTP id h15so2357075igd.8 for ; Sat, 13 Sep 2014 18:20:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=cjzPbKZjHuvM64entMTbNJEHJ262/6ROvu6HWFX0Vh4=; b=vU4UX/XabsT5BGKyrcC92uZsUDj8rZIJ1oy5lkATUsM09ehUPD9yehfkhaqiaz+SN/ pK3mRRSFuN1s0k7QVEfoj31TBl8WG/cgjp0s9x3zby4iqFma55zz0HzrgS+QHnllSVqA fgTAkArCUXLrKb+vWI/kknADly7+ZqLMYdshk= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=cjzPbKZjHuvM64entMTbNJEHJ262/6ROvu6HWFX0Vh4=; b=bsA6L/K+G+vEKNJJ9Vi4/rK367zstpJvxb9Xv09y/OUE7uKoPO+IksWVuZY/WYZNGa hRWU/E/KW5sKNo/27kXdHulNr/bJqNGJ02op1khrcfJhUQ8jOyWwAOdnFuq1P/JzGfzg 1JIG7y31T4RKamwGz7+14+Ra419IurBWN1HfIYwAw9seROkWUZd5YfSbRmuMqttDMO+8 T1zrqyvfNAAdeQ9GE0ZkbLy0KcUeqBsoSDHmKf3TMb6reZeDHkNisSkU64jK8LViwmhP O964oQZDzChTtz/ucVG6MSmBZRS353O4jElAykYqX0weyZp0XymdGJhxHJH4m8fX/78L WzFA== X-Gm-Message-State: ALoCoQlUgGfVJSFreE74xjZD4lYEhg8qPEqKLszkba/fQF+OYbAjMtLV9lVfEUBnue5g8q/ZYH6G X-Received: by 10.42.4.136 with SMTP id 8mr47691ics.57.1410657650444; Sat, 13 Sep 2014 18:20:50 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.7.131 with HTTP; Sat, 13 Sep 2014 18:20:30 -0700 (PDT) In-Reply-To: <1409931283.1731.16.camel@dhcp-2-127.brq.redhat.com> References: <1409931283.1731.16.camel@dhcp-2-127.brq.redhat.com> From: Tom Ritter Date: Sat, 13 Sep 2014 20:20:30 -0500 Message-ID: To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/SWWlAmUE6Q602QPu5sMVyKLxr_g Cc: "pkix@ietf.org" , Phillip Hallam-Baker , "tls@ietf.org" Subject: Re: [TLS] New version of the TLS feature draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 14 Sep 2014 01:20:52 -0000 On 5 September 2014 10:34, Nikos Mavrogiannopoulos wrote: > I don't see how it does close the door. What should the client do if the > server administrator sets up an old version of a valid ocsp staple? Section 3.1.1 specifies "a server MUST return a valid OCSP token". I would consider an expired ocsp staple to not actually be valid. I would refer to it as expired, with the implication that the signature is correct, because if it wasn't a person probably would have said that in addition to describing it as expired. > This > case is not discussed in the security considerations at all. Because I don't consider an expired staple to be valid, I don't feel this case is appropriate for Security Considerations. If for some reason expired OCSP staples are actually accepted by end entities, then yea, Security Considerations fits. Other Comments: Section 3.2.3, omitting status_request results in a SHOULD reject, and omitting in general results in a MAY reject. I agree with the sentiment: we can't predict if future uses of this would be a MUST or SHOULD or MAY, but to someone reading the document, it seems contradictory at first read. I would suggest that this detail be included to explain the apparent contradiction. Section 3.2.2, regarding an Intermediate Cert with the extension. a) I don't understand "primarily intended for use by parties seeking to evaluate the performance of certificate issuers". b) For the status_request extension, I would actually prefer that a client MUST or SHOULD reject certificates that omit the extension if signed by a cert that has the extension. I say this because I see a use case of a CA standing up such an Intermediate, and end entities purchasing certificates off that Intermediate, and then pinning to that Intermediate. This is effectively one mechanism of ensuring that all certificates for a domain contain the extension. Just like 3.2.3, this is another example of the specific case seemingly-but-not contradicting the general case. Minor Grammar: Section 2, Paragraph 3, First sentence. 'is' should be 'are', there should be an 'and', and a period before "These extensions". Section 2, Paragraph 9: "a client request for the status_request or status_request_v2 features" - features should be singular Overall, and I know you went to pains to reduce this, the terminology is confusing. I think the definition you set out with extension = x509 extension and feature = TLS extension works well. But I think it gets confusing because you also define TLS Feature (capital F) as the name of the thingie you are writing the draft about. I'm not saying it should be called this, but I took the draft and replaced 'TLS Feature' with 'Required Data'. This read must nicer, and also exposed a few places where the terminology/grammar was extra confusing or inconsistent. - Features ::= SEQUENCE OF INTEGER - rather than calling it Features, perhaps some word that is not used in so many contexts? Such as 'Requirements', 'RequiredData', 'RequiredExtensions', 'MandatedExtensions', 'MandatedData'... - Section 2, Paragraph two: "the TLS Feature is only" - this should either be 'the TLS Feature extension is only' or if you want to use it as if it's a proper noun, 'TLS Feature is only'. I don't think it should be used as a proper noun, and should be generally referred to as 'the TLS Feature extension' - Section 2, Paragraph three, first sentence: "the only TLS feature extensions that are relevant" - should be "the only features" or expand the definition this once and say "the only TLS extensions" - Section 2, Paragraph three, second sentence: In this sentence 'extension' refers to the TLS extensions. - Section 2, Paragraph five: "The inclusion of a TLS feature extension" - feature should be capitalised as it refers to the thingie defined in the draft. - Section 2, Paragraph six: "Nevertheless a Certification Authority MAY consider the presence or absence of a required TLS feature as one factor" - a) I think you should remove 'required' as it gets confusing as who is requiring what. Whether the client requires Comodo to include the x509 extension or requests it to be included is not relevant. It's also not necessary accurate. Is the presence of a x509 extension in a CSR a requirement? Nay, as I include BasicConstraints ca:True and don't get what I require ;) b) feature should again by capitalized, as you're referring to the thingie defined in the draft. I would suggest saying "absence of the TLS Feature extension in the certificate signing transaction as one factor". I said 'transaction' vs 'request' to encompass both a CSR and a (e.g.) phone call. - Section 2, Paragraph seven: "A server offering an end entity certificate with a TLS feature extension MUST" - again, feature should be capitalized to refer to the thingie being defined - Section 2, Paragraph seven: "that the server is capable of verifying that its configuration is compatible with the feature declaration of the certificates it offers" - strongly suggest this be re-worded to 'with the TLS Feature declaration it offers'. Technically feature could be correct, if it was interpreted not as a defined term but as the colloquial word - but lets try to avoid that. - Section 2, Paragraph seven: "Ideally, the TLS feature declaration" - again, feature should be capitalised to refer to the thingie being defined - Section 2, Paragraph ten: "This document describes the use of the TLS feature in PKIX end entity" - feature should be capitalised, and I would suggest adding 'extension' after it. - Section 3.1 Paragraph one: "server compliant with the feature declaration" - I think omitting 'feature' is actually more descriptive. Otherwise, perhaps 'the object member declaration'? - Section 3.1 Paragraph three: "offering the certificate MUST support the extension specified" - extension refers to TLS extension, and so should be 'feature' - Section 3.1 Paragraph three: "specified for that feature in this document or in the document that specifies the TLS feature" - suggest maintaining consistency and saying 'that TLS feature' in both of these two instances - Section 3.2.3 "a server MUST meet to be compliant with the feature declaration" (and the other two instances of 'feature declaration' in this section) - perhaps replace feature declaration with 'the TLS Feature extension'? - Section 3.3.1 "For example the use of a Feature extension in the CSR" - should be full name, "TLS Feature" - Section 3.3.2 "A server SHOULD support generation of the Feature extension in CSRs if key generation is supported." - same I realize this is an intense number of minor suggestions with tough-to-follow context. If you send the .xml or post it on Github, I'd be happy to make these suggestions in the form of text changes. (I particularly like drafts on Github, as I can logically separate different changes into different commits and you can review them as such.) -tom From nobody Mon Sep 15 17:24:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 355C51A00B0; Mon, 15 Sep 2014 17:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.554 X-Spam-Level: X-Spam-Status: No, score=-108.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rN6U7KUhHGja; Mon, 15 Sep 2014 17:23:47 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6E11A00AF; Mon, 15 Sep 2014 17:23:47 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 9D98518253E; Mon, 15 Sep 2014 17:23:16 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 6000:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20140916002316.9D98518253E@rfc-editor.org> Date: Mon, 15 Sep 2014 17:23:16 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/6wjzoGenQq4GFk6tin7b9HEu_pc Cc: drafts-update-ref@iana.org, tls@ietf.org, rfc-editor@rfc-editor.org Subject: [TLS] RFC 7366 on Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 16 Sep 2014 00:23:50 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7366 Title: Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Author: P. Gutmann Status: Standards Track Stream: IETF Date: September 2014 Mailbox: pgut001@cs.auckland.ac.nz Pages: 7 Characters: 15775 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-tls-encrypt-then-mac-03.txt URL: https://www.rfc-editor.org/rfc/rfc7366.txt This document describes a means of negotiating the use of the encrypt-then-MAC security mechanism in place of the existing MAC-then- encrypt mechanism in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS). The MAC-then-encrypt mechanism has been the subject of a number of security vulnerabilities over a period of many years. This document is a product of the Transport Layer Security Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue Sep 16 12:09:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 836371A03F3 for ; Tue, 16 Sep 2014 12:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMN6kJrR89Ys for ; Tue, 16 Sep 2014 12:08:56 -0700 (PDT) Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 97BC21A0387 for ; Tue, 16 Sep 2014 12:08:56 -0700 (PDT) Received: by mail-we0-f176.google.com with SMTP id q58so313287wes.21 for ; Tue, 16 Sep 2014 12:08:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=H++m5496lUhPvOouVo9iryV2JTAZila4DlO/b5Ata68=; b=pyQnnzj0RTEuOT3gy2/JoyJm3uD3Pb4xtaIMH6WQKIrJZ5PBMnm04zOaQ0AgCNZ0Gi /D3n24nx6OMosBJJ6ogv3OcUazlUEfskqt7Rmnvgawu+chjvNuyL053jxOO/sVsRooBl wAH3kEE2wi61/REh5k3L7TS5kjGNqaaNbYiopspvZglb8Md54T+4f9SjIEk00OfyoQ2R LtUq8PZ0Mt09sanPCZNbpCxuEr6aoRm3BGN+aUnj/dkULh0q5WLbo7Hz4Hdxrbtoean8 KywApwPJpprLtQDrXqAkYwEockfEsTkBqUGTqvYT5QM1jt9ThSCSoBaDnB/K5n+HbqP9 uiYw== X-Received: by 10.194.78.41 with SMTP id y9mr11611074wjw.24.1410894534717; Tue, 16 Sep 2014 12:08:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.66.225 with HTTP; Tue, 16 Sep 2014 12:08:13 -0700 (PDT) From: Ryan Carboni Date: Tue, 16 Sep 2014 12:08:13 -0700 Message-ID: To: tls@ietf.org Content-Type: multipart/alternative; boundary=047d7bf0d2da8eb8d30503337b18 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AA-ci2oOJtu76Me8eizjgr2pPR4 Subject: [TLS] RFC 7366 on Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 16 Sep 2014 19:08:58 -0000 --047d7bf0d2da8eb8d30503337b18 Content-Type: text/plain; charset=UTF-8 I read the discussion on it. The sorts of attacks on cryptographic block ciphers that are less than brute force don't even apply to the typical short messages typically transferred over the internet. Even then, MAC than encrypt doesn't reduce security substantially since even the MAC is encrypted. Oh, BTW, thanks guys for making the internet work. --047d7bf0d2da8eb8d30503337b18 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I read the discussion on it. The sorts of attacks on = cryptographic block ciphers that are less than brute force don't even a= pply to the typical short messages typically transferred over the internet.= Even then, MAC than encrypt doesn't reduce security substantially sinc= e even the MAC is encrypted.

Oh, BTW, thanks guys for making t= he internet work.
--047d7bf0d2da8eb8d30503337b18-- From nobody Tue Sep 16 14:12:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535FF1A03AF for ; Tue, 16 Sep 2014 14:12:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qc9_kQ7JkHNo for ; Tue, 16 Sep 2014 14:12:18 -0700 (PDT) Received: from emea01-am1-obe.outbound.protection.outlook.com (mail-am1on0670.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe00::670]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 324551A03A3 for ; Tue, 16 Sep 2014 14:12:17 -0700 (PDT) Received: from DBXPR03MB383.eurprd03.prod.outlook.com (10.141.10.15) by DBXPR03MB384.eurprd03.prod.outlook.com (10.141.10.20) with Microsoft SMTP Server (TLS) id 15.0.1019.16; Tue, 16 Sep 2014 21:11:54 +0000 Received: from DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) by DBXPR03MB383.eurprd03.prod.outlook.com ([10.141.10.15]) with mapi id 15.00.1015.018; Tue, 16 Sep 2014 21:11:54 +0000 From: "Paterson, Kenny" To: Ryan Carboni Thread-Topic: [TLS] RFC 7366 on Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) Thread-Index: AQHP0eG1BDy3WiNrlkylYpNqdMDgjZwEQer3 Date: Tue, 16 Sep 2014 21:11:54 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [92.4.67.211] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03361FCC43 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(51704005)(199003)(189002)(24454002)(87936001)(95666004)(33656002)(76482001)(15975445006)(76176999)(105586002)(19580395003)(97736003)(19580405001)(80022003)(36756003)(74482002)(81542003)(81342003)(74502003)(79102003)(74662003)(83072002)(83716003)(1411001)(106116001)(77982003)(46102003)(107046002)(101416001)(2656002)(90102001)(85306004)(86362001)(20776003)(54356999)(106356001)(85852003)(92726001)(31966008)(82746002)(4396001)(230783001)(83322001)(50986999)(92566001)(99396002)(66066001)(21056001)(110136001)(64706001)(104396001); DIR:OUT; SFP:1101; SCL:1; SRVR:DBXPR03MB384; H:DBXPR03MB383.eurprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: rhul.ac.uk Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Rynlj6fNuN7Mh2AI0y9nBG3oqqY Cc: "tls@ietf.org" Subject: Re: [TLS] RFC 7366 on Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 16 Sep 2014 21:12:21 -0000 Ryan, The RFC is less clear than it could be about the specific attacks of concer= n that motivated this document. These are (primarily) Vaudenay's padding or= acle attack from 2002 and its reincarnation in the form of Lucky 13 in 2013= . These attacks both recover plaintext, not keys. And the message length is= irrelevant to their success. =20 I'm actually a bit surprised the relevant research papers are not informati= ve references - they ought to be, precisely to preempt the need for this ki= nd of educative dialogue.=20 Cheers, Kenny > On 16 Sep 2014, at 20:09, "Ryan Carboni" wrote: >=20 > I read the discussion on it. The sorts of attacks on cryptographic block = ciphers that are less than brute force don't even apply to the typical shor= t messages typically transferred over the internet. Even then, MAC than enc= rypt doesn't reduce security substantially since even the MAC is encrypted. >=20 > Oh, BTW, thanks guys for making the internet work. > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Sep 16 14:52:26 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91B1B1A6EEF for ; Tue, 16 Sep 2014 14:52:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0TwX3db0zzr2 for ; Tue, 16 Sep 2014 14:52:22 -0700 (PDT) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33B4D1A009C for ; Tue, 16 Sep 2014 14:52:22 -0700 (PDT) Received: by mail-we0-f170.google.com with SMTP id u57so510559wes.1 for ; Tue, 16 Sep 2014 14:52:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Gt2l1E6OxH6+yrs5evUUL+yty1XoxUifcI81iQR3e70=; b=dpVUOasYrw5mD7HUmptObDQHavvU8eS1fKbILxdrRmWTx0XetzsXM3KqF3EPb5DrIk CnNsTofkh2/8qmkdjDXfnlsIn4WmCYewsT3sf+M+kxixSWUXZQCKQD3P4FZ1AQYtmkoT NV1QS3L0U75h3IgiYsSvNXkANSTIlAh+E7dHIBMNgBAEi6M/xaCsrsKXYMkYa0RzPTJK M0Bu+ZbkJ5sMI1k9SFetUeLiCPUIRo0RWRRMfCD3X/RnEaC7vfaXX/hhtz6sWuCtEG7S 1I1AqsRKIxk91lZckzTNpJY79Sg9KzysxignXRMmj7l/wGDsUgqWA8VQAIhycrdZpOfx Gp0w== X-Received: by 10.180.96.161 with SMTP id dt1mr35929359wib.1.1410904340844; Tue, 16 Sep 2014 14:52:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.66.225 with HTTP; Tue, 16 Sep 2014 14:51:40 -0700 (PDT) In-Reply-To: References: From: Ryan Carboni Date: Tue, 16 Sep 2014 14:51:40 -0700 Message-ID: To: "Paterson, Kenny" Content-Type: multipart/alternative; boundary=f46d044306880c5849050335c4b1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Yke4gPfM-Dv3p5r8VXkeMk0tTOI Cc: "tls@ietf.org" Subject: Re: [TLS] RFC 7366 on Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 16 Sep 2014 21:52:24 -0000 --f46d044306880c5849050335c4b1 Content-Type: text/plain; charset=UTF-8 Hmm, the 2013 attack would be later than the discussions I did read. If you're upgrading specifications, why not switch to SHA-3, which is constant time (AFAIK)? That way the number of TLS options in my browser doesn't /double./ On Tue, Sep 16, 2014 at 2:11 PM, Paterson, Kenny wrote: > Ryan, > > The RFC is less clear than it could be about the specific attacks of > concern that motivated this document. These are (primarily) Vaudenay's > padding oracle attack from 2002 and its reincarnation in the form of Lucky > 13 in 2013. These attacks both recover plaintext, not keys. And the message > length is irrelevant to their success. > > I'm actually a bit surprised the relevant research papers are not > informative references - they ought to be, precisely to preempt the need > for this kind of educative dialogue. > > Cheers, > > Kenny > > > On 16 Sep 2014, at 20:09, "Ryan Carboni" wrote: > > > > I read the discussion on it. The sorts of attacks on cryptographic block > ciphers that are less than brute force don't even apply to the typical > short messages typically transferred over the internet. Even then, MAC than > encrypt doesn't reduce security substantially since even the MAC is > encrypted. > > > > Oh, BTW, thanks guys for making the internet work. > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > --f46d044306880c5849050335c4b1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hmm, the 2013 attack would be later than the discussions I= did read.

If you're upgrading specifications, why not swit= ch to SHA-3, which is constant time (AFAIK)?

That way the= number of TLS options in my browser doesn't /double./
<= div class=3D"gmail_extra">
On Tue, Sep 16, 20= 14 at 2:11 PM, Paterson, Kenny <Kenny.Paterson@rhul.ac.uk><= /span> wrote:
Ryan,

The RFC is less clear than it could be about the specific attacks of concer= n that motivated this document. These are (primarily) Vaudenay's paddin= g oracle attack from 2002 and its reincarnation in the form of Lucky 13 in = 2013. These attacks both recover plaintext, not keys. And the message lengt= h is irrelevant to their success.

I'm actually a bit surprised the relevant research papers are not infor= mative references - they ought to be, precisely to preempt the need for thi= s kind of educative dialogue.

Cheers,

Kenny

> On 16 Sep 2014, at 20:09, "Ryan Carboni" <ryacko@gmail.com> wrote:
>
> I read the discussion on it. The sorts of attacks on cryptographic blo= ck ciphers that are less than brute force don't even apply to the typic= al short messages typically transferred over the internet. Even then, MAC t= han encrypt doesn't reduce security substantially since even the MAC is= encrypted.
>
> Oh, BTW, thanks guys for making the internet work.
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls

--f46d044306880c5849050335c4b1-- From nobody Tue Sep 16 14:57:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23BA11A6F30 for ; Tue, 16 Sep 2014 14:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0bNhhLEGKPFx for ; Tue, 16 Sep 2014 14:57:39 -0700 (PDT) Received: from mail-la0-x22b.google.com (mail-la0-x22b.google.com [IPv6:2a00:1450:4010:c03::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FE9B1A6F22 for ; Tue, 16 Sep 2014 14:57:38 -0700 (PDT) Received: by mail-la0-f43.google.com with SMTP id gi9so695024lab.16 for ; Tue, 16 Sep 2014 14:57:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=/gUvohVjj+v5TaH9zP1dlvqTF3Wzjw6aExViKOmOvPk=; b=iP7zPI+hZtmv2X9m/tvVEg1d7/tdad0OHEF7D8tB1yXSUMNwxns1d7lEgHJnEmme7C pokL1awBBeWUBeSGM/7Yyx6Z26iWuM1a1k435fbi6jh6xMnKE+HrAWx2E4oKu8B5/19n 89bWh4A2/6a2F40HbvyuKEsYdAeDBO74Fq8uVaN8omhjLO1CrwNmYEJfQ9lsYml0BZlm eTfbUSi8bEtcLmP+nrszm+5VN0lmwMp9fgfJT+K4uJwy/CGh/yW7X4Erw0HKyS7hcfl1 4o7ONi9EYC0Bn/LxleyPJPHLDOQ9aaPBo7ZszpS2K/xBpCoppsa8H+/tL8klis8StbJh lK+g== MIME-Version: 1.0 X-Received: by 10.112.166.101 with SMTP id zf5mr22386428lbb.36.1410904656726; Tue, 16 Sep 2014 14:57:36 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.241.103 with HTTP; Tue, 16 Sep 2014 14:57:36 -0700 (PDT) In-Reply-To: References: Date: Tue, 16 Sep 2014 14:57:36 -0700 X-Google-Sender-Auth: EYPuYrPBbjWcRc0zn8-CqFay54M Message-ID: From: Adam Langley To: Ryan Carboni Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/MjIBatrUp9g-JVJCHT1nBudEy54 Cc: "tls@ietf.org" Subject: Re: [TLS] RFC 7366 on Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 16 Sep 2014 21:57:40 -0000 On Tue, Sep 16, 2014 at 2:51 PM, Ryan Carboni wrote: > If you're upgrading specifications, why not switch to SHA-3, which is > constant time (AFAIK)? All hash functions used in TLS are constant-time (unless you try very hard to implement them badly). Cheers AGL From nobody Tue Sep 16 15:00:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D110E1A6F20 for ; Tue, 16 Sep 2014 15:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NkoqZNOn4eOz for ; Tue, 16 Sep 2014 15:00:56 -0700 (PDT) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 466D61A6F1E for ; Tue, 16 Sep 2014 15:00:56 -0700 (PDT) Received: by mail-wg0-f50.google.com with SMTP id x13so491995wgg.21 for ; Tue, 16 Sep 2014 15:00:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=3d+BGchYz/hWNyz3keY8ZHVM+4Ii8LV8VSBTcORDzyI=; b=IOa5W1yTZPXslG7yANoByz03mmnEqzsQ8b1LTTt8jA3azpgDvcalyIF9L4d2FwLzYq EvnaSY5dTicBFk35CCtvAN9iYSgxsMMjZ/D5BzMsA+kefBDEECWo1zVJfbtamoCndImW doQLk3FmlELHkG7amR5VhU469+ZFn4zLOzvPDmL8GMD2cpsq3DTJFHK1zppFYAGii2zP YPRUGdbzVuFRm/+NxOVOt6FIJiYPeoWsI3zuLCDh/RGXfdGuimautbNw/Zy5NwGeEiSI 5uEwJjUOKxjiG+VUl+FoO/kq6z6BQaZD2zTKvoO7KpLwypWnrN9y2dhiQXmgxxNgJRWu zOUQ== X-Received: by 10.194.84.175 with SMTP id a15mr2051820wjz.12.1410904854986; Tue, 16 Sep 2014 15:00:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.66.225 with HTTP; Tue, 16 Sep 2014 15:00:14 -0700 (PDT) In-Reply-To: References: From: Ryan Carboni Date: Tue, 16 Sep 2014 15:00:14 -0700 Message-ID: To: Adam Langley Content-Type: multipart/alternative; boundary=047d7bf0c4beb189cb050335e268 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Fkmv9u6WLjqrZPQvv8s69OrY2R4 Cc: "tls@ietf.org" Subject: Re: [TLS] RFC 7366 on Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 16 Sep 2014 22:00:58 -0000 --047d7bf0c4beb189cb050335e268 Content-Type: text/plain; charset=UTF-8 Modulo isn't constant time, but XOR, ROT, NOT, AND are. --047d7bf0c4beb189cb050335e268 Content-Type: text/html; charset=UTF-8
Modulo isn't constant time, but XOR, ROT, NOT, AND are.
--047d7bf0c4beb189cb050335e268-- From nobody Tue Sep 16 15:09:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556261A6F29 for ; Tue, 16 Sep 2014 15:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fP3HbbGorFpX for ; Tue, 16 Sep 2014 15:09:30 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 726DF1A6F30 for ; Tue, 16 Sep 2014 15:09:25 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id u10so713212lbd.13 for ; Tue, 16 Sep 2014 15:09:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=TasI2bnolDubmcIzkM9tUSqJNFTki0cGLFaA79pt+5Q=; b=qWyBhL1pr7pPPERTQdnY35fgMZpDcxsrB41YwzlSui4bkVftR46iAH2C7WVxb0APlg V6XI780tEy6yaZAB2oiggKlLXWxhkqoIHsVi3GYPL465lgeDhxjpbinVDnPGhKlHv5Bp YWRR1XQxlfvcB54dDR+wOoF1SkYnDOkcPoFohLRREfD3FRQgP6QyJCaS/D+s4dL3OCl2 z3fhTfIxGM17kGUnwi+gFH8p/k7SgpDceWIXWcUoLCCEQMYYW2btk4Lhts56EvJ9iD1/ cFGy20hSYOc3ohlrQ8ZfGEHUBH8YtoclYWUmu5HMK1AwQm26EiP6bhloaMdTCyAL1bmx AiqQ== MIME-Version: 1.0 X-Received: by 10.112.14.33 with SMTP id m1mr37863337lbc.16.1410905363797; Tue, 16 Sep 2014 15:09:23 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.241.103 with HTTP; Tue, 16 Sep 2014 15:09:23 -0700 (PDT) In-Reply-To: References: Date: Tue, 16 Sep 2014 15:09:23 -0700 X-Google-Sender-Auth: nTAR_w9QCduY0WDkhrypHSawM-g Message-ID: From: Adam Langley To: Ryan Carboni Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rgwq5t-M1wKZxpfJ4yAABOq0-B8 Cc: "tls@ietf.org" Subject: Re: [TLS] RFC 7366 on Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 16 Sep 2014 22:09:31 -0000 On Tue, Sep 16, 2014 at 3:00 PM, Ryan Carboni wrote: > Modulo isn't constant time, but XOR, ROT, NOT, AND are. That's true in general, but the MD/SHA family of hashes only use mod 2^32 or 2^64 which is just a truncation and thus constant time on any CPU I can think of. Cheers AGL -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Wed Sep 17 09:32:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25DB51A06BC for ; Wed, 17 Sep 2014 09:32:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.133 X-Spam-Level: * X-Spam-Status: No, score=1.133 tagged_above=-999 required=5 tests=[BAYES_50=0.8, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxYx872e-n24 for ; Wed, 17 Sep 2014 09:32:16 -0700 (PDT) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [69.56.148.14]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6D8C1A06AE for ; Wed, 17 Sep 2014 09:32:08 -0700 (PDT) Received: by gateway05.websitewelcome.com (Postfix, from userid 5007) id 6AC91A66D4814; Wed, 17 Sep 2014 11:32:07 -0500 (CDT) Received: from cm2.websitewelcome.com (unknown [192.185.178.13]) by gateway05.websitewelcome.com (Postfix) with ESMTP id 523DEA66D47BD for ; Wed, 17 Sep 2014 11:32:07 -0500 (CDT) Received: from gator3286.hostgator.com ([198.57.247.250]) by cm2.websitewelcome.com with id sGY51o01b5Qt53201GY6Fj; Wed, 17 Sep 2014 11:32:07 -0500 Received: from [198.180.150.142] (port=51060 helo=v142.vpn.iad.rg.net) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XUI9F-0003oQ-43 for tls@ietf.org; Wed, 17 Sep 2014 11:32:05 -0500 From: Sean Turner Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <92626AAF-4530-4E6F-BBC7-6219F316FB08@ieca.com> Date: Wed, 17 Sep 2014 12:32:03 -0400 To: "TLS@ietf.org (tls@ietf.org)" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.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-IP: 198.180.150.142 X-Exim-ID: 1XUI9F-0003oQ-43 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (v142.vpn.iad.rg.net) [198.180.150.142]:51060 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 28 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/iNx-G4_rcSbItc_7HScAxvl-0EI Subject: [TLS] fall interim attendance check X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 17 Sep 2014 16:32:17 -0000 The chairs are concerned that the participation at the interim will be = low and may not be a good use of time. If you are planning to attend = the interim please send a message to the chairs to let them know. J/S= From nobody Wed Sep 17 10:35:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FAC11A069A for ; Wed, 17 Sep 2014 10:35:49 -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=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lesUW3ILPbC9 for ; Wed, 17 Sep 2014 10:35:48 -0700 (PDT) Received: from mail-wi0-f178.google.com (mail-wi0-f178.google.com [209.85.212.178]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D09C41A0535 for ; Wed, 17 Sep 2014 10:35:47 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id ho1so1671496wib.17 for ; Wed, 17 Sep 2014 10:35:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=RT960gr7VKUuOF2XyMYRYdXzafB4B5g4LZhkZV4MRE4=; b=fqjp8Z0vQe06ALGb5p7mWiyah4SYTkPYL64gTd/EiDZYqGgm0AyPZQ/79yCMRe8sn6 jVU6SCN3GGSHQGcP4KO3OiENsDmQa3jhLhwLLGW0g8GIyZQdUxlHkg1BzpmASvdNSdpJ VF/EzyV1dkI5BQ/endru+waFhMX2tJ0Y8U7mBaGzzOrvftO3Yw7FV76BbYAWd7pwDwof lf0D3AT1yiliMJ3bVCb60Nz+PuZNkL8rvQK+4POJhiuKjMygsxksxFDS+poBaxzqwfFJ 8kxwrOB5hUxg8uVIh6DedGGgjHCAR72HbVQGrodLP6udaFZwHlRfHFm1lirPayfsOqlO ClQg== X-Gm-Message-State: ALoCoQnOyc8nNnJV7a8fiwrAqAyjo53AVz/gS17AhjeenxxSY5PgLW/uof9qVJG9AunGYsHcv1sq X-Received: by 10.180.102.233 with SMTP id fr9mr22847192wib.80.1410975345939; Wed, 17 Sep 2014 10:35:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.216.146.194 with HTTP; Wed, 17 Sep 2014 10:35:05 -0700 (PDT) In-Reply-To: <92626AAF-4530-4E6F-BBC7-6219F316FB08@ieca.com> References: <92626AAF-4530-4E6F-BBC7-6219F316FB08@ieca.com> From: Eric Rescorla Date: Wed, 17 Sep 2014 10:35:05 -0700 Message-ID: To: Sean Turner Content-Type: multipart/alternative; boundary=f46d04451a2748310c0503464cbf Archived-At: http://mailarchive.ietf.org/arch/msg/tls/AE1gdItb1Ejjw45q1s2mRKVAagY Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] fall interim attendance check X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 17 Sep 2014 17:35:49 -0000 --f46d04451a2748310c0503464cbf Content-Type: text/plain; charset=UTF-8 I intend to be there. On Wed, Sep 17, 2014 at 9:32 AM, Sean Turner wrote: > The chairs are concerned that the participation at the interim will be low > and may not be a good use of time. If you are planning to attend the > interim please send a message to the chairs to let them know. > > J/S > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > --f46d04451a2748310c0503464cbf Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I intend to be there.


On Wed, Sep 17, 2014 at 9:32 AM, = Sean Turner <TurnerS@ieca.com> wrote:
The chairs are concerned that the participation at the interim w= ill be low and may not be a good use of time.=C2=A0 If you are planning to = attend the interim please send a message to the chairs to let them know.
J/S
_______________________________________________
TLS mailing list
TLS@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/tls

--f46d04451a2748310c0503464cbf-- From nobody Wed Sep 17 12:02:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972D41A0ACE for ; Wed, 17 Sep 2014 12:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.652] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3vA8pprZXnuI for ; Wed, 17 Sep 2014 12:02:24 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 18C141A0894 for ; Wed, 17 Sep 2014 12:02:23 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5ABAC4867D; Wed, 17 Sep 2014 19:02:23 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 4E9C8484EE; Wed, 17 Sep 2014 19:02:23 +0000 (GMT) Received: from ustx2ex-cashub.dfw01.corp.akamai.com (ustx2ex-cashub5.dfw01.corp.akamai.com [172.27.25.71]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 4C04B9803D; Wed, 17 Sep 2014 19:02:23 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.2.28]) by ustx2ex-cashub5.dfw01.corp.akamai.com ([172.27.25.71]) with mapi; Wed, 17 Sep 2014 14:02:23 -0500 From: "Salz, Rich" To: Eric Rescorla , Sean Turner Date: Wed, 17 Sep 2014 14:02:21 -0500 Thread-Topic: [TLS] fall interim attendance check Thread-Index: Ac/SndT0Y7zGJEgQRaq9nbd+ol5FnAAC/slA Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D2E1B13DD@USMBX1.msg.corp.akamai.com> References: <92626AAF-4530-4E6F-BBC7-6219F316FB08@ieca.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/uSogdWgYYPJk9aIP6oY3sRDk34U Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] fall interim attendance check X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 17 Sep 2014 19:02:25 -0000 SeKAmWQgYmUgdGhlcmUNCg== From nobody Wed Sep 17 14:53:19 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1A261A6F56 for ; Wed, 17 Sep 2014 14:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BGvXJc2Q9C6h for ; Wed, 17 Sep 2014 14:53:15 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id D37E71A6F85 for ; Wed, 17 Sep 2014 14:53:14 -0700 (PDT) Received: from [10.70.10.54] (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id 6C8D3F984; Wed, 17 Sep 2014 17:53:12 -0400 (EDT) Message-ID: <541A02C6.3010500@fifthhorseman.net> Date: Wed, 17 Sep 2014 17:53:10 -0400 From: Daniel Kahn Gillmor User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:32.0) Gecko/20100101 Icedove/32.0 MIME-Version: 1.0 To: Sean Turner , "TLS@ietf.org (tls@ietf.org)" References: <92626AAF-4530-4E6F-BBC7-6219F316FB08@ieca.com> In-Reply-To: <92626AAF-4530-4E6F-BBC7-6219F316FB08@ieca.com> Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="7qqI6q2F871QlRX1eTvjRMbt1EctfASxe" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/n79hqFep0cWU6lkihCf-bzKSoyk Subject: Re: [TLS] fall interim attendance check X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 17 Sep 2014 21:53:17 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --7qqI6q2F871QlRX1eTvjRMbt1EctfASxe Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 09/17/2014 12:32 PM, Sean Turner wrote: > The chairs are concerned that the participation at the interim will be = low and may not be a good use of time. If you are planning to attend the= interim please send a message to the chairs to let them know. I plan on attending the October interim. --dkg --7qqI6q2F871QlRX1eTvjRMbt1EctfASxe Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJUGgLGXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcbxMQAMxHh2IRPrmbFKit053t5H1T /MrcyYV6kwKo+n96njqSwQlDFeJhvuxKNN3WUh/hRwnKmzCc8JHnG/57K83fPE7b 5OQ2f3HNhFhNrtKuyR83sxEPF9dH4Xn4XM1n5W8kEXOGcI2l5W7lQeYD2h70f+is 91XAds9KtJLD/LI/NUmotonmjMeulB4mGrcR1ZebXjZd98tRvnNCWDN/5bFaUMOj Fo0Sa8nbn0chKH0Z23ydv6pC158lG2SQW5c7o9j7RN7h4jlxPIr/lWLVk/h9j+Pz h+OdrOFPcePLTlqvFFsiqeWkO2GVZazXbFhTfBmB1XsolkDqNMsLl+2kF9ykOvh4 pW6FE/EUl7EdN3xfaPtVCwRL8KsaSI9WwP6p9DxI6moVi5x1A4vn3wZ+YHC936Ag dAgNnffFCm/DtFycTNwcDqjN2Pyyt5PR6Obzdl40b69/fTLsSMCG/64iv0rp0qkA stCGOt3/6TzdwURW4+YrHlFKFlF3k02M1wskeeM9xz76r+QvsiOoJ7YG/+oHxYiH JJQ6v/wTRCq6T382Fmd4SGWHn2HVSnKcl6u1Sn3aHVTK4BIPjCQFj5FZTMcSIzb6 aeEZwrVgMnw3kGGgUWw892EsfdfBXRSFpE96TnWgp351D6kJrNzO0syfJX9I6lhU H8k+6LjWzetdLd28cMKQ =Qp3J -----END PGP SIGNATURE----- --7qqI6q2F871QlRX1eTvjRMbt1EctfASxe-- From nobody Wed Sep 17 14:58:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DBAFE1A6F56 for ; Wed, 17 Sep 2014 14:58:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.301 X-Spam-Level: X-Spam-Status: No, score=0.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MANGLED_BELOW=2.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RQasvO-G2O9p for ; Wed, 17 Sep 2014 14:58:55 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ED3A1A6F1D for ; Wed, 17 Sep 2014 14:58:55 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id r20so147075wiv.12 for ; Wed, 17 Sep 2014 14:58:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=W252Ek0BAi1wJ1SVb8OHqwI9vokyryM5dsXnnymt/78=; b=k1wz69f7eWz186ibY7+Tf1gs3S/oe1ylgU9kijvHSSZbl10vUvQIYtvPcMSRhl2jpy m0MRdiO69di136rb6d4Bo1pm52ynPSaR8iBUGlnUNrDvvRMLmi+sDn8rs0mEzQBgJTdH ndvbkxPXbrp7qxhVr4BsAcIjfBHR0rla5YiSxzLL+driXfbYFMrlkr43hCrFUgCF/I4k +KTmOMEqNMhrSdA3VzTuopKRunxrNLU/P4NK7Hvsrzm+DA53GYMtPRNnfE5ZfqtB1z5f jcPJlfXPlTMySBw6gQ5UzZy6p+94vsOavJOsHO3+i3vlnaZNB8d36aLKmhu5DXUmhw9x 5ATQ== X-Received: by 10.181.27.197 with SMTP id ji5mr32354510wid.54.1410991134117; Wed, 17 Sep 2014 14:58:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.180.197.136 with HTTP; Wed, 17 Sep 2014 14:58:34 -0700 (PDT) In-Reply-To: <541A02C6.3010500@fifthhorseman.net> References: <92626AAF-4530-4E6F-BBC7-6219F316FB08@ieca.com> <541A02C6.3010500@fifthhorseman.net> From: Karthik Bhargavan Date: Wed, 17 Sep 2014 17:58:34 -0400 Message-ID: To: Daniel Kahn Gillmor Content-Type: multipart/alternative; boundary=001a1134894854959a050349f96a Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DmfJkQf3AEn7tKyWxg7t2DlW9rI Cc: "TLS@ietf.org \(tls@ietf.org\)" Subject: Re: [TLS] fall interim attendance check X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 17 Sep 2014 21:58:57 -0000 --001a1134894854959a050349f96a Content-Type: text/plain; charset=UTF-8 We'll be present (as hosts) and would be happy to present and discuss any changes to or implementations of draft-tls-session-hash. Karthik On Wed, Sep 17, 2014 at 5:53 PM, Daniel Kahn Gillmor wrote: > On 09/17/2014 12:32 PM, Sean Turner wrote: > > The chairs are concerned that the participation at the interim will be > low and may not be a good use of time. If you are planning to attend the > interim please send a message to the chairs to let them know. > > I plan on attending the October interim. > > --dkg > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a1134894854959a050349f96a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
We'll be present (as hosts) and would be happy to pres= ent and discuss any changes to or implementations of draft-tls-session-hash= .

Karthik=C2=A0
On Wed, Sep 17, 2014 at 5:53 PM, Daniel Kahn G= illmor <dkg@fifthhorseman.net> wrote:
On 09/17/2014 12:32 PM, Sean Turner wrote:
> The chairs are concerned that the participation at the interim will be= low and may not be a good use of time.=C2=A0 If you are planning to attend= the interim please send a message to the chairs to let them know.

I plan on attending the October interim.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 --dkg


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


--001a1134894854959a050349f96a-- From nobody Wed Sep 17 18:16:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E68A1A6F93 for ; Wed, 17 Sep 2014 18:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.152 X-Spam-Level: X-Spam-Status: No, score=-5.152 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BUDrr6_G7vIQ for ; Wed, 17 Sep 2014 18:16:27 -0700 (PDT) Received: from smtpde02.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB3C1A6F7D for ; Wed, 17 Sep 2014 18:16:27 -0700 (PDT) Received: from mail05.wdf.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id s8I1GMpC002695 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Sep 2014 03:16:23 +0200 (MEST) In-Reply-To: <20140912200607.GE16660@localhost> To: Nico Williams Date: Thu, 18 Sep 2014 03:16:22 +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: <20140918011622.CB9391AE4C@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) X-SAP: out Archived-At: http://mailarchive.ietf.org/arch/msg/tls/qNTHdfYeJKDc8d0mSdCmYzV8rnw Cc: Markulf Kohlweiss , "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 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: Thu, 18 Sep 2014 01:16:29 -0000 Nico Williams wrote: > On Thu, Sep 11, 2014 at 05:18:37PM +0200, Martin Rex wrote: > > I also don't understand why the fact that TLS finished messages are > > encrypted would make any proof harder. I believe that to be untrue. > > Hugo K.'s rationale is that you then need to have replay protection. We > need replay protection anyways, but if you're only analyzing the > handshake then it helps to not have to include subsequent replay > protection in the analysis. Somehow that argument feels quite lame when it is combined with the argument "the proof would be easier when the finished messages were sent in the clear, could we not change this". Just do the proof under the assumption/premise that the finished messages *ARE* in the clear. Then send them encrypted. Unless you're doing avoidable weird things, sending them encrypted rather then in the clear should not affect the original proof at all. If the TLS channel would be sensitive to what exact data is transferred within that encrypted channel, then you would have *MUCH* larger problems and it would apply to just about any kind of arbitrary application data. -Martin From nobody Wed Sep 17 18:45:08 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7ADC1A002A for ; Wed, 17 Sep 2014 18:45:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.123 X-Spam-Level: X-Spam-Status: No, score=0.123 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wfw-fkiGiEs5 for ; Wed, 17 Sep 2014 18:45:03 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BAD41A0684 for ; Wed, 17 Sep 2014 18:45:02 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id ty20so216412lab.37 for ; Wed, 17 Sep 2014 18:45:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=tMRnGIYKwKwtAMam55s0hQQ6gIhNLIXyrbqgTarQCyQ=; b=Ftc4O1jGdcqSzn0nOWFRcx17B0Fkr+PbBtEd/DoASWh7pw3ZgiCKogTMSiO5LE/9sy ubVEJmrcnaCMqDMR1WdNmQ1ZBd8smNeQ5+SUWN+qS2RLZ/UtkQ2pgHKDUnr3VN2kyKI5 cB/LJrfl4s7Ev0eDmhuo9haPau87rn9qezOh5XLFzSIOoZsDNpQ86RPgQwlbjoQTFMWg WGZu7bN/hA8TNXA5kSCzE2mXwzf2ZD7Z49vYmDrAGCqjl2BWyCVAEGWBkKU0MVCyISAP n0we042rHB+udys6l2Xtpe3sqSBVZBCNlebSNnpWq7PhddYVrfmctG6TkPj7PWQbyPOc ezBA== X-Received: by 10.112.169.33 with SMTP id ab1mr1025599lbc.6.1411004701331; Wed, 17 Sep 2014 18:45:01 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.16.135 with HTTP; Wed, 17 Sep 2014 18:44:31 -0700 (PDT) In-Reply-To: <20140913001943.6EE211AE43@ld9781.wdf.sap.corp> References: <20140913001943.6EE211AE43@ld9781.wdf.sap.corp> From: Hugo Krawczyk Date: Wed, 17 Sep 2014 21:44:31 -0400 X-Google-Sender-Auth: -obwIyvsQ0VJ8RGHM4-AJJvon5s Message-ID: To: mrex@sap.com Content-Type: multipart/alternative; boundary=001a11c26306ffd5da05034d219d Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FDV7TTZAk27xWFOBJgcA5dMP35w Cc: "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 18 Sep 2014 01:45:05 -0000 --001a11c26306ffd5da05034d219d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Sep 12, 2014 at 8:19 PM, Martin Rex wrote: > Hugo Krawczyk wrote: > > > > Let me exemplify how encrypting the Finish message breaks the generic > > security of the protocol, hence also its modularity. > > While I think that your modularity argument has a little merit, > I do not buy the "generic security" idea at all, which I liken to > what Jeff Schiller used to call "magic security pixie dust", > because it is what has caused by far the most security goofs > over the past decades. > =E2=80=8BI have no idea what you understand by generic security but it is c= ertainly not what I (and the cryptographic literature) mean by that. There is no magic in this notion, not in dust or any other form. Generic security refers to well-defined (mathematical) notions=E2=80=8B =E2=80=8Bof security pertaining to some security/cryptography task. Key exc= hange is such a task that is defined in a way that is independent of applications. This is the meaning of "generic". It has the advantage, as I mentioned in my email, to support cryptographic designs that can work independently of, and with, multiple applications. As with any mathematical model of an engineering problem the guarantees you get following this approach are limited by the model itself. In the case of cryptography, a model may not cover all avenues of attack or may make some assumptions not met in some scenarios. Therefore, generic security is no magic, in particular no magic bullet. But it is one of the best tools we have to design sound cryptography and the track record of this approach is MUCH better than the design by intuition-only or by "word of gentleman" (such as "trust me - if there was a problem in this design I would have spotted it already"). Of course, one can use the "word of gentleman" approach also to the selection of cryptographic models and definitions. Luckily we have a very active and vibrant community reviewing these notions and adapting them to new realities and new findings. Formal models and definitions are thus tools to inform us about good and bad designs. While these should not be the only elements for judging cryptographic constructs, ignoring them would take us back 20 years - the days of "I know better - trust me" (and 20 years of demonstrations of why that approach didn't work too well). > Apps can't wait to get their hands on "generic security" stuff, > a number of folks seem to assume that TLS was/is/or should be the > IETFs magic security pixie dust. But I do not believe you could > design such a thing (at least not one that is practical to the > real world IETF audience), even when starting from scratch. > > > IPsec originally went overboard with modularization and offered > integrity and confidentiality as seperate and indendent services. > Maybe you should re-check how that ended. > > =E2=80=8BThis example is indeed illustrative of generic security=E2=80=8B =E2=80=8Bbut not in the way you present it. When one asks the question of how to build a "secure channel" (a notion that requires a definition) between two endpoints that share a secret key there are different solutions depending on the type of encryption and authentication you use. But there is only one generic-secure solution: you first encrypt then authenticate the ciphertext. It means that any encryption that is generically secure against passive attacks combined in that particular way with any authentication mechanism secure against chosen message attack will give you a secure channel. Other combinations may or may not work hence they are not generically secure. As for IPsec, there are many things to complain about ipsec but except for the historic case of independent ESP and AH (deprecated quite early in that history), IPSec has done the right thing: Use generic encrypt-then-authenticate. IPsec did also much better than TLS with repect to cryptographic key exchange - even in the case of IKEv1 the problems were of unnecessary options and complexity, not of insecurity of the basic cryptographic mechanisms. =E2=80=8B > There is no such thing as generic security, and being greedy on > security does not pay off. > =E2=80=8B??? =E2=80=8B > Deploying the fully backwards compatible 1/(n-1) TLS record splitting > countermeasure for the paranoids that misunderstand the BEAST as a > practical attack/vulnerability, would not have been possible if > TLSv1.0 had not been encrypting the MAC. > > I've seen an implementation bug vaguely similar to OpenSSL CVE-2014-0224 > (premature ChangeCipherSpec), but where the fact that the TLS finished > messages are encrypted prevented that bug from becoming exploitable > (because traffic protection keys computed from an empty premaster secret > were only used on one of the communication directions, they keys for > the other direction were properly computed. > > > I consider using seperate/independent keys for handshake and app data > a bad idea, because it will significatly increase protocol and > implementation > complexity _without_ adding value. And you should keep in mind > just how many serious and silly bugs already affect implementations > of the current TLS protocol versions in the real world. > > > One of the downsides of > =E2=80=8B=E2=80=8B > spartanic theoretic cryptography is that it > is often hard to support and brittle like hell. We need less > of the > =E2=80=8B=E2=80=8B > cryptoglycerin stuff, not more of it, and stuff that is easy > to implement, test and support, rather than complex stuff where > the result of (interop) failures is an opaque "failed". > =E2=80=8Bto the contrary, good crypto theory can inform you about how to si= mplify designs by getting rid of unnecessary (and often counterproductive) safety margins. It is a very practical theory if you know how to use it. I guess that glycerin is also quite practical if you know how to use it... Hugo =E2=80=8B > > (did you ever have to help app folks troubleshooting app bugs or weird > network > data corruptions that make xmldsig signature verifications fail? > You might start to appreciate the properties of RSA PKCS#1 v1.5 signatur= es > over other signature schemes). > > > -Martin > --001a11c26306ffd5da05034d219d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Sep 12, 2014 at 8:19 PM, Martin Rex <mrex@sap.com= > wrote:
Hugo Krawczyk wrote:
>
> Let me exemplify how encrypting the Finish message breaks the generic<= br> > security of the protocol, hence also its modularity.

While I think that your modularity argument has a little merit,
I do not buy the "generic security" idea at all, which I liken to=
what Jeff Schiller used to call "magic security pixie dust",
because it is what has caused by far the most security goofs
over the past decades.

= =E2=80=8BI have no idea what you understand by generic security but it is c= ertainly not what I (and the cryptographic literature) mean by that. There = is no magic in this notion, not in dust or any other form. Generic security= =C2=A0 refers to well-defined (mathematical) notions=E2=80=8B
=C2=A0=E2=80=8Bof security pertaining to some security/cr= yptography task. Key exchange is such a task that is defined in a way that = is independent of applications. This is the meaning of "generic".= It has the advantage, as I mentioned in my email, to support cryptographic= designs that can work independently of, and with, multiple applications. A= s with any mathematical model of an engineering problem the guarantees you = get following this approach are limited by the model itself. In the case of= cryptography, a model may not cover all avenues of attack or may make some= assumptions not met in some scenarios. Therefore, generic security is no m= agic, in particular no magic bullet. But it is one of the best tools we hav= e to design sound cryptography and the track record of this approach is MUC= H better than the design by intuition-only or by "word of gentleman&qu= ot; (such as "trust me - if there was a problem in this design I would= have spotted it already"). Of course, one can use the "word of g= entleman" approach also to the selection of cryptographic models and d= efinitions. Luckily we have a very active and vibrant community reviewing t= hese notions and adapting them to new realities and new findings. Formal mo= dels and definitions are thus tools to inform us about good and bad designs= . While these should not be the only elements for judging cryptographic con= structs, ignoring them would take us back 20 years - the days of "I kn= ow better - trust me" (and 20 years of demonstrations of why that appr= oach didn't work too well).


Apps can't wait to get their hands on "generic security" stuf= f,
a number of folks seem to assume that TLS was/is/or should be the
IETFs magic security pixie dust.=C2=A0 But I do not believe you could
design such a thing (at least not one that is practical to the
real world IETF audience), even when starting from scratch.


IPsec originally went overboard with modularization and offered
integrity and confidentiality as seperate and indendent services.
Maybe you should re-check how that ended.

=E2=80=8BThis example is in= deed illustrative of generic security=E2=80=8B
=C2=A0
=E2=80=8Bbut not in the way you present it.
When one asks the question of how to build a "secure chan= nel" (a notion that requires a definition) between two endpoints that = share a secret key there are different solutions depending on the type of e= ncryption and authentication you use. But there is only one generic-secure = solution: you first encrypt then authenticate the ciphertext. It means that= any encryption that is generically secure against passive attacks combined= in that particular way with any authentication mechanism secure against ch= osen message attack will give you a secure channel. Other combinations may = or may not work hence they are not generically secure.

As for IPsec, there are many things to complain about=C2= =A0 ipsec but except for the historic case of independent ESP and AH (depre= cated quite early in that history), IPSec has done the right thing: Use gen= eric encrypt-then-authenticate. IPsec did also much better than TLS with re= pect to cryptographic key exchange - even in the case of IKEv1 the problems= were of unnecessary options and complexity, not of insecurity of the basic= cryptographic mechanisms.

=E2=80= =8B
There is no such thing as generic security, and being greedy on
security does not pay off.

=E2=80=8B???
=E2=80=8B


Deploying the fully backwards compatible 1/(n-1) TLS record splitting
countermeasure for the paranoids that misunderstand the BEAST as a
practical attack/vulnerability, would not have been possible if
TLSv1.0 had not been encrypting the MAC.

I've seen an implementation bug vaguely similar to OpenSSL CVE-2014-022= 4
(premature ChangeCipherSpec), but where the fact that the TLS finished
messages are encrypted prevented that bug from becoming exploitable
(because traffic protection keys computed from an empty premaster secret were only used on one of the communication directions, they keys for
the other direction were properly computed.


I consider using seperate/independent keys for handshake and app data
a bad idea, because it will significatly increase protocol and implementati= on
complexity _without_ adding value.=C2=A0 And you should keep in mind
just how many serious and silly bugs already affect implementations
of the current TLS protocol versions in the real world.


One of the downsides of
=E2=80=8B=E2=80=8B
s= partanic theoretic cryptography is that it
is often hard to support and brittle like hell.=C2=A0 We need less
of the
=E2=80=8B=E2=80=8B
cryptoglycerin stu= ff, not more of it, and stuff that is easy
to implement, test and support, rather than complex stuff where
the result of (interop) failures is an opaque "failed".

=E2=80=8Bto the contrary, good cr= ypto theory can inform you about how to simplify designs by getting rid of = unnecessary (and often counterproductive) safety margins. It is a very prac= tical theory if you know how to use it. I guess that glycerin is also quite= practical if you know how to use it...

Hugo=C2=A0
=E2=80=8B
=C2=A0

(did you ever have to help app folks troubleshooting app bugs or weird netw= ork
=C2=A0data corruptions that make xmldsig signature verifications fail?
=C2=A0You might start to appreciate the properties of RSA PKCS#1 v1.5 signa= tures
=C2=A0over other signature schemes).


-Martin

--001a11c26306ffd5da05034d219d-- From nobody Wed Sep 17 19:03:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A071A6F41 for ; Wed, 17 Sep 2014 19:03:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n6ej01KtqC6S for ; Wed, 17 Sep 2014 19:03:11 -0700 (PDT) Received: from mail-qc0-x22c.google.com (mail-qc0-x22c.google.com [IPv6:2607:f8b0:400d:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C2AC1A6FD2 for ; Wed, 17 Sep 2014 19:03:11 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id x13so326138qcv.31 for ; Wed, 17 Sep 2014 19:03:10 -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=8kXegjCAxs31q9AS06Y7EtQfOToUbOIoLgUAMxFb/dA=; b=0nKyA9tQTMU7wtWpii/oEWDgJRKNh8W9l2K48EmF68W8teofOrlFu9wQZ9To8JuQqO v9rTjeyDf7gVM85u58FIyZ6vmwAfCmO7RFZpL1a2lahQfexypyX/wNtb+fgyu5CSwp3K UWVNrv7kuh2MY/PYHp1Ybwt1uxt3LAiJw4sXBP2BnEx9DEiIeLY1R38aRNzLVG1LJic4 ssa/eaj6ybjCCYlTUcuwEQ5fXCFXKjTlihVyMRMDw4GXTrQAvQvTbiQEiTXiNtT+QmIA B0XaRpRNUm9TjknUCbFWjiEoowrtFXTNieNhPiJUxiipMnXiB/FHPr89PUoltWCgUxhN CKmQ== MIME-Version: 1.0 X-Received: by 10.236.231.178 with SMTP id l48mr808039yhq.143.1411005790545; Wed, 17 Sep 2014 19:03:10 -0700 (PDT) Received: by 10.170.207.216 with HTTP; Wed, 17 Sep 2014 19:03:10 -0700 (PDT) In-Reply-To: <20140918011622.CB9391AE4C@ld9781.wdf.sap.corp> References: <20140912200607.GE16660@localhost> <20140918011622.CB9391AE4C@ld9781.wdf.sap.corp> Date: Wed, 17 Sep 2014 19:03:10 -0700 Message-ID: From: Watson Ladd To: "mrex@sap.com" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/oTZAIpnd0NhLqD4_-18VjcGcl6c Cc: Markulf Kohlweiss , "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 18 Sep 2014 02:03:13 -0000 On Wed, Sep 17, 2014 at 6:16 PM, Martin Rex wrote: > Nico Williams wrote: >> On Thu, Sep 11, 2014 at 05:18:37PM +0200, Martin Rex wrote: >> > I also don't understand why the fact that TLS finished messages are >> > encrypted would make any proof harder. I believe that to be untrue. >> >> Hugo K.'s rationale is that you then need to have replay protection. We >> need replay protection anyways, but if you're only analyzing the >> handshake then it helps to not have to include subsequent replay >> protection in the analysis. > > Somehow that argument feels quite lame when it is combined with the > argument "the proof would be easier when the finished messages were > sent in the clear, could we not change this". > > Just do the proof under the assumption/premise that the finished messages > *ARE* in the clear. Then send them encrypted. Unless you're doing avoidable > weird things, sending them encrypted rather then in the clear should not > affect the original proof at all. Yes, that's what previous analysis had to do. In combination with other misfeatures (need for Oracle DH assumptions, additional complexity) the result was that protocol weaknesses went undetected. The bigger the difference between TLS and the protocol that is actually analyzed, the weaker the guaranties are about the safety of TLS. Furthermore the space of changes people make to TLS is much larger than is actually realized: take all the RFCs referring to any version of TLS, and consider that each one may or may not be implemented. The resulting combinatorial explosion cannot be dealt with except by modularizing the proof. TLS 1.3 adds new tricks, like Zero-RTT, one-RTT forms, and possibly new forms of encrypted data. The easier it is to analyze the core protocol the easier it will be to analyze these proposals, and fix them. Most of the people who are making proposals including myself have not got the ability or time to do a proper analysis. The few people who do are really overworked, and so far we've heard nothing from them (for good reason: you don't want a late change to turn a significant amount of work into a nonstarter) It is a substantially more complicated protocol. We need to think about how to avoid the past two decades of major cryptographic weaknesses, repeatedly identified in TLS implementations, some of which are still not fixed. Sincerely, Watson Ladd > > If the TLS channel would be sensitive to what exact data is transferred > within that encrypted channel, then you would have *MUCH* larger problems > and it would apply to just about any kind of arbitrary application data. > > -Martin -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Wed Sep 17 20:40:55 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8670D1A6F68 for ; Wed, 17 Sep 2014 20:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sePXA5mPg0ge for ; Wed, 17 Sep 2014 20:40:53 -0700 (PDT) Received: from homiemail-a102.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 8A11A1A6FF8 for ; Wed, 17 Sep 2014 20:40:48 -0700 (PDT) Received: from homiemail-a102.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTP id 52F502006D30F; Wed, 17 Sep 2014 20:40:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=43KNauCN2evvpV axG6edDw5BeLI=; b=XbNtt+/C6os17StiXQVwXnAucmwWTC04buDrQxwhVrvWjr YFlBGPBl7/dOXeAm+UlatQLRyEPYT5mOHAy+YDuyxgZUHLSvCAdZelYm0aOqNQUl D5pVoAQDy12Q2k2l77qAbIx6zEUWnMURtit+s2Yp2WCLTfkYZ2IDc8/zQ11XM= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a102.g.dreamhost.com (Postfix) with ESMTPA id E41902006D30D; Wed, 17 Sep 2014 20:40:47 -0700 (PDT) Date: Wed, 17 Sep 2014 22:40:47 -0500 From: Nico Williams To: Martin Rex Message-ID: <20140918034042.GA4273@localhost> References: <20140912200607.GE16660@localhost> <20140918011622.CB9391AE4C@ld9781.wdf.sap.corp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140918011622.CB9391AE4C@ld9781.wdf.sap.corp> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/JpPv5BQRfxBev-SL3bbsVml-bzc Cc: Markulf Kohlweiss , "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 18 Sep 2014 03:40:54 -0000 On Thu, Sep 18, 2014 at 03:16:22AM +0200, Martin Rex wrote: > Nico Williams wrote: > > On Thu, Sep 11, 2014 at 05:18:37PM +0200, Martin Rex wrote: > > > I also don't understand why the fact that TLS finished messages are > > > encrypted would make any proof harder. I believe that to be untrue. > > > > Hugo K.'s rationale is that you then need to have replay protection. We > > need replay protection anyways, but if you're only analyzing the > > handshake then it helps to not have to include subsequent replay > > protection in the analysis. > > Somehow that argument feels quite lame when it is combined with the > argument "the proof would be easier when the finished messages were > sent in the clear, could we not change this". > > Just do the proof under the assumption/premise that the finished messages > *ARE* in the clear. Then send them encrypted. Unless you're doing avoidable > weird things, sending them encrypted rather then in the clear should not > affect the original proof at all. To me the argument feels lame because we must anyways be able to distinguish record types[0] and detect replays[1] (at least for TLS, and for DTLS[2] I would argue that replays of handshake messages must always be enabled). [0] Certainly if we retain any asynchronous handshake or other non-application records post-initial handshake then we must be able to securely distinguish record types! [1] Certainly if we retain any asynchronous... then we must be able to securely detect replays. [2] I understand application record replay detection being optional in DTLS. But certainly it mustn't be for any async handshake records. From nobody Wed Sep 17 20:43:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 074A31A0690 for ; Wed, 17 Sep 2014 20:43:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.666 X-Spam-Level: X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CfC9gUg6vcMV for ; Wed, 17 Sep 2014 20:43:02 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 79EE61A04B6 for ; Wed, 17 Sep 2014 20:43:02 -0700 (PDT) Received: from homiemail-a111.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTP id 2FEA42007F00A; Wed, 17 Sep 2014 20:43:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=RMNYP5c5hbrhgr b+yPA1yg1v4cM=; b=W+n4+KOPXMTIWQHIvlWS4TxbScb8YKrsnX1wjPr/qPknjb jdcUHRv7qTvLI+ZcroAhiR5kKSitJssTbybNGMND1GcEH7ohRe2vCBWvf1s2klRy 0yRzyY9xW+8xH8isRuOJUg1r4LAtMlqo7dKDUIyEuo1qaQyxlBp2QxXEroAzw= Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a111.g.dreamhost.com (Postfix) with ESMTPA id BE7822007F003; Wed, 17 Sep 2014 20:43:01 -0700 (PDT) Date: Wed, 17 Sep 2014 22:43:01 -0500 From: Nico Williams To: Martin Rex Message-ID: <20140918034255.GB4273@localhost> References: <20140912200607.GE16660@localhost> <20140918011622.CB9391AE4C@ld9781.wdf.sap.corp> <20140918034042.GA4273@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140918034042.GA4273@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rb3e22Z55IbPqJpgfQJ6rCfzdEU Cc: Markulf Kohlweiss , "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 18 Sep 2014 03:43:03 -0000 To clarify: I don't oppose not encrypting the Finished messages, and IMO it is better to not encrypt them. From nobody Wed Sep 17 21:29:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84B0E1A0680 for ; Wed, 17 Sep 2014 21:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8e4cIn6aIIq6 for ; Wed, 17 Sep 2014 21:29:28 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0432E1A01E0 for ; Wed, 17 Sep 2014 21:29:27 -0700 (PDT) Received: by mail-qg0-f44.google.com with SMTP id z107so426710qgd.3 for ; Wed, 17 Sep 2014 21:29:27 -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=vsqT/nzbDiX13JzzLqvP1XDfy6+1pKHh5cf1QRhhZS4=; b=VzqNgSdk7APUtNaO0vuzDDdb/G0qvL8Iwlmgg8gFZAWNsi9/x5lm8I1muCQgVcu4JG 91OJd0Rmq8mAiKfsRGTjs8OMpTGmXnNLt1/UwCLCoptHFINLEszOEPeNzbHsAHCWxDhW +fia1uyty6ix9iltH2mlm2H1+EsVXKZ4/cTF160KIAPdjGEG+6oAvcB+mhg46E1I8rK4 s2GHo2HbyOZsDOE6Q+l6nFEKhQzazfowG3rzp1dIY+y7Zyna3TufcpeVwHjS9o08enx6 EIhHaOvZrsEzksjaTIJAtfwC9EmsGQGwXjOwKRiVkCUtRZ4tPEjVkKu7W1R4BNblP2d4 oB7A== MIME-Version: 1.0 X-Received: by 10.236.8.69 with SMTP id 45mr1411760yhq.19.1411014567249; Wed, 17 Sep 2014 21:29:27 -0700 (PDT) Received: by 10.170.207.216 with HTTP; Wed, 17 Sep 2014 21:29:27 -0700 (PDT) In-Reply-To: <20140918034042.GA4273@localhost> References: <20140912200607.GE16660@localhost> <20140918011622.CB9391AE4C@ld9781.wdf.sap.corp> <20140918034042.GA4273@localhost> Date: Wed, 17 Sep 2014 21:29:27 -0700 Message-ID: From: Watson Ladd To: Nico Williams Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/TwXOMCUEY3vyUT5tL-xkMGQ9108 Cc: Markulf Kohlweiss , "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 18 Sep 2014 04:29:29 -0000 On Wed, Sep 17, 2014 at 8:40 PM, Nico Williams wrote: > On Thu, Sep 18, 2014 at 03:16:22AM +0200, Martin Rex wrote: >> Nico Williams wrote: >> > On Thu, Sep 11, 2014 at 05:18:37PM +0200, Martin Rex wrote: >> > > I also don't understand why the fact that TLS finished messages are >> > > encrypted would make any proof harder. I believe that to be untrue. >> > >> > Hugo K.'s rationale is that you then need to have replay protection. We >> > need replay protection anyways, but if you're only analyzing the >> > handshake then it helps to not have to include subsequent replay >> > protection in the analysis. >> >> Somehow that argument feels quite lame when it is combined with the >> argument "the proof would be easier when the finished messages were >> sent in the clear, could we not change this". >> >> Just do the proof under the assumption/premise that the finished messages >> *ARE* in the clear. Then send them encrypted. Unless you're doing avoidable >> weird things, sending them encrypted rather then in the clear should not >> affect the original proof at all. > > To me the argument feels lame because we must anyways be able to > distinguish record types[0] and detect replays[1] (at least for TLS, and > for DTLS[2] I would argue that replays of handshake messages must always > be enabled). That wasn't the argument Mr. Krawczyk and I made. TLS provides a secure channel, and we know how to prove it does. Rather the problem is that some applications like RFCs I've cited, that are deployed, use the TLS handshake to derive a key that is used for another purpose. This is not safe without analysing the specifics of the encryption scheme used. In particular, an application that has its own record layer may interpret the Finished message in strange ways. This can cause problems. There are other unpatched issues, like the possibility to misinterpret the Server Key Exchange field and use this to impersonate a server, that need addressing. And so far nothing has been said about the proposed changes. Sincerely, Watson Ladd > > [0] Certainly if we retain any asynchronous handshake or other > non-application records post-initial handshake then we must be able > to securely distinguish record types! > > [1] Certainly if we retain any asynchronous... then we must be able to > securely detect replays. > > [2] I understand application record replay detection being optional in > DTLS. But certainly it mustn't be for any async handshake records. -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Sep 18 02:25:45 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD3BE1A86F8; Thu, 18 Sep 2014 02:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.554 X-Spam-Level: X-Spam-Status: No, score=-8.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id opI3eG8_xo89; Thu, 18 Sep 2014 02:25:43 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B71B1A86F3; Thu, 18 Sep 2014 02:25:43 -0700 (PDT) Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8I9Pa0n029198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 18 Sep 2014 05:25:37 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8I9PXZ5027766 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 18 Sep 2014 05:25:35 -0400 Message-ID: <1411032333.18523.18.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Tom Ritter Date: Thu, 18 Sep 2014 11:25:33 +0200 In-Reply-To: References: <1409931283.1731.16.camel@dhcp-2-127.brq.redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cSdX1hfu2fxCW_kteFATHverVkY Cc: "pkix@ietf.org" , Phillip Hallam-Baker , "tls@ietf.org" Subject: Re: [TLS] New version of the TLS feature draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 18 Sep 2014 09:25:44 -0000 On Sat, 2014-09-13 at 20:20 -0500, Tom Ritter wrote: > On 5 September 2014 10:34, Nikos Mavrogiannopoulos wrote: > > I don't see how it does close the door. What should the client do if the > > server administrator sets up an old version of a valid ocsp staple? > > Section 3.1.1 specifies "a server MUST return a valid OCSP token". I > would consider an expired ocsp staple to not actually be valid. I > would refer to it as expired, with the implication that the signature > is correct, because if it wasn't a person probably would have said > that in addition to describing it as expired. That's pretty sketchy. OCSP responses have a recommended validity interval, this is not the same as X.509 certificate expiration. I'm not sure what popular browsers do with responses received by the server that are outside the validity period, but I would be very surprised if they dropped the connection. If in this document it is assumed that responses not within the recommended interval should cause a TLS connection failure, it should be explicit. regards, Nikos From nobody Thu Sep 18 02:35:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2560A1A032A for ; Thu, 18 Sep 2014 02:35:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[AC_BR_BONANZA=0.001, BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dj7r7sOKdeka for ; Thu, 18 Sep 2014 02:35:10 -0700 (PDT) Received: from mail-oi0-x236.google.com (mail-oi0-x236.google.com [IPv6:2607:f8b0:4003:c06::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A024D1A8719 for ; Thu, 18 Sep 2014 02:35:10 -0700 (PDT) Received: by mail-oi0-f54.google.com with SMTP id a3so441203oib.27 for ; Thu, 18 Sep 2014 02:35:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pironti.eu; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=BRXojDSI/RACJb/Kkagk2lcouEYakSysB6RkyPS4pME=; b=VCiKojt4s1GCfEEvrDY7efcbrVFgkoH/C0Bo8d5czgycGrLzoHAthYuc6gLA5wDyE3 rwT9L3h8fMCsdE6nF+F3Yzas8wrDTysaZeRwEtaRwnVvNPSrwuDVQD383eUv6dsDfQEj uqnF1vLud6PTJZf8FJmxVvnxVx1Q4Isqjyp24= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BRXojDSI/RACJb/Kkagk2lcouEYakSysB6RkyPS4pME=; b=M7zx1y7eBJcT6OtGM26ByJNyWO0PoVhryaIUbOwGDBKRmjMJ6FO9LjdaCGSZsRm4Wz dWcjKEa8ocpu+TFngegTEtwWtl+Sjywh+gLrv5Ul/ovuaSvqLcvodnb9zrN2c39Jywgw ntpfa6M2CzhjfrPdsV91CpMuWMVwN0KXWdR1EqkGEXw6wjs/fxTkUXb1aF3Dv68MLQjg Z08mWDKpHVpZC0dN35d7Dt1CmorNHtzCjDAAqxj17lMQgwJ+DBmYatoeU4rXmxx6ILob KsVJW4SsWwICd5LJtlGwncd97kCb1x1jRUWp3JQrnfPbAmCrvABWkK4jvOsxRu9zF66d nTJA== X-Gm-Message-State: ALoCoQl1THEwidhOXdPzRpCIVhE9Ttr0vmEBS7RchfOaZGq9U6cQKFcYln47wdoE/PXXppVuPnZJ MIME-Version: 1.0 X-Received: by 10.60.230.70 with SMTP id sw6mr3058950oec.36.1411032909958; Thu, 18 Sep 2014 02:35:09 -0700 (PDT) Received: by 10.76.90.168 with HTTP; Thu, 18 Sep 2014 02:35:09 -0700 (PDT) X-Originating-IP: [128.93.62.11] In-Reply-To: <002301cfcc9d$91f6b4f0$b5e41ed0$@augustcellars.com> References: <00d201cfc63b$1c48b1d0$54da1570$@augustcellars.com> <002301cfcc9d$91f6b4f0$b5e41ed0$@augustcellars.com> Date: Thu, 18 Sep 2014 11:35:09 +0200 Message-ID: From: Alfredo Pironti To: Jim Schaad Content-Type: multipart/alternative; boundary=001a11363c9c5d6919050353b313 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YoyumSHby60WD-GjdFesQwpGmjA Cc: "tls@ietf.org" Subject: Re: [TLS] Master Secret Computation X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 18 Sep 2014 09:35:15 -0000 --001a11363c9c5d6919050353b313 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Sep 10, 2014 at 4:18 AM, Jim Schaad wrote: > As I said in my message, I believe that these issues apply both the TLS > 1.3 document and to the session hash document. The questions that I woul= d > have for the session hash document are: > > > > 1. Why is there not a justification of stopping the hash before > the CertVerify handshake message rather than before the Finish message > which is more logical. > I believe the justification is given at [1] "Implementation note": paragraph. [1] http://tools.ietf.org/html/draft-ietf-tls-session-hash-01#section-3 > 2. From the table that I included: Does the use of the > CertificateURL message cause a problem which has not been looked at. Sin= ce > this may not include any client specific data (the client certificate is > not sent), we are not back into a situation where the client identity and > identity key are not included as part of the computation for the master > secret. I can=E2=80=99t find it on a fast scan, but I believe that you = have > stated that hashing the client identity into the handshake messages is of > importance. This would appear to argue for hashing the CertificateVerify > handshake message since it would be a unique value for the client and > associated with the client certificate in this case. (Another way would = be > to hash in the result of getting the certificate from the URL but that is > probably not desirable.) > The table is not TLS <=3D 1.2. In general, the session hash captures the information that contributes to the session; TLS 1.3 has a different handshake flow, and I expect an updated definition of the session hash. Regarding URLs instead of certificates, this is an orthogonal problem: TLS provides handshake integrity, the integrity of the certificate retrieval seems out of scope (although security relevant). > 3. I don=E2=80=99t believe that there are any implications that com= e from > the use of the Supplemental Data and New Session Ticket handshake message= s, > however it would be good to state that this is the case. I would note th= at > in the case of the New Session Ticket messages, the one sent from the > server to the client can occur only after the client finish message has > been received so it cannot be part of the context used to build the maste= r > secret. > This is true for any data sent after the session hash is computed: they must not alter the state of the session. Alfredo > > > Jim > > > > > > *From:* Alfredo Pironti [mailto:alfredo@pironti.eu] > *Sent:* Wednesday, September 03, 2014 1:45 AM > *To:* Jim Schaad > *Cc:* tls@ietf.org > *Subject:* Re: [TLS] Master Secret Computation > > > > > > > > On Tue, Sep 2, 2014 at 1:18 AM, Jim Schaad wrote= : > > This message applies to both the 1.3 TLS document and to the session hash > document. > > > I have not ever implemented TLS, so I have been spending some time readin= g > the documents to try and figure out how things are going to work. Based = on > mail see, I have assumed that 1.3 is going to adopt the extended hash > computation for the master secret and have created my table based on this= . > (If this is not the case then I think it needs to be argued.) > > As part of putting together the attacked picture, I read a number of > different TLS documents which are not part of the core spec. It is > possible > that some of these are no longer needed and should be ruled out as possib= le > extensions to the TLS 1.3 document, but would be relevant to the extensio= n > for the 1.2 (and prior) documents. > > Notes on the picture that I have included: > > Items tagged with [1] are sent only in the event that the server does not > want to have a client certificate. > Items tagged with [2] are sent only in the event that the a) there is a > client certificate or b) the new session ticket extension is being used. > Items tagged with [3] are sent in the event that a restart is made becaus= e > of a mismatch of key agree groups. > > I am not clear if the use of the Supplemental Data extension means that t= he > server Finish message cannot be sent before receiving the response from t= he > client. > The new session ticket extension requires that the client finish message = be > validated before it can be sent to the client, thus it falls into the [2] > grouping. > > The green means that the handshake message is part of the hash computatio= n. > The yellow means that it would be part of the computation for [2] but not > for [1]. The "pink" is part of my assumption that a the hashing should > include the failed early handshake message. > > The current hashing document says that the hash would not include the > CertificateVerify message (for the client). I am assuming that this is > because there is a large presumption that the hash that is used for the P= RF > function and the hash that the client would use in computing the > CertificateVerify message is going to same. This presumption should > probably be documented. > > > > The hash used for signature and the one used for the PRF can indeed be > different. > The reason why we left CertificateVerify out from the session_hash is tha= t > the master_secret computation depends on session_hash. In turn, in SSL 3.= 0, > the computation of CertificateVerify depends on the master_secret. > This could be relaxed for later TLS versions, where the master_secret is > not used in the computation of the CertificateVerify message. However, > since CertificateVerify does not alter the state of the session, we left = it > out for all TLS versions, to ease implementation of the extension. > This choice is documented in the implementation note of section 3 of the > current session-hash draft. But if the text doesn't read clear enough, we > can try to improve it. > > > > > I am unsure what the correct behavior should be in the event that the > SupplementalData extension is used, but the client certificate message is > not used. Should this be part of the master secret hash or not? > > In looking at the sequence, doing a re-negotiation would seem to have a b= ad > property of going from the cipher suite which uses the hash of the > handshake > to one that just uses the keys and the randoms part way through the > re-negotiation process. This means that any application data sent betwee= n > the first and the second change_cipher_suite messages would potentially n= ot > be as well protected. This could be fixed by not having the first pair o= f > change_cipher_suite messages in the event of a re-negotiation as there is > no > need to go from a NULL_NULL cipher suite to one which has encryption. > > > > As discussed in the session-hash call for adoption thread [1], the > session-hash extension is mainly intended as a fix for TLS <=3D 1.2; wher= eas > the fix should be an integral part of TLS 1.3 (and how this is precisely > achieved is still under design). > > Best, > Alfredo > > [1] http://www.ietf.org/mail-archive/web/tls/current/msg13173.html > > > > > > Jim > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > > --001a11363c9c5d6919050353b313 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Sep 10, 2014 at 4:18 AM, Jim Schaad <ietf@augustcellars.c= om> wrote:

As I said in my message, I believe t= hat these issues apply both the TLS 1.3 document and to the session hash do= cument.=C2=A0 The questions that I would have for the session hash document= are:

=C2=A0

1.=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0Why is there not a justification of stopping the hash= before the CertVerify handshake message rather than before the Finish mess= age which is more logical.

I believ= e the justification is given at [1] "Implementation note": paragr= aph.

[1] http://tools.ietf.org/html/draft-ietf-tls-session-hash= -01#section-3
=C2=A0

2.=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 = From the table that I included:=C2=A0 D= oes the use of the CertificateURL message cause a problem which has not bee= n looked at.=C2=A0 Since this may not include any client specific data (the= client certificate is not sent), we are not back into a situation where th= e client identity and identity key are not included as part of the computat= ion for the master secret. =C2=A0=C2=A0I can=E2=80=99t find it on a fast sc= an, but I believe that you have stated that hashing the client identity int= o the handshake messages is of importance.=C2=A0 This would appear to argue= for hashing the CertificateVerify handshake message since it would be a un= ique value for the client and associated with the client certificate in thi= s case.=C2=A0 (Another way would be to hash in the result of getting the ce= rtificate from the URL but that is probably not desirable.)

The table is not TLS <=3D 1.2. In general, the = session hash captures the information that contributes to the session; TLS = 1.3 has a different handshake flow, and I expect an updated definition of t= he session hash. Regarding URLs instead of certificates, this is an orthogo= nal problem: TLS provides handshake integrity, the integrity of the certifi= cate retrieval seems out of scope (although security relevant).
=C2=A0

<= span>3.=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0 I don=E2=80=99t believe that there are any implications that come fr= om the use of the Supplemental Data and New Session Ticket handshake messag= es, however it would be good to state that this is the case.=C2=A0 I would = note that in the case of the New Session Ticket messages, the one sent from= the server to the client can occur only after the client finish message ha= s been received so it cannot be part of the context used to build the maste= r secret.


This is tr= ue for any data sent after the session hash is computed: they must not alte= r the state of the session.

Alfredo

=C2=A0

Jim<= u>

=C2=A0

=C2=A0

From: Alfredo Pironti [mailto:alfredo@pironti.eu]
Sent:= Wednesday, September 03, 2014 1:45 AM
To: Jim Schaad
C= c: tls@ietf.orgSubject: Re: [TLS] Master Secret Computation<= /p>

=C2=A0

=C2=A0

=C2=A0

On Tue, Sep 2, 2014 at 1:18 AM, Jim Schaad <ietf@augustcellars.com> wro= te:

This message applies to both th= e 1.3 TLS document and to the session hash
document.


I have n= ot ever implemented TLS, so I have been spending some time reading
the d= ocuments to try and figure out how things are going to work.=C2=A0 Based on=
mail see, I have assumed that 1.3 is going to adopt the extended hashcomputation for the master secret and have created my table based on this= .
(If this is not the case then I think it needs to be argued.)

A= s part of putting together the attacked picture, I read a number of
diff= erent TLS documents which are not part of the core spec.=C2=A0 It is possib= le
that some of these are no longer needed and should be ruled out as po= ssible
extensions to the TLS 1.3 document, but would be relevant to the = extension
for the 1.2 (and prior) documents.

Notes on the picture= that I have included:

Items tagged with [1] are sent only in the ev= ent that the server does not
want to have a client certificate.
Items= tagged with [2] are sent only in the event that the a) there is a
clien= t certificate or b) the new session ticket extension is being used.
Item= s tagged with [3] are sent in the event that a restart is made because
o= f a mismatch of key agree groups.

I am not clear if the use of the S= upplemental Data extension means that the
server Finish message cannot b= e sent before receiving the response from the
client.
The new session= ticket extension requires that the client finish message be
validated b= efore it can be sent to the client, thus it falls into the [2]
grouping.=

The green means that the handshake message is part of the hash comp= utation.
The yellow means that it would be part of the computation for [= 2] but not
for [1].=C2=A0 The "pink" is part of my assumption = that a the hashing should
include the failed early handshake message.
The current hashing document says that the hash would not include the<= br>CertificateVerify message (for the client).=C2=A0 I am assuming that thi= s is
because there is a large presumption that the hash that is used for= the PRF
function and the hash that the client would use in computing th= e
CertificateVerify message is going to same.=C2=A0 This presumption sho= uld
probably be documented.

=C2=A0

The hash used fo= r signature and the one used for the PRF can indeed be different.
The re= ason why we left CertificateVerify out from the session_hash is that the ma= ster_secret computation depends on session_hash. In turn, in SSL 3.0, the c= omputation of CertificateVerify depends on the master_secret.
This could= be relaxed for later TLS versions, where the master_secret is not used in = the computation of the CertificateVerify message. However, since Certificat= eVerify does not alter the state of the session, we left it out for all TLS= versions, to ease implementation of the extension.
This choice is docum= ented in the implementation note of section 3 of the current session-hash d= raft. But if the text doesn't read clear enough, we can try to improve = it.

=C2=A0=


I am unsure what the= correct behavior should be in the event that the
SupplementalData exten= sion is used, but the client certificate message is
not used.=C2=A0 Shou= ld this be part of the master secret hash or not?

In looking at the = sequence, doing a re-negotiation would seem to have a bad
property of go= ing from the cipher suite which uses the hash of the handshake
to one th= at just uses the keys and the randoms part way through the
re-negotiatio= n process.=C2=A0 This means that any application data sent between
the f= irst and the second change_cipher_suite messages would potentially not
b= e as well protected.=C2=A0 This could be fixed by not having the first pair= of
change_cipher_suite messages in the event of a re-negotiation as the= re is no
need to go from a NULL_NULL cipher suite to one which has encry= ption.

=C2= =A0

As discussed in the session= -hash call for adoption thread [1], the session-hash extension is mainly in= tended as a fix for TLS <=3D 1.2; whereas the fix should be an integral = part of TLS 1.3 (and how this is precisely achieved is still under design).=

Best,
Alfredo

[1] http://www.ietf.org/m= ail-archive/web/tls/current/msg13173.html

=

=C2=A0



Jim












=





















































<= br>

















=





















































<= br>

















=





















































<= br>

















=





















































<= br>

















=





















































<= br>

















=





















































<= br>

















=





















































<= br>

















=





















































<= br>

















=





















































<= br>

















=





















































<= br>














_____= __________________________________________
TLS mailing list
TLS@ietf.org
https://www.iet= f.org/mailman/listinfo/tls

=C2=A0

=

--001a11363c9c5d6919050353b313-- From nobody Thu Sep 18 04:29:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B0C1A017C for ; Thu, 18 Sep 2014 04:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.743 X-Spam-Level: X-Spam-Status: No, score=-5.743 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yz6TSzAZ75IP for ; Thu, 18 Sep 2014 04:29:50 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFEAC1A014D for ; Thu, 18 Sep 2014 04:29:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1411039790; x=2274953390; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Z5bd3NOO5zJohtn7ZZQ5RkWeAeo0P/+StbhO8YJ9MWg=; b=J4V98kzHhYblbScKE5Mj5Xr0SSeJPesw6unzJHOjHuogjrsZnbRDpfTVSWbR0Jur EoPmFYU+BfudThPnpPp+dNHDYVgXN/qEscWhl+c7SkN4qqq2tnAs5WnTIB/dETvS kvZDqwmvbM/0jMg9boLrOwjpSUlHx0a0LW5Pj8vhzBdbm7JJkrQEj9bmI3q7d9Tz htq7hjmRBbuDGZYQ5ySGOZHNOmiQHNExQbzBFGoeKuQ9eybX27L5dHG1GG45ZVpo ak17FS4F8JfRTZN/ag0TCKJzRNSry2JT6nN9c8ycs2hbNpkdcOql07WpuKGoRQmS cHv5PeHbdHElVi78Jq1tsw==; Received: from mail-out.apple.com (honeycrisp.apple.com [17.151.62.51]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 13.81.31401.E22CA145; Thu, 18 Sep 2014 04:29:50 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay4.apple.com ([17.128.113.87]) by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTP id <0NC300607H95NSK0@local.mail-out.apple.com> for tls@ietf.org; Thu, 18 Sep 2014 04:29:50 -0700 (PDT) X-AuditID: 11973e16-f793b6d000007aa9-8f-541ac22e157b Received: from chive.apple.com (chive.apple.com [17.128.115.15]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay4.apple.com (Apple SCV relay) with SMTP id 19.65.03493.532CA145; Thu, 18 Sep 2014 04:29:57 -0700 (PDT) Received: from [17.153.50.154] by chive.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NC300EIPH9OZ030@chive.apple.com> for tls@ietf.org; Thu, 18 Sep 2014 04:29:49 -0700 (PDT) From: Michael Sweet In-reply-to: Date: Thu, 18 Sep 2014 07:29:49 -0400 Message-id: <58A06E37-B0FB-4D53-87AD-288CF2278B42@apple.com> References: <20140912200607.GE16660@localhost> <20140918011622.CB9391AE4C@ld9781.wdf.sap.corp> To: Watson Ladd X-Mailer: Apple Mail (2.1878.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUiON3OWFfvkFSIwbbTvBafzncxOjB6LFny kymAMYrLJiU1J7MstUjfLoEro+uUR8F7mYolLwobGJeJdzFyckgImEicmHaADcIWk7hwbz2Q zcUhJDCHSeJVyxdWkASvgKDEj8n3WLoYOTiYBeQlDp6XBQkzC2hJfH/UygJiCwlMZpI4O0MX Zub+/1eg5nQzSWzYu4MFwvnAKHH8RjvYUGGBHImXd/+wg9hsAmoSvyf1gcU5BYIltt1fDhZn EVCVaHm8mhliW65E78d/bBAH2Ugs+bQBauhyRomrO6aCJUQE1CUmLN/EAnGGvMSHD8fZQYok BF6zSuxZ08w2gVFkFpKPZiF8NAvJRwsYmVcxCuUmZuboZuaZ6yUWFOSk6iXn525ihAS32A7G h6usDjEKcDAq8fBKCEiFCLEmlhVX5h5ilOZgURLnnc0AFBJITyxJzU5NLUgtii8qzUktPsTI xMEp1cC4TTEguPPYqoKvP6xKBJ279s1/xrffg3kny27bic96FYQi+VXYj9TnPV7UNCHde6eO uvk5403qjYmOx25+OvKdU7LrkKVF6mSl8OrtYdbcV+77dk936dg4s0c43OalhuC55L3Pij3f XTvdciEg8kig4ELdQ8wJV3p28nqFxd544nf6XKeTdpESS3FGoqEWc1FxIgCK0g3ITwIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOLMWRmVeSWpSXmKPExsUi2FDMr2t6SCrE4GefgMWn812MDoweS5b8 ZApgjOKySUnNySxLLdK3S+DKWNnyj7Fgi2zF1dc/2RoYH4h3MXJySAiYSOz/f4UNwhaTuHBv PZDNxSEk0M0k8bR/AROE84FR4viNdlaQKmGBHImXd/+wg9i8AgYSr34+ZgaxmQW0JNbvPM4E YrMJqEn8ntQHVs8pECyx7f5ysHoWAVWJlseroepzJXo//mODsLUlnry7wAox00ZiyacNLBCL lzNKXN0xFaxIREBdYsLyTSwQp8pLfPhwnH0Co8AsJHfMQnLHLCRzFzAyr2IUKErNSaw00Uss KMhJ1UvOz93ECA6+wvAdjP+WWR1iFOBgVOLhPcArFSLEmlhWXJl7iFGCg1lJhPfXQqAQb0pi ZVVqUX58UWlOavEhRmkOFiVx3vdlQCmB9MSS1OzU1ILUIpgsEwenVANj7seGW3dvXVdnK7xk 66TJq+GyQPCW8OMdKVPzFDUDTkzfcJLZlN8sJOeA+9Kf59pTk3vaW3mOcFq0Ci67ln/r2mWb 19dy3tx0cwnyY/CJqbY9tVbrXChjTZrX2xWbl2Q73L/Uzum9i0ehqoVr+72+VbK8V1/tOfip cY4U48d29ocz7ws+Y/RRYinOSDTUYi4qTgQAXyJs2zoCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/pbfyCJtCOuisj8CXKQOt7dYTalg Cc: Markulf Kohlweiss , "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 18 Sep 2014 11:29:52 -0000 My $0.02: Would it make sense to stop treating extensions as an a la carte mechanism, and instead define "extension suites", much as TLS already groups specific combinations of cryptographic primitives that can be selected in cipher suites? Seems like that would limit the allowed combinations of extensions to those that have gone through the necessary analysis and are considered "safe" to use together? On Sep 17, 2014, at 10:03 PM, Watson Ladd wrote: > On Wed, Sep 17, 2014 at 6:16 PM, Martin Rex wrote: >> Nico Williams wrote: >>> On Thu, Sep 11, 2014 at 05:18:37PM +0200, Martin Rex wrote: >>>> I also don't understand why the fact that TLS finished messages are >>>> encrypted would make any proof harder. I believe that to be untrue. >>> >>> Hugo K.'s rationale is that you then need to have replay protection. We >>> need replay protection anyways, but if you're only analyzing the >>> handshake then it helps to not have to include subsequent replay >>> protection in the analysis. >> >> Somehow that argument feels quite lame when it is combined with the >> argument "the proof would be easier when the finished messages were >> sent in the clear, could we not change this". >> >> Just do the proof under the assumption/premise that the finished messages >> *ARE* in the clear. Then send them encrypted. Unless you're doing avoidable >> weird things, sending them encrypted rather then in the clear should not >> affect the original proof at all. > > Yes, that's what previous analysis had to do. In combination with > other misfeatures (need for Oracle DH assumptions, additional > complexity) the result was that protocol weaknesses went undetected. > > The bigger the difference between TLS and the protocol that is > actually analyzed, the weaker the guaranties are about the safety of > TLS. Furthermore the space of changes people make to TLS is much > larger than is actually realized: take all the RFCs referring to any > version of TLS, and consider that each one may or may not be > implemented. The resulting combinatorial explosion cannot be dealt > with except by modularizing the proof. > > TLS 1.3 adds new tricks, like Zero-RTT, one-RTT forms, and possibly > new forms of encrypted data. The easier it is to analyze the core > protocol the easier it will be to analyze these proposals, and fix > them. Most of the people who are making proposals including myself > have not got the ability or time to do a proper analysis. The few > people who do are really overworked, and so far we've heard nothing > from them (for good reason: you don't want a late change to turn a > significant amount of work into a nonstarter) It is a substantially > more complicated protocol. > > We need to think about how to avoid the past two decades of major > cryptographic weaknesses, repeatedly identified in TLS > implementations, some of which are still not fixed. > > Sincerely, > Watson Ladd >> >> If the TLS channel would be sensitive to what exact data is transferred >> within that encrypted channel, then you would have *MUCH* larger problems >> and it would apply to just about any kind of arbitrary application data. >> >> -Martin > > > > -- > "Those who would give up Essential Liberty to purchase a little > Temporary Safety deserve neither Liberty nor Safety." > -- Benjamin Franklin > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair From nobody Thu Sep 18 04:52:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95B5C1A0939 for ; Tue, 16 Sep 2014 15:26:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BVW18ryv0q4V for ; Tue, 16 Sep 2014 15:26:22 -0700 (PDT) Received: from mail-qa0-x22a.google.com (mail-qa0-x22a.google.com [IPv6:2607:f8b0:400d:c00::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FFDB1A03BE for ; Tue, 16 Sep 2014 15:26:22 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id j7so727374qaq.15 for ; Tue, 16 Sep 2014 15:26:21 -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=UIKu8aFn0BAY18KjwnKkcCvdVk6Xyq+RC34GwG+nnK0=; b=FO1WdKWogSjX86If9Wv1Sq55lR22IKyP5SDPp8m5k128nIAvuYsb4JVysZvYmVUCy7 0flDYoIsqj/lNqWyNhoAy+Wfg7BiwYtBYIsCCxxH/4THDKDa2VTxUUNOOUIhqweMJMkB +3T5NJezDz8lZPCMAeLSGLCwKRPaZg6WiW4m1gnpC4lP/FAEuaSGNCicSm98N+tD4UAO IGcjL3LqFtJJE9CVhFEpg7TPpPJlsQVwSrZeE9Pp9wnod9y6nPFqwi0RY6o27xYOMxhp pyIggBSTD3NkED+TEPbPNDSWBV9fNXuBKEX2q2yI7w5iULw/EFmmAiGXtrst1zMuZc8k oGqQ== MIME-Version: 1.0 X-Received: by 10.140.21.85 with SMTP id 79mr43280399qgk.69.1410906381816; Tue, 16 Sep 2014 15:26:21 -0700 (PDT) Received: by 10.140.156.20 with HTTP; Tue, 16 Sep 2014 15:26:21 -0700 (PDT) In-Reply-To: References: Date: Wed, 17 Sep 2014 00:26:21 +0200 Message-ID: From: =?UTF-8?B?Qm9kbyBNw7ZsbGVy?= To: Ryan Carboni Content-Type: multipart/alternative; boundary=001a11c14d50b318d10503363de0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8wND_1dcHQfE4kpRwCqAXIdEE_E X-Mailman-Approved-At: Thu, 18 Sep 2014 04:52:12 -0700 Cc: "tls@ietf.org" Subject: Re: [TLS] RFC 7366 on Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 16 Sep 2014 22:26:23 -0000 --001a11c14d50b318d10503363de0 Content-Type: text/plain; charset=UTF-8 Ryan Carboni : > If you're upgrading specifications, why not switch to SHA-3, which is > constant time (AFAIK)? > Part of the problem is that in TLS MAC-then-Encrypt, the position of the MAC tag depends on the amount of padding -- so *nothing* is constant-time without considerable effort. (It's funny that one of the references provided in the new RFC shows how MAC-then-Encrypt in TLS is supposedly secure, when the RFC came to be because actually it isn't.) Bodo --001a11c14d50b318d10503363de0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Ryan= Carboni <ryacko@gmail.com>:
=C2=A0
If you're upgrading specific= ations, why not switch to SHA-3, which is constant time (AFAIK)?
<= /div>

Part of the problem is that in TLS MA= C-then-Encrypt, the position of the MAC tag depends on the amount of paddin= g -- so *nothing* is constant-time without considerable effort.
<= br>
(It's funny that one of the references provided in the ne= w RFC shows how MAC-then-Encrypt in TLS is supposedly secure, when the RFC = came to be because actually it isn't.)

Bodo

--001a11c14d50b318d10503363de0-- From nobody Thu Sep 18 06:19:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEAE11A00F5 for ; Thu, 18 Sep 2014 06:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.977 X-Spam-Level: X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e66FGqg-UQeI for ; Thu, 18 Sep 2014 06:19:04 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04C2B1A8799 for ; Thu, 18 Sep 2014 06:19:02 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id s18so1132839lam.28 for ; Thu, 18 Sep 2014 06:19:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=QDeV9Z6DNuiLYyDB/r8FURPEA/SK63LhopKRHm8ZphA=; b=YRz2LMgIld+CGZrCwQX2cA6sl4WfBJVksm7oKdztUYO4SsX9l4B1ygv9kZrooBa0f3 bg+x2p5SUk9krDxXlEuiiRm2ryeJ6ZoyMfqnHPmIRHL8CKeEqgvSYZb37kQ0nJdb1R76 oKKiVZHtuJQO5xp6mfYl8cdTrRoCjpk2fty73Cfrr4xKcIK0B/1T+iRDNmRq254iibrp G8xz7H4ayv1EwRQ1lv7Rrp7tUjLOCZpA6uRQTyb+5DkVUyjGDgR1DdK2Q8fLhvQy6iDe zXhdF2PIY1Uq8zy0crmfnYIoLpREvqWglswilytRzkFreaNtGX1p2tODWVHoXvyNRiSu /wDg== X-Received: by 10.112.53.230 with SMTP id e6mr3252046lbp.100.1411046341317; Thu, 18 Sep 2014 06:19:01 -0700 (PDT) MIME-Version: 1.0 Sender: hugokraw@gmail.com Received: by 10.25.16.135 with HTTP; Thu, 18 Sep 2014 06:18:31 -0700 (PDT) In-Reply-To: References: From: Hugo Krawczyk Date: Thu, 18 Sep 2014 09:18:31 -0400 X-Google-Sender-Auth: 1gDmX0EqBGNjuN___26iELbnA5k Message-ID: To: =?UTF-8?B?Qm9kbyBNw7ZsbGVy?= Content-Type: multipart/alternative; boundary=001a11c3c96cef9bc3050356d3fd Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yClfb0g-YrYQTAYaSxABKQZJx48 Cc: "tls@ietf.org" , Ryan Carboni Subject: Re: [TLS] RFC 7366 on Encrypt-then-MAC for Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 18 Sep 2014 13:19:05 -0000 --001a11c3c96cef9bc3050356d3fd Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable What that reference shows is that for authenticate-then-encrypt mode to be secure with cbc and otp encryption (or stream cipher), you must apply the MAC to the plaintext after any encoding (including padding) and, in the case of cbc, in full blocks (and, of course, with unpredictable IVs). Unfortunately, TLS did not do it this way for cbc and that's why all these attacks were possible. The example in the paper, while artificial, explains well why authenticate-then-encrypt with unauthenticated encoding can go wrong. So the math in the paper is correct - the conclusion that TLS does it right is wrong. It doesn't. Hugo On Tue, Sep 16, 2014 at 6:26 PM, Bodo M=C3=B6ller w= rote: > Ryan Carboni : > > >> If you're upgrading specifications, why not switch to SHA-3, which is >> constant time (AFAIK)? >> > > Part of the problem is that in TLS MAC-then-Encrypt, the position of the > MAC tag depends on the amount of padding -- so *nothing* is constant-time > without considerable effort. > > (It's funny that one of the references provided in the new RFC shows how > MAC-then-Encrypt in TLS is supposedly secure, when the RFC came to be > because actually it isn't.) > > Bodo > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > > --001a11c3c96cef9bc3050356d3fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
What that reference shows is that for authentic= ate-then-encrypt mode to be secure with cbc and otp encryption (or stream c= ipher), you must apply the MAC to the plaintext after any encoding (includi= ng padding) and, in the case of cbc, in full blocks (and, of course, with u= npredictable IVs). Unfortunately, TLS did not do it this way for cbc and th= at's why all these attacks were possible. The example in the paper, whi= le artificial, explains well why authenticate-then-encrypt with unauthentic= ated encoding can go wrong. So the math in the paper is correct - the concl= usion that TLS does it right is wrong. It doesn't.

Hugo

On Tue, Sep 16, 2014 at 6:26 PM, Bodo M=C3=B6ller = <bodomoeller@= gmail.com> wrote:
Ryan Carboni= <ryacko@gmail.com>:
=C2=A0
If you're upgrading s= pecifications, why not switch to SHA-3, which is constant time (AFAIK)?
=

Part of the problem is = that in TLS MAC-then-Encrypt, the position of the MAC tag depends on the am= ount of padding -- so *nothing* is constant-time without considerable effor= t.

(It's funny that one of the references prov= ided in the new RFC shows how MAC-then-Encrypt in TLS is supposedly secure,= when the RFC came to be because actually it isn't.)

Bodo

=

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


--001a11c3c96cef9bc3050356d3fd-- From nobody Thu Sep 18 07:24:32 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF9DB1A0379 for ; Thu, 18 Sep 2014 07:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.554 X-Spam-Level: X-Spam-Status: No, score=-8.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cxYyRo5-cild for ; Thu, 18 Sep 2014 07:24:29 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C77F1A01CA for ; Thu, 18 Sep 2014 07:24:29 -0700 (PDT) Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8IEORd8013620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 18 Sep 2014 10:24:27 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8IEOPL8023224 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 18 Sep 2014 10:24:26 -0400 Message-ID: <1411050264.18523.35.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Michael Sweet Date: Thu, 18 Sep 2014 16:24:24 +0200 In-Reply-To: <58A06E37-B0FB-4D53-87AD-288CF2278B42@apple.com> References: <20140912200607.GE16660@localhost> <20140918011622.CB9391AE4C@ld9781.wdf.sap.corp> <58A06E37-B0FB-4D53-87AD-288CF2278B42@apple.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/f3p5O46SPEztohKHNzUh6VgYzwE Cc: "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 18 Sep 2014 14:24:30 -0000 On Thu, 2014-09-18 at 07:29 -0400, Michael Sweet wrote: > My $0.02: Would it make sense to stop treating extensions as an a la > carte mechanism, and instead define "extension suites", much as TLS > already groups specific combinations of cryptographic primitives that > can be selected in cipher suites? Well, I think we need more than your 2 cents for that. Could you elaborate what you mean here? The extensions were put in place to overcome the limitation of the ciphersuites that you just mentioned. > Seems like that would limit the allowed combinations of extensions to > those that have gone through the necessary analysis and are considered > "safe" to use together? Isn't that the set of all extensions that are published by this working group? regards, Nikos From nobody Thu Sep 18 07:39:14 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD9B61A040E; Thu, 18 Sep 2014 07:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.553 X-Spam-Level: X-Spam-Status: No, score=-8.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PEzLtK5CE5Gg; Thu, 18 Sep 2014 07:39:10 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BDB71A882A; Thu, 18 Sep 2014 07:39:09 -0700 (PDT) Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8IEd2Tr014515 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 18 Sep 2014 10:39:03 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8IEcwkL018624 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 18 Sep 2014 10:39:00 -0400 Message-ID: <1411051138.18523.42.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: Phillip Hallam-Baker Date: Thu, 18 Sep 2014 16:38:58 +0200 In-Reply-To: References: <1409931283.1731.16.camel@dhcp-2-127.brq.redhat.com> <1411032333.18523.18.camel@dhcp-2-127.brq.redhat.com> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/a6UYrEObXy0W3OcTGA7Y2C2K9Q4 Cc: "pkix@ietf.org" , "tls@ietf.org" Subject: Re: [TLS] New version of the TLS feature draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 18 Sep 2014 14:39:12 -0000 On Thu, 2014-09-18 at 07:57 -0400, Phillip Hallam-Baker wrote: > >> Section 3.1.1 specifies "a server MUST return a valid OCSP token". I > >> would consider an expired ocsp staple to not actually be valid. I > >> would refer to it as expired, with the implication that the signature > >> is correct, because if it wasn't a person probably would have said > >> that in addition to describing it as expired. > > > > That's pretty sketchy. OCSP responses have a recommended validity > > interval, this is not the same as X.509 certificate expiration. I'm not > > sure what popular browsers do with responses received by the server that > > are outside the validity period, but I would be very surprised if they > > dropped the connection. If in this document it is assumed that responses > > not within the recommended interval should cause a TLS connection > > failure, it should be explicit. > Given that we currently have a situation where the vast majority of > Web browsers are not PKIX compliant and ignore revocation information > completely and Web browsers are only one PKIX application, I don't > think it is appropriate to use a MUST here to direct how invalid > status is handled. Maybe not, but it makes sense to define what is valid and invalid. The problem statement of this draft as you set it is to close a door on a "downgrade" attack where no OCSP response is sent. However, if you don't define what is a secure connection to a server that supports OCSP status request, how can you claim to fix an attack? regards, Nikos From nobody Thu Sep 18 07:52:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2247C1A8821 for ; Thu, 18 Sep 2014 07:52:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.953 X-Spam-Level: X-Spam-Status: No, score=-5.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qH6ssbmgQfd for ; Thu, 18 Sep 2014 07:52:35 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B6921A87F1 for ; Thu, 18 Sep 2014 07:52:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1411051954; x=2274965554; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-transfer-encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=nu7zb1EI/nlzg2zOvrsvDKGtrdX44w8ho0UCVtLcwgg=; b=XhoLENpHeAtEQPvk5m1EheEKEkLAQCCmP8meqQVtmZFyrCLzQjjFc/V0asHnrTVp B9I58YHPiJzdeBEk1NdTsM/luOlFPDf3hqXTRY0LBpEBXqqq37kfBuXVKcU08Pgy 9tmnES8MJQvNlGovO5I9AejArZ+kcrSGMdssNx1laGHqynBAxh4d69jWsWTrzGy+ BLTHn+MGJUnfToEJwEC6dzE1JfuNbZiWBBwFOpqxGw7c5n55GcALF8qzjHd0WQlm 0+q3Eer40kvn9PLldnH61xcs+nUVzBCM5ySvmr+3SVCKhQd9u2BwhmiDaiEx5QjF UUFHTnmAFvbCKUwBEYp7bg==; Received: from mail-out.apple.com (mail-out.apple.com [17.151.62.50]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 2D.F3.31401.2B1FA145; Thu, 18 Sep 2014 07:52:34 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; CHARSET=US-ASCII Received: from relay6.apple.com ([17.128.113.90]) by local.mail-out.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTP id <0NC3005ECQNMAPA0@local.mail-out.apple.com> for tls@ietf.org; Thu, 18 Sep 2014 07:52:34 -0700 (PDT) X-AuditID: 11973e16-f793b6d000007aa9-c0-541af1b2de7b Received: from chive.apple.com (chive.apple.com [17.128.115.15]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 4E.1B.30921.2A1FA145; Thu, 18 Sep 2014 07:52:18 -0700 (PDT) Received: from [17.153.50.154] by chive.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NC300E8TQNKZ080@chive.apple.com> for tls@ietf.org; Thu, 18 Sep 2014 07:52:34 -0700 (PDT) From: Michael Sweet In-reply-to: <1411050264.18523.35.camel@dhcp-2-127.brq.redhat.com> Date: Thu, 18 Sep 2014 10:52:32 -0400 Message-id: References: <20140912200607.GE16660@localhost> <20140918011622.CB9391AE4C@ld9781.wdf.sap.corp> <58A06E37-B0FB-4D53-87AD-288CF2278B42@apple.com> <1411050264.18523.35.camel@dhcp-2-127.brq.redhat.com> To: Nikos Mavrogiannopoulos X-Mailer: Apple Mail (2.1878.6) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUiON3OSHfTR6kQgyf/9C0+ne9idGD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxu4tJxkLngpUvF+1nq2B8QRvFyMnh4SAicSaFTeYIWwxiQv3 1rN1MXJxCAnMYpL4vL6DESTBKyAo8WPyPZYuRg4OZgF5iYPnZUHCzAJaEt8ftbKA2EICk5kk lk4zh5n5tvUd1JxuJomLk5ZAOR8YJZbeWsoEUiUskCPx8u4fdhCbTUBN4vekPlYQm1PASWJt 60ywZSwCqhJ/71hBLFOUOLBzFjPEPTYSszu6mSFmTmKSOPN9BRtIQkRAV+JS81N2iCvkJT58 OM4OUiQh8J5V4t7enSwTGEVmIXloFsJDs5A8tICReRWjUG5iZo5uZp65XmJBQU6qXnJ+7iZG SHiL7WB8uMrqEKMAB6MSD6+EgFSIEGtiWXFl7iFGaQ4WJXHe2QxAIYH0xJLU7NTUgtSi+KLS nNTiQ4xMHJxSDYwKb46969yUW/z69d4JWrZFaSsuSc7ImylyyGjfrGdhH6a5Hev6vjq6fF7q 5NNnAtjbdH1afU60Oe+c/onZxParll3FFqPQo0lLOLYLOHY/cUre/eHekvtRRha37ym2+8zi 19TUVcvdO9FOM3vDpR7bd08Wtr+vKz0xY8qdP6sm1xauYfW+9bJNiaU4I9FQi7moOBEAVatv GFACAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUi2FDMr7voo1SIQds3botP57sYHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVcX/dCcaCJYIVJ2ctYWpgfM3bxcjJISFgIvG29R0bhC0mceHe eiCbi0NIoJtJ4vji+6wQzgdGiaW3ljKBVAkL5Ei8vPuHHcTmFTCQePXzMTOIzSygJbF+53Gw GjYBNYnfk/pYQWxOASeJta0zWboYOThYBFQl/t6xgihXlDiwcxZUq7bEk3cXWCFG2kjM7uhm htg7iUnizPcVYNeJCOhKXGp+yg5xqbzEhw/H2ScwCsxCcsYsJGfMQjJ3ASPzKkaBotScxEoz vcSCgpxUveT83E2M4NArjNrB2LDc6hCjAAejEg+vhIBUiBBrYllxZe4hRgkOZiURXo+3QCHe lMTKqtSi/Pii0pzU4kOM0hwsSuK8e+4DpQTSE0tSs1NTC1KLYLJMHJxSDYyC5133ctqfadJ9 uiJg3RHOjbHnrPOjdwcv4k/te3Vy45vyW55yM+2cMpe6suyctS3lDKuQx4ZZWz5s2FDofmsh S9Lzg6FTe+qDVtX58Rm0/rS8OtF8rmZd21m/k9Y/rSY/UxdyfWRwT05Jd0rNS888tn+1sXd0 ziw0TfVwMLCtLSr+cDe19aMSS3FGoqEWc1FxIgBj56iqOQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7E0z546nty2ELazCr2qjedmL6Xc Cc: "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 18 Sep 2014 14:52:37 -0000 Nikos, The claim was made that TLS + some combination of extensions will produce a non-secure result. I.e., TLS + Extension Foo is secure, TLS + Extension Bar is secure, but TLS + Foo + Bar is not secure (or cannot be proven to be secure). Thus, my comment was just a question: if we can't ensure that all combinations of TLS extensions are secure, does it make sense to negotiate sets of extensions instead of the individual extensions? Obviously a single extension should be secure on its own (otherwise, why is it being approved for use in TLS?), but if a combination of extensions can cause interactions that are not secure then it would make sense to have a way to lock those combinations out (blacklist) or negotiate known good combinations (whitelist). And having worked with enough security people over the years, I know what the usual preference is for such things (whitelists)... (I am not a TLS or security expert, just somebody that uses TLS and knows that I don't know everything about it, so I ask questions even if the answers are obvious to those that can claim to be experts...) On Sep 18, 2014, at 10:24 AM, Nikos Mavrogiannopoulos wrote: > On Thu, 2014-09-18 at 07:29 -0400, Michael Sweet wrote: >> My $0.02: Would it make sense to stop treating extensions as an a la >> carte mechanism, and instead define "extension suites", much as TLS >> already groups specific combinations of cryptographic primitives that >> can be selected in cipher suites? > > Well, I think we need more than your 2 cents for that. Could you > elaborate what you mean here? The extensions were put in place to > overcome the limitation of the ciphersuites that you just mentioned. > >> Seems like that would limit the allowed combinations of extensions to >> those that have gone through the necessary analysis and are considered >> "safe" to use together? > > Isn't that the set of all extensions that are published by this working > group? > > regards, > Nikos > > _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair From nobody Thu Sep 18 08:41:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 960151A885F for ; Thu, 18 Sep 2014 08:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fM2seeg5_Bx2 for ; Thu, 18 Sep 2014 08:40:56 -0700 (PDT) Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A84831A885C for ; Thu, 18 Sep 2014 08:40:55 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id AABDE9001D; Thu, 18 Sep 2014 18:40:52 +0300 (EEST) Date: Thu, 18 Sep 2014 18:40:52 +0300 From: Ilari Liusvaara To: Michael Sweet Message-ID: <20140918154052.GA24231@LK-Perkele-VII> References: <20140912200607.GE16660@localhost> <20140918011622.CB9391AE4C@ld9781.wdf.sap.corp> <58A06E37-B0FB-4D53-87AD-288CF2278B42@apple.com> <1411050264.18523.35.camel@dhcp-2-127.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nAd_igun_f_Qx_zVX0PBDeh03dA Cc: "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 18 Sep 2014 15:40:58 -0000 On Thu, Sep 18, 2014 at 10:52:32AM -0400, Michael Sweet wrote: > Nikos, > > The claim was made that TLS + some combination of extensions will > produce a non-secure result. I.e., TLS + Extension Foo is secure, > TLS + Extension Bar is secure, but TLS + Foo + Bar is not secure > (or cannot be proven to be secure). There are also extensions that individually screw security (and to some degree, such extension already exists). And one would think that if some combination of extensions screws up security, at least one of those would do odd things (the result may still be "provably secure"). The places in TLS 1.3 that are especially critical are keying/ encryption (including early handshake) and authentication (including TLS-UNIQUE and TLS-EXTRACTOR). -Ilari From nobody Thu Sep 18 11:52:39 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B985A1A03B5 for ; Thu, 18 Sep 2014 11:52:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rz5k_wuHFCA4 for ; Thu, 18 Sep 2014 11:52:24 -0700 (PDT) Received: from emh04.mail.saunalahti.fi (emh04.mail.saunalahti.fi [62.142.5.110]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 461F01A0491 for ; Thu, 18 Sep 2014 11:52:24 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh04.mail.saunalahti.fi (Postfix) with ESMTP id 390611A25CB; Thu, 18 Sep 2014 21:52:20 +0300 (EEST) Date: Thu, 18 Sep 2014 21:52:20 +0300 From: Ilari Liusvaara To: Watson Ladd Message-ID: <20140918185220.GA26270@LK-Perkele-VII> References: <20140912200607.GE16660@localhost> <20140918011622.CB9391AE4C@ld9781.wdf.sap.corp> <20140918034042.GA4273@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dmW2oURbJYwkA-4kKljB2CV7Hzs Cc: Markulf Kohlweiss , "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 18 Sep 2014 18:52:30 -0000 On Wed, Sep 17, 2014 at 09:29:27PM -0700, Watson Ladd wrote: > > Rather the problem is that some applications like RFCs I've cited, > that are deployed, use the TLS handshake to derive a key > that is used for another purpose. This is not safe without analysing > the specifics of the encryption scheme used. Is there some application protocol that uses important TLS system subkeys for its own purposes? I would rather see such just break. Such apps are horrible layering violation for no apparent purpose for one. And I really hope I don't run into TLS libraries supporting such blatant misuse. And wonder how the heck such thing got past review. I'm aware of SRTP that gets its keying material from TLS (it is exactly that RFC5764). It does not use any TLS system subkeys for itself, but it dervies dedicated subkeys. So it is OK. And if security of that depends on specifics of some encryption scheme, you got problems... SERIOUS problems. > In particular, an application that has its own record layer may > interpret the Finished message in strange ways. This can cause > problems. If any app does that, it would seem like it would already be broken in TLS 1.3 (since the key exchange looks nothing like it did in TLS 1.2). Or are you saying some application replaces major parts of TLS? SRTP-style mux just uses unused TLS record types to denote non-TLS data, and passes all TLS data to TLS stack without trying to interpret it (it can't even interpret anything encrypted, since it lacks keys to do that). > There are other unpatched issues, like the possibility to misinterpret > the Server Key Exchange field and use this to impersonate a server, > that need addressing. I thought that draft TLS 1.3 + master secret fix would already fix the SKE issue? Are you talking about fixing it in TLS 1.0-1.2? -Ilari From nobody Thu Sep 18 20:29:54 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8111A6FF7 for ; Thu, 18 Sep 2014 20:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypvXcgGSURoN for ; Thu, 18 Sep 2014 20:29:51 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F6921A6FE5 for ; Thu, 18 Sep 2014 20:29:51 -0700 (PDT) Received: by mail-yk0-f182.google.com with SMTP id 131so499725ykp.41 for ; Thu, 18 Sep 2014 20:29:50 -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=+jMWQYf51WFm3mD+l+o6jv2HVpFP7vM6AnJYhGq8OVc=; b=ioilTZPn45So/L/Ks62hkehtwRTCRyuxyd3DkYqa4yYAcBXEvBkL4bKjc5ei2U6yFt 7Gh9xrsqEK0q6zVG6aem3N/nrl2LYBGO2LvrWp3y/nyPwL74drnk5SaCi8j8aXwUZbxS 6JcTv7VC0lhe/CSP8uXEyxzj3qI2/tw85MsDukOPy3KswPVtXmcV0knzJR9OX9mzd+kG Si/5g1sNQbu+fGNYScG6/+AZoXxyW77UYsr7rlI54nrrUfh29cNGBKyp0EggrRoRO/qq 0eIwShSNLi3j6LfMBW8TnVUlh6oP5EzS7PeAFVa5EgmlWGLv2PLiHqlcxBBg3jKq9pPf T0YQ== MIME-Version: 1.0 X-Received: by 10.236.45.65 with SMTP id o41mr8389704yhb.118.1411097390261; Thu, 18 Sep 2014 20:29:50 -0700 (PDT) Received: by 10.170.207.216 with HTTP; Thu, 18 Sep 2014 20:29:50 -0700 (PDT) In-Reply-To: <20140918185220.GA26270@LK-Perkele-VII> References: <20140912200607.GE16660@localhost> <20140918011622.CB9391AE4C@ld9781.wdf.sap.corp> <20140918034042.GA4273@localhost> <20140918185220.GA26270@LK-Perkele-VII> Date: Thu, 18 Sep 2014 20:29:50 -0700 Message-ID: From: Watson Ladd To: Ilari Liusvaara Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/C1plOuYeRUu30DoUqgi6baJiQa0 Cc: Markulf Kohlweiss , "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 19 Sep 2014 03:29:53 -0000 On Thu, Sep 18, 2014 at 11:52 AM, Ilari Liusvaara wrote: > On Wed, Sep 17, 2014 at 09:29:27PM -0700, Watson Ladd wrote: >> >> Rather the problem is that some applications like RFCs I've cited, >> that are deployed, use the TLS handshake to derive a key >> that is used for another purpose. This is not safe without analysing >> the specifics of the encryption scheme used. > > Is there some application protocol that uses important TLS system > subkeys for its own purposes? I would rather see such just break. > > Such apps are horrible layering violation for no apparent purpose > for one. And I really hope I don't run into TLS libraries supporting > such blatant misuse. And wonder how the heck such thing got past > review. > > I'm aware of SRTP that gets its keying material from TLS (it is exactly > that RFC5764). It does not use any TLS system subkeys for itself, > but it dervies dedicated subkeys. So it is OK. Yes, it is OK. But I'm not sure if the extractor is defined in the core TLS spec, or was covered by the miTLS proof, or was not. As a practical matter the nonstandard assumptions of TLS are much more worrying: however, SRTP shows that people do use TLS as a key agreement mechanism, not simply as a secure channel abstraction. Even as a key agreement mechanism TLS falls to a UKS issue. TLS 1.3 will fix some of these problems: maybe not all. > > >> There are other unpatched issues, like the possibility to misinterpret >> the Server Key Exchange field and use this to impersonate a server, >> that need addressing. > > I thought that draft TLS 1.3 + master secret fix would already fix the > SKE issue? Are you talking about fixing it in TLS 1.0-1.2? Yes, in TLS 1.0-1.2. The TLS 1.3 draft changes the way the server certificate is used to fix this issue, and I think it also fixes some of the strong assumption issues, but have not looked hard enough to figure that out. There doesn't seem to be draft solving this problem, unlike the other known weaknesses. Anyone care to comment? We would need an extension that changes the format of the Server Key Exchange. Sincerely, Watson Ladd > > > -Ilari -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Sep 18 22:40:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CCE1A8735 for ; Thu, 18 Sep 2014 22:40:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.301 X-Spam-Level: X-Spam-Status: No, score=-1.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_36=0.6, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CVcUESzPtsHd for ; Thu, 18 Sep 2014 22:40:02 -0700 (PDT) Received: from emh01.mail.saunalahti.fi (emh01.mail.saunalahti.fi [62.142.5.107]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44FE71A0475 for ; Thu, 18 Sep 2014 22:40:02 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh01.mail.saunalahti.fi (Postfix) with ESMTP id E5609900F1; Fri, 19 Sep 2014 08:39:59 +0300 (EEST) Date: Fri, 19 Sep 2014 08:39:59 +0300 From: Ilari Liusvaara To: Watson Ladd Message-ID: <20140919053959.GA29383@LK-Perkele-VII> References: <20140912200607.GE16660@localhost> <20140918011622.CB9391AE4C@ld9781.wdf.sap.corp> <20140918034042.GA4273@localhost> <20140918185220.GA26270@LK-Perkele-VII> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/tls/RG170nh_e3LkC30VaJbswVeSIQc Cc: Markulf Kohlweiss , "tls@ietf.org" Subject: Re: [TLS] cryptanalysis vs. encrypted parts of the TLS handshake [was: Re: Simplifying the proof] X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 19 Sep 2014 05:40:04 -0000 On Thu, Sep 18, 2014 at 08:29:50PM -0700, Watson Ladd wrote: > > Yes, it is OK. But I'm not sure if the extractor is defined in the > core TLS spec, or was covered by the miTLS proof, or was not. As a > practical matter the nonstandard assumptions of TLS are much more > worrying: however, SRTP shows that people do use TLS as a key > agreement mechanism, not simply as a secure channel abstraction. It is not in core TLS spec, it was published after TLS 1.2, nor has it been incorporated into 1.3. Basically, it just invokes the PRF. It does have some (possibly minor) issues: - It can extract important TLS system subkeys[1]. - The underlying PRF does not cleanly separate the label and seed (so one can trivially find collisions)[2]. Also, the extractor is used to authenticate connections by signing output. That needs to work even in face of total failure (universal forgery) of server signature. [1] Application using those for its own purposes can really create a mess security-wise (using the same key for two different algorithms, or even the same algorithm without coordinating nonces can really create problems). [2] E.g. PRF(secret, "foo", "barbaz") and PRF(secret, "foobar", "baz") and PRF(secret, "foobarbaz") of the same length all collide. -Ilari From nobody Fri Sep 19 12:52:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C87A1A068A for ; Fri, 19 Sep 2014 12:52:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LihRJF-m2-Hf for ; Fri, 19 Sep 2014 12:52:51 -0700 (PDT) Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id 94FB11A070A for ; Fri, 19 Sep 2014 12:52:50 -0700 (PDT) Received: from fifthhorseman.net (unknown [38.109.115.130]) by che.mayfirst.org (Postfix) with ESMTPSA id F0328F984 for ; Fri, 19 Sep 2014 15:52:47 -0400 (EDT) Received: by fifthhorseman.net (Postfix, from userid 1000) id 8C3E12000E; Fri, 19 Sep 2014 12:52:35 -0700 (PDT) From: Daniel Kahn Gillmor To: IETF TLS Working Group User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-pc-linux-gnu) Date: Fri, 19 Sep 2014 15:52:31 -0400 Message-ID: <87bnqbxu9s.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FrBNnLZMQJwbwsuOJmDsjU6n5cQ Subject: [TLS] Contemplated major revision to draft-ietf-negotiated-ff-dhe X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 19 Sep 2014 19:52:53 -0000 --=-=-= Content-Type: text/plain Hi TLS folks-- I'm considering a radical syntactic change to the negotiated-ff-dhe draft (though it changes the semantics very little if at all) for the purposes of aligning 1.3 handshake with pre-1.3 handshakes. Feedback about this idea would be appreciated. The idea is to have the draft drop the proposed FF-DHE TLS extension entirely and instead redefine "Supported Elliptic curves" (TLS extension 10) [0] to be a "Supported named groups" extension. Then we would allocate some of the currently unallocated codepoints in the NamedCurve IANA registry [1] to the proposed FF-DHE groups. == Advantages == The main goal of this change is to simplify the TLS 1.3 handshake while allowing clients to send a 1.2+1.3 compatible first flight that includes FF DHE without excessive duplication. TLS 1.2+1.3 handshakes will be able to reference a single registry for their preferred groups and handle them in parallel, without an extra extension. We also avoid introducing new TLS extensions. Clients would be able to send extension 10 without needing to have implemented EC. == Further Considerations == So, for a TLS 1.2 client that wants to support named FF-DHE groups, it would just send TLS extension 10 with only FF-DHE codepoints. It would include DHE ciphersuites, but need not include any ciphersuites with ECDHE key exchange. If a TLS 1.2 client wants to include ciphersuites with ECDHE as well, it can do so, but can also indicate FF-DHE codepoints in the same TLS extension that it indicates the available curves. Servers responding to such a client will fall into two categories: those aware of the FF-DHE entries in named-curves, and those that are not. for unaware servers, they should ignore these entries and carry on with a normal response. For aware servers, if they select a DHE key exchange they should send an SKE as indicated in the current draft, with the server's DHParams modified appropriately. (possibly, Alfredo's suggestion of sending an entirely different handshake message instead of SKE in this case offers a clearer indication to the client that the server has selected a named group). == Codepoint Requests == The NamedCurve registry is 16 bits, which is *huge* considering the pressure we've given to the CFRG to limit the number of proposed curves. This proposal suggests carving out a small space of that registry for finite field groups. For simplicity's sake, i imagine something like "if the high byte is 0x01, it's FF-DHE" (the draft currently only allocates 1 byte anyway). But i'd also be OK with just allocating some specific codepoints and not making any block designation, if folks think that would make more sense. == Feedback Please! == Please speak up if you find this change terrible for some reason, or if you've already implemented the proposed draft and think that backing it out would be misery. I don't think this proposal changes the semantics of the draft at all, and i think it would help the 1.3 handshake to have this established. If i hear no shouts of horror, i hope to get a revision of negotiated-ff-dhe published next week with these changes. I'm likely to need some help in navigating the IANA procedures for a change like this which isn't exactly a straightforward codepoint request, so if anyone has suggestions or experience with that, i'd appreciate pointers. All the best, --dkg [0] https://tools.ietf.org/html/rfc4492#section-5.1.1 [1] https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8 --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQJ8BAEBCgBmBQJUHImAXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFQjk2OTEyODdBN0FEREUzNzU3RDkxMUVB NTI0MDFCMTFCRkRGQTVDAAoJEKUkAbEb/fpcrWQP/3wvZeLoXUFJ5rl0LFIvrlQ2 fWP+g5el5FL++cufGF3kmhtqmyXH5TvSJOO4dQTWK625xA6Rz6WvZCKdzcS0SjKK nI3Y8zVK1YkoriGUFatw68SpHgLhAhkSQ1ll39PS8zowruaqmScOB6EBrQUZUIGz dYgvgUZxhmdx9DgJ5FDK6WIcprauK2+hSqBQ5efnfgX6XmYK2+Mov/UIII3iemum ngu+HhQhLkF8HUGvqDGkNCcNlfL8f2FIi+0dmUe0+O4y8EEuHaFxKuQkF+OuSc8d 2isyTMpML2TjLCdMhMn/DmVNX51taIvShIGMG2CqdHPvGvrfY1p5aJyr0dzRWmw0 9aypEHNPTwY3Fvul0f9CeN8L6hzwehCRY82h7+KL8cXMy+8+ho0ij4XwjLJOamvg J4S//1xusFjv0hqVS8/Yx9/EIUy+tFh8v+OgkGAu9tmdtJlZWQIegbgPIq6OFazU SHpdln2k5GK6C50CiJbrbPyt04NVMGv8iacSugCTNKxkRVP4MoYRQwHVheraMEpZ v3K0ydiTbNF4d1Kbg6QsmC5rDBmhRsFQlOI56jdG+cdxcaCCpeu9/xtL7hxNrZlb OeEFHnIu2o1lvIn7pFS8f0BMCtB10Utm7Mkha9mwFoWoDd+btZc+AwPYcorQUhD6 5Ndq6YcFG8BtbxXrHfQs =ommP -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Sep 19 14:10:07 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4771F1A8762 for ; Fri, 19 Sep 2014 14:10:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3wO8YgjOjUrC for ; Fri, 19 Sep 2014 14:10:04 -0700 (PDT) Received: from emh06.mail.saunalahti.fi (emh06.mail.saunalahti.fi [62.142.5.116]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03FA21A0ADE for ; Fri, 19 Sep 2014 14:10:02 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh06.mail.saunalahti.fi (Postfix) with ESMTP id 17AD669AC1; Sat, 20 Sep 2014 00:09:59 +0300 (EEST) Date: Sat, 20 Sep 2014 00:09:59 +0300 From: Ilari Liusvaara To: Daniel Kahn Gillmor Message-ID: <20140919210959.GA5533@LK-Perkele-VII> References: <87bnqbxu9s.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <87bnqbxu9s.fsf@alice.fifthhorseman.net> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PpD9m9WveK5uFc2cJKvGabAWkEM Cc: IETF TLS Working Group Subject: Re: [TLS] Contemplated major revision to draft-ietf-negotiated-ff-dhe X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 19 Sep 2014 21:10:06 -0000 On Fri, Sep 19, 2014 at 03:52:31PM -0400, Daniel Kahn Gillmor wrote: > > The idea is to have the draft drop the proposed FF-DHE TLS extension > entirely and instead redefine "Supported Elliptic curves" (TLS > extension 10) [0] to be a "Supported named groups" extension. Then > we would allocate some of the currently unallocated codepoints in the > NamedCurve IANA registry [1] to the proposed FF-DHE groups. > > == Advantages == > > The main goal of this change is to simplify the TLS 1.3 handshake while > allowing clients to send a 1.2+1.3 compatible first flight that includes > FF DHE without excessive duplication. Couple problems: - Implementations may not support same curves for ECDH and ECDSA, and SEC negotiates both. - It would be clearer if TLS 1.3 worked in terms of DH functions instead of DH groups (avoids problems with encodings for one, which are made more severe by inability to negotiate). Just check some drafts trying to fit Curve25519 into TLS. Those are quite hacky. Making DH function out of it would be trivial (since it already is DHF). DH Groups can be turned into DHFs by specifying encoding rules (which have to be specified anyway). Also, there are things even more exotic than Curve25519 & co. Like what is called "Kummer" in eBATS. > For aware servers, if they select a DHE key exchange they should send an > SKE as indicated in the current draft, with the server's DHParams > modified appropriately. (possibly, Alfredo's suggestion of sending an > entirely different handshake message instead of SKE in this case offers > a clearer indication to the client that the server has selected a named > group). SKE is quite different in 1.2 and 1.3: In 1.2, it also carries server signature. This does not specify the group used, which leads into a security problem since groups can be confused. In 1.3 the server signature is elsewhere (it has to be because of certificate encryption) which also avoids the group confusion problem (and some annoyances at analyzing security of key exchange). If server's choice of DHG/DHF is specified in ServerHello or SKE is also dependent on how "missed guess" is handled. There are two basic ways: 1) Restart. DHG/DHF has to be in SH. Potential for downgrade attacks? 2) Remedial CKE. The DHG/DHF can be in either SH or SKE. -Ilari From nobody Fri Sep 19 15:05:41 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBFF1A88DB for ; Fri, 19 Sep 2014 15:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, J_CHICKENPOX_45=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uREUEAPTndPi for ; Fri, 19 Sep 2014 15:05:38 -0700 (PDT) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 215071A88DA for ; Fri, 19 Sep 2014 15:05:37 -0700 (PDT) Received: by mail-lb0-f182.google.com with SMTP id u10so4014233lbd.27 for ; Fri, 19 Sep 2014 15:05:36 -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=sOw/8hPMIHqxveIE8eod4SjMuDY4AOEYMlIzWSBTpBs=; b=faYM/NOFMbgvmtRJ6ZnR6dJ8L6oKP2ErHxc1tojDNQaonsJEF4+PlKpSVQPL1K3pdo 56wIFQlr6YfInh5B4Cz1am7MQvMTpRPXq9tWseJy6Z6k2iPvsZW1IoUJbPQtrzJ/5n6t mRRk74qO7L6esxN47Qdf8xDMRD7DNwZrPRJ2uIsqY0P8AzfReveShxre/1dre6WFGrqz uiGg5fumBg92cz3ydDjEz3FG77MGdE0HZwhKqB2iM3K22gaYjAI/4ZfnM71f00XdxP20 327Sf0elHF+vI/jQ40rN59IuzR2SmAONo+LejS/o1UVRmdaIpdOoTeHTtHfmRSqlYrl+ ASCA== MIME-Version: 1.0 X-Received: by 10.152.28.74 with SMTP id z10mr9844541lag.10.1411164336468; Fri, 19 Sep 2014 15:05:36 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Fri, 19 Sep 2014 15:05:36 -0700 (PDT) In-Reply-To: <87bnqbxu9s.fsf@alice.fifthhorseman.net> References: <87bnqbxu9s.fsf@alice.fifthhorseman.net> Date: Fri, 19 Sep 2014 15:05:36 -0700 Message-ID: From: Martin Thomson To: Daniel Kahn Gillmor Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/r_g91FWiD3puLf7FmUQEiWWmGiM Cc: IETF TLS Working Group Subject: Re: [TLS] Contemplated major revision to draft-ietf-negotiated-ff-dhe X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 19 Sep 2014 22:05:39 -0000 On 19 September 2014 12:52, Daniel Kahn Gillmor wrote: > == Advantages == Great. This is much nicer as a rule. I think that the issues Ilari points are entirely orthogonal to this proposal, those are largely existing problems with the existing stuff. I do have one suggestion below that might help alleviate concerns like those though. > This proposal suggests carving out a small space of that registry for > finite field groups. I would rather you add a parameter to the registry so that entities that understand the code point can identify if the group is FF or EC. It would be informative only, scoping the registration appropriately. If further division is required, then more fields can be added. For instance, if Ilari's idea to separate ECDH and ECDSA use is something we decide to do, then the "type" field can be set to ECDH, ECDSA or ECDH+ECDSA (or FF). I'm not sure that that helps on the ServerHello end of things though. From nobody Sat Sep 20 02:20:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75DC41A03A9 for ; Sat, 20 Sep 2014 02:20:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x5YbLuhczLcH for ; Sat, 20 Sep 2014 02:20:07 -0700 (PDT) Received: from emh03.mail.saunalahti.fi (emh03.mail.saunalahti.fi [62.142.5.109]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 351171A0040 for ; Sat, 20 Sep 2014 02:20:06 -0700 (PDT) Received: from LK-Perkele-VII (a88-112-44-140.elisa-laajakaista.fi [88.112.44.140]) by emh03.mail.saunalahti.fi (Postfix) with ESMTP id 9C0AF188884; Sat, 20 Sep 2014 12:20:03 +0300 (EEST) Date: Sat, 20 Sep 2014 12:20:03 +0300 From: Ilari Liusvaara To: Martin Thomson Message-ID: <20140920092003.GA9982@LK-Perkele-VII> References: <87bnqbxu9s.fsf@alice.fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: Ilari Liusvaara Archived-At: http://mailarchive.ietf.org/arch/msg/tls/eQigUBEBnwpwJzCQChY3oVV3Scc Cc: IETF TLS Working Group Subject: Re: [TLS] Contemplated major revision to draft-ietf-negotiated-ff-dhe X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 20 Sep 2014 09:20:11 -0000 On Fri, Sep 19, 2014 at 03:05:36PM -0700, Martin Thomson wrote: > On 19 September 2014 12:52, Daniel Kahn Gillmor wrote: > > == Advantages == > > Great. This is much nicer as a rule. Yeah, I think this proposal sounds good. Process question: Does this need to update 4492 (it repurposes extensions defined there)? > I think that the issues Ilari points are entirely orthogonal to this > proposal, those are largely existing problems with the existing stuff. > I do have one suggestion below that might help alleviate concerns like > those though. I actually figured out solutions to those issues, without impacting this specification (and I consider those less radical than this spec). > > This proposal suggests carving out a small space of that registry for > > finite field groups. > > I would rather you add a parameter to the registry so that entities > that understand the code point can identify if the group is FF or EC. > It would be informative only, scoping the registration appropriately. Yeah, I think it should be done that way. > I'm not sure that that helps on the ServerHello end of things though. Talking about TLS 1.0-1.2 or 1.3? If 1.0-1.2, I don't see how ServerHello is involved (you don't have to signal the DH group used in elliptic_curves). If 1.3, where the group used is signaled anyway? I can't find it it in either SH or SKE. Regarding server key misinterpretation problems (only affects TLS 1.0-1.2), the notation differences between 1.2 and 4492 make seeing what is actually signed hard. So I can't say about possiblity of misinterpretting SKE. Also, regarding TLS libs not accepting <9 bit DHE, I have seen certain infamous TLS library accept some ridiculously short DHE prime (I think it was 16 bits or something like that)... But such problems should be fixed. -Ilari From nobody Sun Sep 21 19:40:01 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9E671A0188 for ; Wed, 3 Sep 2014 21:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.869 X-Spam-Level: X-Spam-Status: No, score=-4.869 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.668, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sULQIUBbLSuV for ; Wed, 3 Sep 2014 21:10:27 -0700 (PDT) Received: from mailbackend.panix.com (mailbackend.panix.com [166.84.1.89]) by ietfa.amsl.com (Postfix) with ESMTP id E2B6B1A017D for ; Wed, 3 Sep 2014 21:10:26 -0700 (PDT) Received: from panix5.panix.com (panix5.panix.com [166.84.1.5]) by mailbackend.panix.com (Postfix) with ESMTP id 1BB832E85F; Thu, 4 Sep 2014 00:10:26 -0400 (EDT) Received: by panix5.panix.com (Postfix, from userid 415) id EC2F5242E4; Thu, 4 Sep 2014 00:10:25 -0400 (EDT) From: Thor Lancelot Simon To: Bodo Moeller Message-ID: <20140904041025.GA21994@panix.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D1204BE08@USMBX1.msg.corp.akamai.com> <54065198.7030802@fussenegger.info> <1337098131.42281155.1409742902146.JavaMail.zimbra@redhat.com> <1408022371.42292099.1409744430634.JavaMail.zimbra@redhat.com> <412891267.42325154.1409748504518.JavaMail.zimbra@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/asVUQZnH2kqmLJWKIHH0Gwuihuk X-Mailman-Approved-At: Sun, 21 Sep 2014 19:40:00 -0700 Cc: "tls@ietf.org" Subject: Re: [TLS] tickets or sesssions or both (oh my) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Date: Thu, 04 Sep 2014 04:10:30 -0000 X-Original-Date: Thu, 4 Sep 2014 00:10:25 -0400 X-List-Received-Date: Thu, 04 Sep 2014 04:10:30 -0000 On Wed, Sep 03, 2014 at 04:02:58PM +0200, Bodo Moeller wrote: > Hubert Kario : > > Could you provide an example of system that "really need[s] tickets"? > > > > Well, strictly speaking, no system really, really *needs* tickets because > you could always start new sessions if a supposedly resumable session can't > be found in the server's cache (at a computational cost, and at a latency > cost). Indeed. Here again, we have the opportunity to make a doctrinaire mistake that trades away actual security in practice (and workload for the likely adversary) to obtain some theoretical security street cred. You know, like forcing everyone to 2048 bit RSA keys (and impeding the universal of HTTPS everywhere, particularly for sites behind computational choke points such as load balancers) when 1280 bits or so would have been plenty. Anything that forces live state synchronization amongst large distributed systems (such as reverting from tickets to a shared session cache) or more full RSA exchanges makes the cost of TLS measurable, and sometimes prohibitive, for some applications where its _only_ real rationale is herd immunity from snooping -- where the only benefit's collective and social and if crypto has measurable costs the entity running the server will just skip the crypto. Let's not make that mistake again. Thor From nobody Sun Sep 21 19:40:34 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 395611A019C; Thu, 18 Sep 2014 04:57:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cPd25dxKy-T; Thu, 18 Sep 2014 04:57:42 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4ACB1A0162; Thu, 18 Sep 2014 04:57:41 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id b12so980857lbj.11 for ; Thu, 18 Sep 2014 04:57:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=am9UFLxq8n7Y7GjP5aIDlJZ0hgF7pWu1TNIxV4czFVk=; b=Wn81gZABmoPziiMitPcWcDLS29hr53hhJ9O55ey/UIqjrYXS/CR71UssRnamy/zksm PKR3QFSxmpVLr1zIJikLU5NH2Nj5wSKJVwvorqG02QpnomvpGqnSDgxfC+lJL6X7iMn6 7jBeNnI/zMIazfWgQDn77HdTs5kRku4ObNNOJyt33dyIGdza6jboOW5/z8b1/3FTZvvF EJS2HckZzyaEsfYp7Vd+ZxVUG3lbqa11F+/bFukmsUXiv56noMFWwhQq/33d88ZIlIta vcQs7fFp2UvAzIbD+qxb3z3ToAWDlelq/ctxJDIKJuDl5CarWHvbBoe+A/cqFm/8rcoq hvWw== MIME-Version: 1.0 X-Received: by 10.112.13.232 with SMTP id k8mr3614021lbc.81.1411041459821; Thu, 18 Sep 2014 04:57:39 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.122.51 with HTTP; Thu, 18 Sep 2014 04:57:39 -0700 (PDT) In-Reply-To: <1411032333.18523.18.camel@dhcp-2-127.brq.redhat.com> References: <1409931283.1731.16.camel@dhcp-2-127.brq.redhat.com> <1411032333.18523.18.camel@dhcp-2-127.brq.redhat.com> Date: Thu, 18 Sep 2014 07:57:39 -0400 X-Google-Sender-Auth: s1TvmsesBfIKOgTiYAtJhLWlivw Message-ID: From: Phillip Hallam-Baker To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-4VSKbYwYsyNQhXPTC4t_Qh5Fh4 X-Mailman-Approved-At: Sun, 21 Sep 2014 19:40:33 -0700 Cc: "pkix@ietf.org" , "tls@ietf.org" Subject: Re: [TLS] New version of the TLS feature draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 18 Sep 2014 11:57:43 -0000 On Thu, Sep 18, 2014 at 5:25 AM, Nikos Mavrogiannopoulos wrote: > On Sat, 2014-09-13 at 20:20 -0500, Tom Ritter wrote: >> On 5 September 2014 10:34, Nikos Mavrogiannopoulos wrote: >> > I don't see how it does close the door. What should the client do if the >> > server administrator sets up an old version of a valid ocsp staple? >> >> Section 3.1.1 specifies "a server MUST return a valid OCSP token". I >> would consider an expired ocsp staple to not actually be valid. I >> would refer to it as expired, with the implication that the signature >> is correct, because if it wasn't a person probably would have said >> that in addition to describing it as expired. > > That's pretty sketchy. OCSP responses have a recommended validity > interval, this is not the same as X.509 certificate expiration. I'm not > sure what popular browsers do with responses received by the server that > are outside the validity period, but I would be very surprised if they > dropped the connection. If in this document it is assumed that responses > not within the recommended interval should cause a TLS connection > failure, it should be explicit. Given that we currently have a situation where the vast majority of Web browsers are not PKIX compliant and ignore revocation information completely and Web browsers are only one PKIX application, I don't think it is appropriate to use a MUST here to direct how invalid status is handled. Dropping the connection is only one response that might be appropriate. For example, if a certificate is presented during an SMPT STARTTLS upgrade. Do we want to abort the connection if the certificate is expired or revoked? Well maybe we do but what if we would have delivered the message without TLS at all. In the Web browser case we might also be in an opportunistic encryption situation. We might drop out the security indicator for a revoked cert in that case. We can certainly tell the server that if the feature extension is present the server MUST be in compliance. Because failure to comply is almost certain to result in a compatibility issue. That compatibility issue may be less than rejection of the connection but client is in its rights to do that. I don't think we can specify compliance requirements on the client. We can provide the client with information and tell the client how to interpret is but we can't mandate anything more. From enricarcediano@gmail.com Sat Sep 20 00:51:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 954701A8943 for ; Sat, 20 Sep 2014 00:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zivOBTUZwCmR for ; Sat, 20 Sep 2014 00:51:47 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AA19C1A8941 for ; Sat, 20 Sep 2014 00:51:47 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id j5so70278qga.39 for ; Sat, 20 Sep 2014 00:51:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=RwjqKx958VUu5RoXhe7GKKjNQZzicZwwzjqCWg0YFcE=; b=a/ckfiWEuEZ9WsIW4wQTDvusxHYC6RAG1yQ16TmTJ6g117lHjjaga6tXYjeZskiCBq MfNSD/GEJdd18Y1yBZrROmIEX+iTADgcgZFecwEtI43YIkCS5fZGrVnYheGhTgtkT6K5 A8vavDQDth//Dr5u0zjjseUMzoF7JEeZBI2kqIVMQtI2QWC1hN6V8SNWvd3eC90ikoiX GSRDXqK5ibhSyP/3fYoCOf2zwoWj+QuPw1fXFdBpKutoFylkucsl85zqKlLGpUvZJ/E7 JvDIGIkD9n2NnXBleC4jqa8WZ6zlhh+jyJS1VCsJIbOAhbYKjSpnN3KVH9ygygUpKp3G Yxzg== MIME-Version: 1.0 X-Received: by 10.140.48.1 with SMTP id n1mr160852qga.104.1411199506731; Sat, 20 Sep 2014 00:51:46 -0700 (PDT) Received: by 10.140.224.199 with HTTP; Sat, 20 Sep 2014 00:51:46 -0700 (PDT) Date: Sat, 20 Sep 2014 09:51:46 +0200 Message-ID: From: Fox Arcadia To: tls@ietf.org Content-Type: multipart/alternative; boundary=001a11350eac4e590805037a7d21 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ExMDr0_0s7aCELoZQzTNH--7Z-o X-Mailman-Approved-At: Sun, 21 Sep 2014 19:41:27 -0700 Subject: [TLS] RFC5487 PSK Key Exchange Algorithm with SHA-256/384. Premaster secret if ciphersuites negotiated for TLS V1.2? X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 20 Sep 2014 07:53:21 -0000 --001a11350eac4e590805037a7d21 Content-Type: text/plain; charset=UTF-8 Hello For the ciphersuites defined in RFC 5487 3.1 PSK Key Exchange Algorithm with SHA-256/384 CipherSuite TLS_PSK_WITH_AES_128_CBC_SHA256 = {0x00,0xAE}; CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA384 = {0x00,0xAF}; CipherSuite TLS_PSK_WITH_NULL_SHA256 = {0x00,0xB0}; CipherSuite TLS_PSK_WITH_NULL_SHA384 = {0x00,0xB1}; How is the premaster secret formed if the negotiated version is TLS 1.2? according to RFC 4279 Pre-Shared key ciphersuites for TLS: The premaster secret is formed as follows: if the PSK is N octets long, concatenate a uint16 with the value N, N zero octets, a second uint16 with the value N, and the PSK itself. Note 1: All the ciphersuites in this document share the same general structure for the premaster secret, namely, struct { opaque other_secret<0..2^16-1>; opaque psk<0..2^16-1>; }; ... Note 2: Using zeroes for "other_secret" effectively means that only the HMAC-SHA1 part (but not the HMAC-MD5 part) of the TLS PRF is used when constructing the master secret. This was considered more elegant from an analytical viewpoint than, for instance, using the same key for both the HMAC-MD5 and HMAC-SHA1 parts. See [KRAWCZYK ] for a more detailed rationale. but if using a PRF defined in TLS V1.2, then HMAC-MD5 is not used but the HMAC defined by the PRF. And, in that case, part of the used premaster is zeroes. should we in that case reuse PSK for other_secret? Thanks --001a11350eac4e590805037a7d21 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello

For the ciphersuites defined in RFC 5487<= /span>=C2=A0 3.1 
PSK Key Exchange =
Algorithm with SHA-256/384
CipherSuite TLS_PSK_W=
ITH_AES_128_CBC_SHA256        =3D {0x00,0xAE};
CipherSuite TLS_PSK_WITH_AES_256_CBC_SHA384        =3D {0x00,0xAF};
CipherSuite TLS_PSK_WITH_NULL_SHA256               =3D {0x00,0xB0};
CipherSuite TLS_PSK_WITH_NULL_SHA384               =3D {0x00,0xB1};


How is the premaster secret formed if the neg=
otiated version is TLS 1.2?

according to RFC 4279 Pre-Shared key ciphersuites for TLS:

The premaster secret is for=
med as follows: if the PSK is N octets
   long, concatenate a uint16 with the value N, N zero octets, a second
   uint16 with the value N, and the PSK itself.

      Note 1: All the ciphersuites in this document share the same
      general structure for the premaster secret, namely,

         struct {
             opaque other_secret<0..2^16-1>;
             opaque psk<0..2^16-1>;
         };


...

 Note 2: Using zeroes for "other_secret" effec=
tively means that
      only the HMAC-SHA1 part (but not the HMAC-MD5 part) of the TLS PRF
      is used when constructing the master secret.  This was considered
      more elegant from an analytical viewpoint than, for instance,
      using the same key for both the HMAC-MD5 and HMAC-SHA1 parts.  See
      [KRAWCZYK] for a more detailed rat=
ionale.

 
but if using a PRF defined in TLS=
 V1.2, then HMAC-MD5 is not used but the HMAC defined by the PRF.
=

And, in that case, part of the used premaster is zeroes.
should we in that case reuse PSK for other_secret?
Thanks
--001a11350eac4e590805037a7d21-- From nobody Mon Sep 22 10:21:24 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2871C1A1BC6 for ; Mon, 22 Sep 2014 10:21:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lI_GucynuR-y for ; Mon, 22 Sep 2014 10:21:21 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E24891A1B6C for ; Mon, 22 Sep 2014 10:21:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=462; q=dns/txt; s=iport; t=1411406480; x=1412616080; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=+wgWRtb6GLPv7/CnbtpqjuniL4dFwNvU1YoAoErj4Mg=; b=NGxIdVRXelzZn9cUhsixmZysZaI/b8r1pSutzF8MJktoiagWlwvobT4V TrV/BHhp+E140VZ55c+vQ+PDQRK6oCba9NHs2Oa4mzrwg4t+4jpwbQF3p vigffa5G5hy8AEEt+vVb9rRcp3zvemSy2hMGkLsEduTVftKdTfCP4W81N s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAABaIFStJA2K/2dsb2JhbABggw6BLtMrFgF5hAo6UQE+QicEiFGfIKUiAReTO4EdBZFXiz+VUoNhgjSBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,572,1406592000"; d="scan'208";a="80187007" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-4.cisco.com with ESMTP; 22 Sep 2014 17:21:20 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s8MHLKqw003256 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 22 Sep 2014 17:21:20 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.15]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0195.001; Mon, 22 Sep 2014 12:21:20 -0500 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: Result of draft-ietf-tls-prohibiting-rc4 working group last call Thread-Index: AQHP1omfO2r5VaDi70eLNEUG2BakCw== Date: Mon, 22 Sep 2014 17:21:19 +0000 Message-ID: <7A435FB4-3BBE-4FCB-B8CB-2C33CA1D8B30@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.136] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/hDG57PYc3pGSzi1l5eIHwY5X46A Subject: [TLS] Result of draft-ietf-tls-prohibiting-rc4 working group last call X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 22 Sep 2014 17:21:22 -0000 We've reviewed the discussion resulting from the WGLC for draft-ietf-tls-pr= ohibiting-rc4-00. The main complaint was that the "MUST NOT" prohibition o= f RC4 for servers was too strong and that RC4 is still needed to interopera= te with older implementations. The consensus of the discussion was to kee= p the document as is with respect to prohibiting the negotiation of RC4. T= his document will be forwarded to the IESG for publication. =20 J/S From nobody Mon Sep 22 14:23:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B411A1B57; Mon, 22 Sep 2014 12:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PjIRetE9GCPr; Mon, 22 Sep 2014 12:10:56 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DFE21A1B4F; Mon, 22 Sep 2014 12:10:56 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id el20so935670lab.4 for ; Mon, 22 Sep 2014 12:10:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=zukrZABkicDSi08OUL0S+bxw3cCH/RPiUOi8TEDaB58=; b=WvqTDrdyVY2b8nWppwVom30VqsFj/K7GVaVX8Ed1SjOQRbYKCeW7a4Y+Lc+yI3S/of j1zDnag+dQ0HcdtsvUvjQKb/0ybrt2xLCyDHqVNPWLv23zTyDOu0pSn1GT52ANoS+aXt qXr/271v1Gwh7nWBqF3ZS621MK++Zyu0hTyg/Qaf9GDPURj2XDR5QLbJoUk109kuWt62 Wf2lWE1U1Sc01rgqzXOev+hFOvHwB69QvUGp2l5ULyDWA4fZXQV1a6iAi2a1/iBtft/p ovN1I6kA7061oZq6TUlScXAPJJVAiGf0jUHPhY7WvQHuBpzwqiZ7fEa4VKv12V4iZRsB BT0g== MIME-Version: 1.0 X-Received: by 10.112.235.199 with SMTP id uo7mr26435145lbc.50.1411413053787; Mon, 22 Sep 2014 12:10:53 -0700 (PDT) Sender: hallam@gmail.com Received: by 10.112.122.51 with HTTP; Mon, 22 Sep 2014 12:10:53 -0700 (PDT) In-Reply-To: <1411051138.18523.42.camel@dhcp-2-127.brq.redhat.com> References: <1409931283.1731.16.camel@dhcp-2-127.brq.redhat.com> <1411032333.18523.18.camel@dhcp-2-127.brq.redhat.com> <1411051138.18523.42.camel@dhcp-2-127.brq.redhat.com> Date: Mon, 22 Sep 2014 15:10:53 -0400 X-Google-Sender-Auth: JhIvkDx4HeGUTo6Anni6rme4TUk Message-ID: From: Phillip Hallam-Baker To: Nikos Mavrogiannopoulos Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ppnin5g6ZMP12ohklVCPzjKC8hA X-Mailman-Approved-At: Mon, 22 Sep 2014 14:23:33 -0700 Cc: "pkix@ietf.org" , "tls@ietf.org" Subject: Re: [TLS] New version of the TLS feature draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 22 Sep 2014 19:10:58 -0000 On Thu, Sep 18, 2014 at 10:38 AM, Nikos Mavrogiannopoulos wrote: > On Thu, 2014-09-18 at 07:57 -0400, Phillip Hallam-Baker wrote: > >> >> Section 3.1.1 specifies "a server MUST return a valid OCSP token". I >> >> would consider an expired ocsp staple to not actually be valid. I >> >> would refer to it as expired, with the implication that the signature >> >> is correct, because if it wasn't a person probably would have said >> >> that in addition to describing it as expired. >> > >> > That's pretty sketchy. OCSP responses have a recommended validity >> > interval, this is not the same as X.509 certificate expiration. I'm not >> > sure what popular browsers do with responses received by the server that >> > are outside the validity period, but I would be very surprised if they >> > dropped the connection. If in this document it is assumed that responses >> > not within the recommended interval should cause a TLS connection >> > failure, it should be explicit. >> Given that we currently have a situation where the vast majority of >> Web browsers are not PKIX compliant and ignore revocation information >> completely and Web browsers are only one PKIX application, I don't >> think it is appropriate to use a MUST here to direct how invalid >> status is handled. > > Maybe not, but it makes sense to define what is valid and invalid. > The problem statement of this draft as you set it is to close a door on > a "downgrade" attack where no OCSP response is sent. However, if you > don't define what is a secure connection to a server that supports OCSP > status request, how can you claim to fix an attack? The draft is designed to allow the client to close the door on the downgrade attack. That meets the problem statement, I think. From nobody Mon Sep 22 15:45:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB631A6F39 for ; Mon, 22 Sep 2014 15:45:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cs-CQgZsfnwa for ; Mon, 22 Sep 2014 15:45:40 -0700 (PDT) Received: from mournblade.imrryr.org (mournblade.imrryr.org [38.117.134.19]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 068411A6F34 for ; Mon, 22 Sep 2014 15:45:40 -0700 (PDT) Received: by mournblade.imrryr.org (Postfix, from userid 1034) id E1D7F2AAC74; Mon, 22 Sep 2014 22:45:38 +0000 (UTC) Date: Mon, 22 Sep 2014 22:45:38 +0000 From: Viktor Dukhovni To: tls@ietf.org Message-ID: <20140922224538.GH13254@mournblade.imrryr.org> References: <1409931283.1731.16.camel@dhcp-2-127.brq.redhat.com> <1411032333.18523.18.camel@dhcp-2-127.brq.redhat.com> <1411051138.18523.42.camel@dhcp-2-127.brq.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QIAvY_wJxyi4kb9V6QAKM4I-SlE Subject: Re: [TLS] New version of the TLS feature draft X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: tls@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: Mon, 22 Sep 2014 22:45:41 -0000 On Mon, Sep 22, 2014 at 03:10:53PM -0400, Phillip Hallam-Baker wrote: > >> Given that we currently have a situation where the vast majority of > >> Web browsers are not PKIX compliant and ignore revocation information > >> completely and Web browsers are only one PKIX application, I don't > >> think it is appropriate to use a MUST here to direct how invalid > >> status is handled. > > > > Maybe not, but it makes sense to define what is valid and invalid. > > The problem statement of this draft as you set it is to close a door on > > a "downgrade" attack where no OCSP response is sent. However, if you > > don't define what is a secure connection to a server that supports OCSP > > status request, how can you claim to fix an attack? > > The draft is designed to allow the client to close the door on the > downgrade attack. That meets the problem statement, I think. I strongly agree, but perhaps we should provide a more detailed answer... Yes of course the draft can't mandate that the client must fail, since as you note the client might be doing opportunistic STARTTLS, and the TLS session should be established in that case, even if stapled data is missing or expired. Therefore, the TLS library cannot unconditionally enforce the requirements of the draft by shutting down the connection or the like. However the TLS library can and should signal a failure to verify the peer certificate chain. Clients that proceed despite such failure can continue to establish the session, while clients that want an authenticated peer may elect to abort the TLS session, or to complete it and then gracefully perform an application-level abort, ... So there is room to say that servers that fail to present an expected sufficiently fresh stapled OCSP response MUST NOT be considered to have a valid certificate chain. What happens after that is up to the application. Such a statement would help library implementors do the right thing, (signal verification failure) and avoid both inadvertently ignoring the problem as well as over-reaction that might needlessly degrade opportunistic clients to cleartext. -- Viktor. From nobody Mon Sep 22 23:47:17 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D741A0352 for ; Mon, 22 Sep 2014 23:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RB8rwn7JsX03 for ; Mon, 22 Sep 2014 23:47:13 -0700 (PDT) Received: from mail-we0-x22f.google.com (mail-we0-x22f.google.com [IPv6:2a00:1450:400c:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 800E61A02FC for ; Mon, 22 Sep 2014 23:47:13 -0700 (PDT) Received: by mail-we0-f175.google.com with SMTP id u57so3210846wes.34 for ; Mon, 22 Sep 2014 23:47:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=CN31LL8wmQbysIy3hiA8cHpFxM9PzfzhOcFk0MVmOUE=; b=lv12WpwdphBIl8X3kLfQT2yLr4d9FdV9A6EMSaT/ZAF9kK+UYJBLXSYILkx5I2kcEb 40wUFv/ANgLBCZm54YiCBxe4/Jwo8m1jqUuhHbZ9aQAz2FIjeECqUg5clu8l2TuybO35 6/dVQgyLAT1rZ4FYri/awup0gcwcPyayDnVV1db1yP9gwWz0LG8TFa4a+5D+cb06RM1y 6eWkhRgNQZhhAo7gIS/yuK9YgJL/CLsC70C21jHlk+X+QwWPlVVx8fzFq8jIqbviSUXI nwwjhifusTXTPSO6VtcfN2FpbqWry6bzP+HV/o/eL7eINHnyg189ahzU5PCsexgT9JYb k7Nw== X-Received: by 10.180.77.100 with SMTP id r4mr896635wiw.1.1411454832030; Mon, 22 Sep 2014 23:47:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.66.225 with HTTP; Mon, 22 Sep 2014 23:46:31 -0700 (PDT) From: Ryan Carboni Date: Mon, 22 Sep 2014 23:46:31 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=f46d04389237e13c2b0503b5eff3 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/E1-YKD536CAvel5HZbAUY2j8HXE Subject: [TLS] Ciphersuite suggestion: add ISAAC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 23 Sep 2014 06:47:15 -0000 --f46d04389237e13c2b0503b5eff3 Content-Type: text/plain; charset=UTF-8 It's slightly more secure then RC4, but much faster. http://burtleburtle.net/bob/rand/isaacafa.html --f46d04389237e13c2b0503b5eff3 Content-Type: text/html; charset=UTF-8
It's slightly more secure then RC4, but much faster.

http://burtleburtle.net/bob/rand/isaacafa.html
--f46d04389237e13c2b0503b5eff3-- From nobody Tue Sep 23 07:27:27 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1919C1A86E6 for ; Tue, 23 Sep 2014 07:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.285 X-Spam-Level: X-Spam-Status: No, score=-1.285 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LbYyyML-gR_3 for ; Tue, 23 Sep 2014 07:27:24 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id C496F1A86ED for ; Tue, 23 Sep 2014 07:27:21 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 5766E48598; Tue, 23 Sep 2014 14:27:21 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 405044858F; Tue, 23 Sep 2014 14:27:21 +0000 (GMT) Received: from ustx2ex-cashub.dfw01.corp.akamai.com (ustx2ex-cashub1.dfw01.corp.akamai.com [172.27.25.75]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 3D95E98046; Tue, 23 Sep 2014 14:27:21 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.2.28]) by ustx2ex-cashub1.dfw01.corp.akamai.com ([172.27.25.75]) with mapi; Tue, 23 Sep 2014 09:27:20 -0500 From: "Salz, Rich" To: Ryan Carboni , "tls@ietf.org" Date: Tue, 23 Sep 2014 09:27:19 -0500 Thread-Topic: [TLS] Ciphersuite suggestion: add ISAAC Thread-Index: Ac/W+joXSJJviJ6CRY68lisAAnmpoQAQCOQA Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D2EDB3EDD@USMBX1.msg.corp.akamai.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_2A0EFB9C05D0164E98F19BB0AF3708C71D2EDB3EDDUSMBX1msgcorp_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UwHzJUqBYqf1T--Zji1PvzxrNo4 Subject: Re: [TLS] Ciphersuite suggestion: add ISAAC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 23 Sep 2014 14:27:26 -0000 --_000_2A0EFB9C05D0164E98F19BB0AF3708C71D2EDB3EDDUSMBX1msgcorp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SXQgaGFzbuKAmXQgaGFkIG11Y2ggcmV2aWV3LiAgQW5kIGZvciBUTFMgMS4zIHdl4oCZcmUgb25s eSBkb2luZyBBRUFEIHR5cGVzIG9mIGNpcGhlcnMuDQoNCi0tDQpQcmluY2lwYWwgU2VjdXJpdHkg RW5naW5lZXIsIEFrYW1haSBUZWNobm9sb2dpZXMNCklNOiByc2FsekBqYWJiZXIubWU8bWFpbHRv OnJzYWx6QGphYmJlci5tZT4gVHdpdHRlcjogUmljaFNhbHoNCg== --_000_2A0EFB9C05D0164E98F19BB0AF3708C71D2EDB3EDDUSMBX1msgcorp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglw YW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdE O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBn dGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIx MDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpz aGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIg Lz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hlYWQ+PGJvZHkgbGFuZz1F Ti1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29yZFNlY3Rpb24xPjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPkl0IGhhc27igJl0IGhhZCBtdWNo IHJldmlldy7CoCBBbmQgZm9yIFRMUyAxLjMgd2XigJlyZSBvbmx5IGRvaW5nIEFFQUQgdHlwZXMg b2YgY2lwaGVycy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7Y29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPi0twqAgPG86cD48L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMxRjQ5N0QnPlByaW5jaXBhbCBTZWN1 cml0eSBFbmdpbmVlciwgQWthbWFpIFRlY2hub2xvZ2llczxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjtjb2xvcjojMUY0OTdEJz5JTTogPGEgaHJlZj0ibWFp bHRvOnJzYWx6QGphYmJlci5tZSI+PHNwYW4gc3R5bGU9J2NvbG9yOmJsdWUnPnJzYWx6QGphYmJl ci5tZTwvc3Bhbj48L2E+IFR3aXR0ZXI6IFJpY2hTYWx6PG86cD48L286cD48L3NwYW4+PC9wPjwv ZGl2PjwvYm9keT48L2h0bWw+ --_000_2A0EFB9C05D0164E98F19BB0AF3708C71D2EDB3EDDUSMBX1msgcorp_-- From nobody Tue Sep 23 13:27:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52AB1A88C9 for ; Tue, 23 Sep 2014 13:27:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FIzKiLPZRYiE for ; Tue, 23 Sep 2014 13:27:30 -0700 (PDT) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DC3D1A88C4 for ; Tue, 23 Sep 2014 13:27:29 -0700 (PDT) Received: by mail-we0-f173.google.com with SMTP id x48so3694125wes.4 for ; Tue, 23 Sep 2014 13:27:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=uUca9XBdZIrJNObvV1uKibt0J7M+kNEIJgK/daK0oQg=; b=TFaAnBb83lHvCG+zNe9bENSh+s1tB4XZ4RbJg4DPfPVtMSFiNJTcl/CzRQgAw28fL6 Lx1NH5inHC3UUbg6sg2QBhlskJFFGcADc7OBeRg7TIlO/svpNAo7tqrV7jZXYu4prFaF foMvkpTBSuNhsF3Fb75/2wETn2OJw03VwTnAbJUeCSzlgWskmQiy7oauvaWgWE27rEn/ Qvs9tg77GCXBy9v6ptqnAJ9zYFcCpddk2fnBDHl6Nisxyfmm9oskL5vo3d7vLx7qGJl3 DDAWqry+ONXkSK2WBGPKH0O9ETAijj4SyXUJOaHCrJIYKUdq5Tl8BlBRSLdKFyxLEgUV GQwQ== X-Received: by 10.180.91.101 with SMTP id cd5mr6363850wib.41.1411504048555; Tue, 23 Sep 2014 13:27:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.66.225 with HTTP; Tue, 23 Sep 2014 13:26:48 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D2EDB4132@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D2EDB3EDD@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D2EDB4132@USMBX1.msg.corp.akamai.com> From: Ryan Carboni Date: Tue, 23 Sep 2014 13:26:48 -0700 Message-ID: To: "Salz, Rich" , "tls@ietf.org" Content-Type: multipart/alternative; boundary=14dae9cc964069cdec0503c16555 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/L0fy2TZMATZeUi2xTF0ZpnhGRAc Subject: Re: [TLS] Ciphersuite suggestion: add ISAAC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 23 Sep 2014 20:27:32 -0000 --14dae9cc964069cdec0503c16555 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable https://en.wikipedia.org/wiki/ISAAC_%28cipher%29#Cryptanalysis Such irony, people have to be famous in the crypto community in order for their ciphers to be adopted, in order to be famous one much have ciphers adopted. On Tue, Sep 23, 2014 at 1:21 PM, Salz, Rich wrote: > I looked at the webpge you posted and it seemed like there was one paper > by someone other than the author? And few will argue about djb=E2=80=99s > credentials. > > > > More importantly, tho, is the AEAD issue. > > > > -- > > Principal Security Engineer, Akamai Technologies > > IM: rsalz@jabber.me Twitter: RichSalz > > > > *From:* Ryan Carboni [mailto:ryacko@gmail.com] > *Sent:* Tuesday, September 23, 2014 4:18 PM > *To:* Salz, Rich > *Subject:* Re: [TLS] Ciphersuite suggestion: add ISAAC > > > > Has a decade of review. Does this mean ChaCha20 won't be adopted either? > > > > On Tue, Sep 23, 2014 at 7:27 AM, Salz, Rich wrote: > > It hasn=E2=80=99t had much review. And for TLS 1.3 we=E2=80=99re only do= ing AEAD types of > ciphers. > > > > -- > > Principal Security Engineer, Akamai Technologies > > IM: rsalz@jabber.me Twitter: RichSalz > > > --14dae9cc964069cdec0503c16555 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Such irony, people have to be = famous in the crypto community in order for their ciphers to be adopted, in= order to be famous one much have ciphers adopted.

On Tue, Sep 23, 2014 at 1:21 PM, Salz,= Rich <rsalz@akamai.com> wrote:

I looked at the webpge you posted and i= t seemed like there was one paper by someone other than the author?=C2=A0 A= nd few will argue about djb=E2=80=99s credentials.

=

=C2=A0

More importantly, t= ho, is the AEAD issue.

=C2=A0

--=C2=A0

Principal Security Engineer, Aka= mai Technologies

IM: rsalz@jabber.me Twitter: RichSalz

=C2=A0

From: Ryan Carboni [mailto:ryacko@gmail.com]
Sent: Tuesday, September 23, 2014 4:18 PM
To: Salz, Rich
= Subject: Re: [TLS] Ciphersuite suggestion: add ISAAC

=C2=A0<= /p>

Has a decade of review. Does this mean ChaCh= a20 won't be adopted either?

=C2=A0

On Tue, Sep 23= , 2014 at 7:27 AM, Salz, Rich <rsalz@akamai.com> wrote:

It hasn=E2=80=99t had much r= eview.=C2=A0 And for TLS 1.3 we=E2=80=99re only doing AEAD types of ciphers= .

=C2=A0

--=C2=A0

Principal Security Engineer, Akamai Technologies

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">IM: rsalz@jabber.me Twitter: RichSalz

=C2=A0


--14dae9cc964069cdec0503c16555-- From nobody Tue Sep 23 13:37:29 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD6371A88AE for ; Tue, 23 Sep 2014 13:37:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w7FD9AQ0S3m3 for ; Tue, 23 Sep 2014 13:37:25 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4D3E21A86F4 for ; Tue, 23 Sep 2014 13:37:25 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id k14so5077583wgh.0 for ; Tue, 23 Sep 2014 13:37:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=nd8SKWCgfGhAb/u1beN3J4eVCcts71dJZF5pOUZEp7A=; b=r5i3fKhrESN8f6O7t61wCpMlFHzdes8A0BUqw55r/5sHEu/BzprU4fHPevq7geB5sQ fmnDtIlxJvJ3vLbsUGDyfok/nOi8EX0jGDGLzTbjj64dYLAagv/xvOzYYKB5HQkxmgOP VAPo6316CdBf532rFC9deeY38RLsbUv+iBXc0QdZceB3Gf0GFUaueXFGDfbkn8rBoUA5 TztiA9+c7HWXII1OyfKlWMY3NlvkvANuZfQuUq0GZib4+Qy34swOUZkhRlwn+V+D24E6 6V17PLZ4KzT0Z28gnUQil2hGYTYnUb4DmZoV4fKwVohgeLHPy2J6Wt/R2bVl/ynciB9B HYqw== X-Received: by 10.194.189.233 with SMTP id gl9mr2704965wjc.2.1411504643789; Tue, 23 Sep 2014 13:37:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.66.225 with HTTP; Tue, 23 Sep 2014 13:36:43 -0700 (PDT) In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D2EDB4145@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D2EDB3EDD@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D2EDB4132@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D2EDB4145@USMBX1.msg.corp.akamai.com> From: Ryan Carboni Date: Tue, 23 Sep 2014 13:36:43 -0700 Message-ID: To: "Salz, Rich" , "tls@ietf.org" Content-Type: multipart/alternative; boundary=047d7bb04d52e459100503c1880e Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Ub1wBjMOKKJTMaIOGZJVb-N5TnM Subject: Re: [TLS] Ciphersuite suggestion: add ISAAC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 23 Sep 2014 20:37:26 -0000 --047d7bb04d52e459100503c1880e Content-Type: text/plain; charset=UTF-8 None taken. But draft proposals can always be withdrawn. And in the case of ChaCha20-Poly1305, you don't even need to have the correct test vectors with the first draft. --047d7bb04d52e459100503c1880e Content-Type: text/html; charset=UTF-8
None taken. But draft proposals can always be withdrawn. And in the case of ChaCha20-Poly1305, you don't even need to have the correct test vectors with the first draft.
--047d7bb04d52e459100503c1880e-- From nobody Tue Sep 23 14:58:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91EAB1A1F04 for ; Tue, 23 Sep 2014 14:58:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.287 X-Spam-Level: X-Spam-Status: No, score=-2.287 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OccIR479lWH for ; Tue, 23 Sep 2014 14:58:14 -0700 (PDT) Received: from smtp.dei.uc.pt (smtp.dei.uc.pt [193.137.203.253]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E1BC1A1BD2 for ; Tue, 23 Sep 2014 14:58:09 -0700 (PDT) Received: from [192.168.1.67] (bl16-206-97.dsl.telepac.pt [188.81.206.97]) (authenticated bits=0) by smtp.dei.uc.pt (8.14.4/8.14.4) with ESMTP id s8NLva1j004854 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 23 Sep 2014 22:57:42 +0100 Message-ID: <5421ECD0.90805@dei.uc.pt> Date: Tue, 23 Sep 2014 22:57:36 +0100 From: Samuel Neves User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: "tls@ietf.org" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-FCTUC-DEI-SIC-MailScanner-Information: Please contact helpdesk@dei.uc.pt for more information X-FCTUC-DEI-SIC-MailScanner-ID: s8NLva1j004854 X-FCTUC-DEI-SIC-MailScanner: Found to be clean X-FCTUC-DEI-SIC-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-60.25, required 3.252, autolearn=not spam, ALL_TRUSTED -10.00, BAYES_00 -0.25, L_SMTP_AUTH -50.00) X-FCTUC-DEI-SIC-MailScanner-From: sneves@dei.uc.pt Archived-At: http://mailarchive.ietf.org/arch/msg/tls/LRtRXvgBBmC2UJaqMCB4Z_k6LWY Subject: Re: [TLS] Ciphersuite suggestion: add ISAAC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 23 Sep 2014 21:58:16 -0000 On 23-09-2014 07:46, Ryan Carboni wrote: > It's slightly more secure then RC4, but much faster. > > http://burtleburtle.net/bob/rand/isaacafa.html There is no good reason to adopt ISAAC in this day and age. Let's suppose= for a moment that ISAAC is perfectly secure, and that we can bolt on some authenticator to make it AEAD. Even then it'= s a poor choice. Here's why: - Not really that fast. The core round operation of ISAAC, like RC4, use= s data-dependent memory accesses and is inherently sequential. This not only makes side-channel attacks a possibi= lity, but also implies that the peak speed of the cipher is limited by L1 latency. In my measurements I get no less tha= n 3.3 cycles per byte on a Sandy Bridge CPU. In this same CPU both Salsa20 and Chacha20 beat that, and in more recent pro= cessors beat it even more convincingly. - Huge internal state. ISAAC requires over 2 KB of (stack) memory just f= or its internal state. This can increase overall cache misses on standard CPUs, and might make it hard to implemen= t on the very low end. - There is already an RC4-like cipher among the winners of the eSTREAM c= ompetition: HC-128. I still wouldn't recommend it, since the previous two points also apply, but it's faster than ISAAC = and its initialization seems better thought-out. At least one TLS implementation has a custom ciphersuite usi= ng HC-128: https://github.com/cyassl/cyassl/blob/7ed180a04b5e64e9fdd355ab01eef17a605= 25fbd/README#L827 Best regards, Samuel Neves From nmavrogi@redhat.com Wed Sep 24 00:57:13 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 369911A8F3E for ; Wed, 24 Sep 2014 00:57:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.488 X-Spam-Level: X-Spam-Status: No, score=-1.488 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id beuHP9d9SF4g for ; Wed, 24 Sep 2014 00:57:12 -0700 (PDT) Received: from mx5-phx2.redhat.com (mx5-phx2.redhat.com [209.132.183.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A60F1A1BA7 for ; Wed, 24 Sep 2014 00:57:11 -0700 (PDT) Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx5-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8O7v84K011794; Wed, 24 Sep 2014 03:57:08 -0400 Date: Wed, 24 Sep 2014 03:57:07 -0400 (EDT) From: Nikos Mavrogiannopoulos To: Ryan Carboni Message-ID: <1853501534.36402020.1411545427606.JavaMail.zimbra@redhat.com> In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C71D2EDB3EDD@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D2EDB4132@USMBX1.msg.corp.akamai.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.6] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF29 (Linux)/8.0.6_GA_5922) Thread-Topic: Ciphersuite suggestion: add ISAAC Thread-Index: FrYm8PA/fbsfg9XydybBTY6mXaS6Sg== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/A7BJmsoAR9wvFuLk5UL9JpJZki0 Cc: tls@ietf.org Subject: Re: [TLS] Ciphersuite suggestion: add ISAAC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 24 Sep 2014 09:40:27 -0000 ----- Original Message ----- > https://en.wikipedia.org/wiki/ISAAC_%28cipher%29#Cryptanalysis > > Such irony, people have to be famous in the crypto community in order for > their ciphers to be adopted, in order to be famous one much have ciphers > adopted. That's not restricted to crypto community though; fame works one way or another, but the main drivers for such decisions are crypto competitions (e.g., AES, estream), and ISAAC hasn't been submitted to any. regards, Nikos From nobody Wed Sep 24 09:34:18 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 116F31A1B57 for ; Tue, 23 Sep 2014 14:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.678 X-Spam-Level: X-Spam-Status: No, score=0.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, FSL_HELO_BARE_IP_2=1, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_NUMERIC_HELO=1.164, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GmaZ5hIZuEZ for ; Tue, 23 Sep 2014 14:51:31 -0700 (PDT) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B887A1A1B44 for ; Tue, 23 Sep 2014 14:51:31 -0700 (PDT) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1XWXzd-000889-Lg for tls@ietf.org; Tue, 23 Sep 2014 23:51:29 +0200 Received: from 50.245.141.77 ([50.245.141.77]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 23 Sep 2014 23:51:29 +0200 Received: from eternaleye by 50.245.141.77 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 23 Sep 2014 23:51:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: tls@ietf.org From: Alex Elsayed Date: Tue, 23 Sep 2014 14:51:18 -0700 Lines: 61 Message-ID: References: <2A0EFB9C05D0164E98F19BB0AF3708C71D2EDB3EDD@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D2EDB4132@USMBX1.msg.corp.akamai.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8Bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: 50.245.141.77 User-Agent: KNode/4.13.1 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ihIEHf1a_ZfoUgVxzX9hhSMpQMY X-Mailman-Approved-At: Wed, 24 Sep 2014 09:34:17 -0700 Subject: Re: [TLS] Ciphersuite suggestion: add ISAAC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 23 Sep 2014 21:51:34 -0000 One can also gain credibility by breaking the ciphers of others, which provides a convincing argument that one understands the attacks and designed a cipher that doesn't fall to them easily. And an attack is an attack no matter who found it, so no catch-22 there. Ryan Carboni wrote: > https://en.wikipedia.org/wiki/ISAAC_%28cipher%29#Cryptanalysis > > Such irony, people have to be famous in the crypto community in order for > their ciphers to be adopted, in order to be famous one much have ciphers > adopted. > > On Tue, Sep 23, 2014 at 1:21 PM, Salz, Rich wrote: > >> I looked at the webpge you posted and it seemed like there was one paper >> by someone other than the author? And few will argue about djb’s >> credentials. >> >> >> >> More importantly, tho, is the AEAD issue. >> >> >> >> -- >> >> Principal Security Engineer, Akamai Technologies >> >> IM: rsalz@jabber.me Twitter: RichSalz >> >> >> >> *From:* Ryan Carboni [mailto:ryacko@gmail.com] >> *Sent:* Tuesday, September 23, 2014 4:18 PM >> *To:* Salz, Rich >> *Subject:* Re: [TLS] Ciphersuite suggestion: add ISAAC >> >> >> >> Has a decade of review. Does this mean ChaCha20 won't be adopted either? >> >> >> >> On Tue, Sep 23, 2014 at 7:27 AM, Salz, Rich wrote: >> >> It hasn’t had much review. And for TLS 1.3 we’re only doing AEAD types >> of ciphers. >> >> >> >> -- >> >> Principal Security Engineer, Akamai Technologies >> >> IM: rsalz@jabber.me Twitter: RichSalz >> >> >> From nobody Wed Sep 24 13:03:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E984A1A0406 for ; Wed, 24 Sep 2014 13:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.133 X-Spam-Level: ** X-Spam-Status: No, score=2.133 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FSL_HELO_BARE_IP_2=1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I-P6WHklgvh0 for ; Wed, 24 Sep 2014 13:03:00 -0700 (PDT) Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [69.93.243.4]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22E5A1A03A5 for ; Wed, 24 Sep 2014 13:02:50 -0700 (PDT) Received: by gateway09.websitewelcome.com (Postfix, from userid 507) id 61E7F58F5229B; Wed, 24 Sep 2014 15:02:49 -0500 (CDT) Received: from gator3286.hostgator.com (gator3286.hostgator.com [198.57.247.250]) by gateway09.websitewelcome.com (Postfix) with ESMTP id 3901B58F52212 for ; Wed, 24 Sep 2014 15:02:49 -0500 (CDT) Received: from [173.73.128.108] (port=56253 helo=192.168.1.7) by gator3286.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.82) (envelope-from ) id 1XWsm0-0001Zi-IM for tls@ietf.org; Wed, 24 Sep 2014 15:02:48 -0500 Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Sean Turner In-Reply-To: <92626AAF-4530-4E6F-BBC7-6219F316FB08@ieca.com> Date: Wed, 24 Sep 2014 16:02:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <92626AAF-4530-4E6F-BBC7-6219F316FB08@ieca.com> To: "TLS@ietf.org (tls@ietf.org)" X-Mailer: Apple Mail (2.1878.6) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator3286.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-IP: 173.73.128.108 X-Exim-ID: 1XWsm0-0001Zi-IM X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: (192.168.1.7) [173.73.128.108]:56253 X-Source-Auth: sean.turner@ieca.com X-Email-Count: 1 X-Source-Cap: ZG9tbWdyNDg7ZG9tbWdyNDg7Z2F0b3IzMjg2Lmhvc3RnYXRvci5jb20= Archived-At: http://mailarchive.ietf.org/arch/msg/tls/x5A9W0LADXXZjrpPLbQmViXSGyI Subject: [TLS] TLS Fall Interim (Paris edition) (was Re: fall interim attendance check) X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 24 Sep 2014 20:03:02 -0000 On Sep 17, 2014, at 12:32, Sean Turner wrote: > The chairs are concerned that the participation at the interim will be = low and may not be a good use of time. If you are planning to attend = the interim please send a message to the chairs to let them know. >=20 > J/S Even with my not so cheery msg, we=92ve confirmed that there=92s plenty = of interest in an interim meeting. See you in Paris! Alfredo has done a wonderful job with the wiki and has update it some = hotel information: = https://wiki.inria.fr/prosecco/IETF_TLS_Interim_October_2014#Accommodation= spt= From nobody Wed Sep 24 14:16:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE6BD1A02DA for ; Wed, 24 Sep 2014 14:16:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wrSEQOTas_1 for ; Wed, 24 Sep 2014 14:16:34 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 590621A0144 for ; Wed, 24 Sep 2014 14:16:34 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id d1so8185862wiv.15 for ; Wed, 24 Sep 2014 14:16:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=+gfXfmHVucG0SLJGY6RBkiFXdOuHrhA4LNJS0aCbkbU=; b=LM+sII87xfTbjdB3mM/HHPyscIo+GTNT8bbf6NY6j8y2T2BAIMxU2I1Liwvjz3vCeg XzjWQ858SrNE8AykASDyX8LVFMIK/qyVsrQ1mjzdnXQ/LMoZyS/PssSMdLi/SHXMH78Z NkOERkShJm9pQAVvId5tCvrKfVuxMEYIwieSseRLNkRZ1dfht69xVTM8YOuIz1qHcbaE Kw6t08/vjVaHkoAVnBDDjuQ593y0ziC7Ja9swtupfRTBkhXooP7i6UDQTGRcj2PU2AHC dsM6BaB/MKw/GLXdESghiIfd+vunhYYE21pt4BVRDUhaJpJ+jVD0y1Icya8SQDsNVsoA 5Nrw== X-Received: by 10.180.96.161 with SMTP id dt1mr34108817wib.1.1411593392963; Wed, 24 Sep 2014 14:16:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.66.225 with HTTP; Wed, 24 Sep 2014 14:15:52 -0700 (PDT) In-Reply-To: References: From: Ryan Carboni Date: Wed, 24 Sep 2014 14:15:52 -0700 Message-ID: To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=f46d04430688c14b370503d6325a Archived-At: http://mailarchive.ietf.org/arch/msg/tls/c0ZgvBfOr0GOQAMBA_KxaHLMcNI Subject: Re: [TLS] TLS Digest, Vol 122, Issue 60 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 24 Sep 2014 21:16:36 -0000 --f46d04430688c14b370503d6325a Content-Type: text/plain; charset=UTF-8 > > One can also gain credibility by breaking the ciphers of others, which > provides a convincing argument that one understands the attacks and > designed > a cipher that doesn't fall to them easily. Mr. Jenkins discovered some biases in RC4, and was one of the first to do so. --f46d04430688c14b370503d6325a Content-Type: text/html; charset=UTF-8
One can also gain credibility by breaking the ciphers of others, which
provides a convincing argument that one understands the attacks and designed
a cipher that doesn't fall to them easily.

Mr. Jenkins discovered some biases in RC4, and was one of the first to do so.
--f46d04430688c14b370503d6325a-- From nobody Wed Sep 24 18:44:56 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BADB1A6EFE for ; Wed, 24 Sep 2014 18:44:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KUFhlfAqCoVG for ; Wed, 24 Sep 2014 18:44:51 -0700 (PDT) Received: from mail-yh0-x22f.google.com (mail-yh0-x22f.google.com [IPv6:2607:f8b0:4002:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C00581A6EFC for ; Wed, 24 Sep 2014 18:44:51 -0700 (PDT) Received: by mail-yh0-f47.google.com with SMTP id t59so3845196yho.6 for ; Wed, 24 Sep 2014 18:44:51 -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=Ff99ac1adX0iJrwcO5IjkRBNM/N2UJ/wYoBEH040dIc=; b=Q0d/hAnGbW3YzuZWEt1Yo0QKP0E0ObvNofDR9Wb8teUKT4WdDH/OHS4SPa86ngAYSa r8TAN2c9nQDWPp9c2KD1vMlYm/D5Ytkl1ra8YWDb31LLU1RacrRZYTW2r/BPQpt99Roj jlbDKD5eQxZ2mUBIOMyF+6dv3QnKfvqki2WuQb/jXE7ZPDBxywmJgFTJCgmsk6qjaXjx ysk5OaGNp/hiGp8lixQZMpqqASxP+jSsI83gFvWpOKwpJKF+sACyHg8XOCntdnIw2Kmo ASEr3aoMUmQW9LvrcO/ELM4V9D7R5mq10a7RO91UHE3U9+us7goiFM1x5B1qzfhTLb4R ZxLA== MIME-Version: 1.0 X-Received: by 10.236.127.77 with SMTP id c53mr12156820yhi.40.1411609490871; Wed, 24 Sep 2014 18:44:50 -0700 (PDT) Received: by 10.170.207.216 with HTTP; Wed, 24 Sep 2014 18:44:50 -0700 (PDT) In-Reply-To: References: Date: Wed, 24 Sep 2014 18:44:50 -0700 Message-ID: From: Watson Ladd To: Ryan Carboni Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NNVAeaCDXUrCBjOc4kbgVUH6cYY Cc: "tls@ietf.org" Subject: Re: [TLS] Ciphersuite suggestion: add ISAAC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 25 Sep 2014 01:44:53 -0000 On Mon, Sep 22, 2014 at 11:46 PM, Ryan Carboni wrote: > It's slightly more secure then RC4, but much faster. > > http://burtleburtle.net/bob/rand/isaacafa.html Ok, why? This doesn't solve the RC4 problem, which is a problem with configurations of software that is past EOL. This cipher isn't faster than ChaCha20, and it's less studied and trusted then AES, or probably even Camelia. How many people are actually going to use it? What's the usecase for it? Sincerely, Watson Ladd > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Sep 25 02:23:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8AF31A1B7C for ; Thu, 25 Sep 2014 02:23:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.688 X-Spam-Level: X-Spam-Status: No, score=-7.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uvOTdt4Uoxv for ; Thu, 25 Sep 2014 02:23:46 -0700 (PDT) Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 482491A02ED for ; Thu, 25 Sep 2014 02:23:46 -0700 (PDT) Received: from zmail22.collab.prod.int.phx2.redhat.com (zmail22.collab.prod.int.phx2.redhat.com [10.5.83.26]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s8P9NiE6026798; Thu, 25 Sep 2014 05:23:44 -0400 Date: Thu, 25 Sep 2014 05:23:44 -0400 (EDT) From: Nikos Mavrogiannopoulos To: Ryan Carboni Message-ID: <525412655.36920496.1411637024435.JavaMail.zimbra@redhat.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.7] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF29 (Linux)/8.0.6_GA_5922) Thread-Topic: TLS Digest, Vol 122, Issue 60 Thread-Index: hnGbTmIp5mSWtBY6PIJmzAt/GsmoaA== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/8yXp-_fC5IRa68Y9pI0jors8R_4 Cc: tls@ietf.org Subject: Re: [TLS] TLS Digest, Vol 122, Issue 60 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 25 Sep 2014 09:23:49 -0000 ----- Original Message ----- > Mr. Jenkins discovered some biases in RC4, and was one of the first to do > so. I wouldn't even bother to reply that. He is well known in that field, and this isn't a popularity contest despite what it is often seen as. Ciphers nowdays get forward either because of international competitions organized by cryptographers, or national standards bodies. Chacha is an exception, because the CFRG adviced this working group to adopt it instead of the proposed Salsa20 (which was in the estream cipher portfolio), on the grounds that it the successor of it. regards, Nikos From nobody Thu Sep 25 02:25:40 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E9BE1A6EFB for ; Thu, 25 Sep 2014 02:25:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.599 X-Spam-Level: X-Spam-Status: No, score=-0.599 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VnJjOtwoTM2o for ; Thu, 25 Sep 2014 02:25:38 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAA451A1A8A for ; Thu, 25 Sep 2014 02:25:37 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id p10so7143338wes.17 for ; Thu, 25 Sep 2014 02:25:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=t+46hHcBXUva92yK41D0NFeVf9jXBOtAvnXGxsrrYCY=; b=yTJ6kBiUhmVmfGGNAN4a64EVMV4aTxaBPOzjK4EC/jLyvzaWEQfLQDEtN8fDaDnPzv 1RIBTyD8g1iE6JdwCQmJr+FwAJrcLqAW34Mfa8f5omkW7t3olGwtuxj6gw1/vZgsrkmc MQxWNextHz0gm4VGmRLPdI67Z6+oaXj3pdgAr35DpqetKTiFGe4vjrMqvLqzOLrUuKfA zIgHKymPwFiI5TzI1IuAWhiNS7nq0ndlOK1F00birLuEOMSFG+LZSKcew1GMiTOF84R9 RbrljnnHx1sQYbQs+G7LfElHiIFpFr9SDsoYdw4j0ROlOCr6qque6kS51AZ6NRWyzze4 lEOA== X-Received: by 10.180.89.243 with SMTP id br19mr37802568wib.41.1411637136501; Thu, 25 Sep 2014 02:25:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.66.225 with HTTP; Thu, 25 Sep 2014 02:24:56 -0700 (PDT) In-Reply-To: References: From: Ryan Carboni Date: Thu, 25 Sep 2014 02:24:56 -0700 Message-ID: To: Watson Ladd Content-Type: multipart/alternative; boundary=e89a8f3ba24d12b6060503e06267 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/UgDX6SUr-_7rD7OsgDehdmctuno Cc: "tls@ietf.org" Subject: Re: [TLS] Ciphersuite suggestion: add ISAAC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 25 Sep 2014 09:25:39 -0000 --e89a8f3ba24d12b6060503e06267 Content-Type: text/plain; charset=UTF-8 It's five instructions per byte (half a cycle on most processors). Or 18.75 instructions per 32-bit word. How can ChaCha20 possibly be faster? Or are you confusing instructions with cycles? How does ChaCha20 solve the RC4 problem, unless it's easier to flash firmware to add ChaCha20? This whole argument is illogical, ISAAC is equally as viable as ChaCha20, and half of all crypto is a vicious cycle in which the more known something is, the more cryptanalysis is attempted against it. Furthermore, what if cryptographers glanced at it, and gave up? It is easier to crack a single round of ChaCha20, whereas ISAAC has a single round like RC4. It is inherently more difficult to break single round ciphers because you have to break the single round, you can't break it partially. On Wed, Sep 24, 2014 at 6:44 PM, Watson Ladd wrote: > On Mon, Sep 22, 2014 at 11:46 PM, Ryan Carboni wrote: > > It's slightly more secure then RC4, but much faster. > > > > http://burtleburtle.net/bob/rand/isaacafa.html > > Ok, why? > > This doesn't solve the RC4 problem, which is a problem with > configurations of software that is past EOL. This cipher isn't faster > than ChaCha20, and it's less studied and trusted then AES, or probably > even Camelia. How many people are actually going to use it? What's the > usecase for it? > > Sincerely, > Watson Ladd > > > > _______________________________________________ > > TLS mailing list > > TLS@ietf.org > > https://www.ietf.org/mailman/listinfo/tls > > > > > > -- > "Those who would give up Essential Liberty to purchase a little > Temporary Safety deserve neither Liberty nor Safety." > -- Benjamin Franklin > --e89a8f3ba24d12b6060503e06267 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It's five instructions per byte (half a cycl= e on most processors). Or 18.75 instructions per 32-bit word. How can ChaCh= a20 possibly be faster? Or are you confusing instructions with cycles?
<= br>How does ChaCha20 solve the RC4 problem, unless it's easier to flash= firmware to add ChaCha20?

This whole argument is illogical, I= SAAC is equally as viable as ChaCha20, and half of all crypto is a vicious = cycle in which the more known something is, the more cryptanalysis is attem= pted against it.

Furthermore, what if cryptographers glanced a= t it, and gave up? It is easier to crack a single round of ChaCha20, wherea= s ISAAC has a single round like RC4. It is inherently more difficult to bre= ak single round ciphers because you have to break the single round, you can= 't break it partially.

On Wed, Sep 24, 2014 at 6:44 PM, Watson Ladd <wat= sonbladd@gmail.com> wrote:
= On Mon, Sep 22, 2014 at 11:46 PM, Ryan Carboni <ryacko@gmail.com> wrote:
> It's slightly more secure then RC4, but much faster.
>
> http://burtleburtle.net/bob/rand/isaacafa.html

Ok, why?

This doesn't solve the RC4 problem, which is a problem with
configurations of software that is past EOL. This cipher isn't faster than ChaCha20, and it's less studied and trusted then AES, or probably<= br> even Camelia. How many people are actually going to use it? What's the<= br> usecase for it?

Sincerely,
Watson Ladd
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>



--
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither=C2=A0 Liberty nor Safety."
-- Benjamin Franklin

--e89a8f3ba24d12b6060503e06267-- From nobody Thu Sep 25 02:31:06 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4489C1A1C03 for ; Thu, 25 Sep 2014 02:31:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gCB0yQxc0VS9 for ; Thu, 25 Sep 2014 02:31:03 -0700 (PDT) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15C661A1BA7 for ; Thu, 25 Sep 2014 02:31:02 -0700 (PDT) Received: by mail-wi0-f170.google.com with SMTP id fb4so7949043wid.3 for ; Thu, 25 Sep 2014 02:31:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=iIxblotsz2PkGHHy/39Y9CUjgwPN0q9uABf7JV/y45w=; b=LFax7URPolkSnjDpfOhVYUf8z30af8o3zK9Zn5cSpIq8aJW54uilqJHLxUMsVyQglz Ywq1U4JBoHjVokpqFFXQ99kZUE6NbedLE8PkEWFcrFyTvjxjTdkruU5ZvWZIRkBFMEtB TsEzN851iB3h6A7d8Oaax27W8A/WtCAnX+IVXnO3lbR0EvHjcpr5fNqAYjWMi4pAYyFa 6N/DcvntzXR2mYzp5mE3La04UEmT8D/voxlww0otjHX+iXUkwXUeF3xX6knPQFnRuias 3yuP3FRoIPJcH8yzPPjGNGbC4OUZsJ9PPJ6oEfe5/E0H02Z37eiexyB+fPsd0SFuXaEq V2zA== X-Received: by 10.180.99.195 with SMTP id es3mr36216401wib.33.1411637461381; Thu, 25 Sep 2014 02:31:01 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.66.225 with HTTP; Thu, 25 Sep 2014 02:30:20 -0700 (PDT) In-Reply-To: <525412655.36920496.1411637024435.JavaMail.zimbra@redhat.com> References: <525412655.36920496.1411637024435.JavaMail.zimbra@redhat.com> From: Ryan Carboni Date: Thu, 25 Sep 2014 02:30:20 -0700 Message-ID: To: Nikos Mavrogiannopoulos , "tls@ietf.org" Content-Type: multipart/alternative; boundary=f46d04426f9c6ffae30503e075f4 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/FxlmKEeN7yuI0W6fDNdh1DIy76o Subject: Re: [TLS] TLS Digest, Vol 122, Issue 60 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 25 Sep 2014 09:31:04 -0000 --f46d04426f9c6ffae30503e075f4 Content-Type: text/plain; charset=UTF-8 Just noticed this email. I see. On Thu, Sep 25, 2014 at 2:23 AM, Nikos Mavrogiannopoulos wrote: > ----- Original Message ----- > > Mr. Jenkins discovered some biases in RC4, and was one of the first to do > > so. > > I wouldn't even bother to reply that. He is well known in that field, and > this isn't a popularity contest despite what it is often seen as. Ciphers > nowdays get forward either because of international competitions organized > by cryptographers, or national standards bodies. Chacha is an exception, > because the CFRG adviced this working group to adopt it instead of the > proposed Salsa20 (which was in the estream cipher portfolio), on the > grounds > that it the successor of it. > > regards, > Nikos > --f46d04426f9c6ffae30503e075f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Just noticed this email. I see.

On Thu, Sep 25, 2014 at 2:23 AM, N= ikos Mavrogiannopoulos <nmav@redhat.com> wrote:
----- Original Message -----
> Mr. Jenkins discovered some biases in RC4, and was one of the first to= do
> so.

I wouldn't even bother to reply that. He is well known in that f= ield, and
this isn't a popularity contest despite what it is often seen as. Ciphe= rs
nowdays get forward either because of international competitions organized<= br> by cryptographers, or national standards bodies. Chacha is an exception, because the CFRG adviced this working group to adopt it instead of the
proposed Salsa20 (which was in the estream cipher portfolio), on the ground= s
that it the successor of it.

regards,
Nikos

--f46d04426f9c6ffae30503e075f4-- From nobody Thu Sep 25 04:43:36 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC02A1A1A76 for ; Thu, 25 Sep 2014 04:43:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.798 X-Spam-Level: X-Spam-Status: No, score=0.798 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PnQ7ml0_-B56 for ; Thu, 25 Sep 2014 04:43:31 -0700 (PDT) Received: from entima.net (entima.net [78.129.143.175]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5779A1A1A5E for ; Thu, 25 Sep 2014 04:43:31 -0700 (PDT) User-Agent: K-9 Mail for Android In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Alyssa Rowan Date: Thu, 25 Sep 2014 12:43:28 +0100 To: tls@ietf.org Message-ID: <12753c9b-6f9b-44d9-86b3-a443a68dc3ab@email.android.com> Archived-At: http://mailarchive.ietf.org/arch/msg/tls/e4lJkNq4NpTXCdS0gIy-yAOEpJg Subject: Re: [TLS] Ciphersuite suggestion: add ISAAC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 25 Sep 2014 11:43:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Please forgive my extreme brevity; limited time. On 25 September 2014 10:24:56 BST, Ryan Carboni wrote: >How can ChaCha20 possibly be faster? ChaCha20: Pipelining. Vectorisation. Parallelisation. Random-access. ISAAC: pipeline stalls, single-threaded, dependency on big state. >How does ChaCha20 solve the RC4 problem, unless it's easier to flash firmware to add ChaCha20? Problem: RC4. Solution: use something better. Not convinced ISAAC is better. >This whole argument is illogical, ISAAC is equally as viable as ChaCha20, I disagree. It's just a keystream generator as specified? Where's the cryptovariable=>state key setup/schedule to be used? Huge security impact. Is it the prototype one suggested? Where's the AEAD based on it? ISAAC didn't win any competition, nor is it a successor to anything that did. I also think it's a bit too similar to RC4, which is a potential negative: might a successful attack against RC4 impact it? >It is easier to crack a single round of ChaCha20, whereas ISAAC has a single round like RC4. Apples::Oranges. ChaCha20 has 20 rounds and no attack known which weakens 7; ISAAC has only one basket, and all its eggs in it. See below. >It is inherently more difficult to break single round ciphers because you have to break the single round, you can't break it partially. Lack of any reduced-round variants significantly complicates cryptanalysis, as you see demonstrated above: I see this is a big negative factor, as it's harder to analyse, compare and assess the security margin. I really don't find any aspect of it compelling or attractive. Sorry. - -- /akr -----BEGIN PGP SIGNATURE----- Version: APG v1.1.1 iQI3BAEBCgAhBQJUI//fGhxBbHlzc2EgUm93YW4gPGFrckBha3IuaW8+AAoJEOyE jtkWi2t6RFUQAKOcUdwQrqlGgUHl/nVPfsAeeFopGzNMz48NyNQ7pEnf5JLejXct V2JD9v25w80zNEEsOC6iBF7Obk1ibkcKTQxg9Nu3w7imJxDHxIIPGbuR3FdnTXQr G3DZ36yL/ZB6/QXFF6/31oEHyJTJ+WGdbYJbnyYXbdWgk6yizHYEQ+xmXyoGFf52 LtVITIUamayFAH5UIkBCae24dxlULpgnpI/8KYjA4m69q75KlrFaLXICOqwSdIlZ w+HezYeNt2cwWtfsD5iQgKrt5BTzZPfWqiU3Kno6AKlkSIs0kGNoqg9TTYD/FNdv 63PrX4wM2jQrIP4Q5tgHSAaN5ACjxGg6k3qPLbMf+eLAcXDj7jqesuf8mt58PtZL 6lq0TJS5WETC7xJOVZrFqVH0NtfSLH60yChPpIihy2uRCd6F65Kuk5nQXH4C4i7m E9MihS/LdOtcCw3qRmshy1E3a7+lkYsoHk9jBY1tTWlWY3T7fv8am45FHaqmWrFM pF3OuMp7bGmiOqSKSCQ9tqy9hvIPKf0Re6fozbdufHMvKOZ+I1VvypwtSz7HH1ul g/Qud7SHCMgRrSWQZ6lb2lLsAfHhXcPqAl2oUKz7WWae/ZXNoInW8bAFMSJ8AHxm X+d1OFm3S3dZznL+iu8hHHh1jwJSBtGZxYB2U/BB+Ei2LJPYGTUPTqRw =vtK3 -----END PGP SIGNATURE----- From nobody Thu Sep 25 14:11:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C57D1A0406 for ; Thu, 25 Sep 2014 14:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.688 X-Spam-Level: X-Spam-Status: No, score=-7.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ipxB24ySxeVr for ; Thu, 25 Sep 2014 14:11:55 -0700 (PDT) Received: from mx4-phx2.redhat.com (mx4-phx2.redhat.com [209.132.183.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07C9A1A0371 for ; Thu, 25 Sep 2014 14:11:54 -0700 (PDT) Received: from zmail11.collab.prod.int.phx2.redhat.com (zmail11.collab.prod.int.phx2.redhat.com [10.5.83.13]) by mx4-phx2.redhat.com (8.13.8/8.13.8) with ESMTP id s8PLBqce024314; Thu, 25 Sep 2014 17:11:52 -0400 Date: Thu, 25 Sep 2014 17:11:52 -0400 (EDT) From: Hubert Kario To: Ryan Carboni Message-ID: <147123008.1354571.1411679512636.JavaMail.zimbra@redhat.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [10.5.82.7] X-Mailer: Zimbra 8.0.6_GA_5922 (ZimbraWebClient - FF32 (Linux)/8.0.6_GA_5922) Thread-Topic: Ciphersuite suggestion: add ISAAC Thread-Index: O0WZdpW7UBU3aTwk6VVCC/vxnoB7Gw== Archived-At: http://mailarchive.ietf.org/arch/msg/tls/5ZZ9SuJ396Zdhg9r6cMJoczDSbE Cc: tls@ietf.org Subject: Re: [TLS] Ciphersuite suggestion: add ISAAC X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 25 Sep 2014 21:11:56 -0000 ----- Original Message ----- > From: "Ryan Carboni" > To: "Watson Ladd" > Cc: tls@ietf.org > Sent: Thursday, 25 September, 2014 11:24:56 AM > Subject: Re: [TLS] Ciphersuite suggestion: add ISAAC > half of all crypto is a vicious cycle in which the more known something is, > the more cryptanalysis is attempted against it. and how is that a bad thing? the more a cipher is used, the better verified we want it to be cryptographers have limited time, so it's better if they concentrate it on most widely used algorithms not do just a cursory verification of every cipher in existence -- Regards, Hubert Kario From nobody Thu Sep 25 17:38:04 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D94F31A0076 for ; Thu, 25 Sep 2014 17:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g3_PQgom7W4s for ; Thu, 25 Sep 2014 17:38:01 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BA961A00B2 for ; Thu, 25 Sep 2014 17:37:59 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id gi9so3295261lab.19 for ; Thu, 25 Sep 2014 17:37:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=OucHJb7ULkCtTz7SV+/0sNNtVM1l23d2WiXLHstJJWg=; b=gXJQIAS6sEqRT9ftERzzpfJqLs8wuSnvH2x9OV5vUzlmPQiNXw9a1AbEB0tr+ZiXhI b/hW6nvl0ftNxnFB8QI3X++dwPe9c53PgVq83mW5D97AZsFIkElljOBOn+i6gv7v6NqR tStOuS0fn16bxARrXVP4pGkcmwEul4wllEv7K5hZM/QrTxwIvPUFiSepzuKL14Q2z6Ma MTCtOPc+1tX27AzhLHgOrvQgU4dwaYaEDWD6il0gBVxdwvVFSGaw09+nXceGcbymBXlG ZQYqfYqXe1iMZiTKe4JN1hrwRKyRaC/AY1xIActRiTYaNkSz3cH0hYJ96I6Q03gjNpLZ eN9A== MIME-Version: 1.0 X-Received: by 10.152.42.194 with SMTP id q2mr3563443lal.75.1411691878432; Thu, 25 Sep 2014 17:37:58 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.241.103 with HTTP; Thu, 25 Sep 2014 17:37:58 -0700 (PDT) In-Reply-To: <540F543E.8080505@cs.tcd.ie> References: <462E2EC4-A285-4D02-9156-D8C94D6BE107@cisco.com> <1D2C7BAF-A3EF-45B8-87EB-EB4DFD2C3C7F@cisco.com> <540F543E.8080505@cs.tcd.ie> Date: Thu, 25 Sep 2014 17:37:58 -0700 X-Google-Sender-Auth: _dphnAw7rFdFPn5jNEDY8JxFHdo Message-ID: From: Adam Langley To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/IMvh5iZtE8CTNgcRy1P8kwlRj6E Cc: "tls@ietf.org" Subject: Re: [TLS] Early code-point assignment for draft-ietf-tls-session-hash X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 26 Sep 2014 00:38:03 -0000 On Tue, Sep 9, 2014 at 12:25 PM, Stephen Farrell wrote: > I've now gotten to that and plan to approve this early > allocation. Be great if the wg can finish up the draft > soon too - there's a 1 year timer that starts when IANA > do the allocation. Any signs of this early allocation? I don't see anything on the IANA pages. Cheers AGL From nobody Thu Sep 25 17:53:22 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3FE1A00A3; Thu, 25 Sep 2014 17:53:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e26smijIglLv; Thu, 25 Sep 2014 17:53:17 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CB8A71A0076; Thu, 25 Sep 2014 17:53:17 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140926005317.27088.57940.idtracker@ietfa.amsl.com> Date: Thu, 25 Sep 2014 17:53:17 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/yllh0L9dK8SfgJGgTD9GdRzr5T0 Cc: tls@ietf.org Subject: [TLS] I-D Action: draft-ietf-tls-pwd-05.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 List-Id: "This 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, 26 Sep 2014 00:53:19 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Transport Layer Security Working Group of the IETF. Title : Secure Password Ciphersuites for Transport Layer Security (TLS) Authors : Dan Harkins Dave Halasz Filename : draft-ietf-tls-pwd-05.txt Pages : 35 Date : 2014-09-25 Abstract: This memo defines several new ciphersuites for the Transport Layer Security (TLS) protocol to support certificate-less, secure authentication using only a simple, low-entropy, password. The ciphersuites are all based on an authentication and key exchange protocol that is resistant to off-line dictionary attack. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tls-pwd/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-tls-pwd-05 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-pwd-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Sep 25 17:58:02 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 325E71A01D8; Thu, 25 Sep 2014 17:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xok3PV2_C9gC; Thu, 25 Sep 2014 17:57:57 -0700 (PDT) Received: from mail-qc0-x22f.google.com (mail-qc0-x22f.google.com [IPv6:2607:f8b0:400d:c01::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 884951A01AE; Thu, 25 Sep 2014 17:57:57 -0700 (PDT) Received: by mail-qc0-f175.google.com with SMTP id o8so5921515qcw.34 for ; Thu, 25 Sep 2014 17:57:56 -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=qkaGbe9HqWd/dAbpXOcfWC4Eh7sTjjrZyG37QJLnOgU=; b=BwHh7taVrUcDQYuem7qMzlP8IGWkODENwh5m5U64+EW2d7y4Z8SlyH1UxL72j0QZ1P 4bEO5HXmOJLBnw3ky35ULgSKd9m8r9XCqVBWPRJAQ/iu7Ow9Bhs0CIgdMVceep8NQXaP 0UfPuIw3PISVESnrOhtmCMiE7VdRpspzEHae2aGNU3ssw2iNldaZ0+wP4IFbYNKP3vyz LmtcxacEvMTeWya1xInLWNAdfdIQ6B+IDa+anx1LOPgWtrUEkkKn0gPKpMNC7ZyWwf+j 5PkBkP7SIT9UmZpY7mojw2Gt8oipVELIKCPYuBX77WrXql4q9s3qHGwwiQgEoi5iN1Ef ek/A== MIME-Version: 1.0 X-Received: by 10.140.85.112 with SMTP id m103mr26840414qgd.50.1411693076551; Thu, 25 Sep 2014 17:57:56 -0700 (PDT) Received: by 10.140.20.199 with HTTP; Thu, 25 Sep 2014 17:57:56 -0700 (PDT) In-Reply-To: <20140926005317.27088.57940.idtracker@ietfa.amsl.com> References: <20140926005317.27088.57940.idtracker@ietfa.amsl.com> Date: Thu, 25 Sep 2014 17:57:56 -0700 Message-ID: From: Watson Ladd To: internet-drafts@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-v_6zxD9HdJfdE2XQi1i3vB4sFo Cc: "tls@ietf.org" , i-d-announce@ietf.org Subject: Re: [TLS] I-D Action: draft-ietf-tls-pwd-05.txt X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 26 Sep 2014 00:58:00 -0000 On Thu, Sep 25, 2014 at 5:53 PM, wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Transport Layer Security Working Group of the IETF. > > Title : Secure Password Ciphersuites for Transport Layer Security (TLS) > Authors : Dan Harkins > Dave Halasz > Filename : draft-ietf-tls-pwd-05.txt > Pages : 35 > Date : 2014-09-25 > > Abstract: > This memo defines several new ciphersuites for the Transport Layer > Security (TLS) protocol to support certificate-less, secure > authentication using only a simple, low-entropy, password. The > ciphersuites are all based on an authentication and key exchange > protocol that is resistant to off-line dictionary attack. The protocol is still not proven secure. The author of the draft has refused to change this in the past year. I see no reason why a protocol like Dragonfly should be used instead of a secure password protocol. Sincerely, Watson Ladd > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tls-pwd/ > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-tls-pwd-05 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-tls-pwd-05 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls -- "Those who would give up Essential Liberty to purchase a little Temporary Safety deserve neither Liberty nor Safety." -- Benjamin Franklin From nobody Thu Sep 25 21:00:33 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F6BB1A00B0 for ; Thu, 25 Sep 2014 21:00:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1B2QyAkY4s-L for ; Thu, 25 Sep 2014 21:00:27 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 699D41A0439 for ; Thu, 25 Sep 2014 21:00:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=214; q=dns/txt; s=iport; t=1411704027; x=1412913627; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=0vKl61wX9qhJcNqC2XAJsAkioks2xlXE939XlEbL0j8=; b=LI840RsTkQMgR9NvZfmlAkgSPKZOi9PouGKiFBcLkaKUWQ8Yo4N8guGq Ygp9q13zgrL/lDWs8RcfqLepUlq8YF1Ay1bQaS2fjE1Yt0VNMZ8pkPfve igN0xWLCQyuTWY7HVspfK2rJ/uaFIJil1SvmbR72IPZwJzbcvFXpE/LPg Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAJLkJFStJV2Z/2dsb2JhbABggw6BLo1KxC2BDhYBe4QKHR1RAT5CJwSIUZwEpUQBF5NTgR0FkWCLQ5VWg2OCNIECAQEB X-IronPort-AV: E=Sophos;i="5.04,603,1406592000"; d="scan'208";a="358342459" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-8.cisco.com with ESMTP; 26 Sep 2014 04:00:05 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s8Q405pm002051 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 26 Sep 2014 04:00:05 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.15]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0195.001; Thu, 25 Sep 2014 23:00:04 -0500 From: "Joseph Salowey (jsalowey)" To: "" Thread-Topic: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00 Thread-Index: AQHP2T5a8EAtsaADg0ykrefiCf9Yjw== Date: Fri, 26 Sep 2014 04:00:04 +0000 Message-ID: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.136] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EXbip7INNBjnihvO8f3j9mQ7GbY Subject: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 26 Sep 2014 04:00:31 -0000 This is an announcement for the working group last call for draft-ietf-tls-= downgrade-scsv-00. Please review the document and send your comments to th= e list by Friday, October 17, 2014. =20 Thanks, J&S= From nobody Thu Sep 25 23:00:20 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34EF41A1A22 for ; Thu, 25 Sep 2014 23:00:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5nI2j7SVhBM for ; Thu, 25 Sep 2014 23:00:15 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5141A1A1E for ; Thu, 25 Sep 2014 23:00:14 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9ED56BEBE; Fri, 26 Sep 2014 07:00:12 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7qRw59kGQMG; Fri, 26 Sep 2014 07:00:06 +0100 (IST) Received: from [192.168.51.37] (business-176-094-121-250.static.arcor-ip.net [176.94.121.250]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 22CB7BDCA; Fri, 26 Sep 2014 07:00:06 +0100 (IST) User-Agent: K-9 Mail for Android In-Reply-To: References: <462E2EC4-A285-4D02-9156-D8C94D6BE107@cisco.com> <1D2C7BAF-A3EF-45B8-87EB-EB4DFD2C3C7F@cisco.com> <540F543E.8080505@cs.tcd.ie> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=UTF-8 From: Stephen Farrell Date: Fri, 26 Sep 2014 07:59:59 +0200 To: Adam Langley Message-ID: <1178ec28-4edf-455f-ba35-1640e7374b16@email.android.com> Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EPwGGeLB0ad-PolrZl097dsv5TA Cc: "tls@ietf.org" Subject: Re: [TLS] Early code-point assignment for draft-ietf-tls-session-hash X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 26 Sep 2014 06:00:18 -0000 On 26 September 2014 02:37:58 CEST, Adam Langley wrote: >On Tue, Sep 9, 2014 at 12:25 PM, Stephen Farrell > wrote: >> I've now gotten to that and plan to approve this early >> allocation. Be great if the wg can finish up the draft >> soon too - there's a 1 year timer that starts when IANA >> do the allocation. > >Any signs of this early allocation? I don't see anything on the IANA >pages. That's my fault - I sent the request to the wrong alias but I fixed it yesterday when someone else pinged me so iana have it in hand now. Should be done real soon. S. > >Cheers > >AGL From nobody Thu Sep 25 23:41:49 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10EA71A1A4B for ; Thu, 25 Sep 2014 23:41:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q29Bv9IElcwK for ; Thu, 25 Sep 2014 23:41:44 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F7C31A1A32 for ; Thu, 25 Sep 2014 23:41:44 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id hz20so14146664lab.29 for ; Thu, 25 Sep 2014 23:41:42 -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=eDjbCanHLde4eI37nSKoKnO1eLdSSg7dudQzc3XIVRo=; b=ObOJhfz8S93ZElnNsFb3x2xVhr82HIEVtEC25+n6mp9f2y0DQusRlWHA/JR//5TGxK LdnbJMGQLs4tzV9wEf+IuWwfZVVaBeJRf7pKmaw7FPkt2Mt3B70yhuFLYNaM04yzs8ov YnGogRI58S2/DAQtDb36pqEcVWb4cpsMMnFjLjUBOlniWDK/5wqPVuMq/bzSxAOhM1Pt uicvtVbFuuAW/SwqWa7X/CPdHRjHBjyq5/bsg2ldy8Q4+6XMuwM1l8f2pWeWQjRbksjn vdIIOlrx6OLg5NTVmuueGUYltmHHIyzDLbDnhNqQDKw/1IkramEu9gfff3gZS/aNlgzE /HnQ== MIME-Version: 1.0 X-Received: by 10.112.34.78 with SMTP id x14mr2511611lbi.38.1411713702449; Thu, 25 Sep 2014 23:41:42 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Thu, 25 Sep 2014 23:41:42 -0700 (PDT) In-Reply-To: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> Date: Fri, 26 Sep 2014 07:41:42 +0100 Message-ID: From: Martin Thomson To: "Joseph Salowey (jsalowey)" Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fVuDzk3EPV-Bt_oVR84yRGCIfpo Cc: "" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 26 Sep 2014 06:41:47 -0000 On 26 September 2014 05:00, Joseph Salowey (jsalowey) wrote: > This is an announcement for the working group last call for draft-ietf-tls-downgrade-scsv-00. Please review the document and send your comments to the list by Friday, October 17, 2014. I've implemented this specification, and it's available in Firefox nightly builds. I found no issues with implementing from the draft. It's basically ready. I have one very minor concern. The exception in Section 4 implies that there is some interoperability reason to avoid including the SCSV in a resumption request. I think that it would be better if the actual interoperability problem. That is, your original session was made to a server instance that only had a lower version and is being resumed on an instance that has a higher version AND the node with the higher version doesn't treat a resumed handshake differently with respect to the handling of the SCSV. Alternatively, the server could have been updated since the original session was established. After some consideration, I think that the only issue with resumption is that it is somewhat wasteful. Requiring servers to ignore the SCSV on resumption would work equally well. I have a few minor editorial nits: - the lists in Sections 3 & 4 have a single item, which is a little odd - Section 4 should just say when to use the SCSV, rather than announce "This section specifies when to send it." From nobody Fri Sep 26 00:02:05 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F9771A1A62 for ; Fri, 26 Sep 2014 00:02:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8YFus29w5lzD for ; Fri, 26 Sep 2014 00:01:58 -0700 (PDT) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C294B1A1A5A for ; Fri, 26 Sep 2014 00:01:57 -0700 (PDT) Received: by mail-lb0-f180.google.com with SMTP id f15so478350lbj.39 for ; Fri, 26 Sep 2014 00:01:56 -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=7LytECela3Yc+i2pFQN0cJMq4ZsNIgRhcFMVPZ1r1NM=; b=XuHy5qYnAGdvZbc84xEUISkx6ljph9qEJwqYvlzaGYLZkemCcfb0OsagA8ejGilcjX Ln7+6jKPduj8Gjznhd9AOPqyaBq6ovEtJRVd+ORSoCV6d91PC85yNoG6aSYvsHeXcdNX 4tX6fXViIhpXJ6+eJsWvsSoJvMnugsbGfkRwoKFcxHanWmhuYE0VUkb6N+jUm/lM6PFB Yv+pWPcR7MVS6iekRQWU9c+vD4p2xa7EqHmY49fIUvGTZBmH0hICXVZugwoD7fda67nz aekLeqOSECwShK6oB9e7RZJwW018BnuRdrhXK7awJLHKpL/F64SL2BjTe42uAlLMHMsF K6MQ== MIME-Version: 1.0 X-Received: by 10.152.36.4 with SMTP id m4mr18223759laj.17.1411714916026; Fri, 26 Sep 2014 00:01:56 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Fri, 26 Sep 2014 00:01:55 -0700 (PDT) In-Reply-To: References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> Date: Fri, 26 Sep 2014 08:01:55 +0100 Message-ID: From: Martin Thomson To: Bodo Moeller Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/wkVRSIB-QfcvPix4YqujXh_9jK8 Cc: "" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 26 Sep 2014 07:02:02 -0000 On 26 September 2014 07:54, Bodo Moeller wrote: > What specifically do you consider wasteful? 16 bits, that's all. Not a big deal (unless you are close to having to pad...) > Note that ignoring the SCSV *on resumption* wouldn't quite work. The server > would need to ignore the SCSV on resumption *attempts*, successful or not; I > don't think I'd like that. The draft requires that downgrade on resumption attempts (yes, you are completely correct) is not guarded. Whether that's a requirement on the server or client doesn't seem like a big deal to me. From SRS0=QEdY=6T=acm.org=bmoeller@srs.kundenserver.de Thu Sep 25 23:54:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AAAEC1A1A5A for ; Thu, 25 Sep 2014 23:54:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.714 X-Spam-Level: X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHYhvaiwmwW7 for ; Thu, 25 Sep 2014 23:54:30 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47F7E1A1A43 for ; Thu, 25 Sep 2014 23:54:30 -0700 (PDT) Received: from mail-yk0-f170.google.com (mail-yk0-f170.google.com [209.85.160.170]) by mrelayeu.kundenserver.de (node=mreue101) with ESMTP (Nemesis) id 0Lecog-1Y42DF1dk6-00qV3u; Fri, 26 Sep 2014 08:54:27 +0200 Received: by mail-yk0-f170.google.com with SMTP id 19so3679569ykq.15 for ; Thu, 25 Sep 2014 23:54:26 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.122.70 with SMTP id s46mr17827861yhh.52.1411714466154; Thu, 25 Sep 2014 23:54:26 -0700 (PDT) Received: by 10.170.194.15 with HTTP; Thu, 25 Sep 2014 23:54:26 -0700 (PDT) In-Reply-To: References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> Date: Fri, 26 Sep 2014 08:54:26 +0200 Message-ID: From: Bodo Moeller To: Martin Thomson Content-Type: multipart/alternative; boundary=20cf3003bd844793ea0503f263c0 X-Provags-ID: V02:K0:Vx9j010HFs8dlCM1+XIN+7J6Gh/4qMKipj6yCBpMlON LZ2q5sZm8nuMN5aqcs3sbOHvk8ASp3igy2Wi9noGPWEkbBb/+2 ixHSuxALrJ2RZf4p+Feh82ZIiLaiCaA09Yb83Cyzp6Hhiz191k BUwrdDFwBsCv2hRiwL2P6qGu0U2Nrv1bSf4+Cd2rh7xZgxxZT8 d8OkN/zecoacvbYmJYFwBpauUodWOc4e+AYP4Prb7TeVsf8T3I LJd+biGX4AtwtZJEGVTiRL5wIuKzQoeLlELDt9Qa+smAL+v03b zeMiUTluWBNQfi8NuH7O/WWwNf9IkA0Appnv45KZv1suG1C/Mi VPC2cfqWP7aA6YgAI4RF/ecH3Mh17GcSkao5Ifq/Yg9RrckEof J+u0xm8D0ARPbITNo2G/GDCiR1jhvD2Wzm77s3Gz9/vOlHvPjw P9fJw X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/NyB0pkH99v_suDLFCWHWMmfRIwU Cc: "" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 26 Sep 2014 07:02:24 -0000 --20cf3003bd844793ea0503f263c0 Content-Type: text/plain; charset=UTF-8 Martin Thomson : The exception in Section 4 implies that there is some interoperability > reason to avoid including the SCSV in a resumption request. I think > that it would be better if the actual interoperability problem. I think it would be better if the verb :-) > That > is, your original session was made to a server instance that only had > a lower version and is being resumed on an instance that has a higher > version AND the node with the higher version doesn't treat a resumed > handshake differently with respect to the handling of the SCSV. > Alternatively, the server could have been updated since the original > session was established. > > After some consideration, I think that the only issue with resumption > is that it is somewhat wasteful. Requiring servers to ignore the SCSV > on resumption would work equally well. > What specifically do you consider wasteful? Note that ignoring the SCSV *on resumption* wouldn't quite work. The server would need to ignore the SCSV on resumption *attempts*, successful or not; I don't think I'd like that. I have a few minor editorial nits: > - the lists in Sections 3 & 4 have a single item, which is a little odd > - Section 4 should just say when to use the SCSV, rather than > announce "This section specifies when to send it." > ACK. Bodo --20cf3003bd844793ea0503f263c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mart= in Thomson <martin.thomson@gmail.com>:

The exception in Section 4 implies that there is some interoperability
reason to avoid including the SCSV in a resumption request.=C2=A0 I think that it would be better if the actual interoperability problem.

I think it would be better if the verb :-)
= =C2=A0
That
is, your original session was made to a server instance that only had
a lower version and is being resumed on an instance that has a higher
version AND the node with the higher version doesn't treat a resumed handshake differently with respect to the handling of the SCSV.
Alternatively, the server could have been updated since the original
session was established.

After some consideration, I think that the only issue with resumption
is that it is somewhat wasteful.=C2=A0 Requiring servers to ignore the SCSV=
on resumption would work equally well.

= What specifically do you consider wasteful?

Note t= hat ignoring the SCSV *on resumption* wouldn't quite work. The server w= ould need to ignore the SCSV on resumption *attempts*, successful or not; I= don't think I'd like that.

I have a few minor editorial nits:
=C2=A0 - the lists in Sections 3 & 4 have a single item, which is a lit= tle odd
=C2=A0 - Section 4 should just say when to use the SCSV, rather than
announce "This section specifies when to send it."

ACK.

Bodo

--20cf3003bd844793ea0503f263c0-- From nobody Fri Sep 26 00:08:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E5FE1A1A71 for ; Fri, 26 Sep 2014 00:08:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.714 X-Spam-Level: X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1yCxLT7jSSA for ; Fri, 26 Sep 2014 00:08:55 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C7FE1A1A70 for ; Fri, 26 Sep 2014 00:08:52 -0700 (PDT) Received: from mail-yk0-f172.google.com (mail-yk0-f172.google.com [209.85.160.172]) by mrelayeu.kundenserver.de (node=mreue101) with ESMTP (Nemesis) id 0MC1IG-1XOeDh3ltg-008uzD; Fri, 26 Sep 2014 09:08:50 +0200 Received: by mail-yk0-f172.google.com with SMTP id 79so3932889ykr.31 for ; Fri, 26 Sep 2014 00:08:48 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.142.7 with SMTP id h7mr55738yhj.133.1411715328917; Fri, 26 Sep 2014 00:08:48 -0700 (PDT) Received: by 10.170.194.15 with HTTP; Fri, 26 Sep 2014 00:08:48 -0700 (PDT) In-Reply-To: References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> Date: Fri, 26 Sep 2014 09:08:48 +0200 Message-ID: From: Bodo Moeller To: Martin Thomson Content-Type: multipart/alternative; boundary=20cf303a36afb448b30503f2960f X-Provags-ID: V02:K0:44l78mThgx0pP1skCz+SGmcY6okcKlfnt6Kkn6ZMjHn 7xQcaPHyQgQwe9HsPqZsnP5pfcATT9IEKKhcgp2+TVtIgnAwfs UNmi3NqRQiEUudUD8qVYfGNHHB/kqZ4+blwDpOryxkL6b14Q28 3eNi7MIi/0y2XxFkD+v9WApjP2RNd/20Li8DnZVCvgWgihNHH9 Z1r5CtUg05z3+nD1wEqac6GA2ptpBFdrzNoKgnq+cn/KMCi2WB XCQfNbvm4Pbh6l/IkRMyNZPYL1pQowdzO58fL6kze70VmYsNwT XvysT1qvrjK1EWITIcz2yCVjbllFWg2OcX7zfnGVJW/hLLX0PD IrWadKHv3nwKFbveOvkz2rjq5LKdyEl8g+Buke1zfYyrO+jET1 UKXx3yAmmimH/wEy+zqH8RuAWkRerCsI2pGwf7v8GFDhTQb9Gm VT8in X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/E_OKzCYjSM9zQfa2TUjaXxVcuU4 Cc: "" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 26 Sep 2014 07:08:56 -0000 --20cf303a36afb448b30503f2960f Content-Type: text/plain; charset=UTF-8 Martin Thomson : > Bodo Moeller wrote: > > > What specifically do you consider wasteful? > > 16 bits, that's all. Not a big deal (unless you are close to having to > pad...) > > > Note that ignoring the SCSV *on resumption* wouldn't quite work. The > server > > would need to ignore the SCSV on resumption *attempts*, successful or > not; I > > don't think I'd like that. > > The draft requires that downgrade on resumption attempts (yes, you are > completely correct) is not guarded. Whether that's a requirement on > the server or client doesn't seem like a big deal to me. > Hm, I think I don't follow. Wouldn't having the server ignore the SCSV on resumption attempts be strictly more wasteful than having the client not send it? The main thinking behind the draft, however, is that the server-side logic should be as simple as possible, because I want *every* server to do this. (What's more, I want every server to do it *correctly*.) The client-side logic, in contrast, can be a bit more complicated: if your client never does those fallback retries, you don't have to do anything. Bodo --20cf303a36afb448b30503f2960f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mart= in Thomson <martin.thomson@gmail.com>:
Bodo Moeller <bmoeller@acm.org> wrote:
= =C2=A0
> What specifically do you consider wasteful?

16 bits, that's all.=C2=A0 Not a big deal (unless you are close = to having to pad...)

> Note that ignoring the SCSV *on resumption* wouldn't quite work. T= he server
> would need to ignore the SCSV on resumption *attempts*, successful or = not; I
> don't think I'd like that.

The draft requires that downgrade on resumption attempts (yes, you a= re
completely correct) is not guarded.=C2=A0 Whether that's a requirement = on
the server or client doesn't seem like a big deal to me.

Hm, I think I don&#= 39;t follow. Wouldn't having the server ignore the SCSV on resumption a= ttempts be strictly more wasteful than having the client not send it?
=

The main th= inking behind the draft, however, is that the server-side logic should be a= s simple as possible, because I want *every* server to do this. (What's= more, I want every server to do it *correctly*.) The client-side logic, in= contrast, can be a bit more complicated: if your client never does those f= allback retries, you don't have to do anything.

Bodo

--20cf303a36afb448b30503f2960f-- From nobody Fri Sep 26 00:22:31 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 125121A1A75 for ; Fri, 26 Sep 2014 00:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9UlJfTekfeu8 for ; Fri, 26 Sep 2014 00:22:28 -0700 (PDT) Received: from mail-la0-x22f.google.com (mail-la0-x22f.google.com [IPv6:2a00:1450:4010:c03::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C6AB1A1A6E for ; Fri, 26 Sep 2014 00:22:28 -0700 (PDT) Received: by mail-la0-f47.google.com with SMTP id mc6so13761309lab.6 for ; Fri, 26 Sep 2014 00:22:26 -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=pVKy3Xq9SNpI/y4g2u4cwkXrHFwQFZOCfJe7E+eCWpQ=; b=RlaAsmJxQIuxkjiJYjv8/8O11FV06vVPlXsJQ3k4PQKdIso8dIOIChAeN5GeNSiWMf TWU9LmXbojZh/yIhWhF43GrpAPjS4x/IewVbcXPkHvegWNmNIZGmCo3ZAYHf5mrOIGfg meHz6tG9eZPJNkLXdvsdMJY6cwiv9G9zv6B+3+1w/JR6RHHaC+m0OZQBZykPFFUs+1Lr /VUXBQDPxFWnDOAuTCTeYxwK7eSJE6heAjwUdjV+41zh6Dln/eumz2SuE9VXYwy5sTSL er1DmivEL4aZdEo+AWv0ML+S/91JKgeAM3/ZG1CQfFcpTv9smASFRZqbojLcwbkv3lct 6oiA== MIME-Version: 1.0 X-Received: by 10.112.148.170 with SMTP id tt10mr17689261lbb.61.1411716146755; Fri, 26 Sep 2014 00:22:26 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Fri, 26 Sep 2014 00:22:26 -0700 (PDT) In-Reply-To: References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> Date: Fri, 26 Sep 2014 08:22:26 +0100 Message-ID: From: Martin Thomson To: Bodo Moeller Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/kAsquRM8BEF6hT-l06Xz8FiY5HM Cc: "" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 26 Sep 2014 07:22:30 -0000 On 26 September 2014 08:08, Bodo Moeller wrote: > > The main thinking behind the draft, however, is that the server-side logic > should be as simple as possible, because I want *every* server to do this. > (What's more, I want every server to do it *correctly*.) The client-side > logic, in contrast, can be a bit more complicated: if your client never does > those fallback retries, you don't have to do anything. I'm OK with that, but if this is the real reason for the MUST, then it's not particularly clear. From nobody Fri Sep 26 00:34:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2A011A1A75 for ; Fri, 26 Sep 2014 00:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.714 X-Spam-Level: X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qpv9mEvDD714 for ; Fri, 26 Sep 2014 00:34:50 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.24]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D70BF1A1A6E for ; Fri, 26 Sep 2014 00:34:49 -0700 (PDT) Received: from mail-yh0-f47.google.com (mail-yh0-f47.google.com [209.85.213.47]) by mrelayeu.kundenserver.de (node=mreue103) with ESMTP (Nemesis) id 0LiWYm-1Y7rKd1I1E-00cewW; Fri, 26 Sep 2014 09:34:47 +0200 Received: by mail-yh0-f47.google.com with SMTP id 29so100478yhl.34 for ; Fri, 26 Sep 2014 00:34:46 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.3.8 with SMTP id 8mr23651393yhg.3.1411716886400; Fri, 26 Sep 2014 00:34:46 -0700 (PDT) Received: by 10.170.194.15 with HTTP; Fri, 26 Sep 2014 00:34:46 -0700 (PDT) In-Reply-To: References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> Date: Fri, 26 Sep 2014 09:34:46 +0200 Message-ID: From: Bodo Moeller To: Martin Thomson Content-Type: multipart/alternative; boundary=001a113676268997ba0503f2f3de X-Provags-ID: V02:K0:q3Ob0f/R0BnwHso4xzpEFsdQz5pZeVF8FnrKNbgrixE zwO+8CBeBUCEqiIL8czFJacwRVoDgFsT5uC1CW00lG552hSXie WVDnwoppmIl82GkhUCCFGR2bybY27bSOKn94tI9K60AZNM6Wse qXRWmkVDjKMZtyg8zMYJUrWh+eqJoGcvZC3nI1pUTa/P0FmE1/ WflIWXt3QSufkTPaljAvr6bcYuA+gaeKibB0KAI8iFIzD3+Gby YwSPPPS001kX7g/ox9bvzKAPkr2Xx0EarpkI5UW8mFRLfE2BIt 1d5gCeaLwzS292i2OYTCwdhu8jxmyUdkA8Qai0d19G9NTmX5FI 4sj9gmiZppKdokhsbB3vmwdDmDmXgo9MBK/ZNVDyHZCTT6UPFJ e6HGmx4HjuYJKswHcy+AzmgcHPipe7Hf8TdPtQFPmxe94kaCf/ uizJV X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/-DlROXpfOPloQCbwc50uTnMHgEk Cc: "" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 26 Sep 2014 07:34:51 -0000 --001a113676268997ba0503f2f3de Content-Type: text/plain; charset=UTF-8 > > I'm OK with that, but if this is the real reason for the MUST, then > it's not particularly clear. > Hm, maybe so. I can add a brief note showing how the handshake would fail if the server acts on the SCSV in this case, but I don't think the document should have to explain why we require the client to omit the SCSV rather than having the server ignore it. (Why would you want to send it if nothing follows from that?) Bodo --001a113676268997ba0503f2f3de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm OK with that, but if this is the real re= ason for the MUST, then
it's not particularly clear.

Hm, maybe so. I can= add a brief note showing how the handshake would fail if the server acts o= n the SCSV in this case, but I don't think the document should have to = explain why we require the client to omit the SCSV rather than having the s= erver ignore it. (Why would you want to send it if nothing follows from tha= t?)

Bo= do

--001a113676268997ba0503f2f3de-- From nobody Fri Sep 26 10:45:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DAE451A90F6 for ; Fri, 26 Sep 2014 10:44:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LruHceRfXK6N for ; Fri, 26 Sep 2014 10:44:55 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0135.outbound.protection.outlook.com [207.46.100.135]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39F5E1A90F5 for ; Fri, 26 Sep 2014 10:44:54 -0700 (PDT) Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB420.namprd03.prod.outlook.com (10.141.92.25) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Fri, 26 Sep 2014 17:44:52 +0000 Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.1034.003; Fri, 26 Sep 2014 17:44:52 +0000 From: Andrei Popov To: "Joseph Salowey (jsalowey)" , "" Thread-Topic: Working Group Last Call for draft-ietf-tls-downgrade-scsv-00 Thread-Index: AQHP2T5a8EAtsaADg0ykrefiCf9Yj5wTq6Mw Date: Fri, 26 Sep 2014 17:44:51 +0000 Message-ID: References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> In-Reply-To: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2001:4898:80e8:ed31::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB420; x-forefront-prvs: 03468CBA43 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(13464003)(189002)(377454003)(164054003)(199003)(90102001)(81542003)(87936001)(4396001)(19580405001)(108616004)(107886001)(230783001)(46102003)(97736003)(107046002)(81342003)(74502003)(79102003)(74662003)(19580395003)(83072002)(86362001)(106356001)(106116001)(85852003)(99396003)(101416001)(10300001)(21056001)(31966008)(15975445006)(20776003)(76176999)(64706001)(33646002)(120916001)(50986999)(99286002)(2656002)(85306004)(54356999)(77982003)(92566001)(76576001)(86612001)(74316001)(80022003)(105586002)(76482002)(83322001)(95666004)(24736002)(3826002)(491001); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB420; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/H5toempuu7uIqg9u0Hf8E9tx5e0 Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 26 Sep 2014 17:44:58 -0000 This I-D currently forces clients to do sequential fallbacks, without skipp= ing versions: TLS1.3->TLS1.2->TLS1.1->TLS1.0 will work, but e.g. TLS1.3->TL= S1.2->TLS1.0 won't. Clients may want to skip protocol versions in the fallb= ack sequence to reduce latency. Clients may also need to disable arbitrary = protocol versions for security reasons. I see two ways to fix this in the draft: 1. Use a TLS extension instead of an SCSV. In the extension, the client cou= ld indicate the previously attempted protocol version. The problem with thi= s is that SSL3 ClientHellos are not supposed to have extensions, but we'd l= ike to secure fallbacks to SSL3. 2. Use one SCSV value per TLS & SSL protocol version. The client includes t= he SCSV indicating the previously attempted protocol version. The drawback = here is that this creates multiple SCSVs:). If this problem is not solved, then clients will have no choice but to avoi= d sending the SCSV when skipping protocol versions, e.g.: TLS1.3(no SCSV)->= TLS1.2(with SCSV)->TLS1.0(no SCSV). Which (at least partially) defeats the = purpose of the I-D. Cheers, Andrei -----Original Message----- From: TLS [mailto:tls-bounces@ietf.org] On Behalf Of Joseph Salowey (jsalow= ey) Sent: Thursday, September 25, 2014 9:00 PM To: Subject: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00 This is an announcement for the working group last call for draft-ietf-tls-= downgrade-scsv-00. Please review the document and send your comments to th= e list by Friday, October 17, 2014. =20 Thanks, J&S _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Fri Sep 26 11:05:25 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30D5B1A6F90 for ; Fri, 26 Sep 2014 11:05:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8wDKnTkwAN4v for ; Fri, 26 Sep 2014 11:05:23 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 942B51A6F83 for ; Fri, 26 Sep 2014 11:05:22 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id z12so14582488lbi.8 for ; Fri, 26 Sep 2014 11:05:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=ZLTt+Fn2FGsuWS2lAEBM6ajmnxjjt+J8+V/B2B1IV/4=; b=Ul1qPcat8n6RzuD3ikOtNpfvvnJ4I8ludZpxrARo42HlJ5gRkc0d7N6cZYwReOe+YD sgr7Q0zC32+aUAHFvxc8PR9ZPIktjlzHEa+PceygfCFBMy0z0zIdzVKHV9j6nKauAGWf mg4uHoaSVbKpmaiu6LlFB+AC7cj6MWUpiErWs7yx4jI3ZW26H96tHlYIaNLPgp2UwmLj oKZcmP7f665maTDfJP80vf5lYTK79S4PytTtmAD1rwGB66gInduSDDYD7sPMBmwa3sSL R32wJ03bwALQmL59LndWy36Z1Ne1i+xRLd1RIktv0yVz+r3ndxbCONFwoBntkH55ru+P 3k6A== MIME-Version: 1.0 X-Received: by 10.112.142.33 with SMTP id rt1mr20633579lbb.69.1411754720449; Fri, 26 Sep 2014 11:05:20 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.241.103 with HTTP; Fri, 26 Sep 2014 11:05:20 -0700 (PDT) In-Reply-To: References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> Date: Fri, 26 Sep 2014 11:05:20 -0700 X-Google-Sender-Auth: G0fFuz2I8dSyyY-uRSsi5kWKW5k Message-ID: From: Adam Langley To: Andrei Popov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/46LrLm1SAYPCNvYWbQdxl249X2U Cc: "" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 26 Sep 2014 18:05:24 -0000 On Fri, Sep 26, 2014 at 10:44 AM, Andrei Popov wrote: > This I-D currently forces clients to do sequential fallbacks, without ski= pping versions: TLS1.3->TLS1.2->TLS1.1->TLS1.0 will work, but e.g. TLS1.3->= TLS1.2->TLS1.0 won't. Clients may want to skip protocol versions in the fal= lback sequence to reduce latency. Clients may also need to disable arbitrar= y protocol versions for security reasons. > > I see two ways to fix this in the draft: > 1. Use a TLS extension instead of an SCSV. In the extension, the client c= ould indicate the previously attempted protocol version. The problem with t= his is that SSL3 ClientHellos are not supposed to have extensions, but we'd= like to secure fallbacks to SSL3. > 2. Use one SCSV value per TLS & SSL protocol version. The client includes= the SCSV indicating the previously attempted protocol version. The drawbac= k here is that this creates multiple SCSVs:). > > If this problem is not solved, then clients will have no choice but to av= oid sending the SCSV when skipping protocol versions, e.g.: TLS1.3(no SCSV)= ->TLS1.2(with SCSV)->TLS1.0(no SCSV). Which (at least partially) defeats th= e purpose of the I-D. We've had the design of an SCSV-per-version before and it didn't really go anywhere. (There is, at least, ekr's draft[1].) Yes, you have to step down every version. But stepping down is a good idea because you want to lose as few features as possible. If you drop right down to SSLv3 then you loose ECDHE and so on. It's more latency, but only for the case of very old, broken servers. So be= it. [1] https://github.com/ekr/ietf-drafts/blob/master/draft-rescorla-tls-versi= on-cs.txt Cheers AGL --=20 Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Fri Sep 26 11:33:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C90641A00EF for ; Fri, 26 Sep 2014 11:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ePhYEEQeELPf for ; Fri, 26 Sep 2014 11:33:11 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0764.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::764]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F58C1A0048 for ; Fri, 26 Sep 2014 11:33:11 -0700 (PDT) Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB418.namprd03.prod.outlook.com (10.141.92.13) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Fri, 26 Sep 2014 18:32:48 +0000 Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.1034.003; Fri, 26 Sep 2014 18:32:48 +0000 From: Andrei Popov To: Adam Langley Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00 Thread-Index: AQHP2T5a8EAtsaADg0ykrefiCf9Yj5wTq6MwgAAKvgCAAAKHEA== Date: Fri, 26 Sep 2014 18:32:48 +0000 Message-ID: References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2001:4898:80e8:ed31::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB418; x-forefront-prvs: 03468CBA43 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(13464003)(189002)(199003)(51704005)(24454002)(230783001)(86612001)(15975445006)(92566001)(110136001)(31966008)(106116001)(76482002)(87936001)(54356999)(64706001)(106356001)(74316001)(20776003)(76176999)(85306004)(76576001)(33646002)(85852003)(101416001)(50986999)(83072002)(90102001)(107046002)(95666004)(83322001)(19580405001)(77982003)(108616004)(97736003)(79102003)(74662003)(80022003)(10300001)(105586002)(21056001)(2656002)(81342003)(4396001)(120916001)(86362001)(46102003)(99396003)(81542003)(19580395003)(99286002)(74502003)(3826002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB418; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GA9t73Xx9JsBbIj4M70omaqryno Cc: "" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 26 Sep 2014 18:33:15 -0000 PiBCdXQgc3RlcHBpbmcgZG93biBpcyBhIGdvb2QgaWRlYSBiZWNhdXNlIHlvdSB3YW50IHRvIGxv c2UgYXMgZmV3IGZlYXR1cmVzIGFzIHBvc3NpYmxlLg0KVGhpcyBtYXkgd2VsbCBiZSwgYnV0IGFy Z3VhYmx5IHRoZSBUTFMgcHJvdG9jb2wgc2hvdWxkIG5vdCBiZSBjcmVhdGluZyBuZXcgY29uc3Ry YWludHMgb24gdGhlIHVwcGVyIFNXIGxheWVycywgd2hlcmUgaXQncyBwb3NzaWJsZSB0byBhdm9p ZCBkb2luZyBzby4NCg0KUmVnYXJkbGVzcyBvZiB3aGF0IHRoZSBicm93c2VyIHdhbnRzIHRvIGRv LCB0aGUgc3lzdGVtIGFkbWluIHdpbGwgc29tZXRpbWVzIGRpc2FibGUgYSBzcGVjaWZpYyBUTFMg dmVyc2lvbiBtYWNoaW5lLXdpZGUgKG9yIGVudGVycHJpc2Utd2lkZSksIGUuZy4gZHVlIHRvIHZl cnNpb24tc3BlY2lmaWMgc2VjdXJpdHkgY29uY2VybnMuIEkgYW0gcG9pbnRpbmcgb3V0IHRoYXQs IHdpdGggdGhlIGN1cnJlbnQgZHJhZnQsIHRoZSBicm93c2VyIGlzIGZvcmNlZCB0byBub3Qgc2Vu ZCB0aGUgU0NTViB3aGVuIHNraXBwaW5nIHZlcnNpb25zLg0KDQpDaGVlcnMsDQoNCkFuZHJlaQ0K DQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogYWxhbmdsZXlAZ21haWwuY29tIFtt YWlsdG86YWxhbmdsZXlAZ21haWwuY29tXSBPbiBCZWhhbGYgT2YgQWRhbSBMYW5nbGV5DQpTZW50 OiBGcmlkYXksIFNlcHRlbWJlciAyNiwgMjAxNCAxMTowNSBBTQ0KVG86IEFuZHJlaSBQb3Bvdg0K Q2M6IEpvc2VwaCBTYWxvd2V5IChqc2Fsb3dleSk7IDx0bHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBS ZTogW1RMU10gV29ya2luZyBHcm91cCBMYXN0IENhbGwgZm9yIGRyYWZ0LWlldGYtdGxzLWRvd25n cmFkZS1zY3N2LTAwDQoNCk9uIEZyaSwgU2VwIDI2LCAyMDE0IGF0IDEwOjQ0IEFNLCBBbmRyZWkg UG9wb3YgPEFuZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPiB3cm90ZToNCj4gVGhpcyBJLUQgY3Vy cmVudGx5IGZvcmNlcyBjbGllbnRzIHRvIGRvIHNlcXVlbnRpYWwgZmFsbGJhY2tzLCB3aXRob3V0 IHNraXBwaW5nIHZlcnNpb25zOiBUTFMxLjMtPlRMUzEuMi0+VExTMS4xLT5UTFMxLjAgd2lsbCB3 b3JrLCBidXQgZS5nLiBUTFMxLjMtPlRMUzEuMi0+VExTMS4wIHdvbid0LiBDbGllbnRzIG1heSB3 YW50IHRvIHNraXAgcHJvdG9jb2wgdmVyc2lvbnMgaW4gdGhlIGZhbGxiYWNrIHNlcXVlbmNlIHRv IHJlZHVjZSBsYXRlbmN5LiBDbGllbnRzIG1heSBhbHNvIG5lZWQgdG8gZGlzYWJsZSBhcmJpdHJh cnkgcHJvdG9jb2wgdmVyc2lvbnMgZm9yIHNlY3VyaXR5IHJlYXNvbnMuDQo+DQo+IEkgc2VlIHR3 byB3YXlzIHRvIGZpeCB0aGlzIGluIHRoZSBkcmFmdDoNCj4gMS4gVXNlIGEgVExTIGV4dGVuc2lv biBpbnN0ZWFkIG9mIGFuIFNDU1YuIEluIHRoZSBleHRlbnNpb24sIHRoZSBjbGllbnQgY291bGQg aW5kaWNhdGUgdGhlIHByZXZpb3VzbHkgYXR0ZW1wdGVkIHByb3RvY29sIHZlcnNpb24uIFRoZSBw cm9ibGVtIHdpdGggdGhpcyBpcyB0aGF0IFNTTDMgQ2xpZW50SGVsbG9zIGFyZSBub3Qgc3VwcG9z ZWQgdG8gaGF2ZSBleHRlbnNpb25zLCBidXQgd2UnZCBsaWtlIHRvIHNlY3VyZSBmYWxsYmFja3Mg dG8gU1NMMy4NCj4gMi4gVXNlIG9uZSBTQ1NWIHZhbHVlIHBlciBUTFMgJiBTU0wgcHJvdG9jb2wg dmVyc2lvbi4gVGhlIGNsaWVudCBpbmNsdWRlcyB0aGUgU0NTViBpbmRpY2F0aW5nIHRoZSBwcmV2 aW91c2x5IGF0dGVtcHRlZCBwcm90b2NvbCB2ZXJzaW9uLiBUaGUgZHJhd2JhY2sgaGVyZSBpcyB0 aGF0IHRoaXMgY3JlYXRlcyBtdWx0aXBsZSBTQ1NWczopLg0KPg0KPiBJZiB0aGlzIHByb2JsZW0g aXMgbm90IHNvbHZlZCwgdGhlbiBjbGllbnRzIHdpbGwgaGF2ZSBubyBjaG9pY2UgYnV0IHRvIGF2 b2lkIHNlbmRpbmcgdGhlIFNDU1Ygd2hlbiBza2lwcGluZyBwcm90b2NvbCB2ZXJzaW9ucywgZS5n LjogVExTMS4zKG5vIFNDU1YpLT5UTFMxLjIod2l0aCBTQ1NWKS0+VExTMS4wKG5vIFNDU1YpLiBX aGljaCAoYXQgbGVhc3QgcGFydGlhbGx5KSBkZWZlYXRzIHRoZSBwdXJwb3NlIG9mIHRoZSBJLUQu DQoNCldlJ3ZlIGhhZCB0aGUgZGVzaWduIG9mIGFuIFNDU1YtcGVyLXZlcnNpb24gYmVmb3JlIGFu ZCBpdCBkaWRuJ3QgcmVhbGx5IGdvIGFueXdoZXJlLiAoVGhlcmUgaXMsIGF0IGxlYXN0LCBla3In cyBkcmFmdFsxXS4pDQoNClllcywgeW91IGhhdmUgdG8gc3RlcCBkb3duIGV2ZXJ5IHZlcnNpb24u IEJ1dCBzdGVwcGluZyBkb3duIGlzIGEgZ29vZCBpZGVhIGJlY2F1c2UgeW91IHdhbnQgdG8gbG9z ZSBhcyBmZXcgZmVhdHVyZXMgYXMgcG9zc2libGUuIElmIHlvdSBkcm9wIHJpZ2h0IGRvd24gdG8g U1NMdjMgdGhlbiB5b3UgbG9vc2UgRUNESEUgYW5kIHNvIG9uLg0KDQpJdCdzIG1vcmUgbGF0ZW5j eSwgYnV0IG9ubHkgZm9yIHRoZSBjYXNlIG9mIHZlcnkgb2xkLCBicm9rZW4gc2VydmVycy4gU28g YmUgaXQuDQoNClsxXSBodHRwczovL2dpdGh1Yi5jb20vZWtyL2lldGYtZHJhZnRzL2Jsb2IvbWFz dGVyL2RyYWZ0LXJlc2NvcmxhLXRscy12ZXJzaW9uLWNzLnR4dA0KDQoNCkNoZWVycw0KDQpBR0wN Cg0KLS0NCkFkYW0gTGFuZ2xleSBhZ2xAaW1wZXJpYWx2aW9sZXQub3JnIGh0dHBzOi8vd3d3Lmlt cGVyaWFsdmlvbGV0Lm9yZw0K From nobody Fri Sep 26 11:43:16 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B59B71A01F4 for ; Fri, 26 Sep 2014 11:43:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhhS6o4zqbb6 for ; Fri, 26 Sep 2014 11:43:12 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E1E391A01F7 for ; Fri, 26 Sep 2014 11:43:11 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id el20so3357509lab.37 for ; Fri, 26 Sep 2014 11:43:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=a+8ord3Y+qxRLiMRRJnGr9NzTKErNjzoCV0faFsLIvM=; b=nIFC/61ai7VDiTkIoXFzaACa+MgkrUlG6rdNClmhrDEcOSGhfdvYaeyf1t8p0dhOyC am8S+iW6CREdXkx+XkBLUArYnpXVIdzgmWV0JJ6eCq4dM0T6tRtaAKBXlVKTziW6SlIr HLTufgGwHwXJ8CB7rYCHR1Ra0rSaCJw6L5oAWo0dHGcGV7JK7+b39h6wtUXQCz3yEiiR WKco8184NWYFzFz8m8scWDhv+a5i8lEP56AEFDO0uHRYrPVRxScPMwNItObCmlvCy291 6nrcs7OCqoDzHqKXhYWbrpHP4BFB6gbhB8Lx47d6dtH+7j1lvlVaJZgn35M4pece0xry HHkg== MIME-Version: 1.0 X-Received: by 10.152.9.200 with SMTP id c8mr22586720lab.76.1411756640828; Fri, 26 Sep 2014 11:37:20 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.241.103 with HTTP; Fri, 26 Sep 2014 11:37:20 -0700 (PDT) In-Reply-To: References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> Date: Fri, 26 Sep 2014 11:37:20 -0700 X-Google-Sender-Auth: WMqfHMFLY4PA9i86Drq8YrDSj7E Message-ID: From: Adam Langley To: Andrei Popov Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/tls/cq1Q5Q5qvxLOBTI1w1rwLVphNRw Cc: "" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 26 Sep 2014 18:43:15 -0000 On Fri, Sep 26, 2014 at 11:32 AM, Andrei Popov wrote: >> But stepping down is a good idea because you want to lose as few feature= s as possible. > This may well be, but arguably the TLS protocol should not be creating ne= w constraints on the upper SW layers, where it's possible to avoid doing so= . > > Regardless of what the browser wants to do, the system admin will sometim= es disable a specific TLS version machine-wide (or enterprise-wide), e.g. d= ue to version-specific security concerns. I am pointing out that, with the = current draft, the browser is forced to not send the SCSV when skipping ver= sions. If an administrator is worried that version x is too weak, then all versions <=3D x need to be disabled too I believe? I can't think of a security concern that is not monotonic with respect to TLS versions. Cheers AGL --=20 Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Fri Sep 26 11:51:53 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 133EA1A0342 for ; Fri, 26 Sep 2014 11:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uMq3X_NiYVIg for ; Fri, 26 Sep 2014 11:51:42 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0753.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::753]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EE131A0327 for ; Fri, 26 Sep 2014 11:51:42 -0700 (PDT) Received: from BL2PR03MB417.namprd03.prod.outlook.com (10.141.92.12) by BL2PR03MB132.namprd03.prod.outlook.com (10.255.230.24) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Fri, 26 Sep 2014 18:51:19 +0000 Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB417.namprd03.prod.outlook.com (10.141.92.12) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Fri, 26 Sep 2014 18:51:18 +0000 Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.1034.003; Fri, 26 Sep 2014 18:51:18 +0000 From: Andrei Popov To: Adam Langley Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00 Thread-Index: AQHP2T5a8EAtsaADg0ykrefiCf9Yj5wTq6MwgAAKvgCAAAKHEIAABmoAgAAATHA= Date: Fri, 26 Sep 2014 18:51:18 +0000 Message-ID: <4362f4b71cb44ebd80629d52dd791437@BL2PR03MB419.namprd03.prod.outlook.com> References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2001:4898:80e8:ed31::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB417;UriScan:; x-forefront-prvs: 03468CBA43 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(51704005)(377454003)(13464003)(199003)(24454002)(2656002)(230783001)(110136001)(76482002)(87936001)(20776003)(85306004)(86362001)(90102001)(31966008)(93886004)(106356001)(99286002)(106116001)(50986999)(101416001)(95666004)(15975445006)(83322001)(81342003)(54356999)(21056001)(80022003)(85852003)(74662003)(79102003)(46102003)(74316001)(120916001)(77982003)(81542003)(108616004)(74502003)(76176999)(97736003)(4396001)(83072002)(99396003)(19580395003)(33646002)(64706001)(92566001)(19580405001)(10300001)(76576001)(86612001)(107046002)(105586002)(3826002)(24736002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB417; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB132; X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/QrTSAxCUuYckgwZLXcC9qWWpPWY Cc: "" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 26 Sep 2014 18:51:49 -0000 PiBJZiBhbiBhZG1pbmlzdHJhdG9yIGlzIHdvcnJpZWQgdGhhdCB2ZXJzaW9uIHggaXMgdG9vIHdl YWssIHRoZW4gYWxsIHZlcnNpb25zIDw9IHggbmVlZCB0byBiZSBkaXNhYmxlZCB0b28gSSBiZWxp ZXZlPyBJIGNhbid0IHRoaW5rIG9mIGEgc2VjdXJpdHkgY29uY2VybiB0aGF0IGlzIG5vdCBtb25v dG9uaWMgd2l0aCByZXNwZWN0IHRvIFRMUyB2ZXJzaW9ucy4NCg0KVGhpcyBtYXkgYmUgdHJ1ZSBm b3IgdGhlIGlzc3VlcyB3ZSBrbm93IGFib3V0IHRvZGF5LCBhbmQgb25seSB0YWtpbmcgaW50byBj b25zaWRlcmF0aW9uIHByb3RvY29sLWxldmVsIHZ1bG5lcmFiaWxpdGllcy4gVGhlcmUgYXJlIHNv bWV0aW1lcyBpbXBsZW1lbnRhdGlvbi1sZXZlbCBidWdzIHRoYXQgYWZmZWN0IGEgc3BlY2lmaWMg cHJvdG9jb2wgdmVyc2lvbiwgYW5kIHRoZXNlIGFyZSBxdWlja2x5IHdvcmtlZCBhcm91bmQgYnkg dGVtcG9yYXJpbHkgZGlzYWJsaW5nIHRoaXMgcHJvdG9jb2wgdmVyc2lvbi4NCg0KSW4gYW55IGNh c2UsIHRoZSBjbGllbnQgYXBwIGhhcyBhIHdvcmthcm91bmQgKHdoaWNoIGlzIHRvIG5vdCBzZW5k IHRoZSBkb3duZ3JhZGUgU0NTViB3aGVuIHNraXBwaW5nIFRMUyB2ZXJzaW9ucykuIFRoaXMgd29y a2Fyb3VuZCBpcyBmYXIgZnJvbSBwZXJmZWN0LCBidXQgSSBjYW4gbGl2ZSB3aXRoIHRoZSBjdXJy ZW50IGRvd25ncmFkZS1zY3N2IGRyYWZ0IGlmIEkgaGF2ZSB0by4gSW4gdGhpcyBjYXNlLCB0aGUg Zml4IGlzIHByZXR0eSB0cml2aWFsLCBzbyBJIHRob3VnaHQgaXQgd2FzIHdvcnRoIGJyaW5naW5n IHRoaXMgdXAuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBhbGFuZ2xleUBn bWFpbC5jb20gW21haWx0bzphbGFuZ2xleUBnbWFpbC5jb21dIE9uIEJlaGFsZiBPZiBBZGFtIExh bmdsZXkNClNlbnQ6IEZyaWRheSwgU2VwdGVtYmVyIDI2LCAyMDE0IDExOjM3IEFNDQpUbzogQW5k cmVpIFBvcG92DQpDYzogSm9zZXBoIFNhbG93ZXkgKGpzYWxvd2V5KTsgPHRsc0BpZXRmLm9yZz4N ClN1YmplY3Q6IFJlOiBbVExTXSBXb3JraW5nIEdyb3VwIExhc3QgQ2FsbCBmb3IgZHJhZnQtaWV0 Zi10bHMtZG93bmdyYWRlLXNjc3YtMDANCg0KT24gRnJpLCBTZXAgMjYsIDIwMTQgYXQgMTE6MzIg QU0sIEFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb20+IHdyb3RlOg0KPj4g QnV0IHN0ZXBwaW5nIGRvd24gaXMgYSBnb29kIGlkZWEgYmVjYXVzZSB5b3Ugd2FudCB0byBsb3Nl IGFzIGZldyBmZWF0dXJlcyBhcyBwb3NzaWJsZS4NCj4gVGhpcyBtYXkgd2VsbCBiZSwgYnV0IGFy Z3VhYmx5IHRoZSBUTFMgcHJvdG9jb2wgc2hvdWxkIG5vdCBiZSBjcmVhdGluZyBuZXcgY29uc3Ry YWludHMgb24gdGhlIHVwcGVyIFNXIGxheWVycywgd2hlcmUgaXQncyBwb3NzaWJsZSB0byBhdm9p ZCBkb2luZyBzby4NCj4NCj4gUmVnYXJkbGVzcyBvZiB3aGF0IHRoZSBicm93c2VyIHdhbnRzIHRv IGRvLCB0aGUgc3lzdGVtIGFkbWluIHdpbGwgc29tZXRpbWVzIGRpc2FibGUgYSBzcGVjaWZpYyBU TFMgdmVyc2lvbiBtYWNoaW5lLXdpZGUgKG9yIGVudGVycHJpc2Utd2lkZSksIGUuZy4gZHVlIHRv IHZlcnNpb24tc3BlY2lmaWMgc2VjdXJpdHkgY29uY2VybnMuIEkgYW0gcG9pbnRpbmcgb3V0IHRo YXQsIHdpdGggdGhlIGN1cnJlbnQgZHJhZnQsIHRoZSBicm93c2VyIGlzIGZvcmNlZCB0byBub3Qg c2VuZCB0aGUgU0NTViB3aGVuIHNraXBwaW5nIHZlcnNpb25zLg0KDQpJZiBhbiBhZG1pbmlzdHJh dG9yIGlzIHdvcnJpZWQgdGhhdCB2ZXJzaW9uIHggaXMgdG9vIHdlYWssIHRoZW4gYWxsIHZlcnNp b25zIDw9IHggbmVlZCB0byBiZSBkaXNhYmxlZCB0b28gSSBiZWxpZXZlPyBJIGNhbid0IHRoaW5r IG9mIGEgc2VjdXJpdHkgY29uY2VybiB0aGF0IGlzIG5vdCBtb25vdG9uaWMgd2l0aCByZXNwZWN0 IHRvIFRMUyB2ZXJzaW9ucy4NCg0KDQpDaGVlcnMNCg0KQUdMDQoNCi0tDQpBZGFtIExhbmdsZXkg YWdsQGltcGVyaWFsdmlvbGV0Lm9yZyBodHRwczovL3d3dy5pbXBlcmlhbHZpb2xldC5vcmcNCg== From nobody Fri Sep 26 11:53:45 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 384751A3B9D for ; Fri, 26 Sep 2014 11:53:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.714 X-Spam-Level: X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POeDoEnTdjcU for ; Fri, 26 Sep 2014 11:53:40 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.10]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 746801A3BA4 for ; Fri, 26 Sep 2014 11:53:22 -0700 (PDT) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) by mrelayeu.kundenserver.de (node=mreue105) with ESMTP (Nemesis) id 0LkxjZ-1Y5Gxu4BlN-00aqWf; Fri, 26 Sep 2014 20:53:20 +0200 Received: by mail-qa0-f53.google.com with SMTP id cm18so6333996qab.26 for ; Fri, 26 Sep 2014 11:53:17 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.21.104 with SMTP id 95mr840497qgk.69.1411757597944; Fri, 26 Sep 2014 11:53:17 -0700 (PDT) Received: by 10.140.156.5 with HTTP; Fri, 26 Sep 2014 11:53:17 -0700 (PDT) In-Reply-To: References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> Date: Fri, 26 Sep 2014 20:53:17 +0200 Message-ID: From: Bodo Moeller To: Andrei Popov Content-Type: multipart/alternative; boundary=001a11c152a22273b20503fc6e00 X-Provags-ID: V02:K0:mqv4MLQK9gVshNwKyFTXEEd0iKtkuF/73wJg8v/u3gk a4RPSlCOiG3da1D70eJOSduX2YL6QirTTF2r8SAowfBxmiEv1v 6+M34bTzyrlUsqh3QtZbFOHSnc4GKhR7KJDGi8/udk49QKCTO7 tojk+BMAAIJZRfmZnL8aekz5M2e4Xg18vpgyEgmzqNR6SAGM3D 34rfSZk8A1jpvFXqX/8rKqHF2Ro3pdXctNI8F9nG5iCcLjB5ly bmFR+5dacXyhWMLaHHe9G/CKiRa7xZ/j8SvpZpt3TL2N0QHvKa zcdL8bb6CaJUZc5r4VANAbY76e0XTO1yhvOWTyR3PH0SxmTAtx yr2LLVUMt+CTnCCAjM040mDaYxtwmKxIxVzG/duhdGuxMphQYn CS6TRJsn2Iy4SU7PV7rH2ra04ZnH0fb+FGf6BQc3j0H8Ux70CX Kr7LF X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/2aCT6EhlH4Al4va9b0N8o3befjw Cc: Adam Langley , "" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 26 Sep 2014 18:53:41 -0000 --001a11c152a22273b20503fc6e00 Content-Type: text/plain; charset=UTF-8 Andrei Popov : > Regardless of what the browser wants to do, the system admin will > sometimes disable a specific TLS version machine-wide (or enterprise-wide), > e.g. due to version-specific security concerns. That's not supported with normal TLS version negotiation either -- if the client offers version X, the server may pick Y (< X) without having any way of knowing that Y is disabled in the client whereas some other version Z (< Y) is not. If you really see a good reason to support this (which I don't) and are concerned about latency, you'd already need some TLS extension to send this information from the client to the server. I've never seen anyone propose this, and would be skeptical about it. I am pointing out that, with the current draft, the browser is forced to > not send the SCSV when skipping versions. I'd rather say that the client is forced not to skip versions when sending the SCSV (and that this is a feature). Bodo --001a11c152a22273b20503fc6e00 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Andr= ei Popov <Andrei.Popov@microsoft.com>:
=C2= =A0
Regardless of what the browser wants to do, the system admin will sometimes= disable a specific TLS version machine-wide (or enterprise-wide), e.g. due= to version-specific security concerns.

Tha= t's not supported with normal TLS version negotiation either -- if the = client offers version X, the server may pick Y (< X) without having any = way of knowing that Y is disabled in the client whereas some other version = Z (< Y) is not.

If you really see a good reason= to support this (which I don't) and are concerned about latency, you&#= 39;d already need some TLS extension to send this information from the clie= nt to the server. I've never seen anyone propose this, and would be ske= ptical about it.

I am p= ointing out that, with the current draft, the browser is forced to not send= the SCSV when skipping versions.

I'd r= ather say that the client is forced not to skip versions when sending the S= CSV (and that this is a feature).

Bodo
<= br>

=C2=A0
--001a11c152a22273b20503fc6e00-- From nobody Fri Sep 26 11:58:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 140CC1A0024 for ; Fri, 26 Sep 2014 11:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vo6Yyzw4P7Ls for ; Fri, 26 Sep 2014 11:58:29 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0130.outbound.protection.outlook.com [207.46.100.130]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FD961A3BA7 for ; Fri, 26 Sep 2014 11:58:29 -0700 (PDT) Received: from BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) by BL2PR03MB419.namprd03.prod.outlook.com (10.141.92.18) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Fri, 26 Sep 2014 18:58:28 +0000 Received: from BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) by BL2PR03MB419.namprd03.prod.outlook.com ([10.141.92.18]) with mapi id 15.00.1034.003; Fri, 26 Sep 2014 18:58:28 +0000 From: Andrei Popov To: Bodo Moeller Thread-Topic: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00 Thread-Index: AQHP2T5a8EAtsaADg0ykrefiCf9Yj5wTq6MwgAAKvgCAAAKHEIAACt+AgAAALYA= Date: Fri, 26 Sep 2014 18:58:28 +0000 Message-ID: <3217718b166c44b887feaab052335509@BL2PR03MB419.namprd03.prod.outlook.com> References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [2001:4898:80e8:ed31::2] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BL2PR03MB419; x-forefront-prvs: 03468CBA43 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(189002)(377454003)(33646002)(74502003)(2656002)(105586002)(83072002)(86362001)(74316001)(21056001)(76576001)(74662003)(81342003)(92566001)(110136001)(108616004)(86612001)(95666004)(50986999)(16236675004)(79102003)(4396001)(83322001)(97736003)(85852003)(76482002)(99286002)(230783001)(93886004)(20776003)(80022003)(85306004)(106116001)(54356999)(81542003)(76176999)(101416001)(19580395003)(120916001)(19625215002)(19580405001)(64706001)(107046002)(46102003)(15975445006)(15202345003)(87936001)(10300001)(106356001)(19300405004)(31966008)(77982003)(90102001)(99396003)(24736002)(3826002); DIR:OUT; SFP:1102; SCL:1; SRVR:BL2PR03MB419; H:BL2PR03MB419.namprd03.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_3217718b166c44b887feaab052335509BL2PR03MB419namprd03pro_" MIME-Version: 1.0 X-OriginatorOrg: microsoft.onmicrosoft.com Archived-At: http://mailarchive.ietf.org/arch/msg/tls/G_dwPyA2pcybbEAJLclnGvXiKak Cc: Adam Langley , "" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 26 Sep 2014 18:58:32 -0000 --_000_3217718b166c44b887feaab052335509BL2PR03MB419namprd03pro_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 w5ggIElmIHlvdSByZWFsbHkgc2VlIGEgZ29vZCByZWFzb24gdG8gc3VwcG9ydCB0aGlzICh3aGlj aCBJIGRvbid0KSBhbmQgYXJlIGNvbmNlcm5lZCBhYm91dCBsYXRlbmN5LCB5b3UnZCBhbHJlYWR5 IG5lZWQgc29tZSBUTFMgZXh0ZW5zaW9uIHRvIHNlbmQgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIHRo ZSBjbGllbnQgdG8gdGhlIHNlcnZlci4gSSd2ZSBuZXZlciBzZWVuIGFueW9uZSBwcm9wb3NlIHRo aXMsIGFuZCB3b3VsZCBiZSBza2VwdGljYWwgYWJvdXQgaXQuDQpJIHRoaW5rIGFsbCB0aGF0IG5l ZWRzIHRvIGJlIGRvbmUgaXMgZm9yIHRoZSBjbGllbnQgdG8gc2lnbmFsIHRoZSBwcmV2aW91c2x5 IGF0dGVtcHRlZCB2ZXJzaW9uLCB2aWEgZXh0ZW5zaW9uIG9yIFNDU1YuIFJhdGhlciB0aGFuIGp1 c3Qgc2F5aW5nIOKAnEnigJl2ZSB0cmllZCBhIGhpZ2hlciB2ZXJzaW9uIGJlZm9yZeKAnSwgd2hp Y2ggaXMgd2hhdCB0aGUgZHJhZnQgYWxsb3dzIG5vdy4NCg0KDQrDmCAgSSdkIHJhdGhlciBzYXkg dGhhdCB0aGUgY2xpZW50IGlzIGZvcmNlZCBub3QgdG8gc2tpcCB2ZXJzaW9ucyB3aGVuIHNlbmRp bmcgdGhlIFNDU1YgKGFuZCB0aGF0IHRoaXMgaXMgYSBmZWF0dXJlKS4NCkkgYWdyZWUgdGhhdCB0 aGUgY2xpZW50IGFwcCBpcyBmb3JjZWQsIGJ1dCBkaXNhZ3JlZSB0aGF0IHRoaXMgaXMgYSBmZWF0 dXJl4pi6Lg0KDQpGcm9tOiBCb2RvIE1vZWxsZXIgW21haWx0bzpibW9lbGxlckBhY20ub3JnXQ0K U2VudDogRnJpZGF5LCBTZXB0ZW1iZXIgMjYsIDIwMTQgMTE6NTMgQU0NClRvOiBBbmRyZWkgUG9w b3YNCkNjOiBBZGFtIExhbmdsZXk7IDx0bHNAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1RMU10g V29ya2luZyBHcm91cCBMYXN0IENhbGwgZm9yIGRyYWZ0LWlldGYtdGxzLWRvd25ncmFkZS1zY3N2 LTAwDQoNCkFuZHJlaSBQb3BvdiA8QW5kcmVpLlBvcG92QG1pY3Jvc29mdC5jb208bWFpbHRvOkFu ZHJlaS5Qb3BvdkBtaWNyb3NvZnQuY29tPj46DQoNClJlZ2FyZGxlc3Mgb2Ygd2hhdCB0aGUgYnJv d3NlciB3YW50cyB0byBkbywgdGhlIHN5c3RlbSBhZG1pbiB3aWxsIHNvbWV0aW1lcyBkaXNhYmxl IGEgc3BlY2lmaWMgVExTIHZlcnNpb24gbWFjaGluZS13aWRlIChvciBlbnRlcnByaXNlLXdpZGUp LCBlLmcuIGR1ZSB0byB2ZXJzaW9uLXNwZWNpZmljIHNlY3VyaXR5IGNvbmNlcm5zLg0KDQpUaGF0 J3Mgbm90IHN1cHBvcnRlZCB3aXRoIG5vcm1hbCBUTFMgdmVyc2lvbiBuZWdvdGlhdGlvbiBlaXRo ZXIgLS0gaWYgdGhlIGNsaWVudCBvZmZlcnMgdmVyc2lvbiBYLCB0aGUgc2VydmVyIG1heSBwaWNr IFkgKDwgWCkgd2l0aG91dCBoYXZpbmcgYW55IHdheSBvZiBrbm93aW5nIHRoYXQgWSBpcyBkaXNh YmxlZCBpbiB0aGUgY2xpZW50IHdoZXJlYXMgc29tZSBvdGhlciB2ZXJzaW9uIFogKDwgWSkgaXMg bm90Lg0KDQpJZiB5b3UgcmVhbGx5IHNlZSBhIGdvb2QgcmVhc29uIHRvIHN1cHBvcnQgdGhpcyAo d2hpY2ggSSBkb24ndCkgYW5kIGFyZSBjb25jZXJuZWQgYWJvdXQgbGF0ZW5jeSwgeW91J2QgYWxy ZWFkeSBuZWVkIHNvbWUgVExTIGV4dGVuc2lvbiB0byBzZW5kIHRoaXMgaW5mb3JtYXRpb24gZnJv bSB0aGUgY2xpZW50IHRvIHRoZSBzZXJ2ZXIuIEkndmUgbmV2ZXIgc2VlbiBhbnlvbmUgcHJvcG9z ZSB0aGlzLCBhbmQgd291bGQgYmUgc2tlcHRpY2FsIGFib3V0IGl0Lg0KDQpJIGFtIHBvaW50aW5n IG91dCB0aGF0LCB3aXRoIHRoZSBjdXJyZW50IGRyYWZ0LCB0aGUgYnJvd3NlciBpcyBmb3JjZWQg dG8gbm90IHNlbmQgdGhlIFNDU1Ygd2hlbiBza2lwcGluZyB2ZXJzaW9ucy4NCg0KSSdkIHJhdGhl ciBzYXkgdGhhdCB0aGUgY2xpZW50IGlzIGZvcmNlZCBub3QgdG8gc2tpcCB2ZXJzaW9ucyB3aGVu IHNlbmRpbmcgdGhlIFNDU1YgKGFuZCB0aGF0IHRoaXMgaXMgYSBmZWF0dXJlKS4NCg0KQm9kbw0K DQoNCg0K --_000_3217718b166c44b887feaab052335509BL2PR03MB419namprd03pro_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30N CmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5N c29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFw aA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJp Z2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5 cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN Cgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExp c3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjE4MDE4NDcwMzU7DQoJ bXNvLWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xOTY5NTc3ODQ2 IC0xNzY2NDIzMjIgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMg Njc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTM7fQ0KQGxpc3QgbDA6bGV2ZWwxDQoJe21zby1sZXZl bC1zdGFydC1hdDoxNjsNCgltc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674OYOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJbXNvLWJpZGktZm9u dC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10 YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMDpsZXZl bDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C pzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwwOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVs OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K QGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowaW47fQ0KdWwNCgl7bWFyZ2luLWJvdHRv bTowaW47fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVm YXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxv OmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwh W2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5r PSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29MaXN0 UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBs Zm8xIj48IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2Rp bmdzIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250Ojcu MHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwv c3Bhbj48IVtlbmRpZl0+SWYgeW91IHJlYWxseSBzZWUgYSBnb29kIHJlYXNvbiB0byBzdXBwb3J0 IHRoaXMgKHdoaWNoIEkgZG9uJ3QpIGFuZCBhcmUgY29uY2VybmVkIGFib3V0IGxhdGVuY3ksIHlv dSdkIGFscmVhZHkgbmVlZCBzb21lIFRMUyBleHRlbnNpb24gdG8gc2VuZCB0aGlzIGluZm9ybWF0 aW9uIGZyb20gdGhlIGNsaWVudCB0byB0aGUgc2VydmVyLiBJJ3ZlIG5ldmVyIHNlZW4gYW55b25l IHByb3Bvc2UgdGhpcywNCiBhbmQgd291bGQgYmUgc2tlcHRpY2FsIGFib3V0IGl0LjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 O2NvbG9yOiMxRjQ5N0QiPkkgdGhpbmsgYWxsIHRoYXQgbmVlZHMgdG8gYmUgZG9uZSBpcyBmb3Ig dGhlIGNsaWVudCB0byBzaWduYWwgdGhlIHByZXZpb3VzbHkgYXR0ZW1wdGVkIHZlcnNpb24sIHZp YSBleHRlbnNpb24gb3IgU0NTVi4gUmF0aGVyIHRoYW4ganVzdCBzYXlpbmcg4oCcSeKAmXZlIHRy aWVkIGENCiBoaWdoZXIgdmVyc2lvbiBiZWZvcmXigJ0sIHdoaWNoIGlzIHdoYXQgdGhlIGRyYWZ0 IGFsbG93cyBub3cuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1p bmRlbnQ6LS4yNWluO21zby1saXN0OmwwIGxldmVsMSBsZm8xIj48IVtpZiAhc3VwcG9ydExpc3Rz XT48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6V2luZ2RpbmdzIj48c3BhbiBzdHlsZT0ibXNvLWxp c3Q6SWdub3JlIj7DmDxzcGFuIHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21h biZxdW90OyI+Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+SSdkIHJhdGhl ciBzYXkgdGhhdCB0aGUgY2xpZW50IGlzIGZvcmNlZCBub3QgdG8gc2tpcCB2ZXJzaW9ucyB3aGVu IHNlbmRpbmcgdGhlIFNDU1YgKGFuZCB0aGF0IHRoaXMgaXMgYSBmZWF0dXJlKS48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztj b2xvcjojMUY0OTdEIj5JIGFncmVlIHRoYXQgdGhlIGNsaWVudCBhcHAgaXMgZm9yY2VkLCBidXQg ZGlzYWdyZWUgdGhhdCB0aGlzIGlzIGEgZmVhdHVyZTwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTpXaW5nZGluZ3M7Y29sb3I6IzFGNDk3RCI+Sjwvc3Bhbj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+LjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwv Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBCb2RvIE1vZWxsZXIgW21haWx0bzpibW9l bGxlckBhY20ub3JnXQ0KPGJyPg0KPGI+U2VudDo8L2I+IEZyaWRheSwgU2VwdGVtYmVyIDI2LCAy MDE0IDExOjUzIEFNPGJyPg0KPGI+VG86PC9iPiBBbmRyZWkgUG9wb3Y8YnI+DQo8Yj5DYzo8L2I+ IEFkYW0gTGFuZ2xleTsgJmx0O3Rsc0BpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4g UmU6IFtUTFNdIFdvcmtpbmcgR3JvdXAgTGFzdCBDYWxsIGZvciBkcmFmdC1pZXRmLXRscy1kb3du Z3JhZGUtc2Nzdi0wMDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+QW5kcmVpIFBvcG92ICZsdDs8YSBocmVmPSJtYWlsdG86QW5kcmVpLlBvcG92QG1p Y3Jvc29mdC5jb20iIHRhcmdldD0iX2JsYW5rIj5BbmRyZWkuUG9wb3ZAbWljcm9zb2Z0LmNvbTwv YT4mZ3Q7OjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7 Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0 O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+UmVnYXJkbGVzcyBvZiB3aGF0IHRoZSBicm93c2VyIHdhbnRzIHRvIGRvLCB0aGUgc3lzdGVt IGFkbWluIHdpbGwgc29tZXRpbWVzIGRpc2FibGUgYSBzcGVjaWZpYyBUTFMgdmVyc2lvbiBtYWNo aW5lLXdpZGUgKG9yIGVudGVycHJpc2Utd2lkZSksIGUuZy4gZHVlIHRvIHZlcnNpb24tc3BlY2lm aWMgc2VjdXJpdHkgY29uY2VybnMuPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0J3Mgbm90IHN1cHBvcnRlZCB3aXRoIG5vcm1h bCBUTFMgdmVyc2lvbiBuZWdvdGlhdGlvbiBlaXRoZXIgLS0gaWYgdGhlIGNsaWVudCBvZmZlcnMg dmVyc2lvbiBYLCB0aGUgc2VydmVyIG1heSBwaWNrIFkgKCZsdDsgWCkgd2l0aG91dCBoYXZpbmcg YW55IHdheSBvZiBrbm93aW5nIHRoYXQgWSBpcyBkaXNhYmxlZCBpbiB0aGUgY2xpZW50IHdoZXJl YXMgc29tZSBvdGhlciB2ZXJzaW9uIFogKCZsdDsgWSkgaXMgbm90LjxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB5b3UgcmVhbGx5IHNlZSBh IGdvb2QgcmVhc29uIHRvIHN1cHBvcnQgdGhpcyAod2hpY2ggSSBkb24ndCkgYW5kIGFyZSBjb25j ZXJuZWQgYWJvdXQgbGF0ZW5jeSwgeW91J2QgYWxyZWFkeSBuZWVkIHNvbWUgVExTIGV4dGVuc2lv biB0byBzZW5kIHRoaXMgaW5mb3JtYXRpb24gZnJvbSB0aGUgY2xpZW50IHRvIHRoZSBzZXJ2ZXIu IEkndmUgbmV2ZXIgc2VlbiBhbnlvbmUgcHJvcG9zZSB0aGlzLCBhbmQgd291bGQNCiBiZSBza2Vw dGljYWwgYWJvdXQgaXQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzow aW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkkgYW0gcG9pbnRpbmcgb3V0IHRoYXQsIHdpdGggdGhlIGN1cnJl bnQgZHJhZnQsIHRoZSBicm93c2VyIGlzIGZvcmNlZCB0byBub3Qgc2VuZCB0aGUgU0NTViB3aGVu IHNraXBwaW5nIHZlcnNpb25zLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdkIHJhdGhlciBzYXkgdGhhdCB0aGUgY2xpZW50IGlz IGZvcmNlZCBub3QgdG8gc2tpcCB2ZXJzaW9ucyB3aGVuIHNlbmRpbmcgdGhlIFNDU1YgKGFuZCB0 aGF0IHRoaXMgaXMgYSBmZWF0dXJlKS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Qm9kbzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_3217718b166c44b887feaab052335509BL2PR03MB419namprd03pro_-- From nobody Fri Sep 26 11:58:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4761A6FAB for ; Fri, 26 Sep 2014 11:58:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqNgIEljsZol for ; Fri, 26 Sep 2014 11:58:55 -0700 (PDT) Received: from mail-oi0-f49.google.com (mail-oi0-f49.google.com [209.85.218.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D1271A6F9F for ; Fri, 26 Sep 2014 11:58:55 -0700 (PDT) Received: by mail-oi0-f49.google.com with SMTP id e131so512340oig.36 for ; Fri, 26 Sep 2014 11:58:54 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HHouj9joNtL9ml6I8G4yI2b16dmr9xWKmMFpLw9nxaQ=; b=lbm0I3cJgmZzng6ncV0ARhxG0g7b4wHYvbnNItw7JVqiyJ4AMZp+8bd689QX17zZ1L Vj8UMT/kd921oiOcFGOSrjw5Miml6M/5P9OizVbTChIlMN97Dr2vkKy6Erll68YJYDoe 2ZaZNY7E0ynANsjjdDQ277BPyX9GtNxqVoYM0ekft4eCocuB5tBpy+3XK1IKj+7CQpaG xlh9lMxjzck9xTiKuIeIVGvTtLMJ7dLEzUg3QtdPRbDuOCnFPbXrUDhQHUQ6y9H9lZxm VjHaD2MU7aZt2joj4V+xnZ5GA5b1L2FNNhgSVtky2K6XztQyIwSsm568pMQGKTAIlklF NGXA== X-Gm-Message-State: ALoCoQmyD3RvuCmOnnAngMWwhh966wiNYGBngw+163SdiE0kL3WpXdiY3zebcB8KC4vMSbCwpnQD MIME-Version: 1.0 X-Received: by 10.60.58.36 with SMTP id n4mr24095404oeq.73.1411757934321; Fri, 26 Sep 2014 11:58:54 -0700 (PDT) Received: by 10.76.74.36 with HTTP; Fri, 26 Sep 2014 11:58:54 -0700 (PDT) In-Reply-To: References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> Date: Fri, 26 Sep 2014 11:58:54 -0700 Message-ID: From: Brian Smith To: Bodo Moeller Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/rXIskUjEJuL5rhPk6kEutO7dQ-c Cc: "" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 26 Sep 2014 18:58:58 -0000 On Fri, Sep 26, 2014 at 12:34 AM, Bodo Moeller wrote: >> I'm OK with that, but if this is the real reason for the MUST, then >> it's not particularly clear. > > Hm, maybe so. I can add a brief note showing how the handshake would fail if > the server acts on the SCSV in this case, but I don't think the document > should have to explain why we require the client to omit the SCSV rather > than having the server ignore it. (Why would you want to send it if nothing > follows from that?) Here is what the draft actually says: However, as an exception to the above, when the client intends to perform an abbreviated handshake to resume a previously negotiated session and sets ClientHello.client_version to the protocol version negotiated for that session, the client MUST NOT include TLS_FALLBACK_SCSV in ClientHello.cipher_suites. So, if the client does NOT set ClientHello.client_version to the version negotiated for that session, then the client MAY send the SCSV in the resumption handshake. Now, if the server could indicate that it supports the SCSV somehow in its ServerHello, then the client could save that acknowledgement in the session state, and then make sure that it always sets ClientHello.client_version to the highest version it supports, regardless of the version that it negotiated for the session it is trying to resume. That would be a very worthwhile addition to the mechanism. Cheers, Brian From nobody Fri Sep 26 12:05:30 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA37A1A6F10 for ; Fri, 26 Sep 2014 12:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WKqxHqs1L9Iu for ; Fri, 26 Sep 2014 12:05:23 -0700 (PDT) Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com [209.85.218.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A16C31A00AE for ; Fri, 26 Sep 2014 12:05:23 -0700 (PDT) Received: by mail-oi0-f54.google.com with SMTP id a3so10274766oib.27 for ; Fri, 26 Sep 2014 12:05:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=I6KlL6kufX3DWu2eY+rzys/paR9m9CgJyyHZEvuiUuo=; b=MVjUdRcBLKeuoyFRGLeueYBguzbPaqUk9OH4mh+RIIcxb3vCA1t7cajAn7wyaCzAC0 8R12OXWsw6brpY6jeyM8e0u9PcD2HFvLvFEKvrxbtqcwNBhDvO/iMCCdsh7MVhaqKWxz kbyQQqdLB96oCTPr2obz4J1yyUtbTADy7KbtBSGLEAmhFEW8KVQTHeawshs0byNPmDVT rEcX/6Lpm35XSsXizN8Au0sCsm9tBwCaY3tW9COjd7oMX8RMI56GjsXYD5Yr5aGQ5X3p pKn7aC2OCUqpOAcW1ORqnEqWO8JJsNDU0N4idPxlWkveoa60bBzniYp7yb8frXTJC/uv oDsw== X-Gm-Message-State: ALoCoQk2EZ4cdn7UBhF50aX3f72qB97K3MB65A3dRuPjOYPbHCpeXhOBmCZzbC71kExfFgNTNS5p MIME-Version: 1.0 X-Received: by 10.60.38.67 with SMTP id e3mr23673609oek.62.1411758323082; Fri, 26 Sep 2014 12:05:23 -0700 (PDT) Received: by 10.76.74.36 with HTTP; Fri, 26 Sep 2014 12:05:22 -0700 (PDT) In-Reply-To: <3217718b166c44b887feaab052335509@BL2PR03MB419.namprd03.prod.outlook.com> References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <3217718b166c44b887feaab052335509@BL2PR03MB419.namprd03.prod.outlook.com> Date: Fri, 26 Sep 2014 12:05:22 -0700 Message-ID: From: Brian Smith To: Andrei Popov Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/0qQn75DVUBo1NUgUGheVayNEMWg Cc: Adam Langley , "" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 26 Sep 2014 19:05:26 -0000 On Fri, Sep 26, 2014 at 11:58 AM, Andrei Popov wrote: > I agree that the client app is forced, but disagree that this is a featureJ. I think the goal should be, in the long term, to remove the non-secure downgrade bug from the clients. The semantics of the current draft are aligned with that goal. Additional features were added to the mechanism to allow for version skipping would be incompatible with that goal. In other words, the feature/bug where the client system administrator can disable arbitrary versions of TLS (e.g. TLS 1.0 enabled, TLS 1.1 disabled, and TLS 1.2 enabled) depends on the client having the non-secure version downgrade bug, and thus seems like a bad thing, all things considered. (We considered allowing that kind of flexibility in the NSS API, and decided against it, for this reason. So, in NSS, you can choose which range of versions to use, but you can't poke holes within that range.) Cheers, Brian From nobody Fri Sep 26 12:09:44 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A1BF1A1A28 for ; Fri, 26 Sep 2014 12:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.714 X-Spam-Level: X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9HBSVNhki1pp for ; Fri, 26 Sep 2014 12:09:43 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.17.13]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 209331A1A0B for ; Fri, 26 Sep 2014 12:09:43 -0700 (PDT) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) by mrelayeu.kundenserver.de (node=mreue103) with ESMTP (Nemesis) id 0LyBrp-1YIUwD3QZh-015cST; Fri, 26 Sep 2014 21:09:41 +0200 Received: by mail-qa0-f41.google.com with SMTP id cm18so6591609qab.28 for ; Fri, 26 Sep 2014 12:09:38 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.140.19.178 with SMTP id 47mr25230655qgh.28.1411758578540; Fri, 26 Sep 2014 12:09:38 -0700 (PDT) Received: by 10.140.156.5 with HTTP; Fri, 26 Sep 2014 12:09:38 -0700 (PDT) In-Reply-To: <4362f4b71cb44ebd80629d52dd791437@BL2PR03MB419.namprd03.prod.outlook.com> References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> <4362f4b71cb44ebd80629d52dd791437@BL2PR03MB419.namprd03.prod.outlook.com> Date: Fri, 26 Sep 2014 21:09:38 +0200 Message-ID: From: Bodo Moeller To: Andrei Popov Content-Type: multipart/alternative; boundary=001a1134f6f8952dfe0503fca808 X-Provags-ID: V02:K0:vLRvrQrGQyzXJIjaqMtYCBYwzFU8QPeZDV0/7p1SLgx D4QaPLkx5GsEHSi5t/shAgwR4vpw/mWSZWn+0fPYORRXfkCPwP xqKMKP1Av6uUxfu46SgZSJ1voADEQ8Y3PsbxVG+eDTnWfs3uro y1vldMj/HIUUUalUz7BSy8b7DmhGzkne11vdrre6ADuKUpNC/a 6q8T1mmVSAbcqvIBQFXtCh8AmPlzJAYu/Edpfl7EH/Obxu2ZTw jOyxUMNd5RhGdIS7MN9u3W4aPt2e0f0LuHab1WIK2exH802ngM ozTUGLaiN9qGWRgl/Qewadyu0rY1CozvCnFW+v78+AsCBHDiBn oLhRSnbbL+IBYDagloSEDZoh/B3CblRRJmL5dgQcf6hGHZFTxv iWZibi8HbSB93V3jy8Bu2LWypqKqJDf7a+GAxDltQjwRm0ehGN BvRQP X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/alOeX7ZvmE3rkda9-xag6Nv__sc Cc: Adam Langley , "" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 26 Sep 2014 19:09:44 -0000 --001a1134f6f8952dfe0503fca808 Content-Type: text/plain; charset=UTF-8 Andrei Popov : > In any case, the client app has a workaround (which is to not send the > downgrade SCSV when skipping TLS versions). Well, that could sometimes be acceptable. Or do send the downgrade SCSV for the version that you want to skip just to confirm that it's this server's highest supported protocol, and then just use the previous version instead (in a new connection). There's an extra latency penalty in this, but I consider this version-skipping scenario very unlikely and we haven't ever bothered to address this in standard version negotiation either (the client can't send a list of supported protocol versions) and so have a similar latency penalty there, so I don't think we should consider this a serious drawback. This workaround is far from perfect, but I can live with the current > downgrade-scsv draft if I have to. In this case, the fix is pretty trivial, > so I thought it was worth bringing this up. You mean, version-specific SCSVs? I'd rather not do that, because then there's much more to do (and possibly get wrong) in servers. And even if we allocate a bunch of SCSVs for future protocol versions, at some point we might run out. (As an aside, if latency is the utmost concern, you don't strictly have to try protocol versions in sequence -- you could do multiple connections in parallel. However, that shouldn't be the norm. We *do* have version negotiation in the protocol, after all. We shouldn't forget that the entire fallback business is about servers that aren't just up to date with the latest protocol version, but are exceptionally broken on top of that.) Bodo --001a1134f6f8952dfe0503fca808 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Andr= ei Popov <Andrei.Popov@microsoft.com>:
=C2= =A0
In any case, the client app has a workaround (which is to not send the down= grade SCSV when skipping TLS versions).

Wel= l, that could sometimes be acceptable. Or do send the downgrade SCSV for th= e version that you want to skip just to confirm that it's this server&#= 39;s highest supported protocol, and then just use the previous version ins= tead (in a new connection). There's an extra latency penalty in this, b= ut I consider this version-skipping scenario very unlikely and we haven'= ;t ever bothered to address this in standard version negotiation either (th= e client can't send a list of supported protocol versions) and so have = a similar latency penalty there, so I don't think we should consider th= is a serious drawback.

= This workaround is far from perfect, but I can live with the current downgr= ade-scsv draft if I have to. In this case, the fix is pretty trivial, so I = thought it was worth bringing this up.

You = mean, version-specific SCSVs? I'd rather not do that, because then ther= e's much more to do (and possibly get wrong) in servers. And even if we= allocate a bunch of SCSVs for future protocol versions, at some point we m= ight run out.


(As an aside, if late= ncy is the utmost concern, you don't strictly have to try protocol vers= ions in sequence -- you could do multiple connections in parallel. However,= that shouldn't be the norm. We *do* have version negotiation in the pr= otocol, after all. We shouldn't forget that the entire fallback busines= s is about servers that aren't just up to date with the latest protocol= version, but are exceptionally broken on top of that.)

Bodo




--001a1134f6f8952dfe0503fca808-- From nobody Fri Sep 26 12:38:36 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F19B21A1A80 for ; Fri, 26 Sep 2014 12:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.714 X-Spam-Level: X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZQ9L4DEn-Pf for ; Fri, 26 Sep 2014 12:38:34 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.130]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 996A01A00AE for ; Fri, 26 Sep 2014 12:38:33 -0700 (PDT) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) by mrelayeu.kundenserver.de (node=mreue003) with ESMTP (Nemesis) id 0MFflp-1XRspv419Z-00Ecw7; Fri, 26 Sep 2014 21:38:31 +0200 Received: by mail-qg0-f48.google.com with SMTP id z107so9259370qgd.7 for ; Fri, 26 Sep 2014 12:38:27 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.224.128.129 with SMTP id k1mr26495808qas.69.1411760307750; Fri, 26 Sep 2014 12:38:27 -0700 (PDT) Received: by 10.140.156.5 with HTTP; Fri, 26 Sep 2014 12:38:27 -0700 (PDT) In-Reply-To: References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> Date: Fri, 26 Sep 2014 21:38:27 +0200 Message-ID: From: Bodo Moeller To: Brian Smith Content-Type: multipart/alternative; boundary=001a1132f694a6e4520503fd0f0b X-Provags-ID: V02:K0:f7X6vzI5tmnz/ksJDK+3wkAunceYHNSl6V/uXP+DdAw A0rWmcDIkRk7qn7JusNqMoadG6qgB1G6WyPimjdiKddKExxAoo sfH4HZfXZuAzcn5xJKaJStPFEGJctF0y8eislTk4P8NgsBoeAx EmUaAIUXBk445dI8a3XGmV4SMnra2FfSoZJFF1HvB62dLCC5K9 dhxIbJ0HmIdarV6o0M7W0ImD4nogMrHfMSwEYG3eY8VqrdrbbD nztb7l54l0meVfkisgI499cfWODuWdo46CoT7OKcWwhOYzndXv d8wltZING083mAQojQ3J4jXOEQZrNMlJdllETT8X8rNCKBTSHg PuHaZhEKf8t3FyFQ3wlz4Q4hxXtW4l/EM7Ia/O+rBmNzdqldOi gf+vFZqUXOdNGcE8eE96tCJ37xM6GCjtVQwBex9y5M6oiC2vFY 9u13L X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Huwa8zV6zPTgcqgkqxUiAU2PhwE Cc: "" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 26 Sep 2014 19:38:35 -0000 --001a1132f694a6e4520503fd0f0b Content-Type: text/plain; charset=UTF-8 Brian Smith : > On Fri, Sep 26, 2014 at 12:34 AM, Bodo Moeller wrote: > > >> I'm OK with that, but if this is the real reason for the MUST, then > >> it's not particularly clear. > > > > Hm, maybe so. I can add a brief note showing how the handshake would > fail if > *Could* fail, sorry. (As already explained by Martin, the problem appears if by the time you try to resume, the server supports additional protocol versions. Of course that could also happen for an immediate retry, and you'll have to live with it then; so I wonder if that "MUST" isn't too strict after all: if you're willing to start over on inappropriate_fallback, you might actually prefer to send TLS_FALLBACK_SCSV *in order* to get a connection failure if the server has been updated.) > the server acts on the SCSV in this case, but I don't think the document > > should have to explain why we require the client to omit the SCSV rather > > than having the server ignore it. (Why would you want to send it if > nothing > > follows from that?) > > Here is what the draft actually says: > > However, as an exception to the above, when the client intends to > perform an abbreviated handshake to resume a previously negotiated > session and sets ClientHello.client_version to the protocol > version negotiated for that session, the client MUST NOT include > TLS_FALLBACK_SCSV in ClientHello.cipher_suites. > > So, if the client does NOT set ClientHello.client_version to the > version negotiated for that session, then the client MAY send the SCSV > in the resumption handshake. > > Now, if the server could indicate that it supports the SCSV somehow in > its ServerHello, then the client could save that acknowledgement in > the session state, and then make sure that it always sets > ClientHello.client_version to the highest version it supports, > regardless of the version that it negotiated for the session it is > trying to resume. Hm, if you can set ClientHello.client_version to the highest version supported by the client and the server tolerates that, you shouldn't be employing the fallback mechanism with this server in the first place. Bodo --001a1132f694a6e4520503fd0f0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Bria= n Smith <brian@briansmith.org>:
On Fri, Sep 26, 2014 at 12:34 AM, Bodo Moeller= <bmoeller@acm.org> wrote:
=C2=A0
>> I'm OK with that, but if this is the real reason for the MUST,= then
>> it's not particularly clear.
>
> Hm, maybe so. I can add a brief note showing how the handshake would f= ail if

*Could* fail, sorry.= (As already explained by Martin, the problem appears if by the time you tr= y to resume, the server supports additional protocol versions. Of course th= at could also happen for an immediate retry, and you'll have to live wi= th it then; so I wonder if that "MUST" isn't too strict after= all: if you're willing to start over on=C2=A0inappropriate_fallback, y= ou might actually prefer to send TLS_FALLBACK_SCSV *in order* to get a conn= ection failure if the server has been updated.)

> the server acts on the SCSV in this case, but I don't think the do= cument
> should have to explain why we require the client to omit the SCSV rath= er
> than having the server ignore it. (Why would you want to send it if no= thing
> follows from that?)

Here is what the draft actually says:

=C2=A0 =C2=A0 =C2=A0 However, as an exception to the above, when the client= intends to
=C2=A0 =C2=A0 =C2=A0 perform an abbreviated handshake to resume a previousl= y negotiated
=C2=A0 =C2=A0 =C2=A0 session and sets ClientHello.client_version to the pro= tocol
=C2=A0 =C2=A0 =C2=A0 version negotiated for that session, the client MUST N= OT include
=C2=A0 =C2=A0 =C2=A0 TLS_FALLBACK_SCSV in ClientHello.cipher_suites.

So, if the client does NOT set ClientHello.client_version to the
version negotiated for that session, then the client MAY send the SCSV
in the resumption handshake.

Now, if the server could indicate that it supports the SCSV somehow in
its ServerHello, then the client could save that acknowledgement in
the session state, and then make sure that it always sets
ClientHello.client_version to the highest version it supports,
regardless of the version that it negotiated for the session it is
trying to resume.

Hm, if you can set Client= Hello.client_version to the highest version supported by the client and the= server tolerates that, you shouldn't be employing the fallback mechani= sm with this server in the first place.

Bodo
=

--001a1132f694a6e4520503fd0f0b-- From nobody Fri Sep 26 13:02:57 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 662CC1A01EE for ; Fri, 26 Sep 2014 13:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYjzCN7rOB5y for ; Fri, 26 Sep 2014 13:02:53 -0700 (PDT) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5EDC1A00A3 for ; Fri, 26 Sep 2014 13:02:53 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id vb8so1262934obc.7 for ; Fri, 26 Sep 2014 13:02:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dqp2/18ieb6cr0KNQ9zK3q2CQxHFU/pWTAFSP3XsCtw=; b=RM8Zf0d63Yj/JqIISgm5uGXKcQg/Atwf1oCu19htYk4OX2gdKkcyz6IV8//TM4chR0 9LlOMwZIcnR+eWDB/27hVDorwV9qsT+V67SoouXaIhiul6KO1ZfMi+4JveJzeiGEDRQf EWRSKttcuQrpYfY8vIPZjzsIFkDYn0dBNbx8mMongeX/DLQwp5M5upK31jTpsazx8EFj SehwFWvhOfHhqyYgn9o4L+0yn9spYZDrrnzGSXbcvkws8PGL2vBAQ/gtLIrQpeZUnS5a zzj01a56/2P2Q7WUVVULpdHGCwYMIzmxGVYGu7OMjUBvRE48l1FMCb75kMAOpitoB3k7 AcZQ== X-Gm-Message-State: ALoCoQmfI72JhL9fQTSOgHhukq0u11DUwBaoVqMxuPH5CVUD1VAO23JeUad9HvINf1A/fQsp1Wzy MIME-Version: 1.0 X-Received: by 10.182.126.233 with SMTP id nb9mr23823370obb.46.1411761772953; Fri, 26 Sep 2014 13:02:52 -0700 (PDT) Received: by 10.76.74.36 with HTTP; Fri, 26 Sep 2014 13:02:52 -0700 (PDT) In-Reply-To: References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> Date: Fri, 26 Sep 2014 13:02:52 -0700 Message-ID: From: Brian Smith To: Bodo Moeller Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/fTtQFE4TeBRfyuK6R3Vyr3z4kCA Cc: "" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 26 Sep 2014 20:02:55 -0000 On Fri, Sep 26, 2014 at 12:38 PM, Bodo Moeller wrote: > Brian Smith : >> On Fri, Sep 26, 2014 at 12:34 AM, Bodo Moeller wrote: > *Could* fail, sorry. (As already explained by Martin, the problem appears if > by the time you try to resume, the server supports additional protocol > versions. Of course that could also happen for an immediate retry, and > you'll have to live with it then; so I wonder if that "MUST" isn't too > strict after all: if you're willing to start over on inappropriate_fallback, > you might actually prefer to send TLS_FALLBACK_SCSV *in order* to get a > connection failure if the server has been updated.) Right. In general, a resumption ClientHello SHOULD be just like a non-resumption ClientHello, except for the presence of the session ID and/or session ticket, because a resumption ClientHello is potentially the start of a full handshake. The TLS specs (TLS 1.2, in this case) say: Whenever a client already knows the highest protocol version known to a server (for example, when resuming a session), it SHOULD initiate the connection in that native protocol. However, actually the client does not ever know the highest protocol version the server supports, because the server may have expanded its version support since the last time the client contacted it. But, the consequence of that sentence is that at least NSS sends the session version as client_version instead of its actual max supported version. I think that is wrong. However, it isn't clear if there are compatibility issues with changing that. >> Here is what the draft actually says: >> >> However, as an exception to the above, when the client intends to >> perform an abbreviated handshake to resume a previously negotiated >> session and sets ClientHello.client_version to the protocol >> version negotiated for that session, the client MUST NOT include >> TLS_FALLBACK_SCSV in ClientHello.cipher_suites. >> >> So, if the client does NOT set ClientHello.client_version to the >> version negotiated for that session, then the client MAY send the SCSV >> in the resumption handshake. >> >> Now, if the server could indicate that it supports the SCSV somehow in >> its ServerHello, then the client could save that acknowledgement in >> the session state, and then make sure that it always sets >> ClientHello.client_version to the highest version it supports, >> regardless of the version that it negotiated for the session it is >> trying to resume. > > Hm, if you can set ClientHello.client_version to the highest version > supported by the client and the server tolerates that, you shouldn't be > employing the fallback mechanism with this server in the first place. I had thought that NSS was changed to use the session version for ClientHello.client_version during resumption for compatibility reasons. However, looking at the change history, it appears to be the case that that change was made coincidentally with a compatibility fix for renegotiation, not initial resumption handshakes. So, it may be the case that it is already safe to always send the max supported version as client_version in an initial resumption handshake, without any indication from the server, even in the non-secure fallback case. It would require some implementation to make that change and test the compatibility to know for sure. Cheers, Brian From nobody Fri Sep 26 13:21:37 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C28C01A6FF9 for ; Fri, 26 Sep 2014 13:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.714 X-Spam-Level: X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 46sXSC9TrccM for ; Fri, 26 Sep 2014 13:21:31 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B1CE1A6FE8 for ; Fri, 26 Sep 2014 13:21:31 -0700 (PDT) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) by mrelayeu.kundenserver.de (node=mreue001) with ESMTP (Nemesis) id 0Lf3PM-1Y4W0U3kPA-00okhO; Fri, 26 Sep 2014 22:21:27 +0200 Received: by mail-qg0-f48.google.com with SMTP id z107so9584713qgd.35 for ; Fri, 26 Sep 2014 13:21:25 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.229.29.3 with SMTP id o3mr7561109qcc.10.1411762885701; Fri, 26 Sep 2014 13:21:25 -0700 (PDT) Received: by 10.140.156.5 with HTTP; Fri, 26 Sep 2014 13:21:25 -0700 (PDT) In-Reply-To: References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> Date: Fri, 26 Sep 2014 22:21:25 +0200 Message-ID: From: Bodo Moeller To: Brian Smith Content-Type: multipart/alternative; boundary=001a1134bbbe4f39910503fda9f6 X-Provags-ID: V02:K0:iebj5YW2UyJyK9g1pJGEHzs6DSvGmLsYkb1SN3XW75X 9xjjaYkqt8gkd08hTOXisJ6tjbILw872LFkTZov7QxduqLpV9E 6pGQCALhVz6YrwBH4eRF9GbzXCDpi+6DPKDijn8PjyzJhYfZe8 Y3fp+CbsVmUVvNUo/ExMvCl5Ih8ZV01bkniz5YanDYPAPGFYht ZYAFPusWIKb0TRAVrxj44UCGmdaBhy+DEtK+GoqKwQMVPiQSQX g8amtZ0wt94GpK4wfukYgZsGpVaFmVjeEhCupLUykfch6uvLOy x4XLk+JmlGenHcM96l15nr40mc3sujZhTTpdfd4QmtwJax2I9J 1cIRQRss7Qs2v1EjtpY3c4Y7NQ7c6kMCkSV7/ZAkpJItI6TMUm kxJZw9UbXhuoCByHvXHCYvOwAROauhiE8hCBvdemI18wa2VS7O Q424d X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/nf1DoUBp_-n6nNSX2koTV-eugno Cc: "" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 26 Sep 2014 20:21:35 -0000 --001a1134bbbe4f39910503fda9f6 Content-Type: text/plain; charset=UTF-8 > > > > *Could* fail, sorry. (As already explained by Martin, the problem > appears if > > by the time you try to resume, the server supports additional protocol > > versions. Of course that could also happen for an immediate retry, and > > you'll have to live with it then; so I wonder if that "MUST" isn't too > > strict after all: if you're willing to start over on > inappropriate_fallback, > > you might actually prefer to send TLS_FALLBACK_SCSV *in order* to get a > > connection failure if the server has been updated.) > > Right. In general, a resumption ClientHello SHOULD be just like a > non-resumption ClientHello, except for the presence of the session ID > and/or session ticket, because a resumption ClientHello is potentially > the start of a full handshake. > > The TLS specs (TLS 1.2, in this case) say: > > Whenever a client already knows the highest protocol version known to > a server (for example, when resuming a session), it SHOULD initiate > the connection in that native protocol. > > However, actually the client does not ever know the highest protocol > version the server supports, because the server may have expanded its > version support since the last time the client contacted it. But, the > consequence of that sentence is that at least NSS sends the session > version as client_version instead of its actual max supported version. > I think that is wrong. Well, arguably it is, but at least if you had to do an additional fallback handshake just to successfully complete a handshake (which is the situation we unfortunately have to concern us with here), you probably wouldn't want to repeat this trial-and-error on every session resumption. So if we accept that fallback handshakes can be a necessity, we also have to accept that lowered client_version on resumption as a fact of life. > So, it may be > the case that it is already safe to always send the max supported > version as client_version in an initial resumption handshake, without > any indication from the server, even in the non-secure fallback case. If the server is version-intolerant for new sessions, why would it be tolerant on (attempted) resumption? Bodo --001a1134bbbe4f39910503fda9f6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

> *Could* fail, sorry. (As already explained by Martin, the problem appe= ars if
> by the time you try to resume, the server supports additional protocol=
> versions. Of course that could also happen for an immediate retry, and=
> you'll have to live with it then; so I wonder if that "MUST&q= uot; isn't too
> strict after all: if you're willing to start over on inappropriate= _fallback,
> you might actually prefer to send TLS_FALLBACK_SCSV *in order* to get = a
> connection failure if the server has been updated.)
=C2=A0
Right. In general, a resumption ClientHello SHOULD be just like a non-resumption ClientHello, except for the presence of the session ID
and/or session ticket, because a resumption ClientHello is potentially
the start of a full handshake.

The TLS specs (TLS 1.2, in this case) say:

=C2=A0 =C2=A0Whenever a client already knows the highest protocol version k= nown to
=C2=A0 =C2=A0a server (for example, when resuming a session), it SHOULD ini= tiate
=C2=A0 =C2=A0the connection in that native protocol.

However, actually the client does not ever know the highest protocol
version the server supports, because the server may have expanded its
version support since the last time the client contacted it. But, the
consequence of that sentence is that at least NSS sends the session
version as client_version instead of its actual max supported version.
I think that is wrong.

Well, arguably it is= , but at least if you had to do an additional fallback handshake just to su= ccessfully complete a handshake (which is the situation we unfortunately ha= ve to concern us with here), you probably wouldn't want to repeat this = trial-and-error on every session resumption.

So if= we accept that fallback handshakes can be a necessity, we also have to acc= ept that lowered client_version on resumption as a fact of life.
=

=C2=A0
So= , it may be
the case that it is already safe to always send the max supported
version as client_version in an initial resumption handshake, without
any indication from the server, even in the non-secure fallback case.

If the server is version-intolerant for new sess= ions, why would it be tolerant on (attempted) resumption?

Bodo

=C2=A0
--001a1134bbbe4f39910503fda9f6-- From nobody Fri Sep 26 13:31:23 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFDB51A0331 for ; Fri, 26 Sep 2014 13:31:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AlTsu7wdJk2z for ; Fri, 26 Sep 2014 13:31:20 -0700 (PDT) Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 011541A0330 for ; Fri, 26 Sep 2014 13:31:19 -0700 (PDT) Received: by mail-ob0-f174.google.com with SMTP id m8so10408372obr.5 for ; Fri, 26 Sep 2014 13:31:19 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=BCnMC/YJpclTD0gDvDAtanMSwjAl1JqkAqVlcOtJirk=; b=gMuGGSZ8+2bZZjZHK/R1B02AbWsiRUjx9s7mQgt+SE1mr6zjU01goaRHj8pEDILhLE z+8S1wqgZgWVHKp7OJ6MmiB80w+xPmZDhDwV1IP7/Kb8UArvdY405147DlvoGfjSPJH3 +jnUKN+r87eWXq8ON+XBF+K1+K4xd+FurA28lXuLzaN4q8YTBAxRBsRpWiSB1OAlph0d SsODt5D6Bya0MjIreNXqABdsVkVZKgXcvyjwPdiSsVPjhgI9MT/0jNRgmS3MPfY2u5qv Qeq9cOF/eMVCl6Z/G4RhLRmOXQSEP+G2R7yckugs0lqKZNWVHad9B2a+HT0MUNQ8DKcw Vn8Q== X-Gm-Message-State: ALoCoQk+WIXo8F3JNHY5RqopKIwYvc3Db4OdOcLUOk3zoOAlMtRlwpH/HrDPZRMlEaXKCOPPY99y MIME-Version: 1.0 X-Received: by 10.182.33.99 with SMTP id q3mr24408506obi.28.1411763479183; Fri, 26 Sep 2014 13:31:19 -0700 (PDT) Received: by 10.76.74.36 with HTTP; Fri, 26 Sep 2014 13:31:19 -0700 (PDT) In-Reply-To: References: <2112FCAD-4820-49D9-9871-6501C83A554D@cisco.com> Date: Fri, 26 Sep 2014 13:31:19 -0700 Message-ID: From: Brian Smith To: Bodo Moeller Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/zSMSksxtAK-W5Xs_sxjGH2Pgodk Cc: "" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 26 Sep 2014 20:31:21 -0000 On Fri, Sep 26, 2014 at 1:21 PM, Bodo Moeller wrote: > If the server is version-intolerant for new sessions, why would it be > tolerant on (attempted) resumption? First, the client tries to handshake with client_version == TLS 1.2 and fails . Then the client tries to handshake with client_version == TLS 1.1 and succeeds, with the server choosing TLS 1.0. Later, the client tries to resume the previously negotiated session. It could choose client_version == TLS 1.1 (ignoring the session version, but remembering the version intolerance), or it could choose client_version == TLS 1.0 (using the session version). My argument is that the client should choose client_version == TLS 1.1 and send the SCSV. Cheers, Brian From nobody Fri Sep 26 18:32:17 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0861A00F4 for ; Fri, 26 Sep 2014 18:32:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ARAiYYTNPO4 for ; Fri, 26 Sep 2014 18:32:13 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 3A2861A00E7 for ; Fri, 26 Sep 2014 18:32:13 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id B7294BE54; Sat, 27 Sep 2014 02:32:11 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uWkC_bpRd6J4; Sat, 27 Sep 2014 02:32:10 +0100 (IST) Received: from [10.87.48.7] (unknown [86.46.23.135]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 78EEABE47; Sat, 27 Sep 2014 02:32:10 +0100 (IST) Message-ID: <5426139A.4070008@cs.tcd.ie> Date: Sat, 27 Sep 2014 02:32:10 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Adam Langley References: <462E2EC4-A285-4D02-9156-D8C94D6BE107@cisco.com> <1D2C7BAF-A3EF-45B8-87EB-EB4DFD2C3C7F@cisco.com> <540F543E.8080505@cs.tcd.ie> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/lbTujAkJU8X1NNk6If8Qhx3G1Ao Cc: "tls@ietf.org" Subject: Re: [TLS] Early code-point assignment for draft-ietf-tls-session-hash X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 27 Sep 2014 01:32:16 -0000 On 26/09/14 01:37, Adam Langley wrote: > On Tue, Sep 9, 2014 at 12:25 PM, Stephen Farrell > wrote: >> I've now gotten to that and plan to approve this early >> allocation. Be great if the wg can finish up the draft >> soon too - there's a 1 year timer that starts when IANA >> do the allocation. > > Any signs of this early allocation? I don't see anything on the IANA pages. Sorted. 23 it is. [1] S. [1] http://www.iana.org/assignments/tls-extensiontype-values > > > Cheers > > AGL > From nobody Fri Sep 26 18:56:44 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2CAC1A0125 for ; Fri, 26 Sep 2014 18:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AFwo2I-aWZhJ for ; Fri, 26 Sep 2014 18:56:41 -0700 (PDT) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 447431A0101 for ; Fri, 26 Sep 2014 18:56:38 -0700 (PDT) Received: by mail-lb0-f170.google.com with SMTP id n15so3704282lbi.1 for ; Fri, 26 Sep 2014 18:56:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=YGba7XwBGoF7vtI8S7WuWidt2+mjRZ6vsDluXFkkHkA=; b=fDiD3HgfiEUU3BCJ3X3blPLq3a9Kq3x0+yehcevoTWcgZncJvgqhKAjZlKQ4gk2wYp 2oy7U7I5ANKqW7mOKTVoe3xAQT1Kz1I+yUywKvKv8NBsF0fZb/KQj+ATzoLFUsaoDGNy T3qi4Hfgxr/ZyV3Aa8zWgY9ERN0izlomPxLSiuBynjiTyefqgtMslnQzOKJkfSFTPLPY 7sl9aLd8ckWV6ynrFkIwI6kssSlOUoX1edswgXWJUDHqWm+oF6ImnO9UkWSkHGmb5N/u uYPuxoBg/4GOXpjYbNkshKQN4uETulVVbSUhIPsvMW/ULxz1x4Ppe/rWqPeklI/iKAzp zrMA== MIME-Version: 1.0 X-Received: by 10.152.197.35 with SMTP id ir3mr24566696lac.82.1411782997325; Fri, 26 Sep 2014 18:56:37 -0700 (PDT) Sender: alangley@gmail.com Received: by 10.112.241.103 with HTTP; Fri, 26 Sep 2014 18:56:37 -0700 (PDT) In-Reply-To: <5426139A.4070008@cs.tcd.ie> References: <462E2EC4-A285-4D02-9156-D8C94D6BE107@cisco.com> <1D2C7BAF-A3EF-45B8-87EB-EB4DFD2C3C7F@cisco.com> <540F543E.8080505@cs.tcd.ie> <5426139A.4070008@cs.tcd.ie> Date: Fri, 26 Sep 2014 18:56:37 -0700 X-Google-Sender-Auth: u0sV2Ia6VY9IojEAidqyCds-teY Message-ID: From: Adam Langley To: Stephen Farrell Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/dUu0aH1XV-epCpK5GIzNfcxOLZA Cc: "tls@ietf.org" Subject: Re: [TLS] Early code-point assignment for draft-ietf-tls-session-hash X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 27 Sep 2014 01:56:42 -0000 On Fri, Sep 26, 2014 at 6:32 PM, Stephen Farrell wrote: > Sorted. 23 it is. [1] Thank you! -- Adam Langley agl@imperialviolet.org https://www.imperialviolet.org From nobody Mon Sep 29 03:57:59 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D95D41A1A48 for ; Mon, 29 Sep 2014 03:57:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.688 X-Spam-Level: X-Spam-Status: No, score=-7.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SIcG-W1FmCMk for ; Mon, 29 Sep 2014 03:57:53 -0700 (PDT) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CDBF1A1A28 for ; Mon, 29 Sep 2014 03:57:52 -0700 (PDT) Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s8TAvpMT003728 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 29 Sep 2014 06:57:51 -0400 Received: from [10.34.2.127] (dhcp-2-127.brq.redhat.com [10.34.2.127]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s8TAvmt1001844 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Mon, 29 Sep 2014 06:57:51 -0400 Message-ID: <1411988268.1922.37.camel@dhcp-2-127.brq.redhat.com> From: Nikos Mavrogiannopoulos To: draft-ietf-tls-session-hash@tools.ietf.org Date: Mon, 29 Sep 2014 12:57:48 +0200 Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.68 on 10.5.11.22 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/okshLjy7lqBi4hEXcgCGmnUZubI Cc: "tls@ietf.org" Subject: [TLS] comment on draft-ietf-tls-session-hash-01 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 29 Sep 2014 10:57:55 -0000 Hello, The text in draft-ietf-tls-session-hash-01 specifies: "Implementation note: As described in Section 4, the "session_hash" is used in the extended master secret computation. Hence, it must be possible to compute the session_hash before the master secret is computed. In SSL 3.0, the master secret is first needed in the Client's CertificateVerify message. Hence, it is widespread implementation practice to compute the master secret as soon as the "pre_master_secret" is available, typically immediately before or after sending the Client Key Exchange message." My first comment is that this text is pretty confusing. The second is to clarify my understanding. Does this text suggest that for SSL 3.0 in order to calculate the "extended master secret", must first calculate the "master secret" it is supposed to replace? If yes, I find the argument unconvincing for the introduction of such complexity in the master secret calculation. I suggest the following alternatives: 1. Do SSL 3.0 extended master secret calculation as in TLS 1.0 when this extension is present 2. Explicitly state that SSL 3.0 is not in the scope of the document; anyway there is no real expectation of such an extension to be implemented in an SSL 3.0-only implementation. regards, Nikos From nobody Mon Sep 29 09:28:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 520971A8883 for ; Mon, 29 Sep 2014 09:28:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RA7wQHW5hIwJ for ; Mon, 29 Sep 2014 09:28:47 -0700 (PDT) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A7631A8872 for ; Mon, 29 Sep 2014 09:28:47 -0700 (PDT) Received: by mail-qc0-f170.google.com with SMTP id m20so1614843qcx.29 for ; Mon, 29 Sep 2014 09:28:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=MG0spsaLgmPypx8/Hid3q3cUpf9ifKm9nGb93rzKJtk=; b=BoelQ9gkMs8Y9fm2SQVVl2RPkrKETXgtKbPkdmQJ1nMIjMMXiGnCjTFHUyAL9e4vcI cwaVDSiZA7IWvgVS7sGuNhGTb7uZ9Et1lrJ0d6qhodPUsBA8tyGN/ArWI+iRq+GBRY77 ZjTRHD+kBi//TmJHsNu0HD3KmfW9jgJrZIg0WtACiG6zsUOy9dgpVCWsoIC7eYrPaen4 qZtIQT7iijuQGqIXlTH+ukLiPK6R4U175gOjkjyySogcs5LGH2nWFcqbZH/ewy2mBDsf jLvao3ZQmzjbitvjK3kmpH+52A1Gd78fJNu8bIch1P067G0ouLAZDybS8BkVGuQ7+feA iwpQ== X-Gm-Message-State: ALoCoQnzvvk1oAk5bn9VXVkU2DLOOnCvDPQ6+fwtzxeEhZjm/qe995tU16ckrEBjzB9fxZnOgLbE X-Received: by 10.224.136.10 with SMTP id p10mr54889754qat.26.1412008126617; Mon, 29 Sep 2014 09:28:46 -0700 (PDT) Received: from ?IPv6:2601:a:2a00:226:dcf6:7fcc:4024:34e3? ([2601:a:2a00:226:dcf6:7fcc:4024:34e3]) by mx.google.com with ESMTPSA id o6sm11574087qag.40.2014.09.29.09.28.46 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 29 Sep 2014 09:28:46 -0700 (PDT) Message-ID: <542988C5.8050307@nthpermutation.com> Date: Mon, 29 Sep 2014 12:28:53 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.1 MIME-Version: 1.0 To: "tls@ietf.org" Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/06k8oAo-me2zVJLHWUE8-edNoXw Subject: [TLS] AEAD only for TLS1.3 revisit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 29 Sep 2014 16:28:49 -0000 Hi - This isn't a proposal to change the decision to only include AEAD ciphers in TLS1.3. But something crossed my desk that suggested I should at least mention a possible issue with this. Background: There are number of countries (and private networks) that have a requirement to decrypt any traffic passing through certain places. There is not a corresponding requirement to allow them to imitate a sender or receiver. This can be done through key escrow, LEAF-like fields or multiple encryption of the data for example. Implication: AEAD ciphers have a single key which is broken down for use both in the encryption and integrity processes. Revealing that single key (to satisfy the decryption requirement) can reveal the credentials to allow masquerading. If the TLS connection credentials are also being used as credentials for control actions (e.g. cyber-physical controls of power systems, control over a firewall, etc), fulfilling the decryption requirement provides an unintended attack surface for possibly life critical systems. Thoughts: At least one AEAD cipher (CCM) uses the exact same key for both integrity and encryption. There is no way to reveal the encryption key without also revealing the integrity key. But if you have the integrity key, you can masquerade as sender or receiver (controller or controlled). Question: In light of the above, should we revisit the AEAD-only decision for TLS1.3? Question: Is there absolutely no requirement for TLS1.3 integrity only cipher suites? The fallback for systems in areas that have these requirements could be either TLS1.2, one of the other IETF security protocols, or something proprietary. And yes, this was triggered by a real-world requirement. Mike From nobody Mon Sep 29 09:35:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E4F1A88B6 for ; Mon, 29 Sep 2014 09:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ioBvm01jqUdJ for ; Mon, 29 Sep 2014 09:35:00 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (prod-mail-xrelay08.akamai.com [96.6.114.112]) by ietfa.amsl.com (Postfix) with ESMTP id 205431A8883 for ; Mon, 29 Sep 2014 09:35:00 -0700 (PDT) Received: from prod-mail-xrelay08.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 53B0048597; Mon, 29 Sep 2014 16:34:59 +0000 (GMT) Received: from prod-mail-relay08.akamai.com (prod-mail-relay08.akamai.com [172.27.22.71]) by prod-mail-xrelay08.akamai.com (Postfix) with ESMTP id 46F8148592; Mon, 29 Sep 2014 16:34:59 +0000 (GMT) Received: from ustx2ex-cashub.dfw01.corp.akamai.com (ustx2ex-cashub2.dfw01.corp.akamai.com [172.27.25.76]) by prod-mail-relay08.akamai.com (Postfix) with ESMTP id 42B2E98049; Mon, 29 Sep 2014 16:34:59 +0000 (GMT) Received: from USMBX1.msg.corp.akamai.com ([169.254.2.28]) by ustx2ex-cashub2.dfw01.corp.akamai.com ([172.27.25.76]) with mapi; Mon, 29 Sep 2014 11:34:58 -0500 From: "Salz, Rich" To: Michael StJohns , "tls@ietf.org" Date: Mon, 29 Sep 2014 11:34:58 -0500 Thread-Topic: [TLS] AEAD only for TLS1.3 revisit Thread-Index: Ac/cAnetUe8MsPzeTHqeHMYLzpawEgAAMJPg Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D2F426FFB@USMBX1.msg.corp.akamai.com> References: <542988C5.8050307@nthpermutation.com> In-Reply-To: <542988C5.8050307@nthpermutation.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/GWPiPi-ogohB8Wxkps8NlhSTX4I Subject: Re: [TLS] AEAD only for TLS1.3 revisit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 29 Sep 2014 16:35:02 -0000 > Question: Is there absolutely no requirement for TLS1.3 integrity only > cipher suites? My strong opinion is no. Use TLS 1.2 or earlier if that's a requirement. -- =20 Principal Security Engineer, Akamai Technologies IM: rsalz@jabber.me Twitter: RichSalz From nobody Mon Sep 29 09:49:00 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F75C1A8928 for ; Mon, 29 Sep 2014 09:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.985 X-Spam-Level: X-Spam-Status: No, score=-4.985 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rearg1jmWTZy for ; Mon, 29 Sep 2014 09:48:57 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id 290C11A891F for ; Mon, 29 Sep 2014 09:48:56 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s8TGmP7T024907; Mon, 29 Sep 2014 12:48:54 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: "'rsalz@akamai.com'" , "'msj@nthpermutation.com'" , "'tls@ietf.org'" Thread-Topic: [TLS] AEAD only for TLS1.3 revisit Thread-Index: AQHP3AJ2/EHuY8NeI02Vv3s5UcgKb5wYkaYA///As6o= Date: Mon, 29 Sep 2014 16:48:24 +0000 Message-ID: <65D2FD736B6B2B48B2EAD2BD189DC9CC479C4C@LLE2K10-MBX01.mitll.ad.local> In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D2F426FFB@USMBX1.msg.corp.akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [155.34.14.22] 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.12.52, 1.0.28, 0.0.0000 definitions=2014-09-29_04:2014-09-29,2014-09-29,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-1402240000 definitions=main-1409290158 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/DFGj6mtrn-Xs0qw26Rg2ymxxop4 Subject: Re: [TLS] AEAD only for TLS1.3 revisit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 29 Sep 2014 16:48:59 -0000 My strong opinion is yes they are required - the need that brought them int= o TLS 1.2- does not disappear with the upgrade to 1.3.=20 I agree that the majority of the installations should not enable this optio= n - but it would be wrong to make it completely unavailable. (And I don't understand this crusade-ish attitude towards/against the integ= rity-only suites.)=20 -- 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, Lexington, MA 02420-9185 =20 Web: http://www.ll.mit.edu/CST/ MIT LL Root CA: ----- Original Message ----- From: Salz, Rich [mailto:rsalz@akamai.com] Sent: Monday, September 29, 2014 12:34 PM=0A= To: Michael StJohns ; tls@ietf.org Subject: Re: [TLS] AEAD only for TLS1.3 revisit > Question: Is there absolutely no requirement for TLS1.3 integrity only > cipher suites? My strong opinion is no. Use TLS 1.2 or earlier if that's a requirement. -- =20 Principal Security Engineer, Akamai Technologies IM: rsalz@jabber.me Twitter: RichSalz _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls From nobody Mon Sep 29 12:33:17 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A63D71ABC74 for ; Mon, 29 Sep 2014 12:33:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.652 X-Spam-Level: X-Spam-Status: No, score=-4.652 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NLW30wZ5Kl1j for ; Mon, 29 Sep 2014 12:33:09 -0700 (PDT) Received: from smtpde01.smtp.sap-ag.de (smtpde01.smtp.sap-ag.de [155.56.68.170]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 348181A9308 for ; Mon, 29 Sep 2014 12:33:08 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) by smtpde01.smtp.sap-ag.de (Postfix) with ESMTPS id 52CE2546CA; Mon, 29 Sep 2014 21:33:06 +0200 (CEST) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id 4677A419A2; Mon, 29 Sep 2014 21:33:06 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id 3FAF71AE89; Mon, 29 Sep 2014 21:33:06 +0200 (CEST) In-Reply-To: To: Bodo Moeller Date: Mon, 29 Sep 2014 21:33:06 +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: <20140929193306.3FAF71AE89@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/EP9PSUfRogohTKaUciVSiyDioS8 Cc: Adam Langley , "" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 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, 29 Sep 2014 19:33:11 -0000 Bodo Moeller wrote: > > (As an aside, if latency is the utmost concern, you don't strictly have to > try protocol versions in sequence -- you could do multiple connections in > parallel. Ouch? When using (EC)DHE cipher suites, then is the costly operation for the server not already triggered by ClientHello? I think it would be a bad idea for *good* clients to perform multiple parallel connections to a server that force the server through PK-crypto, because that hits the server hard and makes it much more difficult for the server to distinguish good and bad clients in order to perform self-defense when the server is suffering from high load. -Martin From nobody Mon Sep 29 12:48:51 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECC7D1A9308 for ; Mon, 29 Sep 2014 12:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.551 X-Spam-Level: X-Spam-Status: No, score=-6.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eHU8eJtQwswM for ; Mon, 29 Sep 2014 12:48:47 -0700 (PDT) Received: from smtpde02.smtp.sap-ag.de (smtpde02.smtp.sap-ag.de [155.56.68.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA7131ABD3D for ; Mon, 29 Sep 2014 12:48:46 -0700 (PDT) Received: from mail05.wdf.sap.corp (mail05.sap.corp [194.39.131.55]) by smtpde02.smtp.sap-ag.de (Postfix) with ESMTPS id C20AD6ECFD; Mon, 29 Sep 2014 21:48:44 +0200 (CEST) Received: from ld9781.wdf.sap.corp (ld9781.wdf.sap.corp [10.21.82.193]) by mail05.wdf.sap.corp (Postfix) with ESMTP id B0146419AD; Mon, 29 Sep 2014 21:48:44 +0200 (CEST) Received: by ld9781.wdf.sap.corp (Postfix, from userid 10159) id A88F51AE89; Mon, 29 Sep 2014 21:48:44 +0200 (CEST) In-Reply-To: To: Martin Thomson Date: Mon, 29 Sep 2014 21:48:44 +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: <20140929194844.A88F51AE89@ld9781.wdf.sap.corp> From: mrex@sap.com (Martin Rex) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/ruYHBKll-o9G6fHGVk_AjtGLg3s Cc: "" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 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, 29 Sep 2014 19:48:49 -0000 Martin Thomson wrote: > > The draft requires that downgrade on resumption attempts (yes, you are > completely correct) is not guarded. Today's servers are permitted to completely ignore resumption requests (and perform a full handshake instead) for protocol versions other than the version that was used to create the (cached) session. Allowing resumption of cached sessions with different parameters (such as a different protocol version or different cipher suite) would look more like a server bug to me. Or could this actually be abused as a "feature": 1. create a new TLS session with TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P384 with a Windows 2008R2 Server (IIS). 2. propose resumption with the previously created session, but try to make server resume with TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256 for processing resumption, the key exchange portion of the cipher suite would technically not strictly be necessary. But the server may have groomed his list of supported cipher suites (not having an ECDSA cert)... -Martin From SRS0=HUAu=6W=acm.org=bmoeller@srs.kundenserver.de Mon Sep 29 13:06:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D36E81AC82C for ; Mon, 29 Sep 2014 13:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.714 X-Spam-Level: X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0HtvPlhcK9U6 for ; Mon, 29 Sep 2014 13:06:37 -0700 (PDT) Received: from mout.kundenserver.de (mout.kundenserver.de [212.227.126.131]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E4A71ABD3C for ; Mon, 29 Sep 2014 13:06:37 -0700 (PDT) Received: from mail-yk0-f182.google.com (mail-yk0-f182.google.com [209.85.160.182]) by mrelayeu.kundenserver.de (node=mreue007) with ESMTP (Nemesis) id 0MdjxY-1Xtdqg3IXk-00PL6y; Mon, 29 Sep 2014 22:06:35 +0200 Received: by mail-yk0-f182.google.com with SMTP id 131so762092ykp.27 for ; Mon, 29 Sep 2014 13:06:33 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.236.155.234 with SMTP id j70mr61782196yhk.74.1412021193615; Mon, 29 Sep 2014 13:06:33 -0700 (PDT) Received: by 10.170.194.15 with HTTP; Mon, 29 Sep 2014 13:06:33 -0700 (PDT) In-Reply-To: <20140929193306.3FAF71AE89@ld9781.wdf.sap.corp> References: <20140929193306.3FAF71AE89@ld9781.wdf.sap.corp> Date: Mon, 29 Sep 2014 22:06:33 +0200 Message-ID: From: Bodo Moeller To: "tls@ietf.org" Content-Type: multipart/alternative; boundary=20cf302d4986a93138050439cd20 X-Provags-ID: V02:K0:x+HFlAxOuCVjr13LF+NLRTZad6/sn+GjBRJBwyk+Cdi 9obIQnjzQlg5TUJEby6KVScf4TgCXtPHg9htHuUtaJE4yLC1Dg oLogLmjNVfyLo0fylxVsmjhVfz7RZ/nIqdqBDIflI9HoYRisro ADCBaSVDZJzz8vLXM+oLX32P3XisMBvA73/mjeFJVabaNhxL4f FSTDrT1zXz85ttoaWoVu3/fs2AdmIXsMcfw6ObcZL/hhIV05T4 zIIGOUZiT94QsZQXPKqhnG+5KW9YaXkW2DZdkogi7zUHBRGD7J FJpTwRqdaYsbPI/4Ml8/ieBM/8lDc58ghR2dTtsjOYTO3N4k/V xSiL8Yq65K/IYgUF9T4zyaPLos6Xh/WHO2ChnWENZrwctRUDdW 6LNPdQSkL/Mch7oraWW4hhIuRhkNmPuqnDhtTpGS92rE5KnilY zWm6A X-UI-Out-Filterresults: notjunk:1; Archived-At: http://mailarchive.ietf.org/arch/msg/tls/xFkJA8GA3Ri7AADXmSyfnAAbV5E Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 29 Sep 2014 20:07:40 -0000 --20cf302d4986a93138050439cd20 Content-Type: text/plain; charset=UTF-8 Martin Rex : > Bodo Moeller wrote: > > > (As an aside, if latency is the utmost concern, you don't strictly have > to > > try protocol versions in sequence -- you could do multiple connections in > > parallel. > > Ouch? > > When using (EC)DHE cipher suites, then is the costly operation for the > server not already triggered by ClientHello? I think it would be a bad > idea > for *good* clients to perform multiple parallel connections to a server > that force the server through PK-crypto, because that hits the server > hard and makes it much more difficult for the server to distinguish > good and bad clients in order to perform self-defense when the server > is suffering from high load. That's a good point, so multiple parallel connections probably aren't a useful suggestion. (At least with (EC)DHE enabled.) Of course, since this is about fallback retries, it would only affect version-intolerant servers; maybe we shouldn't have too much sympathy with those :-) Bodo --20cf302d4986a93138050439cd20 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Mart= in Rex <mrex@sap.com>:
Bodo Moeller wrote:
=C2=A0
> (As an aside, if latency is the utmost concern, you don't strictly= have to
> try protocol versions in sequence -- you could do multiple connections= in
> parallel.
=C2=A0
Ouch?

When using (EC)DHE cipher suites, then is the costly operation for the
server not already triggered by ClientHello?=C2=A0 I think it would be a ba= d idea
for *good* clients to perform multiple parallel connections to a server
that force the server through PK-crypto, because that hits the server
hard and makes it much more difficult for the server to distinguish
good and bad clients in order to perform self-defense when the server
is suffering from high load.

That's a g= ood point, so multiple parallel connections probably aren't a useful su= ggestion. (At least with (EC)DHE enabled.)

Of cour= se, since this is about fallback retries, it would only affect version-into= lerant servers; maybe we shouldn't have too much sympathy with those :-= )

Bodo


--20cf302d4986a93138050439cd20-- From nobody Mon Sep 29 14:16:03 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2E5B1ACCE5 for ; Mon, 29 Sep 2014 14:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BEj6_Xy4-hsl for ; Mon, 29 Sep 2014 14:16:00 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7BB11ACCD8 for ; Mon, 29 Sep 2014 14:15:59 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id gi9so8573166lab.5 for ; Mon, 29 Sep 2014 14:15:58 -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=WBKPCeVEG/TiujMsLhwEN6atnNmbEJjpDxdh1gca7To=; b=r2FHye51XKI85nqQS0/Jxdo8BxJyiw2QwAVbUy4X+liizzsdUxqdGl2nOy0m9sd0Kx zWNdsGSZY6An1uGzoIOZ7wsOXCL8VFpRLyg8Zsp5bNMVxXAggd43qgjaFzqmRh/TmMxI u2bceSWEMwJLLQGat2ClSUFd9ABkT5PAcOqkL1cIwT9VV6oLIn58IFrI8BaJmkqPffpY OYRL1bBsy/HhZjeTgOlVW2wsa1DattaKHGN7/N/IrSoEVGb8IDJTbNK7iRksuPFYl0ov eDnyITNB0HYYjZEET5t6FUog3ilrvTFWNc28NwtODJxll0NYyOfqDNwuhy9fZ5Sz/L3G rKOg== MIME-Version: 1.0 X-Received: by 10.152.36.4 with SMTP id m4mr42479689laj.17.1412025357926; Mon, 29 Sep 2014 14:15:57 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Mon, 29 Sep 2014 14:15:57 -0700 (PDT) In-Reply-To: References: <20140929193306.3FAF71AE89@ld9781.wdf.sap.corp> Date: Mon, 29 Sep 2014 14:15:57 -0700 Message-ID: From: Martin Thomson To: Bodo Moeller Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YfPn03B4TEAt5yIjGgnPw6Jj4cE Cc: "tls@ietf.org" Subject: Re: [TLS] Working Group Last Call for draft-ietf-tls-downgrade-scsv-00 X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 29 Sep 2014 21:16:02 -0000 On 29 September 2014 13:06, Bodo Moeller wrote: > Of course, since this is about fallback retries, it would only affect > version-intolerant servers; maybe we shouldn't have too much sympathy with > those :-) It's not always their fault. From nobody Tue Sep 30 12:44:58 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F66D1A8832 for ; Tue, 30 Sep 2014 12:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BkgEXgf5peVs for ; Tue, 30 Sep 2014 12:44:54 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6D5D1A8831 for ; Tue, 30 Sep 2014 12:44:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2526; q=dns/txt; s=iport; t=1412106294; x=1413315894; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=UH5z9LR8xjXbVqWz4/0jtUFD5+2XFo81YS/oCmqEGNQ=; b=cNVYHPBTSegxyaVX4O2G8b5v1u7bIrdDP86UEZ/4/+L7+N6WSUkhNZdX P45QJfkBjqwl8LfvhOFqPmlppyy4Gq4IkXkOaEz77rs47AvM+D7zgkhui QasgSvgyGB2canrTBxK4Mr/HUzzt3DjMNH+G5+Ww/44C1vxo6TUrG+gqh I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFAAoIK1StJA2E/2dsb2JhbABggw5TVwTKHgqHTQKBDhYBe4QEAQEDAQEBATc0CwULAgEINhAnCyUCBA4FGYgdCA2+SgETBI9QGzMHgy6BHQWRaotFlXCDY2yBSIECAQEB X-IronPort-AV: E=Sophos;i="5.04,628,1406592000"; d="scan'208";a="359587959" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-5.cisco.com with ESMTP; 30 Sep 2014 19:44:53 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s8UJirCW004399 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Sep 2014 19:44:53 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.15]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Tue, 30 Sep 2014 14:44:52 -0500 From: "Joseph Salowey (jsalowey)" To: Michael StJohns Thread-Topic: [TLS] AEAD only for TLS1.3 revisit Thread-Index: AQHP3AJ4lndEwGXmSE2+7AxRf6JNSZwaacsA Date: Tue, 30 Sep 2014 19:44:52 +0000 Message-ID: References: <542988C5.8050307@nthpermutation.com> In-Reply-To: <542988C5.8050307@nthpermutation.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.136] Content-Type: text/plain; charset="us-ascii" Content-ID: <6E1C963016E5F54A91EDAF305E87D9B8@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/3Ak05_sErYHNdqhemhvp3LMVg1s Cc: "tls@ietf.org" Subject: Re: [TLS] AEAD only for TLS1.3 revisit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 30 Sep 2014 19:44:55 -0000 Allowing man-in-the-middle or integrity only cipher suites is not a valid r= eason to revisit the AEAD decision. Allowing for man-in-the-middle and pas= sive monitoring is in opposition to our current mandate. As an aside, if = this becomes a requirement in the future I don't think that AEAD actually l= imits either of these possibilities, although your choice of cipher may. =20 Cheers, Joe On Sep 29, 2014, at 9:28 AM, Michael StJohns wrote= : > Hi - >=20 > This isn't a proposal to change the decision to only include AEAD ciphers= in TLS1.3. But something crossed my desk that suggested I should at least= mention a possible issue with this. >=20 > Background: There are number of countries (and private networks) that ha= ve a requirement to decrypt any traffic passing through certain places. Th= ere is not a corresponding requirement to allow them to imitate a sender or= receiver. This can be done through key escrow, LEAF-like fields or multip= le encryption of the data for example. >=20 > Implication: AEAD ciphers have a single key which is broken down for use= both in the encryption and integrity processes. Revealing that single key= (to satisfy the decryption requirement) can reveal the credentials to allo= w masquerading. If the TLS connection credentials are also being used as c= redentials for control actions (e.g. cyber-physical controls of power syste= ms, control over a firewall, etc), fulfilling the decryption requirement pr= ovides an unintended attack surface for possibly life critical systems. >=20 >=20 > Thoughts: At least one AEAD cipher (CCM) uses the exact same key for bot= h integrity and encryption. There is no way to reveal the encryption key w= ithout also revealing the integrity key. But if you have the integrity key= , you can masquerade as sender or receiver (controller or controlled). >=20 > Question: In light of the above, should we revisit the AEAD-only decisio= n for TLS1.3? >=20 >=20 > Question: Is there absolutely no requirement for TLS1.3 integrity only c= ipher suites? >=20 > The fallback for systems in areas that have these requirements could be e= ither TLS1.2, one of the other IETF security protocols, or something propri= etary. >=20 > And yes, this was triggered by a real-world requirement. >=20 > Mike >=20 >=20 >=20 > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls From nobody Tue Sep 30 12:50:28 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 158D21A8877 for ; Tue, 30 Sep 2014 12:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.984 X-Spam-Level: X-Spam-Status: No, score=-4.984 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cJFyC8ltBPgl for ; Tue, 30 Sep 2014 12:50:24 -0700 (PDT) Received: from mx2.ll.mit.edu (MX2.LL.MIT.EDU [129.55.12.46]) by ietfa.amsl.com (Postfix) with ESMTP id EEB591A8875 for ; Tue, 30 Sep 2014 12:50:23 -0700 (PDT) Received: from LLE2K10-HUB01.mitll.ad.local (LLE2K10-HUB01.mitll.ad.local) by mx2.ll.mit.edu (unknown) with ESMTP id s8UJo10X020667; Tue, 30 Sep 2014 15:50:08 -0400 From: "Blumenthal, Uri - 0558 - MITLL" To: "Joseph Salowey (jsalowey)" , Michael StJohns Thread-Topic: [TLS] AEAD only for TLS1.3 revisit Thread-Index: AQHP3AJ2/EHuY8NeI02Vv3s5UcgKb5waWQoA//++N4A= Date: Tue, 30 Sep 2014 19:49:34 +0000 Message-ID: References: <542988C5.8050307@nthpermutation.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-originating-ip: [172.25.177.187] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3494936965_1266352" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-09-30_08:2014-09-30,2014-09-30,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-1402240000 definitions=main-1409300201 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/Z40cyk1D57cWaYMHTyAIt7a3dVA Cc: "tls@ietf.org" Subject: Re: [TLS] AEAD only for TLS1.3 revisit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 30 Sep 2014 19:50:26 -0000 --B_3494936965_1266352 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable On 9/30/14, 15:44 , "Joseph Salowey (jsalowey)" wrote: >Allowing man-in-the-middle or integrity only cipher suites is not a valid >reason to revisit the AEAD decision. Allowing for man-in-the-middle and >passive monitoring is in opposition to our current mandate. As an >aside, if this becomes a requirement in the future I don't think that >AEAD actually limits either of these possibilities, although your choice >of cipher may. =20 The point is that in some environments the choice is BETWEEN man-in-the-middle (currently done by many corporations via =E2=80=9Csplit SSL=E2=80=9D = or =E2=80=9Ccracked SSL=E2=80=9D) with no security guarantees at all, and passive monitori= ng where you can have at least integrity & authenticity. AEAD with a single key (which is my preference) is incompatible with passive monitoring unless integrity is sacrificed as well. >On Sep 29, 2014, at 9:28 AM, Michael StJohns >wrote: >> Hi - >>=20 >> This isn't a proposal to change the decision to only include AEAD >>ciphers in TLS1.3. But something crossed my desk that suggested I >>should at least mention a possible issue with this. >>=20 >> Background: There are number of countries (and private networks) that >>have a requirement to decrypt any traffic passing through certain >>places. There is not a corresponding requirement to allow them to >>imitate a sender or receiver. This can be done through key escrow, >>LEAF-like fields or multiple encryption of the data for example. >>=20 >> Implication: AEAD ciphers have a single key which is broken down for >>use both in the encryption and integrity processes. Revealing that >>single key (to satisfy the decryption requirement) can reveal the >>credentials to allow masquerading. If the TLS connection credentials >>are also being used as credentials for control actions (e.g. >>cyber-physical controls of power systems, control over a firewall, etc), >>fulfilling the decryption requirement provides an unintended attack >>surface for possibly life critical systems. >>=20 >>=20 >> Thoughts: At least one AEAD cipher (CCM) uses the exact same key for >>both integrity and encryption. There is no way to reveal the encryption >>key without also revealing the integrity key. But if you have the >>integrity key, you can masquerade as sender or receiver (controller or >>controlled). >>=20 >> Question: In light of the above, should we revisit the AEAD-only >>decision for TLS1.3? >>=20 >>=20 >> Question: Is there absolutely no requirement for TLS1.3 integrity only >>cipher suites? >>=20 >> The fallback for systems in areas that have these requirements could be >>either TLS1.2, one of the other IETF security protocols, or something >>proprietary. >>=20 >> And yes, this was triggered by a real-world requirement. >>=20 >> Mike >>=20 >>=20 >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls > >_______________________________________________ >TLS mailing list >TLS@ietf.org >https://www.ietf.org/mailman/listinfo/tls --B_3494936965_1266352 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUOAYJKoZIhvcNAQcCoIIUKTCCFCUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghIHMIIE6jCCA9KgAwIBAgIKH0XZoAAAAAABzTANBgkqhkiG9w0BAQsFADBRMQswCQYD VQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJ MRMwEQYDVQQDEwpNSVRMTCBDQS0zMB4XDTE0MDQxNjIxNTMwMloXDTE1MDQxNjIxNTMwMlow YTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNV BAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqG SIb3DQEBAQUAA4IBDwAwggEKAoIBAQCx/gK75UYos2g8JavX0BVfe3TCGsmjQY34z9ZVeucP 8dGtqRA8T5i1OKdf++Jd81a0/qQA6mIGyzTW6lOtY+77qKUJtEeLM5URd+iv2EejAwxsa2B5 pMq9L9qWuVokR1rTEfEcuUeKR1Kko6xmRE/y6AzBnUhTvHx2X9F6JSVdR36Lx3R62CNeQqFi ZDeHuTI8AhRY4UdPkri1FTDxV6gLYaLKxsGIurrL/6EzdlkX8ImTcxKzEmxX1VjTPy9ZRNYj akDGcJF9clCfcwbq3DI3gAUkVxXf+UbHEjzOCVNQcoga7bYbBUuDpN25Lc86P9RaOiiICtyu ZZP2P/2kkKYRAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQUEN9QHIi9GvlGjs9Th46jrfPir+Uw DgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFNdgZg57SY11TA39z0beyMcSh8q/MDMGA1Ud HwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTMwZgYIKwYB BQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExD QTMwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9BgkrBgEEAYI3 FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+KcwIBZAIBBTAi BgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAYBgNVHSAEETAPMA0GCyqGSIb3 EgIBAwEIMBkGA1UdEQQSMBCBDnVyaUBsbC5taXQuZWR1MCcGCSsGAQQBgjcUAgQaHhgATABM AFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBAL2kCh9ovO8AbHgAVU6T eH5qRmKnOrfTUfn9JnHzkspdWMQA1IdtftSpiZZ7C3lCmblSDCgPqbQl4zMZxXeTgxnQsB6m 1LA6uDHM/0G27RcOJH4OTN9sQ0/2CKb4JPIXXIps1z+s8XjSRzPJZuD8fPC8R8QWvOH3owL2 BLzZebZTOMa5yws3kohY02vP/Clv0KQXYVzUZUYXoYmhUSYmQ1UZZZSFJ2rNdgNn0z8fPrUQ NIYlVaJV0kKQYjlHWTfomVapLEfIY7xRHZy9g997IjYReD0t9IZd6tTwcJES+2ijFM8l/fxk u/cQ4WCYyI+58DaBaV9p68/AC147b0HhvLUwggS8MIIDpKADAgECAgEpMA0GCSqGSIb3DQEB BQUAMFQxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQww CgYDVQQLEwNQS0kxFjAUBgNVBAMTDU1JVExMIFJvb3QgQ0EwHhcNMTMxMjE3MDAwMDAwWhcN MjAxMjMxMjM1OTU5WjBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFi b3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0zMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2jBSdW18tuW1tNxG6h8B0kqckFZQAAtoHCkvUpUEX6jF vBd8mQI53GyLYRuAo4HWJpe7/izFXOfSJDs6UM5ovvCOfXg2bJgDYlBC9JDcLBFIn0nppOu9 RvpjWSixtC56crwJ5Us5QPdtxtKdek5LJXl2oKw3w8lihUixePbxWad1m7ZMKKagvm9zTybP 6FumKRxeYJjSpB2+cAYjoGGEbSVHyx8uzHm6xAoBMHxa8by+yDz8Jzk6sP9iilgP3iXSGoCA mhyBzvlQQ5QNNWP+Emo9jz/ukKhYVB/VwdxtoquPAqn4ifDAIaM9dtb05cy1gXAFSP3Z/iUk xyBZZUORfwIDAQABo4IBmjCCAZYwEgYDVR0TAQH/BAgwBgEB/wIBADAdBgNVHQ4EFgQU12Bm DntJjXVMDf3PRt7IxxKHyr8wHwYDVR0jBBgwFoAUZ6p6z/QKprlytYqg0p3yEMND7SkwDgYD VR0PAQH/BAQDAgGGMGYGCCsGAQUFBwEBBFowWDAtBggrBgEFBQcwAoYhaHR0cDovL2NybC5s bC5taXQuZWR1L2dldHRvP0xMUkNBMCcGCCsGAQUFBzABhhtodHRwOi8vb2NzcC5sbC5taXQu ZWR1L29jc3AwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNy bD9MTFJDQTCBkgYDVR0gBIGKMIGHMA0GCyqGSIb3EgIBAwEGMA0GCyqGSIb3EgIBAwEIMA0G CyqGSIb3EgIBAwEHMA0GCyqGSIb3EgIBAwEJMA0GCyqGSIb3EgIBAwEKMA0GCyqGSIb3EgIB AwELMA0GCyqGSIb3EgIBAwEOMA0GCyqGSIb3EgIBAwEPMA0GCyqGSIb3EgIBAwEQMA0GCSqG SIb3DQEBBQUAA4IBAQAsf9HBn72qU7UTgkxarjAc7iynhcDEgWwezYKtd/SLGSQ0DhtzIV/L TCxqULjOd+H+HTqMJXB8+nHnzhyqQ43RsnGZOFT5RfzPh94db/ZJ3ql244DwlJI7yXBA2DkZ cEEgOWC9bHcrElzU6NnigahSW5odVJrhmH/XhQAcMS77E5H62yyxK1WPPgcBipGVnu1xSHbT iHe7DqfWQ2tVMLUf23XYhIua94kJsQd4jSh71NVD0e7F4snAoqQMI98MzDYeLOkjlzKRs77r /aMsPAKx6nMaOvRL7Cy0Pjp51i2qFkbGmX8ofnh2kerjTTvRJ/g22r1MV8RR1PktjMsNOsPf MIIDgzCCAmugAwIBAgIBATANBgkqhkiG9w0BAQUFADBUMQswCQYDVQQGEwJVUzEfMB0GA1UE ChMWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRYwFAYDVQQDEw1NSVRM TCBSb290IENBMB4XDTA4MDkyMzEyMDAwMFoXDTI5MTIzMTIzNTk1OVowVDELMAkGA1UEBhMC VVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEWMBQG A1UEAxMNTUlUTEwgUm9vdCBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMVO KRdYsiay+a2Kv1wQCoPd5AkwExuwcNDRhaRCdQN17K+lCCKvf9VSQToAsA6q1bACtZUcMv5Z Kx8z5KG4jK9cM40NvEkf/bIOZAHJqzKgWG3N9NqrcAhimcXTXYQIdp1DgjtdADKVLAjXaYpD 2PbpE/JbAPnqKzOENa3Py9CegB0abTlOyLgwXWY/rXTW+4L/hipJ6+sI/ZtrFRmsKGhuwAKo bFr0FDP6uIfx+RaWJcJ1QBIdgM4aohvW8JeriSSMyf/LlFpXTZFcM9SOX0f7wmsYi1yFuKFM nQbkSkxvnpBKMRxrg+98seSbbEnIkvB0C9qBDPLb/lQAvmpW6oMCAwEAAaNgMF4wDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQUZ6p6z/QKprlytYqg0p3yEMND7SkwHwYDVR0jBBgwFoAU Z6p6z/QKprlytYqg0p3yEMND7SkwCwYDVR0PBAQDAgGGMA0GCSqGSIb3DQEBBQUAA4IBAQA+ G20FYNB4eNhKWF+PyT5DUtzlABFkf2IM2VGNUBova0GeKX3I1Nf02qDU/GO2H9ETvnvTYhvf gQ4UB/5EImTkKPa7/TVG/MQ7SgmAmne8xELVbGLFrrytly8PyYtZtngb6DgeEUv+SwFnzcLO 1vg1rdmss3kwsqy0q8e2VYAY8zTptEzyJG36aXcIMbqOxWS/LbPjNuPdgJfO3d1WrHr1Etaa a0QRLqQoZj07dYY7Wo5EDqU+AUAMz9ZVRGK1s5b/jv5Wz/YroyqWFnH2KkNxRn9+2Ar7g3rn rOMZvp6psq2jbDXiPBod1wyMKn8x5y4cuGPNFcqjfyY/HX90ivQAMIIEzjCCA7agAwIBAgIK PVEvPAAAAACTsDANBgkqhkiG9w0BAQsFADBRMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlU IExpbmNvbG4gTGFib3JhdG9yeTEMMAoGA1UECxMDUEtJMRMwEQYDVQQDEwpNSVRMTCBDQS0y MB4XDTE0MDIxMjE4NTMwMVoXDTE1MDIxMjE4NTMwMVowYTELMAkGA1UEBhMCVVMxHzAdBgNV BAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMX Qmx1bWVudGhhbC5VcmkuNTAwMTA1ODQwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCKHhhu75bRiOvWhbZ//TxS76yI2d+rHN2s8bp8wxW8oMjmsaplLeGQusUFRyRNSkfYtdB4 YApjnV6TCxS0Mqzly5BaoeZWoP+CbbMDNGYMszus9iFj22SSlTzGRo+gaL6rqsDKdwDOzs3C PYqh4Uu8sLzEq+QD9rhqAuMJ76635JKWELxK0uDehpNBMCGqVeAY8ht5u2h4ojPdwiuDQDW2 QxWRJjPDL8n1JczuEHY71jHldER3b2+UhpDDYRQ9aVOiGCjW8BwJOruVsBfLNxyDxgffNQ1D 1konuneMpL9H2S8ciHOdy5+Gi7snCQJ+7w30rIJ2NTldWaY6avZAaCa3AgMBAAGjggGWMIIB kjAdBgNVHQ4EFgQUZ7oGjnu6gWRmom/4UswgdVBW/3wwDgYDVR0PAQH/BAQDAgUgMB8GA1Ud IwQYMBaAFI5KfYmhYxccgYg0VzcmRV4Zin4kMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9j cmwubGwubWl0LmVkdS9nZXRjcmwvTExDQTIwYgYIKwYBBQUHAQEEVjBUMC0GCCsGAQUFBzAC hiFodHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExDQTIwIwYIKwYBBQUHMAGGF2h0dHA6 Ly9vY3NwLmxsLm1pdC5lZHUvMAwGA1UdEwEB/wQCMAAwPQYJKwYBBAGCNxUHBDAwLgYmKwYB BAGCNxUIg4PlHYfsp2aGrYcVg+rwRYW2oR8dhevQcIPr7SACAWQCAQQwJQYDVR0lBB4wHAYE VR0lAAYIKwYBBQUHAwQGCisGAQQBgjcKAwQwGAYDVR0gBBEwDzANBgsqhkiG9xICAQMBCDAZ BgNVHREEEjAQgQ51cmlAbGwubWl0LmVkdTANBgkqhkiG9w0BAQsFAAOCAQEAJiU3WfJ9GvGJ iDNPClLazyh252wxxOc/TmClMKtyqHnbFObDEoXAMaoHGxrvs+lU8fU2F2ELpV8q8eYgqLLw 7PG09z5s/GkajlxVZ/FHj/9hNHTfwlicrCRY3zrna1GbOMZgWFz8R6akAoLKpqGulNrvjvU8 c63U+JVmgJmBPCMv5JlH10m87+WPJ+ToK0m4XfZjl7n5OKDJ/hOyBwbBntc+W2gDppfR1BCt DNfEG0+zHjFqF+Of1Q5NI5abhgvw5IEuVA1M4SV/utwmmdreBEv/YuLnDd/PhVgQwp3LHGCX X1dANyiKso2aACl9jrkylq39cA/WgvAlS21w9vxVpDGCAfUwggHxAgEBMF8wUTELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTET MBEGA1UEAxMKTUlUTEwgQ0EtMwIKH0XZoAAAAAABzTANBglghkgBZQMEAgEFAKBpMC8GCSqG SIb3DQEJBDEiBCAf2cUXPUBYRJjYO+DK2JNPY953j1slojdG/wpxgPAKyDAYBgkqhkiG9w0B CQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNDA5MzAxOTQ5MjVaMA0GCSqGSIb3 DQEBAQUABIIBAAZLl0rT9g1gjqsUWZMzNH5P6c09yvUUUoKzWl9KoZY2ByBjVNaFbMUbjJHv lrhLzR1qL8IPoGxxneo4a/ZsB9USQO2eYs9kA6VoLlqZk1e6gkghMwtOCuBI5enTdqp8V9nP ql0UiM93U3WfP63Vgbo3V2yVD8vRHaY+7aZXNI8TrV62rsv8n1dmupeKK6Aio9eFhQH83TNA Nb5M5te+9p6k7QEFgatk2J1r37e0/O7YGouTuNHsQvcHy2c/CKQYCBb3a+ab0lapZuODO/eV d7G024V5w4fm7C87I5JPW8Jv/Q1m/sM0XdsR7ZOf+hEfluROKUuE5011KKnQswa5F7I= --B_3494936965_1266352-- From nobody Tue Sep 30 13:23:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86B161A894B for ; Tue, 30 Sep 2014 13:23:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O89SzL-k0Td8 for ; Tue, 30 Sep 2014 13:23:49 -0700 (PDT) Received: from mail-qc0-f169.google.com (mail-qc0-f169.google.com [209.85.216.169]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 903DB1A8949 for ; Tue, 30 Sep 2014 13:23:48 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id x13so2249720qcv.28 for ; Tue, 30 Sep 2014 13:23:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2WyLdSAwZ7TIDcBhnqnS2WsOyWWJ5z6m/vbJFyi/SmA=; b=g3w44yHKeEa0sHOwh412wuHgUiHPxVpBWbFdNbYkFhmSVTR2q460/FIyXVb6+vgKDD mpRRDN3VGydDqL9GEKz2R5HsGGsY0JX1uLTJ/3LHctO37vfMk1lSuUqk7hpR6dI352kx Cz8fy2vD0V1P5rSmKalklVLIEoUCD2yBhK2oBAMEs7Nv90a0BRY57yS6zBcrZOVjKD76 Ox/YBoH7AtHadE6RzqtaSco46aIaTQRihrRWeKnHyXGxqIHRGESVP/4JHFLDdkf7ETlB ebGc7OJ0MNB36JCj0oImrEqlj0jbjaef121YAeEUjRust8OSzKY5vZkZ0SF36//EVhOx g3Bw== X-Gm-Message-State: ALoCoQn+rvj+eMX2JCAf5CCZlnheJC5+osBpM/TuI57MsQk47ups9of8GhzWvTMBJT9OGlol7/c7 X-Received: by 10.224.22.18 with SMTP id l18mr9483695qab.84.1412108626317; Tue, 30 Sep 2014 13:23:46 -0700 (PDT) Received: from [192.168.1.116] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id b43sm14605023qge.24.2014.09.30.13.23.45 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Sep 2014 13:23:45 -0700 (PDT) Message-ID: <542B1158.4050203@nthpermutation.com> Date: Tue, 30 Sep 2014 16:23:52 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" References: <542988C5.8050307@nthpermutation.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/so_St7T_YRJWKa6wgfAEZkBZuaM Cc: "tls@ietf.org" Subject: Re: [TLS] AEAD only for TLS1.3 revisit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 30 Sep 2014 20:23:50 -0000 On 9/30/2014 3:44 PM, Joseph Salowey (jsalowey) wrote: > Allowing for man-in-the-middle and passive monitoring is in opposition to our current mandate. As an aside, if this becomes a requirement in the future I don't think that AEAD actually limits either of these possibilities, although your choice of cipher may. It depends on the cipher mode. Unfortunately, the restriction/limitation applies to both CCM and GCM; the only "native" AEAD ciphers in the TLS toolchest. For CCM, the key used for encryption is the same one used for integrity. For GCM, the key used for integrity is CIPH[sub K](128 bits of zero) where K is the encryption key - if you have the encryption key, you can generate the integrity key. The only other AEAD cipher suite we have in progress is https://datatracker.ietf.org/doc/draft-mcgrew-aead-aes-cbc-hmac-sha2/ which is a constructed AEAD cipher. That basically splits the input K linearly into two pieces - the HMAC and AES keys, so it would be possible to reveal the AES subkey without revealing the HMAC key. So the choice of AEAD effectively limits these possibilities. For all the non-AEAD suites, the integrity and encryption keys are individually derived. Mike From nobody Tue Sep 30 13:28:38 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8CE51A896F for ; Tue, 30 Sep 2014 13:28:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JTJTdzW5QUx9 for ; Tue, 30 Sep 2014 13:28:32 -0700 (PDT) Received: from mail-la0-x236.google.com (mail-la0-x236.google.com [IPv6:2a00:1450:4010:c03::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 683331A897B for ; Tue, 30 Sep 2014 13:28:29 -0700 (PDT) Received: by mail-la0-f54.google.com with SMTP id gm9so3268375lab.27 for ; Tue, 30 Sep 2014 13:28:27 -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=oVQMUFuxYyQQ9otMfGsmMGvfLPAcbPjh2mFGnwBAd5c=; b=0iMbKWHtn2CDGLS0HUQnAOD59C3hCHgW4zjltvBvMHRRwnLSvwnF28HlUJmDL5iCsC dYWfUgv0l7pgmHn97CBxPY1xNMEHEeyECb2JXkHlwBk1+9T53d6dG7yaxvBzqHroysEm qfD05OHV7njWjSxhAgUeSdu9yOofWz9GlePpJ9zmlsBTBl4Bxd3viZe5Jrg1XGDZHe4b gfuXSZe+O4FN2LIGDmGovBP1phGo8YHvn6MGDha6X+KIbcCCxno1KtPDxpF9eoqw9bF5 RLPJmQ5bX54LSorkdqUdoOpBEmfB2VPwTpGfbfCDebKhhE7uauNjRjf1HB4oKbqsEKmZ 22zg== MIME-Version: 1.0 X-Received: by 10.112.125.132 with SMTP id mq4mr6092233lbb.103.1412108907583; Tue, 30 Sep 2014 13:28:27 -0700 (PDT) Received: by 10.25.166.75 with HTTP; Tue, 30 Sep 2014 13:28:27 -0700 (PDT) In-Reply-To: <542988C5.8050307@nthpermutation.com> References: <542988C5.8050307@nthpermutation.com> Date: Tue, 30 Sep 2014 13:28:27 -0700 Message-ID: From: Martin Thomson To: Michael StJohns Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/vCVpOx_--4rkbXx0iOU0a4iAtmw Cc: "tls@ietf.org" Subject: Re: [TLS] AEAD only for TLS1.3 revisit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 30 Sep 2014 20:28:36 -0000 On 29 September 2014 09:28, Michael StJohns wrote: > Question: Is there absolutely no requirement for TLS1.3 integrity only > cipher suites? If you believe that integrity-only modes are valuable, you could propose an AEAD formulation that does not provide confidentiality. That's fairly trivial to do with an AEAD construction: just move everything under the AD part. From nobody Tue Sep 30 14:02:42 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1440B1A9004 for ; Tue, 30 Sep 2014 14:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ftfey7B3TIJi for ; Tue, 30 Sep 2014 14:02:37 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3CD61A900B for ; Tue, 30 Sep 2014 14:01:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1563; q=dns/txt; s=iport; t=1412110909; x=1413320509; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1hMZ/la1cTN3t0Q16ek66odLFKNQIuJIdjD8GTOvUpA=; b=WTSJOU8YIwxj7RLZUmk50pRok7ocPuOgY71Q/CbpmbRhfSVoC3kQb3Lt T6WrwiC/W46Q1Riwur+84FE1n2GciYYQBEBDmwb9IISqk1UEOQ1RAElXq kHTnh5dsh9q9jJx+3WFIJAj+4zHQn0v2Q+QB7rtbTWQyfBTUi2pqLzPLn g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIFACUZK1StJV2d/2dsb2JhbABggw5TVwTKKIdNAoEPFgF7hAMBAQEDAXkFCwIBCBguMiUCBA4FiDYIDb5GARMEj2szB4MugR0BBJFqhDuHCpVwg2NsgUiBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,629,1406592000"; d="scan'208";a="359617506" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-6.cisco.com with ESMTP; 30 Sep 2014 21:01:49 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s8UL1mQt032250 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Sep 2014 21:01:49 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.15]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Tue, 30 Sep 2014 16:01:48 -0500 From: "Joseph Salowey (jsalowey)" To: Michael StJohns Thread-Topic: [TLS] AEAD only for TLS1.3 revisit Thread-Index: AQHP3AJ4lndEwGXmSE2+7AxRf6JNSZwaacsAgAAK6ACAAAqUAA== Date: Tue, 30 Sep 2014 21:01:48 +0000 Message-ID: References: <542988C5.8050307@nthpermutation.com> <542B1158.4050203@nthpermutation.com> In-Reply-To: <542B1158.4050203@nthpermutation.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.136] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/69NRrlUyzGRgMdLc0ZQqH7xvBUQ Cc: "tls@ietf.org" Subject: Re: [TLS] AEAD only for TLS1.3 revisit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 30 Sep 2014 21:02:40 -0000 On Sep 30, 2014, at 1:23 PM, Michael StJohns wrote= : > On 9/30/2014 3:44 PM, Joseph Salowey (jsalowey) wrote: >> Allowing for man-in-the-middle and passive monitoring is in opposition = to our current mandate. As an aside, if this becomes a requirement in the= future I don't think that AEAD actually limits either of these possibiliti= es, although your choice of cipher may. >=20 >=20 >=20 > It depends on the cipher mode. Unfortunately, the restriction/limitation= applies to both CCM and GCM; the only "native" AEAD ciphers in the TLS to= olchest. For CCM, the key used for encryption is the same one used for int= egrity. For GCM, the key used for integrity is CIPH[sub K](128 bits of zer= o) where K is the encryption key - if you have the encryption key, you can = generate the integrity key. >=20 > The only other AEAD cipher suite we have in progress is https://datatrack= er.ietf.org/doc/draft-mcgrew-aead-aes-cbc-hmac-sha2/ which is a constructed= AEAD cipher. That basically splits the input K linearly into two pieces -= the HMAC and AES keys, so it would be possible to reveal the AES subkey wi= thout revealing the HMAC key. >=20 > So the choice of AEAD effectively limits these possibilities. For all th= e non-AEAD suites, the integrity and encryption keys are individually deriv= ed. >=20 [Joe] Many may consider this a feature rather than a problem, however, as y= ou state above, you can develop an AEAD ciphersuite with the properties you= want. =20 > Mike >=20 From nobody Tue Sep 30 14:23:52 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 898091A9166 for ; Tue, 30 Sep 2014 14:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GoT1bUcUt1oR for ; Tue, 30 Sep 2014 14:23:39 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05AC91A916C for ; Tue, 30 Sep 2014 14:23:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4522; q=dns/txt; s=iport; t=1412112219; x=1413321819; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=fKywB6p2fT7WJ3PDkqXllkaOuxLyIL9fz4fS3+pik8k=; b=KgQdsxvc6d3cOKckm15BzKh4YHjs/2Ml70n7SKFlTXrLtXyq6f2/jl8q Y/jy8cOhGsVw0cFCaHS66hkpq16dV8PZYzHG6tsqa+CGTbvpXco7G7J45 pm2v5hPxsnei7oaKgok/arHI0PNkKohzAgyHyoeb6rp9C80utkh7zkGPG Q=; X-Files: signature.asc : 495 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFAMMeK1StJV2Q/2dsb2JhbABgDoMAU1vKHgqHTQKBEhYBe4QDAQEBAwEBAQFrCwULAgEIGC4nCyUCBA4FDguIHQgNvkoBEwSPUE4Hgy6BHQWRaoIKgUyHb5VwgyNAbIFIgQIBAQE X-IronPort-AV: E=Sophos;i="5.04,629,1406592000"; d="asc'?scan'208";a="359409427" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by rcdn-iport-1.cisco.com with ESMTP; 30 Sep 2014 21:23:38 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s8ULNcJt027362 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Sep 2014 21:23:38 GMT Received: from xmb-rcd-x09.cisco.com ([169.254.9.15]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0195.001; Tue, 30 Sep 2014 16:23:37 -0500 From: "Joseph Salowey (jsalowey)" To: "Blumenthal, Uri - 0558 - MITLL" Thread-Topic: [TLS] AEAD only for TLS1.3 revisit Thread-Index: AQHP3AJ4lndEwGXmSE2+7AxRf6JNSZwaacsAgAABUgCAABo+gA== Date: Tue, 30 Sep 2014 21:23:37 +0000 Message-ID: <44A2498B-D0CB-415C-A1D8-2E362FD8BDF0@cisco.com> References: <542988C5.8050307@nthpermutation.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.33.248.136] Content-Type: multipart/signed; boundary="Apple-Mail=_C2C28AA5-BD7D-456B-8C2D-B135B517D552"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/tls/7rV6-CM32w5hFx3PIPqkDFIikck Cc: "tls@ietf.org" Subject: Re: [TLS] AEAD only for TLS1.3 revisit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 30 Sep 2014 21:23:46 -0000 --Apple-Mail=_C2C28AA5-BD7D-456B-8C2D-B135B517D552 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Sep 30, 2014, at 12:49 PM, Blumenthal, Uri - 0558 - MITLL = wrote: > On 9/30/14, 15:44 , "Joseph Salowey (jsalowey)" = wrote: >=20 >> Allowing man-in-the-middle or integrity only cipher suites is not a = valid >> reason to revisit the AEAD decision. Allowing for man-in-the-middle = and >> passive monitoring is in opposition to our current mandate. As an >> aside, if this becomes a requirement in the future I don't think that >> AEAD actually limits either of these possibilities, although your = choice >> of cipher may. =20 >=20 > The point is that in some environments the choice is BETWEEN > man-in-the-middle (currently done by many corporations via =93split = SSL=94 or > =93cracked SSL=94) with no security guarantees at all, and passive = monitoring > where you can have at least integrity & authenticity. >=20 > AEAD with a single key (which is my preference) is incompatible with > passive monitoring unless integrity is sacrificed as well. >=20 [Joe] I see your point, but its not within our current scope to design = for this. =20 >=20 >=20 >> On Sep 29, 2014, at 9:28 AM, Michael StJohns >> wrote: >>> Hi - >>>=20 >>> This isn't a proposal to change the decision to only include AEAD >>> ciphers in TLS1.3. But something crossed my desk that suggested I >>> should at least mention a possible issue with this. >>>=20 >>> Background: There are number of countries (and private networks) = that >>> have a requirement to decrypt any traffic passing through certain >>> places. There is not a corresponding requirement to allow them to >>> imitate a sender or receiver. This can be done through key escrow, >>> LEAF-like fields or multiple encryption of the data for example. >>>=20 >>> Implication: AEAD ciphers have a single key which is broken down = for >>> use both in the encryption and integrity processes. Revealing that >>> single key (to satisfy the decryption requirement) can reveal the >>> credentials to allow masquerading. If the TLS connection = credentials >>> are also being used as credentials for control actions (e.g. >>> cyber-physical controls of power systems, control over a firewall, = etc), >>> fulfilling the decryption requirement provides an unintended attack >>> surface for possibly life critical systems. >>>=20 >>>=20 >>> Thoughts: At least one AEAD cipher (CCM) uses the exact same key = for >>> both integrity and encryption. There is no way to reveal the = encryption >>> key without also revealing the integrity key. But if you have the >>> integrity key, you can masquerade as sender or receiver (controller = or >>> controlled). >>>=20 >>> Question: In light of the above, should we revisit the AEAD-only >>> decision for TLS1.3? >>>=20 >>>=20 >>> Question: Is there absolutely no requirement for TLS1.3 integrity = only >>> cipher suites? >>>=20 >>> The fallback for systems in areas that have these requirements could = be >>> either TLS1.2, one of the other IETF security protocols, or = something >>> proprietary. >>>=20 >>> And yes, this was triggered by a real-world requirement. >>>=20 >>> Mike >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> TLS mailing list >>> TLS@ietf.org >>> https://www.ietf.org/mailman/listinfo/tls >>=20 >> _______________________________________________ >> TLS mailing list >> TLS@ietf.org >> https://www.ietf.org/mailman/listinfo/tls --Apple-Mail=_C2C28AA5-BD7D-456B-8C2D-B135B517D552 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQEcBAEBAgAGBQJUKx9XAAoJEHDh2NpbGbjAM4AH/RYjxoYEDEemVTR8FdG7sXbm vdLQjpN/+QoKIK9taBOMcYT0nZj01chmpcg3CI0Kk8L1weZBkwjaN7GM8Dn8aUWT mlQqMBKPDV1kbs/5ECqWZ1nyCPKYGUCQQS20/VITVwTvJe0fQt8NEdBDFbPWhwAC MKK/sWzdSHdKKOhCJAoLxpv8JG5wCezAKEjiXUERspC0BE2/61gY23vAYrFRoeoo WL5eTFM+Vm7ScmtP6Q4ng2iyQ8GYyjNsBBVF4Ci9UDiGx/ov/biPdttYLwzstVDR /ET0ksVGScf5T4ZmzyrakIxYAIBwIvI0kug+S2ULLa/ricvVr8cNVXEMBkTlSrQ= =Lnzc -----END PGP SIGNATURE----- --Apple-Mail=_C2C28AA5-BD7D-456B-8C2D-B135B517D552-- From nobody Tue Sep 30 15:19:43 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75BE71ABD37 for ; Tue, 30 Sep 2014 15:19:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q6Kf6QIVvCU9 for ; Tue, 30 Sep 2014 15:19:40 -0700 (PDT) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40B6D1A1BE8 for ; Tue, 30 Sep 2014 15:19:40 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id w8so3501599qac.18 for ; Tue, 30 Sep 2014 15:19:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=UlwKylA67SFb4QKIHwY0zt99RayrAV9SEdlDTT3v5ZM=; b=ZvL9u2HjBRaeBabZnpoJe+5vrkWbqLhu5KmCvCQivA76a6djtoIQoVHn05Lu9epZHL tV83yEM+YFEDHKfzS2/KcQoclOYG2LxQXq8mr5DQau9CMAkIIx/wbmXK8wt9m+nb5clT ah8eUE8Eo+5BwNazZmrJ5yEt4kWqdSM3mvnvbptSr98zcUhnvLtjIshIiLb3cMj8152P b35mNHZGqYuamnXhOQEBQPaZNKs6Wp5tjJWXbbllSPMvL4aXwxN5NOP/G1mhMO0GtlmL 1VT82DstC4vFv1iuF9ZfeesMDGouR77kHHiZDF6uszXsywJV+RJivx1CB4s2hvGsDq6X m9Vw== X-Gm-Message-State: ALoCoQk9621JRf3zdeqcPI2ELax+RHGfv5Ilj1xqW052+tqJFfD8LFVVI5ONVmo88s9X2+zSVfHE X-Received: by 10.140.19.36 with SMTP id 33mr75341176qgg.32.1412115579265; Tue, 30 Sep 2014 15:19:39 -0700 (PDT) Received: from [192.168.1.116] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id l46sm14836283qgd.27.2014.09.30.15.19.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Sep 2014 15:19:38 -0700 (PDT) Message-ID: <542B2C80.7010903@nthpermutation.com> Date: Tue, 30 Sep 2014 18:19:44 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: Martin Thomson References: <542988C5.8050307@nthpermutation.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/WYOtAjFFdWuuRiG7rkTT3ijtkzU Cc: "tls@ietf.org" Subject: Re: [TLS] AEAD only for TLS1.3 revisit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 30 Sep 2014 22:19:41 -0000 On 9/30/2014 4:28 PM, Martin Thomson wrote: > On 29 September 2014 09:28, Michael StJohns wrote: >> Question: Is there absolutely no requirement for TLS1.3 integrity only >> cipher suites? > If you believe that integrity-only modes are valuable, you could > propose an AEAD formulation that does not provide confidentiality. > That's fairly trivial to do with an AEAD construction: just move > everything under the AD part. > > To be a bit pedantic - that's not actually how you would do it. TLS treats the user data as non-AD data. There is no provision in the protocol for moving everything from encryption to AAD only. You could define an AEAD cipher such as NULL_HMAC_SHA256_AEAD could work if you wanted integrity only - it's too bad we can't just use the existing integrity only suites. However, if you want the ability to share the privacy key without having to share the integrity key (and that is a real-world need in various circumstances), you're currently SOL with respect to the current AEAD suites. Later, Mike From nobody Tue Sep 30 15:59:15 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7DF01ACD03 for ; Tue, 30 Sep 2014 15:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.797 X-Spam-Level: * X-Spam-Status: No, score=1.797 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_MISMATCH_COM=0.553, HOST_EQ_NL=1.545, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47Yx8xwXJ5lc for ; Tue, 30 Sep 2014 15:58:58 -0700 (PDT) Received: from vps2.offspark.com (vps2.brainspark.nl [141.138.204.106]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41C671ACC87 for ; Tue, 30 Sep 2014 15:58:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=polarssl.org; s=exim; h=Subject:Content-Transfer-Encoding:Content-Type:To:MIME-Version:From:Date:Message-ID; bh=6wB2/5WNkPwhkp3KdhbEXpqCdNU81bZ5xpwDuXXsKvM=; b=in70yztGwMb2loa+ySxWl8To7Dx9G5NzsoBIp16NL+JXWzWDghfNo7wtLsojyZsP0wdFV0VghkyDvOGvsdUrtMzfAFu1Rh6cmIxaX4N7sNz/01jmGmj6SHVx3308Y+QG14BkmJ6MYkoWWkXNjoVbfJFbusCwAbFqSqOrlcw5oQY=; Received: from thue.elzevir.fr ([88.165.216.11] helo=[192.168.0.124]) by vps2.offspark.com with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1XZ6NU-0003ha-DC for tls@ietf.org; Wed, 01 Oct 2014 00:58:41 +0200 Message-ID: <542B35A2.5090900@polarssl.org> Date: Wed, 01 Oct 2014 00:58:42 +0200 From: =?UTF-8?B?TWFudWVsIFDDqWdvdXJpw6ktR29ubmFyZA==?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "" Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 88.165.216.11 X-SA-Exim-Mail-From: mpg@polarssl.org X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on vps2.offspark.com) Archived-At: http://mailarchive.ietf.org/arch/msg/tls/YDrACyCe6m4obBFpxXod-_O6KUo Subject: [TLS] DTLS retransmit question X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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, 30 Sep 2014 22:58:59 -0000 Hi all, I'm having trouble interpreting some text from RFC 6347 section 4.2.4: Although each flight of messages may consist of a number of messages, they should be viewed as monolithic for the purpose of timeout and retransmission. [...] There are three ways to exit the WAITING state: [...] 2. The implementation reads a retransmitted flight from the peer: the implementation transitions to the SENDING state, [...] Does that mean an implementation is supposed to transition from WAITING to SENDING only when it reads the retransmission of a whole flight? Since the underlying transport is not reliable, one of the messages of the retransmitted flight might get lost: should that prevent from retransmitting in return? An option would be to retransmit as soon as a retransmitted message from the last flight is seen, but that would result in one retransmission per received message in the flight retransmitted by the peer, which would result in a lot of probably useless retransmission, which is bad for congestion. Another option is to retransmit only when a retransmission of the last message of the previous flight is seen, which results in less retransmissions and is a bit less sensitive to message loss than checking for the whole flight. It's also easier to implement (especially for the flight containing the Finished message, since messages from previous epochs can then be dropped by the record layer). This is currently my preferred option, I think. Any clarification of the intention of the RFC, or sensible advice on what to do, would be appreciated. Thanks, Manuel. From nobody Tue Sep 30 17:04:35 2014 Return-Path: X-Original-To: tls@ietfa.amsl.com Delivered-To: tls@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 597C81ACD00 for ; Tue, 30 Sep 2014 17:04:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8EKld0YvQcEY for ; Tue, 30 Sep 2014 17:04:31 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 46C261A9238 for ; Tue, 30 Sep 2014 17:04:31 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 2B423BE08; Wed, 1 Oct 2014 01:04:30 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PsRzALsQIBRY; Wed, 1 Oct 2014 01:04:28 +0100 (IST) Received: from [10.87.48.7] (unknown [86.46.31.250]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id D8561BE04; Wed, 1 Oct 2014 01:04:28 +0100 (IST) Message-ID: <542B450C.5010304@cs.tcd.ie> Date: Wed, 01 Oct 2014 01:04:28 +0100 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "Joseph Salowey (jsalowey)" References: <542988C5.8050307@nthpermutation.com> <44A2498B-D0CB-415C-A1D8-2E362FD8BDF0@cisco.com> In-Reply-To: <44A2498B-D0CB-415C-A1D8-2E362FD8BDF0@cisco.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/tls/e-ZgbnxXauhQW4E97nB4oAbBJUY Cc: "tls@ietf.org" Subject: Re: [TLS] AEAD only for TLS1.3 revisit X-BeenThere: tls@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "This 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: Wed, 01 Oct 2014 00:04:34 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hiya, On 30/09/14 22:23, Joseph Salowey (jsalowey) wrote: > [Joe] I see your point, but its not within our current scope to > design for this. IMO Joe is fully correct. This WG has repeatedly dealt with proposals of many kinds for standardising MiTM attacks on TLS and has repeatedly rejected that functionality. And should it ever be in favour while I'm the irresponsible AD, I'll be asking for the complete analysis of the impact of that on the literally hundreds of other IETF specifications (not to mention non-IETF specs and running code) that depend on TLS and implicitly on TLS not enabling a MiTM. I've raised this point in response to the last 3 or maybe 4 (I've lost count sadly) proposals to MiTM TLS and have yet to get a substantive response. This seems to me to be just another in this series of attempts to legitimise such MiTMs, albeit in this case as a comment on an already establish bit of WG consensus. (The MiTM part is the suggestion that different keys be established with those for confidentiality being "revealed.") Yes, I know that there are deployments that do MiTM TLS. Yes, I know that there are some people who say that is required for some definition of required. (There are also those who claim doing so is anathema, so the existence of an argument is not in itself convincing.) I would ask however that those making the MiTM argument please set that out clearly as the change that it would represent to current IETF consensus documents such as RFCs 2804 and the pretty recent 7258 and others. But first try establish IETF consensus on your MiTM principle. That (establish the principle first) would seem to me to be the proper order required for such a change. S. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUK0UMAAoJEC88hzaAX42ikfUIAJxdIBnNfQaZWjczMiz68Jsw +LUzR4xsPn4nosJAsUWoGEOQI6yP8aj90qPdYMEF5tYORVtdhrDtfjy9Lkl25884 9xep6ug86ya0JHlWmVdcjfH1gg9MIFw0MgH8XqENagCcYzXfpoCmJ6njVwimqROS ZuZnTV+Fa9Offx95d3eZUY1fbe9kAPD18ClXry9J0CbDxxeKWumTLIz/egSGNv1q kFokSJbyRmmzMBEVlUb/iY+Hx8zbqSnwR0n+BiyKIrvWiUn3ZWw5KT9HVoFuBZZS 4czdFaWp9//J7GdJGZg5xz5LLBzeBB6VlFjjVNwiHXoFjswJBjgEuOf5yJQPEEQ= =k+r4 -----END PGP SIGNATURE-----